DoxRunner
Macquarie University Student Accommodation
Overview
Updating a raw script with parameters is a critical process in preparing LoadRunner scripts for a load test. It usually consumes most of the time of a scripter during a period of a project where time is critical. Any process to reduce this time increases the productivity of the scripter.
If a script needs to be re-recorded, the parameters normally need to be re-applied each time, often manually.
DoxRunner significantly reduces scripting time by providing a framework for documenting parameter rules in such a manner that they can be applied automatically to a raw script by DoxRunner's Process Raw operation, reducing manual intervention.
​
DoxRunner categorizes parameter rules into 4 groups:
​
Test data parameters
​
Test data is critical to the operation of a script in a scenario.
DoxRunner's Test Case and Script operations support three methods for handling test data:
​
There is only limited support for VTS. That is, there is a section reserved for VTS in the documents, but DoxRunner's Script operations only recognizes a subset of its functions.
​
Text Data File parameters
A Text Data File parameter is LoadRunner's native method of handling data.
DoxRunner supports Text Data Files by:
-
providing a framework for documenting them as rules (in a Test Case and/or in a Solution document);
-
providing a process whereby those rules can be automatically applied to a raw script using DoxRunner's Test Case and Script operations.
​
LoadTest Database parameters
The LoadTest database option for managing data uses a MySQL database which is superior to Text Data Files and VTS.
​
Although native LoadRunner doesn't support this method, DoxRunner's Script operations provides a mechanism whereby it can, using an easy point-and-click parameterization of database table columns, plus the creation of skeleton functions to tailor database interaction.
Virtual Table Server (VTS) parameters
VTS is LoadRunner's alternative to Text Data Files.
DoxRunner's Test Case and Script operations provide limited support for this method.
In any case the LoadTest Database functionality is superior.
​
Correlation rules
​
DoxRunner's Test Case and Script operations support two types of correlation rules:
​
​
Boundary Correlation rules
​
A Boundary Correlation Rule is a template for preparing one or more web_reg_save_param_ex functions. It is a mechanism for documenting the results of manual correlation for use if re-recording.
​
DoxRunner's Test Case and Script operations have extensive support for applying these rules to a raw script.
​
Regex Correlation rules
​
A Regex Correlation Rule is a template for preparing one or more web_reg_save_param_regexp functions. It is a mechanism for documenting the results of manual correlation for use if re-recording.
DoxRunner's Test Case and Script operations have limited support for automating the creation of Regex parameters in a raw script.
​
Other parameters
​
Custom parameters
DoxRunner's Test Case and Script operations recognize two types of Custom parameters: Global and Iteration as defined below. Whether a Custom parameter is deemed Global or Iteration is automatically determined by the DoxRunner Process Raw operation.
​
​
Global Custom parameters
A Global Custom parameter is one that has a value assigned to it only once (in vuser_init) and all instances of that value in all of the script's files are assigned to that parameter. It is useful for text such as URLs which may need to be redefined if, say, another environment is to be used before testing is complete. It means that if a script needs to be updated, the update needs to be done in only one place.
​
​
Iteration Custom parameters
​
An Iteration Custom parameter is one that has a value assigned to it at the top of Action.c, and all instances of that value in only the Action.c file are assigned to that parameter. The parameter is reassigned at the beginning of each iteration. It is useful for values that need to change every iteration. It gives the scripter the opportunity to apply a function or a LoadRunner value to the parameter in a place that's highly visible.
Random Number parameters
As expected, a Random Number parameter manages random numbers.
​
​The DoxRunner's Test Case and Script operations support this parameter type.
Additional Attributes
An Additional Attribute allows a performance tester to assign a value to a parameter via a scenario in Performance Center or a Controller without needing to update any of the scripts, so long as the scripts recognize the additional attribute and can parameterize it.
Although LoadRunner doesn't recognize Additional Attributes as a parameter type, DoxRunner's Test Case and Script operations support this process by providing mechanism to convert the Attribute Name to a parameter.
​
Unsupported parameter types
​
These parameter types are not supported by any DoxRunner operations. If you need to document them, then you will need to create your own section and manually apply them to the LoadRunner script.
​
-
Group
-
Iteration Number
-
Load Generator Name
-
Table
-
Unique Number
-
Use Defined Function
-
Vuser ID
-
XML