1

/
19

LoadRunner (Controller Module) Interview Questions 43
Q. 1: What is the purpose of using HP - LoadRunner?
In real world scenario, it is not possible to create situation involving say one thousand
users using a
system simultaneously so as to test the behavior. of the system under such stressful
conditions.
LoadRunner can create such a situation.

LoadRunner artificially simulates several thousand users - which are called Virtual Users These artificial.
/ Digitally created users are simultaneously forced to operate on the same task, thereby
loading the
system in a way it is expected to be loaded by real human users in actual practice.
With LoadRunner we can simulate situation with hundreds or thousands of artificial users
& we can
impose definite, consistent and repeatable loads on the system thereby stressing it from
end-to-end.
This way we can emulate several business processes & production conditions, which a
deployed
application is going to encounter.
LoadRunner accurately measures, monitors, and analyzes a
system's performance and functionality.


Q. 2: What are the essential capabilities we look in a typical application performance-testing
Tool?
Essential capabilities of an application performance testing tool are that:

1) It must be able to test a system which combines many software applications and hardware platforms.
2) It must be able to determine the suitability of a server for any given application.
3) It must be able to test the server before the necessary client software has been
developed.
4) It must be able to emulate an environment where multiple clients interact with a
single server
application.
5) It must be able to test an application under the load of tens, hundreds, or even thousands of potential
users.

Q. 3: What are the drawbacks of manual load testing processes?
Load testing of a complete system can be done manually by building an environment where many users
work simultaneously on the system. Each user is made to work on his standalone
machine and every
individual submits input to the system. However due to complexity of such a system,
following
drawbacks are there
1) Manual testing methods offer only a partial solution to the load testing.
2) Manual testing is expensive & requires large amounts of manpower & equipment.
3) Manual testing is complicated, especially while coordinating and synchronizing
multiple testers.
4) Manual testing involves a high degree of organization, especially to record and analyze
results
meaningfully.
5) The repeatability of the manual tests is limited.

Q. 4: How LoadRunner takes care of the shortcomings of manual performance
testing?
1) LoadRunner reduces manpower requirements by replacing human users with virtual users or Vusers.
These Vusers emulate the behavior. Of real users operating real applications.
2) Since several Vusers can run on a single computer, LoadRunner reduces the amount of
hardware
required for testing.
3) LoadRunner Controller allows us to easily and effectively control all the Vusers from a single point of
control.
4) LoadRunner monitors the application performance online, enabling us to fine-tune the system during
test execution.
5) LoadRunner automatically records the performance of the application during a test. We
can choose
from a wide variety of graphs and reports to view the performance data.
6) LoadRunner checks where performance delays occur: network or client delays, CPU performance, I / O
delays, database locking, or other issues at the database server. LoadRunner monitors the network and
server resources to help us improve performance.
7) Because LoadRunner tests are fully automated, we can easily repeat them as often as
we need.

Q. 5: What are the process elements of using LoadRunner?
Process elements of LoadRunner are:
1) Scenario:
Before using LoadRunner, we divide the application performance testing requirements
into various scenarios. A scenario defines the events which occur during each testing session. Thus, for
example, a scenario defines and controls the number of users to emulate, the actions that they perform,
and the machines on which they run their emulations.
2) Vusers:
In the scenario, LoadRunner replaces human users with virtual users or Vusers. When we
run a scenario, Vusers emulate the actions of human users working with our application.
While a
workstation accommodates only a single human user, many Vusers can run concurrently
on a single
workstation. In fact, a scenario can contain tens, hundreds, or even thousands of
Vusers.
2014 Engineer exam preparation materials in various industries and Zhenti Collection
Safety Engineer Electrical Engineer property management division registered
valuer registered chemical engineer

2
/
19

3) Vuser Scripts:
The actions that a Vuser performs during the scenario are described in a Vuser script.
When we run a scenario, each Vuser executes a Vuser script. The Vuser scripts include
functions that
measure and record the performance of our application's components.


3) Vuser Scripts:
The actions that a Vuser performs during the scenario are described in a Vuser script.
When we run a scenario, each Vuser executes a Vuser script. The Vuser scripts include
functions that
measure and record the performance of our application's components.

4) Transactions:
To measure the performance of the server, we define transactions. A transaction
represents an action or a set of actions that we are interested in measuring. 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 that 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.
5) Rendezvous points:
We insert rendezvous points into Vuser scripts to emulate heavy user load on
the server. Rendezvous points instruct Vusers to wait during test execution for multiple Vusers to arrive
at a certain point, so that they may simultaneously perform. a task. For example, to emulate peak load
on the bank server, we can insert a rendezvous point instructing 100 Vusers to deposit cash
into their
accounts at the same time.
6) Controller:
We use the LoadRunner Controller to manage and maintain our scenarios. Using the
Controller, we control all the Vusers in a scenario from a single workstation.
7) Load Generator:
When we execute a scenario, the Controller distributes each Vuser in the scenario
to a load generator. The load generator is the machine that executes the Vuser script,
enabling the
Vuser to emulate the actions of a human user.
8) Performance analysis:
Vuser scripts include functions that measure and record system
performance during load-testing sessions. During a scenario run, we can monitor the
network and
server resources. Following a scenario run, we can view performance analysis data in
reports and
graphs.

Q. 6: What are our expectations from a scenario load testing an application
Server?
The scenario would define the following actions which would be required to be performed on the server
during the load test.
1) Emulating the conditions of controlled load on the server.
2) Emulating the conditions of maximum load on the server.
3) Measuring the server performance under load.
4) Check where performance delays occur: network or client delays, CPU performance, I
/ O delays,
database locking, or other issues at the server.
5) Monitoring the network and server resources under load.

Q. 7: What is the role of Remote Agent Dispatcher in LoadRunner?
The role of Remote Agent Dispatcher is to enable the Controller to start applications on
the load
generator.

Q. 8: What is the role of LoadRunner Agent?
1) LoadRunner Agent enables the Controller and the load generator to communicate with
each other.

2) When we run a scenario, the Controller instructs the Remote Agent Dispatcher to
launch the
LoadRunner agent.

3) The agent receives instructions from the Controller to initialize, run, pause, and stop
Vusers.

4) The agent relays data on the status of the Vusers back to the Controller.

Q. 9: What type of actions a Vuser can perform during database server
testing.?
. A Vuser script can perform following actions while testing a database server.:
1) Logging in to the Web application.
2) Connecting to the database server.
3) Submitting an SQL query.
4) Retrieving and processing the server response.
5) Disconnecting from the server and the Web.

Q. 10: What are the broad steps involved in testing process by LoadRunner?
LoadRunner follows a Six
-
step process for testing the application under the load:
Step - 1:
Planning the Test: Involves development of a thorough test plan for the success of the
load
testing effort.
Step - 2:
Creating the Vuser Scripts: Vusers emulate human users interacting with our application
A.
Vuser script. Contains the actions which each Vuser performs during scenario execution.
Step - 3:
Creating the Scenario: A scenario describes the events that occur during a testing session A.
scenario includes a list of machines on which Vusers run, a list of scripts that the Vusers
run, and a
specified number of Vusers or Vuser groups that run during the scenario. We can create scenarios using
the Controller.

3
/
19

Step - 4:
Running the Scenario: User load is emulated on the server by instructing multiple Vusers to
perform. tasks simultaneously. We can set the level of load by increasing and decreasing the number of
Vusers that perform. Tasks at the same time.
Step - 5:
Monitoring a Scenario: This can be done by executing scenario monitoring with the help
of
LoadRunner's set of many resources.
Step - 6:
Analyzing Test Results: During scenario execution, LoadRunner records the performance
of
the application under different loads. We can use LoadRunner's graphs and reports to
analyze the
application's performance.

Q. 11: What are the benefits of a test plan for a successful load testing?
A well-defined test plan is the first essential step to successful testing.

Planning of load testing helps us in:
1) Building test scenarios which accurately emulate our working environment. Load
testing means
testing our application under typical working conditions, and checking for system
performance,
reliability, capacity, and so forth.
2) Understanding as to which resources are required for testing. Application testing requires hardware,
software, and human resources. Before we begin testing, we need to know which
resources are
available and decide how to use them effectively.
3) Defining success criteria in measurable terms. Focused testing goals and test criteria
ensure
successful testing. For example, it's not enough to define vague objective
s like "Check server response
time under heavy load. "A more focused success criterion would be" Check that 100
customers can
check their account balance simultaneously, and that the server response time will not
exceed one
minute. "
Q. 12: What are the elements of Load Test Planning Process using LoadRunner?
Load test planning is a three-step process:
Step -1:
Analyzing the Application: Involves becoming thoroughly familiar with the hardware and
software components, the system configuration, and the typical usage model. This step
ensures that
the testing environment created by us will accurately reflect the environment and
configuration of the
application under test.
Step -2:
Defining Testing Objectives: Before starting the testing process, we need to define
exactly
what we want to achieve.
Step -3:
Planning LoadRunner Implementation: Involves decision making on how to use LoadRunner to
achieve our testing goals.

Q. 13: What factors do we consider while planning the system configuration
before its load
testing?
We describe the configuration of every system component like client machines, network,
middleware,
and servers in ample detail giving answers to the following:
1) How many users are anticipated to connect to the system?
2) What is the configuration of application client machine. Configuration includes
information on
hardware, memory, operating system, software, development tool etc.?
3) What types of database and Web servers are used with the information of hardware, database type,
operating system, file server etc.?
4) How does the server communicate with the application client?
5) What is the middleware configuration and application server between the front-end
client and
back-end server?
6) What other network components are used like modems etc. which may affect response
time?
7) What is the throughput of the communications devices & How many concurrent users can each device
handle?

Q. 14: What factors do we consider regarding system usage while planning the load testing?
1) Consideration as to how the system is typically used, and decide which functions are
important to
test.

2) Consideration as to who uses the system, what are the number of each type of user and what are the
common tasks performed by each user.
3) Consideration of any background load which might affect the system response time.
For example, say 500 persons log on to the accounting system every morning, and the
same office
network has a constant background load of 100 users performing various word processing and printing
tasks. We would create a LoadRunner scenario with 600 virtual users signing in to the
accounting
database, and check the server response time.

Q. 15: What are the broad objectives before planning load testing?
Before starting testing, we need to define our objectives precisely as to what we want to
achieve.
Broad application testing objectives for load testing with LoadRunner can be:
1) Measuring end-user response time:
To know how long does it take to complete a business
process?

4
/
19

2) Defining optimal hardware configuration:
To know which hardware configuration provides the
best performance?
3) Checking reliability:
To know how hard or long can the system work without errors or failures?
4) Checking hardware or software upgrades:
To know how does the upgrade affect performance or
reliability?
5) Evaluating new products:
To know which server hardware or software should we choose?
6) Measuring system capacity:
To know how much load can the system handle without significant
performance degradation?
7) Identifying problem areas:
To know which element is slowing down the response time?

Q. 16: Load Testing is applicable during which stages of product life cycle?
Load testing is necessary throughout the product life cycle.
Load Testing activities performed during various stages of product life cycle
are:
1) During Planning and Design stage:
Evaluation of new products & measurement of response time
of every activity.
2) During Product Development stage:
Measurement of response time of every activity, checking of
optimum hardware configuration, checking of hardware and software upgrades and
checking of
reliability.
3) During Product Deployment stage:
Checking of reliability, measurement of response time of
every activity and measurement of system capacity.
4) During Production stage:
Measurement of response time of every activity and Identification of
various problem areas.
5) During Evolution stage:
Checking of hardware and software upgrades and measurement of
system capacity.

Q. 17: At which points we use LoadRunner to measure the response time in our
application?
Following type of response times are measured to decide as to where to run the Vusers
and which
Vusers to run, according to our predefined test objectives:
1) Measurement of end-to-end response time:
We can measure the response time which a user
experiences by running a GUI Vuser at the front end. GUI Vusers emulate real users by submitting input
to and receiving output from the client application.
We can run GUI Vusers at the front end to measure the response time across the entire
network,
including a terminal emulator or GUI front end, network, and server.
2) Measurement of network and server response times:
We can measure network and server
response time, excluding response time of the GUI front end, by running Vusers on the client machine.
Vusers emulate client calls to the server without the user interface. When we run many Vusers from the
client machine, we can measure how the load affects network and server response time.
3) Measurement of GUI response time:
We can find out as to how the client application interface
affects response time by calculating the difference among the previous two
measurements ie

GUI response time = (End-to-end response time) - (Network and server response time)
4) Measurement of server response time:
We can measure the time it takes for the server to
respond to a request without going across the network. When we run Vusers on a
machine directly
connected to the server, we can measure the server performance.
5) Measurement of middleware-to-server response time:
We can measure response time from
the server to middleware if we have access to the middleware and its API. We can create Vusers with the
middleware API and measure the middleware-server performance.

Q. 18: What are the broad basis for creating Vuser scripts?
Since Vusers emulate the actions of a typical enduser, the Vuser scripts are created with a consideration
of end-user tasks.

Vuser scripts are created based on the following:
1) Analysis of Vuser types:
For finding out the number and type of Vusers expected to be created.
2) Activities expected to be performed by the Vusers:
For example, for load testing a banking
application, we would create a Vuser script. which performs typical banking related
activities.
3) Test objectives:
Form. The basis of taking decision on tasks to be measured and defining their
transactions.

Q. 19: What factors do we consider while selecting hardware for using
LoadRunner?
For running the desired number of Vusers the hardware and Operating system must be
adequately
powerful and fast.
Following factors are given due consideration while deciding the number of
machines and
their configuration:
1) Make a provision of running LoadRunner Controller on a separate machine.
2) Make a provision of a separate Windows-based machine for every GUI Vuser. However
one UNIX
machine can take care of running of several GUI Vusers.

5
/
19

3) Keep the configuration of GUI Vusers testing machine same like the actual user's
machine.


Q. 20: How LoadRunner can be helpful in checking the reliability of a hardware
system?
LoadRunner can provide good pointers to decision making in following areas pertaining to
hardware:
1) Finding out the level of system stability under heavy or continuous work loads, by creating stress on
the system.
2) Testing the system by forcing it to handle the extended activity in a compressed time
period to
simulate the kind of activity a system would normally experience over a period of weeks
or months.
Q. 21: How do we measure the system capacity?
We measure system capacity to find out how much excess capacity the system can handle without any
degradation in its performance.

For checking the capacity of a system, we compare the performance versus load on the existing system,
and find out a point at which significant degradation of response-time starts taking place. Point is known
as "knee" when plotted over a response time curve.

Q. 22: What is the purpose of creating Scenarios in LoadRunner?
For testing a system by using LoadRunner, we need to create a scenario. Scenario is a
file containing
complete information about the testing session. The scenario is a means of emulating a
real-life user.

The scenario contains following information about the mechanism of emulating
the real
users:
1) Details of groups of virtual users or Vusers.
2) Details of test scripts the Vusers will run.
3) Details of load generators upon which the scripts shall be made to run.

Q. 23: How many types of scenarios can be created while using Controller of
LoadRunner?
We can create any one type of scenario out of the following:
1) Manual Scenario:
Scenario is created manually by defining the number of Vuser groups we want to
run, and building a schedule for LoadRunner to run these groups. Manual scenario can be
created by
defining the total number of Vusers to be used in the scenario, or assigning a percentage
of the total
number of Vusers to each script.
2) Goal-Oriented Scenario:
We define the goals that we want to achieve in our test and LoadRunner
automatically builds a scenario for us, based upon our goals.

Q. 24: How can we change the maximum number of scripts displayed in the Available Scripts
list?
We can change the maximum number of scripts displayed in the Available Scripts list by modifying
the
registry key:
HKEY_CURRENT_USER \ Software \ Mercury Interactive \ RecentScripts \
max_num_of_scripts

Q. 25: What is the purpose of Scenario Files?
A scenario provides detailed description of various events taking place during every load
testing
session.

A scenario is created by using the Design view of Controller in LoadRunner. Once a scenario is created,
LoadRunner saves the information in a
scenario file having an extension (* .lrs).


Q. 26: What methods are available in LoadRunner for building scenarios?
Two methods are available through which we can create scenarios.
1) Manual Scenario creation method:
Involves creating groups and specifying the script, the load
generator, and the number of Vusers included in each group. We can chose to opt for using Percentage
Mode to distribute our Vusers among various scripts.

2) Goal Oriented Scenario creation method:
Involves defining the goals we want our test to
achieve, and LoadRunner automatically builds a scenario for us, based on these goals.

Q. 27: How can we change the maximum number of scripts displayed in the Available Scripts
list?
We can change the maximum number of scripts displayed in the Available Scripts list by modifying
the
registry key:
HKEY_CURRENT_USER \ Software \ Mercury Interactive \ RecentScripts \
max_num_of_scripts

Q. 28: What is the purpose of having Vuser groups in scenarios?
A scenario consists of groups of Vusers which simulate the actions of human users on the
application
under test. When a particular scenario is run, the Vusers generate load on the server, and LoadRunner
monitors the server and transaction performance ..
Vuser groups are created to organize several Vusers in a scenario into manageable
groups. Vuser
groups are created by including Vusers having similar characteristics. For example, when many
Vusers
run the same Vuser script, we can club them into one Vuser group.

Q. 29: What type of actions can be performed on a Vuser group or scenario?
Following actions can be performed on a Vuser group:
1) Defining the group name, Vuser quantity, load generators, and scripts for the Vuser
group.
2) Adding load generators to the Vuser group and configuring the load generators.
3) Adding and configuring scripts to the Vuser group.
4) Enabling or disabling a Vuser group for the scenario.
5) Removing a Vuser group from the scenario.
6) Scheduling the Vuser group execution.
7) Defining service level agreements for the scenario.
8) Running, stopping & resetting the scenario.
9) Configuring the settings of scenario results.

Q. 30: What is the meaning of pending status for a Vuser?
Pending status for a V user indicates that the Vuser is ready to be initialized and is
waiting for an
available load generator, or is transferring files to the load generator. The Vuser will run
when the
conditions set in its scheduling attributes are met.
Q. 31: What is the meaning of rendezvous status for a Vuser?
Rendezvous status for a Vuser indicates that the Vuser has arrived at the rendezvous and is waiting
to
be released by LoadRunner.

Q. 32: What is the purpose of Gradual Stop option for the Vusers?
Gradual Stop option Instructs the Controller to complete the current iteration or action before stopping
the Vuser. This option is only available when the Vuser is in the RUN state.

Q. 33: How do we modify the run-time settings of multiple scripts?
We need to chose the method of modifying the run-time settings:
1) Modification method for Shared run-time settings:
This method opens one window containing
all of the run-time settings in blank mode. In this mode, we set only the options that we want to modify
for all selected scripts. All other run-time settings remain unchanged.
Some of the run-time settings can not be modified in shared mode. These settings do not
appear. To
modify them, we need to open the run-time settings for each individual script.
2) Modification method for Individual run-time settings:
This method opens a separate window
for each selected script. In this mode, we modify each script's settings individually.


Q. 34: What configuration settings we can define for Load Generators in a
scenario?
With th
e help of Load Generators dialog box, we can set following type of load generator's
attributes:

1) Defining which load generators will run Vusers in the scenario. For example, if a load
generator is
unavailable for a particular scenario run, we can exclude it temporarily instead of
removing it entirely
from your list of load generators.
2) Selecting which load generators will take part in the scenario by using the Enable and
Disable
commands. Disabling a load generator temporarily removes it from the list. Enabling a load
generator
reinstates it.

Q. 35: What is the role of controller in LoadRunner?
The Controller monitors a Windows load generator's CPU usage and automatically stops loading Vusers
on a load generator when it becomes overloaded.

We can monit
or the status of a machine's CPU usage. When the CPU usage of a load generator becomes
problematic, the icon to the left of the load generator name contains a yellow bar. When
the machine
becomes overloaded, the icon contains a red bar.

Q. 36: What are the Terminal Services in LoadRunner?
Terminal services allows centralized management of computing resources for each client
connected to
the server, and provides each user with their own working environment.
We use LoadRunner's Terminal Services Manager to r
emotely manage multiple load generators running
in our load testing scenario on a terminal server. With the help of Terminal Services
Manager, we can
select the number of terminals to be used in our scenario & the maximum number of Vusers which can
be run per terminal. The Terminal Services Manager then evenly distributes the number of virtual users
among the client sessions.
With the help of Terminal Server Client, we can operate in a server-based computing environment from
a remote machine. The terminal server transmits applications over the network and displays
them via

7
/
19

terminal emulation software. Every user logs on and sees only his individual session, which is managed
transparently by the server operating system, independent of any other client session.

Q. 37: What is the use of Creating a Manual Scenario Using the Percentage
Mode?
A manual scenario is created in the Percentage mode by defining the total number of Vusers to be used
in the scenario, and assigning load generators and a percentage of the total number of Vusers to
each
script.
While creating a new scenario, we can access the Percentage Mode directly by selecting
the "Use the
Percentage Mode to distribute the Vusers among the scripts "in the New Scenario dialog
box.
A scenario created in the Vuser Group Mode can be easily converted to the Percentage
Mode.

Q. 38: What are the key considerations while converting a scenario from Vuser
Group Mode
to Percentage Mode?
1) In case we have defined multiple scripts for a Vuser group, the number of Vuser scripts created in the
Percentage Mode will be same as the number of scripts defined for the group.
2) All Load Generators will be assigned to all Vuser scripts created in the Percentage Mode. In case
we
have defined multiple load generators for a Vuser group, the Vusers we assign to the
scripts in the
Percentage Mode will be distributed evenly among the load generators previously assigned by us to the
group.
3) All Vuser group schedule settings will be lost. All profiles will contain scenario schedule settings only.

Q. 39: What are the key considerations while converting a scenario from Percentage Mode to
Vuser Group Mode?
1) Each script. Will be converted to a Vuser group.
2) In case we have defined multiple load generators for a Vuser script, the Vuser group which is created
when converting the scenario will also contain multiple load generators.
3) All schedule settings will be retained as it is.

Q. 40: What is the purpose of Scheduling Scenarios?
After creating a scenario, we schedule it to start running at a specified time. We can make
a schedule
defining the time at which to initialize, start, and stop Vusers during the scenario run, and how long an
action should continue running.
We can restrict the execution duration of the scenario or of a Vuser group within the scenario.
We can
also stipulate how many Vusers to start and stop running within a certain time frame. We
can specify
whether LoadRunner should start or stop running all Vusers in a scenario simultaneously,
or only a
certain number of Vusers within a specified amount of time.
Q. 41: What is the effect of Rendezvous points on the running of scenarios as per
schedule?
Rendezvous points, if present in a script, interfere with the scheduled scenario run. The scenario will not
run as scheduled due to the presence of rendezvous points in the script.

Q. 42: What are the methods by which we can schedule the enabled Vuser
groups in a
scenario?
After creating a scenario, we can schedule the enabled Vuser groups to run according to
either of the
following:
1) As a part of a whole scenario:
When we run a scenario, LoadRunner runs all the Vuser groups
enabled in the scenario. The schedule defined for running the scenario is applied to all the Vuser groups
concurrently, and LoadRunner applies each action proportionately to all the Vusers
groups.
2) As per its own schedule:
For each enabled Vuser group in a scenario, we can design a separate
execution schedule. We can specify when to start running the Vuser group, how many
Vusers to start
and stop running within given time intervals, and how long the Vuser group should
continue running.

Q. 43: How many modes are available to us for scheduling the running of
scenario?
We can schedule a scenario to run in one of the following modes:
1) Real-life schedule:
The scenario runs according to a user-defined group of actions that simulate a
real-life schedule of events. Vuser groups run according to the iterations defined in their
run-time
settings, but w