by Rajinder Kumar, Senior Performance Test EngineerDiscover the reasons for conducting various forms of performance testing and the risks you mitigate.
In my first blog I defined some essential performance testing terminology and explored a few of the key concepts. Now in this next post in the series, I'm going to delve deeper into each type of test and give you my thoughts on when and why each should be done.
Performance testing is a catch-all term that includes various tests used to verify speed, scalability, and stability. Tests help identify and mitigate risks in all these critical areas. At the various organisations and clients where I have worked, it was often a surprise to me that many didn't validate their systems by testing in all three areas. In many cases they prioritised speed which in my opinion is a mistake.
In my experience many testing terms are used interchangeably, even by me (!), but they are different and you should ensure that your testing includes them all, or have a good reason why not, preferably alongside some risk analysis.
What do we mean by speed, scalability and stability? The risks related to speed, scalability and stability need to be understood and mitigated so that your application or system meets performance expectations.
Speed: Check that the application meets the required response times in order to satisfy end users or business processes. It should be benchmarked against previous versions or similar applications to verify that there is no degradation or worsening performance.
Scalability: Ensure that the application or system supports both the required number of users or throughput and the data produced to be stored in databases. It also needs to be able to identify or alert when capacity is approaching, perhaps making available extra resources on the fly.
Stability: Make sure that the application is reliable when working over an extended period of time and is recoverable if things go wrong such as hardware failures.
How to mitigate the risks related to speed, scalability and stability Here's an overview of performance test types which can be used to mitigate the risks.
Load test: This will be the most common type of performance test you should be running. It can be testing to the expected load or a peak load, typically over an hour. In various organisations where I have worked, a peak hour is determined by simply doubling the average load expected. But it's difficult to determine what the load should be, especially if it's a new service that's being introduced. So, it's imperative that you work closely with business analysts who can guide you on the load mix for the test. The results from this can be used as a baseline, which future tests can be evaluated against when performance improvements have been made to the application or system. The profile below shows how a load might be applied (in this case 50 users) for 1 hour after a ramp up and then eventually ramping down. This testing should determine the speed of the system so that it can be evaluated against expectations and also provide valuable input to determine stability and scalability.
Volume test: This testing evaluates how a system handles a large amount of data. A representative database size (or expected size) should be used and checked to see if it can handle increased volumes of data or high volume of transactions. In my experience this type of testing can be neglected and I have been in many organisations where a representative sized database is not being used, thus missing potential bottlenecks and performance issues. This type of testing assesses speed, scalability and stability.
Stress test: This will evaluate system behaviour when the load goes beyond the expected levels and establishes what types of errors will occur at the breaking points of a system so it can be planned for. This type of testing can help you set up monitoring alerts at levels before the load causes slowness and failures, so you can take evasive action. The profile below of a typical test shows that the load is gradually increased so that slowness and failures can be monitored. This type of testing assesses speed, scalability and stability.
Capacity test: This type of test can provide information of how many users or throughput a system can support and still meet the performance requirements. These tests will help the business plan for future growth in terms of, for example, server size and number, disk space and network bandwidth. A business would typically have capacity models which capacity tests can help to validate, but these can be complex to set up. This type of testing mitigates against scalability risks.
Scalability test: Assesses how a system can scale up or scale out on the fly, when load increases and more resources are required in order for the required performance goals to be maintained. This is more prevalent now with migration to the cloud where technologies are available to do this easily. This type of testing assesses speed, scalability and stability.
Spike test: Assesses system behaviour when the load increases above expected levels for a short period of time. This type of testing can help the business plan for any failures if a sudden load is experienced and quantify how it affects the speed of the application or system. A typical profile of the test is shown below. This type of testing assesses speed, scalability and stability.
Soak test: This test ensures that performance is consistent over an extended period of time. It checks that resource usage, such as memory, is not growing over time, and makes sure that any other scheduled jobs or unexpected system processes do not affect the performance of the application. Typically, the test is run at a lower load than the peak over an extended period of say 12 or 24 hours with system resourc
