Customisation of LoadRunner Transaction Names

This article will detail a better way of defining and coding for Loadrunner transactions.

Script transaction names should ideally take a common, easily understandable format in order to ease debugging and test analysis activities. Consider the following three transaction names in a Web (HTTP/HTML) search script for a Web application:

  • ClickSearchPage
  • ClickSearchButton
  • ClickRandomItem

Whilst these names may seem innocuous, there are several potential problems:

  1. In a multi-script scenario, there is no way to distinguish which script this transaction originated from, causing potential analysis confusion
  2. In a multi-script scenario, same-name transactions will merge into one single transaction, causing potential analysis confusion
  3. There is no means of identifying which Application Under Test (AUT) page the transaction relates to – pages often share components and may behave differently from a performance standpoint
  4. There is no way to logically order the transaction names according to the sequence in which they occurred
  5. The verbs used in the transaction names are not semantically consistent with the HTTP/HTML script protocol (we’re working at the HTTP protocol level, not the UI level)

Taking these points into consideration, a much improved transaction name notation would be:

<3-letter script identifier>_<3-digit transaction identifier>_<AUT page name>_<action verb><succinct action nouns>

Applying to the above examples:

  • SER_001_Homepage_SelectSearchPage
  • SER_002_ConfigureSearch_SubmitSearchCriteria
  • SER_003_SearchResults_SelectRandomItem

One of the biggest benefits from this approach is ordering and clarity – sorting by name means transactions are automatically ordered by script, then logical transaction ordering and the detail in the transaction name is sufficient to identify where the transaction takes place in the AUT. This applies to both running the test and post-analysis. Also, each area of AUT functionality has its own distinct transaction, which will more than likely make problems easier to identify, particularly in larger systems with many shared components.

Although the transaction notation scheme detailed above brings many added benefits, it can also cause huge script maintenance overhead, particularly in large scripts with many transactions. What if you wanted to change the 3-letter script identifier or insert/remove transactions? This is where a reusable C function library comes in useful:

Step 1 – Create transactions.c File

int  iTransactionId = 1;           //Global transaction ID counter
char sCurrentTransactionName[100]; //Name of <a href="http://avigorelle.com/">vigorelle uk</a> current transaction

//Starts a transaction with specific naming format
void startTransaction(
  char *sPageName,       //The name of the page
  char *sTransactionName //The name of the transaction
) {

  //Print format to buffer
  sprintf(
    sCurrentTransactionName,
    "%s_%03d_%s_%s",
    lr_eval_string("{p_script_identifier}"),
    iTransactionId++,
    sPageName,
    sTransactionName
  );

  //Start transaction
  lr_start_transaction(sCurrentTransactionName);

}

//Ends the current transaction with specific LR transaction end status
void endTransaction(
  int iStatus
) {

  lr_end_transaction(
    sCurrentTransactionName,
    iStatus
  );

}

//Resets the transaction ID (for example for new iterations)
void resetTransactionId() {

  iTransactionId = 1;

}

The functions listed above are deliberately minimised and can of course be extended to your requirements. Note that all dependent global variable modifications are done through the functions and these variables (e.g, iTransactionId) should not be directly referenced in the script.

Step 2 – Include transactions.c File

Include the file above in your scripts using the #include complier directive so that you need only maintain one copy of this file. For example, in vuser_init(), you may use a UNC path to a common location:

 #include "\\scripthost\vugen\transactions.c"

vuser_init()
{

  ... 

Step 3 – Integrate Functions

In your script, first create a parameter called p_script_identifier containing the desired 3-letter script identifier, for example SER. This is used by startTransaction() to construct the transaction name.

Next, create a new action called iteration_init that calls resetTransactionId() – ensure this is executed at the beginning of each Run block iteration so that the transaction ID counter is reset for every iteration of the script:

iteration_init()
{

  resetTransactionId();
  return 0;

}

Next, instead of directly calling lr_start_transaction() and lr_end_transaction(), use the startTransaction() and endTransaction() functions instead:

Action()
{

  startTransaction("Homepage", "SelectSearchPage");

  web_url("web_url",
    "URL=...

  endTransaction(LR_PASS);

  ...

  startTransaction("ConfigureSearch", "SubmitSearchCriteria");

  web_url("web_url",
    "URL=...

  endTransaction(LR_PASS);

  ...

And there we have it – a reusable function library that ensures unique, consistent transaction naming that has the ability to significantly reduce script maintenance time and provides transaction grouping, ordering and clarity.

If you have written a great LR Routine and would like to share then please get in touch and submit your code to this site.  Share with the community, gain recognition  and bask in the glory of fellow Loadtesters. 

More LoadRunner Tips and Coding Tricks can be found here: 

 

2 thoughts on “Customisation of LoadRunner Transaction Names

  1. Hi

    Unable to understand LR recorded script from GWT based application – Hi All , I have an application which uses GWT framework –

    i want to know has any one developed any C framework or .c files, which i can use – because most of the data coming from LR script – recorded information is gibberish and am not able to customize a single line so far – if any one has any information or any pointers i really appreciate i use LR 11 version- do i have to change any settings in LR while recording

    1. This has nothing to do with the topic – but i’ll attempt to help. The GWT framework (Google’s Web Toolkit (GWT) will RPC encoding of HTTP requests – It is possible to correlate, but does look ugly and can be painful depending on the complexity of the load model. You may want to look at the GUI level protocol (but this comes with its own problems). This is a thread that may be of help to you http://groups.google.com/group/LR-LoadRunner/browse_thread/thread/22958bdd970e133f?pli=1

Leave a Reply

Your email address will not be published. Required fields are marked *