95% of IT professionals run performance tests annually. Why? Because they’re essential to creating fast and reliable software, sites, and services. Discover the 10 types of performance testing and how you can use them to understand and optimize your performance.
Performance testing saves companies millions of dollars every year. It helps businesses and organizations:
- Prevent downtime & crashes
- Improve speed & scalability
- Uncover bugs, bottlenecks & bad code
- Mitigate security vulnerabilities & data loss
So what is performance testing?
Performance testing is the umbrella term for tests that look at the speed, scalability, reliability, and recoverability of software systems.
Performance tests are typically “non-functional” tests.
While functional tests involve making sure your web app works as it should, non-functional tests involve making sure your web app continues to work as it should under increased demand.
In simpler terms, functional tests ask: “does it work?” And non-functional tests ask: “How well does it work? How fast and reliable is it? Does it work at scale?”
Performance testing is crucial for making fast, reliable, and scalable software and sites. 92% of IT professionals consider performance testing either important or very important. And just 5% of IT professionals say they never run performance tests—a group you don’t want to be a part of.
Discover in this blog the 10 key types of performance tests and how, when, and why you might use them.
Table of contents
Load testing is the most popular type of performance test and is important for any system that has fluctuating and unpredictable levels of traffic.
Load testing checks software’s performance with a specified load to understand how it behaves under expected or heavy usage.
It lets businesses and organizations simulate different levels of traffic in a controlled environment, so they don’t experience crashes, errors, or slowdowns during popular events like Black Friday, tax time, or a major concert onsale.
RELATED: How High Online Traffic Can Crash Your Website
Load tests typically focus on expected load. This means if you’re expecting 10,000 concurrent users, your test will populate your site with 10,000 users—or maybe 11,000 to give some breathing room—to see how the site manages it.
While load testing is technically a non-functional test, it can reveal both functional (e.g., errors or crashes) and non-functional problems (e.g., slow response times or cart timeouts). This is because some bugs or errors that impact function only appear under load.
Benefits of load testing
- Reduces the risk of downtime
- Verifies performance for service level agreements (SLAs)
- Reveals the bottlenecks limiting scalability
- Shows how businesses and organizations can make faster sites and apps
- Identifies inefficient code, hidden bugs, and other bottlenecks
Stress testing is a type of performance testing that focuses not just on expected load, but on extreme load. It involves taking your site or app to the breaking point and observing recovery.
This means that even if your site works fine at the expected 10,000 concurrent users, you keep bumping that number up until your system crashes.
With a stress test, you’re looking to determine the point at which things slow down, produce errors, and crash. Stress testing reveals the level of load that causes failure and how well and fast your system can recover (its recoverability). The goal is to reduce the likelihood of failure due to load and to make crashes and recovery more graceful and safe.
By taking your system to the point of failure, stress testing can also reveal denial of service or security issues, and whether data is saved before the system crashes or if lost data can be restored.
Benefits of stress testing
- Shows how far an application can go beyond target load; establishing the upper limits to help with capacity planning
- Reveals the triggers you should monitor to prevent crashes and/or errors
- Enables you to verify that security vulnerabilities don’t emerge under extreme load
- Lets you determine and optimize system recoverability
- Reveals whether data loss or other issues occur during failure
- Shows how to fine tune your system to make crashes more graceful
Spike testing is a type of performance testing that involves flooding a site or application with sudden and extreme increases and decreases (spikes) in load.
It’s used to determine how quickly a system can scale, how fast it can recover, and whether traffic spikes produce bottlenecks or performance issues.
Spike testing is similar to load testing. But unlike load testing, spike testing doesn’t apply a uniform or expected load to your system (e.g.,100 requests per minute for 20 minutes). Instead, your spike test might simulate 1,000 requests one minute, then 100 the next, then 2,000 the next, and so on.
Spike tests are useful to prepare for situations in which traffic is large, unpredictable, and sudden, such as:
- Limited-edition product drops or flash sales
- Concert ticket onsales for a popular artist or festival
- A PR appearance or major marketing campaign
- A high-profile public sector registration (e.g. COVID-19 vaccinations, unemployment insurance)
Soak tests measure the performance of an application under a large load for an extended period of time. This prolonged application of load differentiates soak testing from load testing, and is why it’s also sometimes referred to as endurance testing or longevity testing.
The goal of soak testing is to see how your system handles load that lasts. It’s used to ensure performance is preserved during extended periods of usage.
With soak testing, you’ll want to ensure there aren’t issues with memory leaks, performance degradation, or database resource utilization that occur after hours of consecutive usage.
Soak testing is useful in scenarios like:
- Retailers handling several consecutive days of high traffic across Cyber Five (the shopping holidays from Thanksgiving to Cyber Monday)
- A tax portal that experiences several days of high demand in the lead up to tax time
- Streaming services or video games where many consecutive hours of usage is common
Volume testing (also called flood testing) is a type of testing that involves populating a system with large volumes of data.
Where load tests are about the number of users, volume tests are about the amount of data. So volume tests are mainly tests of the database.
Volume testing helps asses the system's ability to handle increasing volumes of data or user load without experiencing performance degradation or functional issues. A volume test may involve activities such as generating large datasets or executing a high number of transactions concurrently.
"The basic goal of a database is to maintain the illusion that there is only one copy, only one person changes it at a time, everyone always sees the most current copy, and it is instantly fast," says Paul King, data science manager at Apple.
Maintaining this illusion is no easy feat. But volume testing lets you determine whether your database is up to the challenge and if it can preserve performance under massive data load.
Recovery testing focuses on evaluating a system's ability to recover from failures, errors, or unexpected events.
Recovery testing is like stress testing because it reveals how gracefully a system crashes and recovers. But the key difference is that stress testing induces failure through load, where recovery testing can induce failure through a variety of methods.
Recovery tests simulate reasons for outages beyond load, such as hardware failure, network disruptions, erroneous software updates, or power outages.
Recovery testing assesses a systems ability to successfully recover its functionality, data, and usual performance after failure. It looks to avoid vulnerabilities, preserve data integrity, and validate backup and restore procedures.
In an ideal recovery test, the system functions and performs exactly the same before and after failure.
RELATED: How to Fix a Website Crash: 6 Steps to Restore & Safeguard Your Site
Scalability testing is a type of load testing that involves measuring the ability of an application to scale up or down in reaction to load.
The objective of scalability testing is to ensure the system can handle an expected increase in users, data volume, or transactions, and to determine the point at which the application cannot continue to scale.
Like spike testing, scalability testing involves applying variable levels of load. But unlike spike testing, scalability tests give the system time to scale up in response to load. Another key difference is that scalability testing can be performed on software, hardware, and the database.
Scalability testing can also be used to determine the effectiveness of server scaling and autoscaling.
RELATED: Autoscaling: Why Scaling Your Site is So Hard
Capacity testing involves measuring the maximum amount of users an application can handle while preserving performance benchmarks—typically those detailed in Service Level Agreements (SLAs).
The aim of capacity testing is to determine the maximum load the application can handle while still being able to deliver optimal performance.
Unlike stress testing—where you’re looking to apply maximum load to induce failure—capacity testing is about determining the maximum load at which things continue to perform as they should. This is sometimes called the “safety zone”.
A capacity test helps you determine the performance benchmarks you can guarantee in your SLAs, and the maximum load you can guarantee them at. Alternatively, it can be used to ensure a third-party service provider meets the standards outlined in their SLAs.
RELATED: How to Avoid the Website Capacity Mistake Everyone Makes
Component testing involves testing a distinct component of your application. This isn’t a distinct type of performance test, but is instead a different way of running performance tests—focusing on individual components rather than on a full typical user journey.
Examples of components an ecommerce company may test individually include a search function, a third-party feature or plugin like a chatbot or tax calculator, the recommendation engine, or a file upload component.
Component testing can be useful if you determine through a load test that one element of your application is a major bottleneck. As you make iterative changes to it, you can run component tests to save the trouble of re-testing the whole system with each change. (Although you should still re-test the whole system before you deploy final changes).
RELATED: Optimize Your Website Performance with These 11 Expert Tips
Reliability testing isn’t a distinct type of performance test but is instead a sub-category of performance testing.
Reliability is defined as the probability of failure-free software operation for a specified period, in a particular environment. Reliability tests help determine this probability, essentially providing a number as to how often an application does what it’s supposed to do.
You can determine the “reliability” of your system in any given situation using many of the different types of performance testing mentioned above.
For example, if you run an hour-long load test and there are faults that last for one minute, your reliability under that load is 59/60, or 98.333%.
RELATED: The Cost of Downtime: IT Outages, Brownouts & Your Bottom Line
You can also measure the availability of your service in the long term by using monitoring to determine its reliability. At Queue-it we use Pingdom to monitor the reliability of our virtual waiting room solution.
The industry standard for reliability is “four nines” (meaning the system availability cannot be lower than 99.99%), but this could anything from two nines (99%) to six nines (99.9999%), depending on your goals.