DoxRunner
​
DoxRunner and LoadRunner
​
Performance testing challenges
​​​​​
LoadRunner scripting faces many challenges. DoxRunner attempts to minimise the impact of these.
​
​Scheduling
Performance testing relies on the system under test to be working as designed, with no high or medium priority defects remaining.
​
This is because proper load can only be achieved if all transactions complete without functional errors. The only errors should be load-related, such as timeouts (hopefully minimal).
Because of this, in a typical project, scripting typically starts after functional testing is complete with no high or medium priority defects.
​
If functional testing is late, and it often is, the time for performance testing activities to be completed is often shortened in order to bring the project in on time.​​
​​
Solution:
​
-
Start documenting early - create one test case per business process. Add the timers and any other rules that are known such as text data files, test accounts, additional attributes, etc.
​
-
Take advantage of DoxRunner's fast recording process followed by the process raw operation, even though you may not be able to complete recording and even though the script may not work properly. But don't waste time correlating the incomplete script - instead identify correlation rules and add them to the documented test case. That means, for each iteration of the process raw operation, the new script gets automatically updated with the documented timers and correlation rules, and any other rules you identify.
​​
-
If this is done, then when functional testing is complete and the application is migrated to the load test environment, very little needs to be done to finalise the documentation and then the script.
​​
Application changes​
​
So you've prepared the scripts, ready to test, and for some reason the application changes. So you need to re-record, re-correlate, and re-shakeout the scripts.
​
Or you've tested the application, and it performs poorly, with high to medium priority performance defects. And the defects have been rectified, but only because the application needed to change. So you need to re-record, re-correlate, and re-shakeout the scripts to verify that the application changes worked.
​
Or this is a new project, the application is upgraded with new functionality, and the old scripts no longer work. So you need to re-record, re-correlate, and re-shakeout the scripts.
​
Solution:
​
If you had documented the test cases in accordance with DoxRunner's processes, then simply re-record the script using the new application with DoxRunner's fast recording process.
Then execute DoxRunner's process raw operation. All of the earlier work will then be applied to the new script.
​
Examine that new script to see what changes are required, update the documentation if necessary, and re-execute the process raw operation.
​​​
Complexity
Scripting with LoadRunner isn't simple. But an experienced scripter can record, correlate, and shakeout a script fairly quickly.
​
However applications are all different and add their own complexity. Scripters typically don't get involved in the development of an application (except via defects), so often they need to reverse engineer the way web responses are to be handled.
​
​​As a system gets more complex, the more important is its documentation. The benefits of the write once, read many, attributes of a document cannot be overstated.
​
Unless solutions to the quirkiness of an application are documented, the effort involved in making sure the scripts handle them is lost.
​
​Typically, performance testing documentation is limited to the communication between the business, who provide the requirements and the business processes needed to be tested, and the test analyst who needs to prepare the scripts and the scenarios.
​
Solution:
​
You guessed it - document the rules plus any tips and tricks needed to deal with the complexity that was learned during the script development process.
​​​​​​​​
Handover
​​Often an organisation insists on the preparation of a handover document so that all issues can be seamlessly transferred to other team members, or new teams responsible for the next iteration of an application's development.
​
If a scripter is replaced and if no documentation is prepared by the previous scripter, the new scripter will need to chew up time to come up to speed before progressing.
Solution:
The solution document becomes the handover document. It should contain enough information for a new scripter to quickly come up to speed.
​​​​​
Legacy scripts
​​Often you are confronted by a suite of legacy scripts that have no comments or supporting documentation. So you need to start from scratch, despite the amount of work that the previous scripter put into it.
Solution:
Create test cases to suit, then apply DoxRunner's reverse engineering operation to each script.
This will capture most rules and update the test cases with them, ready for the process raw operation to be applied to a newly recorded script. Obviously some tailoring will be needed. Try to tailor the scripts via its documentation.
​​​​​
Caveat
​​​​DoxRunner does not recognise TruClient scripts.
​
​​