There are countless articles about the types of website load testing, but many remain at the theoretical level. Interestingly, the number of load testing types can vary depending on the source. For instance, some sources list six types, while others mention five. In this article, we will focus on four key types of load testing: Load Testing, Capacity Testing, Stress Testing, and Soak Testing.
These four load testing types are foundational and cover a wide range of scenarios that performance engineers frequently encounter. Should there be more types, they typically build upon or specialize within these core categories. Let’s dig in to the different types: Load Testing, Capacity Testing, Stress Testing, and Soak Testing. This article will describes when to use each type of test, and provides examples of the type of results you may expect to see.
1 – Load Testing
As expected – this is the bread and butter of every load tester, where you test how a system behaves with a large number of users and what is the response time received for pages under different scenarios.For example, in the graph below, you’re running a load test of 20 users to see that the page time does not exceed 3.5 seconds.
The graph shows the results of a load test for a system under varying user loads.The x-axis represents the relative time in hours, minutes, and seconds. The left y-axis indicates the response time in seconds, while the right y-axis shows the load size, which is the number of users.The green line shows the increase in load size, and the blue line represents the corresponding response times.
Further Reading: Read our guide for How to Do a Load Test with WebLOAD for a detailed look at how RadView’s WebLOAD specifically helps you conduct load testing.
2 – Capacity Testing
Capacity testing (sometimes called scalability testing) helps you identify the maximum capacity of users the system can support, while not exceeding the max page time you defined. The previous load testing example showed that the system easily served 20 users with a page time of 3.5.
Now you want to find out the capacity of your system – or at which point it will not be able to keep the 3.5 seconds response time? Will it be at 21 users, 30, 40, or 50 users?
Your higher-level objective is to identify the ‘safety zone’ of your system. To what extent can you ‘stretch’ it, without hurting the end-user experience? In the results graph that follows you’ll notice that for a page time of 3.5 seconds, the system supports 28 users. But when the load size reaches 29, page time starts exceeding the threshold of 3.5 seconds.
The capacity testing graph shows the system’s performance as the number of users gradually increases up to 34. The green line indicates the increasing load size, while the blue line represents the response times, which become more variable and increase significantly as the load grows.
This test identifies the point at which the system’s performance degrades, helping to determine its maximum capacity.
WebLOAD vs. JMeter : The Ultimate Comparison
3 – Stress Testing
The objective of a stress test is to find how a system behaves in extreme conditions. You purposely try to break your system, using any set of extreme conditions – whether doubling the number of users, using a database server with much less memory, or a server with a weaker CPU. What you’re trying to find out is how will the system behave under stress and
what will be the user experience?
Will the system start throwing out errors?
Will response time double?
Or will the entire system get stuck and crash?
To continue with the previous example, instead of stopping at around 30 users (when the page time exceeds your goal), you’d continue to increase the user load on the system. Your stress test discovers that up to the load size of 41 users, the system functions, despite the increase in page time. But when the load size reaches 42 users, the system starts to deteriorate, with page time reaching 15-17 seconds.
4 – Soak Testing
A soak test, also known as an endurance test, evaluates how a system performs over an extended period under a sustained load. This type of test helps identify issues like memory leaks, degradation in response time, and resource utilization that may not be evident in shorter tests.
Quite often, the ‘standard’ load testing, which is run for a short limited time will not succeed in uncovering all problems. A production system typically runs for days, weeks, and months. For example, an eCommerce application must be available 24×7 and a stock exchange application will run continuously on workdays. The duration of a soak test should have some correlation to the operational mode of the system under test.
Soak testing aims to uncover performance problems that surface only during a long duration of time. During soak testing, you’re asking questions such as:
Is there a constant degradation in response time when the system is run over time?
Are there any degradations in system resources that are not apparent during short runs, but will surface when a test is run for a longer time? For example, memory consumptions, free disk space, machines handles, etc.
Is there any periodical process that may affect the performance of the system, but which can only be detected during a prolonged system run? For example, a backup process that runs once a day, exporting of data into a 3rd party system, etc.
When running soak testing, you’re looking for trends and changes in system behavior. In the following example, notice how the load size is constant for a while, but still, there is a memory leak (=green line). At first, this memory leak may not affect the system, but after a while, the system may crash.(The example below is shorter than a typical soak test, which would last hours, days, and even weeks.)
Another use case, seen below, is a constant load size, but then, after 50 minutes of running the test, there’s an increase in memory (red line), which hurts throughput. This is due to a periodical, background process that affects the system when it starts running. (Again, in a real soak test, this would take much more time).
Get started with WebLOAD
Get a WebLOAD for 30 day free trial. No credit card required.
“WebLOAD Powers Peak Registration”
Steven Zuromski
VP Information Technology
“Great experience with Webload”
Priya Mirji
Senior Manager
“WebLOAD: Superior to LoadRunner”
Paul Kanaris
Enterprise QA Architect
Conclusion
In this blog, we explored four key types of load testing methods essential for evaluating system performance: Load Testing, Capacity Testing, Stress Testing, and Soak Testing.
Each of these load testing types serves a unique purpose in ensuring that your system can handle various conditions. Load Testing assesses the system’s behavior under typical user loads, while Capacity Testing identifies the maximum load the system can handle while maintaining acceptable performance. Stress Testing pushes the system to its limits to determine its breaking point under extreme conditions.
Soak Testing, or endurance testing, evaluates the system’s performance over extended periods to identify issues like memory leaks and response time degradation.
Understanding and applying these types of load testing ensures that your system remains reliable and efficient, ultimately enhancing user satisfaction and trust. If there’s one lesson from these four types of load testing, it is this: performance engineers must dedicate significant thought as to what are the objectives of each test run what are their expectations from the system under test.
Before you invest in building complex, time-consuming scenarios, make sure you have clear goals for your tests.
Get a WebLOAD for 30 day free trial. No credit card required.
“WebLOAD Powers Peak Registration”
Webload Gives us the confidence that our Ellucian Software can operate as expected during peak demands of student registration
Steven Zuromski
VP Information Technology
“Great experience with Webload”
Webload excels in performance testing, offering a user-friendly interface and precise results. The technical support team is notably responsive, providing assistance and training
Priya Mirji
Senior Manager
“WebLOAD: Superior to LoadRunner”
As a long-time LoadRunner user, I’ve found Webload to be an exceptional alternative, delivering comparable performance insights at a lower cost and enhancing our product quality.
