Performance, Load and Stress Testing
Performance, Load and Stress Testing
This domain tests whether you can distinguish the performance test types, choose the right metrics, model a workload, and diagnose bottlenecks. It is the most calculation-heavy non-functional domain.
Test types
- Performance testing: measures response time and throughput under specified conditions.
- Load testing: runs at or near expected peak load to confirm the system meets its service levels.
- Stress testing: pushes beyond capacity to find the breaking point, then observes recovery and whether data is corrupted.
- Spike testing: applies a sudden, short-lived surge.
- Endurance (soak) testing: sustained load over hours to expose memory leaks, resource exhaustion and degradation.
- Capacity and scalability testing: determines maximum supported load and whether performance scales with added resources.
- Configuration testing: compares performance across hardware, network or parameter settings.
Metrics
Response time (report percentiles, not only the mean), transactions per second (TPS), throughput, concurrent users, error rate, hits per second, think time, and resource utilisation for CPU, memory, disk I/O and network. The 2-5-8 second rule is a common usability benchmark for page response.
Little's Law
N = X × R, where N is the average number of concurrent items in the system, X the arrival or completion rate, and R the average time in system. It links users, throughput and response time and underlies workload modelling.
Worked example
A system serves 5,000 user sessions per hour; each session submits 10 transactions; average response time is 2 seconds; think time between transactions is 8 seconds. Arrival rate X = 5,000 × 10 / 3,600 ≈ 13.9 transactions per second. With think time, a single user issues one transaction every (2 + 8) = 10 seconds, i.e. 0.1 tps, so concurrent users needed ≈ 13.9 / 0.1 = 139. If the question asks for in-system concurrency from Little's Law alone, N = 13.9 × 2 ≈ 28. Both numbers are legitimate; the wording decides which is required.
Process and bottleneck analysis
Identify objectives and service levels, define realistic business scenarios and transaction mix, build and parameterise scripts, prepare test data, execute with monitoring, analyse, tune, and retest. Typical bottlenecks: CPU saturation, memory leaks, thread or connection-pool contention, database lock waits and missing indexes, chatty network calls, and insufficient bandwidth.
Traps
Equating concurrent users with registered users; omitting think time; reporting averages that hide the 95th percentile; running stress tests against production data without controls; expecting a stress test to prove stability rather than to find the limit.
Key ideas
Choose the test type from the question's intent - expected peak means load, beyond capacity means stress, long duration means endurance.