Performance Testing Vocabulary

A spike test specifically simulates a sudden, extreme traffic surge — not gradual increase, not sustained load.

A load test runs at expected normal or peak levels to confirm SLAs under realistic conditions. A soak test (endurance test) runs moderate load for extended periods to surface memory leaks and connection pool exhaustion. A stress test increases load gradually to find the system's breaking point. A spike test is the correct answer: it introduces an abrupt, dramatic increase in a very short time window — exactly like a flash sale or viral event — to test auto-scaling, queue management, and failure behaviour.

Key vocabulary:
• Spike test — sudden, extreme traffic surge; tests auto-scaling and failure recovery
• Load test — confirms behaviour under expected production traffic levels
• Stress test — gradual overload to find the system's breaking point
• Soak test (endurance test) — sustained moderate load over hours/days; detects memory leaks
• Auto-scaling — automatic provisioning of additional compute resources under increased load

Throughput measures the system's processing capacity — how many requests it handles per second.

Option A describes Time to First Byte (TTFB) — a latency-related metric. Option B describes response time — the total elapsed time for a complete transaction. Option D describes network latency or ping — a network-level metric independent of application logic. Throughput (measured in RPS, TPS, or requests/min) indicates how many operations the system successfully completes per unit time — a key capacity metric. High throughput with low error rate indicates a healthy, scalable system.

Key vocabulary:
• Throughput — requests/transactions successfully processed per second (RPS / TPS)
• Latency — the delay between a stimulus and a response; often used for network-level timing
• Response time — total elapsed time from sending a request to receiving the complete response
• TTFB (Time to First Byte) — the time until the client receives the first byte of the server response
• RPS — Requests Per Second; the standard unit for API throughput measurement

P99 (99th percentile) means 99% of requests fall at or below this threshold — not an average, not a failure rate.

Option A reverses the meaning: P99 is a success metric, not a failure rate. Option B confuses percentile with mean — the mean would be much lower than P99 in most distributions. Option C is incorrect: P99 does not mean all requests took exactly that value. Option D is the precise definition: if P99 = 1,240 ms, then 99% of requests completed faster than 1,240 ms, and only the slowest 1% exceeded it. P99 and P95 are used in SLAs because they capture the experience of most users, including those on slower connections.

Key vocabulary:
• Percentile (P95, P99) — the value below which X% of observations fall
• SLA (Service Level Agreement) — a formal commitment on performance, uptime, or quality
• P50 (median) — the midpoint; 50% of requests are faster, 50% are slower
• Long tail — the small percentage of slow requests that P99 captures and the mean hides
• Worst-case latency — the response time experienced by the slowest subset of users

A 2.4% error rate under load indicates server-side failures that must be investigated before release.

Option A ignores the error rate entirely — 2.4% errors at scale means thousands of failed transactions per hour. Option B misreads percentile: a 90th percentile of 780 ms means 90% of requests completed within 780 ms, not that 90% failed. Option C is wrong — a 2.4% error rate is never "safe to disregard" in a payment or critical-path API context; even 0.5% can be significant depending on volume. Option D is the professional interpretation: the mean is acceptable, but the error rate signals real server-side failures (HTTP 5xx, timeouts) that need root-cause analysis.

Key vocabulary:
• Mean response time — the arithmetic average response time across all sampled requests
• Error rate — the percentage of requests receiving an error response (HTTP 4xx/5xx or timeout)
• HTTP 5xx — server-side error responses (500 Internal Server Error, 502, 503, etc.)
• Root-cause analysis — investigation to identify the underlying reason for a failure or anomaly

Performance acceptance criteria must specify the endpoint, the percentile threshold, the load level, the error budget, and the test duration.

Options A, B, and D use language that cannot be tested: "fast", "acceptable", and "pass" are all subjective without numbers. No engineer can write a JMeter test or Gatling simulation against "must be fast." Option C is the professional standard: it names the specific endpoint (/api/search), the latency threshold (500 ms), the percentile (P95), the concurrency level (500 users), the error rate budget (0.5%), and the test duration (10 minutes) — every element can be directly configured in a load test tool and objectively pass/failed.

Key vocabulary:
• Performance acceptance criterion — a quantified, testable non-functional requirement
• Concurrent users — the number of simultaneous active sessions during a test run
• Error budget — the acceptable percentage or count of errors during a given period
• Test window — the duration of the performance test run (e.g. 10 minutes of sustained load)
• Non-functional requirement (NFR) — a quality attribute such as performance, security, or availability