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.
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
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.