From:
http://bernardstudios.com/archive/2004/10/06/361.aspx > 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.
