In my previous blog post, I presented you how to create a load testing scenario based on a recorder. While working on it, I faced small problems that required few fixes which were very repetitive (and you know I love to automate as much as possible 🙂 ). Amount the issues I faced, there were:
- Extending a scenario with extra actions
- Update a scenario as a new version of the application is behaving differently (different HTTP POST data and HTTP results)
In this blog post, we will improve the existing load test scenario for M-Files.
Extend a Scenario
When extending a scenario, the HTTP requests we will add will have different session ID (sid, M-Files-Session) and thus, we must find them and do a Search and Replace again. We must repeat this every time we add an HTTP request from a different recording. This might cause problems and waste of debugging time if not done properly.
A better approach would be to add a new type of object: A JSR223 Preprocessor. This code will be called before (as “pre” indicates) each call of any type of object of the scenario. With this, we will be able to modify any HTTP request before it triggers.
If you recall my previous blog post, I discovered a client-side generated timestamp hash based on yeast library:
This is used sometimes in URL as GET parameters, sometimes in POST. We will first focus on GET.
HTTP GET
I will use a PreProcessor of type Apache Groovy which is known to be more efficient than other languages supported by JMeter.
To avoid having the code run for all types of requests, my code will start with an if:
if (sampler instanceof org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy) {
Next part of the code is to check if URL contains the “t” parameter with a regex and replace:
path = sampler.getPath();
findRegex = /&t=(.+)&/;
path = path.replaceFirst(findRegex, "&t=" + newValue + "&");
log.info("t variable updated to " + newValue);
sampler.setPath(path);
Now, whenever I run the scenario, we will see a line in the logviewer:
2024-01-29 09:45:55,722 INFO o.a.j.m.J.JSR223 PreProcessor Variable Updates: t variable updated to OrKPOIA.
And that the triggered URL is different from how it was defined in the HTTP request:
On the left side, we see the “t” value at recording time. On the right, “t” value at scenario runtime.
This covers the case where “t” variable is in the URL. Next, we must do it for POST variables.
HTTP POST
For HTTP POST, we must proceed in the following order:
- Check HTTP Method is POST
- Get arguments list
- Check our argument is in the list
- Remove it
- Add it back with the correct value
This gives the following groovy code:
if (sampler.getMethod() == 'POST') {
arguments = sampler.getArguments().getArgumentsAsMap()
if (arguments.containsKey("t")) {
sampler.getArguments().removeArgument("t")
sampler.addArgument("t",newValue)
log.info("POST: t variable updated to " + newValue);
}
}
What to Improve even More?
I need to make this more generic via a method which I will be able to call for any variable as I have many other variables to consider for this M-Files scenario:
- SID
- M-Files-Session
- Vault ID
Finally, for each of these, I will simply call the method:
updateVariables("t", newValue)
updateVariables("SID", vars.get("SID"))
updateVariables("M-Files-Session", vars.get("SID-MFILES"))