Last updated July 29, 2026
The ISTQB Certified Tester Performance Testing exam is 40 multiple-choice questions in 90 minutes, and you need 26 of them — 65% — to pass. Every question is worth exactly one point, including the analysis-level ones that ask you to read a metric graph or compute a throughput figure. Unlike several ISTQB specialist exams, this one publishes an official question count per chapter, and that split is the most useful preparation fact available: half the exam comes out of a single chapter.
40 questions, 40 points — flat scoring. Nine questions are at K4 (analyse) and four at K3 (apply); the other 27 are recall and understanding. A K4 percentile calculation earns you the same single point as a K1 question about ISO 25010 vocabulary, which is worth remembering when you decide where to spend time in the exam room.
26 correct answers to pass — 65%. You can afford 14 wrong answers. On a 40-question paper that is thinner than it sounds: one weak chapter plus one arithmetic slip is most of your margin.
90 minutes, plus 25% extra time — 113 minutes in total — if the exam language is not your native language. Arrange it when you book, not on the day. Note that some older tables and third-party sites still quote 60 minutes for CT-PT; that is a stale artefact, and both the certification page and the current exam-structure tables say 90.
CTFL is required; work experience is not. The syllabus states it plainly: the Foundation Level Core certificate shall be obtained before taking this exam. There is no minimum number of months in a performance-testing role, and no accredited course is mandatory.
The 2018 syllabus is still the current one. As of mid-2026 ISTQB has not released a successor — the recent specialist releases were elsewhere in the scheme. If a study resource claims to cover a newer CT-PT edition, check the footer date before you trust it.
ISTQB publishes a per-chapter question count for CT-PT, and it is independently confirmed by member boards, so you do not have to guess at weights here. The one thing worth internalising is the shape of that split: Performance Testing Tasks — planning and the performance test plan, operational and load profiles, protocols and scripting, execution, and analysing and reporting results — accounts for half the paper on its own. It also holds ten of the thirteen K3 and K4 questions. The other four chapters share the remaining half between them, which means none of them can be revised the way you would revise a CTFL chapter.
The prescribed teaching time agrees. Of roughly 875 minutes across the five chapters, 475 sit in chapter 4. Two independent official signals pointing the same direction is about as much certainty as ISTQB preparation ever gives you — plan your revision to match, not to feel balanced.
Blurring the eight performance test types. Load, stress, scalability, spike, endurance, concurrency, capacity and general performance testing each have a precise definition, and the exam trades on near-misses. Endurance is about degradation over time — memory leaks, disk fragmentation, a growing database. Spike is a sudden burst and recovery. Scalability is about locating the ceiling. Being approximately right here reliably costs points.
Reading throughput as "number of users". The syllabus is emphatic that load is defined by throughput, not by user count: 500 users issuing one request a minute is sixty times the load of 500 users issuing one request an hour. Expect a question built on System throughput = [number of virtual users] / ([processing time] + [think time]), and be ready to distinguish system throughput from network throughput, and closed systems from open ones.
Reporting averages, and reading results in the wrong order. Response time is judged on minimum, maximum and the 90th percentile, not the mean. And analysis has a prescribed order for a reason: check virtual user status first, because failed transactions finish faster than successful ones and therefore inflate transactions-per-second. Skip that step and every metric after it is misleading.
Confusing correlation with parameterisation. Missing or incorrect correlation is the syllabus's named principal reason recorded scripts fail to replay. Parameterisation is the separate problem of test data: give every virtual user identical data and caching flatters your results while record locking punishes them.
Losing track of who owns which acceptance criterion. Response time is the user's concern, throughput is the business's, resource utilisation is the system's. That mapping appears almost verbatim, and the distractors simply rotate it.
Treating architecture risks as one list. There are nine categories, from a single computer through multi-tier, distributed, virtualised, dynamic cloud, client-server, mobile and embedded real-time to mainframe, and each has its own failure profile. Mobile (battery, memory, temperature, sensors, location) and dynamic cloud (self-scaling behaviour and misconfiguration) are the two most often asked and least often studied.
Assuming raw numbers are self-explanatory. Performance testing usually has no clear test oracle. The syllabus makes the point with an example worth memorising: utilisation under 75% alongside a response time an order of magnitude worse than target. Also know the probe effect — your measurement must not perturb the system under test.
Week 1 — chapters 1 and 2. The ISO 25010 sub-characteristics (time behaviour, resource utilisation, capacity), the five principles, the eight test types, static versus dynamic performance testing, the four load-generation approaches, and the failure modes with their causes. Then the three metric categories — technical, business, operational environment — GQM for selecting them, the three sources of metrics, and the probe effect. These are cheap points; do not overrun.
Week 2 — chapter 3. Architecture risk categories, the four-step risk process, residual risk expressed quantitatively, and how performance testing sits in sequential, iterative and COTS or supplier-acquirer lifecycles. The analysis-level questions here give you an architecture and ask which risks apply, so study by architecture rather than memorising a flat list.
Weeks 3 and 4 — chapter 4. Half your revision time for half the exam. Performance test plan sections and acceptance criteria, test data masking and its cost in realism, protocols by OSI layer, operational profiles and load profiles with ramp-up and steps, script structure and synchronisation points, correlation, think-time tuning, steady versus transient state, and the report structure. Work with actual numbers: compute throughput, read a percentile table, interpret a load profile.
Half a day — chapter 5. Load generators and points of presence, the load management console, monitoring tools, the three licensing models, and the four suitability factors: compatibility, scalability, understandability, monitoring. That is the entire chapter and it is not worth more than an afternoon.
Take a full-length mock cold, under the 90-minute clock, before you finish revising. A 40-question paper has high variance, so you want to find the weak chapter while there is still time to fix it — a diagnostic taken the night before is just anxiety with a score attached.
Then read every rationale, including on the options you did not choose. That is where the distractor logic lives, and the same logic will be waiting on the real exam in different words. Treat 80% under time as ready, not 65%. Passing exactly at the pass mark leaves no room for a badly worded question or one slip in a percentile calculation.
Because the paper is short, look at the shape of your score and not only the total. Being weak in chapter 4 cannot be compensated by being strong everywhere else — there is not enough "everywhere else" to compensate with.
There are three full-length CT-PT mock exams here, and each one reproduces the official chapter split and the official cognitive-level mix exactly — nine K4 questions and four K3 questions per paper, not an approximation of them. Between them they carry throughput, think-time, percentile and network-bandwidth calculations, load-profile interpretation, and root-cause analysis from annotated metric graphs: connection-pool saturation, disk I/O saturation, garbage-collection pauses distinguished from a genuine memory leak, and an unbalanced cluster hidden behind aggregated results.
The three papers deliberately share no scenarios. Each one draws on its own domains — so working through all three exercises the same syllabus points against unfamiliar situations, which is closer to what the real exam does to you than re-sitting one paper until you remember the answers.
Every one of the five syllabus chapters now has enough questions behind it for a standalone chapter practice page, so you can drill a weak chapter directly instead of re-taking whole papers. Chapter 4 has by far the deepest pool, which matches where the exam actually puts its weight. The syllabus itself remains worth reading — ISTQB publishes it free, and no question bank substitutes for the source.
Nobody has real CT-PT exam questions. ISTQB does not release live content, and anyone selling "actual exam dumps" is selling you invented material or somebody else's guesswork, often written against assumptions the syllabus never made. Ours are written from the published syllabus, with a written rationale on every option — the wrong ones included, because that is where the learning is. ISTQB does publish an official sample exam alongside the syllabus, and it is worth doing; it is one paper, not a study programme.
Our mocks copy the real format exactly — 40 questions, one point each, 90 minutes, 65% to pass — so a percentage here means what it looks like it means. What no mock can tell you is whether the specific phrasing of the live exam will suit you.
All CT-PT mock exams and chapter practice are listed on the CT-PT certification page, and you can go straight to mock exam 1 with questions and answers. No sign-up, and every rationale is visible.