VuGen(Virtual User Generator) Script Example in LoadRunner

What is VUGen?

VUGen (Virtual User Generator) is a key tool in LoadRunner to create testing scripts to emulate real-user behavior on your system. In VUGen, a human is replaced by a virtual user (VUser) and the actions performed by a VUser are recorded in VUser script to emulate the real-user behavior for testing and monitoring.

VUGen is one of the four core components of LoadRunner. It is the first component you interact with when getting started with Performance Testing using HP LoadRunner.

Let’s understand a few salient features related to VUGen

VUScripts: As already described, the purpose of VUGen is to create VUScripts that are used to simulate a real-like virtual-user.

Actions: An action is set of user transactions performed in the System Under Load to achieve a defined task. An action can be compared to a function in other programming languages. Each Vuser script has 3 default functions

  • Vuser_init(used to login into the application)
  • Action (used to record the business process)
  • Vuser_end (used to logout of the application)

VUGen not only records scripts but also replays them (for only 1 VUser) to ensure script is recorded correctly. Once you ensure the script is recorded correctly you incorporate it in a LoadRunner scenario

The script development process in VUGen

Script Development Process in VUGen

1. Record the Script: Usually, this is the first step of scripting where every user action is recorded into a script.

2. Replay and Verify: Once the script is recorded, reply the script to ensure its working right. Verify any impact through application frontend or database.

3. Enhance the Script: Once recording has been verified, enhance script by adding checkpoints, validating data, adding transactions and rendezvous points.

4. Replay and Verify: As earlier, re-play your script and verify that everything is working as intended.

5. Configure Runtime Settings: Configure and control pacing duration, think time variation, proxy settings and whether you wish to ignore any external resources.

6. Use for Load Scenarios: Formulate load scenarios based on test objectives. Use load distribution and geo-wide agents to make real like scenarios.

Compare recording between QTP and LoadRunner

VUGen disregards UI Objects:

Unlike QTP scripts, LoadRunner scripts are independent of GUI. This is because the code generated does not work based on UI objects, rather, it works on the principal of client’s request to the server and expecting server response back to the client. This is why replaying LoadRunner scripting is always browser independent. The VUser can communicate directly with a server by executing calls to the server API-without relying on client software (SUL) this means there will no impact on scripts if the changes are made to the UI of the System Under Load. This tells; the Performance Testing is completely based on client/server communication (request and response) and not the GUI objects.

Please refer to below link for more details:

We will see in more details how VUGen scripting works below.

Introduction to Web Tours Application

For all hands-on purpose, we will be using the Web Tours Application that comes bundled with LoadRunner.

The HP Web Tours require a dependent “Web tours Apache server” to be running before it can operate. To run the Web Tours Apache Server, go to Start Menu => HP Software => Samples => Web and then click on Start HP Web Tour Server.

Introduction to Web Tours Application

Once the “server” has been activated, it will open a shell and output on the console.

The console should look like snapshot below, look for your IP address in the shell:

Introduction to Web Tours Application

NOTE: if you close this window, the server will stop.

Now you can access the Web Tours Application –

Introduction to Web Tours Application

Once launched, it will look like –

Introduction to Web Tours Application

Understanding the VUGen Environment

To run the VUGen, double-click on the VUGen shortcut from the desktop, or go to Start Menu => HP Software => and then click on Virtual User Generator.

Understanding the VUGen Environment

VUGen splash screen will appear as follows

Understanding the VUGen Environment

The splash screen will subsequently open HP Virtual User Generator Home page, as shown below:

Understanding the VUGen Environment

From the File menu, you can observe various command controls. The purpose of these controls are mentioned below:

Understanding the VUGen Environment

New Script and Solution: is used to start creating a new script. Alternatively, you can create a new script from the toolbar button.

Open >> Script Solution: is used to open an existing, previously created script or solution from a directory.

Add >> New Script: is used to add a previously created script into the current solution

We will get acquainted with other controls as we start creating our first script. Let’s continue learning.

Click here if the video is not accessible

Creating Your First VUGen Script

Before you record, make sure the Web Tours App server is running. Remember, you need to keep the server running so do not close it. If the window bothers you, you can minimize it.

Tip: In a real-world problem, one needs to get acquainted with the subject application (SUL) especially if it involves complex business workflows and data stages. You can also interact with HP Web Tours to ensure you can repeat the exact steps when recording.

Before one can start with scripting of any application (SUL), one needs to get acquainted with the application flow. With this tutorial, let’s get acquainted with HP Web Tours which is shipped and automatically installed with HP LoadRunner.

Step 1) Click on File =>New Script and Solution as shown in the snapshot below:

Creating First VUGen Script

You can use the shortcut (Ctrl + N) to do the same.

Step 2) A window to select the protocol is shown. The list looks slightly different from previous versions

1. Select Single Protocol

2. Web

3. Enter Script Name

4. Click Create

Creating First VUGen Script

Note: You can use Protocol Advisor to determine right protocol your application uses for communication. For HP Web Tours, we already know that it requires “Web – HTTP/HTML” protocol. We will learn at a later stage how to determine the right protocol for your SUL.

Tip: An application may require more than 1 Protocols sometimes to communicate with its server. For such a case, navigate to Multiple Protocols list on the left side of window.

Creating First VUGen Script

HP Web Tours, however, requires only one protocol when scripting with VUGen.

Tip: You cannot rename your scripts easily, so be creative when giving your scripts a name. If you’ve to rename a script, use Save As feature and give a new name. A good nomenclature could be something like WT01_Signup where WT is a short form of the application name, 01 is a business process sequence, and Sign up refers to the business processes being scripted. Also, note that you cannot use spaces in a script name.

Step 3) once you click Create, HP VUGen will open the IDE (Integrated Development Environment) or code editor. You can notice the script files are blank, except basic signature of Function Action. Below snapshot should help understand it more:

Creating First VUGen Script

Step 4) Click the Recording buttonCreating First VUGen Script which you can find in the toolbar. Refer to the snapshot below:

Creating First VUGen Script

Step 5) a new window opens

Creating First VUGen Script

1. If we study the above window, the name of the script is mentioned in the title bar of this popup. This will help you make changes to the right script when you are dealing with multiple scripts opened at a time.

2. If you do not see the rest of controls, click on the Fewer Options button to ensure you are not viewing fewer options.

3. Record into the action field determines where the code is generated after recording. VUGen scripts facilitate switching to other actions or creates new actions during and after recording.

4. Record: field tells VUGen that the subject application (SUL) is a web application or a desktop client. This option cannot be overridden once recording begins.

5. Application: field tells VUGen, which browser to use for recording. If you are not working with Web – HTTP/HTML protocol, you will select the desktop client with this field.

Tip: Unlike QTP scripts, LoadRunner sample scripts are independent of GUI. This is because the code generated does not work based on UI objects, rather, it works on the principle of client’s request to the server and expecting server response back to the client – usually, in the form of HTML (hence the name of a protocol)

6. URL Address: The URL of the SUL is input here. VUGen will invoke this URL when “Start Recording” is clicked. The browser used will be the one mentioned under “Record:” field if it is different from your default browser.

7. Start Recording: Immediate vs. Delayed: If you’ve selected Immediate recording mode, you will notice that VUGen starts recording events as soon as you hit “Start Recording” button. However, if you select Delayed recording mode, the VUGen will invoke the system (SUL) but will not commence capturing events unless you click on the Recording button from the floating bar.

8. Working Directory: This is a temporary directory which VUGen will use while capturing events. A copy of your script will be available at this location as well, just in case if you lose your folder 🙂

9.Recording Options: These settings tell VUGen what type of URLs to capture and what recording mode to use.

10.Start Recording: Will start recording. Click on it

Step 6) Once recording starts, VUGen will invoke the HP Web Tours application using the browser selected.

Let’s understand with a LoadRunner scripting example to Sign up a user at Web Tours application and record a basic script.

Creating First VUGen Script

Creating First VUGen Script

A floating recording bar will appear which will offer various controls over recording. This tells the time elapsed and a number of events automatically captured. Let’s look at the floating bar closely.

Creating First VUGen Script

In the snapshot shown above, the SUL has fired 56 events and a total of 0 minutes and 25 seconds of time duration has elapsed since recording began.

You’ll also observe that no events are fired as you type. Ask yourself why. Can you answer?

This is because no client to server communication takes place as you type. Hence, no events are fired and no script is generated regarding typing. The code will be generated only once you submit the form (click Continue)

Recording can be pause Creating First VUGen Script using the pause button. Please note, as long as the recording remains paused, all events being fired by the application will be disregarded. This also means that even if your application is sending requests and/or receiving response form SUL, the script will not be generated as long as you’ve paused the recording.

If you’ve paused recording, you will need to click recording Creating First VUGen Scriptbutton from the floating bar to resume recording.

While you are recording in vuser_init section, you’d notice that rendezvous button is not enabled. Switch to Action (or create a new Action) and continue recording. Refer to below snapshot to learn how to switch Action.

Creating First VUGen Script

You’ll notice that after switching to an Action, the rendezvous Creating First VUGen Script button will be enabled automatically. This is because VUGen does not allow insertion of rendezvous points in vuser_init.

Using Transactions at Record Time

Let’s assume you wish to gauge response time when X number of users simultaneously Sign up. To address this objective, let’s read further.

By now you’ve recorded opening of the application in vuser_init action. After you’ve switched to Action, enter the user information required by SUL. Now before you hit “Continue” button, follow below steps:

Start a transaction by clicking buttonUsing Transactions at Record Time in floating bar. Enter the name of the transaction, for example, 01_Signup.

Tip: It is a good practice to name your transaction with a prefix like 01_ to help keep them unique.

The floating bar will look like this:

Using Transactions at Record Time

Click OK to close the transaction label.

Click the Continue button of the application.

End transaction by clicking buttonUsing Transactions at Record Time. Select the name of the transaction you wish to close, for example, 01_Signup in this case. Refer to below snapshot for illustration.

Using Transactions at Record Time

If you do not have multiple transactions opened, you’ll see only one name. If you’ve multiple, however, you’ll 0be able to select from the list.

Insert Comments at Record Time

Now that you’ve successfully closed the transaction, you can put a comment at record time to give yourself a reminder when you study the code later. From the floating bar, click on the button to insert a comment. A text box will appear adjacent to the floating bar where you can enter any text.

Insert Comments at Record Time

This comment will be inserted into the code after the steps (code) you’ve just finished before clicking OK button.

From the application, you can click continue. You’ll observe a welcome note by an application.

Now select vuser_end action and click Sign off from the application. Close the application and click stop button Insert Comments at Record Time from the floating bar.

Code Generation

Once recording has been stopped, you’ll notice VUGen post generation activity. This includes generating code, transactions, and comments based on your recording. Refer to snapshot below.

Code Generation

Immediately after VUGen finished “Performing post generation operations” it will start “Performing scan for correlation post generation operation” We will see in more detail what correlation means.

Code Generation

Once post generation operation is finished, you will see Design Studio window. If any candidates for correlation are found, you’ll be able to review them in this window.

Code Generation

You can safely click on the Close button, and VUGen will take you to the code that has been generated.

The window will look like this:

Code Generation

As highlighted in the above figure, the editor contains easy to understand, readable code. You can have a look on the parameters used while recording.

The left side of VUGen is called Step Navigator that lets you understand the “script” without looking at the granularities of the code. For example, you can read steps as, opening a URL, spend Think Time and submit the form. This encapsulates all the parameters associated with each request.

Your script has been generated, click on the File menu and then click on Save Script As to browser the location where you wish to save your script. VUGen will automatically suggest the last directory used if you’ve already saved a script earlier. The name suggested will be the name you mentioned when you started recording.

All done.

Now, congratulate yourself for having your first script successfully generated and saved.

Deciding a Protocol and Protocol Advisor

You might have questioned yourself why did we use Web – HTTP/HTML protocol. How did we decide which protocol should we use? The answer is not that simple.

There is an architectural foundation set of skills you need to have in place as a prerequisite to answering this question. If you are a beginner, you can pair up with someone who has solid client-side architectural and development skills for your SUL. You can speak with the developers of your SUL and find out which interfaces your application leverages. This should lead you on a natural path to the interfaces that you will be using for your virtual user script development and protocol selection.

To address the needs of beginners less knowledgeable in architectural skills, LoadRunner introduced a feature called Protocol Advisor in LoadRunner 9.1. While this has made life easier for many, one should rely more on the architectural and development skills instead of protocol advisor and receiving information from the development team about underlying development technologies. Protocol may not suggest correct protocol in all cases.

To use Protocol Advisor, go to Record => Protocol Advisor => Analyze Application

Refer to snapshot below:

Deciding a Protocol and Protocol Advisor

This will open the main window of Protocol Advisor. If you notice, this resembles a bit with the window appearing for recording. Let’s have a look at the window below:

Deciding a Protocol and Protocol Advisor

Select the Web Browser since we are using a web-based application.

Specify the URL of the application that will subsequently be invoked. Working directory can be left as such since this is merely a temporary directory for VUGen to use. Ensure you’ve read and write access on this directory.

Click the Start Analyzing button.

A floating bar, somewhat similar to the record time floating bar will appear. Have a look at the snapshot:

Deciding a Protocol and Protocol Advisor

The process will tell the time elapsed and a number of events fired. However, this information is not necessary. The only benefit of this events counter is, you know your client, SUL, is communicating with the server.

It is a good practice to analyze only one business process at a time since the various business process in a large enterprise application may involve various protocols. For example, a dashboard in some application may have Ajax or Flex, etc. but this will not be present on the login page.

Once you’ve finished executing a particular business process, you can hit the Stop button. The VUGen protocol advisor will come up with a summary report on the protocol suggestion. Have a look how it looks like:

Deciding a Protocol and Protocol Advisor

You can see the suggestions from Protocol Advisor. These may or may not be the best choices to pick.

You’ve learned to use Protocol Advisor by now. However, this could be helpful for beginners or for a situation where you need “another opinion” – rely on your architectural sense, programming knowledge, development skills and information received from the development team to decide on the protocol.

Recording Options

Whenever VUGen generates a script, the code generated is based on various configurations that can be found under the “Recording Options” – or you can press Ctrl + F7 to view the Recording Options in LoadRunner.

Let’s have a look at recording options window before we discuss all configurations:

Recording Options

There are various categories of configurations like General, Correlations, Network and Data Format Extension. Let’s understand most significant among these, one by one.

General => Recording:

This topic requires detail understanding. Hence this is discussed separately.

General => Script:

Have a look at the snapshot for a glimpse:

Recording Options

You’ll notice that Language dropdown is disabled. A common myth is that the LoadRunner does not generate code in any other language. Another myth is that it requires a license to work in other languages.

Both are false. LoadRunner decides for itself which language to use when generating the script. In almost all cases, you’ll find yourself working with C Language.

For certain Java applications (like Java applets) the code being generated will be in JavaScript Language.

VUGen will generate a script in VBScript Language only for applications developed in Visual Basic classic (MS Visual Studio 2002)

Scripting Options:

You can opt to “Generate fixed think time after end transaction”. This means, no matter how much a user wait, the think time generated (the delay) will be equal to value specified. The value is in seconds.

A maximum number of lines in the action file refers to the maximum number of lines VUGen will generate an action. If the script is larger, VUGen will automatically create a new action. The default is set to 60,000. The maximum value which can be specified is 65,000

You may find this configuration helpful when dealing with a desktop application with Oracle on the backend.

General => Protocol gives you an option to select and deselect any protocols you’ve selected at the start of recording

Essentially, this will be used only when you wish to Re-Generate Script.

Have a look at the screen:

Recording Options

This is helpful when you’ve used multi-protocols at the time of recording a script. You can regenerate the script and deselect the protocols you don’t wish and get a new script without having to re-record it.

General => Code Generation:

Have a look at the snapshot below:

Recording Options

This configuration tells VUGen to find candidates for correlation at record time. If you do not wish for Automatic Correlation, then you might wish to turn off this feature.

Correlation => Configuration:

Have a look at the screenshot below and familiarize yourself with the screen.

Recording Options

Although automatic correlation is helpful from 5% to 10% only, yet you can select “Rules Scan” and “Automatically correlate values found”. However, if your script doesn’t play, you can consider restoring to defaults by clicking on a button.

Correlation => Rules:

Go to Rules, and here you can see various rules VUGen is using to find correlation candidates. You can add custom rules if you know what your application (SUL) is using as parameters. However, this is an advanced use of record time settings. If you’re a beginner, you can safely skip this topic.

Recording Options

HTTP Properties => Advanced:

This frame offers various settings related to HTTP binding.

Reset context for each action, enabling this option instructs VUGen to reset all HTP contexts between actions to their initial state before recording, providing a clean beginning for the recording session. The option is enabled by default.

You can leave the rest of configurations intact unless required.

Recording Options

Network => Port Mapping:

This frame should be left intact. If you’re recording a desktop application, then you may have to choose WinINet level data.

Recording Options

You can go to Options (as long as you’re using Socket level data) and select various options like SSL version or other types of Secure Socket Layer. If you’re a beginner level or do not require these options, you can skip. Have a look to get yourself acquainted with the screen.

Recording Options

Now you’re done with most of the Record Time options, let’s move to the next topic and understand the difference between HTML and URL based scripting.

Difference between HTML-based and URL-based Scripting

You may have noticed an option to pick either HTML-based script or URL-based script. Have a look at the snapshot for a flashback.

Difference between HTML-based and URL-based Scripting

So what is this option and which one to pick?

The HTML-based script is based on user actions, and the scripts contain functions that correspond directly to the action taken. Let’s understand example of a small piece of code:


web_link(“Enterprise Systems Performance",
"Text=Enterprise Systems Performance,"

The URL-based script is based on HTTP requests sent to the server as a result of user actions.

Here is an example of code for URL mode for the same actions performed as above (in HTML mode)


web_url(“Enterprise Systems Performance",
"Referer=/atc?. . . ,

Tip: It’s best to experiment yourself before you move forward. Change the record time settings and record the same script twice i.e. once with HTML mode and once with URL mode – then compare both. Keep the script short so you can understand the difference.

How do we decide on which mode to use?

Let’s understand the pros and cons of both modes so understand which mode is more suitable under certain situations:

Benefits of HTML Recording

  • Reduces need to capture dynamic values
    • Action tag values and hidden data are NOT hardcoded
    • They are retrieved from memory during playback
    • If they are dynamic, the VUser still run
  • Script is only as big as the business process–one step per page

Disadvantages of HTML Recording

  • Scripts are less scalable
  • Memory (cache) is searched during playback
    • requires more memory
    • requires more CPU power

Benefits of URL Recording

  • Flexibility
    • Support for Java Applets and ActiveX objects on the page
    • Ability to replay on UNIX
  • Scalability
    • Scripts are more scalable than HTML scripts because they require fewer resources

Disadvantages of URL recording

  • Scripts require more correlation (nothing is retrieved from the cache)
  • Context-sensitive checks won’t work (parser is disabled)*
  • Scripts are large (all images and frames are recorded as separate steps)

Here is a quick illustration:

HTML Mode URL Mode
Intuitive and easy to understand. Not as intuitive as the HTML scripts.
Scripts are smaller, requests are encapsulated and easy to understand. Scripts are large, containing a call to each image, css, html, etc. thus making it difficult to understand.
Scalable. More scalable and effective for creating a load test.

Use of Re-Generate Script

Let’s suppose you want to record the same script you just recorded, but with different record time settings. In such a case, you can use the regenerate script feature.

You can access it under Record => Regenerate Script or with hotkey Ctrl+Shift+R

Use of Re-Generate Script

Once you click on the menu, VUGen will give you a warning that your existing script and all changed you’ve made to your existing script will be lost. The warning message looks like this:

Use of Re-Generate Script

You can also click on Options to open Record Time Options from here.

Click OK to proceed with Re-Generation of a script.

Playback a Script and understanding Log

Once you’ve saved the script, you can click on the Playback a Script and understanding Log in the toolbar to replay or hit F5.

You can find this button in the toolbar:

Playback a Script and understanding Log

You need to ensure the server is running (which is required for application to work properly)

When you replay the script, you’ll notice that unlike QuickTest Professional, it doesn’t open any browser to replay. Remember, this execution will simulate only 1 (single) user load on the SUL. The purpose of this execution is to ensure your script is working.

Playback a Script and understanding Log

Tip: You’ll need to verify the impact from the application itself. For example, if you’re creating a record, go to the application and verify manually that your script actually created a record. Your scripts, most likely, will not be tested by yet another Testing or QA team so you need to be very careful with your script and ensure these are thoroughly tested.

You can leave the replay log active since this will be a great help in identifying candidates for correlation and any errors and warning you might come across. Since generating log takes ample resources, it is best-turned off when you’re done with debugging of scripts and using them for scenarios.

Overview of Files Generated During Record & Playback

Let’s close the VUGen and have a look at the files it has created in the script folder.

VUGen creates a series of configuration files, data files and source code files which contain VUser run-time and setup information. The results of each iteration of the script are stored separately. If you’ve executed your script at least once, you will notice a directory by the name result1. This directory is for system use and should be ignored by the tester.

Important files which you need to understand:

VUGen will create one .c (C Language Code file) for each action. Thus, at the last, you’ll have vuser_init.c and vuser_end.c and Action.c – if you’ve more actions created, you will see corresponding files too. For example, myAction.c

The replay log is saved in a file called output.txt. If you’ve replaced it multiple times, output.txt will contain the last execution log whereas, output.bak will contain previous to the last run.

<script_name>.usr file will contain all the run time configurations you’ve customized. Even if you’ve left all the configurations to default, this usr file will contain the information. This file also contains the version of LoadRunner used for creating a script. This information is helpful if you’re reading old scripts for which you can’t recall the version number.

You will see a folder named “data”. This folder keeps an image of the events as well as a copy of your code. VUGen makes use of these files when you “ReGenerate” your code.