As a professional software testing services firm, we supply JMeter scripts to our clients so that they may use Loadium to run performance tests fast and easily. Even if you are not a Loadium customer, you can benefit this checklist to advance JMeter scripts in 9 Steps.
We recognize that the scripts we provide are frequently utilized by teams that do not have formal JMeter training but still want to be able to modify them and understand what they do. We’ve been working on creating scripts that are simple enough for anyone who isn’t a JMeter expert and can read, comprehend, change, and execute them in Loadium without problem.
We’ve developed a nine-point checklist that we go over before providing a script to a customer based on our previous experiences. Checklist contains a set of best practices that is available to you right now.
1. Divide Your Test Script Into Groups By Using Simple Controller
Usually a performance test script contains lots of different requests and processes. For example, for an e-commerce end-to-end scenario, there will be actions like, logging in, searching for a product, seeing the product listing page, choosing an item, adding to cart, etc. To prevent any confusion and to provide an understandable script, you can use Simple Controllers, so that your requests will be divided into separate folders. But be careful about giving descriptive names for your simple controllers.
2. Debug Logging Should Be Enabled
We often allow logging in our test components to debug any errors that may happen during the development and execution of a script. But once the scripting process is finished, you should delete or disable these elements to avoid them from affecting the process of performance testing. If you don’t disable them, there will be times when the script consumes too much of the load generator’s resources. And for example, if you used Debug Sampler during scripting, if you don’t disable it before testing, you will likely see Debug Sampler as a request in your test report.
3. Thread Group Name Should Be Descriptive
Usually Performance Testers don’t give Thread Group a rational name. But this is not the best practice. Even though you know the test script like the back of your hand, stakeholders and other people won’t have enough information and knowledge. Your script should be descriptive and meaningful for every member of the team.
4. Do Not Include Any Additional Requests or Embedded Sources
During recording of a test scenario, you can see some requests for images, CSS files, javascript, etc. that are not required to be included in the script. Because you can enable the Retrieve All Embedded Resources option in the parameters of an HTTP Request sampler corresponding to a primary request in JMeter. By doing that, you won’t have to include those media requests into your test script.
Doing this is also one of the best practices of JMeter. Because the flow will respond more correctly this way than if all secondary queries had been pre-programmed in the script. But keep in mind that if your load generators are not that powerful, doing that will result in more resource usage.
5. Run Your Test with Low Number Of Threads
Before proceeding with performance testing, you should check the status of your load test scripts. To do that, you can make some debug runs with a low number of threads. After receiving approval from the system owners, you can run the test with thread numbers like 20, 50, 100 and so on. This way, you can make sure that you will keep receiving successful responses for multiple requests at the same time.
6. Redirections Should Be Automated
If you ever see response codes like 301 or 302 during load testing, you should know that they indicate some kind of redirection. Some requests cause us to be redirected to a different element, suggesting that the information we seek is accessible elsewhere. In JMeter, you don’t need to create a special HTTP Request for these requests. Because we can utilize the Follow Redirects option in the HTTP Request order (parent request) to execute this process for us.
7. Don’t Forget to Create Assertions For Your Requests
You should create assertions to ensure that the response you have is proper and correct. Assertions simply analyze the response code and response message, and check if it is fit to the assertion criterias you defined.
We should also highlight one important point about assertions. Sometimes we get “200” response code for a request and think that was successful. However, we can encounter requests that seem successful but actually failed, due to development deficiencies. To avoid this situation, you should add some logical actions that check the response message. For example, you can extract the “success” key of a JSON response by JSON Extractor and check if it was “true” or not.
8. Make Use of HTTP Request Defaults
Every HTTP Request sampler in JMeter contains fields like protocol, server name, port number, and (request) path.
Usually systems and applications have lots of different environments like debug, test, pre-production, production, etc. Sometimes you will need to run the same test in different environments.
To switch your environment, you should change the server name for all your requests. Because of that, It’s never a good idea to leave these values as hardcoded.
We can use the HTTP Request Defaults configuration parameter to avoid this issue. We can configure the server and port defaults to wherever we want the requests to go in this element.
9. Verify the Situation of the Requests That Are Sent to External Servers
There may be some actions that send requests to the servers which are not a part of your system under test. If the stakeholders are interested in analyzing the performance of the host, it’s always a good idea to reaffirm with them, because if they aren’t, the HTTP request can be omitted and no traffic to the server is generated.
If you include those external requests in your test script, you should also be careful. Because if you send too many requests to external servers, you can get blocked from sending requests, since your performance testing would be seen as a DDOS attack.
