VuGen Script Recording, Replay And Dynamic Values With

Correlation
Last Updated:May 30, 2021
LoadRunner VuGen Script Recording, Replay and Handling Dynamic Values with Correlation
Technique:
In this Intensive LoadRunner Training Series, we learned more about LoadRunner Recording
Options in detail.
In this tutorial, we will discuss the following:
1. Script replay
2. Handling of dynamic values using ‘Correlation’ (and Recording Options part 2)
In the previous tutorial, we saw how to create the script. So now, let’s replay the script that we
created in the last tutorial.
=> Click Here For Complete Series of LoadRunner Tutorials

4.5M
How to Install Jmeter and Perform Testing Through Jmeter

Next
Stay
What You Will Learn: [hide]
 VuGen Script Replay
 Correlation
 o
 #1) Manual Correlation:
 #2) Automatic Correlation:
 VIDEO Tutorial: VUGen Script Recording
o Conclusion
o Recommended Reading

VuGen Script Replay

Click the replay button (highlighted in red) or use the shortcut ‘F5’ to replay the script.

During the replay, VuGen runs each and every step in a sequence, the current step being run is
highlighted with a yellow arrow on the left (as shown in the below figure).
Also, the following two tools are important (to observe) during (and after) the replay:
(i) Run-time viewer – This gives an approximate response page as seen on the browser for every
request. Remember that this is not an actual browser, hence it may not display the correct response
page every time. But this tool gives an idea of how the response looks like.
(ii) Replay log – The log of script replay.
In general, logs are very useful for debugging VuGen scripts. To view logs, we can open the Output
window (View->Output) and select the type of log (Replay log in this case).
Also, the level of logging can be set in the Run-Time Settings (we will discuss Run Time settings in
detail in our subsequent tutorials). While debugging the scripts, it is recommended to enable
‘Extended Logging’ always (to be able to see the complete log – request/response, parameters
etc.).
Once the script replay is completed, VuGen will show the replay status as ‘Passed’ or ‘Failed’ (as
shown below).

The VuGen ‘Passed’ status may not necessarily mean that all the requests have passed (or
performed what it is intended to do exactly) during the replay. It only means that VuGen has not
encountered any error while replaying the script. VuGen by itself cannot verify if the response to
each and every request is correct or not (we will see how to handle this in our subsequent tutorial
on how to handle this).

If we see carefully, the runtime viewer showed the following message (highlighted in red) when the
second request (login request) was replayed.
The same can be seen in the Replay log.

Which means the response of the second request is not correct (expectation was to get the home
page for the user but instead we got this error page).

Why did this happen?

This could have happened because of a ‘bad’ value (data) in the request (login request in this
example). We will come back to the causes of this error in this specific login request a little later in
the tutorial, but first, let’s understand the types of values (data) that we see in general in a VuGen
script.

A VuGen script can have two types of data/values that we may need to handle –
 1. Static values: The values that a user enters. E.g. Username, password, credit card details
etc.
2. Dynamic values: The values that are generated and sent by the server. Examples are
session ids/tokens, session states, date values etc.
We will talk about the second type (dynamic values) in this tutorial.

Say, a client sends a request (first request) to the server and receives the response which has a
unique dynamic value (generated and sent by the server). E.g. Session Token ‘Zmnnijo’ in the
diagram shown. And this value, being dynamic, changes every time when the first request is sent.

In the next request (second request), the client may be required to send this dynamic value to the
server.

In the VuGen script, we may see such dynamic values in the request. The script when replayed with
the same value may fail because the server may not be able to recognize it. So, we have to capture
such types of values (from the response it is present in) into a parameter and substitute this
parameter into the request(s) where it is present/required.

This is called ‘Correlation’ and is one of the most important tasks to do while working with the
VuGen scripts. So, how do we do ‘Correlation’? We do it using one of the correlation functions as
shown below. These functions capture the dynamic value from the response of a particular request
and save it into a parameter.

1. web_reg_save_param
2. web_reg_save_param_ex
3. web_reg_save_param_regexp
4. web_reg_save_param_xpath
Now coming back to our Web Tours VuGen script and the error we were getting during the replay
for the second request (login request), if we see carefully, we have a userSession value in the
request.

web_submit_data("login.pl",

"Action=http://127.0.0.1:1080/cgi-bin/login.pl",
"Method=POST",
"TargetFrame=body",
"RecContentType=text/html",
"Referer=http://127.0.0.1:1080/cgi-bin/nav.pl?in=home",
"Snapshot=t2.inf",
"Mode=HTML",
ITEMDATA,
"Name=userSession", "Value=123211.212069664zDDHzHzpHcAiDDDDDiAczpAzADcf", ENDITEM,
"Name=username", "Value=jojo", ENDITEM,
"Name=password", "Value=bean", ENDITEM,
"Name=JSFormSubmit", "Value=off", ENDITEM,
"Name=login.x", "Value=66", ENDITEM,
"Name=login.y", "Value=12", ENDITEM, LAST);
This value was not entered by us (the user) during recording. Such values are the unique dynamic
values that we were talking about.

So in this case, while recording, this value was generated and returned by the server (in one of the
responses) and is in turn sent by the client (browser) in this particular request (login request).

Now, because we left this value as hard-coded, during replay, when this request was sent to the
server, the server was not able to identify this value and hence, it returned an incorrect response.

So we have to correlate this value to fix the error.

Correlation
Correlations can be done in two ways:
 Manual Correlation
 Automatic Correlations
 Record
 Replay
 Rules
#1) Manual Correlation:
In manual correlation, we manually insert the correlation function in the script to capture the
dynamic value. Let us do this for the ‘userSession’ dynamic value for our login request. We will use
the first correlation function, ‘web_reg_save_param’ to do this.

On a high-level, these are the steps to be followed for doing the manual correlation:
a) Identify the dynamic value(s) in the script: This can be done by recording the user actions on
the application (creating VuGen script) twice with the same input data (static values like user id,
account number etc.). Now compare the two scripts using text comparison tools like WDiff,
BeyondCompare etc. We can use the in-build comparison option in VuGen which in turn will open
the WDiff tool.

b) Identify the left and right boundaries of the dynamic value: Search for this value in the ‘Code
Generation’ log (Generation Log) and find the Left Boundary and the Right boundary of the dynamic
value.
c) Identify the request whose response contains this dynamic value: In the ‘Code Generation’
log, after we search for the dynamic value in a particular response, go up (in the log) till we see the
corresponding request (that is just above this response).
d) Insert the correlation function: Insert the correlation function in the script just above the
request we identified in the previous step.
So for our Web Tours script, search for the userSession value in the Generation Log (Code
Generation 123211.212069664zDDHzHzpHcAiDDDDDiAczpAzADcf
And identify the left and right boundaries.

So the left boundary can be this – name=”userSession” value=”

And right boundary can be this – “/>

Our correlation function can be like this.

web_reg_save_param (“corUserSession”,”LB=”,”RB=”, LAST);

The ‘web_reg_save_param’ function has each attribute in double quotes and the attributes are
separated by a comma. We have used three attributes here – the first one ‘corUserSession’ is the
name of the parameter into which we want to capture our dynamic value (we can give any name
here), the second one ‘LB’ is the left boundary and the third one ‘RB’ is the right boundary.

‘LAST’ signals the end of attributes (we have more attributes, which will be discussed a little later in
this tutorial).

Finally, our correlation function will look like this (note that we have to put an escape character ‘\’
before any double quotes in the left and right boundaries).

web_reg_save_param (“corUserSession”,”LB= name=\”userSession\” value=\””,”RB=\”/>”, LAST);

Let’s insert this function in our script now.

As the value to be correlated is in the second request (login request), and there is only one request
above this, obviously, this value would have come in the response of the first request. So we will put
the function just above the first request and replace the dynamic value in the second request with
the parameter name (note that parameters are always put in curly braces).
And when we replay the script now, we get the correct page/response for the login request.

The replay log clearly shows the capturing and saving of the dynamic value into the parameter
And substituting the same in the second request.

So we have successfully done with manual correlation.

Let’s see all the attributes of ‘web_reg_save_param’ function in detail:

#1) LB: The left boundary of the dynamic value that we are trying to capture. If LB is not specified,
VuGen uses all of the characters from the beginning of the response as the boundary.
#2) RB: The right boundary of the dynamic value that we are trying to capture. If RB is not
specified, VuGen uses all of the characters till the end of the response as the boundary.
#3) ORD: This is an optional attribute that is used to capture a particular instance of a match. If we
set “ORD=2”, the second instance of the match will be captured and so on (default is “ORD=1”). If
we specify “ORD=ALL”, then all the match occurrences will be saved as an array.
#4) SaveLen: This is an optional attribute that is used to specify the length of a sub–string of the
found value to save to the parameter. The default is –1 (meaning – save to the end of the string).
#5) SaveOffset: This is an optional attribute that is used to specify the offset of a sub–string of the
found value, to save to the parameter. The default is 0 (meaning – save the entire string found
without trimming any character).
#6) Search: This is an optional attribute that is used to specify the scope of the search.
It can take the following values:
 Search=Headers (Search only the headers)
 Search=Body (search only the body)
 Search=Noresource (search only the HTML body, excluding all headers and resources)
 Search=ALL (this is the default)
#7) Convert: This is an optional attribute which can take one of the following values:
HTML_TO_URL: To convert HTML–encoded data to a URL–encoded data format.
HTML_TO_TEXT: To convert HTML–encoded data to plain text format.
#8) IgnoreRedirections: This is an optional attribute and can take one of the two values – “Yes” or
“No”.
If “IgnoreRedirections=Yes” is specified and the server response is redirection information, then
this response is not searched for the dynamic value but a GET request is sent to the redirected
location and the search is performed (for the dynamic value) on this response.
The default one is “IgnoreRedirections=No“.
#9) NOTFOUND: This is an optional option for handing when a boundary is not found.
It can take two values:
Notfound=error (the default value, causes an error to be raised when a boundary is not found)
Notfound=warning (does not issue an error if the boundary is not found)
#10) RelFrameID: This is an optional attribute that is specified to mention the hierarchy level of the
HTML page relative to the requested URL. The possible values are ALL or a number.
#2) Automatic Correlation:
VuGen can also handle the dynamic values automatically after scanning the code (request,
response etc.) internally. This is called ‘Automatic Correlation’.

Automatic correlation can be of three types.

1. Record – VuGen scans the code during recording and provides correlation suggestions.
2. Replay – VuGen scans the code during replay and provides correlation suggestions.
3. Rules – VuGen scans the code as per the rules we define in ‘Recording Options’.
Let us discuss the recording options related to automatic correlations (Recording Options part 2)
which we did not discuss yet.

General-Code Generation: Here we can enable/disable the automatic Correlation scan. If we

disable this, VuGen will not scan for automatic correlations.

Correlations-Configuration: Here we can specify the configuration for automatic correlation – like
enabling/disabling scan types (Record, Replay, Rules), function to be used for correlation etc.
Correlations-Rules: Here we define rules for ‘Rules Correlation’. Rules for some types of
applications will already be here by default. We can add our application (using ‘New Application’
button) and rules (using ‘NewRule’ button) if we wish to. We can also export/import rules.
So if we enable the Correlation scan option, when we record the script after the script is generated,
VuGen performs some postscript generation activities and scanning for correlations is one among
these.
After the scan is complete, VuGen opens ‘Design Studio’ window with the list of recommended
values for correlation (Type can be Record, Replay or Rule). We can select any of these values and
click on the ‘Correlate’ button to complete the automatic correlation.
Also, we can open the Design Studio window and scan for correlations at any time in the VuGen
script (Design->Design Studio)

Update:
We have a hands-on video tutorial recorded on earlier LoadRunner version. The steps are still
applicable in Micro Focus LoadRunner.

VIDEO Tutorial: VUGen Script Recording

Tutorial Summary:
This tutorial provides details of Vugen script recording.
  Protocol is the pre-requisite of script creation.
 Protocol Advisor is used to find the protocol that the application is using.
 Protocol Advisor is beneficial to performance testers by making the process of script
creation faster and more focused. The tutorial covers how to use Protocol Advisor to find the
protocol and jump to the scripting from there.
 We also discussed transaction and its significance, functions used to create a transaction
and how to capture response time of a request through them.
 Transactions are created to capture request of each action going to the server during script
recording.
 A verification point in the form of text check is inserted before closing the transaction to
confirm that the server is responding with the correct response. In case response is not as
expected, the text check will fail, and that will fail the transaction also.
 The sample application that comes along with Vugen is used for demoing – Protocol Advisor
and script recording through Vugen.
 For scripting modular approach is taken as it gives more control over the script.
 During recording elements of the floating recording toolbar is discussed and used while
recording.
After going through this tutorial, viewers will be able to have an exact idea what is required to start
recording a script and how that can be achieved.

This brings us to the conclusion of this tutorial.

Conclusion
Just to summarize, in this tutorial, we discussed ‘Script replay’ and ‘Correlation’.

We will discuss more on Parameterization in our upcoming tutorial!!

=> Visit Here For Complete Series of LoadRunner Tutorials
PREV Tutorial | NEXT Tutorial
Recommended Reading
 Introduction to VuGen (Virtual User Generator) Script with Recording Example
 VUGen Recording Options in LoadRunner
 How to Setup LoadRunner VuGen Script Files and Runtime Settings
 JMeter HTTPS Test Script Recorder
 Web Services Performance Testing Using LoadRunner VuGen Scripting
 Unix Shell Script Arithmetic and Boolean Operators Examples
 Unix Shell Script Functions with Parameters and Return
 Command Line Arguments in Unix Shell Script with Example