Performance Testing is like a sports duel of computer systems. As an endurance competition, it allows you to determine how well the system withstands heavy loads and maintains performance. At the same time, you can find out how the response time, throughput and other characteristics change with increasing load.
In other words, Performance Testing is a simulation of the workflows of your application or service, which is as close to reality as possible. In a reality where very rarely there are only a couple of users.
For success in the digital products market, it is not enough to create just a functionally correct product. It should be ready for the expected flow of requests from its users and a little more. But at the same time, it is unacceptable to use excessively powerful, and therefore expensive equipment.Using obviously excessive server capacity is costly.
Unavailability of your services due to high load is also very costly.
Proper performance testing is a balance between two extremes, saving you from unpleasant surprises.
Despite the fact that performance testing is not functional testing, there are a number of functioning problems that can be identified only when creating at least a weak load.
For different tasks, there are various modifications of performance testing. The right approach will allow you to get the desired result, instead of wasting time.
Some of these approaches are described below.
The process of checking the functioning of a service or its components at a given level of load created by simulating the parallel operation of many users.
The purpose of such testing is to make sure that the application can cope with the actual or planned load and at the same time maintain its operability and responsiveness.
Load testing with going beyond the planned load and/or with a lack of server resources (memory, processor, etc.).
Classic scenarios: the launch of a large-scale advertising company, a failure in part of the servers used or their incorrect configuration, as a result of which the number of system users may become too large for normal functioning.
The purpose of such testing is to make sure that the characteristics gradually degrade with increasing load and/or decrease in available resources.It is important that the service in the worst case correctly responds with something like: "The server is overloaded, come back later."
A specific type of stress load with such a combination of negative factors, when the server cannot respond at all due to the failure of one of the system components.
The purpose of such testing may be both the search for a "weak link" to improve it, and the search for the level of negative factors in which the user will not be able to get any response from your service.
It can be expensive to completely avoid such situations and it's up to you to decide how far you are willing to go to provide users with a good experience in any case.Regardless of the size of the load, the main requirement is to maintain the correctness of the service's data storage in case of failures, and to restore work correctly after reducing the number of requests.
An addition to Tip-over testing, during which it turns out that it is possible to correct the "bottleneck" in the form of a lack of resources only by increasing them.
The goal is to check effective scaling, when, if necessary, the characteristics of the service can be improved by adding resources.
This is Load testing for a long period of time. The load value during such testing is higher than typical, but in the range of expected values.
The purpose of this type of tests is to find problems that are weakly or not at all manifested during short tests within the expected load values. Some examples of such problems:
Testing at low or medium load with short–term rapid increases - "Spikes". Usually, this is a check of the effectiveness and correct configuration of the mechanism for launching additional virtual servers, if necessary.
The goals in this case are to check the possibility of rapid adaptation of the service to increase and decrease the load and reliable restoration of operability after possible failures.
This is load testing with simultaneous functional testing of the user interface.
The goal is to test the functionality and responsiveness of the UI at different load levels.
Such testing can be implemented either with the help of a specialized tool, or by adding additional functional checks in the load test scenario.
Adds an additional load factor to load testing: a large amount of user data.
This data can be transferred not too quickly, with a small number of virtual users. Part of the problem arises not from the performance of the system, but from its inability to store and efficiently process large amounts of data.
Such an addition helps to find out whether your system will be able to correctly process the planned amounts of data. In combination with stress testing, it is additionally possible to find out the maximum amount of stored and processed data.