Ch. 22 · Software Testing

Performance Tests and Realistic Workloads

Performance Tests and Realistic Workloads. Learn the reasoning, a practical example, common mistakes and an interview exercise.

~2 min readadvancedupdated Oct 3, 2026

Performance testing measures behavior under a stated load and environment. Throughput, latency distributions and saturation explain different failure modes.

Before you start

You should understand inputs, expected outputs and the boundaries of the component under test. State the risk a test should detect before choosing a tool or mock. Distinguish controlled dependencies from real integrations so the result does not imply more coverage than the test actually provides.

The practical goal is to reason through this situation: A workload ramps concurrency while recording p95 latency and error rate. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.

Step-by-step walkthrough

Step 1: Specify the workload

Document traffic mix, data size and concurrency.

Step 2: Measure complete outcomes

Include latency distributions, throughput, errors and saturation.

Step 3: Compare equivalent conditions

Warmup and environment differences can distort improvements.

Worked scenario

A workload ramps concurrency while recording p95 latency and error rate.

A new server rejects half its requests quickly, lowering average latency while harming users. Reporting errors and successful throughput prevents that from looking like an optimization. A ramping load test also identifies the point at which queueing and p95 latency rise beyond the target.

Common mistake

A single average latency number can hide overloaded tail behavior.

Verify the behavior

Repeat equivalent workloads and verify the target applies to accepted useful work.

Interview exercise

Define a performance target.

Answer and reasoning

Specify traffic mix, data size, warm-up and capacity assumptions, then compare results under equivalent conditions.

Continue learning

Compare the scenario with the Software Testing interview questions and test your understanding with the Software Testing MCQs. For terminology and implementation details, consult the reference material.

More in Software Testing

read ✓Software Testing · hard

Testing Time with an Injected Clock

Inject a clock instead of calling the system time, freeze it in tests, and remove the sleeps that make tests flaky.

~2 min readread →
read ✓Software Testing · mid

Code Coverage and Its Limits

Read line and branch coverage as a signal, not a goal, and avoid the tests that chase the number without checking behavior.

~2 min readread →
read ✓Software Testing · hard

Scoping End-to-End Tests

Reserve end-to-end tests for critical user journeys, use stable selectors, and avoid duplicating coverage the lower tests already have.

~2 min readread →
esc