Key takeaways
- A good scenario mirrors real traffic mix, not the endpoint that is easiest to script.
- Include think time. Removing it produces a load pattern no user creates.
- Start below expected peak and ramp, so you can see where behaviour changes.
To design a load testing scenario, decide what a pass looks like, then copy production: take the user journeys people actually follow, in the proportions they follow them, at the arrival rate your busiest hour sees, with realistic pauses and varied test data. Run that model from the regions your users are in, ramp it up in steps, and watch client and server metrics together.
The rest of this guide walks through each step with a worked example, so you can turn analytics numbers into virtual users, journey weights and a load profile.
What Is a Load Testing Scenario?
A load testing scenario is the full description of the traffic a test generates. It has five parts: the user journeys being simulated, the mix between them, the number of virtual users or the arrival rate, the timing (think time, ramp-up and duration), and the pass or fail criteria. A script that hits one URL as fast as it can is a benchmark of that URL. It is not a scenario, because no real user behaves that way.
Two scenarios built from the same journeys can stress a system very differently. Fifty users pausing a few seconds between pages put a fraction of the load on a server that fifty users firing requests back to back do. Getting the timing and the mix right matters as much as choosing the pages.
Step 1: Set the Goal and the Pass/Fail Criteria
Write down the question the test answers before you script anything. “Can checkout handle the Black Friday peak with 95% of requests under 800 ms and fewer than 1% errors?” is testable. “Is the site fast?” is not, and a test without a target produces charts nobody can act on.
Good criteria use percentiles rather than averages, because an average hides the slow tail that real users feel. Our guide on why percentiles beat averages in performance testing explains why the 95th or 99th percentile is the number to put in a target. Set criteria per journey where the work differs: a search that queries a database can have a looser target than a cached product page.
Typical criteria to agree on before the first run:
- Response time percentiles per journey (for example p95 under 800 ms for search).
- Maximum error rate, counting 4xx and 5xx responses and timeouts.
- Minimum throughput the system must sustain at peak (requests per second or orders per minute).
- Server-side limits you do not want to cross, such as CPU above 80% for more than a few minutes.
Step 2: Build a Workload Model From Real Traffic
The workload model translates production behaviour into test numbers. Pull it from your analytics and server logs for the busiest hour you need to survive, not from a daily average. You need four numbers: sessions in the peak hour, average session duration, pages or API calls per session, and the share of sessions that follow each journey.
Little’s Law turns those into concurrent users: concurrent users = arrival rate x time each user spends in the system. A worked example:
- The peak hour had 18,000 sessions, so the arrival rate is 18,000 / 3,600 = 5 new sessions per second.
- The average session lasts 6 minutes (360 seconds), so the system holds 5 x 360 = 1,800 concurrent users at peak.
- Each session makes 12 page requests, so the target throughput is 5 x 12 = 60 page requests per second.
Then split the virtual users by journey, using the proportions from your analytics. An illustrative mix for a shop:
| Journey | Share of sessions | Virtual users at peak (of 1,800) |
|---|---|---|
| Browse category and product pages | 60% | 1,080 |
| Search | 25% | 450 |
| Add to basket | 10% | 180 |
| Checkout and pay | 5% | 90 |
The checkout row is small, but it is usually the most expensive journey per request, with payment calls, stock checks and database writes. That is why testing endpoints evenly gets the risk wrong in both directions. If you have no analytics yet, our guide to calculating concurrent users for a load test covers estimation from expected traffic.
Step 3: Script Journeys With Think Time and Varied Data
Think time is the pause a real user takes between actions: reading a page, typing a search, filling in a form. It is the reason 1,800 concurrent users generate 60 requests per second in the example above and not thousands. Twelve requests spread over a 360-second session means each user waits about 30 seconds between requests on average.
Remove that pause and the numbers change completely. With think time at zero and a 0.5-second response time, the same 1,800 virtual users would each fire two requests per second: 1,800 / 0.5 = 3,600 requests per second, sixty times the real peak. The test then reports a failure your users would never cause, or you lower the user count until it passes and the test no longer tells you anything about concurrency.
When you script each journey:
- Add think time between steps, with some randomness (for example 3 to 10 seconds on a product page), so requests do not arrive in lockstep.
- Vary the data. Use a CSV or JSON file of users, search terms and product IDs. One account searching for the same word hits caches that real traffic misses and makes the system look faster than it is.
- Handle dynamic values. Extract session tokens, CSRF tokens and IDs from responses and send them back, the way a browser does. A replayed token usually fails with a 401 or 403.
- Include the calls a page really makes, such as API requests fired by the front end, and decide deliberately whether to include static assets your CDN serves.
Our walk-through on simulating realistic user behaviour in load tests goes deeper into pacing and data variation.
Step 4: Choose the Load Profile
The load profile is how the number of users changes during the test. Each profile answers a different question, so a complete test plan usually has more than one.
| Profile | Shape | Question it answers |
|---|---|---|
| Smoke | 1 to 5 users for a minute or two | Does the script work, and are the targets reachable? |
| Load (peak) | Ramp to the modelled peak, hold 15 to 60 minutes | Does the system meet its targets at expected peak? |
| Stress | Keep stepping past the peak | Where does it break, and how does it fail? |
| Spike | Jump from normal to a multiple of peak in seconds | Does it survive a sudden surge, and does it recover? |
| Soak | Normal load for several hours | Do memory, connections or disk degrade over time? |
For the main load test, ramp up in steps: 25%, 50%, 75% and 100% of the modelled peak, holding each step long enough for response times to settle. Stepped ramps show the point where response time starts to climb, which a straight jump to full load hides. Run a smoke test first every time you change the script; it catches a broken login before you spend an hour of load on it. For the other shapes, see our guides to spike testing and soak testing.
Step 5: Pick Test Locations and the Environment
Generate load from where your users are. Check analytics for the countries or regions that send the most traffic and weight the load the same way, for example 50% from North America, 30% from Europe and 20% from Asia if that is your split. Load from a single region tests one network path and can miss problems in a CDN edge, a regional load balancer or DNS.
Test an environment that matches production as closely as you can afford: the same instance sizes, the same database size, and the same CDN, WAF and rate-limit rules. A staging environment with a tenth of the data answers a different question. If the target sits behind a firewall or WAF, allow the load generators’ IP addresses first, or the test measures your bot protection. Agree a time window with whoever owns the system, and never point a test at a third-party service you do not control, such as a payment provider’s live API; use its sandbox.
Step 6: Monitor Client and Server Metrics During the Run
Client-side metrics tell you what users would experience; server-side metrics tell you why. Collect both on the same timeline so a jump in response time can be matched to the resource that caused it.
- Client side: response time percentiles per journey, throughput (requests per second), error rate by status code, and the number of active virtual users at each moment.
- Server side: CPU, memory, database connections and query time, thread or worker pool usage, queue depth, and I/O.
Watch errors as closely as response times. A server that answers fast with 503s, or with a login page because sessions broke, looks healthy on a latency chart. After each run, fix the first bottleneck, rerun the same scenario and compare against the previous result. One run is a measurement; the comparison between runs is what shows whether a change helped.
Example Load Testing Test Cases
A load testing test case is one scenario with a fixed load and a pass or fail rule, written down so anyone can run it again. Here are five for an online shop, built on the shop example from the steps above. The numbers are examples: take yours from your own analytics and targets.
| Test case | Load | Passes when |
|---|---|---|
| Peak-hour journey mix | Browse, search, basket and checkout journeys in their production proportions, at the busiest hour’s arrival rate, for 30 minutes | Checkout p95 is under 800 ms and errors stay under 1% |
| Login burst | Logins jump from the normal rate to twice the peak-hour rate within seconds, then drop back | No 5xx responses, login p95 under 1 second, and response times back to normal within five minutes |
| Search under load | The search journey alone at its peak-hour load (450 virtual users in the Step 2 example), with varied search terms | Search p95 under 800 ms and database CPU under 80% |
| Soak | The journey mix at a normal hour’s load, held for four to eight hours | Memory stays flat and p95 drifts less than 10% from the first hour |
| Breaking point | Load raised in steps of 25% until errors pass 5% | p95 meets its target at every step up to the modelled peak; the run records the step where p95 first misses its target |
Each row uses a load profile from Step 4: the peak-hour mix and search rows are load tests, the login burst is a spike test, the soak row is a soak test and the breaking-point row is a stress test.
Load Testing Best Practices and Common Mistakes
Each practice below is the fix for a mistake that keeps turning up in real test plans:
- Include think time. Without it the test generates a request rate no real user base produces, as the example above shows.
- Test journeys in the mix production shows, not every endpoint evenly.
- Vary users, search terms and products. One user searching one term for one product lets caches make everything look fast.
- Model the busiest hour, not a daily average, and include planned peaks such as a campaign launch.
- Ramp up in steps instead of jumping straight to full load, so you learn the level where the system started to struggle, not only that it failed.
- Watch errors, not only response times.
- Rerun after each fix. Without a repeat run there is no proof the fix worked.
Running Your Scenarios on LoadFocus
LoadFocus runs these scenarios from the cloud without servers to set up. You can build a test in the browser, with GET, POST and other HTTP methods, headers, cookies and Basic authentication, or upload an existing script for JMeter load testing in the cloud or k6 load testing when a journey needs think time, data files and token handling. Tests run from 25+ cloud regions, and you can split the load between regions with custom percentages to match your traffic. Results show response time percentiles, throughput, errors by response code and active users over time, and paid plans add AI analysis that explains the results. See cloud load testing for the details.
Frequently Asked Questions
How do you create load test scenarios?
Start from production data. Identify the journeys users follow most and the share of traffic each one gets, then calculate concurrent users and throughput for your busiest hour. Script each journey with think time and varied test data, set pass or fail criteria such as a p95 response time and a maximum error rate, and ramp the load up in steps while watching client and server metrics.
What is a good example of load testing?
An online shop preparing for a sale is a typical example. The team models the peak hour from last year’s analytics, scripts browse, search, add-to-basket and checkout journeys in the proportions customers use them, and runs the mix at the expected peak for 30 minutes. The test passes if checkout stays under its response time target with almost no errors.
How do you do load testing?
Set the goal and criteria first, build a workload model from real traffic, script the journeys with think time and dynamic data, choose the load profile (load, stress, spike or soak), pick test locations that match your users, and decide which client and server metrics to watch. Then run, fix the first bottleneck and run again.
How do you design a scenario in performance testing?
Map the most common user journeys, such as logging in, searching and buying, and turn each into a sequence of requests with realistic pauses. Weight the journeys by how often they happen in production and run them together, because the interaction between journeys, for example searches competing with checkout for database connections, is often where problems appear.
What makes a test scenario effective?
It is specific and measurable. It names the journeys, the load level, the duration and the pass criteria, and it is built from real usage data, not guesses. It also varies its data and includes think time, so the load it produces looks like traffic your system will actually receive.
How do you design a workload model?
Take the busiest hour from analytics or logs and record sessions per hour, average session duration, requests per session and the split between journeys. Divide sessions by 3,600 to get the arrival rate per second, multiply by session duration in seconds to get concurrent users, and multiply the arrival rate by requests per session to get the target throughput.
Sources
- John D. C. Little, “A Proof for the Queuing Formula: L = λW”, Operations Research, 1961 (checked October 2026).
- Grafana k6 documentation, load test types (grafana.com/docs/k6/latest/testing-guides/test-types) (smoke, average load, stress, spike, soak and breakpoint), October 2026.
- LoadFocus product pages loadfocus.com/load-testing and loadfocus.com/k6-load-testing (regions, region split, HTTP options and metrics), read October 2026.
