Performance Testing With Load Runner -4- : Working with LoadRunner (creating&recording scripts)

Working with LoadRunner

When testing or monitoring an environment, you need to emulate the true behavior of users on your system. HP testing tools emulate an environment in which users concurrently work on, or access your system. To do this emulation, the human was replaced with a virtual user, or a Vuser. The actions that a Vuser performs are described in a Vuser script. The primary tool for creating Vuser scripts is the Virtual User Generator, VuGen.

Vusers emulate the actions of human users by performing typical business processes in your application. The actions that a Vuser performs during the recording session are described in a Vuser script.

Using VuGen, you can run scripts as standalone tests. Running scripts from VuGen is useful for debugging as it enables you to see how a Vuser will behave and which enhancements need to be made.

Steps for Creating Scripts:

VuGen enables you to record a variety of Vuser types, each suited to a particular load testing environment or topology. When you open a new test, VuGen displays a complete list of the supported protocols.

This window opens up as soon as you open the VuGen. You can select the protocol of you application and click ok. For most of the web application its Web (HTTP/HTML) Protocol

Open VuGen

To start VuGen, choose Start > Programs > <App_Name> (for example LoadRunner) > Applications > Virtual User Generator from the Start menu.

To open an existing script, not in the recent list, click Open Existing Script. To create a new script using a recent protocol, click the protocol in the Recently used protocols list.

To create a new script in a protocol that is not listed, click New Vuser Script.

Choose File > Zip Operations > Import From Zip File … to open an existing Script from a zip archive.


Now click on the New Protocol Script and you will see the following Window. From this window you have to choose the protocol on which the application you are going to load test works.

VuGen provides a variety of Vuser technologies that allow you to emulate your system. Each technology is suited to a particular architecture and results in a specific type of Vuser script. For example, you use Web Vuser Scripts to emulate users operating Web browsers. You use FTP Vusers to emulate an FTP session. The various Vuser technologies can be used alone or together, to create effective load tests or Business Process Monitor profiles.


Now set the General options for VuGen.

For Example To set the environment-related options:
Select Tools > General Options and click the Environment tab.

To save the current script information for auto recovery, select the Save AutoRecover Information option and specify the time in minutes between the saves.

To set the editor font, click Select Font. The Font dialog box opens. Select the desired font, style, and size and click OK. Note that only fixed size fonts (Courier, Lucida Console, FixedSys, and so on) are available.

To use a comparison tool other than WDiff, select Use custom comparison tool and then specify or browse for the desired tool.

Click OK to accept the settings and close the General Options dialog box.

Now Set the Recording Options for recording the user actions of the application under load test.



Now that you are ready for recording Click on the record button


Give the Url of the application that needs to be load tested like the one below


The following table describes the criteria for determining the business functions or processes to be included while recording 


Now record the transaction in either Vuser_init or Vuser_end or action by using the recording tool bar.


Once the recording is over a recording log is also generated

To view a log of the messages that were issued during recording, click the Recording Log tab. You can set the level of detail for this log in the advanced tab of the Recording options.

Now the script will be generated for the recorded user actions and will be displayed like this 



Performance Testing With Load Runner -3- : Load Runner and its components

Load Runner:

HP LoadRunner, a tool for performance testing, stresses your entire application to isolate and identify potential client, network, and server bottlenecks.

HP LoadRunner load tests your application by emulating an environment in which multiple users work concurrently. While the application is under load, LoadRunner accurately measures, monitors, and analyzes a system’s performance and functionality.

How LoadRunner Addresses the Performance Testing:

  • LoadRunner reduces personnel requirements by replacing human users with virtual users or Vusers. These Vusers emulate the behavior of real users— operating real applications.
  • Because numerous Vusers can run on a single computer, LoadRunner reduces the amount of hardware required for testing.
  • The HP LoadRunner Controller allows you to easily and effectively control all the
  • Vusers—from a single point of control.
  • LoadRunner monitors the application performance online, enabling you to fine- tune

    your system during test execution.

  • LoadRunner automatically records the performance of the application during a test. You

    can choose from a wide variety of graphs and reports to view the performance data.

  • LoadRunner checks where performance delays occur: network or client delays, CPU

    performance, I/O delays, database locking, or other issues at the database server. LoadRunner monitors the network and server resources to help you improve performance.

  • Because LoadRunner tests are fully automated, you can easily repeat them as often as you need.

Various Components of LoadRunner:

Vuser Generator is the Script generation component of LoadRunner. This component has two main things and are described below:

Vusers: In the scenario, LoadRunner replaces human users with virtual users or Vusers. When you run a scenario, Vusers emulate the actions of human users working with your application. While a workstation accommodates only a single human user, many Vusers can run concurrently on a single workstation. In fact, a scenario can contain tens, hundreds, or even thousands of Vusers.

Vuser Scripts: The actions that a Vuser performs during the scenario are described in Vuser script. When you run a scenario, each Vuser executes a Vuser script. The Vuser scripts include functions that measure and record the performance of your application’s components.

Controller: You use the HP LoadRunner Controller to manage and maintain your scenarios. Using the Controller, you control all the Vusers in a scenario from a single workstation.

Load Generator: When you execute a scenario, the Controller distributes each Vuser in the scenario to a load generator. The load generator is the machine that executes the Vuser script, enabling the Vuser to emulate the actions of a human user.

Performance analysis: Vuser scripts include functions that measure and record system performance during load-testing sessions. During a scenario run, you can monitor the network and server resources. Following a scenario run, you can view performance analysis data in reports and graphs.

Performance Testing With Load Runner -1- : What is Load test ? What is the purpose of load test? What functions or business processes should be load tested?

  • Load Test:

Load Tests are end to end performance tests under anticipated production load. The objective of such tests are to determine the response times for various time critical transactions and business processes and ensure that they are within documented expectations (or Service Level Agreements – SLAs). Load tests also measures the capability of an application to function correctly under load, by measuring transaction pass/fail/error rates.

Load Tests are major tests, requiring substantial input from the business, so that anticipated activity can be accurately simulated in a test environment. If the project has a pilot in production then logs from the pilot can be used to generate ‘usage profiles’ that can be used as part of the testing process, and can even be used to ‘drive’ large portions of the Load Test.

Load testing must be executed on “today’s” production size database, and optionally with a “projected” database. If some database tables will be much larger in some months time, then Load testing should also be conducted against a projected database. It is important that such tests are repeatable, and give the same results for identical runs. They may need to be executed several times in the first year of wide scale deployment, to ensure that new releases and changes in database size do not push response times beyond prescribed SLAs.

  • What is the purpose of a Load Test?

The purpose of any load test should be clearly understood and documented. A load test usually fits into one of the following categories:

Quantification of risk: Determine, through formal testing, the likelihood that system performance will meet the formal stated performance expectations of stakeholders, such as response time requirements under given levels of load. This is a traditional Quality Assurance (QA) type test. Note that load testing does not mitigate risk directly, but through identification and quantification of risk, presents tuning opportunities and an impetus for remediation that will mitigate risk.

Determination of minimum configuration: Determine, through formal testing, the minimu m configuration that will allow the system to meet the formal stated performance expectations of stakeholders – so that extraneous hardware, software and the associated cost of ownership can be minimized. This is a Business Technology Optimization (BTO) type test.

Assessing release readiness by: Enabling you to predict or estimate the performance characteristics of an application in production and evaluate whether or not to address performance concerns based on those predictions. These predictions are also valuable to the stakeholders who make decisions about whether an application is ready for release or capable of handling future growth, or whether it requires a performance improvement/hardware upgrade prior to release.

  • What functions or business processes should be load tested? 


How to debug LoadRunner script

From time to time there are situations where you work on a script, and it looks fine, compiles with no issues but simply doesn’t work as you expect. In such case there is no other option than just knuckle down and get a little bit dirty. That’s the right time for debugging.

And here some tips from me that (hopefully) will help you making this step less painful.

1) Increase log level
By default, VuGen report only standard information. If you want to see more verbose details, then go to Vuser -> Run-Time settings -> Log and enable “Extended log” option.


2) Use HTTP Proxy
Another option is to find by checking what exactly LoadRunner sends to the server. Personally I use WebScarab and Fidler (from time to time) to sniff network traffic and to check what data my script generate. You can setup proxy in VuGen by going to Vuser -> Run-Time settings -> Proxy.

Below is a setup for WebScarab running locally:


and sample traffic as seen in WebScarab:


3) Use text tools to compare HTTP requests from LR and from real browser
Lets say you sniffed LR HTTP call and browser HTTP call e.g. with local proxy and you want to compare both to search for any differences. Sometimes your HTTP call fails only because of e.g. missing dot somewhere. And such bugs are even harder to find because there is no obvious “Hello, I’m here” error type of message. Try to use Notepad+ or ConTEXT (

Sample results of HTTP requests comparison in ConTEXT editor:


4) Use breakpoint
Breakpoint is a place in script where LR will pause running so you can see all runtime values. Howto setup a breakpoint? Simply right click line where you would like to pause and select “Toggle Breakpoint”. This will put red dot at the beginning of line. It looks like that:


Now, simply start the script, and wait until script reaches this breakpoint. When it’s done, in output window you can switch to “RunTime Data” and see detailed information like which iteration is running currently, which action, line number and (most interesting) all parameter with their current values:


To resume running, simply hit run button once again. To disable a break point, also right click the line and select the same “Toggle Breakpoint”.

5) Run script step by step
Running step by step means that instead of going from one call to another automatically, you need to hit F10 in order to perform next call. This is actually helpful when running with Browser preview or when you have lots of if/while/do…while/for loops and you want to see exactly what LR is doing and where.
To run scrip in step by step mode you just simply hit F10 or select Vuser -> Run Step by Step.

6) Force script to run with specific parameters values
This is actually a trick, definitely not something described in VuGen manual. Lets say your script use parameters very heavily and depends on them as well. Now, you have e.g. parameter USERNAME with lots of accounts to use but you want to use one very specific account. One method is to update/change the parameter so it will pick up correct account. But in such case you need to remember to undo your changes after you are done with the test. Another method is to leave parameter unchanged, and just override it’s value during runtime. For that you can use lr_save_string() function and place it somewhere at the beginning.

One could say that it’s even more dangerous than first method since it always overrides param value so when left unchanged could fail every future load test. But even for than there is a solution. Trick that I use looks like this:

  1. int id;
  2. lr_whoami(&id, NULL, NULL);
  3. if(id < 0)
  4. {
  5.         lr_save_string(“Pete”, “USERNAME”);
  6. }

And basically you can leave it in your script because LR will reach this lr_save_string call only in VuGen. When running in LR Controller, lr_save_string() won’t be reached (lr_whoami called in VuGen always return -1).