5. Correlation and Parameterization¶

After recording, the script has hardcoded values everywhere - tokens, session IDs, timestamps, and other dynamic values that change every session. The script will fail on replay if these are not handled. This step makes the script dynamic.

Correlation¶

What is Correlation?¶

Correlation is the process of: 1. Identifying dynamic values in the recorded script (values that change every time you run the flow)

Finding where those values first appear in a server response
Extracting them from that response
Passing them to subsequent requests that need them

Common dynamic values: - Authentication tokens / JWT - Session IDs - CSRF tokens - Request verification tokens - Timestamps generated by the server - Dynamic IDs (order ID, transaction ID)

How to Find Dynamic Values Using Fiddler¶

This is where the dual recording pays off. Open the saved Fiddler .saz file and the JMeter .jmx side by side.

Steps:

Look through the recorded requests in JMeter - spot any values that look dynamic (long random strings, tokens, encoded values, timestamps)
Copy that suspicious value
In Fiddler, search for it (Ctrl+F) - Fiddler will highlight (yellow) all sessions that contain that value
Look at the earliest highlighted session - that's likely where the value first appeared
Check where the value lives in that response:
Response body → use the SyntaxView tab to find it
Response headers → check the Raw tab
Cookies → check the Cookies tab
In JMeter, add an extractor (Post-Processor) to the corresponding request to capture that value
Replace the hardcoded value in subsequent requests with the extracted variable ${variableName}

Extractors¶

Use extractors (Post-Processors) to capture dynamic values from responses:

Extractor	When to Use
JSON Extractor	Response is JSON (most APIs)
Regular Expression Extractor	Response is HTML, or value is in headers, or JSON extraction is too complex
CSS/jQuery Extractor	Response is HTML and value is in a specific element

JSON Extractor Example¶

If the response is:

{
  "data": {
    "token": "abc123xyz"
  }
}

Configuration: - Variable name: token

JSON Path expression: $.data.token

Regular Expression Extractor Example¶

If the response body contains:

<input name="__RequestVerificationToken" value="CfDJ8NrAkS..." />

Configuration: - Variable name: verificationToken

Regular Expression: name="__RequestVerificationToken" value="(.+?)"
Template: $1$
Match No.: 1

Handling Timestamps¶

Some requests require a current timestamp in the payload (e.g., requestTime, createdAt). The recorded value is hardcoded and will be outdated on replay.

Use a JSR223 PreProcessor (Groovy) to generate the timestamp dynamically before the request is sent:

// Epoch milliseconds
vars.put("timestampMs", String.valueOf(System.currentTimeMillis()))

// Epoch seconds
vars.put("timestampSec", String.valueOf(System.currentTimeMillis() / 1000))

// Formatted date-time (e.g., 2026-02-12T10:30:00.000Z)
import java.time.Instant
import java.time.format.DateTimeFormatter
vars.put("timestampISO", Instant.now().toString())

Then use ${timestampMs}, ${timestampSec}, or ${timestampISO} in the request body.

Tip: You can also use JMeter's built-in function ${__time(,)} for epoch milliseconds or ${__time(yyyy-MM-dd'T'HH:mm:ss.SSS'Z',)} for formatted timestamps. But for complex date logic (e.g., date +7 days, specific timezone), a JSR223 PreProcessor gives you more control.

Using the Extracted Variable¶

Once extracted, use ${variableName} in subsequent requests. For example: - Header: Authorization: Bearer ${token} - Body: "token": "${verificationToken}"

Parameterization¶

What is Parameterization?¶

Parameterization replaces hardcoded static values with variable data so each virtual user can use different inputs. Without it, all users send the same data (same username, same product ID).

CSV Data Set Config¶

The most common way to parameterize. Reads data from a CSV file and assigns each row to a thread.

Example CSV file (testdata/users.csv):

username,password
user001,Pass@123
user002,Pass@123
user003,Pass@123

CSV Data Set Config settings:

Filename: path to the CSV file (relative or absolute)
Variable Names: username,password
Delimiter: ,
Recycle on EOF: True (start over when all rows are used)
Stop thread on EOF: False
Sharing mode: All threads (default)

Then use ${username} and ${password} in your requests.

User Defined Variables¶

For values that are the same for all users but might change between environments (e.g., base URL, port):

Name: baseUrl → Value: https://staging.example.com
Name: port → Value: 443

Use in HTTP Request Defaults or directly in samplers.

When to Use CSV vs User Defined Variables¶

Use Case	Approach
Different data per user (credentials, IDs)	CSV Data Set Config
Same value for all users, but changes per environment	User Defined Variables
Value extracted from a previous response	Correlation (extractor)

Advanced: Dynamic Forms¶

Some applications have forms that differ based on the user - different fields, different options, different structures depending on the user's profile, role, or account data.

The Problem¶

Extracting each form field individually is not reliable since the fields are not consistent across users
Using HTTP Form Manager works locally - it can capture and replay the form structure per user
However, HTTP Form Manager breaks in distributed testing due to serialization issues across remote machines

The Solution¶

For dynamic forms in distributed testing, you need to develop a script (e.g., using JSR223/Groovy) to handle the form data programmatically rather than relying on JMeter's built-in form manager. This could involve:

Capturing the entire form response and parsing it dynamically
Building the form submission body in a script based on what was received
Storing the form data in a format that survives distributed execution

Note: This is an advanced scenario. If you're running locally, HTTP Form Manager is the simpler option. Only move to a scripted approach when you need distributed testing with dynamic forms.

Tips¶

Correlate first, parameterize second - fix the dynamic values before worrying about test data
Start with the first failure - run the script, find where it breaks, fix that correlation, run again. Repeat until the flow completes
Fiddler is your best friend - the ability to search across all requests and responses makes finding dynamic values much faster than hunting in JMeter alone
Name your variables meaningfully - ${authToken} is better than ${var1}
Check the "default value" in extractors - set a default like NOT_FOUND so you can easily spot extraction failures in View Results Tree