More about Date & Time parameter in Loadrunner

We all know that parameterization is used to pass unique user inputs to the application and we have different type of parameters to achieve this uniqueness. One such parameter is Date & Time parameter. Here Date & Time values are appended to the text to generate unique user parameters.

Image A

We are all familiar with this. But most of us are not familiar with the Offset option at the bottom of the parameterization dialog box in Image A , which is what will be explained in this post.

Offset - This defines the number of days the date value should be adjusted in the past or in the future.
Simply, Offset takes you to the past & future dates & time.

Offset Parameter by  -  this is where you define the number of days & time value for which the adjustment should happen. but we have not defined if this should be in the past or in the future.This can be done in the next option.

In the Image A we are offsetting the date & time parameter by 1 day.

Prior to current date - When you check this box, dates are adjust to the past. If this box is unchecked dates are adjust to the future.

In the Image A, Prior to current date option is checked which means we are offsetting the date & time parameter by 1 day in the past. So the Parameter value will be 2018-06-26.

Working days only -  When you check this box only weekdays are considered (i.e) Saturday & Sunday will not be included in the parameter calculation.  If this box is unchecked all the 7 days of the week will be included in the parameter calculation.

Where Offset option will be useful?

1. If you are doing a search in the application to retrieve records from the past days.
2. If your application is using the future dates to mark the due dates.

Simply we can use this, wherever the application uses past & future dates.

Note : All these can also be done using the lr_save_datetime loadrunner function.

How to convert a Fiddler Session into Vugen script

What is Fiddler?

Fiddler is web debugging tool which capture all the traffic between the browser (client) & the server.

Why should we covert a fiddler session into a Vugen script?

When we are trying to record a application which retrieves responses of huge bytes Vugen might crash. So as a workaround we can convert a fiddler session into a Vugen script.

How to do that?

It very simple.

1. Fiddler is an open source tool. First download & install it in your system.
2. Next start the fiddler and launch the browser. Make sure that all other browsers and browser sessions are closed. If not, then the traffic across the all the browsers would be captured in fiddler.
3. In Fiddler, in the right pane we can find the Filters tab under which check the show only traffic from and select the browser session that you have launched.

4. Now perform the flow which you wanted to record in Vugen, the same will be captured as Fiddler session.
5. Then save the session as a .SAZ ( Session Archive Zip) file. File --> Save --> All Sessions 

6. Now import the .SAZ file in Vugen, You could see that Fiddler Session into Vugen script.

Drawback:
The only drawback is that we have to add the transactions only after the vugen script is generated.

Debug a Vugen script using developer tools.

Whenever the application under test is upgraded with latest code which may have UI changes (like few elements in the page might be removed or added or modified) or in other words
the requests would have been modified or added or removed, there are high chances that our vugen script might not work.

To debug scripts of these kind we can use developer tools instead of re-recording the whole script as this approach saves a lot of time.

• After launching the browser press F12 to open the developer tools.

• All the requests sent from the client (browser) to server will be captured under the Network Tab in developer tools.

• Launch the application and capture the request which fails in the script in the developer tool.

• When you click on the request you can see Headers Tab which holds all the information about the request like Request URL, Request Method, Request Headers & Form Data.

• From data is the section where the request parameters are passed on. Compare this Form data with the Item Data in the script request and look out for changes. If there are differences then update the script with the new form data and run the script, this will more likely resolve the issue.

• The Image A below shows the login request in the vugen script and the same same request captured in developer tool in Image B (Highlighted in RED box).

Image A

Image B

• You can clearly see that the parameters under Item data in the script are captured under Form Data in the developer tool.

• On clicking on the view source (Highlighted in BLUE circle in Image B) we can view the parameters in a way it will be formatted in the request (as shown in Image C), which will be more easy to compare and analyze.

Image C

• Also we can you the Inspect element option (Highlighted in GREEN circle on the Left top corner in Image B) to debug the scripts. Turn on this option and select any element in the web-page to get the Element ID & Element Value. This way also we can compare & update the Element ID & Element Value (Item Data) in the script.

How to start the controller from the command line automatically?

Below is the command line argument to invoke the controller

Wlrun.exe –TestPath C:\Temp\Scenario1.lrs –ResultLocation C:\Temp –ResultCleanName Res1 –Run

wlrun.exe is the controller executable file
-TestPath mentions the location from where the Test Scenario is to be invoked
-ResultLocation mentions the location where the Raw Result has to be saved
-ResultCleanName mentions the name with which Raw Result has to be saved

-ResultLocation & -ResultCleanName arguments can be merged together into a single argument
-ResultName

So the command now becomes

Wlrun.exe –TestPath C:\Temp\Scenario1.lrs -ResultName C:\Temp\Res1 –Run

-ResultName mentions the location & filename with which Raw Result has to be saved

If we would like to invoke the Analysis once the test completes then add the argument
–InvokeAnalysis to the above command

So the command now becomes

Wlrun.exe –TestPath C:\Temp\Scenario1.lrs -ResultName C:\Temp\Res1 –Run –InvokeAnalysis

Note

• If the scenario does not specify where the results have to be saved and also even if one of the above parameters was not passed, the scenario will not run.
• The results will always be automatically collated upon scenario termination.
• The results will always be automatically overwritten.

Now comes the automation part.

1. Copy the above command in a notepad and save the file as batch file. Example: ControllerAutomate.bat
2. Now open the Windows Task Scheduler and click Create Basic Task.
3. Mention a Name of the Task in Create A Basic Task. Example -  Controller Scheduler
4. In the Trigger mention when you want to trigger the batch file. Select One Time and set the Date & Time.
5. In the Action Select Start a Program, then browse and Select the batch file.
6. Finish shows the summary of all the selections we have made in the above steps. Verify & click Finish.

Thats it, Windows Task Scheduler will trigger the batch file in the mentioned Date & Time.

Note

• Make sure that Controller is closed before trying to automatically trigger it.

Difference between Concurrent & Simultaneous users in Performance Testing.

Understanding the difference between the Concurrent and Simultaneous users is very much important in generating the type of user load for performance testing.

Concurrent users:

Concurrent users are connected to your test application and are all requesting work at some time intervals but not all at once and not for the same thing (same request or page).

In loadrunner concurrency between the user transactions can be achieved by introducing randomized think time (lr_think_time) and the end of transactions.

Example:

• Below is the table of 5 users working in an e-commerce application.
• We could see that each user is in a different transaction denoted by x mark.
• Transactions highlighted in Green are completed by the user and in yellow are yet to be started which also differs from user to user.

Simultaneous users:

Simultaneous users are connected to your test application and who are all requesting work at the same time and for the same thing (same request or page).

In loadrunner simultaneous user can be achieved by using lr_rendezvous function above the transaction for which we need a simultaneous hit to the server or by selecting all user simultaneously in the controller during the load test.

Example:

• Below is the table of 5 users working in an e-commerce application.
• We could see that all the users are in the same search cart transaction denoted by x mark.
• Transactions highlighted in Green are completed by the user and in yellow are yet to be started which also remains the same for all users.

Pacing Calculation in Loadrunner - Performance Testing

What is Pacing?

• Pacing is the time interval between the iterations. 
• It ensures better gap between the user sessions in the load test.
• It is needed to achieve the required TPS in the load test. 
• Ignoring the pacing will flood the server with requests continuously thus making the test inappropriate.

Pacing can be set in the Run Time Settings.

1. As soon as the previous iteration ends

New iteration will start as soon as the previous iteration ends. Which means Pacing = 0.

2. After the previous iteration ends - with

New iteration will start at fixed or random delay after the previous iteration ends.

Fixed - Mention the exact delay in seconds.

Random - Mention the min and max delay in seconds and pacing will be selected between the specified range.

Example: Pacing = 60 Seconds and Time taken for 1 iteration = 50 seconds.

So the First iteration will end at 50 secs and Second iteration will start after 60 secs from the end of first iteration. Since Pacing = 60 secs.

Here pacing acts as a wait timer.

3. At Fixed or Random intervals - every

Here the Pacing timer for the new iteration will begin when the previous iteration starts and the iterations will be fired at the exact timer. In this case Pacing time should be higher than the Time taken for 1 iteration or else the second iteration will start right after the end of the first iteration.

Fixed - Mention the exact delay in seconds.

Random - Mention the min and max delay in seconds and pacing will be selected between the specified range.

Example 1 : Pacing = 60 Seconds and Time taken for 1 iteration = 50 seconds.

Pacing timer will start with the iteration. First iteration will end at 50 secs and after which there will be 10 secs gap after which the second iteration will start.

Example 2 : Pacing = 60 Seconds and Time taken for 1 iteration = 70 seconds.

Pacing timer will start with the iteration. First iteration will end at 70 secs and after which there will be no gap since the Time taken for 1 iteration has surpassed the pacing time. So the second iteration will start immediately.

Here pacing just acts as a timer.

Formulas to calculate Pacing

Formula 1:

P = ( D - ( I * Ti ) ) / ( I - 1)

where

P   = Pacing time in secs
D  = Duration of the test in secs
I   = No. of Iterations
Ti = Time taken for 1 Iteration in secs

Formula 2:

simplified form of formula 1

P = D / I

where

P   = Pacing time in secs
D  = Duration of the test in secs
I   = No. of Iterations

Formula 3:

P = ( V * D) / Ts

where

P   = Pacing time in secs
V = No. of users in the script for which pacing is calculated
D  = Duration of the test in secs
Ts = Total no of Transactions to be achieved in the test for the script, for which pacing is calculated

Best Practices for Loadrunner Vugen scripting

Best Practices for Loadrunner Vugen scripting.

1. Follow proper script naming convention. Project Name_Scenario Count_Script Name.
Syntax - ProjectName_SCxx_ScriptName

2. Follow proper transaction naming convention. Script Name_ Transaction Count_Step Name.
Syntax - ScriptName_Txx_StepName

3. If script has multiple actions, name the actions properly.
Syntax - ACxx_ActionName

4. Place Think Time (lr_think_time) outside the transactions. Since placing the Think Time in between the transactions, it gets added up to the total Transaction Response time.

5. Try to place Correlation Function (web_reg_save_param) outside the transactions.Since Correlation Functions wait time also adds up to the total Transaction Response time. (Not always possible but still we can do whatever we can.)

6. Use proper condition blocks to validate the each transaction and fail them if the step is wrong.

7. Do a write up of the scripts flow in the vuser_init section.

8. Whenever you debug the script and make some changes to the script do a small write up about the changes made right above the modified request.

9. Follow proper parameterization naming convention. Parameterization naming should be P_ParameterName.

10. Follow proper correlation naming convention. Correlation naming should be C_ParameterName.
(Step 10 & 11 helps to differentiate between a user defined parameter and a correlation parameter.)

11. Do proper user sign off when the transaction fails to avoid user session issues.

12. If the script has customized code logic's, give a brief description on how the code logic works.

Why should we follow the above best practices?!

1. Makes script debugging easier and reduces the debugging time.
2. Gives an organised layout or structure to the script which makes the script understandable for anyone in the team, under the absence of the script creator.