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.

Understanding a LoadRunner Web (HTTP/HTML) script

Once a script is recorded using the Virtual User Generator with the best recording options (please refer to the link ), the next important thing is to understand the complete script and the functions recorded in the script.

At a very high level, the entire script can be classified into three groups i.e.

• Protocol Specific functions
• LoadRunner functions
• Language specific functions

Protocol Specific functions: 
These functions can be used with a specific protocol only and they cannot be used with any other protocol. For a Web (Http/HTML) protocol, the commonly seen functions are:

• web_url(), web_image(), web_link() - All these functions are used to simulate a GET request
• Web_submit_form() is used to simulate a POST request
• web_submit_data() is used to simulate both GET and POST requests. The attribute "Method" tells if that request is a GET or POST.

web_reg_find() and web_reg_save_param() are the service functions used for page verification and correlation respectively.
All the above functions are starting with the word "web" indicating that they are web protocol specific functions and cannot be used outside Web protocol.
Few other web protocol functions are:

web_set_user(), web_set_max_html_param_len(), web_cache_cleanup(), web_cleanup_cookies() etc

LoadRunner functions:
All these functions are loadRunner specific and can be used across any protocol. All these functions start with lr_. Few examples for LoadRunner functions are:

lr_start_transaction() - To start a transaction to measure the response time
lr_end_transaction() - To stop a transaction to measure the response time
lr_think_time() - to wait for a specified duration
lr_eval_string() - To evaluate the value of a LoadRunner parameter placed in {}
lr_save_string() - To save a string to a LoadRunner parameter
lr_save_int() - To save an integer value to a LoadRunner parameter
lr_exit() - exit a loop/iteration/user from execution
lr_set_debug_message() - To control the log settings of the replay log
lr_output_message() - To write to the output log with an information level setting
lr_error_message() - To write to the output message with error level
etc

Language specific functions:
These functions are not a part of the tool, all the functions that can be used in a language(C or Java) can be directly used in the script provided that the protocol is supported in a language.
For example, The Web(HTTP/HTML) protocol is supported by the C language. Hence all the C functions can be used directly in Web script.
The commonly used functions are:

rand() - to generate a random number
atoi()  - converting a string into an integer
sprintf - Saving a formatted output to a string buffer
strcat - string concatenation
strcpy - Copying into a string
strtok - String tokenizer function

The JAVA protocol cannot support the C language and hence these functions cannot be used by the Java based script.

Hope the information provided about the classification a LoadRunner script is helpful in understanding how the scripts work.

Context based Recording Vs Context less Recording and HTML Vs URL based recording

To understand the "context based recording", if some one asks you a question "How is he doing?", you would definitely ask "Whom are you referring to?". But if the same question is asked during a discussion about one of your friends whose name is  Karthik, you would not ask the question because in the current context HE refers to Karthik. So you can understand who "HE" is. 


The context less question would be like "How is Karthik doing?". There won't be any more questions. Because you are explicitly pointing to a person and not using any generic terms like He, it. This is called context less mode.

In the above example of "HE", "HE" refers to Karthik only for that discussion and for a different discussion "HE" may refer to someone else.  The context is only until the discussion.
 
There are two recording modes available in LoadRunner to record the user actions of a Web Application. They are

·         HTML mode

·         URL Mode

HTML mode – In this mode of recording, each USER ACTION is recorded as a separate request.  To put it in simple terms, each HTML content (usually a page except in case of HTML Frames) is recorded as a request

If all the user actions are recorded into a Single ACTION of the script, then the HTML mode of recording acts as "Context Based Recording".

The Virtual User Generator understands the Context by looking at the previous request's response. Hence it identifies the Forms, Images etc and you would notice the below functions in a context based recording of the script.
web_submit_form() - to simulate a POST Request
web_image(), web_link() - to simulate a GET request



In VUGen, the context is applicable only till the Action. If you record a user action into a different action, the context would reset and again the context has to be created.

In a case where the tool has to enter some data in a form and if the form is not found in its previous response, the tool will halt the execution of the script.  Every request is directly dependant on the previous request’s response and has high chances of failure with the UI changes to the web application

The advantages of using the HTML recording mode is that the size is very compact and the customization efforts would be very less. The other side of the coin is that, with the UI changes to the web applications, these scripts would require very high maintenance costs.

URL Mode: In this mode of recording each resource requested by the user is recorded as a separate request.  in other words, whatever the content (like images, CSS, JS, HTML) that makes the HTML page is recorded as a separate request. When a web site is launched apart from the HTML content, there would be lot of images, java script files, CSS files downloaded. All these are called resources and each resource is recorded as a separate request.

URL mode is always context less recording because this mode refers to the data and the URL of a request directly instead of depending on previous response. This mode does not depend on the UI of the application, rather the actions associated with the user actions performed on UI. As each resource is recorded, the size of the script would be very high and this also involves in lot of customization. The benefit of having scripts with URL recording mode is that the maintenance cost associated with these are very less and can be used across various releases of the product despite lot of UI changes.

Usually URL mode of recording is used with Non –browser applications in other words any thick client activity is recorded using the URL mode.

Trade off – with the HTML recording mode, another option is available under “Advanced options” of HTML mode. The option available is Explicit URLs only mode.

The benefits of the HTML mode and URL mode is clubbed together in HTML à Explicit URLs only. With this mode, the size of the script would be compact (as only the user action is recorded as request, not at the UI level but at the request level) and requires a bit of more customization efforts but has the advance of high maintainability for longer durations. This is the most recommended recording mode for web applications where the scripts have to be maintained for longer durations

Tip: Have you forgotten to record the script using HTML à Explicit URLs mode? No problem....

Change the recording options to HTML à Explicit URLs only and now navigate to Toolsà Regenerate script. The regenerated script is as fresh as a recorded script using HTML Explicit URL’s only. But do remember that whatever the changes that are made to the script would be gone if the script is regenerated.

Next post: Understanding various logs in LoadRunner

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.