|
One of the most common, but unfortunate misuse of terminology
is treating "load testing" and "stress testing" as synonymous. The
consequence of this ignorant semantic abuse is usually that the system
is neither properly "load tested" nor subjected to a meaningful stress
test.
1. Stress testing is subjecting a system to an unreasonable load
while denying it the resources (e.g., RAM, disc, mips, interrupts,
etc.) needed to process that load. The idea is to stress a system to
the breaking point in order to find bugs that will make that break
potentially harmful. The system is not expected to process the
overload without adequate resources, but to behave (e.g., fail) in a
decent manner (e.g., not corrupting or losing data). Bugs and failure
modes discovered under stress testing may or may not be repaired
depending on the application, the failure mode, consequences, etc.
The load (incoming transaction stream) in stress testing is often
deliberately distorted so as to force the system into resource
depletion.
2. Load testing is subjecting a system to a statistically
representative (usually) load. The two main reasons for using such
loads is in support of software reliability testing and in
performance testing. The term "load testing" by itself is too vague
and imprecise to warrant use. For example, do you mean representative
load," "overload," "high load," etc. In performance testing, load is
varied from a minimum (zero) to the maximum level the system can
sustain without running out of resources or having, transactions
suffer (application-specific) excessive delay.
3. A third use of the term is as a test whose objective is to
determine the maximum sustainable load the system can handle.
In this usage, "load testing" is merely testing at the highest
transaction arrival rate in performance testing. |
|