Data Parameterization In JMeter Using Configuration Elements

This tutorial explains Data Parameterization in JMeter using Configuration Elements to pick data from files instead of manual configuration.:

Jmeter Configuration elements are the variables that are used later by the Samplers. Requests made by Samplers can be added or modified using config elements.

JMeter provides config elements so that the real behavior of the web can be reproduced.

=> Click here for Complete Free Training On JMeter (20+ Videos)

Video Tutorial On Data Parameterization

JMeter Configuration Elements

Different types of JMeter Configuration elements are listed below:

• CSV Data Set Config
• FTP Request Defaults
• DNS Cache Manager
• HTTP Authorization Manager
• HTTP Cache Manager
• HTTP Cookie Manager
• HTTP Request Defaults
• HTTP Header Manager
• Java Request Defaults
• JDBC Connection Configuration
• KeyStore Configuration
• Login Config Element
• LDAP Request Defaults
• LDAP Extended Request Defaults
• TCP Sampler Config
• User Defined Variables
• Random Variable
• Counter
• Simple Config Element
• MongoDB Source Config (DEPRECATED)
• Bolt Connection Configuration

Let’s go through some commonly used JMeter configuration elements.

#1) CSV Data Set Config

CSV is used to read the lines from a file and convert them into variables. CSV Data Set Config serves the purpose of data source which can supply a large amount of data as per the scenario which you are testing.

In case a user wants to test web applications for 50 users with different credentials, he does not have to create 50 scripts. Now what all has to be done is to make a file that has the user record like (username, password) and upload this file into CSV. CSV converts all the data lines into variables.

Let’s see an example below to understand how data can be read from the CSV file and can be printed in the View Result tree.

#1) Create a Test Plan

#2) Add a thread group with the number of users as 1, Ramp-up period of 1 second, and Loop count as 5.

#3) Add config element as CSV Data set Config.

• Upload a CSV file with the below data:

• Provide Variable names as Username and Password with the comma-separated delimiter.
• Select Recycle on EOF as true so that the file is re-read once it reaches EOF.

#4) Add Sampler: Debug Sampler.

#5) Add Listener: View Results Tree.

#6) Run the Test Plan by selecting the Start button on the top menu.

Variable values of the CSV file gets printed

Since the number of threads has been chosen as 5 and the CSV file has data till 3 rows only, it re-reads the file again and prints the values starting from 1 for the 4^th sampler.

Below is the description of each field:

Configure the CSV Data Source

Filename: Name of the file which will be read and converted to variables. Browse option to upload file is provided with this field.

For specifying the path of the file, you can directly put the filename if your CSV is in the BIN folder of JMETER directory, otherwise, specify the full path of your system.

File encoding: To read the file, encoding to be used needs to be selected from the drop down.

File encoding has below options available:

If no option is selected, then the platform default will be used. This is not a mandatory field.

Variable Name: Variable list is provided here and has to be separated with the delimiter character. If nothing is provided in this field, the first line of the file is read and considered as a column name.

Use First line as variable name: If the variable name is empty then the first line should have headers. In case the variable name is not empty, then the first line of the CSV file will be used.

Delimiter: Data in the file can be separated using Delimiter.

Allow Quoted Data: It checks if CSV file data should be quoted or not. Users can select the option as True/False from the drop-down.

Recycle on EOF: It represents whether the file should be re-read when it reaches the end. EOF stands for End of the File. By default, the selected value is True.

Stop Thread on EOF? It asks if re-reading should be stopped once it reaches EOF or should continue. By default, the selected value is false.

Sharing Mode:

• All Threads: File is shared with all the threads.
• Current Thread Group: Every file is opened for every thread group.
• Current thread: File is opened for every thread.
• Identifier: Common ID is used to share the file between more than one group.

#2) FTP Request Defaults

JMeter supports the FTP protocol as well. Scripting can be done using FTP, FTPS, and SFTP in JMeter.

Use FTP Request Defaults:

• Create a Test Plan.
• Add thread group.
• Add configuration element “FTP Request Defaults”.
• Add Sampler: FTP Request.
• Add Listener: View Results in the table.

Output displayed in View Results in Table:

Below details will help to know more about the fields in FTP Default:

• Server Name or IP: FTP server name or IP has to be provided here. Provided details are of the server where the file will be placed or can be taken from there.
• Port Number: It is of the FTP server. The Default Port number used is 21.
• Remote File: When the file has to be globally declared then the only path for the file on the FTP server has to be provided in this field else it can be left blank as well.
• Local File: Same as remote file – the field can be left blank, need to provide a path for the local server when file has to be declared globally.
• Local File Contents: Content of the source file can be provided here which can be used at the time of uploading to the server.
• Get(RETR): File to be downloaded from the FTP server.
• Put(STOR): To upload the file on FTP Server
• Use Binary Mode: This mode should be deselected for text files, for all other files binary options should be selected.
• Save File in Response: Selecting this option represents that the output will be stored as FTP response data.

#3) DNS Cache Manager

DNS Cache Manager can be used directly under Test Plan or thread group.

DNS Cache element Manager helps in testing the applications for the scenarios such as the services are not interrupted because of instance failure or any other reason. JMeter uses default cache as a JVM DNS cache.

JMeter sends the request to Load Balancer which further divides the requests to the multiple applications say three applications are under test. At times what happens is request goes to one AUT only, the reason for this is identified as DNS caches on the JVM level.

Also read =>> How to clear DNS Cache

DNS cache Manager helps to resolve this problem in the following way:

• Add DNS cache manager in Test Plan and select the option “Use custom DNS resolver” and provide the Hostname or IP addresses and run the test. It will hit both the IP addresses and not one.
• While using a HTTP request always select Httpclient4.
• DNS Cache Manager should be used under Test Plan or a Thread group element.

Field description:

• Clear Cache each Iteration: Selecting this option clears the DNS cache of every thread once a new cycle is started.
• User System DNS Resolver: If the user wants to use a system DNS resolver.
• Hostname or IP address: Details of DNS servers to be used.
• Host and Hostname or IP address: Static Host and Hostname or IP address is mapped.

#4) HTTP Authorization Manager

HTTP Authorization Manager allows us to give user log-ins for the pages of the web application that are restricted using server authentication. It shows the log in Dialog box if the user tries to connect to the restricted page.

Clear auth on each iteration: If this option is selected, authentication at each iteration will be done irrespective of authentication done in the previous thread group or not.

Base URL: URL that matches one or more HTTP URLs.
Username: Username for authorization.
Password: Password for the above username.
Domain: Domain for NTLM.
Realm: Realm for NTLM.
Mechanism: Which authentication mechanism to be performed has to be provided.

Let’s take an example to understand the same.

Try to log in to the site with URL:  https://httpbin.org/basic-auth/user/passwd.It will show an authentication window.

In case of incorrect Username or Password or if config element is not enabled, it will return Response Code -401

And in the case for correct details and if the config element is enabled – it will return Response code -200

#5) HTTP Cache Manager

HTTP Cache Manager is used to save all the downloaded static files when the execution is in progress. It does so only if the “Retrieve all embedded resources” option is selected. And it will not save the already saved ones until any modification is being done.

Clear Cache in each iteration:

Use Thread Group Configuration to control cache clearing:

Use cache- Control/Expires header when processing GET requests. Selecting this option, the cache control/expire will be verified as per the current time.

Max number of elements in Cache: By default, value is 5000 per user. All the cache is saved in the RAM. In case the user puts value more than 5000, the server can throw an exception “Out of memory “ as well.

Let’s see how it behaves when we use cache-control/expire header option and when we do not use it.

Now select the third option and re-run the test plan:

Selecting the option has reduced the Sample time and latency.

#6) HTTP Cookie Manager

HTTP Cookie Manager has the feature that if the user has any HTTP request and response have a cookie, cookie manager stores that cookie and will use for the future reference for that specific site.

Say browser Edge, Firefox, and Chrome are being used to browse a website. When the user logs in with username and password, it gets stored in the system as a cookie. Next time when the user visits the same website he does not need to put in details like username and password as its already been stored in the system as a cookie.

Clear cookies each iteration: On each iteration, i.e. when thread loop gets executed once, the server-based cookies will be cleared.

Let’s take an example to understand:

• Add thread group to the Test Plan with Loop count 3

• Add HTTP Cookie Manager as a config element in the thread group

• Add HTTP Request wherein provide Server Name and Path
• Add Listener “View Results tree” and observe the output:

As per the above results, we can see that in the first iteration request does not have any cookies whereas all other requests have cookie data.

Now, add details in the cookie manager config element as shown in the image below, and observe the result for the same.

#7) HTTP Request Defaults

This config enables the user to set default values for HTTP request controller.

Example: If you are sending 50 HTTP requests to the server xyz.com- The user has to enter the “server name = xyz.com “ 50 times for the 50 HTTP requests, but with the help of HTTP Request Default, user can make 50 HTTP requests by entering the server name =xyz.com once. It saves the time of the user.

All the requests will go to the Webserver provided.

The HTTP Request Default element points towards the default values which are used by HTTP request elements.

Example for how to use HTTP Request Default element:

• Test Plan: Add HTTP Request defaults and add Server name as tribuneindia.com

• Add Thread Group

• Add two HTTP request wherein provide the path only:

• Add Listener “View Results Tree” and run the script. In case no path is provided request will go to the server provided in the HTTP Request Defaults configuration element.

#8) HTTP Header Manager

HTTP header Manager helps in adding or overlapping HTTP Request headers. JMeter supports multiple header managers. List of the Sampler consists of header entries. From the header entries which are being merged, in case any of them matches with the already existing header name, the old one is replaced with the new one.

Accept-Language, Accept-Encoding, User-Agent, Referrer are the standard headers that can be used.

Header Name and values can be added by selecting Add button.

Accept language is used to define which language server should send the response back to the browser.

Accept encoding: Accept coding defines the coding method which the server should use to respond. In case server cannot send the response in accepted encoding, then server will send an error message and status code as 406.

If in case accept encoding field is not provided, server will assume that client will accept any encoding method.

User-Agent: The user agent allows to find the characteristics like the Browser, version, and Operating system of the web server. When a browser connects to any of the websites, it sends the user agent to the same. User-agent is included in the HTTP header.

Supported browsers to HTTP header Manager are as follows:

• IE
• Firefox
• Safari
• Opera
• Chrome

Referer: When one website refers to another website the address is captured in HTTP referrer.

Let’s see how this HTTP header manager works:

• Create a Test Plan and add Thread Group in it.
• Add Config element HTTP Header Manager and add fields like Accept-Language and Accept with their values.

• Add HTTP Request with server name and path as website.com and login.

• Add listener “ View Result Tree” and Run the script and observe the output

Now add another HTTP header and make some changes like Accept-language as SP-sp and in Accept as well and re-run the script.

Headers are captured from the latest header manager only, but no change is done in the already existing headers.

#9) KeyStore Configuration

Key Store configuration is to configure KeyStore- how to be loaded and the keys to be used.

To get to know who is connecting to the server, some systems require client side certificates to be configured. This config element helps to configure the same, but before adding a KeyStore Config element – Java Key Store should be set up with client certificates.

To do the same following steps needs to be followed:

Create Certificate:

• Using Java Keytool utility
• Through PKI: If done through PKI it should be converted to a format that is acceptable by JKS

Add the following in the system. properties file:

javax.net.ssl.keyStore=path_to_keystore

javax.net.ssl.keyStorePassword=password_of_keystore

Preload: KeyStore to be preloaded or not, can be chosen by selecting true or false.

Variable Name Holding Certificate Alias: Variable Name which will consist of the alias to be used for authentication by client certificate.

Alias Start Index (0 based): The index of the first key to be used in KeyStore.

Alias End Index (0 based): The index of the last key to be used in KeyStore.

#10) LDAP Request Defaults

LDAP Request Defaults allows to add default values for LDAP testing.

If the number of requests are to be made to the same LDAP server, the LDAP Request default config element can be used as the user will not have to enter the same details again and again for the LDAP request.

Four LDAP requests can be configured:

• Add Test
• Delete Test
• Search Test
• Modify Test

These requests can be configured by adding LDAP request to the sampler and then changing the name to Add/Delete/Modify/Search and selecting the property as Add Test/Delete/Modify/Search test, respectively.

#11) LDAP Extended Request Defaults

This config element allows to add default values for extended LDAP testing.

LDAP Config element has nine test operations as defined below:

#1) Thread Bind

Thread Bind is used to start a session with LDAP server. User provides a username and password to initiate the session. Providing incorrect password starts the anonymous session, but will fail the same.

#2) Thread Unbind

Thread Unbind is an operation used to end the session.

#3) Single Bind/Unbind

Single bind/Unbind works as a combination of both the operations. It opens up the session to check for the validity of the username and password and then ends the session.

#4) Rename Entry

As the name suggests, it is used to rename an entry. It can also be used to move the entry to another place in LDAP tree.

#5) Add Test

This is used to add Objects to the LDAP server. It is LDAP “add” operation which is being used.

#6) Deletion Test

Deletion test is used to delete an object from the LDAP tree.

The operation used is called LDAP “delete” operation.

#7) Search Test

LDAP “search” operation is performed for this test.

Specifications can be provided such as maximum time which server should take to perform the search, whether the object to be returned or not (by default it is considered false only). If parse the search result is chosen to be true, the search result will be added to the response data.

#8) Compare Test

Compare test is used to compare the attribute with an already known value. In general, it is used to check for a person’s name in the group i.e. whether the name provided already exists in that group or not can be compared.

LDAP “compare” operation is used for the same.

#9) Modification Test

Modification Test can be used to add/delete/remove/replace the values using LDAP “modify” operation.

FAQs About JMeter Configuration Elements

Q #1) What is the Config element in JMeter?

Answer: Requests, which are sent to the server, are modified or configured using config elements in JMeter.

Q #2) What are thread properties in JMeter?

Answer: The Thread properties include the number of threads that are used to execute the same scenario, and also the number of iterations that can be set from the configuration.

Q #3) Which element in JMeter corresponds to the number of users to simulate?

Answer: Thread Group corresponds to the number of users to simulate as a number of threads can be used to configure the users to simulate to check for Performance and the interaction of the users with the application.

Conclusion

JMeter Configuration elements allow users to get access to any variable which is further associated with values in JMeter. They can modify the values of the requests which are originated from the Sampler.

Config elements can be added by right-clicking on the added Sampler and then selecting config element from the list. They can be accessed only from where it is placed i.e. from inside the tree branch.

There are a number of Configuration elements in JMeter as discussed in this article and can be used as per the user’s requirement.

<< PREV   |  NEXT >>

=> Click here Complete Free Training On JMeter (20+ Videos)