Guide to Download and Install HP

LoadRunner 12.0
This is a step by step guide to download and install Loadrunner.

PART 1} Download
Step 1) To Download LoadRunner, go to this link and click Try LoadRunner

Step 2) In next window, enter your personal details and click on Next button

Step 3) A window pops up showing the terms and agreement. Click on I Agree

Step 4) Click on Download on the next page as shown below.

PART 2} Installation

Step 1) Once download is complete, open the installation file. A window will
open, click on install

Step 2) Once you click on install, it will start extracting the set up in Temp
folder.

Step 3) You need to have Microsoft .net framework 4.5 installed before you
begin installation. However, the LoadRunner setup will automatically prompt
you to install it if you do not already have. Below is step by step guide on
LoadRunner installation:

Click OK button to proceed with the installation of missing prerequisites. If you

already have .net framework 4.0 or above, youll not see this screen, rather the
setup will show a splash screen for a moment till it calculates space
requirements. Refer below for a snapshot.
Step 4) Next, HP loadrunner Setup wizard is shown. The setup will enable the
Next button once it has calculated space requirement. Click Next.

Step 5) In next screen, you can choose the directory you wish to install
LoadRunner. Click on the check box and accept for agreement and then click on
installRead the license agreement and if you agree, click Install button to begin
copying of files. The setup will first validate the package to avoid disruption
whilst installation progresses.

`
Step 6) It will take few seconds to install LoadRunner After validating the
package, the setup will copy all files in directory selected earlier. It will register
all components with the system and acknowledge upon completion. The setup
will then show Finish button.

Step 7) In next step, click on OK to proceed.

Step 8) A window pops up showing installation of Setup Wizard

Step 9) Once the LoadRunner setup wizard is installed, click on open

installation log and then click on finish as shown below

Step 10) Once finished, the setup will open readme file by default which
contains useful information. Whether youre new to LoadRunner of experience
user, it is best recommended to go through readme file at least once.

Step 11) The LoadRunner installation is completed at this point. However, you
can see the setup has opened License Utility. Observe this screen and ensure
there is at least 1 license installed and its status has a tick mark in green as
shown in below screenshot. Starting with LoadRunner 12, HP has issued free
license of 50 VUsers which has no expiry.

If youve a valid license from HP, you can install it by clicking on Install New
License button. The new window will open where license file can be browsed
and imported or otherwise a license key can be directly pasted in the bottom
text box. Refer to below snapshot:

Installation of the new version is optimized and takes less than 10 minutes on a
Core i5 machine with 8GB RAM. However the minimum hardware requirements
are different, as put below:

Component

Minimum Requirement

Processor speed

1.6 GHZ or faster

Operating system

Works on: Windows Server 2008 R2 SP1 64-bit Windows Server 2012 64-bit
[only supported for Controller and Analysis] Windows 7 SP1 32 (supported) or

64-bit (recommended) Windows 8 64-bit

Memory (RAM)

Minimum:2 GB Recommended:4 GB or higher

Screen resolution

Minimum:1024 x 768

Browser

Microsoft Internet Explorer 8, 9 and 10

Available hard disk space

Minimum:40 GB

Minimum Hardware requirements for LoadRunner

A Controller simulates load through Load Generators and these are configured
on separate machines. HP had recommended minimum hardware
requirements for Load Injectors:

Component

Minimum Requirement

Processor speed

1.6 GHZ or faster

Operating system

Works on: Windows Server 2008 R2 SP1 64-bit Windows Server 2012 64-bit
Windows 7 SP1 32 (supported) or 64-bit (recommended) Windows 8 64-bit

Memory (RAM)

Minimum:1 GB for Load Generator or 2GB for MI ListenerRecommended:4

GB or higher

Screen resolution

Minimum:1024 x 768

Browser

Microsoft Internet Explorer 8, 9, 10 or 11

Available hard disk space

Minimum:40 GB

Minimum Hardware requirements for Load Generators

Introduction to HP LoadRunner and its

Architecture
LoadRunner is a Performance Testing tool which was pioneered by Mercury in
1999. Loadrunner was later acquired by HP in 2009.

LoadRunner supports various development tools, technologies and

communication protocols. In fact this is the only tool in market
which supports such large number of protocols to conduct performance
testing.
LoadRunner is not only pioneer tool in Performance Testing, but it is still market
leader in the Performance testing paradigm. In a recent assessment,
LoadRunner has about 85% market share in Performance Testing industry.

Broadly, LoadRunner supports RIA (Rich Internet Applications), Web 2.0

(HTTP/HTML, Ajax, Flex and Silverlight etc.), Mobile, SAP, Oracle, MS SQL Server,
Citrix, RTE, Mail and above all, Windows Socket. There is no competitor tool in
the market which could offer such wide variety of protocols vested in single
tool.

What is more convincing to pick LoadRunner for performance testing is the

credibility of this tool. LoadRunner has long established reputation as often you
will find clients cross verifying your performance benchmarks using
LoadRunner. You'll find relief if you're already using LoadRunner for your
performance testing needs.
LoadRunner is tightly integrated with other HP Tools like Unified Functional Test
(QTP) & ALM (Application Lifecycle Management) with empowers you to
perform your end to end Testing Processes.
LoadRunner works on a principal of simulating Virtual Users on the subject
application. These Virtual Users, also termed as VUsers, replicate client's
requests and expect corresponding response to pass a transaction.

Why do you need Performance Testing?

An estimated loss of 4.4 billion in revenue is recorded annually due to poor
web performance.

In today's age of Web 2.0, users click away if a website doesn't respond within 8
seconds. Imagine yourself waiting for 5 seconds when searching over Google or
making a friend request on Facebook. The repercussions of performance
downtime are often more devastating than ever imagined. We've examples such
as those that recently hit Bank of America Online Banking, Amazon Web
Services, Intuit or Blackberry.
According to Dunn & Bradstreet, 59% of Fortune 500 companies experience an
estimated 1.6 hours of downtime every week. Considering the average Fortune
500 company with a minimum of 10,000 employees is paying $56 per hour, the
labour part of downtime costs for such an organization would be $896,000
weekly, translating into more than $46 million per year.
Only a 5 minute downtime of Google.com (19-Aug-13) is estimated to cost the
search giant as much as $545,000.
Its estimate that companies lost sales worth $1100 per second due to a recent
Amazon Web Service Outage.
When a software system is deployed by an organization, it may encounter many
scenarios that possibly result in performance latency. A number of factors
cause decelerating performance, few example may include:

Increased number of records present in the database

Increased number of simultaneous requests made to the system
larger number of users accessing the system at a time as compared to the
past

What is LoadRunner Architecture?

Broadly speaking, the architecture of LoadRunner is complex, yet easy to
understand.

Suppose you are assigned to check performance of Amazon.com for 5000 users
In a real life situation, these all these 5000 users will not be at homepage but
in different section of the websites. How can we simulate different
VUGen:
VUGen or Virtual User Generator is an IDE (Integrated Development
Environment) or a rich coding editor. VUGen is used to replicate System Under
Load (SUL) behaviour. VUGen provides a "recording" feature which records
communication to and from client and Server in form of a coded script - also
called VUser script.
So considering the above example, VUGen can record to simulate following
business processes:
1.

Surfing the Products Page of Amazon.com

2.

Checkout

3.

Payment Processing

4.

Checking MyAccount Page

Controller
Once a VUser script is finalized, Controller is the main component which
controls the Load simulation by managing, for example:

How many VUsers to simulate against each business process or VUser

Group
Behaviour of VUsers (ramp up, ramp down, simultaneous or concurrent
nature etc.)
Nature of Load scenario e.g. Real Life or Goal Oriented or verifying SLA
Which injectors to use, how many VUsers against each injector
Collate results periodically
IP Spoofing
Error reporting
Transaction reporting etc.

Taking analogy from our example controller will add following parameter to the
VUGen Script
1) 3500 Users are Surfing the Products Page of Amazon.com
2) 750 Users are in Checkout
3) 500 Users are performing Payment Processing
4) 250 Users are Checking MyAccount Page ONLY after 500 users have done
Payment Processing
Even more complex scenarios are possible
1.

2.

Initiate 5 VUsers every 2 seconds till a load of 3500 VUsers (surfing Amzon
product page) is achieved.
Iterate for 30 minutes

3.

Suspend iteration for 25 VUsers

4.

Re-start 20 VUSers

5.

Initiate 2 users (in Checkout, Payment Processing , MyAccounts Page)

every second.

6.

2500 VUsers will be generated at Machine A

7.

2500 VUsers will be generated at Machine B

Agents Machine/Load Generators/Injectors

LoadRunner Controller is responsible to simulate thousands of VUsers - these
VUsers consume hardware resources for example processor and memory hence putting a limit on the machine which is simulating them. Besides,
Controller simulates these VUsers from the same machine (where Controller
resides) & hence the results may not be precise. To address this concern, all
VUsers are spread across various machines, called Load Generators or Load
Injectors.
As a general practice, Controller resides on a different machine and load is
simulated from other machines. Depending upon the protocol of VUser scripts
and machine specifications, a number of Load Injectors may be required for full
simulation. For example, VUsers for an HTTP script will require 2-4MB per VUser
for simulation, hence 4 machines with 4 GB RAM each will be required to
simulate a load of 10,000 VUsers.
Taking Analogy from our Amazon Example, the output of this component will be
Analysis:
Once Load scenarios have been executed, the role of "Analysis" component
comes in.
During the execution, Controller creates a dump of results in raw form &
contains information like, which version of LoadRunner created this results
dump and what were configurations.

All the errors and exceptions are logged in a Microsoft access database, named,
output.mdb. The "Analysis" component reads this database file to perform
various types of analysis and generates graphs.
These graphs show various trends to understand the reasoning behind errors
and failure under load; thus help figuring whether optimization is required in
SUL, Server (e.g. JBoss, Oracle) or infrastructure.
Below is an example where bandwidth could be creating bottleneck. Let's say
Web server has 1GBps capacity whereas the data traffic exceeds this capacity
causing subsequent users to suffer. To determine system caters to such needs,
Performance Engineer needs to analyse application behaviour with abnormal
load. Below is a graph LoadRunner generates to elicit bandwidth.

Performance Testing Roadmap: Detailed Steps

Performance Testing Roadmap can be broadly divided into 5 steps:

Planning for Load Test

Create VUGen Scripts
Scenario Creation
Scenario Execution
Results Analysis (followed by system tweaking)

Now that you've LoadRunner installed, let's understand the steps involved in
the process one by one.

Steps involved in Performance Testing process

Planning for the Load Test

Planning for Performance Testing is different from planning an SIT (System
Integration Testing) or UAT (User Acceptance Testing). Planning can be further
divided into small stages as described below:

Assemble Your Team

When getting started with Performance Testing, it is best to document who will
be participate in the activity from each team involved during the process.
Project Manager:
Nominate the project manager who will own this activity and serve as point
person for escalation.
Function Expert/ Business Analyst:
Provide Usage Analysis of SUL & provides expertise on business functionality of
website/SUL

Performance Testing Expert:

Creates the automated performance tests and executes load scenarios
System Architect:
Provides blueprint of the SUL
Web Developer and SME:

Maintains website & provide monitoring aspects

Develops website and fixes bugs

System Administrator:

Maintains involved servers throughout testing project

Outline applications and Business Processes involved:

Successful load testing requires that you plan to carry out certain business
process. A Business Process consists of clearly defined steps in compliance to
desired business transactions - so as to accomplish your load testing objectives.

A requirements metric can be prepared to elicit user load on the system. Below
is an example from an attendance system in a company:

In the above example, the figures mention the number of users connected to
the application (SUL) at given hour. We can extract the maximum number of
users connected to a business process at any hour of the day which is
calculated in the right most columns.
Similarly, we can conclude the total number of users connected to the
application (SUL) at any hour of the day. This is calculated in the last row.
The above 2 facts combined give us the total number of users with which we
need to test the system for performance.

Define Test Data Management Procedures

Statistics and observations drawn from Performance Testing are greatly

influenced by numerous factors as briefed earlier. It is of critical significance to
prepare Test Data for Performance Testing. Sometimes, a particular business
process consumes a data set and produces a different data set. Take below
example:

A user 'A' creates a financial contract and submits it for review.

Another user 'B' approves 200 contracts a day created by user 'A'
Another user 'C' pays about 150 contracts a day approved by user 'B'

In this situation, User B need to have 200 contracts 'created' in the system.
Besides, user C needs 150 contracts as "approved" in order to simulate load of
150 users.
This implicitly means, that you must create at least 200+150= 350 contracts.
After that, approve 150 contracts to serve as Test data for User C - the
remaining 200 contracts will serve as Test Data for User B.

Outline Monitors
Speculate each and every factor which could possible affect the performance of
system. For example, having reduced hardware will have potential impact on
the SUL(System Under Load) performance.
Enlist all factors and setup monitors so you can gauge them. Here are few
examples:

Processor (for Web Server, Application Server, Database Server and

Injectors)
RAM (for Web Server, Application Server, Database Server and Injectors)
Web/App Server (for example IIS, JBoss, Jaguar Server, Tomcat etc)
DB Server (PGA and SGA size in case of Oracle and MSSQL Server, SPs
etc.)
Network bandwidth utilization

Internal and External NIC in case of clustering

Load Balancer (and that it is distributing load evenly on all nodes of
clusters)

Data flux (calculate how much data moves to and from client and server
- then calculate if capacity of NIC is sufficient to simulate X number of users)

Create VUGen Scripts

Next step after planning is to create VUser scripts.

Scenario Creation
Next step is to create your Load Scenario

Scenario Execution
Scenario execution is where 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.
This execution may result the server to go under stress and behave abnormally.
This is the very purpose of the performance Testing. The results drawn are then
used for detailed analysis and root cause identification.

Results Analysis (followed by system tweaking)

During scenario execution, LoadRunner records the performance of the
application under different loads. The statistics drawn from test execution are
saved and details analysis is performed. The 'HP Analysis' tool generates various
graphs which help in identifying the root causes behind lag of system
performance, as well as system failure.
Some of the graphs obtained include:

Time to First buffer

Transaction Response Time

Average Transaction Response Time

Hits Per Second
Windows Resources
Errors Statistics
Transaction Summary

FAQ
Which Applications should we Performance
Test ?
Performance Testing is always done for client server based systems only. This
means, any application which is not a client-server based architecture, must not
require Performance Testing.
For example, Microsoft Calculator is neither client-server based nor it runs
multiple users; hence it is not a candidate of Performance Testing.

What is the difference between Performance Testing &

Performance Engineering
It is of significance to understand the difference between Performance Testing
and Performance Engineering. An understanding is shared below:
Performance Testing is a discipline concerned with testing and reporting the
current performance of a software application under various parameters.

Performance engineering is the process by which software

is testedandtuned with the intent of realizing the required performance. This
process aims to optimize the most important application performance trait i.e.
user experience.
Historically, testing and tuning have been distinctly separate and often
competing realms. In the last few years, however, several pockets of testers and
developers have collaborated independently to create tuning teams. Because
these teams have met with significant success, the concept of coupling
performance testing with performance tuning has caught on, and now we call it
performance engineering.

Understanding VUGen in LoadRunner

VUGen is one of the four core components of LoadRunner. It is the first
component you interact with when getting started with Performance Testing
using HP LoadRunner.
Lets understand a few salient features related to VUGen
VUScripts: As already described, the purpose of VUGen is to create VUScripts
that are used to simulate a real-like virtual-user.
Actions: An action is set of user transactions performed in the System Under
Load to achieve a defined task. An action can be compared to a function in
other programming languages. Each Vuser script has 3 default functions
Vuser_init(used to login into the application)
Action (used to record the business process)
Vuser_end (used to logout of the application)
VUGen not only records scripts but also replays them (for only 1 VUser) to
ensure script is recorded correctly. Once you ensure the script is recorded
correctly you incorporate it in a LoadRunner scenario

In this tutorial we are going to study

1 The script development process in VUGen
2 Compare recording between QTP and LoadRunner
Introduction to Web Tours Application
Understanding the VUGen Environment
3 Creating Your First VUGen Script
Using Transactions at Record Time
Insert Comments at Record Time
Code Generation
Deciding a Protocol and Protocol Advisor
Recording Options
4 Playback a Script and understanding Log

5 Overview of Files Generated During Record & Playback

The script development process in VUGen

1. Record the Script: Usually this is the first step of scripting where every user
action is recorded into a script.
2. Replay and Verify: Once the script is recorded, reply the script to ensure its
working right. Verify any impact through application frontend or database.
3. Enhance the Script: Once recording has been verified, enhance script by
adding checkpoints, validating data, adding transactions and rendezvous points.
4. Replay and Verify: As earlier, re-play your script and verify that everything is
working as intended.

5. Configure Runtime Settings: Configure and control pacing duration, think

time variation, proxy settings and whether you wish to ignore any external
resources.
6. Use for Load Scenarios: Formulate load scenarios based on test objectives.
Use load distribution and geo-wide agents to make real like scenarios.

Compare recording between QTP and

LoadRunner
VUGen disregards UI Objects:
Unlike QTP scripts, LoadRunner scripts are independent of GUI. This is because
the code generated does not work based on UI objects, rather, it works on the
principal of clients request to the server and expecting server response back to
the client. This is why replaying LoadRunner scripts are always browser
independent. The VUser can communicate directly with a server by executing
calls to the server API-without relying on client software (SUL) this means there
will no impact on scripts if the changes are made to the UI of the System Under
Load. This tells; the performance testing is completely based on client/server
communication (request and response) and not the GUI objects.
Please refer to below link for more details: http://youtu.be/FDORUeqpNJs?
t=3m41s
We will see in more details how VUGen works below.

Introduction to Web Tours Application

For all hands-on purpose, we will be using the Web Tours Application that
comes bundled with LoadRunner.
The HP Web Tours requires a dependent Web tours apache server to be
running before it can operate. To run the Web Tours Apache Server, go to Start
Menu => HP Software => Samples => Web and then click on Start HP Web Tour
Server.

Once the server has been activated, it will open a shell and output on the
console.
The console should look like snapshot below, look for your IP address in the
shell:

NOTE: if you close this window, the server will stop.

Now you can access the Web Tours Application

Once launched, it will look like

Understanding the VUGen Environment

To run the VUGen, double click on the VUGen shortcut from the desktop, or go
to Start Menu => HP Software => and then click on Virtual User Generator.

VUGen splash screen will appearas follows

The splash screen will subsequently open HP VUGen Home page, as shown
below:

From the File menu, you can observe various command controls. The purpose
of these controls are mentioned below:

New Script and Solution: is used to start creating a new script. Alternatively,
you can create a new script from the toolbar button.
Open >> Script Solution: is used to open an existing, previously created script
or solution from a directory.
Add >> New Script: is used to add a previously created script into current
solution
We will get acquainted with other controls as we start creating our first script.
Lets continue learning.
Please be patient. The Video will load in some time. If you still face issue
viewing video click here

Creating Your First VUGen Script

Before you record, make sure the Web Tours App serveris running. Remember,
you need to keep the server running so do not close it. If the window bothers
you, you can minimize it.
Tip:In a real world problem, one needs to get acquainted with the subject
application (SUL) especially if it involves complex business workflows and data
stages. You can also interact with HP Web Tours to ensure you can repeat the
exact steps when recording.

Before one can start with scripting of any application (SUL), one needs to get
acquainted with the application flow. With this tutorial, lets get acquainted with
HP Web Tours which is shipped and automatically installed with HP
LoadRunner.
Step 1)Click on File =>New Script and Solution as shown in the snapshot below:

You can use the shortcut (Ctrl + N) to do the same.

Step 2) A window to select the protocol is shown. The list looks slightly
different from previous versions
1. Select Single Protocol
2. Web
3. Enter Script Name
4. Click Create

Note: You can use Protocol Advisor to determine right protocol your
application uses for communication. For HP Web Tours, we already know that it
requires Web HTTP/HTML protocol. We will learn at a later stage how to
determine the right protocol for your SUL.
Tip: An application may require more than 1 Protocols sometimes to
communicate with its server. For such a case, navigate to Multiple Protocols list
on the left side of window.

HP Web Tours, however, requires only one protocol when scripting with VUGen.
Tip: You cannot rename your scripts easily, so be creative when giving your
scripts a name. If youve to rename a script, use Save As feature and give a new
name. A good nomenclature could be something like, WT01_Signup where WT is
short form of the application name, 01 is a business process sequence, and Sign
up refers to the business processes being scripted. Also note that you cannot
use spaces in a script name.
Step 3) once you click Create, HP VUGen will open the IDE (Integrated
Development Environment) or code editor. You can notice the script files are
blank, except basic signature of Function Action. Below snapshot should help
understand it more:

Step 4) Click the Recording

the snapshot below:

button which you can find in the toolbar. Refer to

Step 5) a new window opens

1. If we study the above window, the name of the script is mentioned in the title
bar of this popup. This will help you make changes to the right script when you
are dealing with multiple scripts opened at a time.
2. If you do not see the rest of controls, click on the Fewer Options button to
ensure you are not viewing fewer options.
3. Record into the action field determines where the code is generated after
recording. VUGen facilitates switching to other actions or create new actions
during and after recording.
4. Record: field tells VUGen that the subject application (SUL) is a web
application or a desktop client. This option cannot be overridden once
recording begins.

5. Application: field tells VUGen, which browser to use for recording. If you are
not working with Web HTTP/HTML protocol, you will select the desktop client
with this field.
Tip: Unlike QTP scripts, LoadRunner scripts are independent of GUI. This is
because the code generated does not work based on UI objects, rather, it works
on the principle of clients request to the server and expecting server response
back to the client usually, in the form of HTML (hence the name of protocol)
6. URL Address: The URL of the SUL is input here. VUGen will invoke this URL
when Start Recording is clicked. The browser used will be the one mentioned
under Record: field if it is different from your default browser.
7. Start Recording: Immediate vs. Delayed: If youve
selected Immediate recording mode, you will notice that VUGen starts
recording events as soon as you hit Start Recording button. However, if you
select Delayed recording mode, the VUGen will invoke the system (SUL) but will
not commence capturing events unless you click on the Recording button from
the floating bar.
8. Working Directory: This is a temporary directory which VUGen will use while
capturing events. A copy of your script will be available at this location as well,
just in case if you lose your folder :)
9.Recording Options: These settings tell VUGen what type of URLs to capture
and what recording mode to use.
10.Start Recording: Will start recording. Click on it
Step 6) Once recording starts, VUGen will invoke the HP Web Tours application
using the browser selected.
Lets Sign up a user at Web Tours application and record a basic script.

A floating recording bar will appear which will offer various controls over
recording. This tells the time elapsed and number of events automatically
captured. Lets look at the floating bar closely.

In the snapshot shown above, the SUL has fired 56 events and a total of 0
minutes, and 25 seconds of time duration have elapsed since recording begun.
Youll also observe that no events are fired as you type. Ask yourself why. Can
you answer?

This is because no client to server communication takes place as you type.

Hence, no events are fired and no script is generated regarding typing. Code will
be generated only once you submit the form (click Continue)
Recording can be pause
using the pause button. Please note, as long as the
recording remains paused, all events being fired by the application will be
disregarded. This also means that even if your application is sending requests
and/or receiving response form SUL, the script will not be generated as long as
youve paused the recording.
If youve paused recording, you will need to click recording
floating bar to resume recording.

button from the

While you are recording in vuser_init section, youd notice that rendezvous
button is not enabled. Switch to Action (or create a new Action) and continue
recording. Refer to below snapshot to learn how to switch Action.

Youll notice that after switching to an Action, the rendezvous

button will be
enabled automatically. This is because VUGen does not allow insertion of
rendezvous points in vuser_init.

Using Transactions at Record Time

Lets assume you wish to gauge response time when X number of users
simultaneously Sign up. To address this objective, lets read further.
By now youve recorded opening of the application in vuser_init action. After
youve switched to Action, enter the user information required by SUL. Now
before you hit Continue button, follow below steps:
Start a transaction by clicking
button in floating bar. Enter the name of the
transaction, for example, 01_Signup.
Tip: It is a good practice to name your transaction with a prefix like 01_ to help
keep them unique.
The floating bar will look like this:

Click OK to close the transaction label.

Click the Continue button of the application.
End transaction by clicking
button. Select the name of the transaction you
wish to close, for example, 01_Signup in this case. Refer to below snapshot for
illustration.

If you do not have multiple transactions opened, youll see only one name. If
youve multiple, however, youll 0be able to select from the list.

Insert Comments at Record Time:

Now that youve successfully closed the transaction, you can put a comment at
record time to give yourself a reminder when you study the code later. From
the floating bar, click on the button to insert a comment. A text box will appear
adjacent to the floating bar where you can enter any text.

This comment will be inserted into the code after the steps (code) youve just
finished before clicking OK button.

From the application, you can click continue. Youll observe a welcome note by
application.
Now select vuser_end action and click Sign off from the application. Close the
application and click stop button from the floating bar.

Code Generation:
Once recording has been stopped, youll notice VUGen post generation activity.
This includes generating code, transactions and comments based on your
recording. Refer to snapshot below.

Immediately after VUGen finished Performing post generation operations it

will start Performing scan for correlation post generation operation We will
see in more detail what correlation means.

Once post generation operation is finished, you will see Design Studio window.
If any candidates for correlation are found, youll be able to review them in this
window.

You can safely click on the Close button, and VUGen will take you to the code
that has been generated.
The window will look like this:

As highlighted in the above figure, the editor contains easy to understand,

readable code. You can have a look on the parameters used while recording.
The left side of VUGen is called Step Navigator that lets you understand the
script without looking at the granularities of the code. For example, you can
read steps as, opening a URL, spend Think Time and submit the form. This
encapsulates all the parameters associated with each request.
Your script has been generated, click on the File menu and then click on Save
Script As to browser the location where you wish to save your script. VUGen will
automatically suggest the last directory used if youve already saved a script
earlier. The name suggested will be the name you mentioned when you started
recording.

All done.
Now, congratulate yourself for having your first script successfully generated
and saved.

Deciding a Protocol and Protocol Advisor

You might have questioned yourself why did we use Web HTTP/HTML
protocol. How we decided which protocol should we use? The answer is not that
simple.
There is an architectural foundation set of skills you need to have in place as a
prerequisite to answering this question. If you are a beginner, you can pair up
with someone who has solid client-side architectural and development skills for
your SUL. You can speak with the developers of your SUL and find out which
interfaces your application leverages. This should lead you on a natural path to
the interfaces that you will be using for your virtual user script development
and protocol selection.
To address the needs of beginners less knowledgeable in architectural skills,
LoadRunner introduced a feature called Protocol Advisor in LoadRunner 9.1.
While this has made life easier for many, one should rely more on the
architectural and development skills instead of protocol advisor and receiving
information from the development team about underlying development
technologies. Protocol may not suggest correct protocol in all cases.
To use Protocol Advisor, go to Record => Protocol Advisor => Analyze
Application
Refer to snapshot below:

This will open the main window of Protocol Advisor. If you notice, this
resembles a bit with the window appearing for recording. Lets have a look at
the window below:

Select the Web Browser since we are using a web based application.
Specify the URL of the application that will subsequently be invoked. Working
directory can be left as such since this is merely a temporary directory for
VUGen to use. Ensure youve read and write access on this directory.
Click the Start Analyzing button.
A floating bar, somewhat similar to the record time floating bar will appear.
Have a look at the snapshot:

The process will tell the time elapsed and number of events fired. However, this
information is not necessary. The only benefit of this events counter is, you
know your client, SUL, is communicating with the server.
It is a good practice to analyze only one business process at a time since various
business process in a large enterprise application may involve various
protocols. For example, a dashboard in some application may have Ajax or Flex,
etc. but this will not be present on the login page.
Once youve finished executing a particular business process, you can hit the
Stop button. The VUGen protocol advisor will come up with a summary report
on the protocol suggestion. Have a look how it looks like:

You can see the suggestions from Protocol Advisor. These may or may not be
the best choices to pick.
Youve learned to use Protocol Advisor by now. However, this could be help for
beginners or for situation where you need another opinion rely on your

architectural sense, programming knowledge, development skills and

information received from development team to decide on the protocol.

Recording Options
Whenever VUGen generates a script, the code generated is based on various
configurations that can be found under the Recording Options or you can
press Ctrl + F7 to view the Recording Options.
Lets have a look at recording options window before we discuss all
configurations:

There are various categories of configurations like General, Correlations,

Network and Data Format Extension. Lets understand most significant among
these, one by one.

General => Recording:

This topic requires detail understanding. Hence this is discussed separately.
General => Script:
Have a look at the snapshot for a glimpse:

Youll notice that Language dropdown is disabled. A common myth is that the
LoadRunner does not generate code in any other language. Another myth is
that it requires a license to work in other languages.
Both are false. LoadRunner decides for itself which language to use when
generating the script. In almost all cases, youll find yourself working with C
Language.
For certain java applications (like Java applets) the code being generated will be
in Java Script Language.

VUGen will generate a script in VBScript Language only for applications

developed in Visual Basic classic (MS Visual Studio 2002)
Scripting Options:
You can opt to Generate fixed think time after end transaction. This means, no
matter how much a user wait, the think time generated (the delay) will be equal
to value specified. The value is in seconds.
Maximum number of lines in the action file refers to the maximum number
of lines VUGen will generate in an action. If the script is larger, VUGen will
automatically create a new action. The default is set to 60,000. The maximum
value which can be specified is 65,000
You may find this configuration helpful when dealing with a desktop application
with Oracle on the backend.
General => Protocol gives you an option to select and deselect any protocols
youve selected at the start of recordingp
Essentially, this will be used only when you wish to Re-Generate Script.
Have a look at the screen:

This is helpful when youve used multi protocols at the time of recording a
script. You can regenerate the script and deselect the protocols you dont wish
and get a new script without having to re-record it.
General => Code Generation:
Have a look at the snapshot below:

This configuration tells VUGen to find candidates for correlation at record time.
If you do not wish for Automatic Correlation, then you might wish to turn off
this feature.
Correlation => Configuration:
Have a look at the screenshot below and familiarize yourself with the screen.

Although automatic correlation is helpful from 5% to 10% only, yet you can
select Rules Scan and Automatically correlate values found. However, if your
script doesnt play, you can consider restoring to defaults by clicking on button.
Correlation => Rules:
Go to Rules, and here you can see various rules VUGen is using to find
correlation candidates. You can add custom rules if you know what your
application (SUL) is using as parameters. However, this is an advanced use of
record time settings. If youre a beginner, you can safely skip this topic.

HTTP Properties => Advanced:

This frame offers various settings related to HTTP binding.

Reset context for each action, enabling this option instructs VUGen to reset all
HTP contexts between actions to their initial state before recording, providing a
clean beginning for the recording session. The option is enabled by default.
You can leave the rest of configurations intact, unless required.

Network => Port Mapping:

This frame should be left intact. If youre recording a desktop application, then
you may have to choose WinINet level data.

You can go to Options (as long as youre using Socket level data) and select
various options like SSL version or other types of Secure Socket Layer. If youre

a beginner level or do not require these options, you can skip. Have a look to
get yourself acquainted with the screen.

Now youre done with most of the Record Time options, lets move to the next
topic and understand the difference between HTML and URL based scripting.

Difference between HTML-based and URL-based

Scripting
You may have noticed an options to pick either HTML-based script or URL-based
script. Have a look at the snapshot for a flashback.

So what is this option and which one to pick?

The HTML-based script is based on user actions, and the scripts contain
functions that correspond directly to the action taken. Lets understand
example of a small piece of code:
Example:
...
web_link(Enterprise Systems Performance",
"Text=Enterprise Systems Performance,"
"Snapshot=t4.inf",
LAST);
The URL-based script is based on HTTP requests sent to the server as a result
of user actions.
Here is an example of code for URL mode for the same actions performed as
above (in HTML mode)
Example:
...
web_url(Enterprise Systems Performance",
"URL=http://www.guru99.com/esp.html",
"TargetFrame=",
"Resource=0",
"RecContentType=text/html",
"Referer=http://www.guru99.com/atc?. . . ,
"Snapshot=t4.inf",

"Mode=URL",
LAST);
Tip: Its best to experiment yourself before you move forward. Change the
record time settings and record same script twice i.e. once with HTML mode
and once with URL mode then compare both. Keep the script short so you can
understand the difference.
How do we decide on which mode to use?
Lets understand the pros and cons of both modes so understand which mode
is more suitable under certain situations:
Benefits of HTML Recording

Reduces need to capture dynamic values

- Action tag values and hidden data are NOT hardcoded
- They are retrieved from memory during playback
- If they are dynamic, the VUser still run

Script is only as big as the business processone step per page

Disadvantages of HTML Recording

Scripts are less scalable

Memory (cache) is searched during playback
- requires more memory
- requires more CPU power

Benefits of URL Recording

Flexibility

- Support for Java Applets and ActiveX objects on the page

- Ability to replay on UNIX

Scalability

- Scripts are more scalable than HTML scripts because they require
fewer resources
Disadvantages of URL recording

Scripts require more correlation (nothing is retrieved from the cache)

Context-sensitive checks wont work (parser is disabled)*
Scripts are large (all images and frames are recorded as separate steps)

Here is a quick illustration:

HTML Mode

URL Mode

Intuitive and easy to understand

Not as intuitive as the HTML scripts

Scripts are smaller, requests are encapsulated and

easy to understand

Scripts are large, containing a call to each image, css, htm

it difficult to understand.

Scalable

More scalable and effective for creating a load test

Use of Re-Generate Script

Lets suppose you want to record the same script you just recorded, but with
different record time settings. In such a case, you can use the regenerate script
feature.

You can access it under Record => Regenerate Script or with hot key Ctrl+Shift+R

Once you click on the menu, VUGen will give you a warning that your existing
script and all changed youve made to your existing script will be lost. The
warning message looks like this:

You can also click on Options to open Record Time Options from here.
Click OK to proceed with Re-Generation of script.

Playback a Script and understanding Log

Once youve saved the script, you can click on the
hit F5.

in the toolbar to replay or

You can find this button in the toolbar:

You need to ensure the server is running (which is required for application to
work properly)
When you replay the script, youll notice that unlike QuickTest Professional, it
doesnt open any browser to replay. Remember, this execution will simulate
only 1 (single) user load on the SUL. The purpose of this execution is to ensure
your script is working.

Tip: Youll need to verify the impact from application itself. For example, if
youre creating a record, go to the application and verify manually that your
script actually created a record. Your scripts, most likely, will not be tested by
yet another Testing or QA team so you need to be very careful with your script
and ensure these are thoroughly tested.
You can leave the replay log active since this will be a great help in identifying
candidates for correlation and any errors and warning you might come across.
Since generating log takes ample resources, it is best-turned off when youre
done with debugging of scripts and using them for scenarios.

Overview of Files Generated During Record &

Playback
Lets close the VUGen and have a look at the files it has created in the script
folder.
VUGen creates a series of configuration files, data files and source code files
which contain VUser run-time and setup information. The results of each
iteration of the script are stored separately. If youve executed your script at
least once, you will notice a directory by the name result1. This directory is for
system use and should be ignored by the tester.
Important files which you need to understand:
VUGen will create one .c (C Language Code file) for each action. Thus, at the last
youll have vuser_init.c and vuser_end.c and Action.c if youve more actions
created, you will see corresponding files too. For example, myAction.c
The replay log is saved in a file called output.txt. If youve replaced it multiple
times, output.txt will contain the last execution log whereas, output.bak will
contain previous to the last run.
<script_name>.usr file will contain all the run time configurations youve
customized. Even if youve left all the configurations to default, this usr file will
contain the information. This file also contains the version of LoadRunner used
for creating script. This information is helpful if youre reading old scripts for
which you cant recall the version number.
You will see a folder named data. This folder keeps an image of the events as
well as copy of your code. VUGen makes use of these files when you
ReGenerate your code.

Advance VUGEN: Pamaretization,

Transactions, Functions, Run Time Setttings

A recorded script can simulate a virtual user; however, a mere recording may
not be enough to replicate the real user behaviour.
When a script is recorded, it covers single and straight flow of the subject
application. Whereas, a real user may perform multiple iterations of any
process before he logs out. The delay between clicking buttons (think time) will
vary from person to person. Chances are that some real users access your
application over DSL and some access it over a dial-up. So, in order to get the
real feel of end user, we need to enhance our scripts to be exact match, or at
least very close in behaviour to real users.
The above is the most significant consideration when conducting performance
testing, but there is more to a VU Script. How will you gauge the precise
amount of time taken by a VUser when SUL is undergoing a performance test?
How would you know if the VUser has passed through or failed at certain point?
What is the cause behind the failure, whether some backend process failed or
the server resources were limited?
We need to enhance our script to help answer all above questions.

Using Transactions
Understanding Think Time, Rendezvous Points and Comments
Inserting Functions through menu
Parameterization and it's configuration
Run Time Settings and their impact on VU simulation
o Run Logic
o Pacing
o Log
Think Times
Speed Simulation
Browser Emulation
Proxy

Using Transactions
Transactions are mechanics to measure server response time for any operation.
In simple words, the use of Transaction helps measure the time taken by the

system for a particular request. It can be as small as a click of a button or an

AJAX call upon losing focus from the text box.
Applying transactions is straightforward. Just write one line of code before
request is made to the server and close the transaction when the request ends.
LoadRunner requires only a string as transaction name.
To open a transaction, use this line of code:
lr_start_transaction(Transaction Name);
To close the transaction, use this line of code:
lr_end_transaction(Transaction Name, <status>);
The <status> tells LoadRunner whether this particular transaction was
successful or unsuccessful. The possible parameters could be:

LR_AUTO
LR_PASS
LR_FAIL

Example:
lr_end_transaction(My_Login, LR_AUTO);
lr_end_transaction(001_Opening_Dashboard Name, LR_PASS);
lr_end_transaction(Business_Workflow_Transaction Name, LR_FAIL);
Points to note:

Dont forget, you are working with C and that is a case-sensitive

language.

Period (.) character is not allowed in transaction name, although you can
use spaces and underscore.

If youve branched your code well and added checkpoints to verify the
response from the server, you can use custom error handling, such as,
LR_PASS or LR_FAIL. Otherwise, you can use LR_AUTO and LoadRunner will
automatically handle server error (HTTP 500, 400 etc.)

When applying transactions, ensure there is no think_time statement

being sandwiched or otherwise your transaction will always include that
period.

Since LoadRunner requires a constant string as transaction name, a

common problem when applying transaction is mismatch of string. If you
give a different name when opening and closing a transaction, you will at
least 2 errors. Since the transaction you opened was never closed,
LoadRunner will yield an error. Besides, the transaction you are trying to
close was never opened, hence resulting an error.

Can you use your intelligence and answer to yourself which of the above
error will be reported first? To validate your answer, why not make your own
mistake? If you had answered right, you are on track. If you answered wrong,
you need to focus.

Since LoadRunner automatically takes care of synchronization of

requests and response, you will not have to worry about response when
applying transactions.

Understanding Think Time, Rendezvous Points

and Comments
Rendezvous Points
Rendezvous Points means meeting points. It is just one line of statement that
tells LoadRunner to introduce concurrency. You insert rendezvous points into
VUser scripts to emulate heavy user load on the server.
Rendezvous points instruct VUser to wait during test execution for multiple
VUser to arrive at a certain point, so that they may concurrently perform a task.
For example, to emulate peak load on the bank server, you can insert a
rendezvous point instructing 100 VUser to deposit cash into their accounts at
the same time. This can be achieved easily using rendezvous.
If the rendezvous points are not places correctly, the VUser will be accessing
different parts of the application even for the same script. This is because
every VUser gets different response time and hence few users lag behind.

Syntax: lr_rendesvous(Logical Name);

Best Practices:

Prefix a rendezvous point with rdv_ for better code readability; e.g.
rdv_Login

Remove any immediate think time statements

Applying rendezvous points in a script view (after recording)

Comments
Add comments to describe an activity, a piece of code or a line of code.
Comments help make the code understandable for anyone referring to it in the
future. They provide information about specific operation and separate two
sections for distinction.
You can add comments

While recording (using tool)

After recording (directly writing in code)

Best Practice: Mark any comments on the top of each script file

Inserting Functions through menu

While you can directly write simple lines of code, you may need a clue to recall
a function. You can also use Steps Toolbox (known as Insert Function prior to
version 12) to find and insert any function directly into your script.
You can find Steps Toolbar under View Steps Toolbox.

This will open a side window, look at the snapshot:

Parameterization and it's configuration

A parameter in VUGen is a container that contains a recorded value that is
replaced for various users.

During the execution of the script (in VUGen or Controller), the value from an
external source (like .txt, XML or database) substitutes the previous value of the
parameter.
Parameterization is useful in sending dynamic (or unique) values to the server,
for example; a business process is desired to run 10 iterations but picking
unique user name every time.
It also helps in stimulating real-like behavior to the subject system. Have a look
at below example:
Problem examples:
Business process works only for the current date which comes from the server,
hence cant be passed as a hardcoded request.
Sometimes, the client application passes a Unique ID to the server (for example
session_id) for the process to continue (even for a single user) In such a case,
parameterization helps.
Often, the client application maintains a cache of data being sent to and from
the server. As a result, server is not receiving a real user behavior (in case server
runs different algorithm depending upon search criteria). While VUser script will
execute successfully, the performance statistics drawn will not be meaningful.
Using different data through parameterization helps emulates server side
activity (procedures etc.) and exercises the system.
A date that is hard-coded in the VUser during recording may no longer be valid
when that date has passed. Parameterizing the date allows VUser execution to
succeed by replacing the hard-coded date. Such fields or requests are the right
candidates for parameterization.
Please be patient. The Video will load in some time. If you still face issue
viewing video click here

Run Time Settings and their impact on VU simulation

Run Time Settings bear as much significant as your VUGen Script. With varying
configurations, you can obtain different test designs. This is why, you may end
up in non-repeatable results if Run Time Settings are not consistent. Lets
discuss each attribute one by one.

Run Logic
Run Logic defines the number of times all actions will be executed, except
vuser_init and vuser_end.
Probably this makes clearer why LoadRunner suggests keeping all the Login
code within vuser_init, and Logout part in vuser_end, both exclusively.
If youve created multiple actions, lets say, Sign in, Open Screen, Calculate
Rental, Submit Funds, Check Balance and logout, then, below scenario will take
place for each VUser:
All VUsers will login, execute Open Screen, Calculate Rental, Submit Funds,
Check Balance then again Open screen, Calculate rentalsand so on
iterating 10 times followed by logout (once).

This is a powerful setting enabling to act more like a real user. Remember, a
real user does not login and logouts every time he, usually, repeats same
steps.
How many times do you click inbox when checking you email before logout?

Pacing
This is important. Mostly people are unable to understand the different
between pacing and think time. The only difference is, pacing refers to the

delay between iterations whereas think time is the delay between any 2
steps.
Recommended setting depends upon the test design. However, if you are
looking to have aggressive load, consider opting As soon as the previous
iteration ends

Log
A log (as generally understood) is a bookkeeping of all events while you run
LoadRunner. You can enable log to know whats happening between your
application and your server.
LoadRunner gives powerful logging mechanism which is robust and scalable on
its own. It allows you to keep only Standard Log or a detailed, configurable
extended log or disable it altogether.
A standard log is informative and easily understandable. It contains just the
right amount of knowledge you will generally require troubleshooting your
VUser scripts.
In the case of Extended Log, all the Standard log information is a subset.
Additionally, you can have parameter substitution. This tells LoadRunner
component to include complete information of all the parameters (from
parameterization) including requests, as well as response data.
If you include Data Returned by Server then your log will go in length. This will
include all the HTML, tags, resources, non-resources information included right
within the log. The option is good only if you need serious troubleshooting.
Usually, this makes the log file very big in size and not easily comprehendible.
As you could have guess by now if you opt for Advance Trace, your log file will
be massive. You must give it a try. You will notice the amount of time taken by
VUGen has also increased significantly, although this will have no impact on the
transaction response time reported by VUGen. However, this is very advance
information and maybe useful if you understand the subject application, the
client to server communication between your application and hardware as well
as protocol level details. Usually, this information is dead by essence since it
requires extreme efforts to understand and troubleshoot.

Tips:

No matter how much time VUGen takes when log is enabled, it has no
impact on the transaction response time. HP calls this phenomenon as state
of the art technology.

Disable log if it is not required.

Disable log when you are finished with your scripts. Including scripts with
logging enabled will cause controller to run slower and report nagging
messages.

Disabling log will increase the capacity of the maximum number of users
you can simulate from LoadRunner.

Consider using Send message only when error occurs this will mute
unnecessary information messages and report only error related messages.

Think Times
Think Time is simply the delay between two steps.
Think Time helps replicates user behavior since no real user can use any
application like a machine (VUGen). VUGen generates think time automatically.
You still have complete control to remove, multiply or fluctuate the duration of
think time.
To understand more, for example, a user may open a screen (that is a response
followed by a request) and then provide it is username and password before
hitting enter. The next interaction of the application to the server will happen
when he clicks Sign In. The time a user took to type his username and
password is Think Time in LoadRunner.

If you are looking to simulate aggressive load on the application, consider

disabling think time completely.
However, to simulate a real like behavior, you can User Random Think Time
and set the percentages as desired.
Consider using Limit Think Time to a legitimate period. Usually, 30 seconds is
fairly good enough.

Speed Simulation
Speed simulation simply refers to bandwidth capacity for each client machine.
Since we are simulating thousands of VUsers through LoadRunner, it is amazing
how simple LoadRunner has made to control the bandwidth/network speed
simulation.
If you are customers access your application over 128 Kbps, you can control it
from here. You will get to simulate real like behavior which should help
getting the right performance statistics.

The best recommendation is to set to Use maximum bandwidth. This will help
disregard any network related performance bottlenecks and focus on any
potential issues in the application first. You can always run the test multiple
times to see varying behavior under different circumstances.

Browser Emulation
User experience does not depend upon the browser an end user is using.
Clearly, this is beyond the scope of Performance measures. However, you can
choose which browser you wish to emulate.

Can you answer to yourself when exactly it will really matter for you to select
the right browser in this configuration?
You will use this configuration if you are subject application is a web
application, returning different responses for different browsers. For example,
you get to see different images and contents for IE and Firefox etc.
Another important setting is Simulate browser cache. If you want to gauge the
response time when cache enabled, check this box. If you are looking for worst
case situation, this is obviously not a consideration.

Download non-HTML resources will let LoadRunner download any CSS, JS and
other rich media. This should be remained checked. However, if you which to
eliminate this from your performance test design, you can uncheck this.

Proxy
It is best to eliminate proxy completely from your test environment this will
make the test results unreliable. However, you might face situations where it is
inevitable. In such a situation, LoadRunner does facilitate you with proxy
settings.
You will be working (or should be working) with No proxy setting. You can
obtain it from your default browser. However, dont forget to check which
browser is set to default and what proxy configuration for default browser is.

If you are using a proxy and it requires authentication (or a script) then you can
click on the Authenticate button which leads to a new window. Refer to below
screenshot.

Use this screen to provide username and password to get authenticated on the
proxy server. Click OK to close the screen.
Congratulations. You are done with configuration your VUGen script. Dont
forget to configure it for all your VUser scripts.

Correlation in Loadrunner: Ultimate Guide

Correlation, as the name suggest, is a mechanism of defining relationship
between two variables or entities. Dictionary defines it as statistical relation
between two or more variables such that systematic changes in the value of one
variable are accompanied by systematic changes in the other.
Lets understand co-relation with the following scenario

Consider you are recording a script using Loadrunner

Client- Server Communication
1) During Record, client sends a request to the server to start a session
2) Server receives the request, and allocates a new session ID ABC
3) Client stores the session id ABC in the script.
4) Client start the session with ID ABC, and send request to server to allow it to
record
5) Server recognizes the ID ABC and allows client to record the script

Now, lets study the client server communication during replay

1) During Replay, client sends a request to the server to start a session
2) Server receives the request, and allocates a new session ID XYZ
3) Client start the session with previously recorded session ID ABC, and send
request to server to allow it to record

4) Server is unable to identify the ID ABC as it was expecting ID XYZ that it has
allocated and session fails.

We need a solution, which to capture parse the dynamic value sent at run-time
and return this value back to server. Here is how the client-server
communication will look like with this solution
1) During Replay, client sends a request to the server to start a session
2) Server receives the request, and allocates a new session ID ZZZ
3) Client parses this new session id ZZZ from the request.
4) Client sends a request to start session with id ZZZ
5) Server recognizes the ID ZZZ and allows client to replay the script

This is nothing but correlation.

Please be patient. The Video will load in some time. If you still face issue
viewing video click here
In case of VUGen, correlation is binding relationship between a response and
any preceding request.
There are various situations when a request is based on a previously received
response from the server, such as, a Session ID, server date/time which is
fetched from server. These values are different every time you run application
or record a script. Obviously, if the execution of script depends upon a value
returned by server, it means you need to find a mechanism where you can
catch the server response and attach to those requests which server expects.
This is typically called Correlation in LoadRunner.
In simple words, the solution by using Correlation is:
1. Capture output value from a step
2. Use above captured value to serve as input to all subsequent steps

Correlation is classified into 2 categories in VUGen/LoadRunner:

Automatic correlation
Manual correlation

Automatic Correlation
LoadRunner provides a mechanism to easily perform correlation in automatic
fashion.
VUGen will require you to run a recorded script at least 2 times so it can
internally compare the varying values in server response.
Automatic correlation can be classified into 3 categories:
1. Auto-Detect Correlation
2. Rule-Based Correlation
3. Correlating All Statements

Rule Name

When to Use

Auto-detect Correlation

Detect and correlate dynamic data for application servers supported b

Rule-Based

Used when working with a non-supported application server for whic

known.

Correlate All

Helps correlate all dynamic data in blind fashion.

Though Automatic Correlation seems simpler, it can be error prone and works
in not more than 5% of the cases. It is always advisable to use manual
correlation.
To configure automatic correlation at the time of recording, perform below
configuration in Record Time Setting after a script has been recorded.
Click on Record =>Recording Options (or click Ctrl +F7),

>
Below window will open:

Click on Correlation =>Configuration below window will open.

Here, you need to mark as checked against all applications (ASPNET) etc., which
are used in your subject application. On the right hand side, you can see the
rules which will detect possible candidates for correlation e.g. _VIEWSTATE. You
can also add more applications or custom rules by clicking on New Rule button.
You can also click on RULES, you will see as below:

In order for Automatic Correlation to work, you need to ensure Rules Scan is
marked as checked. If you click on automatically correlate values found, VUGen
will not prompt you with choice once a correlation candidate is found, instead,
it will just correlate them.
We will understand API used for correlation later. However, it is advisable to use
HTML comparison instead of text comparison.
Once youve selected any rules, click on OK button to close the windows.
Click on
from menu and VUGen will
regenerate script (without having to record) with new configurations. VUGen
will automatically add required piece of code to handle correlation. We will look
at the sample in more detail in Manual Correlation.

Please note, if you perform correlation manually or use automatic correlation,

the piece of code will contain exactly same syntax and function.
Steps to auto correlate a script:
1. Record a script
2. Replay script
3. Identify the values to be correlated
4. Select the values and click the auto-correlate button
5. Verify the script by running again. A successful run means successful
correlation.
Tip:
Correlation helps run your script with different values
Correlation also reduces the size of your script

Manual Correlation
Manual correlation is about writing code directly into your script to cater for
ever-changing values. We can split it into below steps:
1. Determine the value to capture
2. Find the right and left text boundaries of the value to capture (WEB)
3. Find which occurrence of the text boundaries should be used
4. Add a web_reg_save_param function to the script, above the piece of code
which requests the page with the value to capture
5. Add a parameter name, left boundary, right boundary, and occurrence to the
function

6. Parameterize the dynamic value in the script every time it occurs

7. Verify correct execution

Manual correlation can be done by VUser Comparison. Steps in VUser

Comparison method of Correlation can be split as below:
1. Identify Dynamic values that need to be correlated
2. Find Servers response containing the Dynamic value
3. Capture the Dynamic value in a parameter
4. Replace every occurrence of the Dynamic value with the parameter
5. Verify Changes

Understanding Web_reg_save_param
function
VUGen provides multiple functions or APIs to correlate candidates, including:
web_reg_save_param
web_reg_save_param_ex
web_reg_save_param_regexp

web_reg_save_param_xpath
While a brief introduction is being provided here, for detailed understanding of
functions and their parameters, open VUGen, write function (or use Steps
Toolbox), move cursor on the function and click F1 get yourself acquainted
with VUGen help and make a habit. You will have to deal with it a lot when
working in the industry.
Here we go with the function details:
web_reg_save_param(Parameter Name , Left Boundary , Right Boundary )
List of Attributes
Convert:The possible values are:
HTML_TO_URL: convert HTML-encoded data to a URL-encoded data format
HTML_TO_TEXT: convert HTML-encoded data to plain text format; this attribute
is optional.
Ignore Redirections: If "Ignore Redirections=Yes" is specified and the server
response is redirection information (HTTP status code 300-303, 307), the
response is not searched. Instead, after receiving a redirection response, the
GET request is sent to the redirected location, and the search is performed on
the response from that location.
This attribute is optional. The default is "Ignore Redirections=No".
LB:The left boundary of the parameter or the dynamic data. If you do not
specify an LB value, it uses all of the characters from the beginning of the data
as a boundary. Boundary parameters are case-sensitive. To further customize
the search text, use one or more text flags. This attribute is required. See the
Boundary Arguments section.
NOTFOUND: The handling option when a boundary is not found, and an empty
string is generated.

"Not found=error", the default value, causes an error to be raised when a

boundary is not found.
"Not found=warning" ("Not found=empty" in earlier versions), does not issue an
error. If the boundary is not found, it sets the parameter count to 0 and
continues executing the script. The "warning" option is ideal if you want to see if
the string was found, but you do not want the script to fail.
Note: If Continue on Error is enabled for the script, then even when
NOTFOUND is set to "error", the script continues when the boundary is not
found, but an error message is written to the extended log file.
This attribute is optional as well.
ORD: Indicates the ordinal position or instance of the match. The default
instance is 1. If you specify "All," it saves the parameter values in an array. This
attribute is optional.
Note: The use of Instance instead of ORD is supported for backward
compatibility, but deprecated.
RB: The right boundary of the parameter or the dynamic data. If you do not
specify an RB value, it uses all of the characters until the end of the data as a
boundary. Boundary parameters are case-sensitive. To further customize the
search text, use one or more text flags. This attribute is required. See the
Boundary Arguments section.
RelFrameID: The hierarchy level of the HTML page relative to the requested
URL. The possible values are ALL or a number. Click RelFrameID Attribute for a
detailed description. This attribute is optional.
Note:RelFrameID is not supported in GUI level scripts.
SaveLen: The length of a sub-string of the found value, from the specified
offset, to save to the parameter. This attribute is optional. The default is -1,
indicating to save to the end of the string.

SaveOffset: The offset of a sub-string of the found value, to save to the

parameter. The offset value must be non-negative. The default is 0. This
attribute is optional.
strong>Search: The scope of the search-where to search for the delimited data.
The possible values are Headers (Search only the headers), Body (search only
body data, not headers), No resource (search only the HTML body, excluding all
headers and resources), or ALL (search body, headers, and resources). The
default value is ALL. This attribute is optional but generally preferred.

You Might Like

How to use Controller in LoadRunner

Controller, as the name suggests, is a program to control overall load test. It is
responsible for helping you run your performance test design using the VUGen
scripts youve already created. It lets you over-ride run-time settings, enable or
disable think time, rendezvous points, add load generators and control the
number of users each generator can simulate. It automatically creates a dump
of execution results, gives you a live view of current state of load test running.
In this tutorial we will learn-

How to Launch Controller

Simulating a Manual Scenario
Simulating a Goal-Oriented Scenario
Configure Load Generators
Schedule a Group
Working with SLAs
Lets learn more about HP Controller.

How to Launch Controller

To launch HP Controller, go to Start Menu ->HP Software ->HP LoadRunner
->Controller as demonstrated below:

After youve launched, youll see a splash screen appearing momentarily. A

quick snap has been displayed below:

The snapshot will automatically lead to the main window of HP Controller. Lets
have a look at it before we discuss main components of the screen.

If the New Scenario screen doesnt come up automatically, (after youve

changed the preference) you can click on New button under File Menu or click
on
button from the toolbar. Alternatively, you can click Ctrl + N. The menu
has been displayed below for reference.

Similarly, to open an existing or previously created scenario you can use Ctrl +
O or
icon, and it will open standard dialogue box to browse files. The
extension of a Load Runner Scenario file is *.lrs
There are two types of scenarios in Controller.

Manual Scenario
Goal-Oriented Scenario

Manual Scenario can further may or may not have Percentage Mode. We will
discuss each in detail.

Simulating a Manual Scenario

A manual scenario is static in nature and gives more control over the situation.
You can decide which transaction to execute, for how many number of times,
for how long.
Based on the composition of test mix, you can see application behaviour such
as number of hits, response time etc.
You will find out how a manual scenario is different from Goal Oriented
scenario later.
In order to create a Manual Scenario, select Manual Scenario from Select
Scenario Type
For now, lets use non-percentage mode to begin with. Have a look at the
snapshot illustrated below:

You can select the scripts you wish to add to the scenario right from the above
screen. However, it is generally practised to add the scripts later.
Click the OK button to proceed.
This will create a blank scenario and load it into the main screen. You will notice
the Save button is enabled now. Have a look at the snapshot below:

Likewise, if you selected Percentage Mode while selecting type of scenario, the
screen will appear slightly differently. Instead of number of users, it will show
distribution of users in percentage. Controller distributes users per assigned
percentage automatically.

The rest is same. Refer to snapshot below:

If you do not create a Scenario at start, you will notice the toolbar as below:

You can click on

button to create a new blank Scenario. Once a scenario has

been created, you can click on

Likewise, you can click on
your local computer drive.

button to Save a scenario or click Ctrl + S.

button to open an already existing scenario from

The remaining button simply invokes other components of LoadRunner.

The

button invokes VUGen and

button invokes HP analysis.

Once you add a VUSer script or group, you will notice the subject toolbar will
show additional icons. The new toolbar will look like this:

The new toolbar has 2 additional controls.

The
button opens the list of all Load Generators. In our case, were using
localhost as generator. This means that your local machine will be used by
Controller as well as Generator to simulate virtual user load. The Network
Virtualization Settings can be opened by clicking on
icon. Network
Virtualization requires Shunra NV for HP Software version 8.6 or higher installed
in your machine. This integration enhances test accuracy by virtualizing
production network conditions in the load and performance test environment.
To incorporate Shunra NV for HP Software into your test environment, contact
your HP service representative.
Now that youve created a new, blank LoadRunner Scenario, please make a note
of
Default configurations of a new scenario:
Scheduled by: Scenario
Run Mode: Real World schedule

Since a VUsers script will be run by a group of VUsers, hence it is called a Group
as well. The Group Name column will show the name of VUser Script once
added. Lets add our VUsers scripts into this scenario.
When a scenario is completely created, you will see below toolbar under
Scenario Groups:

You can click on the

icon in the toolbar to add a VUser Group.

When you click on a cell under Group Name column, it will open a small box
i.e.
here you can see a quick list of recent VUser Scripts as
well as Browse button. Refer to below screenshot.

You can select from the list or simply browse from desired directory. If you click
the browse button, it opens a dialogue box similar to MS common dialogue box.
Refer to below snapshot:

As you can see, you can browser VUser Scripts, GUI Scripts or QTP Scripts here.
Please remember, a GUI or QTP script can only instantiate single user and
cannot be used for load simulation. Can you tell yourself why a QTP script is
available in Load Scenario?
Correct answer is, a QTP scripts can be added to Load Scenario for to extract
below information:
Since LoadRunner script works based on request and response, this doesnt
include UI and data rendering duration. A QTP script will give 1 sample of Real
user experience under load. Of course, the QTP script needs to have all the
transactions applied through descriptive programming.
If you right click on the grey area on the left, you will see a small menu
appearing as in below screenshot:

You can click on the Add Group to browse your VUser script.
To remove a group, simply click on
button in the toolbar or right click on the
group and select Remove Group as shown below:

Tip: You can also click on

button to view Run Time Settings specific to the
selected group. You can select multiple groups (by holding Ctrl + click) to apply
Run Time Settings to selected groups at a time.
From the toolbar, you can click on Details button [
details pertaining to a VUser Group.

] in toolbar to view all

If you click More, it will show you a panel with 3 tabs. 1st tab, Rendezvous, will
open by default:

You can also see the VUsers list in Vusers tab. If youve assigned IDs to VUsers,
youll see them here.

You can also see list of all files in the Script folder. This helps navigating all the
way to the end directory and see only relevant files.

We will study how to Schedule a group separately.

Once your scenario is ready, you can click on
button to start executing your
scenario. Once you click the play button, you will notice the Controller switches
from Design tab to Run tab.
Controller design view also gives view a script as you run the scenario. This is
helpful when you face errors. However, any changes you make in the script will
not be reflected to the running scenario. Even when the scenario is not running,
you need to view the details and click on REFRESH button for changes to take
effect.
You can view a script directly from Controller by clicking on

button.

Likewise, you can see the current VUsers (yes, you can actually view them) by
clicking on
button.
Once youre good with configuration, you can hit the
and click on

button or go to Run tab

button.

At the start of execution of the scenario, Controller will implicitly create a

temporary directory to dump the results. If the directory already exists, you will
get a prompt:

If you select Yes, the previous dump will be lost. If you select No, you will see
below window. You can opt to create a new directory for each result if you wish.
However, consider running out of space shortly after that.

As soon as you hit OK, your scenario will start running. You will see users
moving from Pending to Init columns and so on.
This is how an example execution will look like:

You can click on the Passed Transactions that opens a new window. Here you
can check the status of transactions which youve applied throughout your
scripts.
Similarly, you can click on any graph name on the left to open any graph.

In the bottom of the window, you can see which Transactions are passing, the
minimum time taken by any user thus far, the maximum time, average time and
standard deviation.
You can choose to collate results side by side or only after the end of scenario
completion. For toggle, click on the Results menu and you will find below menu.

If youve wish to enable collation, you can keep it checked.

Simulating a Goal-Oriented Scenario

A Goal Oriented scenario is dynamic in nature this means, it keeps changing
the overall load being simulate over the server. You set a Goal, for example, the
maximum number of hits you wish achieve for target server, maximum
response time against a transaction etc.
Based on above numeric, you can draw analytics such as maximum number of
users your application support while staying between acceptable response time.
Similarly, maximum number of users connected to application till X number of
hits to the server is reached.
In such a case, HP Controller automatically varies the number of users to the
server, thus, youve little control on how many number of times or for how long
a user runs.
Click New to create a new scenario and select Goal Oriented Scenario.
The following screen will appear:

Process of adding VUser Groups is exactly same as in case of Manual Scenario.

The key differences in Goal Oriented Scenario, as the name suggests, is to
create a goal. The Controller will automatically

While most of the interface is pretty much similar to Manual Scenario, certain
screen appear differently, although perform the same actions. For example, to
add a VUser Group or a VUser Script, click on the
will lead to below window:

button. This

Here you can select recent scripts, browser a script or hit Record button to
create a new script.
Click OK to close the window.
Per need, you can click
group/VUser Script.

button to view the details of selected

Clicking
button will remove the selected VUser Group from
current scenario. The changes will be saved only if you save.
Clicking
button will open the Run Time Settings, as we studied
in VUGen. However, if you override (or modify) the Run Time Settings here, the
changes will be effective only for current scenario. If you remove the script and
reload, or hit refresh (in Details View), you will lose any changes made. This will
reload the Run Time Settings saved while creating script.

You can also click on

VUGen.

button to open select VUser Group in

If you wish to configure Load Generators (our next topic) you can click
on

button.

Execution of a Goal Oriented Scenario is same as Manual Scenario.

Configure Load Generators

There are two ways to configure Load Generators.
When you click Add Group ( to add a VUser Script), you will see below window:

You can click on Add corresponding to Load Generator Name and browse your
Load Generators, or alternative, you can simply type localhost and start using
your controller machine as Load Generator.
If you click on add, you will see below window:

You can click on More to see more settings related to Load Generator. Navigate
through different tabs to build more understanding:

The above were configurations to Run-Time Settings. As you can see, a

maximum of 50 users can be initialized at one time.
Below is configuration of VUser Limit.

Click Defaults if you wish to revert to default settings and lose any changes
youve made. Click OK button to save changes and close window.
Another way of adding and configuring Load Generators is by
clicking Scenario menu and click Load Generators.

This will lead to main window of Generators. Here you can see the status of all
Load Generators. The name refers to the name of the Generator. The Status is
the current status, whether or not the generator is ready to be used. The
Platform tells the Operating System of the generator which can be Windows or
Unix only. The Type tells whether its local or Cloud based generator. Have a
look at the below snapshot:

To add another generator, you need to click on Add button. Once you click add,
you will see the same screen as already discussed above.
Once generator has been configured, click Close button to close the screen.

Schedule a Group
Before you run your scenario, you need to configure schedule. Either you
schedule by Scenario or by Group. Each of these, can further be categorized by
Real-world Schedule or Basic Schedule, called Run Mode.
If you schedule by Scenario and create a Real-World Schedule, you will see
below options appearing in Global Schedule area:

However, if you schedule a Scenario and create a Basic schedule, you will see
below window. Can you find difference?

You can also Schedule by Group. This will apply configuration to group level.
This can further be categorized as Real-world and Basic Run Mode.

Likewise, you can change the Run Mode to Basic Schedule. Use your Test
Designing skills to find the difference between the two. Here is a reference:

Did you notice a new icon appearing in the Scenario Schedule toolbar?
Here it is for your reference:
The Rendezvous icon is appearing only in case of Group configurations.

Working with SLAs

You may have signed a Service Level Agreement with your customers. The SLA
in LoadRunner or Controller, gives an opportunity to you to test your
application against an SLA. Keep in mind, a regular (non-SLA) scenario gives you
opportunity to run various types of scenario in order to find the problems and
root cause of problems; whereas, your customers might like to simply test your
application under an SLA to see whether it works as signed in contract or not.
From the main Design View of Controller, find the SLA toolbar; that is on the
right top corner and looks like this:

Click the

Click the

button and following window will open up:

button.

Notice the new window. Here you can select the Measurement of the SLA. In
our example, were taking Transaction Response Time. Have a look:

Click the

button.

In the next window, you can select the Transactions where the above
Measurement will be applied. Were using only main transaction i.e. 01_Signup
This will help remove opening main page and other not so important
transactions to be excluded.
Have a look at the window:

Click the

button.

In the new window, you can select the percentile of threshold value. If youve
selected multiple transactions, you can click
the below window:

button. Have a look at

Click the

button.

The next screen is a plain closure. Click the

button to close the SLA.

After you click

, you will see the main, Design Window of Controller
with an SLA appearing. Have a look:

You can click on the

open up:

Click

buttons to view SLA details. Following window will

button to close the above window.

If you wish to delete an existing SLA, you can click on the

clicking, you will get to see below confirmation message:

If you click on the

button. Upon

button, you will see Advance options of an SLA.

It is advisable that you work with default option i.e. Internally Calculated
Tracking Period. Have a look at the snapshot:

If you work with Internally Calculated Tracking Period, Analysis automatically

sets the tracking period at which SLA statuses will be determined. This option
has minimum tracking period set to 5 seconds.
On the other hand, you select Tracking Period to desired number of seconds.
Simply select the next radio button.
When executing an SLA based scenario, the execution process remain exactly
the same.
Video on Controller
Please be patient. The Video will load in some time. If you still face issue
viewing video click here

How to use Analyzer in LoadRunner

In this tutorial, we will study following topics1. How to use Analyzer in LoadRunner
2. Session explorer
3. Analysis Graphs
4. Merging Graphs
5. Add New Graphs
6. Crossing with Results
7. Saving a Session
8. Exporting into HTML Report

Lets begin-

1. How to use Analyzer in LoadRunner

HP Analysis, as the name suggests, is a program to perform detailed (literally,
very detailed) analysis on the performance test youve carried out.
HP Analysis takes the dump created by Controller, during execution of your load
test. The dump contains all the information in raw format which is parsed by HP
Analysis to generate various graphs.
Lets learn more about HP Analysis.
To launch HP Analysis, go to Start Menu =>HP Software =>HP LoadRunner
=>Analysis as demonstrated below:

This will launch Analysis. As usual, at first a splash screen will open as shown
below:

After a moment, this splash screen will automatically lead to the main screen of
HP Analysis. The main screen will open in restored mode. Refer to below
snapshot:

Click on the File menu and you will see a list of menus as in below snapshot:

Click on the File Menu or use Ctrl + N to open create analysis session. This will
open a dialogue box to help you locate the lrr file. The file extension, LRR stands
for LoadRunner Results.
Remember HP Controller creates a repository of results in a folder? That folder
contains the lrr file.
Locate the res folder of the scenario for which you wish to create analysis
session. A snapshot has been provided below for reference:

As soon as you select the correct file, HP Analysis will first check for available
disk space to ensure you dont run out of space during the process. This is
because the size of a session can be very large especially for complex scenario
where youve included multiple VUScripts and run for long hours.
Below window will open momentarily:

Immediately after affirming availability of disk space, HP Analysis will come to

action and you will see a currently analyzing window, as shown below:

The time taken by above window depends upon the size of result folder (or
statistics contained in that folder)
If it takes way too long, or gets stuck, you can opt to cancel by clicking on the
cancel button.
Once finished, this will automatically lead to a quick window where format
template will be applied:

This should quickly lead you to main window of Session Explorer. However, if
youre using some complex custom template and the operation halts for any
reason, you can click on the Stop button to cancel the operation and start over.

2. Session explorer
Once the operations completes, you will see main session window which looks
something like this:

Here you can see the directory where you picked up the results from.
You can also see complete information about your scenario within Analysis
session. In the Summary Report tab, you can see the duration of the scenario
which was run to get these results.
The term percentile is used in analysis almost with every graph. You can define
the value for percentile in the properties panel. The default is set to 90.

Notice the graph section in Session Explorer:

There are few graphs appearing already. You can click on the graph name and
you will see its details appearance.
From the Summary Report, you can click on the button to open its SLA related
information, if available.
Upon clicking, you will see the below window:

You can locate the toolbar just below File menu on the top, it looks like this:

All the buttons in the toolbar perform some action from within the File menu.

HP Analysis contains every bit of information about your scenario, including

Run time Settings. As youre aware by now that Run Time Settings have
significant impact on performance, you can view the settings from within
Analysis which were used to run the scenario.
To view the Run Time Settings, click on
File Menu or

button from the toolbar.

The Run Time Settings will be displayed as below:

from the

As you can see, not only all the settings can be seen from within this window,
you can also open the Schedule by clicking on

button or view

script by clicking on
on

button. To close the window, click

button.

3. Analysis Graphs
HP Analysis will load most important graphs at the time of Analysis. You can
click on any graph name from the Session Explorer to view details against
available graph.
Lets discuss few graphs one by one.

3.1 Average Response Time graph:

This graph displays the number of hits made on the Web server by VUsers
during each second of the load test. This graph helps you evaluate the amount
of load VUsers generate, in terms of the number of hits.

Have a look at graph of our scenario:

When viewing a graph, it is pivotal to understand the graph legend side by side.
The Legend shows the transaction name, its color, minimum value, average
value, maximum value and standard deviation (variance around the mean).
The colors of the graph can be recognized from the Legend.

3.2 Hits Per Second graph:

This graph displays the number of hits made on the Web server by VUsers
during each second of the load test. This graph helps you evaluate the amount
of load VUsers generate, in terms of the number of hits.
Have a look at the graph in case of our scenario:

As can be seen from graph as well as legend, that there were times where there
were no hits to the server.

3.3 Running VUsers graph:

This graph displays the number of VUsers that executed VUser scripts, and their
status, during each second of a load test. This graph is useful for determining
the VUser load on your server at any given moment.

3.4 Throughput graph

This graph displays the amount of throughput (in bytes) on the Web server
during the load test. Throughput represents the amount of data that the VUsers
received from the server at any given second. This graph helps you to evaluate
the amount of load VUsers generate, in terms of server throughput.

Here is description to some more graphs:

3.5 VUser Summary:

This graph displays the number of VUsers that completed their run successfully,
stopped their run, or ended with errors. This is how it looks like:

3.6 Rendezvous graph:

This graph Indicates when VUsers were released at rendezvous points and how
many VUsers were released at each point. This is how it looks like:

3.7 Transactions Per Second graph:

This graph displays the number of completed transactions (both successful and
unsuccessful) performed during each second of a load test. This graph helps
you determine the actual transaction load on your system at any given moment.
This is how it looks like:

3.8 Total Transactions Per Second graph:

This graph displays the total number of completed transactions (both successful
and unsuccessful) performed during each second of a load test. This graph
helps you determine the actual transaction load on your system at any given
moment. This is how it looks like:

3.9 Transaction Summary graph:

This graph displays the number of transactions that passed, failed, stopped, or
ended with errors. This is how it looks like:

3.10 Transaction Performance Summary graph:

This graph displays the minimum, average, and maximum response time for all
the transactions in the load test. This is how it looks like:

3.11 Transaction Response Time Under Load graph:

Displays average transaction response times relative to the number of VUsers
running at any given point during the load test. This graph helps you view the
general impact of VUser load on performance time and is most useful when
analyzing a load test which is run with a gradual load. This is how it looks like:

3.12 Transaction Response Time Percentile graph:

This graph displays the percentage of transactions that were performed within a
given time range. This graph helps you determine the percentage of
transactions that meet the performance criteria defined for your system. This is
how it looks like:

3.13 Transaction Response Time Distribution graph:

This graph displays the number of times a transaction was completed over a
distribution of time ranges. Note that this graph only displays information for a
single transaction at a time. This is how it looks like:

3.14 Throughput (MB) graph:

This graph displays the amount of throughput (in megabytes) on the Web server
during the load test. Throughput represents the amount of data that the VUsers
received from the server at any given second. This graph helps you to evaluate
the amount of load VUsers generate, in terms of server throughput. This is how
it looks like:

3.15 HTTP Status Code Summary:

This graph displays the distribution of the various HTTP protocol status codes
returned from the Web Server during the load test. This is how it looks like:

3.16 HTTP Response Per Second graph:

This graph displays the number of the different HTTP status codes returned
from the Web server during each second of the load test. This is how it looks
like:

3.17 Pages Download Per Second graph:

This graph displays the number of pages received from the Web server during
the load test. This is how it looks like:

3.18 Connections graph:

This graph displays the number of Connections. This is how it looks like:

3.19 Connections Per Second graphs:

This graph displays the number of Connections per Second. This is how it looks
like:

3.20 Page Component Breakdown (Over Time) graph:

This graph displays the average response time (in seconds) for each Web page
and its components during each second of the scenario run. This is how it looks
like:

3.21 Page Download Time Breakdown (Over

Time) graph:
This graph displays a breakdown of each page component's download time
during each second of the scenario run. This is how it looks like:

3.22 Time to First Buffer graph:

This graph displays each Web page component's relative server/network time
(in seconds) during each second of the scenario run, for the period of time until
the first buffer is successfully received back from the Web server. This is how it
looks like:

4. Merging Graphs
Two graphs maybe required to be merged to bring more meaningful
information. For example, as we discussed above in graphs that when there
were no hits to the server, there was also no bandwidth over the network.
This can be more easily drawn when merging.
Lets see how graphs are merged.
Before you open the graph merging option, ensure you have at least one graph
opened already, which you wish to merge. The utility will assume you want to
add another graph to the already opened graph.

To open the merge graph window, go to View menu and click on Merge Graphs.
Here is how the menu looks like:

Clicking above menu will open the main window of merging graphs, here is a
snapshot:

Here, were merging Transaction Response Time with Running VUsers graph.
The Merge Graph window requires you to provide the name of newly formed
merged graph.
Here is how this merged graph looks like:

5. Add New Graphs

To add new graph, click on the Graph menu and select Add New Graph.
Refer to below snapshot of the Menu:

Once clicked, it will open a list of all graphs available in LoadRunner (HP
Analysis)
You can select any graph by double clicking on its name. This will load the graph
with values/statistics to the main window of HP Analysis.
Click Close button to go back to the main window.
Lets have a look at the window:

6. Crossing with Results

If youve multiple scenario run already, you can use their results folder to cross
match the statistics. This process helps directly compare both results and
generate cumulative report.

In order to perform Cross results, click on

with Results from the File Menu.

icon from the toolbar or click Cross

This will open below window:

The Result List is showing your current results folder (for which the analysis is
being performed)
You can click on the Add button to add another result folder with which a cross
will be analysed.

Select the other result folder and click on Open.

The previous Results List window will be open again. This time you will have 2
result folders in the list.
Have a look at the window:

Click on the OK button.

A new window will open containing side by side comparison of both results.
Here is a snapshot:

You can add as many result folder in cross list as you wish, however, this will
become complicated to understand and analyse. So it is suggested to keep the
list short.

7. Saving a Session
Working with HP Analysis may take significant time. Since you may have merged
graph or currently studying some new graph, it is a good idea to keep your
session information saved.
To save your session, simply click on the File Menu and click on Save.
Below dialogue window will open:

Clicking the Save button will initiate the Save process which could be instant or
time consuming, depending upon the size of session.
Here is what the window looks like:

7.1 Opening a Session

You can open an existing session in similar way. Simply click Open under File
Menu and select the folder of saved session. Remember, HP Analysis will not
open the last folder node; rather it will open the folder itself.

This will open the main window of Analysis where you can resume your work.

8. Exporting into HTML Report:

HP Analysis provides a feature to export all data into a well formatted HTML or
doc format report. To export, click on the Report menu and select HTML Report.
Have a look at the menu below:

This will open a dialogue box to locate the directory where HML report will be
placed.

Have a look at the screen snapshot below:

As soon as you click the Save button, HP Analysis will start exporting results and
preparing a report in HTML format. A splash screen will appear for a short
period, depending upon the size of report youre exporting:

After the export finishes, it will immediately open the recently exported HTML
file in Internet Explorer or your default browser. Here it how your 1st
Performance Testing Report looks like:

Video on Analyzer
Please be patient. The Video will load in some time. If you still face issue
viewing video click here

You Might Like