ISTQB CT-PT key terms

A testing type that measures and evaluates system behaviour such as response time, throughput and resource use under defined load conditions, to determine whether performance requirements are met and where bottlenecks exist.

Testing that exercises a system at expected or anticipated usage levels, including peaks, to confirm it meets requirements and to observe behaviour as load increases toward defined limits.

Testing conducted beyond normal or anticipated load, or with constrained resources, to find the point at which the system fails and to observe how it degrades and recovers.

Testing that determines how well a system sustains increasing load when capacity such as servers, threads or memory is added, revealing whether performance grows proportionally or levels off.

Long-duration testing at a sustained, moderate load, used to expose problems that appear only over time such as memory leaks, connection exhaustion, log growth and gradual degradation.

Testing where load is increased sharply and briefly, then removed, to evaluate how the system handles sudden surges and whether it recovers to normal behaviour afterwards.

A measurable statement describing expected performance, for example a maximum response time for a given transaction at a stated load, expressed precisely enough to be verified by testing.

A formal agreement between a provider and a customer that states measurable service targets, such as availability and response times, which performance testing results are often compared against.

A component or resource whose limited capacity constrains overall system performance, so that relieving other parts yields little improvement until this constraint is addressed.

A representation of the expected user population and their actions, including transaction mix, arrival pattern, think time and data volumes, used to drive realistic performance test execution.

The planned pattern of load over the duration of a performance test, specifying how many users or transactions are applied and how that level changes across phases.

The elapsed time between a request being submitted and the corresponding response being received, often decomposed into network, queueing, application and data-access portions.

The rate at which a system completes work, typically expressed as transactions, requests or data volume per unit of time, measured under a stated load and workload mix.

A named, logically meaningful unit of user work whose start and end are timed during a performance test, such as a login or a checkout, forming the basis for reported metrics.

A value below which a given proportion of measurements fall, such as the 90th percentile response time, used to describe the distribution of timings rather than only the average.

The sum of a set of measurements divided by their count; useful for some resource metrics but misleading for response times, because a few very slow transactions can inflate it.

A measure of how widely individual measurements spread around their mean; a large value for response times indicates inconsistent user experience even when the average looks acceptable.

The proportion of a resource's capacity in use during a test, such as processor, memory, disk or network; sustained very high utilization suggests a likely constraint on performance.

A defect where allocated memory is never released, so consumption grows steadily over time and eventually degrades performance or causes failure; typically revealed by long-duration testing.

Automatic reclamation of unused memory by a runtime environment; its pauses can cause periodic response-time spikes that are hard to see in averages but visible in percentile data.

The simulated pause between a virtual user's consecutive actions, representing real user deliberation, which affects the load actually placed on the system under test.

A simulated user generated by a performance testing tool that executes a scripted sequence of interactions, each instance contributing to the applied load.

A recorded or coded sequence of interactions and validations that a virtual user executes, including data parameterisation and timing logic needed for realistic load generation.

The practice of capturing dynamic values returned by the system, such as session identifiers or tokens, and substituting them into later requests so scripted interactions remain valid.

Supplying varied input data to virtual users from a data source so that each iteration uses different values, avoiding unrealistic caching effects and data collisions during load tests.

The phase in which applied load is gradually increased from a lower level to the target level, allowing observation of how performance changes as demand grows.

The test phase during which load is held constant at the target level long enough for measurements to stabilise, so that collected metrics are representative and comparable.

The phase in which load is gradually reduced after the steady state, used to observe recovery behaviour and to end the test without abrupt disruption to the system.

Control over how frequently a virtual user starts new iterations, independent of response time, so that the generated transaction rate matches the intended workload model.

A machine or process that runs virtual users and produces requests against the system under test; its own capacity must be monitored so it does not distort results.

Software that records or scripts user interactions, generates load, and collects and reports metrics; selection considers protocol support, scripting effort, licensing cost and reporting depth.

Software that observes infrastructure and application behaviour during a test, collecting metrics such as processor load, memory, disk activity and request traces to support analysis.

Detailed analysis of where execution time or resource consumption occurs inside application code or a runtime, used to locate the precise cause of an observed bottleneck.

The hardware, software, network and data configuration in which performance tests run; it should resemble production closely enough for results to be credible and transferable.

A test environment dimensioned and configured comparably to production, including network characteristics and data volume, so that measured performance is representative of live behaviour.

The data set used by performance tests, whose volume and distribution should reflect production; unrealistic data sizes can hide or create performance problems.

A relationship stating that the average number of items in a system equals their arrival rate multiplied by average time spent, useful for checking load, throughput and response-time consistency.

A recorded set of performance measurements from a known configuration, used as a reference for comparing later test runs and detecting regressions after changes.

A deterioration in performance relative to a previous baseline or release, identified by comparing metrics from equivalent tests run under the same conditions.