Felicia Chen has been an Engineer at BlazeMeter and Broadcom's DevOps group since 2017, and is an instructor at the BlazeMeter University. Her background was in sales engineering, and her current focus is in client advocacy, as well as product education--she loves assisting teams in realizing their performance and automated testing goals. She is into process efficiency and excited about exploring creative solutions. She is also an avid motorcyclist and tinkerer of all things, and loves science fiction and long walks on the beach.

Become a JMeter and Continuous Testing Pro

Start Learning

Test Your Website Performance NOW! |

arrowPlease enter a URL with http(s)
May 26 2021

Modularizing for Script Reusability: Examples in JMeter and YAML

Creating performance testing scripts requires a great deal of time. From expanding user stories that incorporate different aspects of applications, to maintaining and managing a large number of scenarios - different executions can become quite time-consuming and challenging, especially as applications become more complex.


BlazeMeter enables cutting down on scripting time by leveraging over twenty open source tools and offering recording tools. The most notable ones are JMeter, Selenium, and YAML, the configuration language leveraged by Taurus. But even with recording - creating and maintaining scripts for multiple user stories and executions can be a hassle. Let’s see how modularizing can help.


Why Modularize?

Save Time

Modularizing means scripts can be broken down into individual components to be reused as a piece of a larger whole. In this case, if multiple scripts leverage the same component, and that component has changed, we don’t need to change all these scripts to keep them updated. Instead, only that one component needs to be changed.This allows for much better change control and coverage, and saves maintenance time.

Ensure Testing Quality

Modularizing also enables mixing and matching components. When building scripts for a new user story for an existing application, this can ensure uniformity to testing standards.

In short, modularizing your JMeter and/or YAML scripts will save time in the creation of new scripts, as well as maintaining existing scripts by promoting reusability and standardization.

Modularizing JMeter Scripts - A Guide

In JMeter, there are a few ways to modularize scripts. For the purposes of this article, we will be taking a look at JMeter test fragments, created from a BlazeMeter Chrome extension recording.

Let’s take a look at one of our demo sites, https://demoblaze.com. This is a recording of a number of different user actions. Each one is separated by using the “Add Step” option in the BlazeMeter Chrome Extension. From here, we can make our edits one time, and save each component as a test fragment.

Take a look at the Login step. This is where we’ll capture a token and save this transaction controller, as well as the others, as test fragments.



Edit the recording:

  • Give each sampler a meaningful name
  • Capture the token that is generated
  • Remove endpoints that are not relevant to our test case



If you can imagine having to do this for every user story that requires a login step, this could become quite cumbersome. This is where saving each component as a test fragment comes in.


Right click on the component and click on “Save as Test Fragment”, and save it with a descriptive name. I’ve named this one as “login.jmx”.



From one recording, we now have a number of test fragments made, one for each transaction controller I defined in the BlazeMeter Chrome extension. These fragments can be mixed and matched to create a multitude of user stories, without having to record and edit each time.


To do this, we will leverage the Include Controller in JMeter. Simply build your scripts with the desired test fragments. In this example, the user will be logging in, watching a video, and then logging out, all leveraging their respective test fragments:




You can create test fragments of HTTP headers, cookies, user defined variables, etc. that are common across multiple scripts for a particular application. This will save you the need to manually configure them each time.


As you can see, it’s a fairly simple process to introduce reusability and standardization across your test suites while creating test scripts. Doing so will save you time when creating new scripts, as well as maintaining existing ones.

Using Modularized JMeter Tests in BlazeMeter

In BlazeMeter, you will need to have the fragments available for the test to find--I suggest leveraging a shared folder to store your test fragments, enhancing your control over managing uniformity when one or more of your test steps require changes. In this example, I have a Shared Folder in BlazeMeter called “fragments”--be sure to edit the path to your specified Shared Folder before uploading the script to BlazeMeter:



Modularizing YAML Configurations

With Taurus, modularizing is made incredibly simple and flexible while working within an IDE, console, and/or a CI/CD environment, which is an ideal way to automate your tests. Taurus has the capability to concatenate multiple YAML files to create a single script. This will reduce time to test in relation to script creation and maintenance.


For example, assuming all test assets were to be stored in a repository, your CI/CD environment could leverage these files from a single source, thereby allowing for ultimate change control. 


Go to your BlazeMeter Chrome extension recording and select the JMeter & Selenium Combined (YAML).




Isolate the portion you want to modularize and define each user step as a scenario. I isolated the HTTP portion of the recording:



Save the file. I called it dblaze.yaml.


Save this as a master record of relevant test steps. Then, we can create a configuration using the include-scenario block, which is a logic block used in Taurus to be able to use modular scenarios to create a new one:



Save the file. I called it scenario_loginlogout.yaml.


From here, we can further modularize by creating execution configurations. This is where we can leverage many different execution settings for any given scenario. This includes load, soak, spike, failover, etc. For this example, we’ll use a spike execution:



Save the file. I called it spike_exec.yaml.


We now have three files. Each of them will be used in the execution of this test, and Taurus will concatenate these files into one complete test case.


Run the test locally, via the command line:


bzt spike_exec.yaml dblaze.yaml scenario_loginlogout.yaml


Taurus will concatenate these YAML configurations and run the relevant scenarios to your definition as one test. Once the test is verified to perform as expected, this test can be pushed to the cloud. Use thethe same command, but append a -cloud to it (and your api key, if this isn’t saved in your bzt-rc file):


bzt spike_exec.yaml dblaze.yaml scenario_loginlogout.yaml totally_real_api_key.yaml -cloud


Extrapolate this to your test suites in your pipeline, and developers and testers will be able to mix and match executions with scenarios, choosing relevant modularized scenarios for their particular test. They will be able to define them on the fly, at run time. Should a tester want to run this same scenario in a soak execution, this is easily achievable with another execution configuration, like this:


bzt soak_exec.yaml dblaze.yaml scenario_loginlogout.yaml totally_real_api_key.yaml -cloud


Final Thoughts

In the quickly shifting world of application development, it is clearly important to create testing assets that are leverageable in the most flexible and reusable manner. Creating one-off scripts for each user story is quickly becoming a part of the burdensome past. Creating, automating, and maintaining test suites in a sane, reusable, and organized manner is the way to keep up with the times.


To start recording with the BlazeMeter Chrome Extension, go here. To get started with Taurus, install here.

arrowPlease enter a URL with http(s)

Interested in writing for our Blog?Send us a pitch!