Stress testing tries to break the system under test by overwhelming its resources or by taking resources away from it (in which case it is sometimes called negative testing). The main purpose behind this madness is to make sure that the system fails and recovers gracefully — this quality is known as recoverability.
Where performance testing demands a controlled environment and repeatable measurements, stress testing joyfully induces chaos and unpredictability. To take the example of a Web application, here are some ways in which stress can be applied to the system:
- double the baseline number for concurrent users/HTTP connections
- randomly start and stop application work
- run processes that consume resources (CPU, memory, disk, network) on the Web and database servers
- Making numerous, concurrent attempts to access a single Web site
- Running several resource-intensive applications in a single computer at the same time
However, stress testing does not break the system purely for the pleasure of breaking it, but instead it allows testers to observe how the system reacts to failure. Does it save its state or does it crash suddenly? Does it just hang and freeze or does it fail gracefully? On restart, is it able to recover from the last good state? Does it print out meaningful error messages to the user, or does it merely display incomprehensible hex codes? Is the security of the system compromised because of unexpected failures? And the list goes on.