Your JMeter scripts are complete and you’re ready to run them in JMeter or in BlazeMeter. All set, right? Hold on. Before you click "start," here are four tips and best practices for things you shouldn’t do with your JMeter script.

Making sure you don’t do these four things will ensure your tests run as smoothly as possible and will save you from the eventual headache of trying to decipher an unreadable script. More importantly, if you don’t do these four things, you’ll be able to have more confidence in the results, without saturating the load generators.

1. Don’t Make Your Script Too Heavy

Your script should be light. So don’t add an exaggerated amount of validations, logic, response parses, debuggers login information, etc., that will just weigh down the script. Otherwise, you won’t be able to execute much load on a machine without saturating its resources, a situation to avoid in order to obtain trustworthy results.

The same happens when you enable too many listeners because they collect a lot of data and render the information in real time which is very resource consuming. Try to avoid this, and do so even more when you plan to use Blazemeter to run your performance tests.

2. Don’t Run the Script Exactly as You Recorded It 

After recording your script, there is still some work to do before you run it. It’s necessary to correlate variables, parameterize, and add elements to faithfully simulate users.

Here is a short list of general samplers and modifications that you’ll need to consider:

• Add a cookie manager. Pay attention whether you need to erase the cookies on each iteration or not (you can set this with a checkbox in the sampler).
• Add an HTTP request default sampler to define the server, port, and protocol in just one place. If you erase this specification from your requests, you will be able to change your test environment easier.
• Review which response assertions you need to add.
• Parametrize hosts in the headers to make your script more flexible and supportable.

There may be other samplers that you need to add depending on your scripts like Cache Manager, counters, regular expressions, Authoritation Managers, or CSV Data Set Config (if you need to read a data file). All of these actions will help you to develop your script in a way that simulates real user actions, which is critical for obtaining reasonable results.

3. Don’t Include Absolute File Paths

Always use a relative path that allows you to run the script from other machines without having to modify it, especially when you need to work with data files. It’s not practical to change the path of your files each time you want to change your workspace. By adding relative paths, you are able to save time later on. This is possible because relative file names are resolved in JMeter according to the active test plan’s path. So make sure CSV files are stored in the relative directory JMeter starts from.

Here is an example of an absolute path setting (the incorrect way):

And now, here is how to do it the recommended way:

In addition, if you are planning to run your test in BlazeMeter, you won’t need to add a path to your file path specifications, but rather only specify the file name. BlazeMeter understands that the data file is in the same directory as your script.

4. Don’t Leave URLs That Don’t Actually Matter to You

After recording your script, you might find some URLs in it that were generated by the browser, like Google Analytics, certain plugins, Windows Update, etc. These make your script less readable and more heavy (because the script will generate more requests) without adding any value to the test. So, verify each request you include in your script and check that the host you are addressing is part of your SUT (system under test). If not, just erase them. Focus only on measuring the performance of servers that you are interested in.

Let’s look at this example of an external URL in a test. Suppose we are testing Abstracta’s servers (this is my company so please do not try this at home!). This means I would be interested in the host, www.abstracta.us.

Here’s what it would look like:

But in our just recorded test plan, we see this URL belonging to an external server — www.youtube.com:

We are not interested in testing YouTube's servers, so we need to erase this request and any others like this one, in order to develop a script that is much more readable.

We’re interested in hearing your tips for writing JMeter scripts! Please share in the comments section below.