What is Spike Test?
Spike Test refers to a performance test which simulates a sudden high load on the server for a shorter period of time. This is a type of non-functional test which helps to identify the behaviour of an application or software system when an unexpected huge load arrives. The outcome of the spike test concludes whether the application can able to handle a sudden load or not. And, if it is then how much load?
The average load is considered as a base load. In some special cases, the peak load replaces the average load and becomes the base load.
Type of Spike Test:
Spike tests are of three types:
1. Constant Spike Test: A high volume load applies to the server for a shorter duration after a fixed interval of time. In this type of spike test, all the spikes have the same height i.e. the same load.
2. Step-up Spike Test: A gradual increase in load applies to the server for a shorter duration after a certain interval of time. In this type of test, response time should measure at each spike and analyse how much it deviates from baseload response time.
3. Random Spike Test: A random spike load applies to the server at random intervals. Such a test is conducted for an application that frequently gets spikes in the production environment.
How to calculate Spike Load?
The business analyst analyses the historical data and checks if any of the sudden spikes appeared in the past. As per his analysis, he suggests the number of users for spike load. He may also predict the numbers by analysing the company’s requirements. For example, if a company has a plan to conduct a flash sale or one-minute sale then he needs to calculate the spike load as per the registered and active user count. Although there are multiple methods to calculate the spike load and a business analyst must be aware of that. This is not a task of a performance tester. A performance tester has a responsibility to design the workload model as per spike test requirements.
For a new application: This is an optional test for a new application. Still, if the business wants to test the application with spike load then a performance tester can design the step-up spike test and note down the behaviour of the application.
- Verify the sustainability of the application at the sudden huge load
- Identify the deviation in the response time during spike load
- Check the failure percentage of the transactions
- Identify the type of error like 500, 504 etc.
- Note the recovery time of the application in case the application is down during a spike
- Identify if there is any bottleneck
- Check whether the resources (CPU, Memory and Disk) do not breach the defined performance limit even during the spike period
The spike test is an optional test in the performance testing world. Spike test scenario is rare in the production environment but unavoidable. If any huge spike identifies in the production then it must require an investigation. During the investigation, the same scenario simulates in the performance test environment and identifies the root cause.
To handle the same situation in the future, a spike test performs in the test environment and tune the application in case of any issue occurs.
A performance tester prepares the workload by referring to the spike test NFR. NFRs must have the defined Base Load and Spike Load so that an accurate workload can be created. Ideally, the duration of the spike test is 1 hour (excluding the ramp-up and ramp-down periods). The typical spike user graphs are shown above (Figure 1, Figure 2 and Figure 3).
In the performance test result, application response time during the spike period is an important metric. Also, the performance tester must give attention to the break (failure) point of the application (if any) along with the type of errors and application recovery period. The type of errors provides an idea of whether the application is fully down or some of the weak functionalities are impacted due to sudden spikes and what is the reason for failure. The root cause analysis helps to identify the exact issue.
It is recommended to plan at least 2 identical spike tests in a single performance testing cycle and if both tests have consistent results then only jump on to the next type of performance test.
YouTube Video: Link
You may be interested: