Checklist for LoadRunner Scripting

19/09/2008

Performance Testing / BFS / Automation Testing Guruprasad R Sivaram C Shrikrishna Jumbad Suvarna Sri S Mythili B guruprasad.r@tcs.com sivaram.chandrasekaran@tcs.com shrikrishna.jumbad@tcs.com suvarna.s@tcs.com mythili.b@tcs.com

TCS Public

Introduction
Load Runner is an industry standard tool for performance testing and plays a vital role in many of the OLTP applications testing during their performance testing phases. This document is intended to cover the checkpoints that are to be verified while scripting using Load Runner for load simulation and performance testing. The checklist will help to improve the quality of the LoadRunner scripts with respect to maintainability and to reduce the number of scripting defects there by improving the accuracy of the test results. Need for a checklist Usage This checklist can be used before and after scripting Before scripting: To add common settings and to follow the conventions there by improving the maintainability and consistency of the scripts After Scripting: To use this as a tool during review to check for compliance to the standards / conventions and to make the scripts more defect free To enhance the reusability of the scripts To have the consistency among the reusable scripts To minimize the occurrence of common defects

Load Runner Details This Checklist can be used for LoadRunner scripting when using HTTP / HTML protocol and with Load Runner Version 8.0 and above Stages defined for Scripting The following stages are considered in defining the checkpoints for each stage of scripting: Pre Recording Stage Recording Stage Post Recording Stage Script Debugging Script Delivery

TCS Public

Pre Recording Stage

Before recording, it is a best practice to manually navigate through the applications web pages to be recorded and identify the steps to be recorded. It is good to follow the naming conventions as given below for Transaction names, name of the action file, input parameters and script name as a whole. Naming Conventions Input Parameters Input parameter names should be in mixed case starting with upper case with no space within every parameter name (OR) use Hungarian Notation (refer http://msdn.microsoft.com/en-us/library/aa260976.aspx) Example: AccountName Correlated Parameters Correlated parameter names should be in mixed case starting with lower case. Every correlated parameter name should be prefixed with cp_. Example: cp_subportfolioDisplayName Script Name Script Name should be a meaningful name and be self explanatory of the functionality. Example: PE_04_UE_SEARCH_AN_ACCOUNT In this example, the script name is self explanatory to reflect the Account Search functionality being scripted It is a good practice to prefix the script names with a module / track identifier for easy categorization Example: PE_04_UE_SEARCH_AN_ACCOUNT In this example, as the functionality belongs to the module / track called UE (User Experience), the script has been prefixed with UE as module / track Identifier.

TCS Public

It is a good practice to prefix the script names with a script code. Example: PE_04_UE_SEARCH_AN_ACCOUNT In this example, Script Code #04 is used to easily identify the script with a code, rather than the script with a lengthy name.

Input DAT file. Input DAT file name should be a meaningful name and must be similar to the script name.

It is a good practice to start Output message using lr_output_message with the string LOG for easy identification during debugging. However too many unnecessary usage of this may slow down the script run and hence this needs to be used judiciously. Action files Action file names must match with the script name. This will help in identifying the action in the results while running with multiple actions in a single load testing scenario.

Transaction Name It is a good practice to follow the below mentioned naming conventions. This will help to maintain the sequence of steps carried out within a script and the consistency across scripts while running in a multi script scenario. Transaction names in every script should be in upper case with an underscore to separate words. Example: PE_04_02_SEARCH_ACCOUNT Transaction names should be prefixed with a running sequence number to easily determine the sequence of steps simulated using LoadRunner. Example: PE_04_02_SEARCH_ACCOUNT PE_04_03_SELECT_ACCOUNT Transaction names should be prefixed with the script code. This helps to map the step name with the appropriate script it belongs to. Example: PE_04_02_SEARCH_ACCOUNT

TCS Public

Header Information The header for each script will be helpful in identifying the functionality and debugging and it can have the following format as an example. /* --------------------------------------------------------------------------------------------------Script Title : PE_02_CASH_DISBURSEMENT_CHECK Script Description : This script is to automate Adhoc (one time) Currency Disbursement by Check Method Original Recording Env : DB env Original Recording Codedrop : 11.1 IT Original Recording Date : Jan 29th 2007 Recorder Version :1 Author : Guru Prasad R ------------------------------------------------------------------------------------------------------*/

Recording Stage
Settings The following settings have to be made before recording the script in New Load Runner Script

Check whether InternetExplorer > Tools > Internet options > General > Settings > Check for newer versions of stored pages option is set appropriately. Check whether all the VuGen > General Options are set correctly.

Display > Show browser during replay option can be

unchecked while scripting, as checking this option will slow down the script rerun in VUGEN as well as Run-Time Viewer is error prone. However for debugging purposes, View > Test Results in menu bar can be used after the script run. Keep other settings as default.

TCS Public

Check whether all the Recording Options are set correctly. Make sure that the option, General > Recording is set to URLbased script, in case HTML mode is not suitable for the given web application to capture all the events. Make sure that the option, URL-based script > Advanced > Create concurrent groups is unchecked. Make sure that the option, HTTP Properties > Advanced > Generate web_reg_find functions for sub-frames is checked. This is like a verification checkpoint. This registers a search for a text string for the very next Action function in the script.

Make sure that the option, General > Script > Generate fixed

think time after end transaction is checked and the value is set to a predefined value. This can be used to simulate the think time taken by the end user during any real time scenario testing.

Make sure that the option, General > Think Time > Ignore think time is selected by default. This can be unchecked if the recorded think time needs to be replayed during any real time scenario testing, which can be done from the controller during the run. Make sure that the option, General > Script > Generate fixed think time after end transaction is checked and the value is set to a predefined value. Make sure that the option, General > Script > Generate think time greater than threshold limit is unchecked. Check whether all the Runtime Settings are set correctly as per the scripting requirement. Make sure that the option, Browser > Browser Emulation > Check for newer versions of stored pages every visit to the page is checked / unchecked as per the requirement of the application under test.

Record the scenario as different steps or transactions with begin (vuser_init) & end (vuser_end) captured. Capture every server conversation as a different transaction. This can be done by capturing appropriate user button click event, list box selection event, hyperlink click event, etc. (whichever gets server response and / or refreshes the page) as a separate transaction.

TCS Public

While recording a new script, ensure that the name for the script and the transaction names within the script follow the naming conventions. Make sure that all the events are captured while recording. Make sure that both the Recording log and the application windows are seen while recording .This will help you to end the transaction correctly (i.e.) just after connection terminated by server appears in the recording log window.

Post - Recording Stage

Ensure that lr_think_time() is present outside the transactions as it may add to transactions time otherwise. Comment out the unnecessary cookies (web_add_cookie) which might have got recorded due to plugins like google / yahoo toolbars, but retain the application specific cookies for successful rerun of the script. Check whether all the lr_start_transaction have their corresponding lr_end_transaction Rename the Action file with the corresponding script name. Parameterize the static values and correlate the dynamic values as per the requirements.

Parameterization While parameterizing, it is always good to keep the related parameters as a group and each group in a separate DAT file. For Example: All Environment related information like URL, userId, password etc parameters can be kept in one DAT file and must be named as Env.dat. All transaction related information like account name, processing date and description code must be in one DAT file and give the DAT file a meaningful name like Transaction.dat file.

In Parameter List, select row selection option as follows: Select Column: By name <column_name> Select Next Row: <Unique> or <Sequential> for the first column depending on the requirements. Choose Same line as FirstColumnName for rest of the parameters. Update Value on: <Each Iteration> When out of values: <Continue in a cyclic manner> or <Abort Vuser> depending on the requirements.

TCS Public

Parameterize the static values and correlate the dynamic values as per the requirements. Degree of script reusability depends on the quantum of parameterization and correlation.

Result Verification Every script should have success criteria for result verification. Example: Add the below mentioned function to search for the activity Id / confirmation Id in case of financial transactions scripting. This will make sure that an activity is created and hence the transaction is successful. Add this function just before the submission of Confirmation page. web_reg_find ("Text=Confirmation", LAST); OR web_reg_find ("Text=Activity ID, LAST); In addition to the success criteria, at times it may be needed to verify / validate the failure cases. Example: When the exact error message is known beforehand, this can be verified as follows: web_reg_find ("Text/IC=Error", "Fail=Found", LAST); After running the script for every iteration, validate the Test Results output against the expected output. Test Results can be viewed using file menu option, View > Test Results. This can be achieved by going through the screen shots in the Test Results output. Results also can be verified from Application Server logs and / or DB tables for the updates, if the access to the application environment is available.

Script Delivery In RunTime settings, set the number of Iterations to 1. Best practice is to deliver the script after identifying, validating with multiple parameter values and testing with couple of concurrent user scenario Delete the unnecessary DAT files, result folders created because of multiple run iterations in VUGEN, unnecessary logs files and index files.

TCS Public