Docstoc

LoadRunner tutorial

Document Sample
LoadRunner tutorial Powered By Docstoc
					           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:

    It is expensive, requiring large amounts of both personnel and machinery
    It is complicated, especially coordinating and synchronizing multiple testers

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

    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.

       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


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

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

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

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.

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 the script. These functions

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

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.

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




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




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:

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



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




    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 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.


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

      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”);

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.”

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


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).
     Each time you run a scenario, some hosts may be unavailable. You can
     temporarily remove (disable) hosts from the list.


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

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.

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.

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

    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.

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


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

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


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


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

       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



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

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.
          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.


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

    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.

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.

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


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




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




    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.

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




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

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.
          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.




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

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.

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.




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

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:
          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

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

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.
      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

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

     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

      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.




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

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:

    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
                                                                                # 42 #
          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.




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

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.




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.



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

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

      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.




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

Report Header
      The header displays general scenario information.




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.



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

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.

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.




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

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




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

The Rendezvous report provides additional information about the rendezvous.

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
                                                                                   # 49 #
           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 224 th 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 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");
}




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




       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.




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.



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




      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.




       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.




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

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




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

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

      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.


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

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:

    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.




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

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.




       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.

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

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




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


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.




        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
                                                                                 # 58 #
           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
                                                                                 # 59 #
          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.




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

Detailed Vuser Report

       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
                                                                                   # 61 #

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:1879
posted:3/20/2010
language:English
pages:61
Description: LoadRunner tutorial for performance testers. It is a step by step guide for loadrunner