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:
- Script replay
- 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
Table of Contents:
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 –
- Static values: The values that a user enters. E.g. Username, password, credit card details etc.
- 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.
- web_reg_save_param
- web_reg_save_param_ex
- web_reg_save_param_regexp
- 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.
- Record – VuGen scans the code during recording and provides correlation suggestions.
- Replay – VuGen scans the code during replay and provides correlation suggestions.
- 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