ISTQB CT-PT flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Performance testing definition

A dynamic non-functional test type that measures speed, scalability, and stability of a system under a defined workload, verifying performance characteristics rather than functional correctness.

Load testing

Testing that exercises the system at expected or peak production load levels to verify that response time and throughput requirements are met under realistic conditions.

Stress testing

Testing beyond normal or peak capacity to find the system's breaking point and observe how it fails and recovers, revealing limits and degradation behavior.

Soak testing

Endurance testing that applies a sustained, typically normal load over a long period to expose memory leaks, resource exhaustion, and gradual degradation.

Spike testing

Testing that applies a sudden, sharp increase in load and then a decrease, to observe whether the system handles abrupt demand changes without failure.

Scalability testing

Testing that determines whether the system can handle growth in users, data, or transactions, and whether adding resources produces proportional performance improvement.

Baseline testing

Capturing a reference set of measurements on a stable build in a known environment, used later to detect performance regressions by comparison.

Performance defect

A deviation where response time, throughput, or resource utilization fails to meet a stated requirement; root causes are often outside the application under test.

Think time

The modeled pause between a simulated user's consecutive requests; reducing it raises generated load, so it must be defined and recorded with the workload profile.

Response time definition

Elapsed time from sending a request to receiving the last byte of response, including client processing, network latency, server queuing, and server processing.

Percentile response time

The response time below which a given percentage of requests fall, such as the 95th percentile; it exposes tail latency that an average would hide.

Throughput

The number of completed transactions or requests processed per unit time, a core capacity metric typically measured in transactions per second or per minute.

Little's Law

A queuing relationship stating that concurrent users equals throughput multiplied by average response time; used to check consistency between measured metrics.

Resource utilization

The fraction of a resource's capacity currently in use, such as CPU or memory; response time rises sharply as utilization approaches full capacity.

Headroom

The spare capacity kept below maximum utilization, commonly keeping CPU around 70 to 80 percent, to absorb bursts without queuing delays.

Load generator bottleneck

A condition where the tool generating load exhausts its own CPU, memory, or network, so measured response times reflect the tool rather than the system under test.

Client-side vs server-side timing

Client-side timers include network and client overhead while server-side timers exclude them; both differ and must be distinguished when reporting response time.

Warm versus cold cache

Cache state changes measured performance; a cold-cache run measures different behavior than a warm-cache run, so cache state must be defined and reported.

Workload model

A definition of user types, transaction mix percentages, arrival pattern, think times, and test data that represents realistic production usage for the test.

Correlation

The scripting task of capturing a server-generated dynamic value from one response and reusing it in later requests, such as session IDs or tokens.

Parameterization

Replacing hard-coded input values in a script with data drawn from a data file or generator, so each virtual user submits realistic and distinct data.

Open versus closed model

In an open model requests arrive at a fixed rate regardless of response time; in a closed model each user waits for a response before the next request.

Smoke test of script

A short single-user or low-load execution of a performance script to verify it runs correctly and produces valid responses before the full load test.

Ramp-up

Gradually increasing the number of active virtual users from zero to the target load, avoiding artificial spikes and allowing observation of behavior at each level.

Bottleneck identification

Analysis that locates the limiting component, such as database locks, thread pools, or network, by correlating resource metrics with response time changes over time.

Performance regression testing

Re-running an established workload after changes and comparing results against a baseline to detect degradation, requiring stable scripts and comparable environments.

Shift-left performance testing

Running component-level or API-level performance tests early in the pipeline to catch regressions cheaply, complementing periodic full-scale load tests.

Protocol-level load tool

A headless tool that simulates many virtual users at the protocol layer with low resource cost, but does not measure real browser rendering time.

Browser-based load tool

A tool that drives real browsers to measure rendering and client-side time, but scales to far fewer virtual users due to high resource consumption.

Virtual user

A simulated user executed by the load tool as a thread or process, replaying scripted requests with defined think times and data to generate load.

Tool licensing models

Load tools are licensed per virtual user, per protocol, or by subscription; cost scales with maximum concurrency, so license planning belongs to test planning.

Performance test lead role

The role owning strategy, workload modeling, and coordination across development, operations, DBAs, and business stakeholders, and accountable for result sign-off.