Lena Fischer·
k6 script with realistic browse-vs-buy traffic and thresholds wired as a CI gate, ready to run
Design realistic load testing scenarios with proper user journeys, traffic patterns, ramp strategies, and performance acceptance criteria.
Load Testing Scenario Designer
You are a performance testing architect. Design a comprehensive load testing suite for the following application.
**Application Under Test:**
{{application_description}}
**API Endpoints / User Flows:**
{{endpoints_flows}}
**Expected Traffic Patterns:**
{{traffic_patterns}}
**Performance Requirements:**
{{performance_requirements}}
**Load Testing Tool:**
{{load_testing_tool}}
**Authentication:**
{{auth_method}}
Generate:
1. **User Personas**: Define realistic user types with their behavior patterns
2. **Test Scenarios**: 8-12 detailed scenarios including:
- Baseline test (normal load)
- Peak load test (2x expected traffic)
- Spike test (sudden 5x traffic surge)
- Soak test (8+ hours sustained load)
- Stress test (until breaking point)
- Ramp-up test (gradual user increase)
3. **Virtual User Scripts**: Complete {{load_testing_tool}} scripts for each scenario
4. **Data Parameterization**: Realistic test data generation and CSV feeds
5. **Ramp Strategy**: User injection rates, think times, pacing
6. **Performance Thresholds**: Pass/fail criteria for response time, error rate, throughput
7. **Resource Monitoring**: What to monitor on app servers, DB, and infrastructure during test
8. **Correlation & Extraction**: Dynamic value extraction for session handling
9. **Reporting**: What metrics to capture and how to present results
10. **CI Integration**: Automated load test gate in the deployment pipeline
Output complete, executable test scripts and a test execution plan.
Ergebnisse
Load-testing suite for a checkout API using k6. Models a realistic mixed-traffic profile (browsers, buyers, bots) with proper ramp and pass/fail thresholds wired as CI gates.
```javascript
import http from "k6/http";
import { check, sleep } from "k6";
import { Trend } from "k6/metrics";
const checkoutLatency = new Trend("checkout_latency", true);
export const options = {
scenarios: {
browse: { // 80% just browsing
executor: "ramping-vus",
startVUs: 0,
stages: [
{ duration: "2m", target: 200 }, // ramp up
{ duration: "5m", target: 200 }, // sustained peak
{ duration: "1m", target: 0 }, // ramp down
],
exec: "browse",
},
checkout: { // 20% convert
executor: "constant-arrival-rate",
rate: 30, timeUnit: "1s", duration: "8m",
preAllocatedVUs: 50, exec: "checkout",
},
},
thresholds: {
http_req_failed: ["rate<0.01"], // <1% errors or the build fails
checkout_latency: ["p(95)<500", "p(99)<1000"],
},
};
export function browse() {
http.get("https://staging.shopflow.io/api/products");
sleep(Math.random() * 3); // think time
}
export function checkout() {
const res = http.post("https://staging.shopflow.io/api/orders",
JSON.stringify({ sku: "SKU-004521", qty: 1 }),
{ headers: { "Content-Type": "application/json" } });
checkoutLatency.add(res.timings.duration);
check(res, { "order created": (r) => r.status === 201 });
sleep(1);
}
```
**Scenarios covered:** baseline (200 VUs), peak (the sustained stage), and a spike variant (swap in a stage jumping to 1000 VUs over 30s). For a **soak test** rerun with the sustained stage at `8h`. **CI gate:** `k6 run --quiet load.js` — the thresholds make k6 exit non-zero on a regression, so a slow build blocks the deploy automatically.
Modell: Claude Sonnet 4
53 Likes15 SavesScore: 28
4 Kommentare
Daniel Cohen·
The debugging, testing details here are spot on.
Marco Rossi·
Quietly excellent. No fluff, just the code that works.
Priya Nair·
Solid. The typing is tight and it actually compiles, unlike half the snippets I find.
Luca Brunner·
I'd ship this as-is. Maybe rename one var, that's it.