Creating a JMeter performance test plan often involves simulating a series of requests. Whether we intend to run one request sometimes depends on if the previous request was successful – in essence creating a branched-logic flow. In this brief post, we will show you how to use JMeter assertions to control the flow of your test.
Conditional Test Flow
In a previous post, we covered all the different types of JMeter assertions that are available. Here, we will focus on configuring the Response Assertion element to control test plan flow. However, many of the same concepts may be extended to other assertion elements.
The best way to illustrate how to use Response Assertion components in practice is by example. Let’s consider the following simple test plan where we have two HTTP requests, “A” and “B”:
In this simple test plan, we have defined two HTTP Request elements inside a Thread Group, with the intent that if “Request A” is successful, we will run “Request B”. The Response Assertion element which appears under request “A” controls the flow of execution such that “B” runs only if “A” is successful. This is defined in the configuration parameters for this Response Assertion:
While you can explore the full range of parameters for the Response Assertion component in the official JMeter documentation, the key parameters we have defined for our example are as follows:
- We have set “Main sample and sub-samples” for “Apply to” – This setting causes execution to skip remaining samplers in our Thread Group if
- The “Field to Test” is set to “Response Code” – There are a number of fields available to us, but the principle here is selecting one which gauges success versus failure of sampler execution.
- “Pattern Matching Rules” are set to “Matches” – In this example, we are looking for an exact match.
- The “Pattern to Test” is set to “
200” – This corresponds to the HTTP success status code.
For the purposes of illustration, we have configured about half of the responses for request “A” to return an unsuccessful 300 or 400 response code. The results of running through several iterations of our test can be seen in the output of the View Results Tree listener:
A More Complex Example
Often, the success of a response is not only considered by the HTTP status code (e.g., 200, 404, etc.), but the content of the request. To describe a more realistic scenario, we can apply multiple assertions to a single HTTP request:
In this case we have an HTTP Sampler which is configured to return an expected JSON response. We are using jsontest.org for this test, a site hosting multiple JSON-returning endpoints for application testing. Specifically, we will be using the IP endpoint, which returns structured content in the form of:
{
"ip": "55a8:6c55:30ad:7ec6:b003:6bc7:58ab:7253"
}
In this example, the first assertion remains the same as it looks for a 200 success response code from our request. The “Response Content Assertion” element is configured differently to look at the content of the request and match a pattern in the response body:
This second assertion will check to ensure that the response from our HTTP request contains “ip” within the response body. The two key parameters that are configured differently in this assertion versus the first are:
- “Field to Test” is set to “Text Response” – This will examine the content within the response body.
- “Pattern Matching Rules” are set to “Substring” – Any occurrence of the specified pattern within the response body will satisfy this assertion.
- The “Pattern to Test” is set to “
ip” – The response body must contain the “ip” field.
As long as both assertions are satisfied, subsequent requests within the thread group will be run. If either assertion fails, test execution will skip further requests within the same thread group until the next iteration.
Did you know that RedLine13 offers a full-featured, time-limited free trial? Sign up now, and start testing today!