Chapter 4 is where performance testing stops being vocabulary and becomes work. It runs the whole task sequence: planning and the sections of a performance test plan, analysis and design of operational and load profiles, choosing protocols and building scripts, executing against a steady state, then analysing results and reporting them to audiences with very different interests. It is also where the syllabus concentrates its analysis-level learning objectives, so the questions ask you to compute and to interpret far more often than to recall.
This is the chapter that rewards having actually run a load test. Candidates who have only read about it tend to know the terms — think time, correlation, ramp-up, percentile — without knowing which one explains the broken result in front of them. The distractors here are built on exactly that gap: every option is plausible performance-testing vocabulary, and only one of them accounts for the symptom described.
If preparation time is short, this is the chapter to spend it on — and to spend it working through numbers rather than re-reading definitions.
Where candidates lose these points:
Treating user count as the load variable. Load is defined by throughput: System throughput = [number of virtual users] / ([processing time] + [think time]). Five hundred users at one request a minute is sixty times the load of five hundred at one request an hour. System throughput and network throughput are also not the same measurement.
Skipping virtual user status when reading results. Failed transactions complete faster than successful ones, so they inflate transactions-per-second. Check user status first; every metric analysed before you have done that is misleading.
Reporting the mean. Transaction response time is judged on minimum, maximum and the 90th percentile. The syllabus also warns against demanding 100% compliance with a response-time target — a question will offer that as the responsible-sounding answer.
Confusing correlation with parameterisation. Incorrect or absent correlation is the named principal reason a recorded script will not replay. Parameterisation is the separate data problem: give every virtual user identical data and caching flatters the result while record locking punishes it.
Rotating the acceptance criteria. Response time belongs to the user, throughput to the business, resource utilisation to the system. The wrong options simply shuffle that mapping.
Assuming the test environment behaves like production. Performance is a non-linear function of the environment, so a scaled-down lab requires explicit extrapolation. Masked or anonymised production data is mandatory under GDPR but may no longer carry production's data characteristics.
Ignoring transient states. Steady state is the usual focus, but mass logins and spike tests live entirely in the transient phase, where averages hide the failure. Load generators themselves need monitoring too, and clocks across all tools must be synchronised or your correlation is fiction.
Guessing at protocol layers. The protocols that matter sit at OSI layers 5 to 7 — ODBC and JDBC for databases, HTTP and HTTPS for web, SOAP and REST for services. A protocol-level script measures server plus network; a GUI-level script measures end-to-end. Knowing which one a scenario needs is a recurring question.
This chapter is covered most heavily (20 questions) in CT-PT — Mock Exam 1 (Performance Testing Tasks, Load Profiles and Metrics), CT-PT — Mock Exam 2 (Resource Saturation & Bottleneck Diagnosis), CT-PT — Mock Exam 3 (Distributed Systems, Garbage Collection and Cluster Analysis)