What Is a Scenario in Load Testing?

Steps, state, and order

A scenario is more than a list of URLs, because the steps are connected. Step one logs in and the response carries a token; step two needs that token in a header; step three needs an order ID that only exists because step two succeeded. The scenario is what carries that state forward.

This is what separates a load test from a stress-the-endpoint script. Hitting /api/orders ten thousand times with a single hard-coded token exercises one cached code path. Ten thousand virtual users each logging in, browsing, and ordering exercises session storage, token validation, write contention, and the connection pool — the parts that actually fall over.

Mixing scenarios in one test

Real traffic is never one journey. A typical hour on an e-commerce site might be 70% browsing, 20% searching, and 10% checking out — and the 10% is where the database writes are. A test made only of the cheap journey will report excellent numbers and predict nothing.

Running several scenarios in one test with weights that mirror production is what makes the result transferable. It also surfaces interference between journeys: checkout contending for the same pool as search is a class of problem no single-scenario test can find.

Designing scenarios that mean something

Model journeys, not endpoints. Start from the paths that carry revenue or risk, keep them short enough to stay maintainable, and drive them with varied data so every VU is not requesting the same row.

• One scenario per meaningful journey — login, browse, checkout — rather than one per endpoint.
• Feed the journey from a data source so users, products, and searches vary. Identical inputs produce a cache-hit benchmark.
• Add an assertion to each step, so a scenario that silently starts returning error pages is not reported as fast.
• Include think time between steps, or the journey generates traffic no human ever would.