backend-load-testing

Backend Load Testing

Purpose

Design consistent, production-grade load testing plans. Every test must follow the same conventions for test type selection, scenario design, metrics collection, threshold definition, results analysis, and CI regression detection.

Agent Protocol

Trigger

Exact user phrases: "load test", "stress test", "soak test", "spike test", "k6", "Locust", "Artillery", "performance test", "benchmark", "throughput", "RPS", "latency p99", "CI performance", "regression test", "load test results", "run a load test", "design a load test".

Input Context

Before activating, verify:

• The system or endpoint being tested is known.
• The test type (stress / soak / spike / smoke) is known. If not, ask: "What type of test? Smoke (quick validation), Load (normal traffic), Stress (breaking point), Soak (long duration), or Spike (sudden surge)?"
• The target throughput and latency SLOs are known.
• The CI integration requirement is known.

Output Artifact

No file output unless the user requests it. Produces load test specifications and scripts as text.

Response Format

For each test:

Test: {name}
Type: {smoke | load | stress | soak | spike}
Tool: {k6 | Locust | Artillery}
Target: {endpoint or system under test}
Duration: {time}
VUs: {number} / RPS: {target}
Thresholds:
  p95 < {ms}
  p99 < {ms}
  error_rate < {%}

For a full test plan:

## {test suite name}
{list of tests with scenarios}

No preamble. No postamble. No explanations. No filler/hedging/transitions. Compress output — why use many token when few do trick.

Completion Criteria

• Test type is selected with justification.
• Tool is selected (k6 for most cases, Locust for Python teams, Artillery for Node.js).
• Test scenarios cover critical user journeys, not just health endpoints.
• Thresholds are defined for all metrics (latency, error rate, throughput).
• Test data strategy is defined (static vs dynamic data).
• CI integration is configured.
• Results analysis format is defined.