Glossary¶

Terms are defined as they apply to Load Tester and web performance testing. Where a term has a broader industry meaning, the definition here reflects how we use it in this product specifically.

A¶

Analytics Dashboard: Interactive real-time performance analysis interface introduced in Load Tester v7.0. Provides drill-down charts, AI-powered insights, and metric correlation across six tabs (Summary, Metrics, Pages, Servers, Errors, User Levels). Replaces static HTML reports as the primary analysis tool. See Embedded Analytics Dashboard.
Application State Management (ASM): Rules-based expert system with AI-powered dynamic detection that automatically finds and configures dynamic fields in test cases. ASM detects session cookies, CSRF tokens, OAuth bearer tokens, hidden form fields, and other values that change between sessions, turning a raw recording into a working, replayable test. See ASM Overview.

B¶

Bandwidth: Network throughput measured in Mbps (megabits per second) during a load test. Should increase proportionally with virtual users until a network bottleneck is reached.
Bottleneck: The system resource that reaches its limit first, constraining overall application performance. Common bottlenecks include CPU, memory, database connections, disk I/O, and network bandwidth. The bottleneck determines the system's maximum capacity. See Identifying Bottlenecks.
Boundary Extractor: A type of custom extractor that captures dynamic values from responses by matching text boundaries (a start marker and an end marker) around the target value. Simpler than regex extractors but limited to cases where the surrounding text is consistent. See Extractors & Boundary Extraction.

C¶

CAN (Connection Authentication Negotiation): The use of HTTP headers by browsers and servers to negotiate the authentication protocol for transmitting credentials. The most common protocol is NTLM.
CAN Duration: The total duration of all CAN transactions required to complete a single user transaction. Reported as N/A when no authentication negotiation was required.
CAN Transactions: Additional HTTP round-trips required to negotiate the authentication protocol before the actual request can be sent. Typically 0, 1, or 2 per user transaction depending on the protocol and connection state.
Concurrency: Multiple users accessing an application simultaneously. One user hitting a site 1,000 times sequentially does not test concurrency (it tests throughput for a single session). Load testing creates real concurrency by running many virtual users in parallel, each maintaining independent sessions.
Correlation: The process of linking where a dynamic value appears in a server response (extraction) to where it's used in a subsequent request (assignment). ASM performs correlation automatically for most dynamic fields. Manual correlation is needed when ASM doesn't recognize the pattern. See Basic ASM / Dynamic Fields.

D¶

Dataset: A table of test data (like a spreadsheet) with columns (fields) and rows of values. Each virtual user draws from a different row, providing unique credentials, search terms, or form data per user. Essential for realistic multi-user testing. See Datasets & Data-Driven Testing.
Dynamic Field: Any value in an HTTP request that must change between sessions or requests to maintain a valid conversation with the server. Session cookies, CSRF tokens, hidden form fields, and transaction IDs are all dynamic fields. If a dynamic field isn't properly correlated, replays fail.
Dynamic Field Names: Field names (not just values) that change across recordings or replays. Common in Salesforce, ASP.NET, and other frameworks that auto-generate form field identifiers. ASM detects and handles these automatically. See Dynamic Named Fields.

E¶

Error Rate: The percentage or count of failed transactions during a load test. Includes HTTP errors (4xx, 5xx), connection failures, timeouts, and validation failures. A healthy load test typically shows an error rate below 1%.
Extractor: A mechanism that captures dynamic values from server responses for use in subsequent requests. ASM creates extractors automatically during correlation. Custom extractors (boundary or regex) can be added manually when ASM doesn't detect a pattern. See Extractors & Boundary Extraction.

F¶

Field Modifier: A configuration on a test case field that controls how the field is populated during replay. Can reference a dataset column, use a value from an extractor, apply a text constant, or generate a random/unique value.

G¶

Goal: See Performance Goal under P.

H¶

Hits/sec: Server throughput measured as completed HTTP requests per second. Should increase with virtual users until the server reaches capacity. When hits/sec plateaus while virtual users keep climbing, the server is at its limit.

I¶

Iteration: One complete execution of a test case by a virtual user. During a load test, each virtual user runs multiple iterations in a loop, with a configurable repeat delay between iterations.

L¶

Load Engine: The component that generates load by running virtual users, executing test cases, and collecting metrics. Can run locally or on remote machines (including cloud-provisioned EC2 instances). Multiple engines can work together to generate higher load levels. See Cloud Load Testing.
Load Profile: The definition of how many virtual users are active at each point during a load test. Typically follows three phases: ramp-up (gradual increase to target), steady state (hold at target), and ramp-down (gradual decrease). Can also use stepped levels for capacity analysis. See Configuring a Load Test.
Load Test: A simulation of multiple users accessing a web application simultaneously. Measures response times, throughput, error rates, and server resource utilization under realistic traffic conditions to identify capacity limits and bottlenecks.

N¶

NTLM: A Microsoft authentication protocol used by IIS and other Windows-based web servers. Requires multiple HTTP round-trips (CAN transactions) to complete authentication. See Basic/Form Authentication.

P¶

Page: A logical grouping of transactions in a test case, representing one user action (clicking a link, submitting a form). A page contains one or more transactions: typically one primary request plus secondary requests for images, CSS, JavaScript, and other resources.
Page Duration: The total time to complete all transactions for a page, from initiating the first connection to receiving the last response. Does not include the think time that follows the page.
Percentile: A statistical measure showing the value below which a given percentage of observations fall. The 95th percentile response time means 95% of users experienced that response time or better; 5% experienced worse. Percentiles reveal the tail of the distribution that averages hide. See Understanding Metrics.
Performance Goal: A threshold that defines acceptable performance for a page or transaction (for example, "homepage must load in under 2 seconds at the 95th percentile"). Goals are configured before running a load test and evaluated automatically in results. See Performance Analysis Workflow.

R¶

Ramp-Down: The final phase of a load profile where virtual users gradually decrease from the target level back to zero. Allows graceful session shutdown.
Ramp-Up: The first phase of a load profile where virtual users gradually increase from zero to the target level. Prevents shocking the system with instant peak load and lets you observe how performance changes at each user level.
Recording: The process of capturing HTTP traffic from a browser session to create a test case. Load Tester v7.0 uses a Chrome extension to capture all requests and responses as you interact with the application. See Your First Recording.
Regex Extractor: A custom extractor that uses regular expressions to capture dynamic values from server responses. More flexible than boundary extractors but requires knowledge of regex syntax. See Extractors & Boundary Extraction.
Repeat Delay: The pause between the time a virtual user finishes one iteration of a test case and starts the next. Prevents unrealistic "instant restart" behavior.
Replay: Execution of a recorded test case with a single virtual user to verify it works correctly before scaling to a load test. The essential validation step: if a replay fails, the load test will fail too. See Running a Replay.
Repository: A .wpt file that stores test cases, datasets, load configurations, and load test results. The fundamental project container in Load Tester. See Repository Management.
Response Time: Time from sending an HTTP request to receiving the complete response. Includes network latency, server processing, and data transfer. The primary measure of user experience under load.

S¶

Sample: A set of metric data collected during a specific time interval within a load test.
Sample Period: The length of each measurement interval during a load test. Shorter sample periods provide finer-grained data but increase result size.
Scatter Plot: A visualization that plots individual response times for every transaction in a load test, revealing the full distribution of performance. Essential for spotting patterns that averages hide. A 2-second average sounds acceptable until the scatter plot shows a bimodal split: half the responses at 1 second, the other half at 10. See Identifying Bottlenecks.
Session: A continuous interaction between one virtual user and the application, spanning multiple pages and transactions. Maintained through cookies, tokens, and other session identifiers that ASM correlates automatically.
SNI (Server Name Indication): A TLS extension that allows the browser to send the target hostname during the SSL handshake. Enables virtual hosting of multiple HTTPS sites on a single IP address. Load Tester supports SNI automatically.
Steady State: The main phase of a load profile where the virtual user count is held constant. Allows measurement of sustained performance, detection of memory leaks, and identification of resource exhaustion that only appears over time.

T¶

Test Case: A series of HTTP transactions between a client and one or more servers, organized as a sequence of pages. Usually created by recording a browser session. The test case captures the complete user workflow: requests, responses, headers, cookies, and timing. See Configuring Test Cases.
Test Case Elapsed Time: The total time to execute all pages in a test case including think time between pages. Usually much larger than the sum of page durations because of the think time.
Think Time: The simulated delay between pages, representing the time a real user spends reading content, entering data, or deciding what to click next. Realistic think time is critical for accurate load tests because it controls the rate at which each virtual user generates requests. Without it, virtual users behave like bots hammering the server as fast as possible. That's a stress test, not a simulation of real users. See Load Test Concepts.
Throughput: The rate at which the server processes requests, measured as hits/sec (requests per second) or bandwidth (Mbps). When throughput plateaus under increasing load, the server has reached its capacity limit.
TLS (Transport Layer Security): The protocol that secures traffic between client and server, used for all HTTPS communication. Load Tester handles TLS transparently during both recording and replay.
Transaction: A single HTTP request/response pair between a client and a server. The fundamental unit of a test case. A page typically contains multiple transactions (one for the HTML document, additional ones for images, CSS, JavaScript, and API calls).

U¶

User Variable: A named variable that stores a value extracted from a server response (such as a session ID or bearer token) for use in subsequent requests. Created automatically by ASM during correlation, or manually when configuring custom extractors.

V¶

Validation: A check that verifies a server response contains expected content. Used to catch application errors that return HTTP 200 but contain error messages in the body. Without validation, a load test can report zero errors while the application is silently failing on every request. See Debugging Failed Replays.
Virtual User (VU): A simulated user that executes a test case exactly as a real user would: sending HTTP requests, parsing responses, extracting dynamic values, following redirects, handling cookies, waiting for think time, and looping through iterations. From the server's perspective, a virtual user is indistinguishable from a real user. The number of concurrent virtual users determines the load level. See Load Test Concepts.