APPLICATION-TESTING TOOL: Mercury LoadRunner 8.0

An enterprise business application could use multiple technologies, platforms, servers and components. It could be for running financial transactions, trade or auction. Such a system is expected to support thousands of users simultaneously and be available all the time. Also it should respond quickly, handle user load and transactions so that users get the desired results.

Mercury LoadRunner is designed with all this in mind; it is an automated-testing tool that helps to predict the systems' behavior and performance, before you deploy it. It stresses the system by creating virtual users, collecting the systems' performance information and then analyzing it. It's designed to monitor enterprise applications such as ERP, application servers, Web servers and database servers from various vendors.

Let's see how LoadRunner functions. For any business system, you first need to plan the load-testing requirements. For example, in case of an online air-booking system, the requirements could be defined as: successful handling of 20 users, response time not exceeding 1 min, etc. Then depending upon the kind of application being tested, you need to select the protocol script. This is done using LoadRunners's Virtual User Generator Script wizard list. So in the case of online-booking system, Web script (HTTP/HTML) should be selected. 

The Virtual User Generator Script works on the 'record and playback' principle. You need to run the script by clicking on the Start Recording button, and give the URL where the application is running. Once that is done, then in case of our example, you can start your air ticket booking process. As you do this, the script records the all the steps you take to book the tickets (you can stop the script anytime in between). 

You can control a variety of test parameters from the same window

Once your booking is done, then replay the script to ensure that it runs properly after being deployed in a load-testing scenario. For replaying, you can configure some settings in the wizard, such as number of times the script should run and how long does the user stop to think between steps. You can also view the status of the script to see whether it failed or passed and if there is some warning. You can drill down to know the reasons for the status, like where did the failures occur. 

Once the script is ready, the next step is to create the load test scenario using LoadRunner's scenario wizard. There are two scenarios: manual and goal oriented. In the manual scenario, you control the number of virtual users to run the script. In goal-oriented scenario, users are generated automatically, based on the goals you define. For example, a goal could be transaction-response time and number of hits/transactions per second. 

After the scenario is defined, load needs to be generated for the script. This is done by using the Load Generator option, in which you can select the OS and other parameters. You can also control the scenario scheduling such as, running and stopping two virtual users every 40 secs, duration for which the virtual user should run, etc. 

When you run the scenario, LoadRunner creates load on the application. It generates graphs to view the application's

performance. And these graphs are generated according to the type of applications (database application, application server) being tested. In the airline example, graphs would be for the transaction-response time, hits per second, etc. Plus graphs are generated for system resources and errors. The graphs, on clicking, give details about the system's performance and the number of errors that were encountered under the load. So, if the transaction-response time is high for airline booking that implies that the system didn't performed well. 

The last step in testing the system is to analyze its performance. This is to find failures in the system's performance and the causes behind it. LoadRunner gives a detailed analysis report. You can correlate the graphs with the report to have a better view. They help to locate the source of system failure. The reports can be published either in HTML or MS Word format. In the airline booking system, the report would include minimum, maximum and average time, standard deviation for transaction response time, etc.

The tool is designed to test the system rigorously, but the price varies according to the number of virtual users and the system being tested. 

The Bottom Line: The tool gives a comprehensive analysis of an application's performance and supports all major enterprise platforms. 

Sushil Oswal