DoxRunner
Macquarie University Student Accommodation
Overview
DoxRunner facilitates the documentation of Transaction Timers.
DoxRunner also facilitates an efficient method of recording a raw script, where only the Timer ID is entered when a new step in the business process is started. Also when recording, the transaction is not ended, and all steps are initially placed in Action.c.
DoxRunner also facilitates the completion of the timer details from the documentation using the Process Raw operation.
​
That is, the Process Raw operation completes the lr_start_transaction(...) name and inserts an lr_end_transaction(...) function in the correct place. It also replaces all think_time() functions with those from the documentation, and prepares web_reg_find() functions from the documentation.
​
The Process Raw operation can insert three types of timer:​
​
How it works
If you follow the advice in the Recording page, then VUGen will have only recorded a Start Transaction at the beginning of each business process step. The Start Transaction will only contain the Timer ID only. No End Transaction will have been recorded. For example, at the beginning of Timer ID 8, only the following will be recorded:
The Process Raw operation will replace the Timer ID in the Start Transaction function with the Timer Long Name in accordance with the Timer Template CI.
​
For example, a Timer Template of <Test Case ID> <Timer ID> <Timer Name> with Test Case ID of CEP001 and Timer Name of 'Enter Details' will result in a Timer Long Name shown here:
The Process Raw operation will also replace any think times with one using the value in the Think Time column as shown here:
​
If the Validation column contains text, the Process Raw operation will insert a web_reg_find function containing that text:
If the Validation column is empty, then validation text may be sourced elsewhere. Refer to here for more details.
The Process Raw operation will make all functions associated with each Timer easy to identify by inserting an easy to see line and the Timer ID / Timer Name at the beginning of each step:
The Process Raw operation will insert the Expected Result just below the visual cue:
The Process Raw operation will add the End Transaction function just after the last request associated with the business process step:
If the Add Common Timers option was selected, the Process Raw operation will wrap the normal timers described above with another timer designed to accumulate all steps with the same name, irrespective of the Timer ID or test case they belong to (so long as all scripts are in the same test):
If the Transfer Steps option was pressed, the Process Raw operation will identify steps with phase LI, TI, and LO and move them from Action.c to another action file depending on where specific text is located. Refer to here for more details.
​
Setting the Think Time Options
​
Think Times for each business process step are documented in the Transaction Timers section.
When initiating the Process Raw operation, the dialog box illustrated on the right is presented, with the Think Time options.
​
You can choose whether to source the Think Times from the Think Time column of the Transaction Timers section of the test case document, or set it to a fixed value.
​
You can also specify the Think Time range if you want to randomize them. The Runtime Settings will be configured accordingly. However, the Process Raw operation sets the Think Time option in the Runtime Settings to be "Ignore think time", as shown below. This is to facilitate initial shakeout testing, where Think Time may slow down shakeout testing. Once shakeout testing is complete, you must review these options and set the one that is appropriate for your test.
​
Setting the Timer Options
​
DoxRunner supports three types of Transaction Timer:
​
-
Step - wrapped around all requests associated with one business process step;
-
Common - also wrapped around one business process step, but with any context such as the Test Case ID and Timer ID removed - only the Timer Name remains *;
-
End to End - wrapped around all requests in Action.c.
When initiating the Process Raw option, the dialog box on the right is presented, with several Timer options. The Add common timers and Add 'End to End' timer options are self-explanatory.
​
The Timer Name Template allows you to tailor the format of the Long Timer Name wherever it is used. The default is shown in the illustration on the right. The default can be changed using the Timer Name Template CI in the Configuration section, or you can alter it in the dialog box illustrated on the right. Some testers prefer underscores instead of spaces between the components.
​
* The Common timer names begin with an underscore so that when the Analysis Summary is prepared, they appear altogether at the top. In this way you can decide whether to delete them all, or delete all except a sub-set that may be of interest. For example, if a Timer Name of "Press Cane Estimate Button" appears in several scripts, their response times are grouped together in the one report summary line as "_Press Cane Estimate Button".
​
Example:
​
If all three timer types are configured as shown in the illustration above, then the following three transaction timers are inserted at the top of Action.c:
lr_start_transaction("CEP001 Cane Volume Estimation Process_End_To_End");
lr_start_transaction("_Enter Lot Number");
lr_start_transaction("CEP001 05 Enter Lot Number");
​
Points to note about the above example:
-
The Test Case ID is CEP001;
-
The Test Case Name is Cane Volume Estimation Process;
-
The Timer ID is 05;
-
The Timer Name is Enter Lot Number.
​
Validation
​
There are three levels of validation covered here. DoxRunner supports two of them.
Standard VUGen
​
When recording, the setting in the illustration below allows VUGen to identify text between the title tags, and configure the script with web_reg_find() accordingly. This setting is compatible with the DoxRunner method.
​
Advantages:
1. All responses are examined and the web_reg_find() function is placed prior to the relevant request;
2. It's easy to set up and seamless when recording and replaying.
​
Disadvantages:
1. The LB and RB tags are not flexible - they are always <title> and </title>;
2. The tags aren't included in the web_reg_find() function.
For example, if <title>Create Purchase Order</title> is detected in a response, then the following is placed just prior to the relevant request:
web_reg_find("Text=Create Purchase Order", LAST);
​
Validation Template in the Configuration Section
​
The LB and RB can be specified as CIs in the Configuration section of the document. The Process Raw operation will search all responses and, if the LB and RB are identified, a web_reg_find() function is placed immediately prior to the relevant request. The LB and RB text is included in the web_reg_find() function.
​
Example:
The illustration below shows the boundaries to be <ins and </ins>.
If this text is found in the response: <ins>Create Purchase Order</ins> ...
...then this function is inserted immediately prior to the appropriate request:
web_reg_find("Text=<ins>Create Purchase Order</ins>", LAST);
Advantages:
1. The boundaries can be different to the VUGen default;
2. The tags are included.
​
Disadvantages:
1. May not apply to all responses.
​
Validation Column in the Transaction Timer Section
​
Specific text can be specified for any business process step by inserting it into the validation column of the Transaction Timer section.
This is useful if no LB and RB can be identified, or if it is different to that specified in the Configuration section.
​
Example:
The illustration below shows that User Management is expected in the response.
This function is inserted immediately prior to the appropriate request whether the text is in the response when recording or not:
web_reg_find("Text=User Management", LAST);
Advantages:
1. The text can be tailored to a specific business process step.
​
Disadvantages:
1. After recording, the response must be manually examined for unique text then manually added to the cell in the Transaction Timer section.
​
