Free ISTQB CT-PT Practice Exam with Questions & Answers

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.

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.

Resource allocation happens during the test planning phase, wherehardware, tools, and personnelare assigned to the project. This ensures that performance tests areadequately supported.

Option B (Test execution)is when resources are actually used, not allocated.

Option C (Test evaluation)happensafter executionto analyze results.

Option D (Test completion)focuses on documentation and reporting.

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.

Aload generatoris responsible forsimulating virtual usersand applyingworkloads to a systemas defined by an operational profile. This allows testers to analyze how the system behaves under different load conditions.

Option A (Background load)is incorrect becauseload generators create simulated user interactions, not just background noise.

Option C (Record and analyze behavior)is the role ofmonitoring tools, not a load generator.

Option D (Support root cause analysis)is incorrect becauseroot cause analysis is done after the load test, using monitoring tools.

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.

ODBC (Open Database Connectivity)is astandard database protocolthat enables applications toconnect to and interact with databasesregardless of vendor specifications.

Option B (JUNIT)is aunit testing framework, not a database protocol.

Option C (SMP - Symmetric Multiprocessing)relates toCPU architecture, not databases.

Option D (MMS - Multimedia Messaging Service)is related tomobile messaging, not database communication.

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.

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.

Aggregating test resultshelps stakeholders understand performance trendsbycombining data points from multiple test runs. This makes iteasier to draw conclusionsabout system behavior.

Option A is incorrectbecause aggregation may reduce detailed visibility, not increase it.

Option B is incorrectbecause aggregation does notexpedite testing itself.

Option D is incorrectbecause aggregated results do not indicatetest completion.