Q.
1: What is the purpose of using HP - Load Runner?
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. Load Runner can create such a situation.
Load Runner 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 Load Runner 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.
Load Runner 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 ther
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 Load Runner takes care of the shortcomings of manual performance
testing?
1) Load Runner 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.
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.
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.
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 objectives 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?
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 i.e.
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.
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_USERSoftwareMercury
InteractiveRecentScriptsmax_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_USERSoftwareMercury
InteractiveRecentScriptsmax_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 cannot 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 the 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 monitor 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 remotely 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 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 we can define how many Vusers to run at
a time, how long Vusers should continue to run, and how many Vusers to stop
running at a time.
2) Classic Schedule: All
enabled Vuser groups run together on one schedule, each according to its own
run-time settings. We can schedule how many Vusers to start running at a time,
how long to run the Vusers, and how many Vusers to stop running at a time.
3) Run until complete: All
the Vuser groups in the scenario run according to the iterations defined in
their run-time settings. Each Vuser group in the scenario runs its defined
course, and when all the Vuser groups have finished running, the scenario run
is complete.
Q.
44: What is the purpose of specifying Service Level Agreements in scenarios?
While creating a load
testing scenario, we can specify our goals or service level agreements - SLA's
for the performance measurement.
When this scenario is made
to run the LoadRunner captures all the performance related data. During
analysis phase, Analysis compares this data against the SLAs and determines SLA
status for the defined measurements.
Q.
45: What methods LoadRunner uses to find out the SLA status?
Depending on the
measurements being evaluated by us, LoadRunner finds out the SLA status in one
of the following ways:
1) As per time interval
within the run: Analysis displays SLA statuses at set time intervals in the
timeline. For example, every 10 seconds - Analysis checks to see if the
measurement’s performance has deviated from the threshold defined in the SLA.
2) As per the whole run:
Analysis displays a single SLA status for the whole scenario run. The
measurements include - Total Hits, Average Hits, Total Throughput, and Average
Throughput.
Q.
46: How many types of Goal Oriented Scenarios can be created in LoadRunner?
In a goal-oriented scenario,
we define the goals required to be achieved through our tests, and LoadRunner
automatically builds a scenario for us based on these goals.
When we want to test how
many Vusers the application can run simultaneously, it is better to define a
type of goal for the Virtual Users.
Following five types of
goals can be defined in a goal-oriented scenario:
1) Defined number of virtual
users
2) Defined number of hits
per second by the Web Vusers.
3) Defined number of
transactions per second.
4) Defined number of pages
per minute by the Web Vusers.
5) Defined transaction
response time we want our scenario to reach.
Q.
47: Under what circumstances a Pages per Minute or Hits per Second
goal-oriented scenario fails?
Pages per Minute or Hits per
Second goal-oriented scenario is assigned a "Failed" status in
situations like:
1) When the Controller has
twice attempted to reach the goal using the maximum number of Vusers specified,
and the goal could not be reached.
2) When no pages per minute
or hits or transactions per second were registered after the first batch of
Vusers was run.
3) When the number of pages
per minute or hits or transactions per second did not increase after the
Controller ran a certain number of Vuser batches.
4) When all the Vusers that
were run failed.
5) When there were no
available load generators for the type of Vusers we attempted to run.
Q.
48: What is Load Balancing process in LoadRunner?
Load balancing is the
process, which evenly distributes the load generated by Vusers among the
requested load generators, thereby ensuring an accurate load test.
When a Windows load
generator’s CPU usage becomes overloaded, the Controller stops loading Vusers
on the overloaded load generator, and automatically distributes them among load
generators taking part in the scenario.
Load balancing option is
available only in goal-oriented scenarios and manually controlled scenarios in
the Percentage Mode.
Q.
49: What policy attributes can be defined for rendezvous points?
Setting the rendezvous
policy determines how the Vusers handle a rendezvous point. We can set the
following policy attributes for every rendezvous point:
1) Release policy: Defines
how many Vusers will be released from a rendezvous point at a time.
2) Timeout policy: Defines
how long the Controller shall wait before releasing Vusers from a rendezvous
point.
Q.
50: Can we disable a particular Vusers at Rendezvous Points?
We can disable a rendezvous
point for all Vusers in a scenario.
In addition to this we can
disable a rendezvous point for a particular Vusers.
By disabling Vusers at a
rendezvous point, we temporarily exclude them from participating in the
rendezvous. Enabling disabled Vusers returns them back to the rendezvous.
51:
What type of status related Rendezvous Information is available to us during
creation of a scenario?
Following Rendezvous
Information is available to us for viewing & necessary modifications:
1) Current Status: The
number of Vusers that arrived at the rendezvous point out of the total number
of Vusers assigned to the rendezvous.
2) Time: The time at which
the Vusers at the rendezvous point were released.
3) Reason: The reason the
Vusers at the rendezvous point were released. The possible reasons are Timeout
or Arrived.
Q.
52: Out of Individual Load Generator settings & Global Settings, which ones
come into effect?
When the global scenario
settings differ from those of an individual load generator, the load generator
settings override them.
Q.
53: What is the use of LoadRunner Expert mode?
We can configure additional
settings for the LoadRunner agent and other LoadRunner components with the help
of LoadRunner Expert mode.
Q.
54: How LoadRunner takes care of timeout value requirements in case of large
number of Vusers?
LoadRunner automatically
understands the fact that the number of active Vusers has a significant effect
on the timeout values.
For example, 1000 Vusers
trying to initialize will take much longer than 10 Vusers. Taking care of this,
LoadRunner automatically adds an internal value, based on the number of active
Vusers, to the timeout value specified by us.
Q.
55: While running a scenario, the run-time files are stored at which location
by default?
While we run a scenario, by
default the run-time files get stored locally on each load generator machine
running the Vuser script.
The default location of the
files is under the temporary directory specified by the load generator’s
environment variables like Windows - TEMP or TMP Directory.
If no environment variable
is defined, the files get saved to the /tmp directory.
Q. 56: What are the various
types of Primary Run-time files?
Primary run-time files are
of following types:
1) Vuser Script files: When
we run a Vuser, the Controller sends a copy of the associated Vuser script to
the Vuser load generator. These script files are stored in the load generator’s
temporary run-time directory.
2) Result files: While we
run a scenario, the participating Vusers write their results to the temporary
run-time file directory. After scenario execution, these result files are
consolidated and the results from all the load generators are transferred to
the results directory.
Q.
57: How transfer of script files takes place at run time in case Vusers access
the scripts at some shared location?
If we specify that all
Vusers access their Vuser scripts directly at some shared location, no transfer
of script files take place at run time.
Q.
58: What is Path translation in LoadRunner
Path translation is a
mechanism used by LoadRunner to convert remote path names. We need to do path
translation, when we specify a shared network drive for run-time file storage.
Q.
59: What preparatory steps are recommended for running a scenario?
Before running a scenario
following are suggested steps:
1) Specify the location of
the results.
2) Assign a name to the
results.
3) Scheduling of the
scenario.
4) Providing scenario
summary information.
5) Specification of
applications to be invoked at the start of the scenario.
Q.
60: What is the extension of scenario result file?
The general information
about the scenario are stored in a result file with an extension (.eve and
.lrr)
Q.
61: 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.
Q.
62: 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.
Q.
63: 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.
Q.
64: 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.
Q.
65: 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.
Q.
66: 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.
Q.
67: 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.
Q.
68: 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.
Q.
69: 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.
Q.
70: 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.
.
71: 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.
Q.
72: 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.
Q.
73: 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.
Q.
74: 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.
Q.
75: 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.
Q.
76: 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.
Q.
77: 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.
Q.
78: 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.
Q.
79: 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.
Q.
80: 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.
Q.
81: 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.
Q.
82: 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 Webservers during
a scenario run.
17) Infrastructure Resources
Monitor: For measuring the statistics of the network client data points during
a scenario run.
Q.
83: 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.
Q. 84: 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.
Q.
85: 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.
Q.
86: 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.
Q. 87: 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.
Q. 88: 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.
Q.
89: 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.
Q.
90: 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.
91:
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.
Q.
92: 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.
Q.
93: 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.
Q.
94: 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.
<<<<<<
=================== >>>>>>
Q.
95: 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?
Q.
96: 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.
Q.
97: 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.
Q.
98: 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.
Q.
99: 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.
Q.
100: 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.
No comments:
Post a Comment