Tag Archives: “Load Test”

I Feel Much Better Now, Really I Do

I’ve written about how overloaded the term “load test” is, and how we might spin off some of its meanings into other useful terms. The first was the endurance test.

The second spin-off can be the recovery test.

The idea of the recovery test is to deprive the application of a critical resource, then determine whether its behavior is acceptable.

Some such critical resources:

  • Memory
  • Disk space
  • Network connection
  • Database connections
  • Database integrity
  • Power

Desired behaviors:

  • Data is retained, especially user data.
  • The problem is logged as fully as possible.
  • Users are informed of the problem in a timely manner.
  • The application restarts, if necessary and appropriate.
  • The application resumes previous activities, if necessary and appropriate.

Barnacles? What Barnacles?

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

Degraded Performance

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.

Resource Leaks

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.