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