Why do I need reusable components in a load script?
Ok, so generally speaking a load script may not really need reusable components you think. However there are plenty of reasons to actually use them and use them effectively, efficiently and heavily.
First of all, not all Jmeter load scripts are for a one off effort. There are quite some times that, if not entire scripts, then at least part of a script could be extremely useful to reuse. Think of a nice application, such as a webshop, you may be trying to stress out with Jmeter. While building it I hope the developers were thinking of reuse, so why wouldn’t you while building a script to stress that shop out?
Secondly, when building load scenarios, you may want to reuse a search function, a registration function, a login function, etc. So why not make a bunch of reusable modules or JMX scripts that help you build scenarios by just clicking existing things together rapidly rather than reinvent the wheel over and over for each and every scenario.
I am not even going to mention the default reasoning: standard practice of DRY: Don’t Repeat Yourself! (ok, there, I did it anyway)
Does JMeter allow for it?
Well, that one seems a bit obvious, since I am writing about it here of course 🙂 Yes Jmeter has a wonderful way of dealing with reuse:
All you need is a Module Controller
Jmeter 2.13 Module Controller
or an Include Controller (which I will write a brief how-to about in a followup post):
Jmeter 2.13 Include Controller
These two can basically do a similar thing, you can reuse either a module or reuse, and by reuse I mean include of course) a complete testplan in a test. The actual working and thus their use and usefullness is quite different though.
The Module Controller keeps everything within one testplan, whereas the Include Controller expects you to have several (at least 2) testplans to use and work with.
How do I use them
Module Controller
The Module Controller is a relatively easy one to explain as the first one. I use this method often when building scenarios which are relatively close to each other, for example for a webshop. The example I am going through below is a very simple basic one. Sticking to a basic description, since I mainly wanted to show that it is possible to use reusable components and how you can do it.
Imagine a few scenarios for a webshop:
Scenario 1:
- Create account
- While logged in browse the webshop
- Add items to your shopping cart
- Go through Checkout
- Log out of webshop
Scenario 2:
- Browse to the webshop
- Add items to your shopping cart
- Go to Checkout
- Create account on Checkout
- Go through checkout
- Log out of webshop
Scenario 3:
- Browse to the webshop
- Sign in to the webshop with an account with at least 1 purchase
- Do something the My Account
- Add items to shopping basket and leave them there
- Log Off
In these scenarios there are several steps that are repeated: Sign up for an account, log off, add some items to a basket. If you want to make sure you do not need to maintain these steps at different spots in your script, it make perfect sense to make these steps reusable. This is after all what you would do with test automation as well, right? Let’s do just that!
What do you need in Jmeter:
Testplan
> <DISABLED>Threadgroup
> Simple Controller with Signup steps
> Samplers etc needed to run through the signup flow
> Simple Controller with LogOff steps
</DISABLED>
> Threadgroup
> Module Controller - In this controller you can choose which controller you want to use. Select the Signup Controller
> Simple Controller
> Samplers etc. needed to execute the following steps
Your JMX could now look something like this:
Include Controller
This will be coming along in a followup post at a later time.
A lot of the performance tests I have executed over the past year or so, have not used the Graphical User Interface. Instead the tests use the communications underneath the GUI, such as XML, JSON or whatever else passes between server and client. In these performance tests the functionality of the application under test is still run through by the tests, so a functional walkthrough/test does get executed, my assertions however do not necessarily validate that and definitely not on a level that would be acceptable for normal functional test automation. In other words, most of the performance tests cannot (easily or blindly) be reused as functional test automation.
Technical Software Testing 