LoadRunner Script Development Framework

Developing a common header file with frequently used calls and variable declarations helps in effective script debugging and avoiding reworking that requires manual intervention. This header file is modified whenever there are changes in the environment or any other requests. We will be good to proceed with test executions without even needing to open the other scripts.

In general, for any project, we develop scripts, create test data, and execute the scripts. During tight project schedules, we do not have time to create the data, and synthetic data that we create might not accurately match with the production environment, so we have come up with an innovative idea to fetching the data directly from the database.

We query the test data from the database and execute the scripts. With custom coding in the test scripts, we are able to establish connectivity to the database. 

There are some scenarios where it is useful to have a single header file with all the reusable functions. This header file will be executed from the LoadRunner script.  

Advantage of having this common header file:

  • Easy script maintenance
  • Effective debugging at the function level

In addition to that, there will be cases where we need to execute tests in multiple test environments that must be triggered one after another. Given the minimal time gap between each test, the best way to do this is to have them in one centralized location and call them from our script. In this way, we can make debugging easy and make changes in one place that will be reflected in all the scripts.

This framework helps in any project where there are actions that are common to all scripts. Having all the common actions in one header file avoids redundancy and duplication and facilitates having a defined and structured script framework. This way, we can also make the script easily understandable, reduces the chances of making mistakes and allowing us to make modifications very quickly with less manual intervention.

To understand the framework, here is a case where we have the commonly called actions in a header file. This header file will interact with the database to query for particular ID, retrieve it, and call the function in the header file. There will always be script-specific actions that are executed from the script itself. 

LoadRunner Script Framework



In the flowchart above, HomePage (), Login (), IDSearch (), and Logout () are shared by all the scripts. 

The ID Search will query the data from the database. There is a column status to track whether the data is reusable or unique. After querying the data, the status is modified accordingly. This way, we can track the data that is consumed in the test executions.

After the ID is queried from the database, there are certain script-specific requests that are kept in the script logout, which is a common action called from the common header (CommonActions.h).

With this approach, we have a flexible scripting framework and can execute tests in any environment with minimal modifications. All the reusable code is kept in one header, which helps in developing a sophisticated scripting framework that adheres to process compliance and avoids the time needed to modify the same content in multiple files. In this case, modification in the common files’ header file means that all of the scripts are executed without any issues. This would not have been possible if it was modifying 60 scripts manually every time there are dynamic changes.


Gautam Datta
Performance Engineer

Gautam Datta is a Performance Engineer with 3 years of experience in performance testing and engineering using open source (Jmeter) and commercial tools (HP LR, IBM RPT, Neoload, VSTS, and Silk Performer). He has expertise in designing frameworks for complex technologies and projects. He is also an aspiring blogger who likes to share the happenings in performance testing and performance engineering through his blog.