Boris Beizer says:

>         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.