Load Runner

Training

© Xavient Information Systems

This document contains the confidential and proprietary information of Xavient
Information Systems, the disclosure of which would provide a competitive
advantage to others. As a result, no part of this document should be disclosed,
used, duplicated, reproduced, stored, copied, or transmitted, in whole or in part, in
any form or means, electronic, mechanical, photocopying or otherwise without the
express consent of Xavient Information Systems. This document shall remain the
property of Xavient Information Systems.
This restriction does not limit the rights of the recipient to use information
contained within the document if it is rightfully obtained from the source without
restriction. The data subject to this restriction are contained in the entire document

Xavient Information Systems

2125 C Madera Road; Simi Valley, C.A 93065.
Main Line: 1.805.955.4111, Fax Line: 1.805.955.4144 Visit us: www.xavient.com

1|Page
Version Summary

Version No. Prepared By Reviewed By Approved By Release Date

1.0 Syed Faeez Sultan Vandana Negi

2|Page
Contents
What is testing.............................................................................................................................................5
Software testing is divided into two categories:..........................................................................................6
Functional testing:...............................................................................................................................6
Non Functional Testing:.......................................................................................................................7
Performance Testing...................................................................................................................................8
Performance testing can serve different purposes..............................................................................8
Why Do Performance Testing?....................................................................................................................9
Performance Testing Sub-Genres......................................................................................................10
Performance Testing Approach.................................................................................................................12
Terminologies............................................................................................................................................15
Throughput:-......................................................................................................................................15
Latency:-............................................................................................................................................15
Concurrent User:-..............................................................................................................................15
State Full:-..........................................................................................................................................15
State Less:-.........................................................................................................................................15
Cookies:-............................................................................................................................................15
Persistent Cookie:-.............................................................................................................................16
Non Persistent Cookie:-.....................................................................................................................16
Cache:-...............................................................................................................................................16
Paging: -.............................................................................................................................................16
Response Time:-................................................................................................................................17
Dead Lock:-........................................................................................................................................17
Multithreading:-................................................................................................................................18
Process:-............................................................................................................................................18
Client Server Architecture.........................................................................................................................19
Two tier architecture.........................................................................................................................19

3|Page
 Three tier architecture.......................................................................................................................20
LOAD RUNNER...........................................................................................................................................22
Components of Load Runner.............................................................................................................23
Lab Setup:..................................................................................................................................................25
Scripting.....................................................................................................................................................26
Recording Option...............................................................................................................................26
Customization of Script......................................................................................................................31
Parameterization...............................................................................................................................31
Correlation:........................................................................................................................................34
Runtime settings................................................................................................................................36
Debug Function.........................................................................................................................................47
lr_set_debug_message.......................................................................................................................51
Controller..................................................................................................................................................53
Controller Functionality.....................................................................................................................53
Types of Scenarios.............................................................................................................................54
Vuser Groups.....................................................................................................................................54
Adding Vuser Group..........................................................................................................................55
Analysis......................................................................................................................................................57
Creating Analysis Session...................................................................................................................57
How to Collate the Results................................................................................................................59
Analysis Graphs.................................................................................................................................59
Adding New Graph............................................................................................................................60

4|Page
What is testing
It is the process used to help identify the correctness, completeness, security,
and quality of developed computer software. Testing is a process of technical
investigation, performed on behalf of stakeholders, that is intended to reveal
quality-related information about the product with respect to the context in which it
is intended to operate. This includes, but is not limited to, the process of executing a
program or application with the intent of finding errors. Quality is not an absolute;
it is value to some person. With that in mind, testing can never completely establish
the correctness of arbitrary computer software; testing furnishes a criticism or
comparison that compares the state and behavior of the product against a
specification. An important point is that software testing should be distinguished
from the separate discipline of Software Quality Assurance (SQA), which
encompasses all business process areas, not just testing.

5|Page
Software testing is divided into two
categories:
 Functional Testing
 Non Functional Testing

Functional testing:
Functional testing is testing the application against business requirements. It is
done using the functional specifications provided by the client or by using the design
specifications like use cases provided by the design team.

Functional Testing covers:

 Unit Testing
 Smoke testing / Sanity testing
 Integration Testing (Top Down, Bottom up Testing)
 Interface & Usability Testing
 System Testing
 Regression Testing
 Pre User Acceptance Testing(Alpha & Beta)
 User Acceptance Testing
 White Box & Black Box Testing
 Globalization & Localization Testing

Non Functional Testing:

In contrast to functional testing, which establishes the correct operation of the
software (correct in that it matches the expected behavior defined in the design
requirements), non-functional testing verifies that the software functions properly even
when it receives invalid or unexpected inputs. Software fault injection, in the form of
fuzzing, is an example of non-functional testing.
The non functional aspect of software components involves things or criteria
which judges the operation of the system, rather than specific behavior.

Non-Functional Testing covers:

6|Page
  Load and Performance Testing
 Ergonomics Testing
 Stress & Volume Testing
 Compatibility & Migration Testing
 Data Conversion Testing
 Security / Penetration Testing
 Operational Readiness Testing
 Installation Testing
 Security Testing (Application Security, Network Security, System Security)

7|Page
Performance Testing
Performance testing is type of Non functional testing. It is used to determine the
speed or effectiveness of a computer, network, software program or device. This
process can involve quantitative tests done in a lab, such as measuring the response
time or the number of MIPS (millions of instructions per second) at which a system
functions. Performance testing is often done in conjunction with stress testing.

Performance testing can serve different purposes

 It can demonstrate that the system meets performance criteria.
 It can compare two systems to find which performs better.
 Or it can measure what parts of the system or workload causes the system
to perform badly.

8|Page
 Why Do Performance Testing?
At the highest level, performance testing is almost always conducted to address
one or more risks related to expense, opportunity costs, continuity, and/or corporate
reputation. Some more specific reasons for conducting performance testing include:

 Assessing release readiness by:

 Enabling you to predict or estimate the performance characteristics of an
application in production and evaluate whether or not to address
performance concerns based on those predictions. These predictions are
also valuable to the stakeholders who make decisions about whether an
application is ready for release or capable of handling future growth, or
whether it requires a performance improvement/hardware upgrade prior
to release.
 Providing data indicating the likelihood of user dissatisfaction with the
performance characteristics of the system.
 Providing data to aid in the prediction of revenue losses or damaged
brand credibility due to scalability or stability issues, or due to users being
dissatisfied with application response time.
 Assessing infrastructure adequacy by:
 Evaluating the adequacy of current capacity.
 Determining the acceptability of stability.
 Determining the capacity of the application’s infrastructure, as well as
determining the future resources required to deliver acceptable
application performance.
 Comparing different system configurations to determine which works
best for both the application and the business.
 Verifying that the application exhibits the desired performance
characteristics, within budgeted resource utilization constraints.
 Assessing adequacy of developed software performance by:
 Determining the application’s desired performance characteristics before
and after changes to the software.
 Providing comparisons between the application’s current and desired
performance characteristics.
 Improving the efficiency of performance tuning by:
 Analyzing the behavior of the application at various load levels.
 Identifying bottlenecks in the application.
 Providing information related to the speed, scalability, and stability of a
product prior to production release, thus enabling you to make informed
decisions about whether and when to tune the system.

9|Page
Performance Testing Sub-Genres

Load Testing
Load testing is the simplest form of performance testing. A load test is usually
conducted to understand the behavior of the application under a specific expected load.
This load can be the expected concurrent number of users on the application
performing a specific number of transactions within the set duration. This test will give
out the response times of all the important business critical transactions. If the database,
application server, etc. are also monitored, then this simple test can itself point towards
any bottlenecks in the application software.

Stress Testing
Stress testing is normally used to understand the upper limits of capacity within
the application landscape. This kind of test is done to determine the application's
robustness in terms of extreme load and helps application administrators to determine
if the application will perform sufficiently if the current load goes well above the
expected maximum.

Endurance Testing (Soak Testing)

Endurance testing is usually done to determine if the application can sustain the
continuous expected load. During endurance tests, memory utilization is monitored to
detect potential leaks. Also important, but often overlooked is performance
degradation. That is, to ensure that the throughput and/or response times after some
long period of sustained activity are as good as or better than at the beginning of the
test.

Spike Testing
Spike testing, as the name suggests is done by spiking the number of users and
understanding the behavior of the application; whether performance will suffer, the
application will fail, or it will be able to handle dramatic changes in load.

Configuration Testing
Configuration testing is another variation on traditional performance testing.
Rather than testing for performance from the perspective of load you are testing the
effects of configuration changes in the application landscape on application
performance and behavior. A common example would be experimenting with different
methods of load-balancing.

10 | P a g e
Isolation Testing
Isolation testing is not unique to performance testing but a term used to describe
repeating a test execution that resulted in an application problem. Often used to isolate
and confirm the fault domain.

11 | P a g e
 Performance Testing Approach

The performance testing approach:

1. Activity 1. Identify the Test Environment.  Identify the physical test

environment and the production environment as well as the tools and resources
available to the test team. The physical environment includes hardware, software, and
network configurations. Having a thorough understanding of the entire test
environment at the outset enables more efficient test design and planning and helps
you identify testing challenges early in the project. In some situations, this process must
be revisited periodically throughout the project’s life cycle.
2. Activity 2. Identify Performance Acceptance Criteria.  Identify the response
time, throughput, and resource utilization goals and constraints. In general, response
time is a user concern, throughput is a business concern, and resource utilization is a
system concern. Additionally, identify project success criteria that may not be captured

12 | P a g e
 by those goals and constraints; for example, using performance tests to evaluate what
combination of configuration settings will result in the most desirable performance
characteristics.
3. Activity 3. Plan and Design Tests.  Identify key scenarios, determine variability
among representative users and how to simulate that variability, define test data, and
establish metrics to be collected. Consolidate this information into one or more models
of system usage to be implemented, executed, and analyzed.   
4. Activity 4. Configure the Test Environment.  Prepare the test environment,
tools, and resources necessary to execute each strategy as features and components
become available for test. Ensure that the test environment is instrumented for resource
monitoring as necessary.
5. Activity 5. Implement the Test Design.  Develop the performance tests in
accordance with the test design.
6. Activity 6. Execute the Test.  Run and monitor your tests. Validate the tests, test
data, and results collection. Execute validated tests for analysis while monitoring the
test and the test environment.
7. Activity 7. Analyze Results, Report, and Retest.  Consolidate and share results
data. Analyze the data both individually and as a cross-functional team. Reprioritize the
remaining tests and re-execute them as needed. When all of the metric values are within
accepted limits, none of the set thresholds have been violated, and all of the desired
information has been collected, you have finished testing that particular scenario on
that particular configuration.

13 | P a g e
Terminologies
Throughput:-
Throughput or network throughput is the average rate of successful message
delivery over a communication channel. This data may be delivered over a physical or
logical link, or pass through a certain network node. The throughput is usually
measured in bits per second (bit/s or bps), and sometimes in data packets per second or
data packets per time slot. The system throughput or aggregate throughput is the sum
of the data rates that are delivered to all terminals in a network.

Latency:-
In general, the period of time that one component in a system is spinning its
wheels waiting for another component. Latency, therefore, is wasted time. For example,
in accessing data on a disk, latency is defined as the time it takes to position the proper
sector under the read/write head.

Concurrent User:-
It’s that when a number of users try to Access a Particular Action at one Time. A
computer operating system that allows several users to access a resource on the
computer at the same time is a multiuser multitasking operating system, historically
called a time-sharing operating system. The capacity of a system can also be measured
in terms of maximum concurrent users, at which point system performance begins to
degrade noticeably.

State Full:-
State full means that some device is keeping track of another device or a
connection, either temporarily or over a long period of time. A state full connection is
one in which some information about a connection between two systems is retained for
future use.

State Less:-
Previous access methods do not maintain a session between the server and the
database.

Cookies:-
A cookie, also known as a web cookie, browser cookie, and HTTP cookie, is a
piece of text stored on a user's computer by their web browser. A cookie can be used for
authentication, storing site preferences, shopping cart contents, the identifier for a

14 | P a g e
server-based session, or anything else that can be accomplished through storing text
data. A cookie consists of one or more name-value pairs containing bits of information,
which may be encrypted for information privacy and data security purposes. The
cookie is sent as a field in the header of the HTTP response by a web server to a web
browser and then sent back unchanged by the browser each time it accesses that server.
Cookies may be set by the server with or without an expiration date. Cookies without
an expiration date exist until the browser terminates, while cookies with an expiration
date may be stored by the browser until the expiration date passes. Users may also
manually delete cookies in order to save space or to address privacy issues.

Persistent Cookie:-
These cookies are stored in Hard disk. If a Persistent Cookie has Max-age Set to 1
year, then within a Year, the initial value Set in that Cookie would be sent back to
Server Every time, User is Visiting the server.

Non Persistent Cookie:-

These Cookies are Stored in Web Browser. A session Cookie Will Expire if a User closes
the Browser or if a User Haven’t visited the server for Certain Period of Time.

Cache:-
It’s is a component that transparently stores data so that future requests for that
data can be served faster. The data that is stored within a cache might be values that
have been computed earlier or duplicates of original values that are stored elsewhere. If
requested data is contained in the cache (cache hit), this request can be served by simply
reading the cache, which is comparatively faster. Otherwise (cache misses), the data has
to be recomputed or fetched from its original storage location, which is comparatively
slower. Hence, the more requests can be served from the cache the faster the overall
system performance is. To be cost efficient and to enable an efficient use of data, caches
are relatively small. Nevertheless, caches have proven themselves in many areas of
computing because access patterns in typical computer applications have locality of
reference. References exhibit temporal locality if data is requested again that has been
recently requested already. References exhibit spatial locality if data is requested that is
physically stored close to data that has been requested already.

Paging: -
Paging is one of the memory-management schemes by which a computer can
store and retrieve data from secondary storage for use in main memory. In the paging
memory-management scheme, the operating system retrieves data from secondary
storage in same-size blocks called pages. The main advantage of paging is that it allows
the physical address space of a process to be noncontiguous. Before the time paging was
used, systems had to fit whole programs into storage contiguously, which caused

15 | P a g e
various storage and fragmentation problems. Paging is an important part of virtual
memory implementation in most contemporary general-purpose operating systems,
allowing them to use disk storage for data that does not fit into physical random-access
memory (RAM).

Response Time:-
In real-time systems the response time of a task or thread is defined as the time
elapsed between the dispatch (time when task is ready to execute) to the time when it
finishes its job (one dispatch).

Dead Lock:-
Deadlock is a common problem in multiprocessing where many processes share
a specific type of mutually exclusive resource known as a software lock or soft lock.
Computers intended for the time-sharing and/or real-time markets are often equipped
with a hardware lock (or hard lock) which guarantees exclusive access to processes,
forcing serialized access. Deadlocks are particularly troubling because there is no
general solution to avoid (soft) deadlocks.

Example:-
This situation may be likened to two people who are drawing diagrams, with
only one pencil and one ruler between them. If one person takes the pencil and the
other takes the ruler, a deadlock occurs when the person with the pencil needs the ruler
and the person with the ruler needs the pencil to finish his work with the ruler. Neither
request can be satisfied, so a deadlock occurs.

Connection Pooling
Connection pooling is maintaining a pool of connection which will allow us to
resume the connection without creating a new one.
The most time consuming process when we work with a database is to create a
connection object. When application goes out of scope the object becomes a candidate
for garbage collector. Every time we create and every time will be destroyed. This was
effect on a distributed application, where n no clients are waiting for the response.
Connection pooling is a concept of object reusability. This is a service provided by
application servers.

Multithreading:-
Multithreading is the ability of a program or an operating system process to
manage its use by more than one user at a time and to even manage multiple requests
by the same user without having to have multiple copies of the programming running
in the computer. Each user request for a program or system service (and here a user can

16 | P a g e
also be another program) is kept track of as a thread with a separate identity. As
programs work on behalf of the initial request for that thread and are interrupted by
other requests, the status of work on behalf of that thread is kept track of until the work
is completed.

Process:-
Process is defined as the virtual address space and the control information
necessary for the execution of a program while Threads are a way for a program to split
itself into two or more simultaneously running tasks. In general, a thread is contained
inside a process and different threads in the same process share some resources while
different processes do not.

17 | P a g e
Client Server Architecture
Two tier architecture
In modern two-tier architecture, the server holds both the application and the
data. The application resides on the server rather than the client, probably because the
server will have more processing power and disk space than the PC.

Two tier architecture

Three tier architecture

Three-tier is a client–server architecture in which the user interface, functional
process logic ("business rules"), computer data storage and data access are developed
and maintained as independent modules, most often on separate platforms.
Three-tier architecture has the following three tiers:
Presentation tier
This is the topmost level of the application. The presentation tier displays
information related to such services as browsing merchandise, purchasing, and

18 | P a g e
shopping cart contents. It communicates with other tiers by outputting results to the
browser/client tier and all other tiers in the network.

Application tier

(Business logic, logic tier, data access tier, or middle tier)

The logic tier is pulled out from the presentation tier and, as its own layer, it controls an
application’s functionality by performing detailed processing.

Data tier
This tier consists of database servers. Here information is stored and retrieved.
This tier keeps data neutral and independent from application servers or business logic.
Giving data its own tier also improves scalability and performance.

Three tier architecture

19 | P a g e
20 | P a g e
LOAD RUNNER
Performance testing cannot be done manually. We cannot say 1000
users to click on the same button at a same time. We need a tool to do
performance testing. Load runner is a tool for the performance testing. There
are many tools available in the market for the performance testing but Load
runner is the best amongst them.

Manual Testing Is Problematic

Coordinator

21 | P a g e
Components of Load Runner

Types of Components
 VuGen (Virtual User Generator)
 Load Generator
 Controller
 Analysis

VuGen (Virtual User Generator)

The VuGen is used to emulate the steps of real human users. VuGen lets the user
record and/or script a test to be performed against an application under test, and play
back and make modifications to the script as needed, such as defining Parameterization
(selecting data for keyword-driven testing). HP LoadRunner supports more than 51
protocols including Web HTTP/HTTPS, Remote Terminal Emulator, Oracle and Web
Services. A protocol acts as a communication medium between a client and a server .

Load Generator

22 | P a g e
Load generators (also known as hosts) are used to run the Vusers that generate load on
the application under test.

Controller
Once a script is prepared in Vugen, it is run via the Controller. Each run is called as
a scenario with some preset settings. As a single point of control, it provides complete
visibility of the tests and the virtual users. The Controller facilitates the process of
creating a load test scenario by allowing us to:
 Assign scripts to individual groups.
 Define the total number of virtual users needed to run the tests.
 Define the host machines on which virtual users are running.
Controller provides a suite of performance monitors to monitor the performance of
individual components. Some monitors include Oracle Monitors, WebSphere
Monitors, etc. Once a scenario is set and the run is completed, the result of the
scenario can be viewed via the Analysis tool.

Analysis
Once the results are ready, analysis is the most important job in the whole
performance test if the requirements of performance test are not defined. The main
criteria for analysis should be to find out the bottlenecks and we should be able to track
the transactions / users / hits that create the highest level of performance reduction.
Based on the test run, Load Runner will generate various graphs and reports. This
phase contains.

Lab Setup:
23 | P a g e
Scripting
Recording Option
Broadly divided into three categories:-

 General
 Network

24 | P a g e
  HTTP Properties

General:-

Script:
When you record a session VuGen creates a script that emulates your actions.
The default script generation language is C or C# for MS .NET. For the FTP,
COM/DCOM, and mail protocols (IMAP, POP3, and SMTP), VuGen can also generate a
script in Visual Basic, VB Script, and JavaScript.

Protocols:
Before recording a multi-protocol session, VuGen lets you modify the protocol
list for which to generate code during the recording session. If you specified certain
protocols when you created the script, you can enable or disable them using the
Protocol Recording options.

25 | P a g e
Recording:
HTML
The HTML-based script level generates a separate step for each HTML user
action. The steps are also intuitive, but they do not reflect true emulation of the
JavaScript code.

URL
The URL-based script mode option instructs VuGen to record all browser
requests and resources from the servers that were sent due to the user's actions. It
automatically records every HTTP resource as URL steps (web_url statements). All
actions are recorded as web_url steps instead of web_link, web_image, and so on.

Network:-
VuGen uses the Port Mapping settings to direct traffic via a specific server:port
combination to the desired communication protocol. You can configure the Port
Mapping settings in the following areas:
 Capture level. The level of data to capture (relevant only for HTTP based
protocols):

 Socket level data. Capture data using trapping on the socket level only. Port
mappings apply in this case (default).
 WinINet level data. Capture data using hooks on the WinINet.dll API used
by certain HTTP applications. The most common application that uses these
hooks is Internet Explorer. Port mappings are not relevant for this level.
 Socket level and WinINet level data. Captures data using both mechanisms.
WinINet level sends information for applications that use the WinINet DLL.
Socket level sends data only if it determines that it did not originate from the
WinINet dll. Port mapping applies to data that did not originate from
WinINet.

26 | P a g e
HTTP Properties
Advanced

27 | P a g e
Correlation
VuGen's correlation engine allows you to automatically correlate dynamic data
during your recording session

28 | P a g e
29 | P a g e
Customization of Script
Parameterization
Parameters are like script variables. They are used to vary input to the server and
to emulate real users. Parameter is not a dynamic value captured from server response
but it is something for which the user has predefined data values available. There is
different type of parameters in Load Runner, Different types of Parameters.

Types of Parameter list:

File
Date/time
User ID
Group Name
Iteration number
Load Generator name
Random Number parameter
Unique number
User Defined Function
User File path

Data Files:
Data that is contained in a file either an existing file or one that we create with
VuGen. Data files hold data that a Vuser accesses during script execution. Data can be
stored in local or global files. Data files are useful if we have many known values for
parameter. The data in a data file is stored in the form of a table. One file can contain
values for many parameters. Each column holds the data for one parameter.

30 | P a g e
31 | P a g e
32 | P a g e
Correlation:
Correlation is use to handle dynamic content. Dynamic content refers to page
components that are dynamically created during the execution of a business process,
and the value may differ from the value generated in a previous run. Examples of
dynamic content include the ticket number in an on-line reservation system, a
transaction ID in an on-line banking application and most importantly the unique
session ID that is created each time a user logs in. Such dynamic values must be
correlated in order to run the recorded script. The script while running will return an
error if such a dynamic value has not been correlated, since the value changes each time
the user logs in.

Correlation can be done in two ways:

1. Automatic Correlation
2. Manual Correlation
Automatic Correlation:
VuGen's correlation engine allows you to automatically correlate dynamic data
during your recording session

33 | P a g e
Manual Correlation
Manual Correlation is done by using the LR inbuilt function given below:
web_reg_save_param("When_Txt", "LB= ", "RB= ", LAST);

Runtime settings

Broadly divided into four categories:

 General
 Network
 Browser
 Internet Protocol

General

Run Logic
You can instruct a Vuser to Repeat the Run section when you run the script. Each
repetition is known as iteration
Number of Iterations
Load Runner repeats all of the actions, the specified number of times.
If you specify scenario duration in the controller, the duration setting overrides the
Vusers iteration settings.

34 | P a g e
Pacing
 Control the time between iterations.
 The pace tells the Vuser how long to wait between iterations of Vuser
You can instruct Vuser by following any of the method below
 As soon as the previous iteration ends.
 After the previous iteration ends with a fixed / random delay
 At fixed / random intervals

Log
Vusers log information about themselves and their communication between
server
Two types of Logs
 Standard
 Extended
VuGen writes log messages that we can view in execution log.

35 | P a g e
lr_log_message. Messages sent manually, using lr_message, lr_output_message, and
lr_error_message, are still issued

Think Time
When you run a Vuser script, the Vuser uses the think time values that were
recorded into the script during the recording session. VuGen allows you to use the
recorded think time, ignore it, or use a value related to the recorded time:

36 | P a g e
Miscellaneous
We can set the following miscellaneous run-time options for a Vuser script:
 Error Handling
 Multithreading
Vusers support multithreaded environments. The primary advantage of a multithread
environment is the ability to run more Vusers per load generator.
Automatic Transactions

37 | P a g e
Network
Using the Speed Simulation settings, you can select a bandwidth that best emulates the
environment under test. The following options are available:
 Use maximum bandwidth. By default, bandwidth emulation is disabled
and the Vusers run at the maximum bandwidth that is available over the
network.
 Use bandwidth. Indicate a specific bandwidth level for your Vuser to
emulate. You can select a speed ranging from 14.4 to 512 Kbps, emulating
analog modems, ISDN, or DSL.
 Use custom bandwidth. Indicate a bandwidth limit for your Vuser to
emulate. Specify the bandwidth in bits, where 1 Kilobit=1024 bits.

38 | P a g e
Browser
We can use the Browser: Browser Emulation node in the Run-Time Settings tree to set
the browser properties of your testing environment.

39 | P a g e
Internet

Proxy
Types of Proxy setting
No proxy:
All Vusers should use direct connections to the Internet. This means that the connection
is made without using a proxy server.
Obtain the proxy settings from the default browser:
All Vusers use the proxy settings of the default browser from the machine upon which
they are running.
Use custom proxy:
All Vusers use a custom proxy server. You can supply the actual proxy server details or
the path of a proxy automatic configuration script (.pac file) that enables automatic
configuration

40 | P a g e
Preference
Image and Text Checks:
Image and text checks option allows the Vuser to perform verification checks
during replay by executing the verification functions. This option only applies to
statements recorded in HTML-based mode. Vusers running with verification checks use
more memory than Vusers who do not perform checks.

41 | P a g e
Download Filters
We can specify the Web sites from which Vusers should download resources
during replay. You can indicate either the sites to exclude or the sites to include. You
control the allowed or disallowed sources, by specifying a URL, host name, or host
suffix name.

42 | P a g e
Content Check
VuGen's Content Check mechanism allows you to check the contents of a page
for a specific string. This is useful for detecting non-standard errors. In normal
operations, when your application server fails, the browser displays a generic HTTP
error page indicating the nature of the error. The standard error pages are recognized
by VuGen and treated as errors, causing the script to fail. Some application servers,
however, issue their own error pages that are not detected by VuGen as error pages.
The page is sent by the server and it contains a formatted text string, stating that an
error occurred.

43 | P a g e
44 | P a g e
Debug Function
When we perform load testing, we have to be fully confident, that our application
works correctly. It may be very useful to check UI of application - is it shown correctly
or not.

This verification can be performed with 2 ways:

 Using LoadRunner content verification with web_reg_find function
 Running LoadRunner GUI Vusers (QTP or WR scripts)

How to add Load Runner content checkpoint?

Let's start with Load Runner demo Web application - Web Tours.
I will show how to check that a greeting 'Welcome to the Web Tours site' is shown on a
start page:

I've recorded a simple script on Web Tour application - it just opens a start page, logs
in, and logs out:

45 | P a g e
After that:
 open the script in Tree View (with menu 'View/Tree View')
 select initial step ('Url: WebTours')
 select the text I would like to check on the page and
 right mouse click:

Use default settings in 'Find Text' dialog:

46 | P a g e
Then open LoadRunner script in Script View (menu 'View/Script View') and i will see
that web_reg_find function has been just added before the first function:

web_reg_find("Text=Welcome to the Web Tours site", "Search=Body", LAST);

web_url("WebTours", "URL=...", ...LAST);
.
Please, note:

web_reg_find function has been added before the page opening function (web_url)!
This is because LoadRunner web_reg_find function does not search for text on a page;
it just registers a search request for a text string on an HTML page.

This is very important and I would like to pay your attention - web_reg_find function
should be placed before the function, which loads a page.
. Description of web_reg_find function attributes
The simplest web_reg_find function can look like:
.
web_reg_find("Text=Welcome to the Web Tours site", LAST);
.
This form means 'register a request to search for a "Welcome to the Web Tours
site" text on a next Web page retrieved from a server.

47 | P a g e
 Attribute 'Text=' contains a text, that should be searched.
If the check fails, the error is reported after the next action function executes:

Attribute 'Search=' defines the scope of the search:

o Body (default value) means to search in a body of server's response and its
resources
o Headers means to search within a pages headers
o No resource means to search in a body of HTML page retrieved from server
and do not search in its resources

Example:
Please, see a server response:

The following web_reg_find function checks that server's name is 'Xitami':

web_reg_find("Text=Server: Xitami", "Search=Headers", LAST);

The next important attribute of web_reg_find function is 'SaveCount='. Use it to save a

number of matches that were found.

Imagine, that we have to get a number of 'A Coach class ticket for:' text on Itinerary page:

48 | P a g e
The following code:
 uses web_reg_find function with "SaveCount=" attribute (3rd line) before the
Itinerary page loads
 then loads Itinerary page (6th line)
 extracts number of matches (8th line) and
 compares it to an expected value (9th line):

1. int nFound;
2.
3. web_reg_find("Text=A Coach class ticket for :", "SaveCount=TextPresent_Count",
LAST);
4.
5. // open Itinerary page
6. web_image("Itinerary Button", "Alt=Itinerary Button", LAST);
7.
8. nFound = atoi(lr_eval_string("{TextPresent_Count}"));
9. if (nFound == 11)
10.     lr_output_message("Correct number of 'Coach class ticket' text: %d", nFound);
11. else
12. {
13.     lr_error_message("Incorrect number of 'Coach class ticket' text: %d", nFound);
14.     return 0;
15. }
16.

If we have additional info on 8th line:

17. nFound = atoi(lr_eval_string("{TextPresent_Count}"));

49 | P a g e
lr_set_debug_message
It sets the message level for the script execution.
Syntax:-
3. int lr_set_debug_message (unsigned int message_level, unsigned int
on_off);
Example   
In this example, the lr_set_debug_message function enables the full trace option just
before a call to lrd_fetch, which the user needs to debug because it has been giving
unexpected results.
The second invocation of lr_set_debug_message resets the debug level to what it was
formerly, by turning off (LR_SWITCH_OFF) the extended message level.

4. lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG |
LR_MSG_CLASS_FULL_TRACE, LR_SWITCH_ON );

rc = lrd_fetch(Csr1, 1, 1, 0, PrintRow3);

if (rc>2000)
5.   lr_debug_message(LR_MSG_CLASS_FULL_TRACE,
             "Fetch failed returned %d", rc);

/* Now reset message class to former level */

lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG |
LR_MSG_CLASS_FULL_TRACE, LR_SWITCH_OFF );

50 | P a g e
Controller
Once a script is prepared in VuGen, it runs using the LoadRunner Controller.
The Controller manages and maintains the scenarios that are run. During a scenario
run, the Controller allows monitoring of network and server resources. The Controller
assigns virtual users and load generators to specific scenarios.

Multiple machines can be set up to act as load generators in concert. For

example, to run a test of 1000 users, three or more machines can be set up with an HP
LoadRunner agent installed on them. These machines are known as load generators
because the actual load is generated from them. Each run is configured with a scenario
that describes which scripts will run, when they will run, how many virtual users will
run, and which load generators will be used for each script. The tester connects each
script in the scenario to the name of a machine that is going to act as a load generator
and sets the number of virtual users to be run from that load generator. HP LoadRunner
can control multiple load generators and collect results, and it can control load
generators located at remote networks (through a firewall) if required.

HP LoadRunner uses monitors during a load test to monitor the performance of

individual components under load. HP LoadRunner supports more than 60 monitors,
including Oracle and other database server monitors, WebSphere and other web
application server monitors, transaction and run-time monitors, system resource
monitors, network delay monitors, firewall monitors, web server resource monitors,
streaming media monitors and ERP/CRM server resource monitors. Once a scenario
has been created and run in the Controller, results can be viewed and analyzed using
the Analysis tool

Controller Functionality
 Controller organizes and manages scenario elements
 During scenario execution the controller :
 Runs Vuser Groups
 Controls the initialize, run, pause, and stop conditions of each Vuser
 Displays the status of each Vuser
 Displays any messages from Vusers
 Monitors system and network resources

51 | P a g e
Types of Scenarios
 Manual Scenario
 Manage your Load Test by specifying the number of Virtual users to run
 Goal-Oriented Scenario
 Allow LoadRunner Controller to create a Scenario based on the goals you
specify

Manual Scenario
 You control the number of Running Vusers at the time which they run.
 You can specify how many Vusers run simultaneously
 Allows you to run the Vuser in Percentage mode

Goal-Oriented Scenario
 Determine your system to achieve the particular goal
 The goal may be number of hits per second, Number of transaction per second,
etc.,
 Manages Vusers Automatically to maintain and achieve the goal

Vuser Groups
 Scenario consists of group of Vusers which emulate the Human users to interact
with your application
 Each script you select is assigned a Vuser group
 Each Vuser group is assigned a number of Vusers
 You can Assign different script to each Vuser or You can assign the same script
to all the Vusers

52 | P a g e
Adding Vuser Group
 Group Name
 Vuser Quantity
 Load Generator name

53 | P a g e
54 | P a g e
Analysis

Reports and Analysis

Creating Analysis Session

 When you run a scenario, data is stored in a result file with an .lrr extension.
Analysis is the utility that processes the gathered result information and
generates graphs and reports.
 When you work with the Analysis utility, you work within a session. An Analysis
session contains at least one set of scenario results (lrr file). Analysis stores the
display information and layout settings for the active graphs in a file with an .lra
extension.

Analysis provides graphs and reports to help you analyze the performance of your
system. These graphs and reports summarize the scenario execution.

55 | P a g e
To view a summary of the results after test execution, we can use one or more of the
following tools:

• Vuser log files contain a full trace of the scenario run for each Vuser. These files
are located in the scenario results directory.
• Controller Output window displays information about the scenario run.
• Analysis graphs help you determine system performance and provide
information about transactions and Vusers.
• Graph Data and Raw Data views display the actual data used to generate the
graph in a spreadsheet format.

Report utilities enable us to view a Summary HTML report for each graph or a variety
of Performance and Activity reports. You can create a report as a Microsoft Word
document, which automatically summarizes and displays the test’s significant data in
graphical and tabular format

How to Collate the Results

• When you run a scenario, by default all Vuser information is stored locally on
each Vuser host

56 | P a g e
 • After scenario execution the results are automatically collated or consolidated –
results from all the hosts are transfer to results directory
• You disable automatic collation by choosing Results > Auto collate Results from
the controller window
• You can collate manually by selecting Results > Collate Results
• If your results are not collated Analysis will automatically collate the results
before generating the analysis data

Analysis Graphs
Analysis graphs are divided into the following categories:

 Vuser Graphs - Provide information about Vuser states and other Vuser
statistics.
 Error Graphs - Provide information about the errors that occurred during the
scenario.
 Transaction Graphs - Provide information about transaction performance
and response time.
 Web Resource Graphs - Provide information about the throughput, hits per
second, HTTP responses per second, number of retries per second, and
downloaded pages per second for Web Vusers.
 Web Page Breakdown Graphs - Provide information about the size and
download time of each Web page component.
 User-Defined Data Point Graphs - Provide information about the custom
data points that were gathered by the online monitor.
 System Resource Graphs - Provide statistics relating to the system resources
that were monitored during the scenario using the online monitor.
 Network Monitor Graphs - Provide information about the network delays.
 Firewall Server Monitor Graphs - Provide information about firewall server
resource usage.
 Web Server Resource Graphs - Provide information about the resource usage
for the Apache, iPlanet/Netscape, iPlanet(SNMP), and MS IIS Web servers.

Adding New Graph

Graph > Add Graph, or click <New Graph>

57 | P a g e
  Graphs that contain data are listed in blue. By default, only graphs that
contain data are listed. To view the entire list of LoadRunner graphs, clear
Display only graphs containing data.
 Use the Scenario Elapsed Time field to limit the time range for which graph
data is displayed.

58 | P a g e