Five best practices to optimise your load tests

Five best practices to optimise your load tests

Whatever stage you are at with the load testing of your web application, being aware of best practices in the industry can greatly enhance your testing efforts.

Here are a few of the best practices to adopt that will significantly improve the quality and accuracy of your load-testing exercise:

  • Ensure your user journey is accurate

It cannot be overstated how important this point is. Most systems and applications are stateful. For example, you can’t remove items from a shopping cart without first registering an account and logging into the system. Your tests need to model these user journeys accurately and appropriately.

Does your system follow an open or closed model? At what rate do users typically arrive at the system? When the users do arrive, how long do they normally stay and what transactions do they typically perform? All of these questions are important to answer accurately in order to create a realistic user journey and load test.

Getting this part wrong can mean you are not accurately measuring the substantial usage of the live system, and your test results will therefore be inaccurate and of less value.

  • Use dynamic test data

Most systems will have caches that store data being used repetitively. If your load test is logging in with the same user, to the same area of the system, this will not make for a realistic real-world simulation. Ensure that you are using varied and dynamic test data to target the application itself, not just the caches.

In order to construct this data you may need to create datafiles to hold the parameters that you will subsequently pass to the test, such as a series of usernames and passwords. Depending on the type of test data required, there is potential that this can also be generated dynamically at runtime by the load testing tool.

It may also be necessary to populate a database with test data before each load test run, so as to ensure an accurate and realistic test.

  • Involve a wide range of stakeholders

Load testing should be the responsibility of everyone invested in the system. Business and analytics-focused people will typically have access to information not predominantly available to the development team. This information should be leveraged to craft accurate load scenarios.

It is both unfair and unrealistic to expect the software developers and testers in the team to have an accurate understanding of how the end-users will use the system. Additionally, developers will often have an idea in their head of how they “think” the user will interact with the system that is completely different from the reality. Involving a broad range of stakeholders across the business will help to mitigate this.

  • Focus on response time percentiles, not averages

Measuring a system’s average response time is an insufficient metric to use in determining performance. A handful of outlying times can significantly skew the data, making system performance seem far better (or worse) than reality.

A superior metric to use is the nth percentile, such as the 90th percentile. This metric can be read as “90% of responses from the system were of this time or less”. Percentile metrics have the added benefit of being more relatable to business stakeholders for reporting purposes.

An average response time still has a place in the load test report, since all data relating to system performance is useful. But it must be used with an awe of caution and not relied predominantly upon as the fundamental measure of the application’s performance

  • Make performance testing part of the agile development process

It can be tempting to wait until the end of the project to start performance testing, as at this point you may be able to build out a test environment with an application that is close to the same level as the one to be used in production. However, waiting until this point of the project lifecycle to begin performance testing can prove to be a pricey mistake.

Assessing the performance of your system only at the end of the project makes it difficult, costly and sometimes impossible to fix issues. A far better approach is to incorporate performance testing early in your project, as part of your continuous integration build.  Remember to identify and measure against clearly defined criteria on what is and isn’t an acceptable level of performance. Test early, test often.

Learn more about Gatling step by step

Learn more about Gatling, the best developer tool to load test your applications, at gatling.io

The Gatling team

Posted in Tech
Posted on 21 April 2020