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.