JMeter Parameterization - The Complete Guide
This blog post was updated in March 2021 by Pablo Richieri, a performance engineer.
Parameterization is the act of creating variables that will grant us many different configuration options on a load testing script. For example:
- Variables to login with different credentials on a web service
- Variables to use different environments (dev, master, etc.)
- Variables to search for a list of products in an e-commerce site
1. JMeter Parameterization Using External Files
In JMeter, one of the common ways to parametrize your performance scripts is to use a CSV file. Let’s see how this works using one of the examples that we explained earlier: login with different credentials. Let’s assume that we have a login request that works for one specific user:
We can easily parametrize that request and run it across different users. We can see that we are in need of two variables to parametrize this script: for storing the email and password..To do this we’ll need to provide a CSV file with the list of users credentials to use in the login process. (Or, you can use BlazeData).Let’s create a csv file containing different users with emails and passwords:
Now with our CSV file created, let’s add the “CSV Data Set Config” element to our script following these steps:
Right click on Thread Group -> Add -> Config Element -> CSV Data Set Config
A short explanation of ‘CSV Data Set Config’ parameters:
- Name - the element name as it will be used in the JMeter tree.
- Filename - the name of the input file. Relative file names are resolved based on the path of the active test plan. Absolute filenames are also supported.
- File Encoding - encoding of input file, if it’s not the platform default.
- Variable Names - a list of separated variable names that will be used as a container for parsed values. If empty, the first line of the file will be interpreted as the list of variable names.
- Ignore first line - true in case you want to ignore the first line of the CSV file if the variable names are stored there.
- Delimiter - a delimiter that will be used to split the parsed values from the input file.
- Allow quoted data? - true in case you want to ignore double quotes and allow such elements to contain a delimiter.
- Recycle on EOF? - true in case the file test plan should iterate over the file more than once. It will instruct JMeter to move the cursor to the beginning of the file.
- Stop thread on EOF? - false in case of loop iteration over the CSV file and true if you want to stop the thread after reading the whole file.
- Sharing mode: (more info here)
- All threads - the file is shared between all virtual users (the default).
- Current thread group - the file will be opened once for each thread group.
- Current thread - each file will be opened separately for each of threads.
- Edit - all threads sharing the same identifier also share the same file.
In our case, it’s enough to add the “Filename” (user-credentials.csv) and “Variables Names” (userEmail,userPassword) config values and leave the rest to their default settings.
The last step we have to take is to parametrize the login request with our new variables. This can be done by replacing the initial values with appropriate variables from the “Variable Names” configuration field of the CSV Data Set Config, like this:
If we run our test script now, JMeter will replace these variables with values from the ‘user-credentials.csv’ file. Each JMeter virtual user will receive credentials from one of the csv file lines.
The login request by the first and second users will look like this:
2. JMeter Parameterization Using Databases
Another way to parametrize your performance scripts is to use database data. JDBC is an application programming interface that defines how a client can access a database and we’ll be using it to parametrize our JMeter scripts.
After that, configure the database connection by using the ‘JDBC Connection Configuration’ element. Add it following these steps:
Right click on Thread Group -> Add -> Config Element -> JDBC Connection Configuration
‘JDBC Connection Configuration’ parameters:
- Name - the name of the connection configuration that will be shown in the thread group tree.
- Variable Name - the name that will be used as a unique identifier for the db connection (multiple connections can be used and each one will be tied to a different name).
- Max Number of Connections - the maximum number of connections allowed in the connection pool. In case of 0, each thread will get its own pool with a single connection in it.
- Max Wait (ms) - pool throws an error if the specified timeout is exceeded during db connection.
- Time Between Eviction Runs (ms) - the number of milliseconds to pause between runs of the thread that evicts unused connections from the db pool.
- Auto Commit - yes to turn auto commit for related db connections.
- Test While Idle - check idle connections before an effective request is detected. More details: here.
- Soft Min Evictable Idle Time(ms) - the period of time during which a specified connection might be idle in the db pool before it can be evicted. More details: here.
- Validation Query - health check query that will be used to verify if the database is still responding.
- Database URL - JDBC connection string for the database. Examples on this link.
- JDBC Driver class - appropriate name of driver class (specific for each db). For example, ‘com.mysql.jdbc.Driver’ for MySql db.
- Username - database username.
- Password - database password (will be stored unencrypted in the test plan).
In our case we need to setup the mandatory fields only:
- Variable name Bound to Pool
- Database URL
- JDBC Driver class
The rest of the fields in the screen can be left as defaults:
Let’s assume that we stored test user credentials in the database:
Now when the database connection is configured, we can add the JDBC request itself and use its query to get all the credentials from database:
Right click on Thread Group -> Add -> Sample -> JDBC Request
By using the ‘Select Statement’ query and ‘Variable Names’ we can parse the response to custom variables.
We will now have JMeter variables that can be used further in subsequent requests. Specified variables will be created with incremental suffix (userEmail_1, userEmail_2, userEmail_3…..).
To use these variables in the ‘Login request’, we need to add a counter that will be used to access the right values from the JDBC query response. To add the ‘Counter’ element in JMeter follow this steps:
Right click on Thread Group -> Add -> Config Element -> Counter
After that, we can update the ‘Login request’ using the “__V” function. This returns the result of evaluating a variable name expression and can be used to evaluate nested variable references. It is shown here:
The specified configuration is enough to use database values to run the script across different users:
3. JMeter Parameterization Using the ‘Parameterized Controller’ Plugin
If you need to execute a repeating sequence of the same action with different parameters, you can also use the ‘Parameterized Controller’ plugin. This controller allows us to configure a set of variables to be used in every step added into that controller. First of all, you need to install the ‘Parameterized Controller’ plugin as it is not included into the JMeter core. Installation steps of that process can be found here.
Let’s move the ‘Login Request’ into a separate controller and disable it (right-click it and select "Disable"). This is the most preferable way to have a modules container inside your test plan, but also to keep them referenceable so they can be used.
After the installation is over, you can add two ‘Parameterized Controller’ controllers with different user credentials stored in variables:
Right click on Thread Group -> Add -> Logic Controller -> Parameterized Controller
Parameterized Controllers contains the ‘User Defined Variables’ section, where you can specify your parameters. Put the credentials of the first user in the first parameterized controller and the second user credentials in the second parameterized controller.
Now we’ll need to add references to the ‘Reusable Controller’ inside each ‘Parameterized Controller’.
We can do this by adding a ‘Module Controller’, this controller will run all steps in a selected module.
In this case it will call the ‘Login request’ with different parameters. To create a ‘Module Controller’ follow these steps:
Right click on ‘Parameterized Controller’ -> ‘Add’ -> ‘Logic Controller’ -> ‘Module Controller’
When running your script, you will see that the ‘Login request’ triggered each of the parameterized controllers separately. It can be very useful in case you need to run your script across different combinations of input parameters.
Introduction to Correlations
Correlations operate side by side with parametrization. After parameterization, correlation is the process of capturing and storing the dynamic response from the server and passing them on correctly to subsequent requests.
You can learn more from this blog post: “How to Handle Correlation in JMeter”.
You can handle correlations manually, using extractors to save data in variables, or automatically, using a plugin called “Correlation Recorder”. This plugin enables you to easily load test applications with dynamic variables. The plugin records the dynamic variables and automatically correlates them during the recording time, instead of having to manually apply correlations to each request and response.
To learn more about the “Correlation Recorder” plugin visit this post.
That’s it! You now know a number of ways to parameterize your tests. To learn more tips and hacks for building your JMeter scripts, try out our free JMeter academy. To try out BlazeMeter, which enhances JMeter features, sign up for free here.