Section 1 Review
You've finished Performance Testing Foundations, the first section of Performance Testing. This page is a dedicated recap — bookmark it as a fast reference, separate from the modules themselves.
Section Summary
✔ What is Performance Testing? — why correctness and performance under load are independent properties, and where this path builds on Database Testing's and API Testing's own QA-level performance-recognition modules ✔ Performance Metrics and SLAs — latency, throughput, error rate, and resource utilization; why a percentile (p95, p99) reveals what an average hides; the SLA-vs-SLO distinction ✔ Performance Testing Strategy — prioritizing what deserves dedicated performance testing by traffic, business criticality, and risk; the baseline-load-stress test sequence; what a written strategy captures
How they build on each other: Module 1 established why performance needs its own dedicated testing effort. Module 2 gave you the precise vocabulary to measure it. Module 3 closed the section with the planning discipline that decides what to test, in what order, before any test actually runs.
Core Vocabulary Quick Reference
| Term | What It Means |
|---|---|
| Latency | How long one request takes |
| Throughput | How many requests/transactions processed per unit time |
| p95 / p99 | The response time below which 95% / 99% of requests fall — reveals the slow tail an average hides |
| SLA | A formal, often contractual performance commitment |
| SLO | A team's own, typically tighter internal target |
| Baseline → Load → Stress | The required order: normal behavior, then expected peak, then past-capacity breaking point |
Section 1 Knowledge Check
Five realistic scenarios. For each, decide which module's framework applies, and what you'd check or do first. No answers are provided here. Solutions: Section 1 Solutions.
Scenario 1: A feature passed every functional test, but the team wants to know if it's actually ready for a major traffic event next month.
Scenario 2: A performance report shows "average response time: 400ms," and the team wants to know if that's actually good news.
Scenario 3: A QA team has three weeks to performance-test five features before a release, and can't test all five equally thoroughly.
Scenario 4: A team wants to run a stress test to find their system's breaking point, but hasn't run any other performance test yet.
Scenario 5: A business team has a contractual SLA of "99.9% of requests under 2 seconds," and QA wants to set an internal testing threshold.
Continue to Section 2
Designing a Performance Test, starting with Performance Testing Types — where this section's strategy and metrics turn into an actual, executable test design.