Performance Testing
Use when asked to measure application responsiveness and resource use under workload — the umbrella covering load, stress, endurance, and spike testing (see load-testing, stress-testing) — to identify bottlenecks and confirm the system meets performance requirements.
Performance testing measures an application's performance and responsiveness under specific workloads and scenarios — identifying bottlenecks, determining system limitations, and confirming the application meets its required performance standards, as the umbrella discipline several more specific techniques sit within.
The four core variants
- Load testing — performance under normal and peak loads, simulating high user-traffic volume and monitoring response time, throughput, and resource utilization (see Load Testing in depth).
- Stress testing — behavior under extreme loads beyond capacity, pushing the system to its limits to find where and how it degrades or fails (see Stress Testing).
- Endurance testing — performance over an extended continuous period, surfacing issues that only manifest over time (memory leaks, gradual resource exhaustion) that a short test would never reveal.
- Spike testing — performance during sudden, significant traffic spikes, checking for degradation or failure specifically at the moment of a fast increase, distinct from a sustained peak (see Peak Testing).
Choosing which variant to run
Each variant answers a different question about the same underlying system: load testing asks "does it handle expected traffic well," stress testing asks "where does it actually break," endurance testing asks "does it degrade over time even under stable load," and spike testing asks "does a sudden jump specifically cause a problem a gradual increase wouldn't." A comprehensive performance testing effort typically needs more than one of these — passing load testing alone says nothing about endurance or spike behavior.
Common pitfalls
- Running only load testing and calling it "performance testing" — each of the four variants finds a different class of issue; skipping the others leaves real gaps.
- No endurance testing for a long-running service — a memory leak or slow resource exhaustion is invisible in a short load test and only surfaces after hours or days of sustained operation.
- Vague performance requirements — "the system should be fast" isn't testable; a specific target (e.g. 95th-percentile response time under 200ms at expected peak load) is what performance testing actually checks against.
Learn more
- Load Testing, Stress Testing, Peak Testing for the specific variants in depth.
- Benchmark Testing for comparing performance-testing results against a reference point.
- System Quality Attributes for where "performance" sits among the fuller catalog of quality attributes.