Understanding various log files in LoadRunner

Once a script is recorded using LoadRunner tool, one can notice 4 different tabs as part of the output window. This article is all about these tabs and their usage. The 4 tabs that you notice are: 

•   Replay Log
•  Recording Log
• Correlation Results
• Generation Log

Let us start the way these logs are generated.

Recording Log:

When a script is being recorded, the Virtual User Generator records all the communication that has happened between the client and the server into a log called “Recording Log.” Though this is not in a much readable format, the recording log will be the base for the generation log.

The option Regenerate script (Navigate to tools à Regenerate script) works purely using the recording log. If the recording log is missing, the script cannot be regenerated with different recording options

Generation Log:

Generation contains the information about the recording options used for the script, the request header, request body, response header and response body and the function that simulates the request. This function may be varied based on the recording options used.

The generation log content may be changed based on the recording options that are used and for the generation Log, recording log is input file

Once generated, the contents of the recording and generation logs are not altered

Replay Log

This log displays the output when the script is replayed. This log is helpful to debug the script and  customize the script. The contents of this log file can be controlled based on the run time settings (Vuser à Run Time settings à Log à either standard log or extended log)

The output functions like lr_output_message, lr_log_message() and lr_error_message() would write their content to the Replay Log.

Correlation Results

Once a script is recorded and replayed,  the script can be verified for the dynamic data.  The option “Scan for correlations” is used to compare the recording  and replay data and to highlight the dynamic data if any. The script can be correlated directly from this tab and this is one form of auto correlating the script.

As it compares the recording time data and the replay data, it is always necessary to have the “data” folder inside the script folder

I believe this article is informative and helpful.

Performance testing from tool perspective

The objective of any performance test is to assess the capabilities and limitations of the system when it is subjected to realistic user load. The keyword here is realistic user load. A performance test would be more realistic if it has the below items implemented.

• Simulation of real user behavior
• Simulation of real user load patterns

Simulation of real user behavior is to understand the way the application is accessed by an end user. There are four important aspects of Real user behavior simulation. They are as below:

Real user navigation are different - If there are 100 users accessing a web application,  its not mandatory that all of them using the application for the same purpose. For example a Banking application can be used by the users either to transfer funds, check their balances, Add beneficiaries, download statements and many more. Each of these navigation should be recorded as a separate script.

Real user inputs are different - The inputs provided by the end users to the product are also different. Different people log in with different user name and passwords, search for different products, enter different shipping and permanent addresses etc. To Simulate this aspect, each script has to be parameterized

Real user Selections are different - Once the users enter the application, their selections also can be different (selections from dropdown, radio buttons, check boxes etc). For example in case of booking flights, even if two users are searching for flights from Hyderabad to New York , there can be several flights available and there are chances that both the users may choose different flights. To simulate this aspect of real user behavior, each script has to be correlated

Real users wait between the requests - There would be some waiting time between two successive requests made by a real user. For example the real user launches gmail.com (request1)  and then he enters the username and password and click on Log in(request2). So between request1 and request2, the user waits for some time (this wait time is called think time, and the user waits between requests either to read content and fill in some details or to think and act upon). The same has to be implemented in every script by including think times in the script.

All the above are achieved using the Scripting part of the performance tool (in case of LR, it is VUGen).

The other important aspect of a realistic performance test is to simulate the realistic load patterns
which includes

• Simulating  User Mix (Various types of users for ex: Registered users vs non registered users, Admin users etc)
• Simulating Transaction Mix (The ratio at which each identified use case has to be executed or the load distribution across various use cases)
• Simulating Users' Geographical Locations - Either by having the Load Generators from the locations where the users are coming from or Having the WAN Simulator to simulate the users' geographical locations
• Simulating User's bandwidth - Though few users are from same location, there are possibilities that their Bandwidths are different. This point has to be kept in mind while generating the user load on to the system
• Simulating traffic rate - The rate at which the users come on to the system, the duration the peak user load is maintained, the rate at which users drop off from the system

Most of the above can be achieved in controller.

If the above two points are considered, a performance test that is executed will be more realistic and the results are more accurate.

Date Randomization in LoadRunner

One of the common requirements that a performance tester may experience is randomizing the date.

For example in a online booking of train ticket or air tickets, we may want to book a ticket for a post date which can be any where between tomorrow or 60 days from today. Usually if it is a date is constant, that can be parameterized in LoadRunner. If thats not a fixed date and needs to be randomized, the below code will be helpful.

rand() is a C function that is used to generate a random number.
rand()%30 will give us a random number any where between 0 -29.

randNum = rand()%30 +1 //gives you a random number anywhere between 1 - 30

lr_save_datetime("%d/%m/%Y", DATE_NOW + ONE_DAY*randNum, "JrnyDate");

lr_save_datetime() is the loadrunner function to save a date of a specified format to a loadrunner variable.

In the above example, the date in the format of Date/Month/Year (25/05/2012) is saved to a LoadRunner parameter called "JrnyDate". DATE_NOW gives us the current date and ONE_DAY*randnum will give us a future random date.

Hope this information is helpful.