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

Mobile and browser-based applicationsoften rely on APIsfordata retrieval and processing.Unexpected API loadcan causelatency issues, bottlenecks, and system crashes.

Option A (Hard disk speed)is not a major issue incloud-based or mobile systems.

Option B (Misconfigured host machine)affectson-premise systems, not mobile/browser-based applications.

Option D (Internet connectivity issues)is auser-side issue, not a system performance risk.

When system resources areoversaturated(e.g., CPU, RAM, or network bandwidth),responsetimes will degradebecause the systemstruggles to process requests efficiently. This is akey performance bottleneck indicator.

Option A is incorrectbecause response times do not improve under heavy load; they typically worsen.

Option C is incorrectbecauseerror logging may actually increaserather than decrease under stress.

Option D is incorrectbecause database size is independent of system saturation unless records are actively purged.

One of thebiggest contributors to unreliable performance projectionsisdifferences between the test and production environments. If test environments do not matchCPU, memory, network configurations, and database setupsin production, the results may not berepresentative of real-world performance.

Option A (Redundancy between test and production environments)isnot a problem; it's actually beneficial for reliability.

Option B (Disagreement between stakeholders)can affect planning but does not cause unreliable projections.

Option D (Unrealistic stakeholder goals)affects expectations butnot the accuracy of projections.

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.

Aramp-up periodin a performance testgradually increases loadover time, and aramp-down perioddoes the opposite. This preventssudden surges in system load, making test resultsmore realistic.

Option A (Ensuring transactions complete in a time window)is incorrect because ramp-up/down periods do not control transaction timing.

Option C (Providing a buffer for slow transactions)is incorrect because ramp-up/down is about load balancing, not transaction timing.

Option D (Keeping all virtual users active throughout the test)is incorrect because ramp-down periods reduce users gradually.

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.

When system resources (e.g.,CPU, RAM, I/O) are oversaturated, the system becomes overloaded, leading toincreased response timesandpoor application performance.

Option A (Gradual improvement of response time)is incorrect becauseperformance degrades under heavy load.

Option C (Error logging decreases)is unlikely; in most cases, errorsincreasewhen systems reach their limits.

Option D (Database size decreases)is unrelated to performance saturation.

REST (Representational State Transfer)is a widely usedweb service protocolthat enablesclient-server communicationover HTTP. It is commonly used inmodern APIs and web applicationsfor performance testing.

Option A (SOAK)refers tosoak testing, which evaluates performance over an extended period.

Option C (HTTP)is atransport protocol, butRESTis the actual web service architecture built on HTTP.

Option D (RTE)isnot a web service protocolbut may refer toReal-Time Enterprise systems.

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.