Set Variables In JMeter And Property Transfer In SoapUI

Author: Vikrant Kumar & Anjali Kushwaha

Apache JMeter is a fully open-source tool that can be used to assess the performance of dynamic and static resources. SOAP UI is an automated testing tool for SOAP and REST APIs. Both can be used to simulate a heavy load on a server, a group of servers, a network, or an object to test its strength or to analyze overall performance under different load types.

In this blog post, we will explore ways in which we can set variables in JMeter and transfer properties from one request to another. During performance testing, we come across some use cases where requests need a dynamic parameter that gets generated from some other requests. These variables can be used across multiple thread groups depending on the process followed.

1. User-Defined Variables (JMeter):

The variables used in the JMeter script are declared and defined using the User Defined Variables config element in JMeter. Some variables, such as application URL, port, etc., are generally defined in the User Defined Variable element.

Here, we will discuss how to set User Defined Variables (UDVs) with different strategies in thread group(s).

1. Accessible across the same thread group:

The scope of the variables will be local if the UDV is placed under the Thread Group or Sampler. We will create a variable ‘hostName’ that we will use in the sampler to send an HTTP request.

Steps to create UDV:

1. Select the ‘Test Plan’, ‘Thread Group’, or ‘Sampler Node’ where you want to add the UDV.
2. Right-click on the respective thread group (in our case, we will be adding the UDV to ‘First Thread Group’).
3. Go to ‘Add’.
4. Hover the mouse on ‘Config Element‘.
5. Click on ‘User Defined Variables’.

The ‘User Defined Variable’ will be added to the respective thread group.

Single or multiple variables can be declared in the UDV config. There are several fields that can be defined to identify the config element or the variables defined under it.

• Name: The property name of the UDV config.
• Comments: To provide verbose for the config (if any).

The column will have the details of the variable(s) declared:

• Name : The name of the variable to be used.
• Value : The value assigned to the declared variable.
• Description : The description of the variable (optional).

To add a variable in the list follow the steps:

1. Click on the ‘Add’ button present at the bottom.
2. Double-click on the space present under Name to edit the variable name.
3. Double-click on the space present under Value to edit the variable value.
4. Double-click on the space present under Description to add the description for variable (optional).

If more variables are to be added to the same UDV config, we can follow the same steps mentioned above.

Before running the Test Plan, make sure that the option in the figure below is marked in the Test Plan configuration.

After executing the test plan, we will see that the variable referenced in the HTTP Request config of the ‘First Thread Group’ gets replaced with the declared value of ‘www.google.com’. However, the HTTP Request Config in the second thread group is not able to access the value, resulting in an error.

2. Accessible across all the thread groups:

If the UDV is placed under the Test Plan, it will be accessible across all the Thread group(s), Sampler(s), and other configs under that test plan.

To test this situation, we just need to take the User Defined Variable that is already defined in the previous case and place it under the Test Plan. Put the UDV at the top, before all the Thread groups defined, as shown in the figure below.

Now if we run the test, the ‘hostName’ variable defined in the HTTP Request config of the First Thread Group and the Second Thread Group will be able to read its value, respectively.

The method that we discussed above can be preferably used when we need to set a pre-processing value of a variable. However, what if there is a situation where we are required to set the variable dynamically, with its value being received by hitting an API?

2. Set Variable using BeanShell Assertion (JMeter)

Now, let’s consider one such case where we will extract the value from a JSON payload. We will set the extracted value as a variable under the name ‘timeStamp’ and use it in the subsequent requests.

NOTE: We can extract data from XML, HTML, or any other textual format in JMeter.

A use case of a freely available weather API (RainViewer API) is considered in this demonstration. We will try to get radar data from the servers for an available timestamp, which we will get from accessing a different API.

Steps involved:

1. Create a ‘Test Plan’ (named ‘RainViewer Test Plan’).
2. Add user-defined variables such as host names, paths, etc. of APIs that we will use. These are the variables declared (name, ‘value’):
   1. (protocol, ‘HTTPS’)
   2. (timeStampHostName, ‘api.rainviewer.com’)
   3. (timeStampPathURL, ‘/public/maps.json’)
   4. (radarImageHostName, ‘tilecache.rainviewer.com’)
3. Add a ‘Thread group’ to the plan (named ‘First Thread Group’).
4. Add an ‘HTTP Request’ config. This will call the API, which will give us the available timestamps for which the data is available on the server. Set it up as shown in the screenshot below.

5. Right-click on the First Thread Group, hover over ‘Post Processors’, and add a ‘JSON Extractor’. The API is returning the response in JSON format; thus, we are using the mentioned extractor.
6. Configure the JSON Extractor as follows:
   1. Apply to: Main sample only (select)
   2. Names of created variables: timeStamp
   3. JSON Path expressions: $[0] (we will be considering the first time stamp in the response array)
   4. Default Values : 0

NOTE: Multiple variables can be created at once using the ‘;’ separator. Example, names can be ‘ts1;ts2;ts3’ and their values can be ‘$[0];$[1];$[2]’ respectively.

The format of the response that we are getting is shown below:

7. Now we need to add a ‘BeanShell Assertion’, where we will use the JMeter function __setProperty(property name, property value) to set a global variable with the name ‘timeStamp’ and the value will be the one extracted from the response using the JSON Extractor in the previous step. To add this assertion, right-click on the request config, go to Add → Assertions → BeanShell Assertion.

8. Next, we will add a new Thread Group, namely ‘Second Thread Group’.
9. Add an ‘HTTP Request’ sampler to the thread group and configure it as shown in the figure below.

NOTE: Here we have used the function __property(property name), this is a function provided by JMeter to read properties defined in the project. We will use this function to read the ‘timeStamp’ property set by the BeanShell Assertion config.

10. Run the test plan to see the results.

This way, the user can define either static or dynamic properties and use them while testing in JMeter. The mentioned methods can be very handy and helpful in modularizing and structuring your test cases significantly.

3. Property Transfer (Soap UI):

Property transfer in SoapUI is a way to transfer the values of properties across various TestSteps or TestCases. This can be helpful for various purposes, including:

• Passing data from one request to another.
• Storing data for later use.
• Reusing values across multiple tests.

Here, we’re taking a use case where for each request, we need to pass a token that will be generated using another request. So, we’ll transfer the token using property transfer. To add a property transfer to a SoapUI project, you can follow these steps:

1. Right-click on the TestStep or TestCase where you want to add the property transfer.

2.  Type the name of the TestStep and click OK.

3. A new wizard will pop up after the addition of the Token Transfer step.

4. In the property transfer box, click the ‘Add a new property transfer’ icon (+) in the top-left corner. When requested, enter a name for the transfer. Type ‘Token’, then choose OK.

5. In the Property Transfer wizard, select the source and target properties. The ‘Source’ Property will contain the request from which we will extract the token, and the ‘Target’ Property will be the request for which the token is required and will be transferred to this Target request.

Just below the Source, we’ll pass the key of the token in the text editor. In this case, the response is in JSON format; hence, the path language chosen here is JSONPath.

Make sure the TestStep to get the token value from the ‘Token URL’ is before the Token Transfer (Property Transfer) TestStep, and the request which is token dependent is after the Token Transfer (Property Transfer) TestStep.

6. Now declare the property ‘token’ into the ‘Home’ TestStep, which requires the token as Bearer Authorization. As the property transfer will send the token into the request of the ‘Home’ request, add ‘Authorization’ as a header and the value as ‘Bearer ${Request}’:

After successfully running the testCase, this property transfer will transfer the value of the jwtToken from the response of the ‘Token URL’ step to the property of the ‘Home’ step.