Correlation of Dynamic Values

Everyone has heard the phrase “If life gives you lemons… you make lemonade.” Motivationally it means that if life hands us some opportunity we should take it and that all things that appear to us can be squeezed for their juice. Logically speaking, we are facing a relationship where b implies a, “a→b”. We can determine two variables in this relationship where both can take 2 different values as shown below:3

• First variable: ${fruits}: can take the values: [Lemons, Oranges]
• Second variable: ${juice}: can take the values: [Lemonade, Orange Juice]

If we cover all possible combinations of values in both variables, we can get the following:

• If life gives you ${fruit} … have ${juice}:
  • If life gives you “lemons” … have “lemonade”: Successful
  • If life gives you “oranges” … have “orange juice”: Successful
  • If life gives you “lemons” … have “orange juice”: Failed
  • If life gives you “oranges” … have “lemonade”: Failed

Focus on the Client-Server relationship and replace the word “Life” in the relationship with “Server”. If the “Server” sends lemons only it is possible to do something that contains those lemons “Lemonade”, otherwise this relationship would be failed, for example when the server sends lemons and as a response sends “Orange juice”.

Translating this to a technical and software architecture level, if the server returns a SessionID with the value “123abc”, the client can only send back the same session ID “123abc” otherwise the request will be rejected. Many of these values have dynamic behavior, they are generated automatically from the server, if we use any tool to capture traffic (Requests - Responses) like JMeter, these dynamic values (SessionID, Token, Key, ID, etc.) remain recorded, if we do not perform correlation before executing the script, we will send these variables with the values that took when the recording was done, and consequently we will be facing errors in our script due to sending incorrect dynamic values.

Correlation is the process of capturing and storing dynamic values sent from the server and their inclusion in subsequent client requests. A value is considered dynamic when it returns different data for each request in each iteration. Each user session receives a unique set of values. The server expects these values to be received in subsequent requests.

The name correlation indicates that dynamic values in the requests are related to corresponding values in previous responses. The main objective of load and stress testing is to simulate realistically the impact of user virtual interactions on a server. A user virtual object generates HTTP traffic, unlike “real users,” which are not designed to execute JavaScript or fully simulate browser behavior; user virtuals do not implement correlation mechanisms. Instead, they simply reproduce the traffic as it was registered. Therefore, correlation must be performed manually or through an automated mechanism that allows autocorrelation.

One of the most commonly used elements for extracting dynamic values in JMeter is Regular Expression Extractor, which is designed to extract content from server responses using regular expressions and is part of the postprocessors family. There are other extractors like JSON Path Extractor, XPath Extractor, and CSS Selector Extractor. All of these will be explained in another post.

Some dynamic values commonly found in various web applications can be:

• SessionID: The server communicates with multiple clients at any given time. Due to the lack of state in HTTP protocol, the server cannot determine which client sent a particular request. Therefore, when establishing communication with a specific client, the server generates a unique identifier and this ID must be returned on all subsequent requests.
• Token and Key: The authentication process emits a security token that is sent between the server and the client, containing information about users and applications.
• Application Context or Application State: The application context can include various data about user activity. For scalability purposes, it may not be stored in the server but included in all HTTP requests going to and from the server. An example of a dynamic parameter that carries the application state is the parameter “__ViewState” in ASP.NET applications. These parameters can vary depending on the technologies or programming languages.
• Other Values: There are other variables related to element IDs that the server automatically generates. For instance, if we are testing an e-commerce web application, we may find elements such as product ID, cart ID, purchase ID, etc.

To conclude this post, it is valid to specify the difference between parameterization and correlation. In many cases, they tend to confuse each other. Let’s look at a simple example:

• We recorded a scenario of a user logging into an application web. To make such a scenario more realistic, the dynamic data that varies in different test iterations should replace the values registered in the related login fields on the web application. Parameterization replaces the registered value with dynamic data. If we wanted to simulate 3 virtual users, we would have the following values:
• delvis1,mypassword1
• delvis2,mypassword2
• delvis3,mypassword3

However, unlike correlation, this last one does not use values generated from the server; instead, it uses predefined datasets, random data, or other information originating from the client, such as when we use CSV Dataset Config in JMeter.

Simulate realistic behavior in our performance tests is a primary objective, whether it’s simulating virtual users, thinktime, or correlating and parameterizing dynamic values. Remember that if the server returns at a specific moment, “lemons” will only be waiting for lemonade.

See you in a next post.