Load, stress, spike, endurance, and volume testing investigate different causes of performance degradation. They can use similar user scenarios, but the experimental question changes: normal load, increased intensity, abrupt change, prolonged execution, or a large dataset.
Names and boundaries vary across tools and teams. Record the actual profile, duration, data, and criteria in the plan. “We ran a stress test” says little about readiness without these conditions.
Load testing: expected operating conditions
Load testing checks quality under an agreed normal or peak profile. For example, search receives 100 requests per second and checkout receives 10. Each journey is expected to preserve its response-time and correctness criteria.
Use a realistic mix of reads and writes, popular and uncommon objects, and response sizes. A fast isolated endpoint does not validate a purchase journey. Success means meeting criteria during a stable measurement window at the load actually achieved; virtual-user count alone is insufficient.
Stress testing: higher load and limits
Stress testing examines behavior above ordinary load and exposes degradation. After testing 100 RPS, a team might increase intensity in stages to 150, 200, and 250 RPS, observing useful throughput, errors, queues, and recovery at each stage.
Stress testing does not always require complete failure. If the goal is to find an SLO violation point or capacity limit, state that explicitly along with stop conditions. Some tools distinguish limit-finding as breakpoint testing. The concrete experimental result matters more than a universal interpretation of the name.
Spike testing: an abrupt surge
Spike testing examines sudden load changes, such as rising from 20 to 300 requests per second within a few seconds. This helps assess a ticket sale opening or a mass response to a notification.
Measure scaling reaction time, accumulated queue size, rejected request share, and recovery time alongside peak errors. After the spike, old jobs may keep the system slow even at normal incoming load. Check integrity too: confirmed bookings must not disappear and retries must not create a second payment.
Endurance and soak testing: effects over time
Endurance testing, often called soak testing, examines sustained operation at a chosen load. It reveals effects absent from short runs: resource leaks, growing queues, temporary-file accumulation, and periodic jobs.
Choose duration according to the suspected failure mechanism. A two-hour run may miss overnight cleanup, daily token renewal, or log rotation. Examine trends and abrupt changes throughout the run. Memory growth alone does not prove a leak; inspect garbage collection, caching, and resource release after load ends.
Volume testing: data scale
Volume testing examines the effect of data quantity and structure. A million orders can alter query plans, report generation time, and index size even at the same 20 RPS. Volume can also refer to files, message history, or queue contents.
Prepare realistic relationships and distributions. A million identical rows do not represent ten years of history with large customers and varying filter selectivity. Check pagination, totals, timeouts, and untruncated results. Data volume and request intensity are separate variables worth investigating independently first.
Choosing a test type
Connect the experiment to change risk. A new cache needs warm-up, invalidation, and prolonged-use checks. An index change calls for realistic data volume. An advertising campaign calls for an expected profile and a sudden influx. Rate-limiter changes require overload and recovery checks.
Every release does not need every type. First establish scenario correctness at minimal load and under expected conditions. If errors already occur there, a complex multi-hour experiment rarely speeds up diagnosis.
Practical example: a booking service
Suppose the agreed peak is 50 search starts per second and the expected database contains two million active and archived records. The team chooses four independent investigations using the same scenario version.
- →Load: 50 searches per second for 30 minutes; p95 below 700 ms, errors below 1%, and correct results.
- →Spike: an abrupt rise to 200 searches per second and return to 50; agreed recovery within two minutes of the decrease.
- →Endurance: six hours at 50 searches per second; no unbounded queue growth, and criteria remain satisfied across time windows.
- →Volume: the same profile on two datasets, including a realistic two million records; compare query plans, result completeness, and latency separately.
These are illustrative parameters, not a ready-made standard. For stress investigation, define stages, acceptable impact on the environment, and stop conditions separately. Perform all operations in an agreed environment with test bookings.
Making comparisons fair
Test type does not automatically determine the request arrival model. Choose an open or closed model deliberately for each profile, preserve the scenario mix, and measure actual intensity. If the generator cannot start enough work, record that as an experimental limitation.
Separate warm-up, steady-state measurement, ramp-down, and recovery. Check residual queues and data state before the next run. Otherwise, the second test inherits the first test's accumulated effects and results become incomparable.
Key takeaways for QA
Performance test types examine different risk dimensions: intensity, rate of change, duration, and data volume. Select the type from a hypothesis and describe its profile with numbers and conditions. A useful report shows correctness, degradation boundaries, recovery, and the limits of what was tested.