How Analysis module of LoadRunner interacts with the results files?
When analysis graphs and reports are generated, the Analysis module of LoadRunner copies all the scenario result files to a database.
Then the Analysis module directly interacts with the database and does not require the individual result files.
What are the benefits of saving scenarios in a Quality Center Project?
When Controller module of LoadRunner is connected to a Quality Center project, we can create a new scenario in the Controller and save it directly to the Quality Center project.
This helps us in keeping a track of all scenarios created for each subject and allows monitoring the progress of test planning and creation.
How can we test the functionality of an application under heavy load using LoadRunner?
LoadRunner integrates functional testing scripts created by Functional testing Tools like QTP or WinRunner. These scripts in the form of GUI Vuser scripts integrate into the scenarios of LoadRunner.
What are the benefits of running functional test scripts in LoadRunner?
1) To see how the functionality of the application gets affected under the heavy load.
2) To measure the end-to-end response time experienced by a typical user on the client side while the application is under load.
3) By including QTP test scripts at specific points in a LoadRunner scenario we can confirm that the functionality of our application does not get affected by the extra load at these sensitive points.
4) When a GUI Vuser script runs on our screen during the LoadRunner scenario, we can watch the actual steps executed by the Vuser in a real time.
What is a GUI Vuser?
A GUI Vuser emulates the complete environment of a human user. GUI Vusers enable us to measure and monitor end-to-end user response times while our client/server system is under load.
A GUI Vuser can be programmed to read and act on information that appears on its machine’s display. All actions of every GUI Vuser are described in a GUI Vuser script generally created in QTP or WinRunner.
GUI Vusers are monitored and managed through the Controller module of LoadRunner.
Can we use VuGen module of LoadRunner to run a GUI Vuser script?
We cannot use VuGen to run a GUI Vuser script.
We use the Controller module of LoadRunner to run a GUI Vuser script as part of a scenario. Whereas we use QTP or WinRunner to run a GUI Vuser script in the standalone mode.
What is End-to-end response time in relation to GUI Vuser Technology?
End-to-end response time means the total time that a user waits for a response after submitting a request. GUI Vusers measure real end-to-end response times. End-to-end response times include GUI response times plus network and server response times.
What are the special design constraints with QTP Tests while adopting in LoadRunner?
1) Only simple QTP tests should be adopted for use in LoadRunner & should be designed to pinpoint specific operations.
2) LoadRunner cannot run nested action iterations.
3) Do not include references to external actions or other external resources, like an external Data Table file, environment variable file, shared object repositories etc.
4) Include transactions in QTP test since LoadRunner only provides performance information for data that is included within a transaction.
How do we define transactions within our Vuser script?
Transactions are defined as an action or a set of desired actions to measure the performance of a server.
We define transactions within our Vuser script by enclosing the appropriate sections of the script with start and end transaction statements. For example, we can define a transaction, which measures the time it takes for the server to process a request to view the balance of an account and for the information to be displayed at the ATM.
For use in LoadRunner, which statements are manually added to basic Vuser script recorded in WinRunner?
Since LoadRunner provides performance-related information only for the data included within a transaction. Hence WinRunner test scripts are manually edited to include transactions needed to be used by LoadRunner. Thus following statements are manually inserted into WinRunner test scripts:
1) Transaction statements to measure the performance of the server.
2) Rendezvous statements to emulate a specific user load.
What are the special considerations while running the LoadRunner scenario integrated with GUI Vuser script created in QTP or WinRunner?
1) Run just the one GUI Vuser concurrently per machine.
2) Ensure that QTP and WinRunner are closed before running the scenario.
3) In the Run-time Settings for script dialog box, only the General categories and sub-categories like General, Iterations, Miscellaneous, Think Time etc. are relevant for QTP and WinRunner tests.
4) The Replay options are not relevant for QTP and WinRunner tests.
What actions are performed by the LoadRunner during scenario execution?
While executing a scenario, the LoadRunner does the following:
1) Recording of the duration of the transactions you defined in the Vuser scripts
2) Performing the rendezvous included in the Vuser scripts
3) Collecting error, warning, and notification messages generated by the Vusers
During running of scenarios Controller module of LoadRunner performs following actions:
a) Checking the scenario configuration information.
b) Invokes the applications selected by us for running with the scenario.
c) Distributing each Vuser script to its specified load generator. When the Vuser groups become re ready, they start executing their respective scripts.
Can we activate an additional Vuser while a scenario is running?
With the help of Run / Stop Vusers dialog box, we can activate an additional Vuser while a scenario is running.
The scenario will finally end when all the Vusers have completed their scripts, or when the specified duration finishes out, or when we terminate it.
What are the brief steps of running a scenario?
Scenario execution by & large follows following basic steps:
Step -1:Opening of an existing scenario or creating a fresh one.
Step -2:Configuring and scheduling the scenario.
Step -3:Setting the results directory.
Step -4:Running and monitoring the scenario.
How running of individual Vusers differ from running an entire scenario?
We can run all the Vusers and Vuser groups all together in a scenario, alternatively we can chose the specific Vuser groups and Vusers and can run them individually.
The difference in operation lies as under:
1) When We run an entire scenario, LoadRunner does not begin running Vusers until they all reach the Ready state.
2) When we run individual groups or Vusers, LoadRunner runs each Vuser immediately after it reaches the Ready state.
What do we mean by initialization of Vusers in a group?
By initializing the Vusers, we distribute the Vusers in the group to their specified load generators so that they get ready to execute their script.
The status of the Vuser group changes from Down to Pending to Initializing to Ready. In case a particular Vuser group does not get initialized due to any reason, the status of this Vuser group changes to Error.
By initializing all the Vusers in a group before running them, we can ensure that they all begin executing the scenario at the same time.
How the addition of new Vusers differ among various modes of running a scenario?
We run a scenario or Vuser in two modes like: 1) Vuser Group Mode 2) Percentage Mode.
1) Vuser Group Mode: Here we control the number of new Vusers that can be added to each Vuser Group, and the load generators on which these additional Vusers will run.
2) Percentage Mode: Here we control the number of new Vusers that can be distributed among the Vuser scripts according to the percentage you define, and the load generators on which these additional Vusers will run.
What type of Vuser activity can be seen while a scenario is running?
LoadRunner allows us to see the following Vuser activity during a scenario run:
1) On the Controller load generators, we can view the Output window, monitor Vuser performance online, and check the status of Vusers executing the scenario.
2) On remote machines, we can view the Agent summary with information about the active Vusers.
How connections are established among Controller & Load Generators under fire walled environment?
In a conventional non-firewalled load test scenario, the Controller can directly connect to the LoadRunner agents running on remote machines.
While running Vusers over a firewall, the direct connection between the controller and the Load Generator gets blocked by the firewall. The reason being that the Controller does not have permissions to open the firewall.
LoadRunner addresses this problem by using a communication configuration based on HTTPS or secured TCP/IP.
In such a fire walled environment, a LoadRunner agent is installed on load generators running Vusers, and on Monitor machines which monitor the servers. This agent communicates through port 443 in the firewall.
What is a MI Listener machine?
The MI Listener machine works as a router between the following:
1) The agent on the load generator machine and the Controller, enabling the Controller to run Vusers over a firewall.
2) The agent on the Monitor over Firewall machine and the Controller, enabling the Controller to monitor the servers that are located over a firewall.
MI Listener components are installed on a dedicated machine.
How the communication takes place across MI Listener machine in a fire-walled environment?
The MI Listener serves the purpose of a router between the Controller and the LoadRunner agent.
When the LoadRunner agent connects to the MI Listener machine, the MI Listener keeps a listing of the connection to the agent using a symbolic name that the agent passed to it.
When the Controller connects to the MI Listener machine, it communicates to the MI Listener through port 50500.
How many types of online monitors are available for controller machines?
1) Run-Time Monitors: For displaying the number and status of Vusers participating in the scenario, as well as the number and types of errors that the Vusers generate.
2) Transaction Monitors: For displaying the transaction rate and response time during scenario execution.
3) Web Resource Monitors: For providing information about the number of Web connections, throughput volume, HTTP responses, server retries, and pages downloaded to the Web servers during the scenario.
4) System Resource Monitors: For measuring the Windows, UNIX, Tuxedo, SNMP, Antara FlameThrower, and SiteScope resources used during a scenario.
5) Network Delay Monitor: For displaying the information about the network delays on our system.
6) Firewall Monitor: For measuring the statistics of the firewall servers during the scenario.
7) Web Server Resource Monitors: For measuring the statistics of the Apache, Microsoft IIS, iPlanet Web servers during the scenario.
8) Web Application Server Resource Monitors: For measuring the statistics of the Ariba, ATG Dynamo, BroadVision, ColdFusion, Fujitsu INTERSTAGE, iPlanet, Microsoft ASP, Oracle9iAS HTTP, SilverStream, WebLogic and WebSphere application servers during the scenario.
9) Database Server Resource Monitors: For measuring the statistics of the SQL server, Oracle, Sybase, and DB2 databases during the scenario.
10) Streaming Media Monitors: For measuring the statistics of the Windows Media Server and RealPlayer audio/video servers, as well as the RealPlayer and Media Player client during the scenario.
11) ERP/CRM Server Resource Monitors: For measuring the statistics of the SAP Portals, Siebel Servers, and PeopleSoft servers during the scenario.
12) Java Performance Monitor: For measuring the statistics of Java Platforms and Java-based applications using J2EE machines.
13) J2EE & .NET Diagnostics Monitors: For providing information to trace, time, and troubleshoot individual transactions through J2EE & .NET Web, application, and database servers.
14) Application Component Monitor: For measuring the statistics of the Microsoft COM+ server during a scenario run.
15) Application Deployment Solutions Monitor: For measuring the statistics of the Citrix MetaFrame servers during a scenario run.
16) Middleware Performance Monitors: For measuring the statistics of the Tuxedo and IBM Web servers during a scenario run.
17) Infrastructure Resources Monitor: For measuring the statistics of the network client data points during a scenario run.
What is Merging Graphs in LoadRunner?
LoadRunner allows us to merge the results of two graphs from the same scenario into a single graph.
The merging helps us to compare several different measurements at once. For example, we can make a merged graph to display the Web Throughput and Hits per Second, as a function of the elapsed time.
To merge two graphs, the x-axis of both the graphs must be the same measurement.
What situations are best suited for performing path translation?
1) When saving run-time result files to a shared drive which has been mapped differently by the Controller and remote load generator.
2) When the remote machine maps the path as another drive letter or path, path translation is necessary to enable the load generator to recognize the script location.
2) Across platforms - to translate Windows-based paths as seen by the Controller into paths recognized by the UNIX Vuser load generator.
What is the use of Expert mode of Controller module of LoadRunner?
It is basically meant for the support personnel & helps us in getting access to the system information.
When we work in the Expert mode, the Controller dialog boxes contains additional options for fine tuning the Controller operation.
How to check whether a particular problem lies with a scenario or lies with the Vuser script?
1) Verify that the script runs properly on all remote load generators in stand-alone mode.
2) Test the GUI Vuser scripts on Windows platforms using WinRunner.
3) Test the Vuser scripts on UNIX platforms by running them from the command line.
4) Test all other types of Vuser scripts on Windows platforms by running them from VuGen, or by running a single user from the Controller.
What to do when a test passes when run in VuGen, but fails when run in Controller?
When a test runs in VuGen, the full browser is used. However when this test is run in Controller, it use the browser basics only.
Hence before running a scenario in the Controller with multiple Vusers, it is a best practice to run a single Vuser in stand-alone mode to ensure that the test is free from bugs.
What to do when Controller machine fails to connect to the remote load generator machine?
Check the following items:1) Check TCP/IP connectivity: Ensure full TCP/IP connectivity among the Controller and Vuser machines. Use the ping utility from the DOS command line to verify communication with a remote machine.
2) Check Load generator connections: Ensure full connectivity of the load generator with every remote load generators from the Controller’s Load Generators dialog box.
3) Check UNIX shell: For UNIX Vusers, make sure that the Windows Controller can execute a remote shell command.
What is the use of LoadRunner Agent?
LoadRunner Agent runs on the load generators and enables communication between the Controller, load generators, and MI Listeners under fire-walled environment.
The LoadRunner agent receives instructions from the Controller to initialize, run, pause, and stop Vusers. At the same time, the agent also relays data on the status of the Vusers back to the Controller.
How can we increase the load during the Load test?
We can increase the load on the application during a running load test by manually adding more Vusers.
What to do in case of a warning message that Controller cannot activate additional Vusers?
This is a hardware related problem. It happens when we use our local machine having limited memory resources, as a load generator.
Hence it is better to use a dedicated machine as a load generator to avoid such problems.
How to know as to whether my application performed well under the load?
Look at the transaction response time and find out whether the transaction was within an acceptable limit for the customer.
If the transaction response time degrades, we need to look for problems.
When do we use of goal-oriented scenario in LoadRunner?
Prior to deploying an application, we want to run an acceptance test to make sure that the system will withstand the real-life expected workload.
We have an idea about a rate at which we expect the server should perform say in terms of number of hits or transactions per second.
Using a goal-oriented scenario we define a goal for the number of hits per second, transactions per second, or the transaction response time which we want to generate.
How many types of goals are provided by LoadRunner in a goal oriented scenario?
LoadRunner provides following five types of goals in a goal oriented scenario:
1) Number of concurrent Vusers.
2) Number of hits per second.
3) Number of transactions per second.
4) Number of pages per minute.
5) Transaction response time which we want the scenario to reach.
What is the objective of an analysis session after the load test?
The aim of an analysis session is to find out the failures in performance of our system and then to point out the root cause of such failures.
Following questions are asked during the analysis session.
1) Were the test expectations met?
2) What was the transaction response time on the user’s end under load?
3) Did the SLA meet or deviate from its goals?
4) What was the average transaction response time of the transactions?
5) What parts of the system could have contributed to the decline in performance?
6) What was the response time of the network and servers?
7) Can we find a possible cause by correlating the transaction times and backend monitor matrix?
What to do when a script fails during simple playback, while during recording same actions were successful?
Many applications use dynamic values which change every time we use the application. For example, some servers assign a unique session ID for every new session. When we try to replay a recorded session, the application creates a new session ID which happen to differ from the recorded session ID.
LoadRunner addresses this issue through correlation. Correlation saves the changing values, in this case the session ID, to a parameter. When running the emulation, the Vuser does not use the recorded value and instead of it, it uses the new session ID, assigned to it by the server.
How to confirm as to whether the desired content is the same as the returned web page?
This can be done through the content check which verifies that the expected information appears on a Web page while the script is running.
We can insert following two types of content checks:
1) Text check: For checking that a text string appears on a Web page.
2) Image check: For checking an image on a Web page.
What is the use of a Throughput graph?
The Throughput graph shows the amount of data in terms of bytes which the Vusers receive from the server at any given second.
We then compare this graph with the Transaction Response Time graph to see how throughput affects transaction performance.
How to know that the test has finished running?
When the test finishes its run, the Scenario Status pane shows the Down status. This indicates that the Vusers have stopped running.
We can look in the Vuser dialog box to see the status of each individual Vuser.
How can we instruct LoadRunner to randomly run only one Vuser in a group?
This can be done by right-clicking the Vuser group and selecting "Run One Vuser Until Complete".
A Vuser script log will open, displaying the run-time information about the Vuser.
When analysis graphs and reports are generated, the Analysis module of LoadRunner copies all the scenario result files to a database.
Then the Analysis module directly interacts with the database and does not require the individual result files.
What are the benefits of saving scenarios in a Quality Center Project?
When Controller module of LoadRunner is connected to a Quality Center project, we can create a new scenario in the Controller and save it directly to the Quality Center project.
This helps us in keeping a track of all scenarios created for each subject and allows monitoring the progress of test planning and creation.
How can we test the functionality of an application under heavy load using LoadRunner?
LoadRunner integrates functional testing scripts created by Functional testing Tools like QTP or WinRunner. These scripts in the form of GUI Vuser scripts integrate into the scenarios of LoadRunner.
What are the benefits of running functional test scripts in LoadRunner?
1) To see how the functionality of the application gets affected under the heavy load.
2) To measure the end-to-end response time experienced by a typical user on the client side while the application is under load.
3) By including QTP test scripts at specific points in a LoadRunner scenario we can confirm that the functionality of our application does not get affected by the extra load at these sensitive points.
4) When a GUI Vuser script runs on our screen during the LoadRunner scenario, we can watch the actual steps executed by the Vuser in a real time.
What is a GUI Vuser?
A GUI Vuser emulates the complete environment of a human user. GUI Vusers enable us to measure and monitor end-to-end user response times while our client/server system is under load.
A GUI Vuser can be programmed to read and act on information that appears on its machine’s display. All actions of every GUI Vuser are described in a GUI Vuser script generally created in QTP or WinRunner.
GUI Vusers are monitored and managed through the Controller module of LoadRunner.
Can we use VuGen module of LoadRunner to run a GUI Vuser script?
We cannot use VuGen to run a GUI Vuser script.
We use the Controller module of LoadRunner to run a GUI Vuser script as part of a scenario. Whereas we use QTP or WinRunner to run a GUI Vuser script in the standalone mode.
What is End-to-end response time in relation to GUI Vuser Technology?
End-to-end response time means the total time that a user waits for a response after submitting a request. GUI Vusers measure real end-to-end response times. End-to-end response times include GUI response times plus network and server response times.
What are the special design constraints with QTP Tests while adopting in LoadRunner?
1) Only simple QTP tests should be adopted for use in LoadRunner & should be designed to pinpoint specific operations.
2) LoadRunner cannot run nested action iterations.
3) Do not include references to external actions or other external resources, like an external Data Table file, environment variable file, shared object repositories etc.
4) Include transactions in QTP test since LoadRunner only provides performance information for data that is included within a transaction.
How do we define transactions within our Vuser script?
Transactions are defined as an action or a set of desired actions to measure the performance of a server.
We define transactions within our Vuser script by enclosing the appropriate sections of the script with start and end transaction statements. For example, we can define a transaction, which measures the time it takes for the server to process a request to view the balance of an account and for the information to be displayed at the ATM.
For use in LoadRunner, which statements are manually added to basic Vuser script recorded in WinRunner?
Since LoadRunner provides performance-related information only for the data included within a transaction. Hence WinRunner test scripts are manually edited to include transactions needed to be used by LoadRunner. Thus following statements are manually inserted into WinRunner test scripts:
1) Transaction statements to measure the performance of the server.
2) Rendezvous statements to emulate a specific user load.
What are the special considerations while running the LoadRunner scenario integrated with GUI Vuser script created in QTP or WinRunner?
1) Run just the one GUI Vuser concurrently per machine.
2) Ensure that QTP and WinRunner are closed before running the scenario.
3) In the Run-time Settings for script dialog box, only the General categories and sub-categories like General, Iterations, Miscellaneous, Think Time etc. are relevant for QTP and WinRunner tests.
4) The Replay options are not relevant for QTP and WinRunner tests.
What actions are performed by the LoadRunner during scenario execution?
While executing a scenario, the LoadRunner does the following:
1) Recording of the duration of the transactions you defined in the Vuser scripts
2) Performing the rendezvous included in the Vuser scripts
3) Collecting error, warning, and notification messages generated by the Vusers
During running of scenarios Controller module of LoadRunner performs following actions:
a) Checking the scenario configuration information.
b) Invokes the applications selected by us for running with the scenario.
c) Distributing each Vuser script to its specified load generator. When the Vuser groups become re ready, they start executing their respective scripts.
Can we activate an additional Vuser while a scenario is running?
With the help of Run / Stop Vusers dialog box, we can activate an additional Vuser while a scenario is running.
The scenario will finally end when all the Vusers have completed their scripts, or when the specified duration finishes out, or when we terminate it.
What are the brief steps of running a scenario?
Scenario execution by & large follows following basic steps:
Step -1:Opening of an existing scenario or creating a fresh one.
Step -2:Configuring and scheduling the scenario.
Step -3:Setting the results directory.
Step -4:Running and monitoring the scenario.
How running of individual Vusers differ from running an entire scenario?
We can run all the Vusers and Vuser groups all together in a scenario, alternatively we can chose the specific Vuser groups and Vusers and can run them individually.
The difference in operation lies as under:
1) When We run an entire scenario, LoadRunner does not begin running Vusers until they all reach the Ready state.
2) When we run individual groups or Vusers, LoadRunner runs each Vuser immediately after it reaches the Ready state.
What do we mean by initialization of Vusers in a group?
By initializing the Vusers, we distribute the Vusers in the group to their specified load generators so that they get ready to execute their script.
The status of the Vuser group changes from Down to Pending to Initializing to Ready. In case a particular Vuser group does not get initialized due to any reason, the status of this Vuser group changes to Error.
By initializing all the Vusers in a group before running them, we can ensure that they all begin executing the scenario at the same time.
How the addition of new Vusers differ among various modes of running a scenario?
We run a scenario or Vuser in two modes like: 1) Vuser Group Mode 2) Percentage Mode.
1) Vuser Group Mode: Here we control the number of new Vusers that can be added to each Vuser Group, and the load generators on which these additional Vusers will run.
2) Percentage Mode: Here we control the number of new Vusers that can be distributed among the Vuser scripts according to the percentage you define, and the load generators on which these additional Vusers will run.
What type of Vuser activity can be seen while a scenario is running?
LoadRunner allows us to see the following Vuser activity during a scenario run:
1) On the Controller load generators, we can view the Output window, monitor Vuser performance online, and check the status of Vusers executing the scenario.
2) On remote machines, we can view the Agent summary with information about the active Vusers.
How connections are established among Controller & Load Generators under fire walled environment?
In a conventional non-firewalled load test scenario, the Controller can directly connect to the LoadRunner agents running on remote machines.
While running Vusers over a firewall, the direct connection between the controller and the Load Generator gets blocked by the firewall. The reason being that the Controller does not have permissions to open the firewall.
LoadRunner addresses this problem by using a communication configuration based on HTTPS or secured TCP/IP.
In such a fire walled environment, a LoadRunner agent is installed on load generators running Vusers, and on Monitor machines which monitor the servers. This agent communicates through port 443 in the firewall.
What is a MI Listener machine?
The MI Listener machine works as a router between the following:
1) The agent on the load generator machine and the Controller, enabling the Controller to run Vusers over a firewall.
2) The agent on the Monitor over Firewall machine and the Controller, enabling the Controller to monitor the servers that are located over a firewall.
MI Listener components are installed on a dedicated machine.
How the communication takes place across MI Listener machine in a fire-walled environment?
The MI Listener serves the purpose of a router between the Controller and the LoadRunner agent.
When the LoadRunner agent connects to the MI Listener machine, the MI Listener keeps a listing of the connection to the agent using a symbolic name that the agent passed to it.
When the Controller connects to the MI Listener machine, it communicates to the MI Listener through port 50500.
How many types of online monitors are available for controller machines?
1) Run-Time Monitors: For displaying the number and status of Vusers participating in the scenario, as well as the number and types of errors that the Vusers generate.
2) Transaction Monitors: For displaying the transaction rate and response time during scenario execution.
3) Web Resource Monitors: For providing information about the number of Web connections, throughput volume, HTTP responses, server retries, and pages downloaded to the Web servers during the scenario.
4) System Resource Monitors: For measuring the Windows, UNIX, Tuxedo, SNMP, Antara FlameThrower, and SiteScope resources used during a scenario.
5) Network Delay Monitor: For displaying the information about the network delays on our system.
6) Firewall Monitor: For measuring the statistics of the firewall servers during the scenario.
7) Web Server Resource Monitors: For measuring the statistics of the Apache, Microsoft IIS, iPlanet Web servers during the scenario.
8) Web Application Server Resource Monitors: For measuring the statistics of the Ariba, ATG Dynamo, BroadVision, ColdFusion, Fujitsu INTERSTAGE, iPlanet, Microsoft ASP, Oracle9iAS HTTP, SilverStream, WebLogic and WebSphere application servers during the scenario.
9) Database Server Resource Monitors: For measuring the statistics of the SQL server, Oracle, Sybase, and DB2 databases during the scenario.
10) Streaming Media Monitors: For measuring the statistics of the Windows Media Server and RealPlayer audio/video servers, as well as the RealPlayer and Media Player client during the scenario.
11) ERP/CRM Server Resource Monitors: For measuring the statistics of the SAP Portals, Siebel Servers, and PeopleSoft servers during the scenario.
12) Java Performance Monitor: For measuring the statistics of Java Platforms and Java-based applications using J2EE machines.
13) J2EE & .NET Diagnostics Monitors: For providing information to trace, time, and troubleshoot individual transactions through J2EE & .NET Web, application, and database servers.
14) Application Component Monitor: For measuring the statistics of the Microsoft COM+ server during a scenario run.
15) Application Deployment Solutions Monitor: For measuring the statistics of the Citrix MetaFrame servers during a scenario run.
16) Middleware Performance Monitors: For measuring the statistics of the Tuxedo and IBM Web servers during a scenario run.
17) Infrastructure Resources Monitor: For measuring the statistics of the network client data points during a scenario run.
What is Merging Graphs in LoadRunner?
LoadRunner allows us to merge the results of two graphs from the same scenario into a single graph.
The merging helps us to compare several different measurements at once. For example, we can make a merged graph to display the Web Throughput and Hits per Second, as a function of the elapsed time.
To merge two graphs, the x-axis of both the graphs must be the same measurement.
What situations are best suited for performing path translation?
1) When saving run-time result files to a shared drive which has been mapped differently by the Controller and remote load generator.
2) When the remote machine maps the path as another drive letter or path, path translation is necessary to enable the load generator to recognize the script location.
2) Across platforms - to translate Windows-based paths as seen by the Controller into paths recognized by the UNIX Vuser load generator.
What is the use of Expert mode of Controller module of LoadRunner?
It is basically meant for the support personnel & helps us in getting access to the system information.
When we work in the Expert mode, the Controller dialog boxes contains additional options for fine tuning the Controller operation.
How to check whether a particular problem lies with a scenario or lies with the Vuser script?
1) Verify that the script runs properly on all remote load generators in stand-alone mode.
2) Test the GUI Vuser scripts on Windows platforms using WinRunner.
3) Test the Vuser scripts on UNIX platforms by running them from the command line.
4) Test all other types of Vuser scripts on Windows platforms by running them from VuGen, or by running a single user from the Controller.
What to do when a test passes when run in VuGen, but fails when run in Controller?
When a test runs in VuGen, the full browser is used. However when this test is run in Controller, it use the browser basics only.
Hence before running a scenario in the Controller with multiple Vusers, it is a best practice to run a single Vuser in stand-alone mode to ensure that the test is free from bugs.
What to do when Controller machine fails to connect to the remote load generator machine?
Check the following items:1) Check TCP/IP connectivity: Ensure full TCP/IP connectivity among the Controller and Vuser machines. Use the ping utility from the DOS command line to verify communication with a remote machine.
2) Check Load generator connections: Ensure full connectivity of the load generator with every remote load generators from the Controller’s Load Generators dialog box.
3) Check UNIX shell: For UNIX Vusers, make sure that the Windows Controller can execute a remote shell command.
What is the use of LoadRunner Agent?
LoadRunner Agent runs on the load generators and enables communication between the Controller, load generators, and MI Listeners under fire-walled environment.
The LoadRunner agent receives instructions from the Controller to initialize, run, pause, and stop Vusers. At the same time, the agent also relays data on the status of the Vusers back to the Controller.
How can we increase the load during the Load test?
We can increase the load on the application during a running load test by manually adding more Vusers.
What to do in case of a warning message that Controller cannot activate additional Vusers?
This is a hardware related problem. It happens when we use our local machine having limited memory resources, as a load generator.
Hence it is better to use a dedicated machine as a load generator to avoid such problems.
How to know as to whether my application performed well under the load?
Look at the transaction response time and find out whether the transaction was within an acceptable limit for the customer.
If the transaction response time degrades, we need to look for problems.
When do we use of goal-oriented scenario in LoadRunner?
Prior to deploying an application, we want to run an acceptance test to make sure that the system will withstand the real-life expected workload.
We have an idea about a rate at which we expect the server should perform say in terms of number of hits or transactions per second.
Using a goal-oriented scenario we define a goal for the number of hits per second, transactions per second, or the transaction response time which we want to generate.
How many types of goals are provided by LoadRunner in a goal oriented scenario?
LoadRunner provides following five types of goals in a goal oriented scenario:
1) Number of concurrent Vusers.
2) Number of hits per second.
3) Number of transactions per second.
4) Number of pages per minute.
5) Transaction response time which we want the scenario to reach.
What is the objective of an analysis session after the load test?
The aim of an analysis session is to find out the failures in performance of our system and then to point out the root cause of such failures.
Following questions are asked during the analysis session.
1) Were the test expectations met?
2) What was the transaction response time on the user’s end under load?
3) Did the SLA meet or deviate from its goals?
4) What was the average transaction response time of the transactions?
5) What parts of the system could have contributed to the decline in performance?
6) What was the response time of the network and servers?
7) Can we find a possible cause by correlating the transaction times and backend monitor matrix?
What to do when a script fails during simple playback, while during recording same actions were successful?
Many applications use dynamic values which change every time we use the application. For example, some servers assign a unique session ID for every new session. When we try to replay a recorded session, the application creates a new session ID which happen to differ from the recorded session ID.
LoadRunner addresses this issue through correlation. Correlation saves the changing values, in this case the session ID, to a parameter. When running the emulation, the Vuser does not use the recorded value and instead of it, it uses the new session ID, assigned to it by the server.
How to confirm as to whether the desired content is the same as the returned web page?
This can be done through the content check which verifies that the expected information appears on a Web page while the script is running.
We can insert following two types of content checks:
1) Text check: For checking that a text string appears on a Web page.
2) Image check: For checking an image on a Web page.
What is the use of a Throughput graph?
The Throughput graph shows the amount of data in terms of bytes which the Vusers receive from the server at any given second.
We then compare this graph with the Transaction Response Time graph to see how throughput affects transaction performance.
How to know that the test has finished running?
When the test finishes its run, the Scenario Status pane shows the Down status. This indicates that the Vusers have stopped running.
We can look in the Vuser dialog box to see the status of each individual Vuser.
How can we instruct LoadRunner to randomly run only one Vuser in a group?
This can be done by right-clicking the Vuser group and selecting "Run One Vuser Until Complete".
A Vuser script log will open, displaying the run-time information about the Vuser.
