Growth only makes sense if there’s a guarantee that things will work. This principle applies to people, companies, and software. There’s only a point in scaling an application if we know it won’t break right after. And to determine how much systems can grow without crashing, stress tests are necessary.

Like load, peak, and endurance tests, stress tests are a type of performance test. Through these tests, we determine the performance efficiency of a component or system.

The efficiency measured specifically by stress tests is the limit. In other words, these tests determine the limits of the system's operation as well as the point at which the application fails.

Join us in this article to learn more about stress testing, why it’s so important, and how the key performance metrics are analyzed from a stress testing perspective.

Load it as much as the app can handle

The International Software Testing Qualifications Board defines stress testing as a type of performance testing used to evaluate a component or the entire system at or beyond the limits of its estimated or specified workloads. Stress testing can also verify these limits in scenarios where resources—such as memory or server access—are limited.

As stated in the definition itself, stress tests can be either unit tests or integration tests. It is especially important to highlight this point, since stress tests are part of the continuous application development cycle. It is through these tests that we identify minor changes in the system’s behavior or implement corrective or evolutionary changes. The continuous and automated execution of stress tests increases the accuracy in identifying the points that pose the greatest risk of system failure.

We use terms like “failure” and “collapse” because the analogy that applies here is to a physical structure, such as a building. It is no coincidence that we have borrowed two concepts from civil engineering—more specifically, structural design —and applied them to the context of stress testing: the Serviceability Limit State and the Ultimate Limit State.

The first indicates the operating limit. It specifies the threshold beyond which the system ceases to function. The Ultimate Limit State, on the other hand, defines the critical state in which the system “exists.” Once the Ultimate Limit State is exceeded, there is no guarantee that the system can be restored to the state it was in prior to that point.

To determine these two metrics, the application is gradually subjected to increasing load volumes until it stops functioning and then fails. As we explained in the article on load testing, it is characterized by three elements:

1. Concurrent users
2. Requisitions
3. Data Volume and Complexity

Each of these elements illustrates the behavior of a single dimension. By analyzing them all together, it is possible to identify the two limits of the applications and convert them into a single number. From that point on, they can be used as a gauge to determine how safe the application’s operation is.

Stress Testing: How We Identify the Most Important Metrics in Performance Testing

In general, all types of performance tests aim to understand—under different usage volumes—the efficiency of applications by examining five key metrics: concurrent users, throughput, resource consumption, response time, and error rate.

As we've already mentioned, stress tests are like load tests conducted until the application's limit scenarios are reached. Therefore, the observations regarding the metrics will be similar:

1. Concurrent users → this is the control variable (input) for the test. The absolute maximum number of concurrent active connections that can be sustained before the system becomes unavailable is determined empirically.
2. Response time → reflects both the latency and the level of delay per request at the exact moment the system exceeds its designed operational capacity. In other words, when the response time exceeds the threshold identified in stress tests, we know that the application is no longer functional.
3. Throughput → This refers to the upper limit for both the number and the “size” of requests—the number of bytes in each one—that the network and server can process simultaneously before they become overloaded.
4. Resource consumption → For systems scaled using cloud computing—whether with a single provider or a multicloud environment—this metric is essential for stress testing. In addition to identifying the infrastructure’s exhaustion limits, resource consumption metrics help detect memory leaks and other deep coding anomalies that only occur when the load becomes unsustainable.
5. Error rate → In stress testing, the characterization of the error rate is just as important as its “magnitude.” In addition to quantifying the percentage of connections that fail when the application reaches its limits, the error messages returned to the user are also examined.

Stress tests are extremely important for system reliability and, consequently, for the perception of its quality. They offer many benefits. Let’s highlight three of them.

The first is the prevention of financial impact. A system outage that affects systems central to a company’s value stream—even if only for a few minutes—can result in financial losses in the millions. Stress tests are what allow us to predict under what circumstances this might occur. By identifying these scenarios and continuously monitoring quality as a service, it becomes possible to prevent sudden outages when the application encounters unpredictable situations. Furthermore, it is possible to develop contingency plans for outages, thereby reducing financial losses.

The second benefit we highlight is resilience. More than simply defining the Service Limit State and the Ultimate Limit State, stress tests characterize them. Thus, when the software degrades, it is possible to identify the path to follow so that it can resume—often automatically—its ability to return to normal as quickly as possible.

Last but not least, capacity planning—including the extension of limits for applications that use cloud computing, whether with a single provider or a multicloud environment. If the bottlenecks are identified and characterized, and if the limiting factor is computational resources, it is possible to reserve additional cloud resources well in advance to prevent the system from crashing. Consequently, it is even possible to plan how much financial resources should be invested in these scenarios.

It’s always worth remembering that stress tests are part of the continuous application development cycle. During major changes, different types of performance tests—which are already performed automatically—should be supplemented with on-demand tests. This helps validate user behavior during periods of large and sudden fluctuations in system traffic.

Here at Inmetrics, we conduct stress tests during both the Challenge Identification and Solution phases of our AI-Driven Operations Mode. If you need to understand the “inner workings” of your applications in detail to feel completely confident about their maintenance, click here to contact us! One of our experts can walk you through all the benefits of stress testing.