load-testinglisted

# Load Testing `performance` fixes measured slowness after it appears. Load testing finds the breaking point before users do — generate realistic and adversarial traffic, characterize how the system saturates, and validate that autoscaling and capacity claims hold. This is proactive capacity validation, a distinct discipline from reactive optimization. ## When to use - Before launch: validate the system handles expected and peak traffic - After a major change: new endpoint, architecture shift, dependency swap, data growth - Setting or validating SLOs (p99 latency, error rate under load) - Validating autoscaling rules and capacity headroom - Triggers on "load test", "stress test", "capacity", "k6", "Locust", "wrk", "压测", "压力测试", "容量测试" **Not for:** fixing a known performance bottleneck (use `performance`); unit/integration/e2e correctness tests (use `tdd` / `api-testing` / `e2e-testing`). Load testing answers "how much can it handle," not "does it work" or "why is it slow." ## Steps ### 1. Define capacity goals State the targets before generating load — without them, a load test produces numbers without judgment. Extract from SLOs, business expectations, or historical peak: - Expected steady-state load (RPS, concurrent users) - Peak load (2–10× steady state, sustained for how long) - Acceptable p99 latency and error rate under target load - The "break" threshold: the point past which the system is considered failed _Verify: goals are written as numbers with units, not