What is the differences between performance, load and stress testing ?

(from internet)

The diferences between performance, load and stress testing may seem subtle or even non-existent
to non-testers or less experienced testers. There are significant conceptual overlaps between the
three, which can make it difficult to differentiate each approach clearly.

All three assume that the software under test has passed functional testing. All three test approaches
are seeking results based on behavioral measurements of the software at runtime on target
hardware. Often, these measurements are taken when the combination of software and hardware is
near or beyond its expected peak capacity.

The distinctions are in how each test approach is applied and the specific objectives behind each
testing method.

Performance Testing
The main objective of performance testing is to evaluate a softwares runtime efficiency under
moderate load conditions. It reveals imbalances in the softwares execution that result in poor
application responsiveness or slow processing due to latency or resource hogging. Such
characteristics are not functional bugs but rather are defects in the software architecture, design or
its specific implementation. Under load, the software may become I/O bound, CPU bound or suffer
from client-server latency for example.

The response of the software developers, assuming the design is acceptable, is to optimize the
codes performance to an acceptable level of efficiency. As the software matures, performance
testing eventually produces a firm baseline of software performance. At this point, this baseline
becomes part of continuing regression tests to measure deviations in performance as software
changes are added.

Detecting performance bottlenecks may be challenging until a system is sufficiently loaded.

Response times may be acceptable with 20 concurrent users but not with 200 users. An additional
goal of performance testing is recording such pressure point limits, re-testing these limits and
increasing the load as code development continues up to what is specified in the original software
performance requirements.

Load Testing
Once the software has met its performance requirements, load testing begins. Software performance
balancing has been done, so the objective of load testing is more about endurance and volume. It
attempts to simulate the real-world conditions it will be subjected to after deployment. Usually, this is
done with automated tools to achieve a realistic deployment scale.
Examples of volume testing include simulating thousands of users accessing the application or the
addition of tens of thousands of new user accounts in a brief time period. Endurance testing, also
known as soak testing, is the application of load testing continuously over a long period of time as
might occur, for example, on a banks online service during semi-monthly paydays.

Load testing reveals software defects that might not occur during the shorter intervals of
performance tests. Such defects include memory leaks, buffer overflows, failure to close network or
inter-module connections and gradual degradations in response time.

Stress Testing
Performance testing tunes software performance, while load testing ensures the software can
manage peak deployment requirements. Stress testing then allows testers to bang on the software
with hammers. Its primary purpose is to apply maximum pressure to see where and how the system
breaks. It measures the softwares responses under extreme conditions, especially its ability to
degrade gracefully, retain data and recover its previous state.

Stress tests push the software far beyond normal load limits, restrict resources and create
unexpected integrity issues in a variety of ways:

Doubling the maximum limit on users

Closing and restarting database access suddenly
Randomly shutting down network connections
Removing runtime libraries upon which the software depends
Severely reducing physical resources such as disk space, memory or network
bandwidth

If, after such conditions are applied, the system is able to recover without loss of data and without
creating security leaks, it has successfully passed the stress test. It is also desirable that during
failure the system issued meaningful error messages and a crash trail that assists operators in
understanding the root cause of failures.

Naturally, there is much more that can be written on this topic including specific tools and techniques
employed for each testing type and how these tests integrate depending on development
methodologies. For instance, agile development teams may desire to apply these three test
methodologies during sprints rather than deferring them to a point when the software is nearing
release. In any case, this discussion has drawn sufficient distinctions between performance, load
and stress testing to alleviate confusion regarding their specific methodologies and objectives.