Correlation is the process of extracting and re-using dynamic values. This is something your browser does without you even noticing.
Typically, you send your login and password to the server. In the response from said server there will be some form of ID, usually a cookie. This ID must be used in further requests to ensure that you are logged in.
Correlation is required since we are running protocol based tests. Otherwise the traffic we replay will make no sense to the servers. And because of that our tests would not test the backend, so they would not be relevant.
Additional steps can be taken to reproduce the business logic. Take for instance a webstore, you may want to add more than one product to the cart. It could be even better to add a random number of products to the cart. So you could use a loop and a random number to achieve that.
Also, on any website, users are likely to give up before the end of the testing scenario. You could reproduce this by having only a percentage of them continue.
This is what can make the difference between a good test scenario and an excellent one. Plus most of these do not take a lot of time to prepare compared to their added value.
Asynchronous behavior may also require specific treatement, we’re going to see that in the next section.
A common asynchronous mechanism is polling, it involves sending a request on a regular basis to check if the server has any information to send back.
This it typically something to handle with a loop and a delay. If you plan to run it during your tests, it should be in a separate thread. Otherwise it would be affected by the response time of other requests and not occuring as regularly as it should be. For instance if you put your polling requests in the middle of a test scenario it will have to wait for other requests to finish.
Another form of asynchronous behavior that is pretty common nowadays is websockets. The behavior is really different here since a single request may generate a lot of responses:
You must take that into account when preparing your script.
HTTP Response codes
Before we talk about validating the responses a look at the HTTP response codes:
These codes provide a good first step toward validating the responses. But the HTTTP code is not enough since a 200 OK can include an eror message inside the page.
Validations will take this one step further by controlling that the content of the response is also ok.
For instance here we could controll that there is a “Thank you” message. This way we know everything is alright before we go to the next step.
Strong validations will help you analyze the issues during the test but also debug your test scripts faster. It is important to place them on every key step of your test script. But do not overdo it since these mechanisms also have a high resource cost. And since we will be running hundreds or thousands of virtual users from a single machine, you must be wary of resource usage.
Here are a couple of examples of validations done right: