As the best known and most commonly conducted type of performance testing, load testing involves applying ordinary stress to a software application or IT system to see if it can perform as intended under normal conditions. It is related to its bigger, more brutal cousin, stress testing, but load testing ensures that a given function, program, or system can simply handle what it’s designed to handle, whereas stress testing is about overloading things until they break, applying unrealistic or unlikely load scenarios. Both practices can play important roles in determining exactly how well a given piece of frontend software, such as a website, or a backend system, such as the Apache server hosting that site, can deal with the actual loads they’re likely to encounter through regular use. Stress testing deliberately induces failures so that you can analyze the risk involved at the breaking points, and then, perhaps, choose to tweak programs to make them break more gracefully. Stress testing is useful for preparing for the unexpected and determining exactly how far a given system can be pushed, exploring the outer limits of performance capacity. But when it comes to simply making sure that a software application or physical network can endure the user requests and actions it is likely to encounter in ordinary circumstances, load testing is the right method for the task.
Of course, it should be noted that if your application isn’t actually ready for the expected demands, then a test that was intended to be a load test when you launched it can suddenly become a stress test while it’s running. Read our best practices for load testing to avoid these common pitfalls. Once the load starts causing things to break, from that moment on you are, by definition, stressing the system. This is the main reason the terms are often confused, because the exact same test may turn out to be a load test under some situations and a stress test under others.