LoadRunner Scripting Standards

by

Working on LoadRunner is one thing, but doing quality work is another important thing which is possible only by following the LoadRunner scripting standards. Many performance testers are LoadRunner experts but still lack scripting quality. This article will help you understand the LoadRunner Scripting Standards.

Naming Convention:

Script Name

If your project follows releases or sub-releases, then the script’s appropriate naming helps to differentiate the scripts used in the specific release. The name should be given like below:

<ReleaseNumber>_<SubReleaseNumber>_<TestCaseName>_<Version>

Example: R13_2_OrderSubmission_V01

Scenario Name

If your project follows releases or sub-releases then the scenario’s appropriate naming helps to differentiate the scenario used in the specific release. The name should be given like below:

<ReleaseNumber>_<SubReleaseNumber>_<Environment>_<ApplicationName>_<TestType>_<NumberOfScripts>_<NumberOfVUsers>_<Duration>_<Version>

Example: R13_2_PreProd_CoreBanking_Soak_5_500_10H_V01

Transaction Name

Another important naming convention that helps to make quality script.

<TestCaseName>_<TransactionNumber>_<TotalNoOfSteps>_<StepName>

Example:

OrderSubmission_01_15_Login

OrderSubmission_02_15_SearchProduct

  • Do not use hyphens or spaces in transaction names. Use underscores instead.
  • Use an underscore between elements and Camel Case notation (no underscores, no spaces) for the step description. Camel case is a writing convention that uses capitalized letters to separate words in a phrase without using spaces, dashes or underscores like SearchProduct, SubmitOrder etc.
  • Script numbers and step numbers have one or two leading zeros according to the total number of steps. Example: 01 or 001.
  • The use of “_Click” and similar suffixes describing the action on control is now deprecated for LoadRunner scripting. Only four controls are used: tab (for menu options), buttons, links, and select (for dropdown).
  • Keep the transaction names short. Long transaction names can make some LoadRunner reports wrap the transaction name to the next line. This makes it difficult to paste the results into Excel and sort by response times or errors. Particularly if you need to include that transaction name on a graph (e.g., response time as a function of users or throughput), long names are a significant handicap.
  • Use abbreviations in the descriptions by omitting the vowels from the word. E.g.
    • BU_ = Business Unit
    • LkUp = Look up
    • Ctrl = Control
    • Prjt = Project
    • Acct = Account
    • PO = Purchase Order
    • PR = Purchase requisition
    • LI = Line Item
    • PrcsMon = Process Monitor
    • Save = ClickOnSaveButton
  • Mouse clicks which contain no code in the LoadRunner recording should not be given a transaction number or name because these are client-side JavaScript actions and do not make calls to the server.

Variable Name

  • User Defined Parameter files should be created as per the below points
    1. Create the required parameter file and select the file type as per the requirement.
    2. Follow the naming conventions for creating the parameter file as below.
      • Add “p_” before the parameter starts to differentiate from the correlation value
      • Use camel case notation.
        eg. {p_UserName}, {p_OrderID} etc.
  • Correction Variables:
    1. Follow the below naming conventions for a correlation function.
      • Add “c_” before the parameter starts to differentiate from the correlation value
      • Use camel case notation.
        eg. {c_OrderNumber}, {c_SessionID} etc.

Scripting Guidelines

General Guidelines

  • Record the application as per the approved test case or flow document.
  • Write the below section to provide the script details at the beginning of the vuser_init section.
/*********************************************************
Script Title: 
Test Case ID / Name:
Script Author:  
Created Date:  
Notes:  
*********************************************************/
  • Do a write-up of the script flow in the vuser_init section.

  • Do not comment the ‘EXTRARES‘ and other Sub calls.
  • Do comment only the calls which are not related to the application. These calls might be third-party calls like Google etc.
  • Comment the cookies in case there is no specific scenario where you have to provide the cookies explicitly.
  • As suggested above, the transaction names should have the same structure and follow the chronology.
  • Usage of PassFailExit Function

PassFailExit Function

It is used for Error Handling. PassFailExit function will be written as a separate action file. Below are the text checks we will perform for the error handling mechanism.

PassFailExit(“OrderSubmission_01_15_Login”,” Please Log In“);

Text check name which is used in the below code

web_reg_find(“Text/IC=500 server error“, “savecount=errchk“,LAST);
web_reg_find(“Text/IC=Please Log In“,”savecount=txtchk“,”Search=All“,LAST);

“500 server error” is to validate the HTTP return code of the calls and the next one is for validating the page’s response.

These 2 return codes will be sent as a part of the parameter in the PassFailExit function for error handling.

PassFailExit function will be written at the end of the transaction instead of lr_end_transaction();

The lr_end_transaction(); will be written inside the PassFailExit function. Below is the code written inside PassFailExit function to perform the error-handling mechanism.

PassFailExit (char* transName,char* txt1)
{      

// To get the return code of the particular call
    i=web_get_int_property(HTTP_INFO_RETURN_CODE);

// If the return code is other than 200 OK the transaction will declared as Fail.
    
    if (i!=200)

    {
        lr_end_transaction(transName,LR_FAIL);
        lr_error_message("%s was not Downloaded. The error code returned was : %d",transName,i );
        lr_exit(LR_EXIT_ACTION_AND_CONTINUE, LR_FAIL);        
    }

// Based on the error check count and text check count the transaction status will be declared
    
    else if (atoi(lr_eval_string("{errchk}"))!=0)
    {
        lr_end_transaction(transName,LR_FAIL);
        lr_error_message("%s failed due to error check '500 server error' is captured",transName);    
        lr_exit(LR_EXIT_ACTION_AND_CONTINUE, LR_FAIL);        
    }
    
    else if (atoi(lr_eval_string("{txtchk}"))==0)
    {
        lr_end_transaction(transName,LR_FAIL);
        lr_error_message("%s failed due to text check '%s' is not captured",transName,txt1);
        lr_exit(LR_EXIT_ACTION_AND_CONTINUE, LR_FAIL);
    }

    // if the above validation Fails we will declare the status of the transaction as PASS using the below code.

    else
    {
        lr_end_transaction(transName,LR_PASS);
        lr_output_message("%s was Downloaded",transName);
    }

    i=0;

    lr_think_time(5);
   
    return 0;
    
}

Think Time

Think time will be declared inside the PassFailExit function since all the think time functions will be used after the transactions end.

We generally declare the think time as 5 Secs but in runtime settings, we will handle the think time based on the requirement. Refer to the article to get detailed information on ‘Loadrunner – Runtime Setting – Think Time‘.

You can also declare a variable for think time. 

lr_think_time(p_ThinkTime);

Socket options

Generally, we use the below 2 socket options to avoid SSL errors. Since we use the WinInet option for recording we need to give any one of the socket options.

  1. web_set_sockets_option(“SSL_VERSION”, “TLS1.2”);
  2. web_set_sockets_option(“SSL_VERSION”, “TLS1.1”);
  3. web_set_sockets_option(“SSL_CIPHER_LIST”, “{Get it from App Team}”);

Text checks

We usually do the text check in the error handling area itself. As mentioned above, the text check count will be taken with the help of ‘savecount’ option.

web_reg_find(“Text/IC=Please Log In“,”savecount=txtchk“,”Search=All“,LAST);

And it will be sent to the PassFailExit Function

PassFailExit(“OrderSubmission_01_15_Login”,” Please Log In“);

Using the if condition the count will be checked, if it is equal to “0” we will declare the transaction as failed with the message “failed due to text check <textcheck> is not captured”

else if (atoi(lr_eval_string("{txtchk}"))==0)
    {
        lr_end_transaction(transName,LR_FAIL);
        lr_error_message("%s failed due to text check '%s' is not captured",transName,txt1);
        lr_exit(LR_EXIT_ACTION_AND_CONTINUE, LR_FAIL);
    }

By following the above-mentioned LoadRunner scripting standards, you can deliver a quality script to the client.

You may be interested: