DoxRunner
Macquarie University Student Accommodation
Overview
If a script can be used for more than one purpose with the simple setting of some text, then Additional Attributes is the way to go. An Additional Attribute allows a performance tester to apply configuration to a script at runtime without needing to update the script.
They are defined in an Additional Attributes section which is described below.
The Performance Test Support process uses an Additional Attribute parameter rule to do the following:
1. Create an Additional Attribute in the Runtime Settings
2. Add functions to vuser_init to extract the Additional Attribute at runtime and assign it to a parameter
3. The assigned parameter works in a manner similar to the Global Parameters in that the value is parameterized in all script files
Two benefits are:
1. If a transaction needs to be applied using two (or more) different data values, each requiring the test to submit them at different volumes, but the script is essentially the same for each data value, then only one script needs to be developed, with the variations configured as Additional Parameters. In a scenario, the script is added twice, once for each variation. For each of the two entries, the Additional Attributes are changed in the scenario to suit.
2. If one variable changes over time, and all scripts use the same variable, such as the name of the LoadTest database, then the scripts need not change, nor is there a need to update the Additional Attributes. The Additional Atrributes for all script in a scenario can be applied using the scenario's command line.
How it works
The diagram below shows what happens when the Performance Test Support application is applied to a raw script. The definitions are added to the runtime settings, the code to extract the values and assign to a parameter is inserted into vuser_init, and all values in all script files are parameterised. A comment containing the description is appended to the line that assigns the value in vuser_init, and, optionally, a comment containing the original value is placed at the end of each line that was updated.
​
The example on the right shows that this test case defines 3 Additional Attributes. The Description column documents what needs to be done.
The Process Raw operation of the Performance Test Support application automatically adds the Additional Attributes to the runtime settings of the script.
The Process Raw operation of the Performance Test Support application prepares lr_get_attrib_string functions for each rule and inserts them into vuser_init.c. The resulting parameters (starting with a... in this case) become ready for the scripter to use in the script.
If the LoadTest database is used, the illustration on the right shows how the Performance Test Support application automatically prepares the initialisation function using the aDatabaseName parameter, which, earlier in this example, is assigned from an Additional Attribute called DatabaseName. It allows the LoadTest database name to be changed in all scripts using the command line of the scenario at execution time without changing any of the scripts.
This is an example of the use of the aCreateData parameter (from an Additional Attribute called CreateData) where the scripter has manually tailored the script to test whether it is to create data or not. It allows this script to be included in scenarios used for load testing and separate scenarios to create data without the need to manage two scripts or to change the script in any scenario.
Parameterizing values
Once the code to extract the value from the Additional Attribute at runtime using function lr_get_attrib_string and assigned to the relevant parameter by the Process Raw operation of the Performance Test Support application, no further processing is done - the values in the script must be manually parameterised.
​
Scenario Configuration
The Performance Test Support application does not configure any scenario. The example here shows how Additional Attributes can be manually configured in a scenario.
Example 1: The script CEP005 Sugar Content Estimation Process can be executed in two ways with slightly different changes in code branching. Each applies a different load on the system and they are to be executed with very different transaction rates.
The script is added to the scenario twice, each with a different Group Name, as illustrated below.
Each group name has its Additional Attributes value configured differently (as illustrated below) so that the code can branch as expected, and the transaction rate can be tailored accordingly.
Example 2: An Additional Attribute called aDatabaseName applies to all scripts in the scenario. In this case it is configured in the command line of the scenario. When configured here, the value overrides the values set in the runtime settings of each script, making it a fast was of configuring scripts where overall options are needed. If a script doesn't need this attribute, the command line setting is ignored by that script.
A similar command line setting is available for scenarios on the controllers when Performance Center is not used.
Section Management - Additional Attributes
An Additional Attributes section may appear in two places (unlike the Global Parameters section, which can appear in three places):
-
Test Case Template document
-
Any Test Case
It is optional. Unless you have deleted it from the Test Case Template document, it will be included in all new test cases you create.
It is a relatively simple section. The important components are identical to all other sections that contain a table. That is, the important components are the bookmark and the table.
The parameter rules in the table are described in more detail below.
Manually deleting or re-adding the whole section in a test case or in the Test Case Template is relatively straightforward, but must be done with care.
For the test case, make sure you follow the appropriate link on the right and review the methods described there before taking any action.
The one in the Test Case Template must be manually managed.
In the Test Case Template
If the section exists, it is semi-structured:
-
The bookmark in the Test Case Template document = P_AdditionalAttributes
-
Title - can be any text, but the Microsoft Word style should begin with I_Appendix.
-
Text - can be any text up to 1,000 characters. The Microsoft Word style should be I_BodyText.
-
Table - must contain at least three columns with heading text Parameter, Attribute, and Value as shown below. A Description column is useful and if it exists is appended to the line in vuser_init where the parameter is assigned.
The symbol that looks like this is not linked to anything at this stage - it will include a link only in the test case when it is created.
It is recommended that you leave the section empty in the Test Case Template.
In the Test Case
This section is optional in a test case. It is a part of the Test Case Template document, so, unless you have deleted it from there, it will be included in all new test cases you create.
If the section exists, it is semi-structured:
-
The bookmark for an instance in a test case will include the test case ID. For example P_CEP001_AdditionalAttributes
-
Title - can be any text, but the Microsoft Word style should begin with I_Appendix
-
The symbol at the end of the section title now links to the top of the test case
-
Text - can be any text up to 1,000 characters. The Microsoft Word style should be I_BodyText
-
Table - must contain at least three columns with heading text Parameter, Attribute, and Value. A Description column is useful and, if used, is appended to the vuser_init line where the value is assigned.
All entries in the table must be manually entered. Experience will guide the scripter as to which value is useful.
How to add Additional Attribute parameter rules
Adding an Additional Attribute parameter to an existing Additional Atributes section in a test case is simply a matter of adding it to the table, making sure there is one row per parameter and that the Parameter Name is unique within the script.
Parameter column
The parameter must conform to LoadRunner naming rules. The Value is assigned to it in vuser_init.c during runtime.
Attribute column
The name of the attribute as inserted into the runtime settings.
Value column
The value specified here is the default value assigned to the Parameter if the person setting up the scenario or initiating a test doesn't change it.
Description column
The description is also inserted into the Runtime Settings. It is suggested that it include all possible values and their effect.
How to delete Additional Attribute parameter rules
Except for the last one, deleting one or more Additional Attributes in a test case is simply a matter of manually deleting the appropriate rows in the table.
The row of the last one should not be deleted - instead clear the row of all text.
If it is not expected that there will be any need for them for that test case, consider deleting the section altogether, making sure you delete its associated bookmark too.