This is a continuation of part 1 where we recorded a JMeter test plan using Geb to drive the application under test. We are now ready to do some initial correlation. I will have to leave post procesing for a 3rd post as I haven't had time to get the content together yet.
Git Repository
A git repository is available containing all the files used in this blog post: here
Correlation
Once the script has been recorded, you need to go through and identify any session specific values for correlation. JMeter Regular Expression Extractors are ideal for pulling this data from a response and making it available for future requests.
I tend to have two JMeter sessions open at this point, one with the recorded script in src/main/resources/Recording.Template.jmx, and one with src/main/resources/TestPlan.Template.jmx open. As items for correlation are identified, find the first response that returns that value in the View Results Tree Listener under the Workbench (in the Recording Test Plan). Construct a regular expression that uniquely identifies that value in the response and put it into a new Regular Expression Extractor in the root of the test plan within TestPlan.Template.jmx. Putting it in the root of the test plan means that it will apply to all responses.
In the case of the test plan recorded earlier, we did a search for Wikipedia then clicked on the first result which took us to Wikipedia.org which has been hard coded in the recorded test plan. For the purposes of this post, lets say we wanted to dynamically determine what URL the first result would take us to, and then browse to that URL. We would need to do the following:
- Correlate the URL using a regular expression extractor
- Add this extractor to the TestPlan.Template.jmx
- Write a groovy script that will perform correlation using this extractor automatically on test plans we record in the future.
Correlate the URL using a regular expression extractor.
When we perform a Google search we click one of the result links and go to the relevant URL. To simulate this using JMeter we need to identify the request that gives us this URL and correlate it so we can pull it out dynamically.
In the screenshot below we can see that the URL is given to us in the response to request 51. Note that this request number is likely to change when you record the test yourself.
Once we know which response gives us our result URL we can construct a regular expression to pull out what we want. In this instance, the following gives us what we need: 'x22([a-z]+):\\\/\\\/(.+?)\\\/\\\\x22'.
I don't claim to be an expert at regexes so I am sure there is a more elegant verion but this works (at the time of writing).
Add a Regular Expression Extractor to the Test Plan Template
Now we have identified the regular expression that will pull out the information we need, we need to add this to our test plan template.
The following screenshot shows the configuration that should be used for the Regular Expression Extractor.
It is worth briefly explaining the different parameters we have used in this post processor.
- Reference Name - this is the name by which we will reference the extracted value.
- Regular Expression - this is the expression used to extract the data we want to use.
- Temple - In the expression we are using, there are actually two parts: ([a-z]+) & (.+?). The template allows us to define which bits we use and in which order. In this case we are only going to use the second part.
- Match No - If there are multiple matches, we can specify which match we would like to use. In this case we are only going to use the first match.
- Default Value - This allows us to define the default value to use if we don't get a match for a particular response. Given the we have put this post processor in the root of our test plan, it will apply to all responses. As such it is highly likely that at some point we won't get a match. To mitigate this, I am referencing the parameter recursively. Once it is initialised, it will stay intialised. In this instance any other default value would be bad as we might find a match in one response, then overwrite it in the next with a default value because we have not found another match.
Part 3 will tie all of this together. We will cover writing a Groovy script to process the recorded JMeter test plan and replace the original search result URL with the value pulled out using the Regular Expression Extractor. At that point we should hopefully be in a position to change our automated UI test to perform an entirely different search and record a new performance test script with (almost!) no manual involvement.