The term load test (along with stress test) is so very overloaded that any conversation that uses it is more likely to confuse than clarify — because the term can mean so many different things to different testers. I’ll try to spin off some of the meanings in this and other posts.
One of the spin-offs can be endurance testing. (Some testers like to say soak test, but I think it’s better to keep the slang out.)
So. A new ship has no barnacles. And what we get from the nightly build is exactly like a new ship.
Only over time do barnacles attach to the ship’s hull, growing, accumulating, increasing friction and turbulence, slowing the ship. In the same way, problems can accumulate in an application over time. And that’s why we need the endurance test.
In an endurance test, the application under test is run in a perfectly normal environment, with a perfectly normal workload. The purpose of the test is to determine whether the application continues to operate sensibly over a long period of time. (We already know that it behaves sensibly over shorter periods because of our functionality testing, right?)
There are two main things to look for in an endurance test:
- Degraded performance
- Resource leaks
To discover degraded performance, look for worsenings in: server response time, rendering response time, server throughput rates. A sharp change in any of these may point to a problem, but a trend is especially ominous and should be investigated thoroughly.
To discover resource leaks, monitor usage of: memory, handles, sockets, and other resources that the application uses. As in performance degradations, sharp change is an important indicator, while a trend is a serious warning.