Stress is a common test category, but it can have different meanings depending on context and goals. Some stress tests are used to see how a system behaves under load. Others are used to generate random operations against the software to gain coverage outside of what is hit in more deterministic tests. Another goal of stress can be to simple find help new bugs in a system, as once a set of regression tests pass, they rarely find new bugs unless the area they test is changed.

Testing under high load is the classic meaning of stress testing. To do this operations are performed against the software until a system bottleneck is reached. For instance, when stress testing a database, disk IO could be the first bottleneck that is reached, thus limiting the rate of operations of the test to the rate the disk can satisfy requests. The location of a bottleneck can change over the lifetime of a system. In the previous database example caching disk IO could have been implemented, thus moving the bottleneck to another layer such as the network.

When load testing is being done, the primary concern is ensuring that the bottleneck being hit is in the system being tested, not in the test. A test which does extensive logging of operations to a file might hit a bottleneck writing to the test’s log file. This would leave the software under test not hitting any limits.

Another goal of stress testing can be to see how a system behaves under random input. For this style of stress test the goal is to hit a wide amount of coverage during a stress run in hopes that areas not tested elsewhere are hit. While this approach does test a broad area of a system, the types of operations tend to be shallower as it is hard to have random operations which have dependencies on other operations. Tests can be made to honor dependencies, but this will reduce the randomness of the test. The other big disadvantage is knowing what the state of the system being tested should be at any given point in time. This reduces the ability to verify the results of stress operations. Often tests of this nature resort to just trying to make the system crash, as even the returns of individual calls can be hard to predict, especially if there is more than one thread and/or process perform operations.

The first to kinds of stress testing are not mutually exclusive and dovetail into a third goal of stress testing: finding bugs. Many stress tests are written not to specifically load a system or to widen the coverage of a system, but instead to make the system fail in different ways every time the test is ran (or at least as long as bugs that are found are fixed). This kind of stress test is usually written with the internal details of the system being tested in mind. If an application caches certain kinds of data, then a stress test for the system might perform operations involving the data being cached. A classic cache would involve one writer thread hitting a resource with another thread performing reads against said resource.