Generate K6 Load Test Scripts and Analysis

The skill builds K6 load tests around K6's core model: independent virtual users (VUs) running the script in parallel, iteration- or duration-based execution, staged ramp-up/down to simulate realistic traffic, and thresholds that turn a test into an automated pass/fail check on metrics like response time and error rate. A typical test defines stages (ramp to 10 VUs, hold, ramp to 20, hold, ramp down) and thresholds such as http_req_duration: ['p(95)<500'] and http_req_failed: ['rate<0.1'], with setup()/teardown() for one-time prep and cleanup and check() plus custom Rate/Trend metrics inside the main function.

Use it to design realistic scenarios beyond a single flat-load script: data-driven tests that pull payloads from a CSV via SharedArray to avoid duplicating data across VUs, session-based tests that group() a login step and subsequent authenticated operations, or named load patterns - spike testing (quick ramp to high load and back) and stress testing (staged ramp well beyond normal capacity to find the breaking point). It is not a functional-correctness testing tool: check() assertions here validate the system under load, not general application logic.

Input is the target API/service and the load profile to simulate. Output is a runnable .js test script plus, at runtime, K6's own metrics: http_req_duration percentiles (p50/p95/p99), http_req_failed error rate, http_reqs throughput, active vus, and completed iterations, optionally tagged per request (e.g. tags: { endpoint: 'data', version: 'v1' }) for finer-grained analysis. Execution and output options are set on the CLI:

# Run with specific VUs and duration
k6 run --vus 50 --duration 10m script.js

# Run with environment variables
k6 run --env BASE_URL=https://staging.api.com script.js

# Output results to InfluxDB
k6 run --out influxdb=http://localhost:8086/k6 script.js

# Generate HTML report
k6 run --out json=results.json script.js

Scripts read environment variables at runtime via __ENV (e.g. BASE_URL, API_KEY), can stream results to InfluxDB or Grafana-compatible outputs, and can produce a custom summary through handleSummary() - stdout text, summary.json, or an HTML report via the k6-summary jslib helper. Performance tips include batching requests, reusing connections, setting timeouts, implementing a gradual ramp-up so the system isn't overwhelmed immediately, and monitoring the load-generator machine's own resource usage so it isn't the bottleneck. For debugging, failed checks are logged with the response status and body so a failing request can be diagnosed without re-running the whole test.

Engineers who need production-realistic K6 load tests - proper VU ramping, thresholds, data-driven or session-based scenarios, and custom metrics - rather than a single hard-coded request repeated in a loop.