Reuse and Maintain JMeter Scripts

So far, we have seen some important components of JMeter which are required to start with the performance script creation. But, just recording the actions and generating the script will not solve the purpose of creating a robust and reliable performance script. We would need to analyze all the dynamic values which may change in each fresh session of the application. So in order to maintain the consistency in each and every execution of the scripts, we need to get our hands dirty. Following are the few things we should do; whenever we plan to use the recorded scripts for future use:

Follow the previous post “Creating First JMeter Script” for recording of the scripts

After recording the scripts we have something like the below image:

In the above image you can see that I have highlighted the ‘HTTP Header Manager’ inside a request. This node will be added by default in each and every recoded request. So, your first step will be removing all these ‘HTTP Header Manager’. After removing this node, we will add three new components under the Thread node. You can see the highlighted components at the bottom of the tree.

>> HTTP Request Defaults

>> HTTP Cookie Manager

>> HTTP Cache Manager

We will discuss each of these components in detail, but before that see the changes done in Test Plan:

See the highlighted area in the above image, which is showing the added user variables. All these added variables in the Test Plan can be used as global variable for the complete suite.

Now, come back to the added components. 

HTTP Request Defaults: This element lets you set default values that your HTTP Request controllers use. This makes life too easier, if your all request are going to the same server. You could add a single HTTP Request Defaults with the ‘Server Name or IP’ field filled in, instead of using same detail for every request. Now, see the details filled in below image of HTTP Request Defaults:

Notice all the highlighted fields in the HTTP Request Defaults area, all of these are defined in the Test Plan as user variables. Using this technique will help you in maintaining your scripts. You will have to change it all only at one place, hence saving your time and effort.

HTTP Cookie Manager: It stores and sends cookies just like a web browser. If you have a HTTP Request and the response contains cookie, the cookie manager automatically stores that and will use it for all future request to that particular web site. Select ‘Clear cookies each iteration’ checkbox, it will clear all server-defined cookies each time the main Thread Group loop is executed. By default ‘Hc3CookieHandler’ is selected, If you have a web site to test with IPv6 address, choose ‘HC4CookieHandler’.

HTTP Cache Manager: While preparing for performance testing of any web application, we try to mimic exactly the same environment as in the real world. For the best and near to actual performance data, it is very important to consider as many things we can. As we know that every browser has some mechanism that reduces the traffic over the internet/network and Cache is one of them. A cache is just like a repository, which stores data and used to expedite the process of retrieving the data. HTTP Cache Manager is used to add caching functionality to HTTP requests within its scope to simulate the browser caching feature. Select the ‘Clear cache each iteration’ checkbox. You can also set the number of elements stored in cache, by default it is 5000.

Till now, we have discussed only the configuration part of this suite; which is mostly the one time task. Now we will see the actual scripts and the changes need to be done, so that those scripts could be used as many times we want without any major changes. So let’s do it.

Following images in sequence will show a simple example of how to extract some data at runtime and use in subsequent requests.

In the below image the ‘Add to cart’ is a POST request with some data being sent to the server. See the highlighted ‘token’ field in parameters section where a hexadecimal value is being used and that might change every time client request the server. So in order to find the token value from the active session of the web site; we need to extract the data at run time. But before that, we need to identify the request from where we can get this value.

In this particular example, I have found that value in Launch request. See the highlighted area in below image where that value is in the response body of the Launch request.

We found the location from where we have to extract the value at runtime. But the question is how to do that? The answer is ‘Regular Expression Extractor’. To add a regular expression extractor, follow the steps mentioned below:

Do a right-click on the desired component and follow the displayed image.

Once Regular Expression Extractor added to the node, we need to write regular expression syntax to extract the desired value from it. See the below image, how regular expression is being used to extract the token value from the response body of the Launch request.

Notice the highlighted group of fields and specifically the ‘Regular Expression’ field. I have written regular expression syntax to fetch the token value from the Launch request. There are other fields as well which we will discuss in detail in a separate post. To use the extracted value we have a reference name in here, let’s see the below image:

See the difference here, ${staticToken} has been used to assign the extracted value to the parameter token.

Now our suite is ready to execute as many times you need to. This is a simple example for ‘How to make your scripts reusable’. Further we will discuss many more components which will be required/would help to make performance test scripts reusable, robust and reliable.

Please like and comment if you liked the post. Stay tuned to see more posts.

Facebook Page: https://www.facebook.com/crazzzygig

References: http://jmeter.apache.org/