The organization had initially invested in a full Mercury Interactive suite of tools - including LoadRunner. As stated in the Mercury's QuickTest Professional evaluation both TestDirector and QuickTest Professional were eventually accepted by the organization but LoadRunner was still effectively "shelf ware". Now the organization plans to implement a commercial data warehouse solution (SAP Business Warehouse) but has developed any in house performance or stress testing solution. Solution "dust off" LoadRunner and quickly implement a targeted performance testing solution to meet this immediate need.
Information Evaluation
No formal evaluation of LoadRunner. was performed since both the immediate success of the performance testing efforts and previous investment in this tool pre-empted any formal evaluation. The tool was first used to meet a specific need but the flexibility and power of the tool encouraged the testing team to capture our initial impressions of LoadRunner. and the lessons learned.
General: The framework supports the creation of a series of business processes or business threads that are captured as virtual user scripts. LoadRunner enabled the testing team to organize, author, and maintain a set of Virtual User Scripts and supporting software libraries in a shareable environment. These scripts were then be used to simulate several users (hundreds to thousands) accessing the application at once by using the LoadRunner Controller.
Development: LoadRunner provides a software development environment designed to meet the needs of experienced Test Automation Engineers. Two primary development languages are supported by LoadRunner: JavaScript and C-script. This makes the development environment accessible to anyone with development experience. Experienced Automation Engineers will have little difficulty in becoming proficient in LoadRunner - the online help and built-in tutorial certainly provides a firm foundation to grow from. It should be noted that this is a rather primitive / limited development environment but little actual development should be required when deploying a performance testing solution using LoadRunner. LoadRunner enabled the testing team to organize, author, and maintain a set of Virtual User Scripts and supporting software libraries in a shareable environment. The actual organization of the code is left up to the Engineers - the test organization must take responsibility for organizing and maintaining this code base.
Virtual User Scripts: LoadRunner provides a simple record and playback mechanism that can be used to create scripts - Virtual User Scripts. These scripts become the baseline for developing a scenario or business thread that will be used to exercise the application / architecture under test. The Virtual User development environment allows the Test Automation Engineer to customize the initial scripts by: defining transactions, defining rendezvous points, controlling playback behavior, supporting data driven scripts (parameterization), and full customization of the underlying code.
Controller: LoadRunner Controller allows the Test Automation engineer to execute several Virtual User Scripts each script being executed by 1 to n virtual users. The Controller can use 1 to n stations (PC's) to execute these scenarios. The Controller provides a full suite of basic monitoring screens that can be used to measure the performance of the application/architecture under test from several perspectives - everything from throughput, to response time, to transaction failure rate... it is important to note that these results can be saved to a report that can be viewed at anytime. The LoadRunnerx. Controller enables the Test Automation engineer to control several aspects of the Performance test: virtual user scripts, number of virtual users per script, ramp up time, ramp down time, ramp up/down of virtual users, execution time - basically a full customization of what, where, when, and how much testing will occur for that run. This is not an ad-hoc assembly of wizards - it is a well thought-out solution that is designed to support performance and load testing.
Maintenance: LoadRunner is a test automation development studio, which allows for both development and maintenance of code, data, and test scripts. Management and control of the test artifacts is left to the testing organization - therefore maintenance can become burdensome if the testing organization does not implement adequate configuration management practices. The architectural framework, on which LoadRunner is built, certainly makes it much easier to accomplish these tasks than with previous generations of testing tools.
Summary: LoadRunner met the immediate needs of the test organization. In a very short period of time (2-days) the Test Automation Engineers were able to build and execute a simple series of performance tests that enabled the Database Designer and SAP consultants to fine-tune the SAP Business Warehouse implementation. LoadRunner is an extremely robust and powerful performance-testing tool able to deal with almost any architectural framework you may want to test - we are still exploring its capabilities.
End-User "Automation Engineer"
Findings
The Test Automation Engineers found that LoadRunner supplied a complete framework to meet our immediate performance testing needs (SAP Business Warehouse). The organization now plans to use LoadRunner whenever an architectural or business change could impact the performance of an application / architecture.
Lessons Learned
From their automation work with LoadRunner the Test Automation engineers learned several valuable lessons:
LoadRunner is very dependent on the accuracy of the virtual user script - most of the issues encountered during script execution were caused by changes in the environment or user setup. The Virtual User script should be tested as a standalone script first using the Virtual User development environment then as a standalone script in the Controller environment using a limited number of virtual users (1 or 2). A fully tested virtual user script can usually be trusted to function as expected - if it does not function as expected you are probably looking at a change in the environment since the script was last executed. The most common issues to look for in a Web enabled environment are: User/Password changes, Server Changes, and changes in the application data.
LoadRunner comes with the capacity to create standalone code and store them in sharable libraries. This allowed the automation engineers to create a common toolkit that could be accessed and maintained by the team.
LoadRunner integrates with Mercury's new Quality Center and TestDirector - unfortunately it does not support performance testing from Quality Center. The integration does allow the Test Automation Engineer to use Quality Center as a common repository of scripts that can be accessed by all members of the team.
