Stress Testing Process

Stress Testing Process

	Stress testing is seen as part of the process of performance testing which tries to identify the breaking point in a system under test by overwhelming its resources or by taking resources away from it. This helps to ensure that the system fails and recovers gracefully. Stress Testing is done to uncover memory leaks, bandwidth limits, transactional problems, resource locking, hardware limitations and synchronization problems that occur when an application is loaded beyond the limits determined by the performance statistics. Stress testing tools generate extremely high load on the Web server by simulating multiple client connections.
Stress testing process is very simple and straightforward which is done in three easy steps: Record Your Stress Test Scripts Add dynamic data to the test and set load level Run stress test and analyze stress test results
Stress Testing Features
The key features that help you perform stress testing are: Stress Test Recording Stress test recording is made simple and easy with a point and click user action. You can record stress test scripts to capture any HTTP/HTTPS/SSL/AJAX requests. Flexible User Scenarios and Dynamic Data Generation To emulate the real-user activities, stress testing provides the flexibility to split the number of users accessing different parts of the web application performing different operations. You can also capture user diversity to simulate a variety of virtual users characteristics such as different connection speeds, different browser types, IP Spoofing and different servers/ports. To capture real-life stress testing, you can generate dynamic data for the stress test. The values of session IDs or request parameters (Get/Post data) can be fetched from a number of ways (from dataset, hidden elements, previous response/url, cookies, etc). Real-world Load Simulation To stress test and identify the potential breaking points in your web application. Burn-in Mode Load Test: The burn-in mode helps you to verify the acceptability of your web sites/web applications when abnormal or extreme load conditions are encountered for an extended period of time, such as diminished resources or extremely high number of users. You can exit the stress test only based on some specified exit criteria. Exit criteria allows you to set multiple criteria based on which the stress test should exit or the system should break, if one of the criterion is not met during the stress test execution. This goal based test methodology enables stress testers to set thresholds and parameters during stress test configuration to identify the breaking points. If not attainable, either the system should break or the stress test should exit.  Exit Criteria Options Following are the options available to set the goal for the stress test: Exit on Server Crash: Select this option to exit the stress test, if the web-server crashes.   Exit if Test Duration exceeds specified time: Select this option to exit the stress test, if the test duration exceeds the specified time in milliseconds. Exit if Response Time is not less than specified millisecs for % of the time: Select this option to exit the stress test, if the response time is less than the specified milliseconds for the specified percentile of the time. For example, if the response time is given as 10 milliseconds for 95 % of the time. Then the response time is sorted in ascending order from the lowest to the highest. Assume there are 20 values, then find the 95th percentile value (95/100*20=19). If this value is less than 10 milliseconds then exit the stress test.   Exit if CPU% on Server exceeds specified %: Select this option to exit the stress test, if the CPU % of the specified server exceeds the specified CPU %. You can also configure new server monitors and check the CPU % of the same. Mixed Load Test: This helps you to identify the breaking point in your web application when a combination of workloads is added which emulates the real-world load behavior such as steady-state, ramp-up or ramp-down.  Distributed Stress Testing To simulate a very high load hitting your web site for stress testing, you have the option of simulating the users in a single machine with a high configuration or distribute the load across multiple machines using the distributed playback option. Single load test controller that centrally manages automatically generates and distributes the load across multiple play engines. Web-based Play Engine Configuration UI allows you to quickly and easily configure the distributed machine IPs and the maximum virtual users to be simulated in each machine (Windows or Linux machines). Stress Test Reports Provides a clear and comprehensive range of stress test reports and graphs which includes both summary and detailed reports. You can also refer to the white paper on Performance Testing Report Analysis. Some of the key stress test reports and graphs that helps you to quickly and easily analyze the potential bottlenecks in your web application are as follows. Request/Response Status Summary to know whether the stress test configuration is appropriate. Error Rate Graph, Error Distribution Graph, Response Validation Error Details helps you to analyze the stress test errors and adjust the stress tests in order to achieve meaningful and accurate results. Graph to identify performance bottlenecks provides a consolidated view which shows the server response time for individual URLs, error percentage and the number of active users over elapsed time. User Details Graph helps you to know the number of virtual users generated by the load generator. The Hits per Second graph shows the number of HTTP requests made by Virtual users to the Web server during each second of the run. Response time graphs help you to know whether the response time meets your target requirements. User capacity graph and Response Time vs User Load Graph helps you to know how many simultaneous virtual users your web server can handle. Server and Database graphs help you to know how your web application performance affects due to server and database parameters.