The 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
Introduction to Web Tours Application
Understanding the VUGen Environment
Creating Your First VUGen Script
Using Transactions at Record Time
Insert Comments at Record Time:
Code Generation:
Deciding a Protocol and Protocol Advisor
Recording Options
Difference between HTML-based and URL-based Scripting

• Reduces need to capture dynamic values             

• Script is only as big as the business process–one step per page

•  Scripts are less scalable

•  Memory (cache) is searched during playback

• Flexibility

• Scalability

•  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)

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
Playback a Script and understanding Log
Overview of Files Generated During Record & Playback

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 scripts are 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: http://youtu.be/FDORUeqpNJs?t=3m41s

We will see in more details how VUGen works below.

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

The HP Web Tours requires 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.

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:

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

Now you can access the Web Tours Application –

Once launched, it will look like –

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.

VUGen splash screen will appearas follows

The splash screen will subsequently open HP VUGen Home page, as shown below:

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

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 current solution

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

Please be patient. The Video will load in some time. If you still face issue viewing video click here

Before you record, make sure the Web Tours App serveris 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:

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

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.

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 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:

Step 4) Click the Recording  button which you can find in the toolbar. Refer to the snapshot below:

Step 5) a new window opens

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 facilitates switching to other actions or create 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 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 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 Sign up a user at Web Tours application and record a basic script.

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

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

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. Code will be generated only once you submit the form (click Continue)

Recording can be pause  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 button 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.

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

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  button 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:

Click OK to close the transaction label.

Click the Continue button of the application.

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

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.  

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.

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 application.

Now select vuser_end action and click Sign off from the application. Close the application and click stop button from the floating bar.

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.

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.  

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.  

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:

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.

You might have questioned yourself why did we use Web – HTTP/HTML protocol. How we decided 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:

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:

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:

The process will tell the time elapsed and 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 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:

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 help for beginners or for situation where you need “another opinion” – rely on your architectural sense, programming knowledge, development skills and information received from development team to decide on the protocol.

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.

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

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:

 

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 Java Script 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.

Maximum number of lines in the action file refers to the maximum number of lines VUGen will generate in 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 recordingp

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

Have a look at the screen:

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:

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.

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  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. 

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.

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.

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.

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.

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

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:

Example:

...

web_link(“Enterprise Systems Performance",

"Text=Enterprise Systems Performance,"

"Snapshot=t4.inf",

LAST);

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)

Example:

...

web_url(“Enterprise Systems Performance",

"URL=http://www.guru99.com/esp.html",

"TargetFrame=",

"Resource=0",

"RecContentType=text/html",

"Referer=http://www.guru99.com/atc?. . . ,

"Snapshot=t4.inf",

"Mode=URL",

LAST);

Tip: It’s best to experiment yourself before you move forward. Change the record time settings and record 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

                     - Action tag values and hidden data are NOT hardcoded

                     - They are retrieved from memory during playback

                     - If they are dynamic, the VUser still run

Disadvantages of HTML Recording

                      - requires more memory

                      - requires more CPU power

Benefits of URL Recording

                      - Support for Java Applets and ActiveX objects on the page

                      - Ability to replay on UNIX

                      - Scripts are more scalable than HTML scripts because they require fewer resources

Disadvantages of URL recording

Here is a quick illustration:

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 hot key Ctrl+Shift+R

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:

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

Click OK to proceed with Re-Generation of script.

Once you’ve saved the script, you can click on the  in the toolbar to replay or hit F5.

You can find this button in the toolbar:

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.

Tip: You’ll need to verify the impact from 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.

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 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 copy of your code. VUGen makes use of these files when you “ReGenerate” your code.