During speed testing, the user response time latency of each user action is measured. The script for each action will look for some text on each resulting page to confirm that the intended result appears as designed. Since speed testing is usually the first performance test to be performed, issues from installation and configuration are identified during this step. Identified the business processes under test. Documented production installation configuration instructions and settings.
Quantified the start-up, shut-down, and user GUI transaction response latency times when the system is servicing only a single user at a time under no other load in order to determine whether they are acceptable. Ensured CPU, disk access, data transfer speeds, and database access optimizations are adequate. Contention conclusions This form of performance test aims to find performance bottlenecks such as lock-outs, memory leaks, and thrashing caused by a small number of Vusers contending for the same resources.
Each run identifies the minimum, average, median, and maximum times for each action. This is done to make sure that data and processing of multiple users are appropriately segregated. Such tests identify the largest burst spike of transactions and requests that the application can handle without failing.
Such loads are more like the arrival rate to web servers than constant loads. Identified performance bottlenecks such as lock-outs, memory leaks, and thrashing caused by a small number of Vusers contending for the same resources.
Ensured that data and processing of multiple users are appropriately segregated. Identified the largest burst spike of transactions and requests that the application can handle without failing. Volume Tests for Extendability This form of performance testing makes sure that the system can handle the maximum size of data values expected.
These test runs measure the pattern of response time as more data is added. These tests make sure there is enough disk space and provisions for handling that much data, such as backup and restore.
Quantified the degradation in response time and resource consumption at various levels of simultaneous users. This is done by gradually ramping-up the number of Vusers until the system "chokes" at a breakpoint when the number of connections flatten out, response time degrades or times out, and errors appear. Determined how well the number of users anticipated can be supported by the hardware budgeted for the application.
Quantified the "Job flow balance" achieved when application servers can complete transactions at the same rate new requests arrive. Ensured that there is enough transient memory space and memory management techniques.
Make sure that admission control techniques limiting incoming work perform as intended. This may include extent of response to Denial of Service DoA attacks. During tests, the resources used by each server are measured to make sure there is enough transient memory space and adequate memory management techniques.
This effort makes sure that admission control techniques limiting incoming work perform as intended. This includes detection of and response to Denial of Service DoA attacks. Fail-Over conclusions This form of performance testing determines how well how quickly the application recovers from overload conditions. For example, this form of performance testing ensures that when one computer of a cluster fails or is taken offline, other machines in the cluster are able to quickly and reliably take over the work being performed by the downed machine.
This means this form of performance testing requires multiple identical servers to be configured and using Virtual IP addresses accessed through a load balancer device. Determined whether the application can recover after overload failure. Measured the time the application needs to recover after overload failure.