This glossary defines key terms for Performance Testing Service (PTS).
|
Term |
Description |
|
3xx |
Indicates that the client must take further action to complete the request. These status codes are typically used for redirection. The redirect URL is specified in the |
|
4xx |
Indicates a client error that prevents the server from processing the request. |
|
5xx |
Indicates a server-side error that prevents the fulfillment of a valid request. This may be due to an internal error or insufficient resources. |
|
Business Session |
An ordered collection of performance testing APIs that represents a business process. Within a session, you can pass data between APIs by correlating input and output parameters. Sessions run independently and do not share data unless you use a data export command. |
|
Pre-business Session |
A session that runs before all regular sessions to perform setup tasks. It behaves like a regular session but is always executed first, similar to a A pre-testing session is typically used for data preparation, such as exporting login cookies. |
|
Post-business Session |
A session that runs after all regular sessions are complete. It is used to perform cleanup actions and is similar to a Important
A post-testing session runs only when you manually stop a test. It does not run if the test completes its configured duration. |
|
API for Testing |
A single request that simulates a user action. Performance testing APIs are the building blocks of a performance testing scenario and define the URL for each step in a session. For example, on an e-commerce website, actions like logging in, viewing product details, and submitting an order each correspond to one or more API requests. |
|
VU |
An abbreviation for virtual user. The number of VUs defines the concurrent load in a test. For example, 100 VUs means 100 independent threads send requests concurrently. |
|
VUM |
A unit of measurement for testing resources, calculated as VUs multiplied by the test duration in minutes (VUM = VU × min). |
|
VUs |
Simulates a single user sending requests to your application. During a test, each virtual user runs as an independent process or thread to generate load. |
|
Concurrency |
The number of virtual users running at the same time. |
|
Concurrent Mode |
A load generation pattern where you define a fixed number of virtual users. This mode helps you determine the maximum number of concurrent users your system can handle. |
|
Performance testing scenario |
A sequence of HTTP or HTTPS APIs that models a real-world user workflow. You can associate APIs with data files to simulate different user inputs. By combining APIs that represent various business actions, such as logging in or adding items to a cart, you can create a realistic load model. |
|
Output parameter |
A value extracted from an API response. You can use an output parameter as an input for subsequent APIs in the same session. |
|
Checkpoint (assertion) |
Verifies whether an API response meets expected criteria. A 200 OK status code does not always guarantee a successful business operation. You might need to inspect the response body. If an assertion fails, subsequent APIs in that session are not executed. Checkpoint results are recorded in performance test reports. |
|
Rendezvous Point |
Pauses virtual users at a specific point until a condition is met. Once the condition is met, all waiting users are released simultaneously. This is useful for simulating scenarios with a sudden burst of traffic, such as a flash sale. |
|
Conditional Jump |
Alters a session's execution flow based on the value of an output parameter. Supported actions include jumping to another API, continuing to the next step, or ending the session. |
|
RPS Mode |
A load generation pattern, also known as throughput mode, that maintains a fixed rate of requests per second (RPS). |
|
Think Time |
A pause between two consecutive API calls that simulates the time a real user spends thinking or interacting with a page. Multiple modes are supported. |
|
Data Export |
A command that exports data from a session (such as cookies, output parameters, or parameters defined by a data command) for use in other sessions. Exported data is shared globally. |
|
Parameter Command |
A command that processes data within a session. It transforms values from a previous API, such as output parameters or function results, into new parameters for subsequent APIs. |
|
File Parameter |
A parameter whose values are sourced from an external file. You can organize related parameters into columns in a file, upload it to PTS, and then reference these parameters in your performance testing APIs. |
|
TPS |
Abbreviation for transactions per second, the number of transactions a system processes per second. |
|
Response time (RT) |
The total time elapsed from when a client sends a request to when it receives the complete response from the server. It is the sum of request sending time, network latency, and server processing time. |
|
75th percentile response time |
The value below which 75% of the response times for a specific session or API fall. For example, if the 75th percentile response time is 120 ms, 75% of requests completed in 120 ms or less. |
|
Command |
A PTS component that controls the behavior and flow within a session. Commands help you create more realistic simulations of business traffic. |
|
Request success rate |
The percentage of an API's requests that were successful during a test. |
|
Timing Waterfall |
A visualization that breaks down the request lifecycle into timed phases, helping to identify which phase contributes most to the overall response time. |
For more information, see Test metrics.