Designing Test Plans with Controllers the Right Way

Designing Test Plans with Controllers the Right Way

JMeter Load & Stress testing might seem very straightforward with a little practice, but in big scale projects, things can get complicated. Test plans can be broken, it might be hard to keep the design clean, and it could become a burden for the team to maintain the flow in the long run.

Like most things in life, the very same rule applies for JMeter: “Simple can be harder than complex” Steve Jobs.

To create a well-organized and smoothly maintainable test in the long run, in this article we will focus on JMeter Controllers and how they can ease our pain.

Storyline:

In the name of modularity, JMeter provides us Module Controller combined with either Simple Controller or Test Fragment. It is convenient, yet efficient to empower such controllers with Parameterized Controller, Include Controller, Loop Controller, Random Controller, Interleave Controller, Recording Controller, Throughput Controller, Once Only Controller and RunTime Controller.

Tagline:

Once you start digging deeper, reorganizing and refactoring for every step plays a vital role to keep your design simple, neat and progressive.

Keeping things modular

Cached pages –pages that are not supposed to be regenerated on the fly-, not-supposed-to-be-cached pages –pages that are meant to be served with real-time data, linked user scenarios, data-driven load tests and such plans need to be run on a well-established design. If the case is based on reliable and sustainable plans –hopefully, what we all expect-, there is a big chance to get lost in components farm and bring the current situation to an even more complex one than before.

At this very point, Module Controller comes in handy. We can simply create test step blocks with either Simple Controller or Test Fragment. These side elements are at our service to help us improve code re-usability. By adding a module controller under our test plan, we will be able to use these thread groups for each plan we prepare. We can also save a Test Fragment as a JMX file and pass it into the plans by simply adding an Include Controller to our test plan. These approaches not only improve the re-usability and centralized management but also support the external folder structure, versioning, and relocation.

Let’s spice it up a little

So everything is great so far. We got familiar with Jmeter and following the tips above, now that we know how to handle the modularity. Let’s go one step further and place some extra elements into our test plans to be sure that things are set the way we want exactly.

There could be a few questions you need to deal with while preparing your plans;

• How many times do you want your tests to repeat? And how can you set the cycles for each module in its scope specifically?
• Do you want your tests to run randomly or in sequential order?
• Is there supposed to be a time-out separately for each test group?
• Do you need to distribute the load by thread count or percentage over the test groups?
• Do you need to run a request only once per thread?

How many times do you want your tests to repeat? And how can you set the cycles for each module in its scope specifically?

In your thread group settings, it is possible to set the loop count for the entire steps block. But what happens if we need to repeat the requests for a set of requests inside this cycle?

Loop Controller comes to the rescue at this very moment. You can easily add Loop Controller under your thread group and place desired request steps under it.

Loop Controller presents us two options to overcome in-scope-looping situation: Forever and loop count. When you check the forever option, requests in this scope simply are repeated forever. If you choose to set loop count, the requests will run as many as the assigned number.

Do you want your tests to run randomly or in a sequential order?

All three controller elements — Random Controller, Random Order Controller and Interleave Controller- have their own way to change the request flow. The main difference between them is executing the requests once per cycle or all per cycle.

Once per cycle: Once you execute a group of requests under the related controller, it picks one of the requests and runs it only.

All per cycle: Once you execute a group of requests under the related controller, it runs it all.

Random Order Controller is an all-per-cycle kind of element. On the other hand, Random Controller and Interleave Controller is a once-per-cycle type of element.

To visualize, a concise example would be;

We have a thread group with loop setting set to 2. Under this thread group, we have all three controllers mentioned above. Now we add two requests for each controller element. Basically what we have is as the following;

• Test Plan
• Thread Group
• Random Order Controller
• Request #1
• Request #2
• Random Controller
• Request #1
• Request #2
• Interleave Controller
• Request #1
• Request #2

Once we run the group with the Random Order Controller, we get the following result in our reports;

Request #2

Request #1

Request #1

Request #2

As you notice already, 2 loop x 2 files mean 4 requests in a random manner.

Similarly, as we run the ones with Random Controller, we get;

Request #2

Request #1

2 loop x 2 files but for this controller type, it means 1 request picked for each cycle in a random manner.

Last but not least, when we run the requests under Interleave Controller, we get;

Request #1

Request #2

Two loop x 2 files again but also for this controller type, again it means one request picked for each cycle sequentially

Is there supposed to be a time-out separate for each test group?

There might be some situations to run the requests for a specific period. Runtime Controller is the one you are looking for.You set the runtime in seconds, and your group will run and stop exactly right after the number of seconds you entered.

Just one thing that might lead to confusion though… This controller overrides the loop and continues for the given period. Therefore, if you set 30 seconds for Runtime Controller and set the Thread Group loop set to 1 but your request set is supposed to be done in 5 seconds then it will run six more times.

Do you need to distribute the load by thread count or percentage over the test groups?

There might be situations that require testing endpoints with relatively more load than any other. In this case, Throughput Controller provides us two options: thread count or percentage.

By using Throughput Controller, just like other controller elements mentioned above, with either of these options makes us easily share the load between the requests in no time.

Do you need to run a request only once per thread?

If you face this kind of situation, just add Once Only Controller, and you are good to go. It does the job and executes the request only once and in the first loop only for each thread.

Sticky Notes

Please keep in mind that all those modularity elements can easily be combined with JMeter’s built-in CSV support or custom BeanShell scripts to pass any desired data into the plans.

By using a Recording Controller beyond all the concepts discussed in this article, you can have your request steps created automatically for you. Even though this type of controller does not affect your design, it is a very handy choice to ease your manual work.

If you’re interested in using CSS selectors in JMeter Scripts, then go and enjoy our blog!

Happy Load Testing…