CT-PT ISTQB Certified Tester - Performance Testing Questions and Answers

Load testingassesses a system’s ability to handlegradually increasing levels of loadand ensures that it meets performance expectationsunder normal and peak conditions.

Option B (Elevation testing)is incorrect because this term does not exist in ISTQB performance testing terminology.

Option C (Spike testing)focuses onsuddenincreases in load rather thangradualscaling.

Option D (Endurance testing)examines how a system performsover an extended period, rather thangradual load increases.

Aload management consoleis a tool that helps testersanalyze and visualize test results, providingperformance reports, graphs, and insights. This aids in understandingbottlenecks, response times, and throughput trends.

Option A (Simulating user behavior)is incorrect;load generatorshandle simulation.

Option B (Senior management monitoring)is not the primary role of atest console.

Option D (Emulating virtual users)is incorrect; that is the job ofload injectors.

Performance testsprimarily identifyresource bottleneckssuch asCPU saturation, memory leaks, network congestion, and database slowdowns.

Option B (Suitability issues)is afunctional requirement concern, not a performance issue.

Option C (Learnability concerns)relates tousability testing, not performance.

Option D (Accessibility requirements)falls undercompliance and usability testing, not performance testing.

Acloud-based environmentis themost cost-effectivesolution for performance testing. It offersscalability, pay-per-use models, and flexibility, allowing testers to simulate large workloadswithout expensive infrastructure investments.

Option A (Isolated lab environment)is costly due tohardware maintenance and infrastructure costs.

Option C (Mainframe environment)isexpensive and impracticalfor performance testing.

Option D (No environment)is not a viable option.

Akey risk in distributed systemsisunreliable remote servers, which can lead tolatency, timeouts, and failuresin performance testing.

Option A (Hard disk de-fragmentation)is not a significant risk in distributed systems.

Option B (Excess memory)is apositive factor, not a risk.

Option D (Bluetooth connectivity)is unrelated todistributed system performance.

Wait timeis the period a transaction spendswaiting for resources, database responses, or external servicesbefore completing. It is critical for understandingreal-world transaction durations.

Option A (Think time)refers touser delays, not system delays.

Option C (Action time)focuses onexecution time only.

Option D (User time)is not a standard performance metric.

Iftimeouts and excessive wait times occur, butthroughput is high, this suggests thatthe system is unable to process requests fast enough. This points toslow processing speeddue toCPU bottlenecks, memory limitations, or inefficient database queries.

Option A (Network infrastructure investigation)would be relevant if throughput wasloworvariable.

Option C (Impatient virtual users)is irrelevant; virtual users followscripted behaviors.

Option D (New test data)does not address the core issue.

Spike testingis a type of performance testing that evaluates how a systemresponds to sudden, extreme increases or decreases in load. It is designed to simulateunexpected surges in user activity or workload, such as flash sales, viral events, or cyberattacks.

Option A (Gradual load increase testing)describesload testing, not spike testing.

Option B (Handling expected peak load)describesstress testing, which pushes the system to or beyond its limits but does not focus on sudden changes.

Option C (Meeting future efficiency requirements)relates tocapacity planningrather than spike testing.

Spike testing helps toidentify system bottlenecks, resource allocation issues, and performance degradationwhen traffic surges unexpectedly.

Forsafety-critical software, performance goalsmust be identified as early as the requirements phase. This ensures thatperformance constraints are well understood and accounted for throughout development.

Option A (After test readiness but before system testing)istoo late, as requirements should be definedbefore coding begins.

Option C (During the concept stage)istoo early, as details may not be concrete.

Option D (During software design)is useful butshould be preceded by a proper definition during the requirements phase.