DoxRunner
Macquarie University Student Accommodation
Overview
The Configuration Items (CIs) described here are located in the Configuration section of the Solution document. Once set, they are expected to change only rarely.
It is also expected that they remain the same across all test cases in the solution.
​
However, there may be occasions where a test case requires one or more of the configuration items to be different. In that situation, a Configuration section can be added to any test case. Any CIs within a test case will override corresponding CIs in the Solution document.
​
The CIs can be catalogued into five separate groups:
​
Example
​
The illustration below shows all CIs with example values.
​
Foundation CIs
​
There are six Foundation CIs. With the exception of the Protocol CI, they are simply for documentation purposes. Any of them can be deleted from the Configuration section table if they are not relevant to the solution.
Whenever the Process Raw operation is applied to a test case, it places the Value into vuser_init as illustrated below. The illustration also shows the Test Case Name and Generation Date, which aren't CIs but are included for documentation purposes. The date refers to the date when the Process Raw operation was applied, not the date when it was recorded or last manually updated.
Each of the six CIs are described in more detail in the six paragraphs following the illustration.
Organisation
​
This is used for documentation only. Choose a short version of the organisation. It appears at the top right hand corner of all screens and in vuser_init as illustrated above
​Solution
​
This is used for documentation only. It only appears at the top of vuser_init as illustrated above.
Project
​
This is used for documentation only. It only appears at the top of vuser_init as illustrated above.
​
Release
​
This is used for documentation only. It only appears at the top of vuser_init as illustrated above.
Environment
​
Normally performance testing is executed in its own environment, and there are many reasons for this. However, if the script needs to be executed in more than one, then there may be subtle differences between them.
The Value of the Environment CI will be documented at the top of vuser_init as illustrated above, but it may be used for conditional execution also.
For example, if the script needs to be tested in a SIT environment but executed in an SVT environment, then it may be more convenient to toggle URLs between them, using a Global parameter and/or an Additional Attribute based on this Environment CI.
​
Protocol
The default is HTTP/HTML. Other values are:
-
Siebel
-
SAP Web
-
MS Dynamics CRM
The Value of the Environment CI will be documented at the top of vuser_init as illustrated above.
Some specialized operations are utilized by DoxRunner operations when Siebel or SAP Web is specified.
Folders
​
There are 4 folders that the DoxRunner operations need to know about. They tell them where to find files. The illustration below shows how to configure them. It also shows them located on the C: drive, however they can all be located on a network drive if that is more appropriate for team access, so long as the drive is configured with sufficient capacity (espcially throughput).
​
The four paragraphs below the illustration describe them in more detail.
Support folder
​
The Solution document and the Test Case Template documents must be placed in this folder.
​
A test case will be placed here when it's checked out. To check-in a test case, it must be placed here too.
​
Although not essential, the DoxRunner.docm file will normally be placed here too, especially for a single solution.
​
Included Files folder
​
This folder contains all files that the DoxRunner operations need to include in a script. Although the illustration below shows this folder to be a sub-folder within the scripts folder, this is not necessary - it can be anywhere.
​
Any file in this folder that has .c as the extension is inserted into the Actions section of the script (examples include mySQL.c, SessionManagement.c and Libs.c).
Any file that has a .dat or .txt extension is simply copied into the script's folder - they are assumed to be text data files.
​
All other file types are added under the Extra Files section (examples include mySQL.dll and pcre3.dll).
​
Example folders
The example folder structure shown here was not created using LoadRunner's solution facility. Although the structure is shown on the C: drive, it could be located on a network drive for team access and operation.
​
LoadTest Database CIs
A MySQL database installation can consist of multiple databases. These can be used for several purposes such as one database per project, or one per release or one for everything. If a MySQL database is used as the LoadTest Database, only the database name is required here. However it is expected that all elements of the LoadTest database are set up properly in mySQL.c.
The DoxRunner operations will assign the Database Name CI to a parameter in vuser_init as shown here:
The parameter is used when the DoxRunner operations prepares the DatabaseOperations.c action as shown here:
VTS CIs
The VTS CIs are used by DoxRunner to configure the VTS connect statement in vuser_init.c as shown in the illustration below.
​
If the CTOPT_KEEP_ALIVE argument is not appropriate, it will need to be manually changed.
Correlation Option
This simple Yes/No CI tells the DoxRunner operations whether to process Correlation Rules using the DoxRunner process or leave it up to the native VUGen process.
​
Yes: Process the Boundary and Regex correlation rules in accordance with the Solution document and/or the test case;
No: Leave it up to the native VUGen process, or correlate manually.
​
Timer Name Template CI
This CI guides the DoxRunner operations to reformat timer names from the step number-only format (as recommended during recording) to a proper name.
Different organisations use different formats for the names of their timers. The most common examples are:
<Step No> <Step Name>
<Test Case ID> <Step No> <Step Name>
<Test Case ID> <Test Case Name> <Step No> <Step Name>
Use one of the above or make up your own from one of the following, in any combination:
<Step No>
<Step Name>
<Test Case Name>
<Test Case ID>
Use whatever you want as the delimiter (space, underscore, dash, anything). Although absurd, the following templates are valid:
<Test Case ID> amy <Step No>???<Step Name>
<Test Case Name>@#$ <Step Name>
<Step No> 444<Step No><Test Case Name>
Example 1 shows the result of timer template <Test Case ID> <Step No> - <Step Name>
As recorded:
As applied:
Example 2 shows the result of timer template <Test Case ID> <Test Case Name>_<Step No> <Step Name>
As recorded:
As applied:
Validation Template CIs
These two CIs are optional and are used to assist in the preparation of web_reg_find functions by the Process Raw operation. They can be used to supplement those that are defined in your instance of VUGen, which is restricted to <title> </title>. One difference is that the LB and RB specified here in the Configuration section are included in the web_reg_find function, whereas the one defined in VUGen excludes them. Including them enhances page verification.
​
When processing a script, the Process Raw operation prepares one web_reg_find function per request. The first request in a step is special. If the Validation column in the Steps table of the test case is not empty, it uses that. However if it is empty, it searches the appropriate response in the snapshot file(s) for text bounded by the above two Validation Template CIs. If found, it uses that text.
If not found, it still prepares a web_reg_find function, but it is commented out and default text is used. It is expected that the scripter will manually search for relevant text to replace the default text, and un-comment the web_reg_find function. If this is the first request in a Step, then it is also expected that the scripter will paste that text into the Validation column of the Steps table, ready for the next time the script is generated.
​
​web_reg_find("Text=<script type='text/javascript' src='/ui/general.js'></script>",LAST);
​
​
Validation template examples
Example 1 - Standard VUGen
1. VUGen Recording Options configured as shown on the right;
2. Both LB and RB Validation Template CIs are deleted;
3. The Validation column of the Steps table is empty;
4. The response to the first request in the step contains:
<title>Available Sugar Content</title>
Outcome:
Example 2 - Validation Template CI only
1. VUGen Recording Options are disabled as shown on the right;
2. Both LB and RB Validation Template CIs are in place:
LB = <title
RB = </title>
3. The Validation column of the Steps table is empty;
4. The response to the first request in the step contains:
<title>Available Sugar Content</title>
Outcome:
Example 3 - Validation Template CIs exist and the step contains text in the Validation column
1. VUGen Recording Options are disabled as shown in the previous example above;
2. Both LB and RB Validation Template CIs are in place:
LB = <title
RB = </title>
3. The Validation column of the Steps table contains:
Unploughed fields are difficult.
4. The response to the first request in the step contains these two items of text:
<title>Available Sugar Content</title>
Unploughed fields are difficult.
Outcome:
Example 4 - Unable to find any validation text in the response
Regardless of the VUGen settings, the Validation Template CIs or the Validation column of the Steps table, if the value cannot be found in the response, then the web_reg_find function cannot be configured.
However, to save typing, a commented out web_reg_find function is inserted, ready for the scripter to manually identify and insert relevant text. If it is the first request in a Step, then the scripter should also insert the value into the Validation column of the Steps table for future script re-generation.
Outcome:
