Foundations and test types

Performance testing asks a controlled question about how a system behaves under workload. A useful test therefore needs four things before a tool is selected: a system boundary, a workload, measurable outcomes, and an objective or comparison point. Without those, a graph of response times is only an observation.

What performance testing evaluates

The visible side is usually responsiveness: how long a request, transaction or user journey takes. But a complete result also includes how much work the system completed, whether responses remained correct, whether errors increased, whether resources saturated, and whether the system stayed stable during and after the workload.

For an HTTP service, a minimal outcome set is usually:

response-time distribution — not only an average;
throughput — requests or business transactions completed per unit of time;
error rate — failed requests and failed correctness checks;
resource/saturation evidence — CPU, memory, pools, queues, database waits, network or other architecture-specific limits.

The system-side metrics explain why the user-visible metrics changed. The load generator tells you what happened from the client side; it does not, by itself, locate a bottleneck.

Load testing

A load test checks the system under an anticipated realistic workload. The key question is not “Can I create 1,000 users?” but “At the forecast traffic mix and rate, does the system meet the agreed performance objectives?”

A valid load test therefore preserves the important behavior of production: transaction mix, timing, data shape, cache state assumptions, session behavior and the shape of the peak.

Stress testing

A stress test intentionally approaches or exceeds normal limits, or reduces available resources, to reveal failure behavior. Useful outputs include:

the load level where latency or errors become unacceptable;
the first saturated constraint;
whether the service rejects work predictably or collapses;
whether it recovers after the stress is removed.

Stress is not merely “load test with a bigger number.” Its objective is different.

Spike testing

Spike testing models a rapid increase in load and then observes the return to a steady state. It is appropriate for risks such as ticket-sale openings, flash promotions, login storms, notification bursts or event-driven fan-out.

The recovery phase matters. A system can survive the burst but remain unhealthy because queues do not drain, autoscaled instances do not stabilize, connection pools remain exhausted, or retries create a second wave.

Endurance or soak testing

An endurance test holds a representative workload long enough to expose time-dependent degradation. Typical targets include:

memory or resource leaks;
gradually growing queues;
connection/thread/file-handle exhaustion;
cache growth or eviction problems;
periodic jobs that interact badly with normal traffic;
database growth effects;
increasing GC cost or fragmentation.

The question is stability over time, not peak capacity.

Scalability and volume

Scalability testing checks whether the system can grow while continuing to meet its requirements. The input may be more users, a higher arrival rate, more instances, or a larger dataset. A good scalability test records the relationship between added capacity and added useful throughput rather than assuming that doubling hardware doubles performance.

Volume testing focuses on large amounts of data. It is useful when data size changes query plans, index behavior, serialization cost, cache efficiency, storage I/O, compaction or batch-processing duration.

Baseline versus requirement

A requirement or SLO says what the system must achieve. A baseline says what a known version achieved under controlled conditions. They are not interchangeable. A baseline is useful for regression detection, but a historically slow system does not become acceptable merely because a new build matches it.

A good performance objective

Weak: “The API should be fast with many users.”

Better: “Under the defined peak checkout workload, the service must stay within the agreed percentile-latency and error-rate objectives while sustaining the required business transaction rate.”

The actual numbers must come from product requirements, SLOs, production evidence or an explicitly agreed baseline. They should not be invented inside the test script.

What to retain

Performance testing is a measurement discipline. Choose the test type from the risk, define the workload and success criteria before execution, validate response correctness as well as speed, and collect enough server-side evidence to explain the result.

Performance Testing