Glossary

The response time value (Time to First Byte) that covers 90%, 95%, 98% or 99% of simulated requests respectively.

To calculate the value, LoadComplete –

1. Sorts the response time values measured for all requests in your test.

2. Excludes 10% (or 5%, or 2%, or 1%) of the highest response time values.

3. Finds the highest value among the remaining values. It is the needed response time value.

This is the response time value below which 90% (95%, 98% or 99%) of response time values of requests are.

You can view these values on the Summary page of the test report.

The completion time value that covers 90%, 95%, 98% or 99% of completion time values of a simulated user-defined transaction.

This is the completion time value below which 90% (95%, 98% or 99%) of completion time values of the appropriate transaction are.

LoadComplete calculates the value using the same algorithm as for the response time.

You can view these values only in the Report test log exported to a PDF file or in the printed Report test log. These values are not available in LoadComplete directly.

These metrics are available only if you have user-defined transactions in your test.

Access to the target web server’s content that does not require specifying any credentials (account name and password). If the anonymous connection is used, LoadComplete can test the target server without any restrictions.

Access to the target web server that requires authentication information in order to provide access to its content. LoadComplete supports Basic authentication, Digest authentication, NTML authentication, Kerberos authentication and Negotiate authentication. For more information on supported authentication types, see Supported Authentication Types.

A simple authentication method that passes user credentials to the target web server as Base64 encoded clear text. When performing Basic authentication, LoadComplete uses the credentials specified in the recorded scenario or in the Authentication table.

A batch is a collection of load tests that you can run with a single command at a scheduled time without user interaction. To create batches and run them, you use the BatchRuns project item. See also About Batch Runs.

See Validation Rule.

A scenario that consists of one or several other scenarios, and each of them can be executed several times.

Starting from LoadComplete 4.0, complex scenarios have been replaced with ordinary scenarios that use the Call Scenario and Loop operations for running other scenarios.

A scenario that uses parameterized computer-independent data instead of recorded data. For example, if the target web server resides on the same computer as that where the traffic is recorded, the name of the target server is specified in traffic as localhost. Such a scenario can be played back successfully only on the computer where it was recorded. To make the recorded scenario computer-independent, the target server name should be modified to use the computer’s network name rather than the localhost name.

See Concurrent Requests.

Requests that are sent to the server in several parallel connections created by the browser (during recording) or by LoadComplete (during playback). This approach allows simulating several requests simultaneously, which speeds up the test execution and makes traffic simulation closer to real life. For more information, see Configuring Parallel Requests.

Virtual users that simulate recorded HTTP traffic simultaneously. Once a load test has several virtual users, they are simulated concurrently.

The time it takes the client side to establish connection to the target web server. The connect time can also include the SSL time value. The more time it takes the connection to be initialized, the busier the network is.

A link between the client side (workstation) and the target web server established to exchange data. LoadComplete stores information on the connection established during the traffic recording, and that information includes the URL address of the web server to which the connection has been established, the number of the used port and the SSL attribute that specifies whether the connection is secured. The information on the connection can be explored and changed in the Scenario Editor.

The speed virtual users obtain data from the target web server during the traffic simulation.

LoadComplete allows you to set the connection speed for each scenario that will be executed during the load testing. The speed value is set in the Load Test Editor. You can manually specify the speed in kilobits per second or select a value from the drop-down list (you can choose from the dial-up connection speed up to the DSL connection speed).

The connection speed can be used to simulate the bandwidth of the download stream.

The period passed after the previous web page has been loaded completely and before LoadComplete opens a connection to download the next web page’s resources.

Connection think time affects the page load time both during the scenario verification and the test run.

You can view and edit the connection think time in the Think Time edit box of the selected connection or on the Timeline page of the Page operation to which the connection belongs.

Data set by the web server to maintain client-specific information and stored on the client side. Cookies can contain authentication information, session identifiers or web form data.

Cookies can be persistent or session. Session cookies exist in memory during a web browser session, while persistent cookies have an expiration date and are stored on the client side until the date expires.

Since web servers use cookies to provide responses to client requests, the cookies may affect load test results. It is recommended to clear cookies before recording traffic. You can do this either via the Record User Scenario dialog invoked when the traffic recording starts, or manually by deleting the browser’s cookies and temporary files.

During the traffic simulation, LoadComplete can use either the recorded cookies stored during the traffic recording, or the real-time cookies changed during the test run.

For more information on cookies in load testing, see Managing Cookies.

The same as Data Correlation.

LoadComplete automatically captures individual web pages when you are recording scenarios. In addition, it lets you define custom pages for specific requests in scenarios. For example, you can define custom pages for RIA requests that correspond to specific user actions but do not have an associated web page. For more information, see Recording Custom Pages.

The way of modifying the simulated traffic that means that the test tool extracts dynamic parameter values from received server responses and inserts them into subsequent requests. Using this approach makes responses and requests properly correlated during the test run.

This is needed if your application’s client requests depend on some session-specific parameters (like session ID) received from the server as a response to an earlier request. Without correlation, you will not be able to play back the recorded traffic properly as the parameters change from one session to another, so the parameters that were recorded will be invalid during the playback.

The way LoadComplete extracts data from responses and inserts them into request depends on the request type and protocol used by the application under test. For complete information, see About Data Correlation.

A pattern that matches a fragment of the response contents and is used to extract the fragment from the response.

Data selectors are created in the Data Selectors tabbed page of the Scenario Editor. Data extracted from the responses can be used to parameterize the subsequent requests sent to the target server.

For more information, see About Data Selectors.

An authentication method that transmits user credentials via the network as an MD5 hash. The original user name and password cannot be deciphered from the hash. For more information on supported authentication types, see Supported Authentication Types.

The time it takes the DNS server to resolve the DNS name of the tested web server to its IP address. The DNS lookup can increase the time required to send a request to the tested web server, especially from remote locations.

The time it takes to load the initial HTML document (including frames). Since browsers have to download the document first in order to download all the embedded objects, the time of initial HTML document downloading is a critical measure.

To learn about request duration, see Request Duration.

To learn about operation duration, see Operation Duration.

To learn about test duration, see Test Duration.

Parameters generated by the server for the current application run. Dynamic parameters can include session IDs, query strings, form data in post requests, cookies, hidden fields, and so on. The dynamic parameters change every time the tested web application is run, so playing back a load test with the recorded parameters may fail. LoadComplete provides several ways to handle dynamic parameters. For information on these ways, see About Data Correlation.

LoadComplete reports an error if it fails to simulate a request or has not obtained a response from the test server. See Resolving Errors and Warnings.

A type of authentication when a website provides a web form to collect data from a user in a browser.

LoadComplete saves the request containing the credentials during the traffic recording and uses it during the playback to authenticate the user.

For details on supported authentication types, see Supported Authentication Types

A hypertext transfer protocol designed to transfer hypertext documents between computers over the Web.

A secure hypertext transfer protocol designed to transfer encrypted information between computers over the Web.

A sequence of requests sent to the target web server and responses returned by the server to these requests. In LoadComplete, you can record HTTP traffic into scenarios, which, in their turn, are used as part of tests.

To view or modify the recorded traffic, you can use the Scenario Editor.

The time passed between the start of the test run and the moment when the first workstation became ready to work. This time can include the time needed for initializing cloud machines, connecting to Remote Agent and so on.

Authentication that uses the Key Distribution Center (KDC) service to provide both the client and the server with session keys. The session keys are used to encrypt and decrypt data transferred between the client and the server. When reproducing the recorded traffic to web servers that support the Kerberos authentication, LoadComplete corrects the traffic in order to perform the Kerberos authentication. For authentication, LoadComplete uses the credentials specified in the properties of the LoadComplete project item. For more information on supported authentication types, see Supported Authentication Types.

See Network Latency and Response Latency.

A feature specifying whether the workload on the target server grows dynamically during the test run. You can specify whether to use the load profile during the current load test in the Load Test Editor and specify how the amount of virtual users is changed during the testing.

A type of testing aimed at simulating real-life workload conditions for the tested web server and checking its behavior under massive load. Load testing allows determining:

• How many users can work with the web server simultaneously without perceptible slowdown.

• How the server response time changes if the number of the users increases.

For more information on load testing in LoadComplete, see Load Testing With LoadComplete.

The upper bound of allowed time spent on downloading a complete web page during the test run. If the Page Load Time exceeds the threshold value, an error occurs.

You can specify the threshold value:

• In the Scenario editor, for each page of a scenario.

• On the SLA page of a load test, for all pages in all test scenarios.

During the test run, you can view the actual and threshold values on the Runtime > Graphs page. To do that, enable monitoring for the needed page in the Pages section of the counter list. You can also monitor the number of threshold value violations occurring during the test run.

To learn how to set the correct threshold, see Setting Reasonable Goals for Service Level Agreement.

The upper bound of allowed time spent on receiving a web server response during the test run. If the Time to First Byte exceeds the threshold value, an error occurs.

You can specify the threshold value:

• In the Scenario editor, for each request of a scenario.

• On the SLA page of a load test, for all requests of all test scenarios.

To learn how to set the correct threshold, see Setting Reasonable Goals for Service Level Agreement.

The time it takes the request sent by the client to reach the target web server.

Data sent by the client passes a number of routers during the transmission until it reaches the target web server. While running a load test, you can also use the Windows Tracert command-line utility to measure individual hops the sent packets take. You should run the tracert utility for each workstation used for virtual users’ simulation to measure the network latency.

Authentication that uses NTML, Kerberos or Digest authentication depending on the operating system the client and server computers have. It is also called Integrated Windows Authentication.

A secure form of authentication. User credentials are hashed before they are sent through the network. This type of authentication uses information about the current Windows user account registered on the client computer. When performing the NTML authentication, LoadComplete uses the credentials specified in the Authentication table.

A framework that allows a web application to access protected web resources on the server on behalf of the resources' owner. To represent a permission granted to the web application by the resource owner, it uses access tokens.

LoadComplete stores the credentials the web application provides during traffic recording and uses them to get the appropriate access tokens during the test run.

For more information on how LoadComplete supports various authentication protocols, see Supported Authentication Types.

For an operation (except for the HTTP Request operation), the duration is the time it takes to simulate the operation completely. If the operation has child operations, the duration also includes the time it takes to simulate them.)

A group of requests in a recorded scenario.

During the scenario recording, LoadComplete groups requests automatically. It creates a separate page for each –

• An HTML document that a tested server returns as a response to requests. Such pages include a request, to which the web server returned the document, and requests to all the document’s resources, for example, images, CSS, scripts, fonts, and so on.

• A POST request.

For Rich Internet Applications (RIAs), LoadComplete creates a single page. This happens because such applications exchange data with the server without changing the current page (without changing the URL). You can organize requests into pages in RIA scenarios manually (see Custom Pages).

LoadComplete collects several testing metrics for pages. See Page Load Time, Page Resources, Page Think Time.

The time it takes to download a complete page including all images, scripts, CSS files, and so on.

You can see this metric in the Report panel of test results. You can also monitor it during the test run on the Runtime > Graphs page. It shows the load time of individual pages in your test and the average load time of all pages.

The page load time does not include the page think time. However, it includes the think time of all requests, connections, and statement operations that belong to that page.

External files (images, scripts, and others) that are loaded into the web page when you open or view this page in the browser.

The amount of page resources (like scripts, images and others) with their size specified.

The size of a page with all of its resources (like scripts, images, CSS and other files) downloaded. This metric indicates whether some heavy weight pages were downloaded during the testing.

If page load time exceeds the specified maximum page load time, LoadComplete reports an SLA violation. The Page SLA Violations metric indicates the number of times the page load time has exceeded the threshold since the previous measurement. The metric is available on the Runtime > Graphs page during the test run.

The period passed after the last request of a page has been completed and before LoadComplete sends the first request of the next page.

LoadComplete detects page think time automatically during the recording and saves it to the recorded scenario.

LoadComplete records the page think time as a pause at the beginning of the recorded page. You can view it in the Think Time edit box of the Scenario editor when you select the page in the Scenario Explorer.

LoadComplete uses the page think time during the test run to simulate delays that happen because the user is viewing or working with the page. You can configure your load tests to use the recorded page think time or random think time or to ignore the think time. See Setting Page Think Time Behavior and Changing Think Time for Pages and Requests.

The page think time does not include the page load time.

The number of successful requests passed to the test server since the previous measurement. You can view this metric on the Runtime > Graphs page.

A type of testing aimed at determining the web application operational boundaries. It includes other types of testing:

• Stress testing

• Load testing

• Scalability testing

You can perform all these types of testing with LoadComplete. For more information on how to perform testing, see Typical Use Cases.

A part of a request’s URL containing dynamic parameters. You can view the URLs of the recorded requests on the Request Header panel.

The query string in a URL follows the question mark and contains name-value pairs, for example: http://my_url.com/showpage?page_id=sample_page&session_id=4s35f8b15.

To learn how to handle dynamic parameters in recorded traffic, see Editing Recorded Requests.

Cookies stored on a workstation and set or changed during the test run.

LoadComplete can use cookies that are stored on the workstation during the load testing. When using real-time cookies, the simulation of the same scenario by different virtual users on different workstations may produce different results.

You can specify whether to use the real-time cookies during the testing in the Simulating - General dialog. For more information on working with cookies during the load testing, see Managing Cookies.

Cookies stored during the traffic recording and used for traffic simulation. If you use recorded cookies during the load testing, the target server produces the same responses it was producing during the recording.

You can specify whether to use the recorded cookies during the load testing in the Simulating - General dialog. To learn how to work with cookies, see Managing Cookies.

See Workstation.

A synchronization point for virtual users that run a scenario. When one of the virtual users simulating the scenario containing the rendezvous point reaches one, the load testing pauses until all other virtual users that run the same scenario reach that point.

You can add rendezvous points in the Scenario editor. See Adding, Removing and Arranging Operations in Scenarios.

For more information on synchronizing virtual users, see Synchronizing Virtual Users.

A message sent to the target web server from the client.

For example, after a user has entered the credentials into appropriate fields on a web page, the server sends this data as a request to the security server that checks the validity of the specified account.

Requests sent to the server are recorded when you record the scenario. You can view the list of recorded requests in the Scenario Editor.

The Request page displays detailed information on each recorded HTTP request.

The WebSocket Message page shows the contents of each recorded WebSocket client message.

Additional information stored in a request’s header fields. Request details include information on the request itself and on the client that sent the request. You can view request details on the Request Header panel.

The request details can include hundreds of bytes, so to reduce the amount of disk space required for testing, in the Simulating - General dialog, you can specify whether to store only the request initial line.

For an HTTP request, the duration is the time it takes the server to process the request. It is estimated as the time to first byte.

The first line of a request message sent to the server. The request initial line contains the name of the method to be applied to the resources specified by the URL and the used protocol version.

You can view the initial line of the recorded requests in the Request Header panel.

The values that a request sent to the target server contains. Request parameters may contain search values, form data or the name of a requested file. Parameters of GET requests are passed in the URL of the request page (or file). They are separated from the address with a question mark. Parameters of POST requests can be passed either in the URL or in the request body.

LoadComplete supports working with parameters of both request types. You can view and edit them in the Scenario editor.

If time to first byte of a request exceeds the specified maximum time to first byte, LoadComplete reports an SLA violation. The Request SLA Violations metric indicates the number of times the response time has exceeded the threshold since the previous measurement. The metric is available on the Runtime > Graphs page during the test run.

The amount of data (in kilobytes) transferred to the server per second. It is estimated as a ratio of the overall amount of data sent to the server during a period of time to the duration of that period.

This metric depends on the number of simulated virtual users: the more users are sending data to the server, the larger the request throughput is.

You can view this metric on the Runtime > Graphs page during the test run.

The period passed after LoadComplete receives a response to a request and before it sends the next request to the server. To emulate browser behavior, LoadComplete can simulate requests in multiple concurrent connections. LoadComplete uses the request think time for requests it sends through the same connection.

Request think times are stored within user scenarios and affect the page load time both during the test run and the scenario verification.

The request think time is not so important for simulating real-life user behavior in comparison with the page think time. However, you may need to change it for simulating the appropriate browser behavior.

You can view and change the request think time in the Think Time edit box of the Operation Editor page or on the Timeline page of the Page or Connection operation to which the request belongs. See also Changing Think Time for Pages and Requests.

The speed at which a request is transferred to the server (in megabytes per second). It is estimated as a ratio of the request size to the time it takes to send the request. For example, if a request containing 1 Mb of data is sent to the server and it takes 0.5 seconds to transfer the request, the request transfer speed is 2 MB/sec.

For several requests, the transfer speed is estimated as an average of the transfer speed values of all the requests.

You can view the metric on the Runtime > Graphs page during the test run. You can also view this metric in the Request Transfer Speed section of the Report panel.

A message sent by the server to the client in response to the request sent by the client before.

LoadComplete records responses sent by the target server during the traffic recording. You can view the response contents on the Response page of appropriate requests.

The code that was returned by the tested web server in response to the sent request. For more information on response codes, see Typical Response Codes.

The sum of the following values: the time it takes a request to reach the tested web server, the time it takes the server to process the request, and the time it takes the response to reach the client. In LoadComplete, it is estimated as the Time to First Byte metric: the time between the first byte of the leaving request and the first byte of the arriving response. You can view the Time to First Byte metric on the Runtime > Graphs page during load testing.

The amount of data (in kilobytes) transferred from the server per second. It is estimated as a ratio of the overall amount of data sent from the server during a period of time to the duration of that period.

This metric depends on the number of simulated virtual users: the more users are sending requests to and receiving responses from the server, the larger the response throughput is.

You can view this metric on the Runtime > Graphs page during the test run.

The time spent by the server to process the request of the given connection.

The speed at which a response is transferred from the server (in megabytes per second). It is estimated as a ratio of the response size to the time it takes to receive the response. For several responses, the transfer speed is estimated as an average of the transfer speed values of all the responses.

You can view the metric on the Runtime > Graphs page during the test run. You can also view this metric in the Response Transfer Speed section of the Report panel.

The time between the first byte and the last byte of a response arriving. You can view the metrics on the Runtime > Graphs page during the test run.

A type of testing that is aimed at determining whether the tested application scales with the workload's growth. Scalability testing allows determining:

• How the software and hardware changes affect the server performance.

• Whether it is possible to improve the application's productivity by upgrading the server hardware.

For information on common test steps for scalability testing, see Scalability Testing: Checking Whether a Site Performance Can Scale Up.

A container for recorded HTTP traffic. Scenarios are created by LoadComplete when you record actions performed against the tested web application or server.

Recorded scenarios are stored in LoadComplete projects and can be examined and modified via the Scenario Editor.

Scenarios can call other scenarios. This feature makes it easier to organize and maintain scenarios that correspond to large user sessions. See Calling Scenarios From Other Scenarios.

The time it takes to execute a scenario completely, that is, the time interval between the first byte of the first request of the scenario and the last byte of the response to the scenario’s last request.

If your load test includes a scenario that consists of several subscenarios, LoadComplete will calculate this metric both for the entire scenario and for each individual subscenario.

You can view this metric:

• In the Scenario Completion Time table on the Summary > General Information page of the Report test log.

• On the Response Time > Scenario Completion Time page of the Report test log.

• On the Runtime > Graphs page during the test run. Note: This metric shows only the average completion time of all executed scenarios. It does not show the completion time of individual scenarios.

See Target Server.

The time passed between the last byte of the user request and the first byte of the server response.

For web servers and web applications, a service level agreement is an agreement between the web server or web application provider and end users that sets the expected level of server or application performance.

With LoadComplete, you can check whether your tested web application or server meets the expected level of service. You can set SLA criteria, and then check whether your tested web application or server violates them during the test run.

The SLA criteria you can set include:

• For pages, max page load time. You can set it both on the scenario level, for individual pages in scenarios, and on the test level, for all the pages in all your test scenarios.

• For HTTP requests, max time to first byte. You can set it both on the scenario level, for individual requests in scenarios, and on the test level, for all the requests in all your test scenarios.

• For WebSocket messages, duration, that is, the time spent on sending or receiving a message. You can set it both on the scenario level, for individual messages, and on the test level, for all the messages in all your test scenarios, as the Max Time to First Byte setting of the test.

• For other operations, max duration. You can set it only on the scenario level.

If the actual page load time, time to first byte, or duration measured during the test run exceeds the expected criteria, LoadComplete will report an error. You can view the number of violated criteria during the test run on the Runtime > Graphs page.

To learn how to set correct criteria, see Setting Reasonable Goals for Service Level Agreement.

See Service level agreement.

A user scenario that is called from another scenario. See Calling Scenarios From Other Scenarios.

From the technical point of view, subscenarios are ordinary scenarios. The term is used just to indicate they are called from another scenario.

A test that LoadComplete creates automatically when recording a user scenario. Single-user tests are typically used to verify that scenarios work correctly. You can also use them to create load tests on the basis of the recorded scenarios.

An XML-based protocol for exchanging structured and type information over the Web. See Support for SOAP Protocol (XML).

An attribute of an HTTP connection that specifies whether the connection is established via the HTTPS protocol.

LoadComplete stores information on the connections established during the traffic recording. You can change the SSL attribute of the needed connection in the Scenario editor. For more information on testing HTTPS connections, see Support for HTTPS Applications.

See Workstation.

The time it takes the client to establish a secure connection to the tested web server, perform data encryption and authentication.

The value (in milliseconds) that indicates the deviation of the response time values from the average response time value. The greater the value, the more dispersed the response time values.

You can view this value on the Summary page of the test report.

The value that indicates the deviation of the completion time values of a user-defined transaction from the transaction’s average completion time. The greater the value, the more dispersed the completion time values.

You can view these values only in the Report test log exported to a PDF file or in the printed Report test log. These values are not available in LoadComplete directly.

These metrics are available only if you have user-defined transactions in your test.

A type of testing aimed at verifying the target server’s behavior under extremely heavy load and at determining the load that causes the tested application to crash. Stress testing allows determining:

• What load can crash the application.

• What tested application parameters need to be monitored.

• How to fail over the tested web application.

See Stress Testing: Finding the Server's Crash Point for common stress testing use cases.

A web server (for example, www.google.com) that will be used for traffic recording. That is, LoadComplete records a request sent by the client to that server and responses obtained from that server.

During the traffic recording, LoadComplete records the name of the target server. To learn how to change the recorded server name if the target server has been moved, see Changing the Tested Server.

The overall test execution time. It includes not only the time it takes to simulate all test scenarios, but also the time spent on starting and stopping the test.

You can view the test duration on the Report > Summary > General Information page of the test log.

If you use continuous load, you can set the duration for your test on its Continuous Load page.

The period between two subsequent operations in a scenario.

See Page Think Time, Connection Think Time and Request Think Time.

An arbitrary sequence of operations that correspond to a task a user performs when working with the tested web server. For instance, you can combine operations that simulate adding a new order on the New Order web page into the “Add a New Order” business transaction. For more information on defining transactions for LoadComplete scenarios, see About User-Defined Transactions.

The time interval between the user-defined transaction’s start marker and its end marker (or the current moment of the running test). The transaction duration includes the duration of its requests, operations and their think times. You can view this metric in the Transaction Completion Time section of the Response Time tabbed page after the test run is over.

If your load test contains multiple transactions, LoadComplete will calculate the total completion time of all transactions, as well as the completion time of each individual transaction.

The duration of each individual transaction will be displayed in the Details panel of the test log.

The time passed between the first byte of the user request and the first byte of the server response.

You can view this metric on the Runtime > Graphs page during the test run.

The time passed between the first byte of the user request and the last byte of the server response.

You can view this metric on the Runtime > Graphs page during the test run.

The total number of requests sent to the test server during the load test run. You can view this metric in the General Information section on the Summary page of the Report panel.

An application (a web browser) running on the workstation and used to simulate the current request.

The web browser data used to send a request is stored in the request’s User-agent header field. You can view and change it on the Request Header panel.

Changing that field value, you can emulate different browsers during the load testing. For more information on this, see Specifying User Browser.

A condition that LoadComplete uses to compare the contents of a server response against some expected value. These conditions work during the test run and scenario verification. They let you specify additional criteria for verifying whether a request was simulated successfully or not. See About Validating Response Contents.

You specify validation rules in the Scenario editor, on the Validation tab of the server response.

An “unreal” user that corresponds to a collection of recorded requests and responses sent to and received from the tested web server. LoadComplete uses virtual users to simulate traffic. A virtual user simulates requests, and the server “thinks” that it is working with an actual user.

You can specify the number of virtual users that will simulate the recorded traffic during the load testing in the Load Test Editor.

The number of virtual users that are being currently simulated. You can view this metric on the Runtime > Graphs page during the test run.

LoadComplete reports a warning if the real-time response code obtained for the current request is other than the recorded response code. See Resolving Errors and Warnings.

Unacceptable performance of the tested web application. It can be an error, access violation, warning or slowdown of the request processing.

Commonly, it is the stress testing that is aimed at determining the load that causes the tested application on the target server to crash.

See Page.