The primary objective of stress testing is to check the stability of the product work with boundary loads. Stress testing involves tests that load much higher than the operating load volume on the product. We usually use special tools, since it's usually impossible to manually create an overload. For example, testing web applications with the help of the robot to generate a significant flow of requests.
You can use stress testing for:
finding out the bottlenecks of the applications (heavily used sections of code that need optimization);
management errors (for example, lack of proper limits on memory usage, thread, system descriptors);
system synchronization errors (for example, the lack of synchronization, and as a consequence we get incorrect operations or destruction of data);
load balancing errors (e.g. wrong configuration balancer).
How does a stress test work for web application
In general, the methodology of stress testing is based on the removal and analysis of application performance under load, significantly exceeding expectations on the maintenance stage, and it carries the aim to determine the endurance and stability of the application in the case of a burst of activity on its use.
Why stress testing is important:
Most of all the systems are designed with the assumption of functioning normally, and even when the opportunity to increase the load is ok, the actual volume of its increase is not taken into account.
In the case of SLA-contract (agreement on service level), the cost of system failure under extreme conditions can be very high.
Detection of errors or defects in the functioning of the system is not always possible with other types of testing.
Testing conducted by the developer may not be enough to emulate the conditions where there might be a system failure.
It is preferable to be prepared to handle the extreme situation of the system and what to expect after its crash.
The main directions of stress testing use:
the general study of the behavior of the system at peak loads;
error handling and exceptions study system at peak loads;
the study bottlenecks of the system or individual components with disproportionate workloads;
testing of the system capacity;
stress testing, as well as load testing, can also be used to regularly assess changes in performance to obtain for further analysis of the dynamics of change in the system behavior over an extended period.
Hard Work: Stress Test Example
Capacity Testing is one of the most important regarding business development and stress testing, and it's the most complex regarding the conduction and analysis. Capacity testing is conducted to determine the margin of the system at full strength according to performance requirements. In the simulation, capacity load testing is accounted as the current load in the form of both the number and proportion of requests received by the system, as well as expected receive in the future.
For example, a web service is designed to display data for authorized users in the .docx format. The company is going to provide the ability to display data in a .pdf format, and the company expects that current users will continue to work with the old format, and will use the new .pdf format. By simulating the load on the system during the capacity testing, we take into account not only the current scenario of its use (displaying data in .docx), and the alleged use of the script in the future (of the concurrent user system using .docx, and some - .pdf).
The result of the capacity testing of application or the system is a set of maximum allowable load characteristics of the system under which the application or system meets the performance requirements, developed and documented during the design phase of the architecture.
Common web stress test mistakes
We have seen reports on stress testing where the number of errors exceeds the number of successful operations with a simultaneous load of 5 users. These results should alert you immediately. No, wait, you do not have to get such results!
The way out:
always think about whether your system is configured correctly before you carry out any type of load testing. Perform functional testing after installation and applying the application settings before you proceed with the stress test, and do not start the system to check the workload, if your the basic functionality does not work.
Many testers that are involved in stress testing forget to watch the system during load tests. Often you can see reports about the stress testing where there is only information about the simulated load, the response time of the system and the number of successfully / not successfully completed operations. And there is no information about the memory consumption, the load on the network interfaces and hard drives, the burden on the processor and what wastes time in the operations.
The way out:
watch out for the loaded system during the process, keep the load information for all the main components of the system. Such as the amount of memory consumption, CPU utilization, load on the network interfaces, the number of operations with the hard disk, as well as information on resources that are unique to your application. For example the number of records in the database, the number of messages in the message queue, etc. to know what resources are being consumed. Include this information into reports on stress testing.
Different types of testing
In fact, the load (although it is not quite a right word) testing comprises the following types of tests as load, performance and stress testing. With some projects, it is actually divided into different test types and each conducted separately from the provision of individual reports. Many projects are limited to carrying out only one type of test while it is not carried out correctly enough because they do not ask themselves the question on what kind of testing they perform.
The way out:
The information from tests is used in business. If we provide inaccurately and improperly treated and structured information, the project bears the losses, that are often more expensive than the quality of stress testing and analysis of the results.