Skip to content

Test types glossary

Each test type answers a specific question about your system. Pick the type before you build a test. It saves time and gives you a result the team can act on. This page defines every common type and says when to use 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). It only checks that the test script and the target work. 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 long enough to reach a steady state. It confirms that 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 watch how the system degrades. You learn how it behaves under excessive load: whether it degrades gracefully, returns errors cleanly, or crashes.

In MaxoPerf: increase VU count in steps beyond your expected peak. Watch for the 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 shows 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 a long period (hours or overnight). It finds 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 get an alert when 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. It finds 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 step by step. A breakpoint test 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 in the run comparison view.


A volume test focuses on data volume instead of 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 find the configuration that performs best. 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 catch 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 check that the new run’s p95/p99 latency and error rate stay within an acceptable delta (e.g. ±5%). The failure criteria feature can automate this gate.

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