Skip to content

Test types glossary

Each test type answers a specific question about your system. Choosing the right type before you build a test saves time and gives you a result the team can act on. This page defines every common type and tells you when to reach for it.

Cross-link: the Test types section has a full page per type with MaxoPerf walk-throughs.


A smoke test is a very small, very short run — typically 1–5 VUs for 1–3 minutes — whose only goal is to verify that the test script and target are functioning correctly. Run it before any heavier test to catch broken URLs, missing auth tokens, or script bugs.

In MaxoPerf: create a test with a minimal load profile (1 VU, 2 min). If it shows errors, fix the script before scaling up.


A load test applies a realistic expected load — the traffic level the system is designed and expected to handle — and holds it for long enough to reach a steady state. The goal is to confirm the system meets its performance objectives under normal conditions.

In MaxoPerf: configure the load profile to match your production traffic estimate. Check p95/p99 latency and error rate against your SLO thresholds during steady state.


A stress test drives load beyond the system’s normal operating range to find the breaking point or to observe degradation behavior. The goal is not to break the system for fun but to understand how it behaves under excessive load: does it degrade gracefully, return errors cleanly, or crash?

In MaxoPerf: increase VU count in steps beyond your expected peak. Watch for the inflection point where error rate climbs or latency spikes — that is the stress boundary.


A spike test applies a sudden, sharp increase in load for a short period, then returns to baseline. It tests how the system handles burst traffic: auto-scaling lag, connection pool exhaustion, queue overflow.

In MaxoPerf: configure a ramp profile that jumps from baseline to spike level in seconds, holds briefly, then returns. The cookbook recipe spike and recover has a full walk-through.


A soak test (also called an endurance test) runs at a moderate load for an extended period — hours or overnight — to surface problems that only appear over time: memory leaks, connection pool exhaustion, log file growth, database lock accumulation.

In MaxoPerf: set the test duration to several hours and enable notifications so you are alerted if the test finishes or trips a failure criterion. The cookbook recipe overnight soak test covers setup.


A breakpoint test (also called a capacity test or saturation test) ramps load upward continuously until the system fails or a predefined limit is hit. The goal is to find the absolute maximum throughput (and the conditions at that point).

In MaxoPerf: use a step-ramp load profile with no upper cap. Stop on a failure criterion or when error rate exceeds an acceptable threshold. Record the VU/RPS level just before degradation — that is your system’s practical capacity ceiling.


A scalability test measures how system throughput and latency change as resources are added or as load increases incrementally. Unlike a breakpoint test (which pushes to failure), a scalability test asks: “does adding more resources linearly improve capacity?”

In MaxoPerf: run the same test profile at multiple load levels with different runner counts or locations, then compare the results side by side using the run comparison view.


A volume test focuses on data volume rather than request rate: it loads the system with large datasets, high record counts, or large payloads to verify that the system handles them correctly and within acceptable time bounds.

In MaxoPerf: use a data-driven test scenario (CSV parametrization) with a large dataset and a moderate VU count. Check response times and error rates as dataset size grows.


A configuration test runs the same load profile against different system configurations (e.g. connection pool sizes, cache settings, instance types) to identify the configuration that delivers the best performance. It is a controlled experiment, not a stress test.

In MaxoPerf: run a series of tests with identical load profiles and compare results per configuration change. Document each configuration in the test notes field.


A baseline regression test compares a new build’s performance against a previously recorded baseline to detect regressions before they reach production. The baseline is the known-good measurement: it could be the last release, last week’s nightly, or a manually approved snapshot.

In MaxoPerf: save a reference run as a baseline, then use the run comparison view to evaluate whether the new run’s p95/p99 latency and error rate are within acceptable delta (e.g. ±5%). The failure criteria feature can automate this gate.

See also: Foundations: baselines, SLOs, and error budgets.