STRESS TESTING

The application is tested against heavy load such as complex numerical values, large number of inputs, large number of queries etc. which checks for the stress/load the applications can withstand. Stress testing deals with the quality of the application in the environment.   The idea is to create an environment more demanding of the application than the application would experience under normal work loads. 

This is the hardest and most complex category of testing to accomplish and it requires a joint effort from all teams. A test environment is established with many testing stations. At each station, a script is exercising the system. These scripts are usually based on the regression suite. More and more stations are added, all simultaneous hammering on the system, until the system breaks. The system is repaired and the stress test is repeated until a level of stress is reached that is higher than expected to be present at a customer site.

Race conditions and memory leaks are often found under stress testing. A race condition is a conflict between at least two tests. Each test works correctly when done in isolation. When the two tests are run in parallel, one or both of the tests fail. This is usually due to an incorrectly managed lock. A memory leak happens when a test leaves allocated memory behind and does not correctly return the memory to the memory allocation scheme. The test seems to run correctly, but after being exercised several times, available memory is reduced until the system fails.

Reasons for stress testing include:

    * The software being tested is "mission critical", that is, failure of the software (such as a crash) would have disastrous consequences.
    * The amount of time and resources dedicated to testing is usually not sufficient, with traditional testing methods, to test all of the situations in which the software will be used when it is released.
    * Even with sufficient time and resources for writing tests, it may not be possible to determine beforehand all of the different ways in which the software will be used. This is particularly true for operating systems and middleware, which will eventually be used by software that doesn't even exist at the time of the testing.
  

    * Customers may use the software on computers that have significantly fewer computational resources (such as memory or disk space) than the computers used for testing.
    * Concurrency is particularly difficult to test with traditional testing methods. Stress testing may be necessary to find race conditions and deadlocks.
    * Software such as web servers that will be accessible over the Internet may be subject to denial of service attacks.
    * Under normal conditions, certain types of bugs, such as memory leaks, can be fairly benign and difficult to detect over the short periods of time in which testing is performed. However, these bugs can still be potentially serious. In a sense, stress testing for a relatively short period of time can be seen as simulating normal operation for a longer period of time.

■	Load Testing
■	Stress Testing
■	Domain Testing
■	Exploratory Testing
■	Recovery Testing
■	User Acceptance Testing
■	Alpha Testing
■	Beta Testing
■	Unit Testing
■	Static & Dynamic Analysis Testing
■	Functional Testing
■	Ad-hoc Testing
■	Volume Testing

Stress Testing