Why Parameterize Test Data
A test plan that sends the exact same username, product ID, or search term on every single request is unrealistic and can produce misleading results: databases may cache identical query results, unique-constraint inserts will fail after the first iteration, and CDNs or reverse proxies may serve cached responses that hide real backend load. Parameterization replaces hardcoded values with data pulled from an external source at runtime, most commonly a CSV file, so that each thread or iteration exercises the system with distinct, realistic input, exposing performance characteristics a fixed-value test would mask entirely.
Cricket analogy: Testing with one hardcoded value repeatedly is like practicing only against a bowling machine set to the exact same length and line every ball, you never find out how the batter handles variation, which is the real skill test.
CSV Data Set Config Fields
username,password,productId
user001,Pass!2024a,SKU-1001
user002,Pass!2024b,SKU-1002
user003,Pass!2024c,SKU-1003Path (HTTP Request): /v1/login
Body Data: {"username":"${username}","password":"${password}"}
Subsequent request path: /v1/products/${productId}The CSV Data Set Config element reads a delimited file and assigns each column to a JMeter variable, referenced elsewhere as ${variableName}. Key fields are Filename (an absolute path or one relative to the JMX file), Variable Names (a comma-separated list matching column order, left blank if the CSV's first row already contains headers and 'Allow quoted data?' plus a header-detection option are used instead), Delimiter (comma by default, but configurable for tab- or pipe-separated files), 'Recycle on EOF?' (whether to loop back to row one after the last row is consumed), and 'Stop thread on EOF?' (whether to end that thread entirely once data runs out instead of erroring).
Cricket analogy: Recycle on EOF is like a bowling machine's ball hopper that automatically reloads from the top of its feed once it runs out of balls, rather than the session grinding to a halt mid-practice.
Sharing Modes and Distribution Across Threads
The 'Sharing mode' dropdown determines how the file's row cursor is shared across threads. 'All threads' (the default) means every thread pulls from one shared cursor, so as concurrent threads race to read the next row, distribution across threads is essentially random and rows are not duplicated within a single pass. 'Current thread group' scopes a separate cursor per thread group when multiple groups reference the same CSV file. 'Current thread' gives each individual thread its own private cursor that always starts at row one, useful when you want thread N to deterministically always use the same row regardless of iteration timing, but it requires the file to have at least as many rows as threads if each thread should get a unique first value.
Cricket analogy: 'All threads' sharing mode is like all batsmen in a nets session drawing balls from one shared bowling machine feed, whoever's turn comes up next gets whichever ball is loaded, order isn't guaranteed per player.
Place the CSV Data Set Config at the Test Plan level to share one dataset across all Thread Groups, or nest it inside a specific Thread Group to scope the data to only that group's threads.
Alternative Parameterization Techniques
CSV files aren't the only option. The __CSVRead() function offers finer-grained control for reading specific columns without a dedicated config element. For data that must come from a live database, a JDBC Request sampler in a setUp Thread Group can pull rows into variables at test start. Built-in functions like __Random(min,max), __threadNum(), and __Counter(TRUE) generate synthetic values on the fly, useful for things like unique order IDs where an actual realistic dataset isn't necessary, only uniqueness is. The right choice depends on whether you need genuinely representative production-like data (CSV or JDBC) or just algorithmically unique values (functions).
Cricket analogy: Using __Counter for unique IDs is like a scorer assigning each new delivery a strictly incrementing ball number, you don't need real match data, just a guaranteed unique sequence.
If 'Recycle on EOF?' is set to False and the CSV file has fewer rows than the total iterations the test will consume, threads will run out of data mid-test and throw errors; either provide enough rows, enable recycling, or set 'Stop thread on EOF?' deliberately so exhaustion ends the thread gracefully instead of failing samplers.
- Parameterization replaces hardcoded values with realistic, varied data to avoid caching artifacts and duplicate-key failures.
- CSV Data Set Config maps file columns to JMeter variables referenced as ${variableName} in samplers.
- 'Recycle on EOF?' loops back to the start of the file; 'Stop thread on EOF?' ends the thread when data runs out.
- Sharing mode ('All threads', 'Current thread group', 'Current thread') controls how the row cursor is shared across concurrent threads.
- Placing the config element at the Test Plan versus Thread Group level scopes which threads share a dataset.
- Functions like __Random, __threadNum, and __Counter generate synthetic unique values when representative data isn't required.
- Insufficient CSV rows combined with 'Recycle on EOF?' = False causes mid-test data-exhaustion errors.
Practice what you learned
1. What is the primary risk of running a load test with the exact same hardcoded input value on every request?
2. In CSV Data Set Config, what does 'Recycle on EOF?' set to True do?
3. Which Sharing mode gives each individual thread its own private, independent row cursor?
4. Which built-in function would you use to generate a guaranteed-unique incrementing value without needing an external data file?
5. What happens if 'Recycle on EOF?' is False and a thread requests more rows than the CSV file contains?
Was this page helpful?
You May Also Like
HTTP Request Sampler
The core JMeter element for sending HTTP/HTTPS requests to a server, covering method, path, parameters, body data, and implementation settings.
Correlation: Extracting Values with Extractors
Capture dynamic values like session tokens, CSRF tokens, and IDs from server responses and replay them in later requests using JMeter's extractor elements.
Configuring Headers and Cookies
Use the HTTP Header Manager and HTTP Cookie Manager to simulate realistic browser and API-client behavior, including auth headers and session cookies.