Create a Load Test
A load test is configured on its Configure tab. Start by choosing the mode — you can switch it on the saved test at any time.
The walkthrough configures a Simple load test first — tests, users, repeats, environment, and browser — then switches the same test to Advanced to set the target and paths, load profile, threshold gates, and review the generated k6 script before saving.
Choose A Mode
| Mode | What it does | When to use it |
|---|---|---|
| Simple | Concurrent browser users replay your generated feature tests and time every step. No k6 script involved. | You want realistic, UI-level load and per-step latency — the easiest path. Features need a generated test first. |
| Advanced | Protocol-level k6 load — paths, virtual users, ramp, duration, think time, and threshold gates. TestVibe generates the k6 script. | You want raw HTTP throughput, precise threshold gates, or load against endpoints rather than journeys. |
Create The Test
- Select Load Testing from the navigation rail.
- Select New load test in the list rail.
- Pick Simple or Advanced and configure the sections below.
- Select Save, then Run when you are ready.
Simple Mode Settings
| Setting | What it controls |
|---|---|
| Tests | Use Choose tests or Change to open the picker, select generated tests, and choose Done. These are the tests the browser users replay. If the list is empty, generate tests first — or switch to Advanced for URL-based load. |
| Users | How many browser users run concurrently, up to the lower of your plan limit and 100. Above 20 users TestVibe automatically spreads the load across multiple cloud machines — you still see one test and one merged result. |
| Repeats per user | How many times each user replays the features (users × repeats × selected features = total planned feature replays). |
| Environment | Choose a saved environment or Custom URL to set this load test's target. |
Simple runs report per-step latency under load — you see which step of the journey degrades first.
The Browser picker applies one saved Playwright configuration per load run (or the stored Default configuration when no valid selection is supplied). Browser VUs always launch headless Chromium/Chrome. They read the configuration's viewport, base URL, reduced motion, HTTP credentials, permissions, and geolocation; they do not fan out across configurations or switch to Firefox/WebKit. A mobile-sized viewport here is not full device emulation: user-agent, touch/mobile flags, and device scale factor are not applied by this load harness.
Advanced Mode Settings
| Setting | What it controls |
|---|---|
| Target & paths | The URL the virtual users hit and the paths requested each iteration. |
| Load profile | Virtual users, total duration, ramp-up window, and think time. Users ramp from 0 to the target over the ramp-up, then hold. |
| Thresholds | k6 pass/fail gates such as p(95)<1000 on http_req_duration or rate<0.01 on http_req_failed. The run fails if any gate fails. |
| Generated k6 script | A read-only preview of the script TestVibe generated from this configuration. |
Both modes support Thresholds. Simple starts without default gates, but any gates you add are enforced: http_req_duration measures a whole feature replay, http_reqs counts completed replays, and http_req_failed is the fraction that failed. These are not individual HTTP-request measurements in Simple mode. Advanced starts with protocol thresholds. Review gates when switching modes because the metric meanings differ.
Sizing Guidance
- Start small — 10 users for 60 seconds is enough to validate the configuration end to end.
- Increase users gradually and keep ramp-up at 10–20% of the total duration so the system warms up realistically.
- In Advanced mode, set thresholds from a passing baseline run rather than guessing; tighten them once results are stable.