Performance, Load, Stress and Soak testing

Last Updated on by

Post summary: Performance, Load, Stress and Soak testing are different aspects of one goal – proving that application will function correctly with large amount of users.

Previously I have written for non-functionally testing the application in conditions of large amount of users in How to do proper performance testing post. There I’m using only one term performance testing. If we have to be precise there are several different types of testing that can be done to achieve the goal of sustaining large amount of users.

Performance testing

Testing the system to find out how fast is the system. Create a benchmark of system response times and stability under particular user load. Response time should be small enough to keep users satisfied.

Load testing

Testing how the system performs when it is loaded with its expected amount of users. Load can be slightly increased to measure if and how performance degrades. Load and performance testing are tied together. System performance depends on the load applied to it. Load testing should prove that in case of expected and peak users load system performs close to benchmarks measured with small load.

Stress testing

Testing of the system beyond its normal expected amount of users to observe its behaviour. Sometimes system is loaded until its crash. The idea behind this testing is to understand how system handles errors and data when it is highly loaded, is data preserved correctly, what load can crash the system, what happens when the system crashes.

Soak testing

This is kind of underestimated but it is rather important. Soak testing is to test the system with expected or little more than expected load for a long amount of time. The idea behind that is system may respond fast during short tests but actually to hide some memory leak which will become obvious after long amount of time.

Knowledge is power

Knowing the problems helps to prepare against them. Procedures can be prepared and followed to avoid system crash. In case there is a module identified to be slow but important for business it can be made configurable and can be turned down in case of higher load. In case users count have reached critical level that could endanger the system, support can reject some users. In case of memory leaks, support can restart the system on regular intervals in time of low load to avoid crash. All those and many more can be done only if we know the system.

Conclusion

There are different techniques to prove that system can handle amount of users expected by business. I like the term performance testing and use it to combine all the types of testing above. It is not that important to know the precise definition of the terms than to know what is good to be done in order to prove system can handle large amount of users, or to identify the bottlenecks in case it cannot.

If you find this post useful, please share it to reach more people. Sharing is caring!
Share on FacebookShare on LinkedInTweet about this on TwitterShare on Google+Email this to someone
Category: Non-functional | Tags: