Run massively scalable performance tests on web, mobile, and APIs

Request a Demo
Sep. 26th, 2018

How Different Teams Can Work on the Same JMeter Script

As we have all heard many times, we should add performance testing to our development lifecycle, instead of waiting for complete system integration. But, how can we achieve this if our system has a lot of separate functionalities, developed by different teams? And what happens if the different Apache JMeter™ script parts depend on each other? To achieve agility and error free releases, we should be able to test each functionality separately, but also run one JMeter script that executes the complete system, in which each part can be updated independently by each team.

 

Well, here at Abstracta we have faced this scenario and we found a solution that we want to share with you, so you can use it as well. I will show how to develop the separate scripts and the considerations to take into account, and then how to invoke each part to work on a joint script. Let’s get started.

 

Let’s suppose we have an e-commerce site. One team is working on the login, another team is working on the list of items, and a third is working on the checkout stage.

 

This is the script that tests all the different functionalities being developed. It has three functionalities: Login, List the items and Checkout.

 

jmeter, modular scripts

 

If we expand each thread group, it looks like this:

 

jmeter, joint scripts

 

As mentioned, we want the teams to be able to test and update their parts independently. But as you can see, the login is used in the next two functionalities, which are dependent on it. The same goes for the list of items. So, If the Login team changes the way they invoke the script, should the other teams update their scripts? Well, the answer is no.

 

The solution is a modularizing script. A modularizing script is a script you can develop as joint modules. In such a script, each module is independent of the others, and script sections are not repeated. Rather, the logic is declared in one place.

 

To build such a script, I will use the Test Fragment, Module Controller and Include Controller.

  • Test Fragment: Allows you to use Module and Include controllers. In our scripts, we are going to use the Test Fragment to declare the logic of each step (Login, for example) and this will be the only place where the logic is implemented.
  • Module Controller: Invokes substituting sections of the script. Once you have declared the logic of the script in the test fragment, Module Controllers will reference that logic in order to reuse the step in the Thread Group. It’s important to mention that the step or logic referenced have to be in the same script. In our case, we will reference the steps declared in the Test Fragment, but you can reference any part of your script.
  • Include Controller: Invokes an external script (jmx file) into your script. Similar to the module controller, this controller enables invoking steps that aren't in the same script.

 

The Individual Scripts

 

We'll start with the personal scripts each teams creates.  We will generate multiple modules in the form of separate .jmx files, which we are going to piece together next. The "Include Controllers" will be used to invoke each of these individual scripts.

 

Let's start with the login step.

  • Open an empty script.
  • Add a Test Fragment by clicking the right button over the Test Plan.
  • Into the Test Fragment, add the logic of the Login step. These are the actions we will invoke with the Include and the Module controllers.

 

jmeter load testing, module controller

 

Now, just for debugging purposes, let’s:

  • Add a Thread group.
  • Into the Thread group add the common elements you need to run the scripts. For example the data, the cookie manager and a listener.
  • Add a Module Controller (Thread Group -> Add -> Logic Controller -> Module Controller). Into the Sampler, select the step you want to call. In our example, the Test Fragment that includes the Login logic.

 

jmeter load testing, logic

 

As you can see, we have used a Test Fragment with the logic of the script (the step development). Later on, we will be able to use "Include Controllers" to invoke this script.

 

Now, if the login changes, you just have to update it in one single place, the test Fragment.

 

The General Script

 

So now, in the general script, we just have to include the test fragment, add an Include controller and detail the name of the script we want to invoke, in this case, “Login”.

 

Woah! That was a lot of information just in one sentence! Let’s review how to do this step by step.

 

  • Right click over the Thread Group -> Add -> Logic Controller ->Include Controller.
  • In the Filename field specify the name of the script you want to include, as we show in the picture:

 

jmeter, script, logic controller

 

If you locate the general script into the same folder than the “login.jmx” script, you don’t need to specify the whole path, just the name of the script. Each developer team needs to ensure the updated script is always on the machine with the other scripts.

 

We can work in a similar way for the “List the items” functionality. We have to create a script just for the team. But, as we have shown before, this functionality depends on the Login part. So, we could develop our script like this:

 

jmeter script, load testing, functionality development

 

Put the logic of the functionality in the Test Fragment, and include the Login in the Thread Group for debugging purposes. Now you can include this fragment of logic in the general script.

 

jmeter, test fragment, module controller, include controller, listeners

 

I also recommend using a Cookie Manager, so the script saves the session of the user using these controllers.

 

Finally, we have to create the test fragment for Go To Checkout step.

 

jmeter script with many functionailities

 

And include it in the general script:

 

integrating functionalities in jmeter

 

That’s it! We have created a general script that uses three functionalities, but their source logic is written in just one place. So, if the owner of the functionality changes the way they created the step, the developer just has to change the script. This will not only impact the general script, but also the the scripts that depend on that functionality.

 

That’s it! This is how you can avoid repeating parts of the script, to make it more maintainable. You’re welcome to share the solutions you found in the comments section below.

 

Once you’ve finished your tests, scale them in BlazeMeter. To run your test in BlazeMeter, put your URL in the box below and your test will start in minutes. Or, request a live demo with one of our performance engineers.

     
arrow Please enter a valid URL

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