JMeter Scripting Best Practices

Hey All,

Iam Vybhav working as a Senior Performance Engineer

I would like to share some of the best practices for Scripting in JMeter

Script creation / Script development using Jmeter is one of the most important activities in the PTLC ( perf Testing life cycle )

I would like to point out that before just directly jumping on to work on scripting activities due to deadlines pressure, tight timelines and what not, we should pause a little

First of all, try to understand what are the business scenarios or workflows to be scripted,get a fair / decent understanding of the same.Check it out manually/navigate it a few times e2e, try to think in the shoes of an end user

Once that is all done and you get some much needed clarity and relevant data, then I suppose we can proceed ahead with the scripting activities

Now, let’s try to have a look into some of the best scripting practices in JMeter,

1. Proxy should be setup on your local host machine where JMeter is setup / installed
2. Make sure that the Root CA certificate is active and valid otherwise the requests will not get captured at all in JMeter
3. Use In-Built JMeter Functions
4. ${__UUID()} - Generate unique identifiers ${__time(yyyy-MM-dd)} - Current date/time ${__Random(1,1000)} - Random integers ${__RandomString(10,abcdef)} - Random strings

There are many more such In-Built functions available in JMeter

1. Please check if the App under Test ( AUT ) is working well and stable in the Test Env ( staging / non-prod )
2. Always try to ensure to have a clean recording of the test / business scenario user actions ( either record in JMeter using Recording controllers/ Transaction controllers )
3. We can also just navigate the business scenarios in the browser and download the HAR file and convert it to a .jmx file using Blazemeter HAR file converter
4. Always record each of the user actions in a separate individual Recording or Transaction Controller so that its easy to understand and also looks readable/structured
5. There is a setting in JMeter where we can specify the app server domain URLs and only the network traffic or requests pertaining to that domain will be captured otherwise what happens is that quite a lot of junk or unnecessary requests get captured
6. Use a View Results Tree listener while recording the business scenario so that it will have all the requests and responses data which is very helpful in tracing the requests interactions & in scripting/ debugging
7. Configure User Defined Variables ( UDV ) to reference properties:

For example,

${BaseUrl} ${Thread count} ${duration}

${Gateway}

${TestEnv}

so that its easy to maintain and we can just update the values here whenever required and it will be reflected everywhere in the script

8. Name the Thread Groups appropriately based on the business scenario such that it is easily understandable

9. For the HTTP Request samplers — keep an appropriate label so that its easy and quick to identify which request endpoint it is during scripting phase / debugging phase

10. Use HTTP Request Defaults element at the Jmeter Test Plan level

Server Name: ${BaseUrl} Protocol: https

it’s really important to specify the connect timeout and response timeout values

that will vary from service to service, app to app, need to get those details from the Dev Team

For Example, Connect Timeout: 30000 ms Response Timeout: 60000 ms

if we don’t specify these values, what happens is that JMeter will try to keep waiting until and unless response is received and you will end up reporting at times unusually high response times

which should otherwise ideally fail with timeout error and so on

11. Cookie and Cache Manager

HTTP Cookie Manager: Add at Thread Group level for session management HTTP Cache Manager: Enable for realistic browser behavior Configuration: Clear cache each iteration

12. Paramaterisation — CSV dataset config

When every virtual user logs in with the same credentials and searches for the same product for example, you are testing the cache, not the application.

always make sure the test data is realistic and there should be a variety of data

please identify which test data is re-usable, which test data is unique and handle it accordingly

In Production, real users not necessarily repeat the same requests continuously and databases behave completely differently under unique query loads versus cached ones.

Make sure that CSV File Name is appropriate & easy to understand : ScenarioName_TestData_Staging

13. Use Flow Control Action or Timers in Jmeter to specify think time

there are a variety of Timers available in JMeter such as,

• Uniform random timer
• Constant timer
• Gaussian random timer
• Throughput Shaping Timer

It is Not really recommended to have a static think time all the time because it does not reflect the real world behaviour

using Timers like Uniform random timer / Gaussian random timer is more realistic since not exactly every user or every transaction will be performed in real world scenarios at exact fixed intervals

14. Correlation of Dynamic Values

It’s very important to be able to identify all possible dynamic values so as to ensure that Jmeter script does not fail due to incorrect / missing correlations

check the response of each and every request, check the request headers, response headers thoroughly so that there is no hardcoded values — where in most situations, multiple dynamic values get passed in multiple requests

Utilise the various Correlation functions in JMeter,

• Regular expression extractor
• JSON Extractor
• Boundary Extractor

15. Use Response Assertions Accurately

I have seen many a time PT Engineers just apply a Response Assertion / Validation of 200 OK for the Response of a Request which is not exactly a best practice

what happens sometimes is that the content of the Response might actually be incorrect but still HTTP Response Code will be 200 OK and we would be validating the incorrect response

Add a Response Message assertion instead by capturing a value from the Response

16. Use JMeter Listeners purely for Debugging Purposes only

JMeter listeners generate a lot of redundant load on your local machine, and they create lots of objects in the heap memory that might occupy most of the heap space and thereby consumes lot of memory & hence cause problems

17. Use JMeter JSR223 / Groovy Pre-Processor & Post-Processor

Please make use of Pre-Processors and Post-Processors in JMeter while there is a requirement of simulating complex test scenarios/business scenarios

• Writing data to a CSV file and using that data elsewhere
• Encryption & Decryption
• Custom app business logic
• Complex Request Payload
• Complex Correlations

18. Re-try Logic for Requests

We can use Logic Controllers such as

• IF controller
• Loop Controller and
• While Controller

to simulate the re-try Logic for Requests in a Jmeter script depending on the scenario requirements

19. Use Parallel Controller Plugin for JMeter Scripting

By default, JMeter sends requests sequentially, one after another. But real browsers make parallel HTTP requests, especially for static assets/resources. To simulate that behavior more accurately, we can use the jp@gc - Parallel HTTP Requests plugin which is available by installing the JMeter Plugins Manager

A lot of Plugins are available these days which are very helpful in simulating complex scenario requirements

20. Use Different Types of Controllers in JMeter Scripting

What happens sometimes is that, based on very particular or complex scenario requirements, we will have to try to simulate/re-produce that behaviour in our scripts

We need to first understand what exactly that behaviour is like with regards to scenario requirements, do not just straight away jump into scripting

And then we should be able to find out which Controllers in JMeter can possibly help me with that / what best strategy I can use to handle the complex scenario requirements

In such situations, we will have to try a few approaches perhaps to find the best combination of Controllers / Custom Logic as well which can help us to handle it in a more effective manner

21. JMeter Scripts Failure Propagation

Failure propagation determines whether Failure of one sampler / request should automatically cause its Parent Controller or Subsequent Samplers to be marked as failed or skipped

*Suppose, we have not kept* any Failure handling mechanism in place, Then what happens is that you will see multiple failures** because the subsequent requests / dependent requests also Fail due to some Failure/ Error

NOTE:

Having a Failure handling mechanism in place, stops some unnecessary execution of subsequent requests and thereby produces less incorrect errors and the reports look cleaner

Also useful when we don’t want later requests executing after a critical failure.

NOT only that, in certain test scenarios what happens is that there can be a situation where if a particular dynamic value for example is incorrect / not available, then the subsequent request should NOT get executed with that inaccurate value, otherwise it may appear that the particular request has Failed and it will be like a False Error reported

22. Make JMeter Scripts having re-usable components / modular

Create reusable modules for common operations which are across multiple scenarios which makes things a lot easier to handle

For example — Launch, Search, Logot actions

Test Fragment: Store reusable logic that can be called across test plans / test scripts

IF suppose any changes are needed in those Logics, you only need to make the update once at a time rather than in multiple tests scripts repeatedly

Module Controllers: Then Using the JMeter Test Fragment, we can like just call / invoke the necessary re-usable logic across test scenarios/ scripts

We can also use an Include Controller in JMeter

It is a logic controller designed to call / invoke external .jmx test fragments / test plan into a master test plan at runtime.

This enables modular script design, allowing teams to re-use logics like user login and other common user actions instead of duplicating them across multiple test scenarios.