ISTQB CT-PT ISTQB Certified Tester - Performance Testing Exam Practice Test

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.

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.

Stress testingis designed to evaluate how a system behavesunder extreme conditions, often exceeding its design limitations. The goal is to identify bottlenecks, memory leaks, and failures that occurbeyond normal operating conditions.

Option A is incorrectbecause it refers toresilience testing, which focuses on recovery rather than stress beyond limits.

Option B is incorrectas it describesload testing, which measures performance under expected loads.

Option C is incorrectsincedetermining the maximum transactionsis a feature ofcapacity testing, not stress testing.

To ensure anaccurate operational profile, it is crucial tovalidate and adjust it with key stakeholders before executing tests. This step ensures that the workloadrealistically represents actual user behavior.

Option A (Executing the test first and adjusting later)is incorrect becauseadjustments should be made before executionto avoid misleading results.

Option C (Aggregating profiles into a single generic profile)removesimportant distinctions between different user types, reducing test accuracy.

Option D (Creating separate profiles and using equal proportions)does not match the actualpower purchaserbehavior, which requires arealistic representation of their higher-volume transactions.

Crowd-based load generationinvolves using distributed users (e.g., cloud-based testers or real users). The mainchallengeis thatthe load generation can be difficult to reproduce consistentlydue to variations innetwork conditions, device types, and user behavior.

Option B is incorrectbecause load generation methods should adapt to system changes.

Option C is incorrectsince mainframe applications typically do not rely on crowd-based testing.

Option D is incorrectbecause crowd-sourced load testing is generallyless precisethan scripted load testing.

One of thebest practices in performance test scriptingis tovalidate that correct data is recorded in the databaseafter execution. This ensures thatperformance issues do not impact data integrity.

Option A (Increasing the number of scripts)may providemore coverage but does not verify accuracy.

Option C (Adding transaction timers)is useful for performance monitoring but does not ensurecorrect data entry.

Option D (Holding the development team accountable)is amanagement responsibility, not a scripting best practice.

One of the biggest challenges of cloud-based performance testing is the lack of control over test execution timing due to shared cloud resources. Cloud environments dynamically allocate computing power, meaning that test execution may vary due to background processes, VM migrations, or auto-scaling events.

Option B (Inability to generate load) is incorrect because cloud platforms can scale upresources to generate high loads.

Option C (Lack of behavior simulation tools) is incorrect because cloud providers offer robust testing tools.

Option D (Test execution speed being too high) is not a valid performance testing challenge.

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.

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.

Before running the next set of performance tests, it is crucial tounderstand the differences (delta) between the previous test results and the expected improvements. This ensures that:

The changes made by developers are properly validated.

Performance objectives are aligned with measurable improvements.

Option B (Adjust stakeholder expectations)is incorrect, as performance testing should focus on real data rather than adjusting expectations.

Option C and D (Realign objectives for milestones or time-to-market goals)are incorrect becausetest objectives should focus on technical accuracy rather than schedule constraints.

During performance testing, it is crucial to definefailure handling proceduresto ensure thatfailures do not introduce additional errorsinto the test execution process. This helpsmaintain test accuracyandavoid misleading results.

Option A (Meeting stakeholder expectations)is important but not the primary reason for defining failure handling.

Option C (Capturing all defects)is ageneral testing principle, not specific to failure handling in performance tests.

Option D (Minimizing distractions)is not a valid reason for defining failure handling.

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.