Loadrunner Standards
This material is a set of standards, which can be used across a variety of protocols very successfully.
They are based on training I was given 15 years ago by a company called Starbase who specialise in performance testing training.
The aim is to standardise across the LoadRunner process from virtual user names through to the analysis names used. By standardising in this way you introduce consistency, quality, version control and efficiency in a proven standard.
Throughout the document we are going to use abbreviations to represent the type of data to be used. Here is a brief list of the abbreviations and their descriptions.
aa - The application abbreviation
nn - Two-digit number to make the user unique.
vv - Two-digit version number
pp - The project abbreviation
ss - Two (or more) digit sequence number of the step
s - The letter s indicates a scenario
r - The letter r indicates a run/result
nnn - Three-digit unique scenario number
nnnn - Four-digit unique run/result number
Naming – Application Abbreviations
To endeavour to standardise from the start of the project we need to define an abbreviation, which will be used throughout the performance testing to reference the application under test. This is usually a two (or more) alphanumeric character representation (aa). Ideally, a log of the abbreviations used should be maintained centrally to avoid duplication.
aa - a two (or more) alphanumeric character representation
Examples:
abcd
efg
If the project is implementing multiple applications you may want to include a higher project abbreviation (pp) and although the application abbreviation will usually be the same as the project abbreviation, this standard allows for multiple applications to be tested within the same project.
Naming – Virtual User Scripts
Many people try to use the virtual user’s name to describe what the user does; this can lead to very long names and the associated issues such as identifying users. By keeping the name of the virtual user concise and using a database or a spreadsheet to provide a description of what the user does is the best approach.
A virtual user name is made up of the application abbreviation (aa) and a two-digit number (nn) to make the user unique (aann).
aann - application abbreviation and a two-digit number to make the user unique.
Examples:
abcd01
efg01
During script development the virtual user script name indicates the development version (aann_vv). E.g. abcd01_01. The version numbers used are as follows: -
00 – Vanilla (un-modified) recording
01 – Development version 1
02 – Development version 2
Once the script has been finalised it is renamed to the application abbreviation and a two-digit number e.g. abcd01 and saved into the Live directory.
Naming – Action files
Within the virtual user script the action files should be renamed to make the virtual user clearly identifiable in the LoadRunner results. For this purpose the Virtual User name and Business Process short description are used (aann_BusinessProcess).
aann_BusinessProcess - the Virtual User name and Business Process short description.
Examples:
abcd01_Login
efg01_GetEmployee
For types of vusers where the action cannot be renamed add a transaction in the format aann_BusinessProcess e.g. abcd01_Login to wrap the contents of the action.
Naming – Steps
Each call within the virtual user script is referred to as a step. By renaming these steps we can make the business action and virtual user clearly identifiable, enabling them to flow in the correct sequence in the LoadRunner results. The step name details the Virtual User and the Business Action of the step. (aann_ss_BusinessAction).
aann_ss_BusinessAction - the Virtual User and the Business Action of the step.
Examples:
abcd01_0010_Login
efg01_0010_GetEmployee
For types of vusers where the steps cannot be renamed add a transaction in the format aann_ss_BusinessProcess e.g. abcd01_0010_Login to wrap the contents of the step.
Naming – Transactions
The transaction name details the Virtual User and the Business Actions it is timing (aann_ss_BusinessActions).
aann_ss_BusinessActions - the Virtual User and the Business Actions it is timing.
Examples:
abcd01_0010_Login
efg01_0010_GetEmployee
Naming – Scenarios
The Scenario name is kept short and unique (snnn). All scenarios should begin with the letter s and then have a unique id assigned to them. Every time changes are made to a scenario the scenario name should be changed.
snnn – the Scenario unique id.
Examples:
s001
s035
Naming – Runs/Results
The run/result name is kept short and unique (rnnnn_snnn). All runs/results should begin with the letter r and be followed by a unique run/results number. This is then adjoined with the scenario name.
rnnnn_snnn - the Run/Result unique id and Scenario unique id.
Examples:
r0001_s001
r0099_s010
Naming – Analysed Results
The analysed results name is the run name with an optional version number (rnnnn_snnn_vv).
rnnnn_snnn_vv - the Run/Result name with optional version.
Examples:
r0001_s001_01
r0099_s010_02
Naming – Summary
Application Abbreviation
aa
Virtual Users
aann and aann_vv
Action Files
aann_BusinessProcess
Steps
aann_ss_BusinessAction
Transactions
aann_ss_BusinessActions
Scenarios
snnn
Runs/Results
rnnnn_snnn
Analysed Results
rnnnn_snnn_vv
Directory Structure
A standardised directory structure has been devised to house all of the performance documentation, results, script and scenarios. By using this structure it will enable the ease of sharing between a team. It also adds a level of professionalism and enables the customer to understand the results of performance testing between different projects.
A visual basic script has been created which will create this structure for you on a controller and/or injector.
project
aaLoadtest - Main directory for application aa
analysed - Contains analysed results
docs - Contains the Load test documentation
reports - Contains the html-format & word-format results reports
results - Contains the results
scenarios - Contains the scenarios
vusers - Contains the Virtual Users
dev - Contains the Virtual Users being developed
live - Contains the “Live” Virtual Users
vanilla - Contains the “Vanilla” Virtual Users
If the project is implementing multiple applications you may want to use the project abbreviation (pp) instead of the application abbreviation (aa), this standard allows for multiple applications to be tested within the same project.
The analysed, results and scenarios directories have the following sub-directories:
calibration – for calibration scenarios
runs – for standard scenarios
The vusers/dev and vusers/live directories each have a shared sub-directory to contain data that is shared amongst vusers.
The report directory can be shared on the network so that all interested parties can view the html reports.
Change Control Life Cycle
Initial Recording
aaLoadTest\vusers\vanilla\aann_00
Enhancements
aaLoadTest\vusers\dev\aann_01, 02, 03
Live
aaLoadTest\vusers\live\aann
Redevelopment
aaLoadTest\vusers\dev\aann_oo, pp .. zz
Live
aaLoadTest\vusers\live\aann