Load Testing

Performanceintermediate

// Definition

Verifying system behaviour under expected production load. Confirms the application meets performance targets at typical concurrent-user counts before release.

// Why it matters

Load testing checks behaviour at expected peak traffic — does the system hold its latency and error budget when 1,000 users arrive at once? QA's value is realistic modelling: right concurrency, right think-time, right data variety. A load test on cached identical requests proves nothing.

// How to test

Load testing is a k6/JMeter/Gatling job, not a Cypress one — Cypress is
functional, single-browser. The QA design work:
  • model concurrency to expected peak (e.g. 1,000 VUs, 5-min ramp)
  • vary inputs so you exercise cache misses, not one hot row
  • assert on p95 latency AND error rate < budget, not just "it didn't crash"
  • baseline first, then compare every run against it

// Code Example

k6Constant arrival rate for 1 minute
JavaScript
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  scenarios: {
    api: {
      executor: 'constant-arrival-rate',
      rate: 50, timeUnit: '1s', duration: '1m',
      preAllocatedVUs: 50, maxVUs: 100,
    },
  },
};

export default function () {
  const r = http.get('https://example.com/api/health');
  check(r, { 'status is 200': (res) => res.status === 200 });
}

// Common mistakes

  • Hammering one identical request (all cache hits — unrealistically fast)
  • No ramp-up, so you measure a thundering herd instead of steady peak
  • Passing on "no errors" while p95 quietly tripled

// Related terms

Learn more · Performance Testing with K6

Chapter 4 · Lesson 1: Load Testing — Realistic User Workloads