ISTQB CT-PT study plan

Define performance testing and distinguish it from load, stress, spike, soak, and scalability testing using your own one-sentence definitions

Identify at least six performance risk factors (e.g., high user concurrency, large data volumes, slow third-party interfaces) and map each to a test type that would expose it

Explain the performance testing lifecycle from planning through analysis and retest, naming the entry and exit criteria at each stage

Contrast performance testing with functional testing in terms of test basis, oracle, and pass/fail criteria

Derive performance acceptance criteria from non-functional requirements that are vague, then rewrite them into measurable targets

Draft a workload model for a worked scenario, specifying user profiles, think times, and arrival patterns

Sequence the main activities of a performance test project (planning, design, environment setup, execution, analysis, reporting) with the input and output of each

Justify why performance testing must start early and identify the cost of finding defects late

Define response time, throughput, utilization, and resource consumption, and state the unit and measurement point for each

Distinguish client-side, network, and server-side measurement points and explain how each shifts the reported number

Interpret a percentile distribution (median, 90th, 95th, 99th) and argue why averages mislead in performance reporting

Compute the relationship between concurrency, think time, and throughput using Little's Law on a worked example

Explain how the performance efficiency characteristics of a system (time behavior, resource utilization, capacity) map to metrics

Design a load profile that includes ramp-up, steady state, and ramp-down, and justify the duration of each phase

Select monitoring counters for at least four layers (application server, database, OS, network) and state what anomaly each counter reveals

Diagnose a described bottleneck scenario by correlating response time, CPU, memory, and I/O data

Explain how to establish a performance baseline and how to decide that a result is statistically trustworthy

Write a test design that specifies test types, load profiles, data requirements, and environment needs for a given system description

Plan test data and environment setup, including how to keep runs comparable across executions

Describe how to execute a performance test cycle: pre-checks, run monitoring, data capture, and post-run validation

Outline the contents of a performance test report, including how to present findings to technical and business stakeholders

Identify at least five common pitfalls in execution (e.g., unrealistic think time, unmonitored test environment, ignored warm-up) and a mitigation for each

Classify performance testing tools by function (load generation, monitoring, profiling, analysis) and name the selection criteria for each category

Explain the architecture of a load generation tool: controller, agents, virtual users, protocols, and scripting

Describe how to build and validate a script, including parameterization, correlation, and verification of recorded traffic

Explain the role of performance testing in a continuous integration pipeline and the trade-offs of early, small-scale performance checks

Define the roles and responsibilities in a performance testing team and the skills each role requires

Describe organizational factors that enable or block performance testing, such as environment availability, shared ownership, and budget cycles

Explain how performance testing fits into the wider test process and how results feed release decisions

Revisit the risk-to-test-type mapping from week 1 and correct any gaps found in your understanding

Answer a full-length set of practice questions under timed conditions and score each domain separately

Review every missed question and write the underlying concept in your own words with a concrete example

Rehearse the exam's key distinctions (test types, metrics, measurement points, tool roles) from memory without notes

Consolidate weak areas into a final revision sheet of no more than two pages