For QTP Documents visit: www.gcreddy.

com

LoadRunner
Understanding The LoadRunner

To load your client/server system, LoadRunner emulates an

environment where
multiple users work concurrently. While the client/server system is under
load, LoadRunner accurately measures and analyzes the system
performance, and its functionality.

Client/Server Load Testing

Modern client/server architectures are complex. While they provide an

unprecedented degree of power and flexibility, these systems are difficult to
test. Whereas single-user testing focuses primarily on functionality and the
user interface of a single application, client/server testing focuses on
performance and reliability of an entire client/server system.

For example, a typical client/server testing scenario might depict 200

users that login simultaneously to a system on Monday morning: What is the
response time of the system? Does the system crash? To be able to answer
these questions—and more—a complete client/server performance testing
solution must:

 Test a system that combines a variety of software applications and

hardware platforms
 Determine the suitability of a server for any given application
 Test the server before the necessary client software has been
developed
 Emulate an environment where multiple clients interact with a single
server application
 Test a client/server system under the load of tens, hundreds, or even
thousands of potential users

Manual Testing Limitations

Traditional or manual testing methods offer only a partial solution to

load testing. For example, you can test an entire system manually by
constructing an environment where many users work simultaneously on the
system. Each user works at a single machine and submits input to the
system. However, this manual testing method has the following drawbacks:

Testing Tools – LoadRunner

#1#
 For QTP Documents visit: www.gcreddy.com

 It is expensive, requiring large amounts of both personnel and

machinery
 It is complicated, especially coordinating and synchronizing multiple
testers
 It involves a high degree of organization, especially to record and
analyze results meaningfully
 The repeatability of the manual tests is limited

The LoadRunner Solution

The LoadRunner automated solution addresses the drawbacks of

manual performance testing:

 LoadRunner reduces the personnel requirements by replacing human

users with virtual users or Vusers. These Vusers emulate the behavior
of real users—operating real applications.
 Because numerous Vusers can run on a single computer, LoadRunner
also reduces the hardware requirements.
 The LoadRunner Controller allows you to easily and effectively control
all the Vusers—from a single point of control.
 LoadRunner automatically records the performance of the client/server
system during a test. You can choose from a wide variety of graphs
and reports how you want to view the performance data.
 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 you
improve performance.
 Because LoadRunner tests are fully automated, you can easily repeat
them as many times as you need.

Understanding LoadRunner • Introduction Using LoadRunner

Using LoadRunner, you divide your client/server performance testing

requirements into scenarios. A scenario defines the events that 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.
In the scenario, LoadRunner replaces human users with virtual users or
Vusers. When you run a scenario, Vusers emulate the actions of human users
—submitting input to the server. 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.

Testing Tools – LoadRunner

#2#
 For QTP Documents visit: www.gcreddy.com

To emulate conditions of heavy user load, you create a large number

of Vusers that perform a series of tasks. For example, you can observe how a
server behaves when one hundred Vusers simultaneously withdraw cash
from the bank ATMs. To accomplish this, you create 100 Vusers, and each
Vuser:

 Enters an account number into an ATM

 Enters the amount of cash to withdraw
 Withdraws cash from the account
 Checks the balance of the account
 Repeats the process numerous times

The actions that a Vuser performs during the scenario are described in a
Vuser script. When you run a scenario, each Vuser executes a Vuser script.
The Vuser scripts include functions that measure and record the
performance of the server during the scenario. To measure the performance
of the server, you define transactions.

Transactions measure the time that it takes for the server to respond
to tasks submitted by Vusers. For instance, you 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.
You insert rendezvous points into Vuser scripts to emulate heavy user load
on the server.

Rendezvous points instruct multiple Vusers to perform tasks at exactly

the same time. For example, to emulate peak load on the bank server, you
insert a rendezvous point to instruct 100 Vusers to simultaneously deposit
cash into their accounts. You use the LoadRunner Controller to manage and
maintain your scenarios.

Using the Controller, you control all the Vusers in a scenario from a
single workstation. When you execute a scenario, the LoadRunner Controller
distributes each Vuser in the scenario to a host. The host is the machine that
executes the Vuser script, enabling the Vuser to emulate the actions of a
human user. Vuser scripts include functions that measure and record system
performance during load-testing sessions. During a scenario run, you can
monitor the network and server resources. Following a scenario run, you can
view performance analysis data in reports and graphs.

The LoadRunner Testing Process

You can easily create and run load-testing scenarios by following the
LoadRunner testing process below. The following illustration outlines the
testing process:

Testing Tools – LoadRunner

#3#
 For QTP Documents visit: www.gcreddy.com

Step I: Planning the Test

Successful load testing requires that you develop a thorough test plan.
A clearly defined test plan will ensure that the LoadRunner scenarios that
you develop will accomplish your load testing objectives.

Step II: Creating the Vuser scripts

Vusers emulate human users interacting with your client/server

system. A Vuser
script contains the actions that each virtual user performs during scenario
execution.
In each Vuser script you determine the tasks that will be:

 Performed by each Vuser

 Performed simultaneously by multiple Vusers
 Measured as transactions

Step III: Creating the Scenario

A scenario describes the events that occur during a client/server

testing session.

Testing Tools – LoadRunner

#4#
 For QTP Documents visit: www.gcreddy.com

A scenario includes a list of machines that “host” Vusers; a list of Vuser

scripts that the Vusers run; and a list of Vusers that run during the scenario.
You create scenarios using the LoadRunner Controller.

Creating the List of Hosts to Run Vusers

For each scenario, you create a list of hosts—machines configured to

execute Vuser scripts. For each scenario, you create a list of scripts that
Vusers run during scenario execution.

Creating the Vusers

To each Vuser in a scenario, you assign a Vuser script and a host to run
the script.

Step IV: Running the Scenario

You emulate user load on the server by instructing multiple Vusers to

perform tasks simultaneously. You can set the level of load by increasing and
decreasing the number of Vusers that perform tasks at the same time.
Before you run a scenario, you set the scenario configuration. This
determines how all the hosts and Vusers behave when you run the scenario.
You can run the entire scenario, individual Vusers, or groups of Vusers (Vuser
Groups). While a scenario runs, LoadRunner measures and records the
transactions that you defined in each Vuser script.

Step V: Analyzing Test Results

During scenario execution, LoadRunner records the performance of the

client/server system under different loads. You use LoadRunner’s graphs and
reports to analyze the server’s performance.

LoadRunner Vuser Technology

LoadRunner replaces human users with virtual users or Vusers. Vusers

emulate the actions of human users by performing typical business
processes. Each action that a Vuser performs submits input to the
client/server system. By increasing the number of Vusers, you increase the
load on the system. While a workstation accommodates only a single human
user, many Vusers can run concurrently on a single workstation.

To emulate conditions of heavy user load, you create a large number

of Vusers that perform a series of tasks. For example, you can observe how a
server behaves when one hundred Vusers simultaneously withdraw cash
from a bank’s ATMs. Using LoadRunner, you divide your client/server
performance testing requirements into scenarios. A scenario defines the

Testing Tools – LoadRunner

#5#
 For QTP Documents visit: www.gcreddy.com

events that 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.

Developing Vuser Scripts

LoadRunner has a variety of Vuser types, each type suited to a

particular load testing environment. This enables you to use Vusers to
accurately model and emulate real world situations. The actions that a Vuser
performs during the scenario are described in a Vuser script. The Vuser
scripts include functions that measure and record the performance of the
server during the scenario. Each Vuser type requires a particular type of
Vuser script. Creating the Vuser scripts required for a scenario is part of the
LoadRunner testing process.

Developing Vuser Scripts - Looking at Vuser Types

LoadRunner provides a variety of Vuser technologies that enable you

to generate
server load when using different types of client/server architectures. Each
Vuser technology is suited to a particular architecture, and results in a
specific type of Vuser. For example, you use RTE Vusers to operate terminal
emulators; TUXEDO Vusers to emulate TUXEDO clients communicating with a
TUXEDO application server; Web Vusers to emulate users operating Web
browsers. The various Vuser technologies can be used alone or together, to
create effective load testing scenarios.
The following table summarizes the use of the various Vuser types:

Testing Tools – LoadRunner

#6#
 For QTP Documents visit: www.gcreddy.com

GUI Vusers

GUI Vusers operate graphical user interface (GUI) applications. These

applications can run in either the MS Windows or the X Windows
environments. Each GUI Vuser that you develop emulates a real user by
submitting input to, and receiving output from, GUI applications. For
example, a GUI Vuser could operate Microsoft Paint as follows:

1. Select Open from the File menu.

2. Select a graphic file called test.bmp.
3. Click the Open button.
4. Select Flip/Rotate from the Image menu.
5. Click the Flip Horizontal radio button.
6. Click the OK button.
7. Select Save from the File menu.

Testing Tools – LoadRunner

#7#
 For QTP Documents visit: www.gcreddy.com

The operations that a GUI Vuser performs on an application are defined in a

GUI Vuser script. You create GUI Vuser scripts using Mercury Interactive’s
GUI testing tools: WinRunner (for MS Windows applications), and XRunner
and VXRunner (for X Windows applications).

You can run only a single GUI Vuser on a Windows-based host.

However, Mercury Interactive’s Virtual X Server technology allows you to
simultaneously run many GUI Vusers on a single UNIX host.

Database Vusers

Database Vusers generate load on a server by submitting input directly

to the server. Database Vusers do not operate client applications—they
access the server using LoadRunner API functions. These API functions
emulate the input from an actual application.

Testing Tools – LoadRunner

#8#
 For QTP Documents visit: www.gcreddy.com

Because Database Vusers are not reliant on client software, you can use
Database Vusers to test server performance even before the client software
has been developed. Further, because Database Vusers do not have a user
interface, system resources are not used, and you can therefore run large
numbers of Database Vusers on a single workstation.
The following example illustrates the use of Database Vusers: Suppose
that you have a database server that maintains your customer information.
The information is accessed by numerous customer service personnel who
are located throughout the country. The database server receives the
queries, processes the requests, and returns responses to field personnel.
You want to test the response times of the server when numerous service
personnel simultaneously access the server. Using LoadRunner, you could
create several hundred Database Vusers, each Vuser accessing the server
database. The Database Vusers enable you to emulate and measure the
performance of your server under the load of many users. You develop a
Database Vuser script to define the actions of a Database Vuser. A Database
Vuser script includes functions that control the script execution, specify the
input that the Vuser submits to the server, and measure the server
performance.
You develop Database Vuser scripts either by recording with
LoadRunner’s Vuser Script Generator (VuGen) or by using LoadRunner’s
Vuser script templates. For the database server example above, you could
create a Database Vuser script that performs the following actions:

 Connects to the server

 Submits an SQL query
 Retrieves and processes the server response
 Disconnects from the server

Developing Vuser Scripts

The structure and content of a Vuser script differ from one Vuser type
to another.
For example, Database Vuser scripts always have three sections, are written
in a code that resembles C, and include SQL calls to a database server. In
contrast, GUI Vuser scripts have only one section, and are written in TSL (test
script language). The following diagram outlines the process of developing a
Vuser script.

Testing Tools – LoadRunner

#9#
 For QTP Documents visit: www.gcreddy.com

You begin the process of developing a Vuser script by recording a basic

script. LoadRunner provides you with a number of tools for recording Vuser
scripts (see the table below for a list of the tools).

You enhance the basic script by adding control-flow structures, and by

inserting transactions and rendezvous points into the script. You then
configure the run-time settings. The run-time settings include loop, log, and
timing information, and define how the Vuser will behave when it executes
the Vuser script.

To verify that the script runs correctly, you run it in stand-alone mode.
When your script runs correctly, you incorporate it into a LoadRunner
scenario.

Testing Tools – LoadRunner

# 10 #
 For QTP Documents visit: www.gcreddy.com

Working with VuGen – Introducing VuGen

About VuGen

The Vuser Script Generator, also known as VuGen, is LoadRunner’s

primary tool for developing Vuser scripts. VuGen is a Windows-based
application that not only records scripts, but also runs them. Running scripts
from VuGen is useful when debugging. It enables you to emulate how a
Vuser script will run when executed in a LoadRunner scenario from the
Controller.

Note: VuGen records sessions on Windows platforms only. However, a

recorded Vuser script can run on either a Windows or a UNIX platform. When
you record a Vuser script, VuGen generates and inserts various functions into

Testing Tools – LoadRunner

# 11 #
 For QTP Documents visit: www.gcreddy.com

the script. These functions include general Vuser functions and

protocolspecific functions. The general Vuser functions, also known as LR
functions, allow you to obtain information about Vusers running in a
scenario. The protocol-specific functions are specific to the Vuser type. For
example, VuGen inserts LRT functions into a TUXEDO script, and LRS
functions into a Windows Sockets script.

The general Vuser functions and the protocol-specific functions

together form the
LoadRunner API and enable Vusers to communicate directly with a server.

Recording Vuser Scripts with VuGen

You use VuGen to develop a Vuser script by recording a user performing

typical business processes on a client application. VuGen creates the
script by recording the activity between the client and the server. For
example, in database applications, VuGen monitors the client end of the
database and traces all the requests sent to, and received from, the
database server.

Instead of manually creating a Vuser script by programming the

application’s API function calls to the server, you use VuGen to:

 Monitor the communication between the application and the server

 Generate the required function calls
 Insert the generated function calls into a Vuser script

VuGen greatly simplifies the task of creating Vuser scripts by reducing the
need for manual programming. Each Vuser script that you create with VuGen
can communicate directly with a server by executing calls to the server API—
without relying on client software. You can therefore use Vusers to check
server performance even before the user interface of the client software has
been fully developed.

Testing Tools – LoadRunner

# 12 #
 For QTP Documents visit: www.gcreddy.com

In addition, when a Vuser communicates directly with a server, system

resources
are not used on a user interface. This lets you run a large number of Vusers
simultaneously on a single workstation. This in turn allows you to use only a
few testing machines to emulate large server loads.

About Recording with VuGen

VuGen enables you to create a Vuser script by recording actions from

an application. When you run the recorded script, it emulates activity
between the client and server. VuGen eliminates the need to manually
program Vuser scripts. Each Vuser script that you create using VuGen
contains three sections: vuser_init, Actions, and vuser_end. During recording,
you can select the section of the script into which VuGen will insert the
recorded functions.

In general, you record a log in to a server into the vuser_init section;

client activity into the Actions section; and the logoff procedure into the
vuser_end section. While recording, you can insert transactions and
rendezvous points.

Creating a Vuser Script

Before you begin recording, you must create a Vuser script. If you are
recording a Java, Baan, or RTE application, you can also record into an
existing script.

To create a new Vuser script:

 Start VuGen.

Testing Tools – LoadRunner

# 13 #
 For QTP Documents visit: www.gcreddy.com

Select Start > Programs > LoadRunner > Virtual User Generator.
The VuGen window opens.

Recording with VuGen

 Click the New button. The New Virtual User dialog box opens with a list
of the supported Vuser script types.

 Select a Vuser script type and then click OK.

Recording Vuser Scripts

The recording procedure differs slightly between protocols. For Baan

and Java
Vusers. For all other Vusers types, see the section below.

To record for APPC, Database, TUXEDO, or Windows Socket Vusers:

Testing Tools – LoadRunner

# 14 #
 For QTP Documents visit: www.gcreddy.com

 If the Start Recording dialog box is not open, click the Start Recording
button. The Start Recording dialog box opens.

 Specify an application to record. To locate your application, click

Browse to the right of the Program to Record box.

Note that you can add command line parameters to your application by
filling them in manually in the Program to Record box, to the right of the
application name. For example: starts plus32.exe, and connects the user
Peter to the server Neptune.

 Specify a working directory for your application.

 In the Start Recording into Section box, select the section in which you
want to begin recording. The available sections are vuser_init, Actions,
and vuser_end.
 Click OK to begin recording. VuGen starts your application and the
Recording toolbar appears.

Perform typical actions within your application. To switch sections

during recording, use the floating toolbar.

f:\orant\bin\plus32.exe peter@neptune

 After recording typical user actions, select the vuser_end section from
the floating toolbar.

Testing Tools – LoadRunner

# 15 #
 For QTP Documents visit: www.gcreddy.com

 Perform the log off procedure. VuGen records the procedure into the
vuser_end section of the script.
 Click Stop Recording on the Recording toolbar. The main VuGen
window displays all the recorded statements.

 Click Save to save the recorded session. The Save As dialog box opens
(for new Vuser scripts only). Specify a script name.

After recording a script, you can manually edit the script in VuGen’s
main window. VuGen creates a series of configuration, data, and source code
files during recording . These files are used to execute the Vuser actions. You
can display the contents of each of these sections in the main VuGen
window. You can display the contents of only a single section at a time. To
display a section, highlight its name in the Sections box.

Enhancing Vuser Scripts

When you create a Vuser script, you can enhance its capabilities by adding
Vuser functions. For example, you can add debugging code, or functions that
Testing Tools – LoadRunner
# 16 #
 For QTP Documents visit: www.gcreddy.com

retrieve runtime information about the Vusers participating in the scenario.

VuGen helps you generate most of the Vuser functions by recording from
your application—other functions you must manually type into the Vuser
script.
LoadRunner provides several libraries whose functions enhance a
script. You can use general Vuser functions or functions from the library
specific to your application—such as Oracle, CtLib, ODBC, TUXEDO, Web, or
Windows Sockets. In addition, you can enhance your Vuser script with
standard ANSI C functions.

Inserting Transactions

You define transactions to measure the performance of the server.

Each transaction measures the time it takes for the server to respond to
specified Vuser requests. These requests can be simple tasks such as waiting
for a response for a single query, or complex tasks, such as submitting
several queries and generating a report. To measure a transaction, you
insert Vuser functions to mark the beginning and end of a task. Within a
script, you can mark an unlimited number of transactions for analysis, each
with a different name. During scenario execution, the Controller measures
the time that it takes to perform each transaction. After the scenario run,
you analyze the server’s performance per transaction using LoadRunner’s
graphs and reports.

To mark the start of a LoadRunner transaction:

 While recording a Vuser script, click the Start Transaction button on

the Recording toolbar. The Start Transaction dialog box opens.

 Type a transaction name in the Name box. Click OK to accept the

transaction name. LoadRunner inserts an lr_start_transaction
statement into the Vuser script. For example, the following function
indicates the start of the trans1 transaction:
lr_start_transaction(“trans1”);

To mark the end of a transaction:

 While recording a script, click the End Transaction button on the

Recording toolbar. The End Transaction dialog box opens.
Testing Tools – LoadRunner
# 17 #
 For QTP Documents visit: www.gcreddy.com

 Click the arrow for a list of open transactions. Select the transaction to
close. Click OK to accept the transaction name. LoadRunner inserts an
lr_end_transaction statement into the Vuser script. For example, the
following function indicates the end of the trans1 transaction:
lr_end_transaction(“trans1”, LR_AUTO);

Inserting Rendezvous Points

To emulate heavy user load on your client/server system, you

synchronize Vusers to perform a task at exactly the same moment. You
ensure that multiple Vusers act simultaneously by creating a rendezvous
point. When a Vuser arrives at the rendezvous point, it is held by the
Controller until all Vusers participating in the rendezvous arrive. When the
rendezvous conditions are met, the Vusers are released by the Controller.
You designate the meeting place by inserting a rendezvous point into your
Vuser script. When a Vuser executes a script and encounters the rendezvous
point, script execution is paused and the Vuser waits for permission from the
Controller to continue. After the Vuser is released from the rendezvous, it
performs the next task in the script.

To insert a rendezvous point:

 While recording a Vuser script, click the Rendezvous button on the

Recording toolbar. The Rendezvous dialog box opens.

 Type a name for the rendezvous point in the Name box. Click OK to
accept the rendezvous name. VuGen inserts an lr_rendezvous
statement into the Vuser script. For example, the following function
defines a rendezvous point named rendezvous1:
lr_rendezvous(“rendezvous1”);

Testing Tools – LoadRunner

# 18 #
 For QTP Documents visit: www.gcreddy.com

Inserting Comments

VuGen allows you to insert comments between Vuser activities. You

can insert a comment to describe an activity or to provide information about
a specific operation. For example, if you are recording database actions, you
could insert a comment to mark the first query, such as “This is the first
query.”

To insert a comment:

 While recording a script, click the Comment button on the Recording

tool bar. The Insert Comment dialog box opens.

 Type the comment into the text box.

 Click OK to insert the comment and close the dialog box. The text is
placed at the current point in the script, enclosed by comment
markers. The following script segment shows how a comment appears
in a Vuser script:

Note: You can insert comments into your script even after you complete a
recording session, by selecting Insert > Comment from the VuGen menu.
/*
* This is the first query
*/

LoadRunner Controller

To open the Controller:

Select Start > Programs > LoadRunner > Controller.

The Controller window opens with the LoadRunner Controller dialog box
inside.

Testing Tools – LoadRunner

# 19 #
 For QTP Documents visit: www.gcreddy.com

The LoadRunner Controller dialog box includes the following options:

Wizard: Creates a scenario with the aid of the LoadRunner Scenario wizard,
an interactive, step-by-step guide to creating a scenario.
New: Creates a new scenario.
Open an existing scenario: Opens an existing scenario.
Show at Startup: If you do not want this window to appear the next time
you start LoadRunner, clear the “Show at Startup” check box. Once you clear
this checkbox, when you open the Controller, the window layout from the
last time you worked with the Controller appears.

Introducing LoadRunner Controller

The LoadRunner Controller window contains the following elements:

Title bar Displays the name of the scenario on which you are currently
working.
Menu bar Displays the menus from which you select commands.
Tool bar Provides shortcuts for selecting commands. Clicking on a button
executes a command.
Status bar Provides information on the current state of the scenario.
Vuser window Displays a list of all the virtual users that can take part in the
scenario. You also create Vusers using this window.

Testing Tools – LoadRunner

# 20 #
 For QTP Documents visit: www.gcreddy.com

Understanding LoadRunner • The LoadRunner Controller at a Glance

The following five icons appear at the bottom of the Controller window. Click
an icon to display the corresponding window inside the Controller.

Host window Displays the list of machines that can execute Vuser scripts
during the scenario.
Script window Displays a list of all the Vuser scripts that you can assign to
Vusers.
Rendezvous window Displays the Vusers that simultaneously perform
tasks during the scenario.
Output window Displays error and notification messages generated by
Vusers during scenario execution.
Transaction window Displays all the transactions that will be measured
during scenario execution.

Selecting LoadRunner Commands

You select LoadRunner commands from the menu bar or on the

toolbar.

Choosing Commands from a Menu

You select LoadRunner commands from the menus on the menu bar.
Some commands use standard Microsoft Windows shortcut conventions.

Testing Tools – LoadRunner

# 21 #
 For QTP Documents visit: www.gcreddy.com

Choosing Commands from the Toolbar

You can execute many LoadRunner commands by clicking a button on
the toolbar in the LoadRunner Controller.

A scenario describes the events that occur during each load testing
session. A scenario contains lists of hosts, Vusers, Vuser scripts, transactions,
and rendezvous points. You create a scenario using the LoadRunner
Controller. After you create the scenario, LoadRunner saves the information
in a scenario file (. lrs). You use the commands in the File menu to create,
open, save, and close scenario files. Some of these commands are available
from the toolbar.

Creating a New Scenario

The New command creates a completely new scenario. Note that the
New command clears all the information displayed in the Controller windows.
To create a new scenario, choose File > New, or click the New button.
You can also create a new scenario by using the Scenario wizard. The
wizard is an interactive, step-by-step guide to creating a scenario. To create
a new scenario by using the Scenario wizard, select File > Scenario Wizard.

Opening an Existing Scenario

The Open command opens any existing scenario.

To open an existing scenario:

 Choose File > Open, or click the Open button. The File Open dialog box
opens.

Testing Tools – LoadRunner

# 22 #
 For QTP Documents visit: www.gcreddy.com

 Click a file in the File Name list or type a file name in the File Name
box.
 Click OK. The File Open dialog box closes and the scenario appears in
the LoadRunner Controller.

Saving a Scenario

The Save command saves the current scenario.

Closing a Scenario

Closing a scenario closes all the Controller windows. To close the

scenario, choose File > Close. If you made changes to the scenario, a Save
Changes message appears. Choose Yes to save the changes you made. All
open windows and icons in the Controller close.

Filtering and Sorting Information

Each window in the LoadRunner Controller displays information about

the scenario. You can filter and sort the information that appears in each
window. Filtering information displays only those items that meet the
selected criteria. For example, you can filter the Vuser window to display
only those Vusers that are in the READY state. Sorting information displays
all the items in a list in a certain order. For example, you can sort all Vusers
in the Vuser list, in order of their Vuser ID number (1,2,3 etc.).
This section describes how to filter and sort the information displayed in the
Vuser window. Note that you cannot filter or sort the transactions displayed
in the Transaction window.

Testing Tools – LoadRunner

# 23 #
 For QTP Documents visit: www.gcreddy.com

Filtering Information

You use the Filters box to filter the information that appears in a
window. There is a Filters box in the toolbar in each window.

To filter information:

 Click the arrow on the Filters list. The list of available filters appears.

 Click a filter in the list. The information in the window is filtered.

Sorting Information

You use the Sort list to sort the information that appears in a window.
There is a
Sort box in the toolbar in each window.

Create a Scenario

To develop a scenario, you create a host list, a script list and a Vuser
list. This describes how to create a host list—the list of machines, or hosts,
that execute Vuser scripts during a scenario run.

Testing Tools – LoadRunner

# 24 #
 For QTP Documents visit: www.gcreddy.com

Creating a Host List

Hosts are the machines on which Vusers run their scripts. The host list
displays the machines that can run Vusers during scenario execution. You
can add both UNIX and Windows machines to the host list. The Host window
displays the host list and the following information for each host:

 The status of the host

 The platform type of the host (UNIX or Windows)
 Details of the scenario that is currently running

The Host window has its own menu in the Controller menu bar, and a tool
bar that lets you create and manage the host list.

The following procedure outlines how to create a host list for a

scenario:

 Install a LoadRunner remote command launcher on every

machine (except for local host) you want to use as a host.
The remote command launcher is an application that enables the
Controller to invoke applications on the host. For more information
about installing LoadRunner remote command launchers, refer to the
Installing LoadRunner guide.
 Add the names of the hosts to the host list.
 Set attributes for each host (optional).
Host attributes specify the number and type of Vusers that can run on
each host.
For example, you can set the maximum number of DB Vusers a host
can run.
 Select which hosts will take part in the scenario (optional).

Testing Tools – LoadRunner

# 25 #
 For QTP Documents visit: www.gcreddy.com

Each time you run a scenario, some hosts may be unavailable. You can
temporarily remove (disable) hosts from the list.

Creating a Scenario • Creating a Host List

Adding a Host to the Host List

You use the Host window in the LoadRunner Controller to add hosts to the
host list. After you create a host, you can set and modify the attributes for
the new host.

To add a host to the host list:

 Start the LoadRunner Controller and open the Host window. The Host
menu appears in the LoadRunner menu bar.

 Choose Host > Add. The Host Information dialog box opens.

 Type the name of the host in the Name box.

 Click a platform in the Platform list (UNIX or Windows).

Testing Tools – LoadRunner
# 26 #
 For QTP Documents visit: www.gcreddy.com

 By default, LoadRunner stores temporary files on the host during

scenario execution in a temporary directory specified by the host’s
TEMP or TMP environment variables. To override this default for a
specific host, type a location in the Temporary Directory box.

 If the host is UNIX-based, set the login information for the host. By
default, LoadRunner uses your NT user name for the UNIX login. In
other words, if your NT login is lrunner, the Controller will log on to the
host as lrunner. You can also specify to login to the UNIX machine as
another user.

 7 Click OK to close the Host Information dialog box. The host name you
entered appears in the Host window; the host status is set to DOWN.

Modifying Host Attributes

Host attributes determine:

 The maximum number of Vusers that a host runs

 The initialization quota for a host

 The location of the WinRunner configuration file (for GUI Vusers)

 The location of the files during run-time

Setting the Maximum Number of Vusers that a Host Can Run

You can increase or decrease the maximum number of GUI, DB and

RTE Vusers that a host can run. You modify the maximum number according
to the available resources, the needs of your scenario, and your LoadRunner
license agreement.

To set the maximum number of Vusers that a host can run:

 Open the Host window. The Host menu appears in the LoadRunner
menu bar.
 Click a host in the Host window. The host is highlighted.
 Choose Host > Details. The Host Information dialog box opens.

Testing Tools – LoadRunner

# 27 #
 For QTP Documents visit: www.gcreddy.com

 Click the Vuser Types tab.

 In the Maximum Active boxes enter the maximum number of Vusers of

each type that the host can run. The maximum number of active
Vusers that you specify must not exceed the number of Vusers that
you are licensed to run. To check your Vuser licensing limitations,
choose Help > About LoadRunner.

 Click OK to close the Host Information dialog box.

Setting the Initialization Quota

The initialization quota determines how many Vusers a host initializes

at a time. Initializing a large number of Vusers simultaneously places large
stress on a host. To reduce stress on a host, you can initialize smaller
batches of Vusers.

Testing Tools – LoadRunner

# 28 #
 For QTP Documents visit: www.gcreddy.com

To set the initialization quota:

 Open the Host window. The Host menu appears in the LoadRunner
menu bar.
 Click a host in the Host window. The host is highlighted.
 Choose Host > Details. The Host Information dialog box opens.
 Click the Vuser Types tab.
 In the Initialization Quota boxes, enter the maximum number of Vusers
of each type that the host will initialize simultaneously.
 Click OK to close the dialog box.

Setting the Location of the WinRunner Configuration File

A GUI Vuser, running on a Windows-based host, uses WinRunner to

execute its Vuser script. To enable the LoadRunner Controller to open
WinRunner, you specify the location of the appropriate WinRunner
configuration file ( wrun.ini). To specify the location, you can:

 Use the default configuration file for the scenario.

 Specify another configuration file for all Vusers on a certain host—all
the Windows

GUI Vusers running on the specified host will access this file.

To select the location of WinRunner for a GUI Vuser:

 Open the Host window. The Host menu appears in the LoadRunner
menu bar.
 Click a host in the Host window. The host entry is highlighted.
 Choose Host > Details. The Host Information dialog box opens.
 Click the WinRunner tab, and then click one of the following options:

Scenario Default: Instructs the Vuser to use the WinRunner

configuration file specified in the Scenario Configuration dialog box.
Local Configuration File: Instructs the Vuser to use the host’s
WinRunner configuration file.
Path: Instructs the Vuser to use the WinRunner configuration file that
is in a specific location on the network. To specify the path of the
configuration file, click the browse button to the right of the Path box,
and then set the location using the Choose WinRunner Configuration
File dialog box.

 Click OK. The Host Information dialog box closes.

Testing Tools – LoadRunner

# 29 #
 For QTP Documents visit: www.gcreddy.com

Specifying where a Host Saves Files During Run-Time

When a host runs a Vuser script, the Vuser generates results that
describe the execution of the script. By default, these results are saved
temporarily on a local drive of each host—until they are collated by the
Controller to a central location. Alternatively, you can select to save the
results directly to a shared network drive. The way in which the scenario
results are saved is set globally for all the hosts in the scenario, you can
change the way in which individual hosts save their results.

To change how individual hosts save their results:

 Open the Host window. The Host menu appears in the LoadRunner
menu bar.
 Click a host in the Host window. The host entry is highlighted.
 Double-click the host or choose Host > Details. The Host Information
dialog box appears. Ensure that the Runtime File Storage tab is visible.

 To store the scenario results on a shared network drive, click “On a

shared network drive,” and then select the Results check box. This
option overrides the setting for the scenario.
 To store the results temporarily on a hard drive of the host computer,
click “On local host.” The temporary result files will be stored under the
temporary directory specified by the host’s environment variables (on

Testing Tools – LoadRunner

# 30 #
 For QTP Documents visit: www.gcreddy.com

Windows, TEMP or TMP and on UNIX, $TMPDIR or $TMP). This option

overrides the setting for the scenario. These temporary results are
deleted either when the agent goes down or when you run the scenario
again.
 To store the scenario results according to the scenario default, click
“Scenario default”. This is the default setting.
 Click OK to close the dialog box.

Selecting the Hosts for a Scenario

Before you run a scenario, you can select which hosts will run Vusers.
This compensates for the possibility that some hosts will be unavailable. For
example, a machine may already be in use when you want to run the
scenario. You select which hosts will take part in the scenario by using the
Enable and Disable commands. Disabling a host temporarily removes it from
the list. Enabling a host reinstates it.

Disabling Hosts

When you disable a host, the host will not execute Vuser scripts during
a scenario execution.

To disable a host:

 Open the Host window. The Host menu appears in the LoadRunner
menu bar.
 Click a host in the Host window. The host is highlighted.
 Click the Disable button or choose Host > Disable. The host name
changes from black to gray. The host is disabled.

Enabling Hosts

Enabling a host reinstates a previously disabled host.

To enable a host:

 Click a disabled host in the Host window. The host is highlighted.

 Click the Enable button or choose Host > Enable. The host name
changes from gray to black, and the host is enabled.

Creating a Script List

Testing Tools – LoadRunner

# 31 #
 For QTP Documents visit: www.gcreddy.com

To develop a scenario, you create a host list, a script list, and a Vuser
list. This describes how to create a script list—the list of all the Vuser scripts
that Vusers can run during scenario execution.

About Creating a Script List

A Vuser script defines the actions that a Vuser performs during

scenario execution. The script list contains all the Vuser scripts that Vusers
can run. The script list may contain scripts for GUI, DB, and RTE type Vusers.
The Script window, which displays the script list, has its own menu in the
Controller menu bar. The Script window includes the following information for
each script in the list:

 The name of the Vuser script

 The type of Vuser that will run the script
 The location (path) of the script
 Command line options associated with the script

Adding a Script to the Script List

You use the Script window in the LoadRunner Controller to add scripts
to the script list. After you create a script, you can set and modify the details
of the new script.
When you add a script to the script list, ensure that the Controller can
recognize the script’s path. During run time, the Controller sends a copy of
the scripts to the Vuser hosts.

To add a script to the script list:

 Start the LoadRunner Controller and open the Script window. The
Script menu
appears in the LoadRunner menu bar.

Testing Tools – LoadRunner

# 32 #
 For QTP Documents visit: www.gcreddy.com

 Choose Script > Add. The Vuser Script Information dialog box opens.

 Click the browse button to the right of the Path box. The Open dialog
box appears.
 In the “Files of Type” box select the Vuser type, and then select the
path and file name of the new script.
 Click Open to select the files. The Open dialog box closes, and the new
script name and its Vuser type appear in the Vuser Script Information
dialog box.
 In the Command Line box, type any command line options to use when
running the script. For example: -x value -y value

 To see the transactions declared in the selected script, click the

Transaction tab.

Testing Tools – LoadRunner

# 33 #
 For QTP Documents visit: www.gcreddy.com

 To see the rendezvous points declared in the selected script,

click the Rendezvous tab.
 To see the list of Vusers associated with the selected script, click
the Vusers tab. If you have not yet created Vusers, the box will
be empty.
 To see the list of data tables used by selected script and the
global data directory, click the Data Tables tab.
 To see the list of files used by the selected script, click the Files
tab. This list includes all files which make up the Vuser script,
including the configuration settings file, the init, run and end
portions of the script, the parameterization definitions file and
the user file.

 Click OK to close the Vuser Script Information dialog box.

The new script name and its details appear in the Script window.

Modifying Script Details

You can modify the details of a script in the script list using the Vuser
Script Information dialog box.

To modify the details of a script in the script list:

 Start the LoadRunner Controller and open the Script window. The
Script menu appears in the LoadRunner menu bar.
 Click a script in the Script window. The script is highlighted.
 Choose Script > Details. The Vuser Script Information dialog box
opens, displaying the details of the selected script.
 Modify the details as necessary. Note that you cannot modify the
transactions, rendezvous, or Vusers associated with a script.
 Click OK to close the Vuser Script Information dialog box and save the
changes. The modified script details appear in the Script window.

You can customize the way that the Controller executes a Vuser script by
configuring the script’s run-time settings. You can modify these settings
using the LoadRunner Controller by choosing Script > Runtime Settings. You
can also modify the settings using the Vuser Script Generator (VuGen). The
run-time settings can be set in the following areas: Think Time, Iterations,
Log, and Web.

Creating a Vuser List

To develop a scenario, you create a host list, a script list, and a Vuser
list. This describes how to create the Vuser list—the list of all the Vusers that
can run during scenario execution.

Testing Tools – LoadRunner

# 34 #
 For QTP Documents visit: www.gcreddy.com

About Creating the Vuser List

With LoadRunner, you test your client/server system by creating and

running scenarios. A scenario describes the events that occur during a
client/server load testing session. Each scenario contains a list of many
virtual users (Vusers). Vusers emulate human users interacting with your
client/server system. When you run a scenario, the Vusers generate load on
the server, and LoadRunner monitors the server’s performance. For example,
to test a bank server you could create Vusers that deposit and withdraw cash
using automatic teller machines (ATMs). LoadRunner would monitor the bank
server’s performance while varying numbers of customers simultaneously
perform deposit and withdrawal operations.

Creating the Vuser List

You create the Vuser list in the Vuser window. The Vuser window has a
menu in the LoadRunner menu bar, and a tool bar that lets you create and
manage the Vuser list. You can also use the Vuser window to control Vusers
while running a scenario.

The following procedure outlines how to create a Vuser list:

 Create the Vusers.

For each Vuser, you select the script the Vuser runs and a host to run
the script.

 Schedule the Vusers (optional).

You can set scheduling attributes for each Vuser. These attributes
determine the order and time each Vuser runs during scenario
execution.

 Organize the Vusers into Vuser Groups.

You can use Vuser Groups to organize Vusers into manageable groups.
For example, you can create a Vuser Group that contains Vusers of the
same type or that run the same script.

Creating Vusers

You create a Vuser by specifying the Vuser script that the Vuser will
run, and a host to run the script. You can assign the same Vuser script to
many Vusers.

Note: The type of Vuser script that you select determines the type of Vuser
created: selecting a DB Vuser script creates a DB Vuser; selecting a GUI

Testing Tools – LoadRunner

# 35 #
 For QTP Documents visit: www.gcreddy.com

Vuser script creates a GUI Vuser; selecting an RTE Vuser script creates an
RTE Vuser.

To create Vusers:

 Start the LoadRunner Controller, display the Vuser window, and click in
the Vuser side of the window. The Vuser menu appears in the
LoadRunner menu bar.
 Choose Vuser > Add. The Vuser Information dialog box appears.

 In the Quantity box, enter the number of Vusers that you want to
create.
 Select a host in the Host Name list. Select New to open the Host
Information dialog box and add a host to the list.
 Select a script in the Script Name list. To see the rendezvous points
and transactions defined in the Vuser script, click the Script tab. To add
a new script to the list, click New to open the Vuser Script Information
dialog box.
 Click OK to close the Virtual User Information dialog box. The new
Vusers appear in the Vuser window. LoadRunner assigns unique ID
numbers to the Vusers. If you did not create a Vuser Group,
LoadRunner creates the Vuser Group G1 and assigns the Vusers to it.

Testing Tools – LoadRunner

# 36 #
 For QTP Documents visit: www.gcreddy.com

Scheduling Vusers

After you create a Vuser, you can schedule the Vuser by setting:

 The earliest time the Vuser can run

 The amount of time after the scenario has begun that the Vuser will
start running

To schedule a Vuser:

 Open the Vuser window, and click in the Vuser side of the window. The
Vuser menu appears in the LoadRunner menu bar.
 Choose Vuser > Details. The Vuser Information dialog box appears.
 Click the Scheduling tab.

 Set one of the following scheduling options:

 Not Before Time The earliest time the Vuser will run.

Testing Tools – LoadRunner

# 37 #
 For QTP Documents visit: www.gcreddy.com

 With Delay of The amount of time (in minutes) after the

scenario has begun that the Vuser will start running.
 Click OK to close the dialog box.

Creating Vuser Groups

You can use Vuser Groups to organize the Vusers in a scenario into
manageable groups. You create Vuser Groups that contain Vusers with
shared or similar characteristics. For example, you can create a Vuser Group
for all Vusers that run the same Vuser script.

To create a Vuser Group:

 Open the Vuser window. The Vuser menu appears in the LoadRunner
menu bar.
 Click anywhere in the Vuser Group column. The Vuser Group menu
appears in the LoadRunner menu bar.
 Choose Group > Add. The Vuser Group Information dialog box opens.

 In the Name box, enter the name of the Vuser Group and then click OK.
The new Vuser Group appears at the bottom of the Vuser Group list in
the Vuser window.
 In the Command Line box, type any command line options to use when
running the group. For example: -x value -y value

Note: At run time, the Group command line options will be joined together
with any Vuser script command line options. If the Group and the script
specified the same option with different values, then the value defined for
the Group is used.

Testing Tools – LoadRunner

# 38 #
 For QTP Documents visit: www.gcreddy.com

Note: When you renumber Vusers, the Vusers are assigned new ID numbers.
This may conflict with previous results.

To renumber the Vusers within a Vuser Group:

 Select the Vuser Group that you want to renumber.

 Choose Group > Renumber. The Vusers in the selected group are
renumbered from 1.

Scheduling Vuser Groups

After you create a Vuser Group, you can schedule the group by setting:

 The amount of time after the start of the scenario that the group must
wait before it starts running
 The amount of time the group will run

To schedule a Vuser Group:

 Open the Vuser window, and click in the Vuser Group (left) side of the
window. The Group menu appears in the LoadRunner menu bar.
 Choose Group > Details. The Group Information dialog box opens.

 Set one or both of the following scheduling options:

Testing Tools – LoadRunner

# 39 #
 For QTP Documents visit: www.gcreddy.com

 Start Delays the start the Vuser Group when you run a scenario.
You enter the delay time in minutes. Note that if you delay the
start of a specific Vuser (via the Vuser Information dialog box),
the Vuser delay begins only after any Vuser Group delay time
has passed.
 Run for Runs all the Vusers in the Vuser Group for a specified
amount of time from when the Vuser Group started. You enter
the time in minutes.
 Click OK to close the dialog box.

Running the Scenario

You run a scenario in order to check response times of your

client/server system under load. To accurately emulate a real-world
situation, you can use rendezvous points to cause multiple Vusers to perform
tasks at exactly the same time, thereby creating intense user load on the
server. To further improve the way that your scenarios emulate real-world
situations, you can configure some of the scenario execution parameters.
When you run a scenario, LoadRunner generates load on the client/server
system, and measures the system’s performance.

About Running a Scenario

When you run a scenario, the Vusers are assigned to their hosts and
execute their Vuser scripts. During scenario execution, LoadRunner:

 Records the durations of the transactions you defined in the Vuser

scripts
 Performs the rendezvous in the rendezvous list
 Collects error and notification messages generated by the Vusers

You can run an entire scenario unattended, or you can interactively

select the Vuser Groups and Vusers that you want to run. When the scenario
starts running, the Controller first checks the scenario configuration
information. Next, it invokes the applications that you selected to run with
the scenario. Then, it distributes each Vuser script to its designated host.
When the Vusers are ready, they start executing their Vuser scripts. While
the scenario runs, you can pause and stop individual Vuser Groups and
Vusers. The scenario ends when all the Vusers have completed their Vuser
scripts, when the duration runs out, or when you terminate it.

The following procedure outlines how to run a scenario:

 Open an existing scenario or create a new one.

 Configure the scenario.

Testing Tools – LoadRunner

# 40 #
 For QTP Documents visit: www.gcreddy.com

 Set the results directory.

 Run and monitor the scenario.

While the scenario runs, you can pause and stop individual Vuser Groups and
Vusers; monitor each Vuser in the scenario; and view error and notification
messages generated by the Vusers

Running an Entire Scenario

You can run all the Vusers in a scenario, or you can select the specific Vuser
Groups and Vusers that you want to run. This section describes how to run
an entire scenario.

To run an entire scenario:

 Open an existing scenario or create a new one.

 Choose Scenario > Start, or click the Start button. The Controller starts
initializing the Vusers and distributing them to their designated hosts—
where they begin to execute their Vuser scripts. If you have not
specified a results directory for the scenario, the Set Results File dialog
box opens. During scenario execution you can manipulate individual
Vusers and Vuser Groups in the scenario.
 Choose Scenario > Stop, or click the Stop button to terminate the
scenario.

Controlling Individual Vusers and Vuser Groups

You can run an entire scenario as described above, or you can

manipulate individual Vusers in the scenario. This section describes how to
initialize, run, pause, and stop Vusers.

Initializing Vusers

Initializing a Vuser distributes the Vuser to its designated host so that

the Vuser is ready to execute its script.

To initialize a Vuser:

 Select the Vuser Groups or Vusers that you want to initialize.

 Choose Vuser > Initialize or Group > Initialize, or click the Initialize
button. The Vuser’s status changes from DOWN to PENDING to
INITIALIZING to READY. If a Vuser fails to initialize, the Vuser status
changes to ERROR.

Running Vusers

Testing Tools – LoadRunner

# 41 #
 For QTP Documents visit: www.gcreddy.com

Running a Vuser tells the Vuser to execute its script.

To run a Vuser:

 Select the Vuser Groups or Vusers that you want to run.

 Choose Vuser > Run or Group > Run, or click the Run button. The
Vusers execute their scripts. If you run a Vuser in the DOWN or ERROR
state, LoadRunner initializes and then runs the Vuser.

Pausing Vusers

Pausing a Vuser temporarily stops script execution. The Pause

command changes the status of a Vuser from RUNNING to PAUSE.

To pause a Vuser:

 Select the Vuser Groups or Vusers that you want to pause.

 Choose Vuser > Pause, or click the Pause button. The Vusers are
paused.

Stopping Vusers

Stopping a Vuser stops script execution. If you stop a Vuser, the Vuser
still appears in the Vuser list.

To stop a Vuser:

 Select the Vuser Groups or Vusers you want to stop.

 Choose Vuser > Stop, or click the Stop button. The Vusers stop
executing their scripts.

Manually Releasing Vusers from a Rendezvous

While you run a scenario, you can manually release Vusers from a
rendezvous
before the Controller releases them.

To manually release Vusers from a rendezvous:

Testing Tools – LoadRunner

# 42 #
 For QTP Documents visit: www.gcreddy.com

 Open the Rendezvous window. The Rendezvous menu appears in the

LoadRunner menu bar.
 Click a rendezvous in the Rendezvous window.
 Choose Rendezvous > Release, or click the Release button. The Vusers
in the rendezvous are released.

Monitoring Vusers

During scenario execution, you can use the Vuser window to monitor
the actions of all the Vusers in the scenario. This section describes how to
monitor Vusers running on Windows-based and UNIX platforms. In addition to
monitoring UNIX Vusers, you can view the actions that they perform. While a
scenario is running you can monitor the state of each Vuser. The Status field
of each Vuser displays the current state of the Vuser. The following table
describes all possible Vuser states.

Testing Tools – LoadRunner

# 43 #
 For QTP Documents visit: www.gcreddy.com

You can display scenario statistics by expanding the Vuser window.

This allows you to see how many Vusers in each Vuser Group are in the
DOWN, PENDING, INITIALIZING, READY, RUNNING, PAUSED, and
RENDEZVOUS states.

To expand the Vuser window:

 Choose Vuser > Show Group Totals, or click the Show Totals button.

To Hide the scenario statistics:

 Choose Vuser > Hide Group Totals, or click the Hide Totals button.

Viewing Scenario Execution Messages

While the scenario runs, the Vusers and hosts send error and
notification messages to the Controller. You can view these messages in the
Output window. The messages in this window are cleared at the start of
scenario execution.
Testing Tools – LoadRunner
# 44 #
 For QTP Documents visit: www.gcreddy.com

The Output window also displays:

 The time each message arrived

 The type of message sent
 The Vuser’s host
 The ID of the Vuser that sent the message
 The text of the message

To view more details about a Vuser who sent a message:

Highlight a message from a Vuser in the Output window and choose
Output > Vuser Details to see the Vuser information, or choose Output >
Show Vuser Log to see the Vuser’s output log file.

To limit the number of messages that are displayed in the Output

window:
Choose Options > Settings. In the Output tab, select “Limit the number
of output messages to” and specify the number of messages.

To save scenario execution messages:

Choose Output > Export To File, or click the Export button. The Output
messages are saved to a file.

To clear scenario execution messages:

Choose Output > Remove All, or click the Remove All button. The
Output window is cleared of all messages.

Analyzing Test Results, Understanding LoadRunner Analysis

Testing Tools – LoadRunner

# 45 #
 For QTP Documents visit: www.gcreddy.com

After running a scenario, you can use LoadRunner’s graphs and reports
to analyze the performance of your client/server system.

Working with Analysis Reports

In order to view a report, you must generate the report from the
LoadRunner Analysis window. LoadRunner reports are displayed in a Report
Viewer. You can print, save, or export the data using the viewer.

Selecting and Displaying Reports

When you run a scenario, LoadRunner stores the scenario results in the
specified directory. When you run the analysis, LoadRunner processes the
data and formats them into a database. The formatted data is used to
generate reports and graphs. You can instruct LoadRunner to run the
analysis automatically at the end of a scenario by selecting Results > Auto
Load Analysis.

To display reports:

 Select Results > Analyze Results, or click the Analysis button. The
Analysis window opens.
 From the Reports menu choose a report. The report is generated and
displayed. You can display multiple copies of the same report.

The Report Viewer

Each report is displayed in its own report viewer. Each viewer contains
a header
and a toolbar.

Report Header
The header displays general scenario information.

Testing Tools – LoadRunner

# 46 #
 For QTP Documents visit: www.gcreddy.com

The report header contains the following information:

Title: The name of the report.

Scenario: The name of the scenario described in the report.
Result: The pathname of the scenario results directory.
Start time: The time at which the Run Scenario command was executed.
End time: The time at which the scenario script was terminated.
Duration: The total run time of the scenario.

Report Viewer Toolbar

Each report viewer has a toolbar that lets you perform operations on
displayed reports.

The report viewer toolbar contains the following buttons:

Zoom: Toggles between an actual size, full page, and magnified views of the
report.
Print: Prints the displayed report.
Export to file: Exports the displayed information to a disk file.
Export to mail: Mails the displayed information using Microsoft Mail.

Analysing Scenario activity

After running a scenario, you can analyze the Vuser activity that
occurred during the scenario to check that the scenario ran as planned.

Testing Tools – LoadRunner

# 47 #
 For QTP Documents visit: www.gcreddy.com

About Scenario Activity

During scenario execution, Vusers generate data as they perform

transactions. LoadRunner enables you to generate graphs that show scenario
activity or overall scenario performance. Scenario activity graphs and reports
let you track Vuser behavior throughout the scenario. The graphs map the
transactions, rendezvous, and active status of the Vusers, according to the
elapsed scenario time. When working with graphs, you can focus on specific
segments of the scenario using the zoom tools. In addition, you can change
the granularity of the graph.

Running Virtual Users Graph

The Running Virtual User graph displays the number of Vusers that
executed Vuser scripts during each second of a scenario run. Only Vusers in
the RUNNING and RENDEZ states are included in the graph. Vusers in the
LOADING, READY and PAUSE states are not displayed.

This graph is useful for determining the Vuser load on your server at any
given moment. The x-axis represents the elapsed time (in seconds) since the
start of the scenario run. The y-axis represents the number of running Vusers
in the scenario. For example, the above graph indicates that there was a
maximum load of thirty Vusers. Until the 37th second of the scenario run,
Vusers were gradually loading. Thereafter, the number of running Vusers
decreased to twenty, and then to ten.

Rendezvous Graph and Report

The Rendezvous graph indicates when Vusers were released from

rendezvous points, and how many Vusers were released at each point. This

Testing Tools – LoadRunner

# 48 #
 For QTP Documents visit: www.gcreddy.com

graph helps you understand transaction performance times. If you compare

the Rendezvous graph to the Transaction Performance graph, you can see
how the load peak created by a rendezvous influences transaction times.

On the Rendezvous graph, the x-axis indicates the number of seconds

that elapsed since the start of the scenario run. The y-axis indicates the
number of Vusers that were released from the rendezvous. If you set a
rendezvous for 60 Vusers, and the graph indicates that only 20 were
released, you can see that the rendezvous ended when the timeout expired
because all of the Vusers did not arrive. In the above Rendezvous graph, the
first query rendezvous takes place during the 312th second of the scenario,
and 60 Vusers were released. By comparing these results to the Transaction
Performance graph, you see that the peak time for the query transaction
occurred under the load of sixty Vusers, with a response time of 20 seconds.

The Rendezvous report provides additional information about

the rendezvous.

Testing Tools – LoadRunner

# 49 #
 For QTP Documents visit: www.gcreddy.com

Redezvous First arrival time Release time Members Released

Reason

Query_md 11:54:11 11:55:06 50 40

Time out
Query_md 11:55:11 11:55:42 50 10 by
Vuser
Query_md 11:55:43 11:56:01 50 50
OK
Query_md 11:56:19 11:57:21 50 48
Time out

In the above report, the rendezvous policy was set to All Arrived,
requiring all 50 Vusers to arrive at the rendezvous point. In the first
rendezvous, 40 Vusers were released after the timeout period while 10
Vusers were manually released by the operator. In the next rendezvous, all
50 Vusers arrived. In the last rendezvous, two Vusers never arrived, causing
the others to reach the timeout.

Transactions per Second Graph (Passed)

The Transactions per Second (Passed) graph displays the number of
completed, successful transactions performed during each second of a
scenario run. This graph helps you determine the actual transaction load on
your system at any given moment. You can compare this graph to the
Transaction Performance graph in order to analyze the effect of the number
of transactions on the performance time.

Testing Tools – LoadRunner

# 50 #
 For QTP Documents visit: www.gcreddy.com

The x-axis represents the elapsed time (in seconds) since the start of
the scenario run. The y-axis represents the number of transactions
successfully performed during the scenario run. For example, the above
graphs indicate that in the 224th second of the scenario, nine query
transactions were successfully completed. The response time at that point
was 49 seconds.

Failed Transactions Graph and Report

The Transactions per Second (Failed) graph displays the number of

completed, unsuccessful transactions performed during each second of the
scenario run. This graph contains information about transactions that were
assigned an LR_FAIL value in the lr_end_transaction statement.

Note: The lr_end_transaction statement must be executed in order to

generate the Failed Transaction graph. If your program aborts immediately
upon an error, all current transactions are terminated—no data is generated
for failed transactions.

The following example uses a Web Vuser script. Web Vuser statements
return zero for success and a positive value for failure. The Web Vuser script

Testing Tools – LoadRunner

# 51 #
 For QTP Documents visit: www.gcreddy.com

below tries to access an HTML page using a GET statement. If the GET
request succeeds, the script assigns the LR_PASS status to the transaction. If
the GET request fails, the script assigns LR_FAIL to the transaction. On the
Transactions per Second (Failed) graph, the x-axis represents the elapsed
time (in seconds) since the start of the scenario run. The y-axis represents
the number of transactions unsuccessfully performed during the scenario.

lr_start_transaction(“wizard”);
if (URL("http://www.wizard.com/index.html") == 0)
lr_end_transaction(“wizard”, LR_PASS);
else {
lr_end_transaction(“wizard”, LR_FAIL);
lr_log_message("Wizard home page not returned");
}

For example, the above graph indicates that in the 33rd second of the
scenario, nine insert_row transactions failed. The Failed Transaction report
provides detailed information about the beginning, end, and duration of the
failed, yet completed transaction.

Testing Tools – LoadRunner

# 52 #
 For QTP Documents visit: www.gcreddy.com

Failed Vuser Report

The Failed Vuser report provides details about all Vusers that were in
the ERROR, ABORTED, or DONE:FAILED states during the scenario execution.
The Ready At and Running At times are relative to the computer’s system
clock.

In this scenario, one Vuser failed, two had errors, and three were
aborted.

Scenario Execution Report

The Scenario Execution report details the major events that occurred
during the scenario run. This includes information on every Vuser, such as
when it was ready to run and for how long it ran.

Testing Tools – LoadRunner

# 53 #
 For QTP Documents visit: www.gcreddy.com

The Ready At and Running At times are based on the computer’s

system clock.
The Termination Status field indicates the status of the Vuser at the end of
the scenario run (PASSED, FAILED, ERROR, or ABORTED). At the end of the
Group information, there is a summary of the Group’s activities.

Scenario Performance Analysis

After running a scenario, you can create graphs and reports to help
you locate
bottlenecks and analyze overall Vuser performance. You can determine if the
transaction response time was adequate, and how your system handled a
load of many users.

About Scenario Performance

During scenario execution, Vusers generate data as they perform their

transactions. LoadRunner allows you to generate graphs that show scenario
activity or overall scenario performance. Scenario performance graphs and
reports let you analyze Vuser behavior throughout the scenario. The
Performance graphs map the transaction response time, and other general
information about the scenario.
When working with graphs, you can focus on specific segments of the
scenario using the zoom tools. In addition, you can change the granularity of

Testing Tools – LoadRunner

# 54 #
 For QTP Documents visit: www.gcreddy.com

the graph. When working with reports, you can export the data in ASCII
format or in a custom format for common spreadsheet applications.

Percentile Graph

The Percentile graph analyzes the percentage of transactions that

were performed within a given time range. This graph helps you determine
the percentage of transactions that met the performance criteria defined for
your system. In many instances, you need to determine the percent of
transactions with an acceptable response time. The maximum response time
may be exceptionally long, but if most transactions have acceptable
response times, the overall system is suitable for your needs.

The x-axis represents the percentage of the total number of transactions

measured during the scenario run. The y-axis represents the time taken to
perform the transactions.
In the above example, a system administrator determines that 2
seconds is an acceptable time for a particular transaction. If 95 percent of
the transactions are 2 seconds or less, the current configuration is suitable. If
more than five percent of the transactions have a response time greater
than fifteen, the configuration must be optimized. In the above graph, 95
percent of the report transactions were performed in 2 seconds or less.
Compare the Percentile graph to a graph indicating average response
time such as the Transaction Performance Summary graph. A high response
time for several transactions may raise the overall average. However, if the
transactions with a high response time occurred fewer than five percent of
the times, that factor may be insignificant.

Performance Under Load Graph

Testing Tools – LoadRunner

# 55 #
 For QTP Documents visit: www.gcreddy.com

The Performance Under Load graph indicates transaction times relative

to the number of Vusers running at any given point during the scenario. This
graph helps you view the general impact of Vuser load on performance time
and is most useful when analyzing a scenario with a gradual load. You can
create a gradual load using the scheduling options in the Vuser information
box.

The x-axis indicates the number of running Vusers, and the y-axis
indicates average transaction time in seconds. In the above graph, the
execution time for the top_sales transaction increases with the number of
running Vusers. For twenty running Vusers, the response time for the
transaction was 3.5 seconds.

Analyzing Scenario Performance

The Performance Under Load Graph indicates transaction times

relative to the number of Vusers running at any given point during the
scenario. In order for this graph to be meaningful, the performance is
calculated when there is a stable load (constant number of running Vusers)
for at least five seconds (by default). If the Vuser load is not stable for at
least five seconds, the transaction time is not calculated and the graph will
indicate zero.
For example, a scenario with a load of 50 to 70 Vusers had an average
performance of 10 seconds, but its graph displayed zero. This occurred
because the Vusers did not stabilize for five seconds. You can instruct
LoadRunner to measure transaction time for shorter periods of steady load.

To change the Performance Under Load interval:

Testing Tools – LoadRunner

# 56 #
 For QTP Documents visit: www.gcreddy.com

 Choose Options > Performance Under Load Interval in the Analysis

window.

 Enter the desired interval.

 Click OK to accept the settings.
 Regenerate the Performance Under Load graph.

The Performance Under Load report provides the same information as

the graph
for each transaction in table form.

Transaction Performance Graph

The Transaction Performance graph displays the average time taken to

perform
transactions during each second of the scenario run. The x-axis represents
the elapsed time (in seconds) since the start of the scenario run. The y-axis
represents the average time (in seconds) taken to perform each transaction.
You can compare the Transaction Performance graph to the Running Virtual
Users graph to see how the number of running Vusers affects the transaction
performance time.
If you have defined acceptable minimum and maximum transaction
performance
times, you can use this graph to determine whether the performance of the
server is within the acceptable range.

Testing Tools – LoadRunner

# 57 #
 For QTP Documents visit: www.gcreddy.com

For instance, the graph above shows the transaction performance

times for two
transactions. You can see that each time the transaction was executed,
performance time decreased. If you compare this graph to the Running
Virtual Users graph, you can see that the performance time improved
because the Vuser load decreased.
Note that the transaction times are only indicated by the peaks in the
graph. When running multiple Vusers, one transaction may begin before the
previous one ends, resulting in a continuous line. The line does not indicate
the actual start and end times of transactions; it is only a mechanism used
by the graph to join the peaks. The Transaction Performance graph may be
displayed using different granularities. The y-axis represents the average
transaction response time within the granularity interval. For example, for a
granularity of 1, the y-axis shows the average response time for each one
second period of the scenario. For a granularity of 2, the y-axis shows the
average response time for every two second period of the scenario. In the

Testing Tools – LoadRunner

# 58 #
 For QTP Documents visit: www.gcreddy.com

graphs below, the same scenario results are displayed in a granularity of 2,

5, and 10 (from top to bottom). The lower the granularity, the more detailed
the results. However, it may be useful to view the results with a higher
granularity to study the overall Vuser behavior throughout the scenario. For
example, using a low granularity as in the upper graph, you see the intervals
when no transactions were performed. By viewing the same graph with a
higher granularity, you can easily see that the overall transaction response
time averaged 3.5 seconds.

Transaction Performance Summary Graph and Report

The Transaction Performance Summary graph displays the minimum,

maximum
and average performance time for all the transactions in the scenario.

Testing Tools – LoadRunner

# 59 #
 For QTP Documents visit: www.gcreddy.com

The x-axis specifies the name of the transaction. The y-axis shows the
time, rounded off to the nearest second, taken to perform each transaction.
For example, the above graph displays the statistics of the query
transaction. The transaction was performed in a minimum time of 24
seconds, an average time of 36 seconds, and a maximum time of 42
seconds.
The report shows similar information in table form. The information in
the table is not rounded off to the nearest second, as it is in the graph.

Transaction Performance by Vuser Graph and Report

The Transaction Performance Summary by Vuser graph displays the

time taken by an individual Vuser to perform transactions during the
scenario. The minimum, maximum, and average times are plotted for each
transaction performed by the Vuser. This graph is useful when you have
different types of Vusers in a scenario, and you want to characterize
performance for each type.

Testing Tools – LoadRunner

# 60 #
 For QTP Documents visit: www.gcreddy.com

The x-axis specifies the name of the Vuser and the Group to which it
belongs. The y-axis shows the time, in seconds, it takes to perform each
transaction. For example, the above graph displays transaction processing
times for the Vusers in the group15. Vuser two performed the query
transaction in a minimum of 25 seconds, an average of 32 seconds, and a
maximum of 40 seconds.

The Performance Summary by Vuser report shows similar information

for each
Vuser in table format.

Transaction Distribution Graph

The Transaction Distribution graph displays the distribution of the time
taken to
perform a transaction. The transaction response times are divided into five
bars. Each bar shows how many times the transaction was completed within
a given time range. If you compare it to the Transaction Performance
Summary graph, you can see how the average performance was calculated.
Note that this graph only displays information for a single transaction.

Testing Tools – LoadRunner

# 61 #
 For QTP Documents visit: www.gcreddy.com

The x-axis represents the time range, in seconds, to perform the

selected transaction. The y-axis represents the number of transactions
executed during the scenario.
For example, the above graph indicates that the performance time for
52 query
transactions was between 38.44 and 41.99 seconds.

Detailed Vuser Report

Testing Tools – LoadRunner
# 62 #
 For QTP Documents visit: www.gcreddy.com

The Detailed Vuser report is a list of all transactions executed by each

Vuser during a scenario. The report lists the start and end times, the
duration, and status of each transaction.

The Start time and the End time in this report refer to the system time
at the beginning and end of a transaction. The Result field contains the final
transaction status, either Pass or Fail.

Testing Tools – LoadRunner

# 63 #