LoadRunner Part # 9 - Understanding VUGen in LoadRunner #2

Deciding a Protocol and Protocol Advisor

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.

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.

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.

Difference between HTML-based 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

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

Playback a Script and understanding Log

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.

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