Most teams know the names of the performance test types. The harder question is which one to run, when, and in what order. This guide is built around that decision. If you want the definitions and the process first, start with our overview of the types of performance tests, and then come back here to decide what to run.
Start with the question you need answered
Pick the test by the risk you are worried about:
| If your worry is… | Run this test |
|---|---|
| “Will it cope with normal and peak traffic?” | Load testing |
| “Where does it break, and will it recover?” | Stress testing |
| “What if traffic jumps suddenly, for a sale or a launch?” | Spike testing |
| “Will it slow down or leak memory after running for days?” | Soak (endurance) testing |
| “Will adding servers actually help?” | Scalability testing |
| “Will big data sets slow reports and queries?” | Volume testing |
A sensible order to run them
- Baseline first. Run a small test with a single user or few users to record normal response times.
- Load test to confirm you meet targets at expected traffic. Fix obvious bottlenecks.
- Stress test to find the limit and check recovery.
- Spike test if you expect sudden surges.
- Soak test before major releases, since it takes the longest.
- Scalability and volume tests when you plan to grow users or data.
Running them in this order saves time, because each test builds on knowledge from the one before.
The six types in practice
Load testing
The most common test. It simulates real world traffic and measures behaviour at different load levels, such as 200, 500 and 1,000 concurrent users. The goal is to find bottlenecks like slow response times or errors under heavy but expected use. It helps you optimise performance, confirm scalability and keep the system working at high traffic. You can watch a demo of the load testing tool Azure Load Test, and see our Azure Load Testing article for what to fix before production.
Stress testing
Stress testing pushes the application into extreme conditions, such as very high user numbers, limited resources or peak periods, to see how it responds under severe pressure. It reveals weak points and shows whether the system fails gracefully and comes back on its own.
Spike testing
Spike testing simulates sudden, steep traffic jumps and checks how the system handles the surge and recovers. It shows whether auto scaling reacts fast enough.
Soak and endurance testing
Both run the system for a long period to find issues that only appear over time. See the next section on how the two terms relate.
Volume testing
Volume testing checks how the system behaves with large amounts of data, to find the point where data size, not user numbers, causes slowness. See software performance testing for general background.
Scalability testing
Scalability testing measures how performance changes as load and capacity change. It shows whether the architecture scales out and where the returns diminish.
Soak testing vs endurance testing
This is the most common point of confusion. In most teams, soak testing and endurance testing mean the same thing: run a steady, realistic load for a long period and watch for degradation. Some teams draw a line between them, using “soak” for sustained high load and “endurance” for normal load over a long period, but there is no strict industry rule. If you use both terms in your own plan, define each one in writing so everyone means the same thing.
Frequently asked questions
What is performance testing?
It is a way to evaluate how a system performs under conditions such as heavy traffic, extreme limits and long running use, so problems are fixed before users meet them.
How long should a soak or endurance test run?
Long enough to reveal slow problems. Many teams run for 8 to 48 hours, and longer for systems that run for weeks without a restart. Pick a duration based on how long the system normally stays up between restarts, then document it with the objectives so results are reliable.
Should load and volume tests run in parallel?
Not by default. Run them separately first so you can tell which factor caused any slowness. Then run them together in a final test to mimic reality, where many users also create or read large amounts of data. For a hands on example of running load tests in the cloud, see running Gatling on the cloud.
How often should I run performance tests?
Run a light load test on every major change, and the full set (stress, spike, soak) before big releases or events. Automating the light tests in your pipeline catches regressions early; see shift left performance testing.
Which tools should I use?
Apache JMeter, k6 and Gatling are popular open source options. Compare them in our load testing tools guide.
Conclusion
Performance testing works best when each test has a clear question. Start with a baseline and a load test, add stress and spike tests to learn the limits, schedule soak tests before big releases, and use scalability and volume tests when growth is coming. Tuning the system after each result, and testing again, is what turns the numbers into a faster product.
Part of our guide to Performance Testing. Start with the complete Performance Testing guide, or read the related articles:
Want more testing guides in your Google results? Add Testmetry as a preferred source.
