Chapter 1 sets the vocabulary the rest of the exam is written in: performance efficiency as ISO 25010 defines it, the principles of performance testing, the eight types of performance test, the difference between static and dynamic performance testing, the four ways load can be generated, and the common failure modes together with their causes. Every question here is recall or understanding — you explain and distinguish, you never calculate.
That makes it the cheapest chapter to secure and the most expensive one to be sloppy in. The distinctions defined here come back as distractors later: if endurance and spike blur together now, they will blur again when a later question hands you a load profile and asks which test it represents.
Where candidates lose these points:
Separating the eight types by size of load instead of by intent. Endurance is about degradation over time — memory leaks, disk fragmentation, a growing database. Spike is a sudden burst and the recovery after it. Stress goes beyond expected capacity. Scalability looks for the ceiling. Concurrency is many users doing the same thing at the same instant. Capacity is the maximum sustainable value of a parameter.
Putting reliability inside performance efficiency. ISO 25010 places time behaviour, resource utilisation and capacity inside it; reliability is a separate top-level characteristic sitting alongside. This is the single most reliable K1 trap in the chapter.
Assuming performance testing is dynamic by definition. Static performance testing is in the syllabus: reviewing requirements, database schemas and ER diagrams, queries and stored procedures, network and system architecture, and performance-critical code. An option claiming otherwise is offering a misconception, not a definition.
Not knowing which load-generation approach fits which situation. There are four — through the user interface, through crowds, through the API, and through captured communication protocols. The last one is the answer when there is no API specification and driving hundreds of GUI instances is impractical.
Detaching failure modes from their causes. Slow under any load is a different finding from slow only under medium or high load (resource saturation), which is different again from degradation over time (leaks, fragmentation, database growth) and from ungraceful failure at the limit (undersized resource pools, small queues and stacks, time-outs set too aggressively). Questions describe the symptom and expect the right family.
Muddling stakeholder expectation with a measurement target. The principles include that results must be reproducible, comparable and understandable, and that testing must be feasible on a full or partial system within budget and timescales. Those are properties of the test, not thresholds for the system.
This chapter is covered most heavily (6 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)