Skip to main content

What Is Load Testing?

Short answer

Load testing asks whether the system still completes a real user journey when N people do it at the same time. You control concurrency (virtual users or arrival rate) and duration, then judge the run with latency (p95), HTTP fail rate, and 4xx / 5xx breakdowns against an SLO. It is not volume testing (how much data already exists) and not stress testing (how far past expected demand you can push before collapse).

Part of Performance testing guides.

Who this is for​

Teams that can already prove checkout works for one user (Playwright / SmartTests) and now need an authoritative answer to “will it still work on launch day / Black Friday / the sales spike after a newsletter?”

Load testing in one sentence​

A load test is a controlled traffic experiment: generate concurrent sessions against a representative environment, measure whether journeys complete successfully and fast enough, then compare this run to a prior comparable run so a silent p95 creep is visible.

Typical pass/fail is not “the process exited 0.” It is:

  • Thresholds you approved (p95 under X ms, fail rate under Y%)
  • No degrade vs last release on the same journey / environment / profile / dataset — see performance regression testing

What load testing is not​

Confused withWhy it is different
Functional E2EOne user, empty-ish DB, assertion on correctness. Load tests many users; asserts on latency and errors.
Volume testingVolume = large data. Load = many users. A list page that is fine with 50 VUs and three invoices can still die at 1 VU with 100k invoices.
Stress testingStress finds the breaking point past expected load. Load tests the load you expect to serve.
A request-per-second hammerHitting POST /checkout in a tight loop is not “50 shoppers.” Real users think, wait on UI, and retry. Model journeys with think time.
Production RPS copied into k6Telemetry tells you which paths are hot. Absolute VUs still come from capacity policy—not from blindly pasting RUM counts.

Anatomy of a useful load test​

  1. Journey — the user path (search → product → cart → pay), not a single URL.
  2. Concurrency model — closed (fixed VUs looping) or open (arrival rate). See load testing patterns.
  3. Ramp — start low so you can tell “env never became healthy” from “we melted at 80 VUs.”
  4. Think time — pauses between steps so the VU mix looks like people, not a flood of HTTP.
  5. External doubles with realistic latency — live Stripe/LLM calls make the test flaky and expensive; 0 ms stubs hide queueing. Stub, but sleep a documented typical.
  6. SLOs + comparison — thresholds for the profile, and a prior-run overlay.

Virtual users vs requests per second​

  • Virtual users (VUs) — concurrent sessions executing the journey. k6 ramping-vus is the usual closed-model load test.
  • Arrival rate (open model) — N new iterations start per second regardless of how slow the last one was (constant-arrival-rate / ramping-arrival-rate). Better when you must not let a slow system “protect itself” by completing fewer loops.

If you only crank RPS on one endpoint, you under-test client waterfalls, connection pools, and session cache. If you only raise VUs with zero think time, you over-test a synthetic hammer nobody will produce in production.

TestChimp’s default authoring stance: load = N concurrent users completing the journey, ramping from a low start, with think time—not a tight request loop. Product layout: load vs volume.

What to measure (and why)​

A green http_req_failed of 0% can still be a failed load test if p95 doubled. Track at least:

SignalUtility
HTTP duration p95 (and p99)User-visible slowness; SLO gate
Fail rateCombined errors (http_req_failed)
5xx rateServer / dependency faults under load
4xx rateAuth, validation, stock, script bugs—not the same as “the site is down”
VUs over timeConfirms you actually reached the intended concurrency

Full unpack: performance test metrics. TestChimp ingest keeps these plus timeseries so Executions can overlay two runs.

How TestChimp runs load tests​

Functional SmartTests stay in Playwright. Load tests are Grafana k6 files under the mapped tests root:

Smoke (max_vus: 1) is for authoring contracts. Real load numbers live in k6/profiles/ and run-perf-tests.policy.md—agents do not invent VUs from TrueCoverage.

Example shape (k6 closed-model load)​

export const options = {
  scenarios: {
    checkout: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '2m', target: 20 },
        { duration: '5m', target: 20 },
        { duration: '2m', target: 0 },
      ],
    },
  },
  thresholds: {
    http_req_duration: ['p(95)<800'],
    http_req_failed: ['rate<0.01'],
  },
};

Always run through TestChimp wrappers (run-journey.sh), not bare k6 run—wrappers ingest summary + timeseries. Details: how tests are organized.

Common load-testing mistakes​

  • Testing localhost as if it were staging then promoting the numbers to a release gate
  • Zero-latency mocks that never fill pools or timeout budgets
  • One composite that does everything with no isolated journey—you cannot tell which path degraded
  • Comparing smoke to 100 VU load and calling it a regression
  • Copying production RPS into k6 without a capacity decision

Frequently asked questions

What is load testing?

Load testing verifies that a realistic number of concurrent users can complete a user journey within agreed latency and error SLOs. You vary virtual users or arrival rate—not dataset size.

How is load testing different from stress testing?

Load testing uses expected concurrent demand. Stress testing exceeds that demand to find the breaking point. Soak testing holds realistic load for a long duration. Same tools, different questions.

How many virtual users should I use?

Absolute VUs, RPS, and duration are a capacity decision (policy or explicit approval)—not something to copy from production telemetry or TrueCoverage. Start with a documented smoke profile, then promote an approved load profile.

Can Playwright do load testing?

Playwright is for functional and UX journeys (SmartTests). Load and volume belong in a dedicated executor such as k6 so you can generate real concurrency without launching hundreds of browsers. TestChimp keeps both in Git and links them to the same scenarios.

How does TestChimp help with load testing?

Agents author scenario-linked k6 journeys, run related tests after a PR or release git range, ingest p95 / 4xx / 5xx / fail rate, and overlay comparable prior runs so you catch degrades—not just threshold misses.

Turn load testing into a release check

Scaffold k6 with `/testchimp init-perf`, author load journeys for the checkout path, and overlay this release against the last comparable run in Executions.

Start free on TestChimp · Book a demo

Related pages