Understand Requirements and Flow
Table of Contents
Why this is tool-neutral
What to ask before opening any load testing tool — the application under test, the scope, the NFRs, the test data, the environment constraints — does not change with the tool. I already wrote that up once and I am not repeating it here:
- Understand Requirements and Flow (JMeter track) — the questions to ask and the pass/fail criteria template
- Performance Testing Fundamentals — the test types (smoke, load, stress, endurance, spike, scalability) that come out of those requirements
Read those first. What is specific to k6 is how the answers turn into script structure, which is this page.
How: translate NFRs into k6
| From the requirements | In k6 |
|---|---|
| NFR response time target (e.g. p95 < 500ms) | a thresholds entry on http_req_duration, e.g. 'p(95)<500' |
| NFR throughput target (e.g. 200 TPS) | the constant-arrival-rate executor, which holds an iteration rate steady instead of a VU count (ramping-arrival-rate instead, if the rate itself should ramp through stages) |
| Expected concurrent users | VUs — options.vus for a flat load, or a stages array for a ramp |
| Each business flow identified in the requirements | one exec function per flow, wired into its own scenario in options.scenarios |
That last row is the one that shapes the script the most. A JMeter test plan puts every flow's samplers under one Thread Group tree; k6 keeps flows apart as separate functions, so a script with a login flow and a checkout flow reads as two short functions rather than one long one. k6 Concepts shows what that looks like in practice, and Load Model covers picking stages vs. ramping-arrival-rate per test type.
Tips
- Write the threshold before the script. If the NFR says "p95 under 500ms with under 1% errors", write
thresholds: { http_req_duration: ['p(95)<500'], http_req_failed: ['rate<0.01'] }first. It turns a vague target into a script that exits non-zero on its own when the target is missed — no manual reading of a report required. - A TPS-based NFR is not a VU count. If the requirement is "200 orders per second", don't guess a VU number and hope it lands near 200 — use
ramping-arrival-rateand set the rate directly.