LoadRunner Interview Questions

Load testing is the process of examining how a system behaves under normal and significantly high loads by simulating real-world loads on the application. This testing helps us understand how well our application can cope with the peak loads simultaneously on the servers during the maximum demand scenarios. Without load testing, there are chances that we might have underestimated how well the application would perform, and when the application is under heavy user loads, the application might crash which could potentially result in huge losses to the business. Load testing is typically done when the development of the software/application is close to completion.

Checkpoints are the verification points that help to identify if your script has tested the flow properly. Sometimes, the script may not have tested the flow properly, but still, returned the test as PASS. To ensure that proper workflow has been followed, we use checkpoints. LoadRunner supports two types of checkpoints:

1. Text checkpoint: This checkpoint confirms if a text string is present on the web page during run-time
2. Image checkpoint: This checkpoint confirms if an image is present on the web page during run-time

We can enable the text and image checks in VuGen by making use of the web_find and web_image_check functions respectively. We can also enable this by enabling text and image checks from runtime settings as --> Go to Runtime Settings -> Click on “Preference” -> Enable Image and Text checkbox.

Elapsed time indicates how much time has elapsed (or passed) since the start of the current event. For the scenario status window, the elapsed time is measured from the exact moment the “Start Scenario” or “Initialize/Run Vuser” button is clicked. For the Vuser window, the elapsed time is calculated from the moment Vuser enters the “running” state.

LoadRunner has two types of scenarios:

1. Manual Scenario: Here, the user should specify the ramp-up, ramp-down, test duration time, Vusers, Vuser scripts, etc that gives the testers control over how they can run the script and at what instance of time.
2. Goal-oriented Scenario: This scenario is created on the basis of the goal provided by us that allows the LoadRunner Controller to do it. Goals can be in terms of throughput, the number of concurrent Vusers, the response time of transactions, hits per second, and pages per minute.

A scenario is a description of events that is supposed to take place during testing. It regulates and specifies the number of users that need to be emulated, the sequence of actions which has to be performed, and the machines on which virtual users should execute the actions and simulations.
To create a scenario:

1. Install the LoadRunner controller on the host.
2. Add a list of hosts where the Vuser scripts have to run and add the list of Vusers that should run the specified scenario.
3. Save.

To run a scenario:

1. Open existing scenario.
2. Configure the scenario with Vusers and Vuser scripts.
3. Set result directory.
4. Run scenario.

Correlation deals with managing dynamic values in a test script. The values could change depending on every user action dynamically. Correlation ensures that the dynamic values do not break down during the execution of the script. There are two types of correlation:

1. Manual Correlation: This deals with manually locating dynamic values, finding unique boundaries of value capture, determining the first occurrence of that value and finally developing the “web_reg_save_param” correlation function before a request has the first occurrence of a dynamic value in response.
2. Automatic Correlation: This works based on the predefined rules of correlation. When a script fails, it would be replayed and inspected for autocorrelation. VuGen helps to identify areas where correlation rules are valid and approval value is correlated. Automated Correlation can be set by going to General Options --> Correlation. Correlation rules can be set by going to Recording Options --> Correlations.

• Ramp up: This refers to increasing (ramping up) load gradually on a server. For example, we can gradually increase the number of Vusers that creates load on the server under test. The initial value for ramp-up would be set by default and we can specify what is the value to wait between intervals. This can be configured by just going to ‘Scenario Scheduling Options’ in LoadRunner.
• Ramp down: This refers to decreasing the load (ramping down) gradually on a server. Gradually decreasing the number of Vusers is an example of a ramp-down. Ramp-down can be correlated to the scenario when an application in real-time sees a drop in concurrent users after the peak time.

Following are the benefits of ramp up and ramp down:

1. They help to mimic real-time end-user behaviour and pattern that aids in understanding how the application behaviour varies with an increase or decrease in concurrent users at a steady pace.
2. They help to test auto-scaling in a server by verifying if more servers are spinned up with increasing load or not.
3. Server metrics like memory and CPU utilization can be calculated that would closely reflect the real-time behaviour of applications under varying loads.

Logs are files that are crucial for debugging a script. Logging is mainly used for debugging and is disabled during script execution. However, we can enable logs for errors only after the script has been launched. LoadRunner supports two types of Vuser logs, they are:

• Standard Logs
• Extended Logs

Standard logs create logs of messages and functions sent to the server during the execution of the script whereas extended logs are used for logging additional warnings and other messages required for debugging process.

In LoadRunner, Vuser is a replacement for human users and is used for imitating the behaviour of real users by executing specified business activities mentioned in the Vuser script of the application under test. These activities are recorded in the recording session. Vuser script is a script generated with the help of the VuGen component that controls the activities of Vusers for accomplishing a specific goal. Every Vuser executes the Vuser script. The performance of the application under test is tracked by functions defined in the Vuser script.

• vuser-init: This records the initialization operations called pre-operations before the application is actually executed.
• action: This is used for recording business processes.
• vuser-end: This is used for recording log-off activity to the server.

Following are the steps involved in the creation of Vuser Script:

• Create: The first step is the creation of a blank script.
  • Open VuGen, select File, and then you can either select New Script and Solution or New Solution button.
  • A dialog box opens up that indicates to Create a New Script. Here select the protocols that you want to test from the Category list and enter the name for your script in the Script Name field. (It is advised not to name the scripts init, run or end as these are the keywords that are being used internally by the VuGen.)
  • Click on Create to create the blank Vuser script.
• Record: Once an empty script has been created, we can use the VuGen for recording user-action processes into the script. VuGen provides a floating toolbar that aids in recording control - for example - pause, stop, insert rendezvous points, etc.
• Replay and Debug: Once the recording is done, we have the option to replay the script. This aids in testing the basic functionality of the script and recognizes areas with errors/issues that have to be addressed. For example, the script might need correlation adjustment which is usually found during the replaying of the script. VuGen provides various debug features in the toolbar that helps to identify errors.
• Enhance: Once the replay is complete, you can enhance the script by adding functionalities like transaction points, parameterization, rendezvous points, comments, steps etc.
• View/Analyse: Finally view the summary and analyze the scripting process by going through the “Replay Summary Report”. This report is useful while you are creating the Vuser script.

For a more detailed overview of the steps involved in the scripting process, you can refer [here]

Following are the steps to run a test on LoadRunner:

• Plan Tests - This step involves developing a well-defined test plan that ensures that the performance objectives are accomplished when running LoadRunner scenarios.
• Create Vuser scripts - This step deals with the creation of a Vuser script which consists of various tasks that are to be performed by each Vuser during the execution of test scenarios.
• Create Scenario – This step deals with the elaboration of events that takes place during the testing. A scenario consists of machines, Vusers, and scripts that Vusers make use of during the execution. These are created in Controllers. Scenarios can be manual or goal-oriented.
• Run the Scenario – The scenario created in the above step is executed under the influence of individual Vusers or Vuser groups. The Vusers are instructed to perform tasks in the scenario at the same time for emulating the load on the system.
• Monitor the performance – During the execution of scenarios, monitoring of resources used during database transactions and various operations can be done. This helps in identifying the performance bottlenecks under varying load conditions.
• Analyse test results - The result of LoadRunner’s scenario execution are analyzed by going through the graphs and reports generated by the “Analysis” component of LoadRunner.

The following are the major components of LoadRunner:

• VuGen (Virtual User Generator): This component helps to record end-user business processes like payment process on abc.com, checking user profile, etc, and generates the automated testing script called Vuser script. This script can be used in various other Micro Focus applications like Business Process Monitor, LoadRunner Cloud etc.
• Controller: This component is an administrative center responsible for the creation, maintenance, execution, and monitoring of various load test scenarios. It helps to control the load simulation by providing options to manage:
  • How many VUsers are needed for simulating each business process?
  • What should be the behaviour of Vusers? Should they act simultaneously, concurrently or should the count of Vusers ramp up or ramp down?
  • How should the error reporting be done?
  • How should the transaction reporting take place?
  • When do you want the results - periodically or one time? etc
• Load Generator: As the name indicates, this component is used for generating load (or VUsers) which in turn consumes hardware resources like CPU, memory, etc which can put a limit on the machine simulating the tests. This component is also called an Agent Machine as they generate “agents” for the application under test. As good practice, it is recommended to have controllers and load generators on different machines.
• Analysis: This component is used for visualizing and analyzing the results of load tests. It provides tools to generate graphs and reports for summarising the performance of a system. Once the load testing scenarios are completed, the controller dumps the results in raw form. All the exceptions and errors encountered would be tracked in the Microsoft Access Database (.mdb file) and this file is read by the Analysis component for performing different types of analysis on the results to generate graphs. The resultant graphs help us to identify under what scenarios errors have occurred and various other performance bottlenecks which the developers can then work on fixing them.

Performance testing is the process of evaluating an application’s performance under varying load and stress conditions. Performance is commonly measured by the time it takes for an application to respond to user actions. LoadRunner supports the following types of performance testing:

• Load Testing: This testing helps to determine how well an application performs under heavy load.
• Stress Testing: This helps to identify how the system responds and behaves during sudden spurts of activities.
• Capacity Testing: This helps to recognize the resources (capacity) needed by the system to ensure that it responds to a user action in an acceptable manner.

LoadRunner is a licensed performance testing tool provided by Micro Focus. Earlier it was called HP LoadRunner. It is essentially used for testing the behaviour and the performance of an application under various load conditions. The following are the advantages of LoadRunner:

• It supports various testing types like - Load testing, Stress testing, and capacity testing of software.
• LoadRunner can be used to detect performance bottlenecks in our applications.
• It helps reduce the amount of human intervention and interaction by providing means to automate the testing process.
• It helps to accurately identify and fix various system, code-level, and end-user bottlenecks before deployment and helps to reduce the downtime of that application when it is live.
• By identifying the system’s operating capacity and limits, LoadRunner helps improve system scalability.

The count of Vusers depends on the application under test, hardware settings, infrastructure like network configurations, memory, operating system, and objective of the performance test. We cannot provide a generic value for the number of Vusers.

The result will be displayed next to the student’s name with the label “Passed” or “Failed” depending on whether the student has passed or not. How can we identify what is the count of students that have passed and failed the VuGen Script?

Since we have “Passed” and “Failed” labels on the page, we can make use of the text check using the web_reg_find method and SaveCount to store the number of matches found on the webpage as follows:

/* To find count of students passed */
web_reg_find("Text=Passed", "SaveCount=Students_Passed", LAST);

/* To find count of students failed */
web_reg_find("Text=Failed", "SaveCount=Students_Failed", LAST);

Conclusion

LoadRunner has become an important software performance testing tool in the corporate world as it provides various powerful tools to emulate real-world scenarios effectively under varying loads. Hence, it is important to have both practical experience and theoretical knowledge about this tool for any software testers as well as software developers. In this article, we have seen the most commonly asked interview questions in LoadRunner for both freshers and experienced professionals in software testing and development fields.

References

LoadRunner Official Documentation: https://www.microfocus.com/en-us/products/loadrunner-professional/overview

Important Testing Interview References:

• https://www.interviewbit.com/blog/types-of-software-testing/
• https://www.interviewbit.com/blog/performance-testing-tools/
• https://www.interviewbit.com/software-testing-interview-questions/
• https://www.interviewbit.com/automation-testing-interview-questions/
• https://www.interviewbit.com/database-testing-interview-questions/
• https://www.interviewbit.com/functional-testing-interview-questions/
• https://www.interviewbit.com/agile-testing-interview-questions/
• https://www.interviewbit.com/manual-testing-interview-questions/

Yes, caching has a lot of impact on load testing. In the presence of caching, the surf history would be stored in a temporary memory called cache and whenever information is required to load a page, it would be loaded mostly from cache thereby reducing the time taken to load the page for second and subsequent times. This will affect the reaction times in the testing results as they would not be accurate while testing varying loads. Hence, caching should be disabled before we perform load testing.

Concurrent users define the number of users for a given test duration whereas simultaneous users define the number of users performing the same transactions at a particular point in time. All concurrent users are not the same as simultaneous users, however, all simultaneous users are actually concurrent users.

In LoadRunner, when a script is running, all Vusers working on the test are concurrent users as they are assigned to use the application under test at the same time. However, the Vusers might not be performing the same activity at any instant in time. For example, in the image below, we can see that there are 6 Vusers available and performing a series of actions in an application under test. We can observe that not all Vusers would be in the same step at that point for concurrent users. Whereas for simultaneous users, we can see that all users would be performing the same activities at that instant of time.

It is possible to convert concurrent users to simultaneous users by making use of rendezvous points. When we add rendezvous points in between actions, the controller waits for the specified number of Vusers to arrive at that point so that they can perform tasks at the same time.

Hits Per Second is a measure of the number of times our site is hit/visited by users in any second. It corresponds to the number of times users send HTTP requests to the web server.

Throughput is a measure of the number of requests a software can handle per hour, or per minute or per second. An increase in the Response time of requests decreases the throughput.

VuGen stands for Virtual User Generator. This is usually where the actual scripting takes place. Running a script in VuGen is beneficial if we want to debug while we are writing it as the VuGen lets us see where the script has failed, what the response of the script is, and what needs to be changed. However, this is useful only to test with a single user and is limited to local machines only. When we are ready with the script after debugging here, we can run the script in the controller. The controller is like a command centre in LoadRunner because here we have options to ramp up the number of Vusers, select scenario configuration based on the workload model, configure monitors etc. In addition to this, the controller does not launch separate VuGen instances for each Vuser while running the script.

Think time refers to the delay that happens between the time when the user receives the response from a server and the time taken by the user to review this response. This can be emulated in LoadRunner by intentionally configuring wait time between the script actions. The threshold level of think time refers to the level below which the think time recorded is ignored. 

The default threshold level value for this field is 5 seconds. This value can be changed in VuGen by going to the Recording Options. Go to Recording Options, then go to Script, and then you can generate think time greater than the threshold.

Monitors are used for monitoring performance bottlenecks by helping to identify the problematic area that leads to an increase in response times. Monitors are available in LoadRunner controllers. Some monitors would be enabled by default and their statistics would be visible while running the test. However, most monitors require configuration within the Controller component. LoadRunner Controller provides monitors like Run-time, Transaction, Web Resource, Network, System Resource, Firewall, Database Server Resource, Web Application Server, Dynatrace, Kafka, and many more!

To set up the monitoring environment in LoadRunner Professional, we need to follow the below steps:

1. First, install monitoring components on the server. The setup/installation details vary for each type of monitor. You can refer to the official documentation for installing each monitor.
2. Add the server that has to be monitored to the Controller. This can be done by:
   • Select a server whose monitors have to be configured in the controller. If we need to monitor a server from the controller, then we need to add the monitoring measurements and the machine in the controller.
   • Select the required monitor graph in Graphs the section for displaying in the right pane of the Run tab.
   • Select Add Measurements on the graph or from the graph menu (in hamburger shape). This opens the Monitor dialog box. Here, Go to the Monitored Server Machines section and click Add. This opens the Add Machine dialog.
   • Enter the IP address or your server name that needs to be monitored. Select which platform your server runs. Select what measurements have to be configured.
   • Ensure that the monitors selected appear in the Monitored Server Machines section of the Monitor dialog.
   • In the Resource Measurements part in the Monitor dialog, click Add and define the server measurements in the Monitor Configuration dialog.

Following are some of the changes we can make in the run-time settings:

• Log – This allows us to define and set which logs have to be stored.
• Run Logic – This lets us arrange operations in a logical way and set the number of iterations for the script.
• Browser – This lets us calibrate browser settings like cache.
• Pacing – This lets us insert random or fixed delays between iterations.
• Proxy – This helps us set the proxy server.
• Think time – This can be set to fix or random delay between transactions.
• Miscellaneous – This lets us configure settings corresponding to multithreading, error handling, or automatic transactions.
• Speed simulation – This aids in configuring the network speed by setting the bandwidth value.
• Streaming – This sets up video buffer retries and timeouts.
• Download Filters – This lets us filter out unwanted requests coming from any source like a server or URL.
• Content check – This helps us find known errors in the script at the time of execution.
• Preferences – This lets us set checkpoints and advanced settings like performance graphs etc.

The autocorrelation rules can be exported to a .cor file and it can be then shared with the teammates. The teammate then has to import this file into autocorrelation rules present in their workstation.

It is not possible to perform manual correlation when the script runs. However, the script can be stopped and then we can make the required changes.

There are two possible ways to identify if a project requires correlation or not:

1. Look out for correlation manually and examine what are the list of values that can be subjected to correlation.
2. Record two scripts and compare the results. We can look at the difference between these two results and identify the values which can be correlated.

When we run Vuser as a process, the same driver program will be loaded into memory for each Vuser. This results in high RAM consumption and restricts how many Vusers we want to execute in that single generator. However, if we run Vuser as a thread, then only one instance of the driver program will be loaded into memory for that many Vusers. This type of multithreading mode allows us to add and run more Vusers on a single generator. Hence, running on the thread is more advantageous.

The Performance Testing Life Cycle is a systematic process of carrying out non-functional testing of software applications under test. Performance testing helps to identify bottlenecks in performance and gives an overview of how well our system can perform under varying conditions. The lifecycle of performance testing consists of the following steps:

1. Risk Assessment: The main aim of this phase is to see if the components are eligible for performance testing based on evaluating the risk assessment of the application. Typically this is done by the manager or leader assigned to test the performance.
2. Requirement Gathering & Analysis: Here, the non-functional requirements have to be gathered and client expectations have to be understood thoroughly. The end result of this phase is to arrive at a document called “Performance Testing Requirement Document”.
3. Planning: In this phase, the performance testing team has to come up with a test strategy known as a performance test plan that tests the non-functional requirements gathered above.
4. Design and Scripting: Here, the aim is to write test scripts as per the plan approved in the previous phase.
5. Workload Modelling: The Workload scenario has to be modelled and created based on the test scripts and the test plans.
6. Execution & Analysis: Here, the performance tests have to be executed and the results are to be analyzed based on the test findings.
7. Report and Recommend: Finally, the goal is to compile and publish the report on performance testing and based on the findings, recommend possible solutions to avoid any bottlenecks.

Rendezvous points create intense load (as defined by rendezvous policy) on the server by instructing multiple Vusers to perform certain tasks simultaneously. They also enable the LoadRunner Professional to calculate the performance under this load. For example, if we want to test how a banking system website performs when there are 20 Vusers simultaneously checking for their account information, we emulate this by instructing the Vusers to check their account information at the same time by creating a rendezvous point. When a Vuser arrives at the rendezvous point early, the LoadRunner Controller holds it there as per the rendezvous policy. A rendezvous policy can be configured based on which the Controller can release the Vusers from that rendezvous point when required Vusers arrive or after a specific amount of time has elapsed. The Vusers are released to perform multitasking simultaneously to simulate the load. A rendezvous point is simply a meeting point for the Vusers between transactions.

Rendezvous points can be inserted in any one of the below ways:

• During recording, we can click on the Rendezvous button present on the Recording toolbar as shown in the image below, and enter the name in the dialog box. Please note that the name is not case-sensitive.

• After recording, to add a rendezvous point, we need to Select Design --> Insert in Script --> Rendezvous --> enter name.

After insertion of the rendezvous point, VuGen inserts lr_rendezvous("name_of_point") function into Vuser script to mark that point in the script as a rendezvous point.

Earlier, performance testers had to rely mostly on the project development team to understand what protocol the system under test uses to interact with the server. But, from version 9.5 onwards of LoadRunner, we have a protocol advisor that inherently detects what protocol the application uses and suggests to the testers the best protocol using which the script can be created for simulating real user testing.

The lr_abort() function does the task of aborting the execution of the script after the execution of the “vuser_end” section. It is useful when we require to abort the script manually due to specific error criteria.

The lr_exit() function lets the user exit from the script at the time of execution by giving different continuation options like exiting the Vuser or exiting the current iteration and continuing with the next. There are three ways from which script execution can be exited by the LoadRunner. It can be the exit from iteration, action, or the script itself. 

The syntax of lr_exit is:

void lr_exit (int continuation_option, int exit_status);

Here, the continuation_option specifies how the script should continue after calling lr_exit and the exit_status (LR_PASS, LR_FAIL, LR_AUTO, or LR_STOP) defines what should be the status of exit of the scenario group.

The following are the types of continuation options available:

• LR_EXIT_VUSER – This immediately stops script execution and goes to the vuser_end section.
• LR_EXIT_ACTION_AND_CONTINUE – This stops the current action and continues to go with the next action.
• LR_EXIT_ITERATION_AND_CONTINUE – This exits the execution of the current iteration and goes to the next iteration.
• LR_EXIT_VUSER_AFTER_ITERATION – This stops the script execution after the current iteration is complete.
• LR_EXIT_VUSER_AFTER_ACTION – This stops the script execution after the current action is complete.

It is interesting to note that if lr_exit is called with LR_EXIT_VUSER as the continuation option and LR_ABORT as exit status, then it equals the lr_abort functionality as both of its aims is to abort the script execution.