DoxRunner
​
Script Operations
​Improving script development efficiency is the ultimate goal of documenting test cases in the special way described on these pages.
The efficiency starts with recording a raw script - only the Timer IDs are typed in while recording. The DoxRunner application fills in those details that the scripter would normally need to.
After recording, processing a raw script by the Process Raw operation applies the definitions and configuration in the test case in such a manner that, for a properly documented Test Case, the script will, on average, be 70% complete. Sometimes 100% complete.
There is a one-for-one relationship between a Test Case and a script. There can be multiple recordings of that script, but with each recording, the effort by the scripter is reduced.
​​
Recording a raw script
​
LoadRunner provides several facilities while recording a script. Recording the DoxRunner way is faster.
​
While recording you would normally do the following:
-
Enter the start transaction name (so that an lr_start_transaction function can be inserted by VUGen);
-
Flag the end of a transaction (so that the corresponding lr_end_transaction function can be inserted by VUGen);
-
Enter validation text (so that a web_reg_find() function can be inserted by VUGen);
-
Enter comments to assist you during post recording activities.
​
However if you need to re-record the script for whatever reason (perhaps because the application has changed or you have made a mistake), then you need to re-type these items, and that can be time consuming.
​
If, however, you have prepared a Test Case in accordance with the guidelines set out in this site, then you will have prepared a Transaction Timers section within it containing all business process steps that need response times to be recorded during a load test. Each business process step represented by a Timer row in the Timer table.
​
It is assumed that, for each Timer, you have completed, at a minimum, the Timer ID and the Timer Name cells in the row.
​
If you record the timers using the guidelines set out below, then you will only need to type in the Timer ID during recording.
The raw script will contain skeleton lr_start_transaction() functions as shown below.
The attributes of each Timer will be put in place automatically when you use the Process Raw operation.
​
Recording the traditional way
​
Recording the DoxRunner way
​
As you can see from the illustration below, there is a big difference when recording a script using the DoxRunner way..
​
-
Instead of typing in full timer names and other elements of a timer as you record, all you need to type in are the Timer IDs;
-
All transactions are recorded into Action.c. That is, vuser_init.c and vuser_end.c are left empty.
The assumption is that you have created the relevant Test Case and documented all Timers.
It is also advisable to have the test case open with the Timers table in view so that you can refer to any notes in the Notes column.
​
Refer to the Recording Tips below.
The Process Raw operation will fill in the gaps.
​
It will:
-
add the Timer Names to the lr_start_transaction() names;
-
add the respective lr_end_transaction() functions;
-
add the Expected Results as a comment;
-
add web_reg_find() functions;
-
transfer requests from Action.c to vuser_init.c or vuser_end.c as specified in the Phase column of each Timer.
Recording tips
​
For complex business processes there may be 10 or more timers required. Often these exist as notes that the performance test analyst has taken while exploring the process with the business analyst(s). After recording, the notes are often thrown away.
​
DoxRunner offers a more professional way of doing this. By documenting the business process steps as timers in each test case's Timer Section, the document can be used during the initial recording, reused if rescripting is needed, and shared with management, business analysts, and other team members.
​
Create the Test Case and document the business process steps - one step per Timer - in the Transaction Timers section.
​
​When recording, have the documented Timer Section available for reference. Update it if necessary, particularly the Notes column. ​This ensures more accurate recording and ensures others can benefit from any changes.​
​
Apply an iterative approach to scripting, as set out below.
​
​
Skeleton lr_start_transaction() functions
​
If you follow the advice in the Recording page above, then VUGen will have only recorded an lr_start_transaction() function prior to the first request of each business process step.
​
No lr_end_transaction() will be recorded.
The lr_start_transaction() will be a skeleton, only containing the Timer ID as shown below.
For example, at the beginning of Timer ID '8', only the following will be recorded:
​​
​​The Process Raw operation will append an lr_end_transaction() function to the end of the last request in the business process step.
It will also replace the lr_start_transaction() skeleton with an expanded Timer Name as shown in the illustration below.
​
​
Iterative approach
​
Because recording is so quick and easy, and the Process Raw generates a script so easily, an iterative approach can be contemplated.
​
​That is, execute the following 6 paragraphs each time the the application is deployed into the test environment:
1. Record the script against the application in the test environment using the Timers document in the Test Case. Save it into the Scripts folder that is configured in DoxRunner's Configuration Items section.
2. Start correlating, but don't update the script, update the Test Case documentation instead;
3. Document the URL(s) in the Additional Attributes or Custom Parameter sections of the Test Case, but don't update the script;
4. Document any test data that you know about so far into the Test Case. Choose whether to document them in the Text Data File, VTS, or LoadTest Database sections. Include Test Accounts into one of these three test data options. Don't update the script;
​
5. Execute the Process Raw operation, which will update the script with the contents of the Test Case;
​
6. Wait until the next deployment of the application into the Test environment. Then re-start at No. 1 above.
​
When the application has completed functional testing with severe and high defects rectified and released into the load testing environment, the Test Case should be updated as much as possible, and the Process Raw operation should produce a script that is close to completion. If not, then any parameterisation that is needed, once again, update the Test Case, not the script. Then re-run the Process Raw operation. Continue this until the script passes shakeout tests.​​
​
It is rare for the Process Raw operation to do everything. After it has completed, you will need to review the script and tailor it.
​
Review all lr_start_transaction() functions, looking for Timers that generated no request - consider deleting them and, optionally, renumbering the remainder. If renumbering them in the script, don't forget to align the Timers table in the Test Case with the new numbers.
Review all requests that don't belong and delete them. Typical examples are requests to Google or Microsoft.
Do not alter the format or anything else in the script.
​​​​​​
Process Raw operation
The Process Raw operation takes a raw script and applies all rules documented in the corresponding Test Case to it.