Performance Testing 101

Performance testing ensures your application is fast, stable, and scalable for users. By simulating traffic and concurrent users, you can see how your application responds, then identify bottlenecks in both code and infrastructure. You can then make any necessary adjustments before the code ever reaches production.

There are many different types of performance tests:

• Load tests
• Stress tests
• Spike tests
• Capacity tests
• Soak tests
• Smoke tests
• And more...

Many organizations run performance tests just before a production deployment, or even on an ad-hoc basis, but they’re most effective earlier in the development process. The easiest way to do this is incorporate them into your continuous integration (CI) builds to run automatically when new code reaches a staging or production branch.

Load vs. Stress Tests

There's a lot of confusion over the difference. After all, isn't a high load designed to add stress to an application? And, aren’t both tests simulating a high level of traffic to see how the application responds? On the surface, they seem like they’re driving towards the same objective.

The key difference is the goal of each:

• Load tests help you understand how a system behaves under an expected load.
• Stress tests help you understand the upper limits of a system's capacity using a load beyond the expected maximum.

In other words, stress tests help you determine how a system would behave under an extreme load, such as a DDoS attack, Slashdot effect, or other scenarios. The goal is more to determine a maximum limit than to identify bottlenecks. That way, you can be prepared for unexpected circumstances.

On the other hand, load tests are designed to ensure that you meet user expectations, such as service level agreement (SLA) promises. The goal is to ensure an acceptable overall user experience rather than try to break the application. It lets you confidently deploy new code.

Use the Right Tools

With all the options to run performance tests, using the right tools depend on your requirements.

Stress tests are often run with a combination of Apache JMeter, a protocol-based load testing tool, and tools like EatCPU, EatMem, and EatDisk. JMeter simulates traffic and concurrent users, while the other tools reduce the number of available resources to test various limits, such as a lack of disk space due to a large user file upload.

While you can use JMeter for load tests as well, browser-based load tests provide a much more accurate picture of performance. These load testing tools spin up actual browser instances in the cloud and direct them to a web application, which is especially helpful for applications with heavy client-side assets, such as single-page applications (SPAs).

The LoadNinja Browser-Based Load Test Recorder – Source: LoadNinja

LoadNinja's browser-based load testing platform enables anyone to record load tests in a browser and execute them in the cloud. In addition, you can access step times, browser resources, async calls, and associated navigation timings across both your web UI and API layer to quickly identify and fix bottlenecks.

It’s easy to integrate LoadNinja into your existing CI/CD processes with support for Jenkins and other systems. You can even tie in test management and reporting to Jira with the Zephyr for Jira plugin. By shifting your tests left, you focus on building them sooner and identifying bottlenecks before it’s too late.

Best Practices for Testing

Keep these in mind when developing your load and stress tests, as well as other performance tests in your test suite.

• Start with a performance baseline. Every performance testing effort should begin with a solid baseline. You can spot anomalies and measure performance improvements or degradation over time.
• Prioritize your performance tests. It's impossible to cover every user workflow with performance tests – especially with so many different types. Focus on the most important workflows first.
• Add performance tests to CI/CD builds. Performance tests should be run as part of a continuous integration and deployment process to ensure they’re consistently run on schedule. Ad hoc rarely works in practice.
• Budget time to fix any performance issues. If you run performance tests early enough in the development process, you leave time to make any fixes before a production deployment. This often means shifting your testing efforts left.

Test Correct or Don’t Test At All

Performance testing is a critical component of Agile software development. When building a test plan, it's important to understand the difference between load tests, stress tests, and other types of tests. You should also ensure that these tests are consistently run as part of your CI/CD process.