Performance testing shows how an application behaves under load: how fast it responds, how many users it can serve and whether it stays stable. There is no single performance test. Each type answers a different question, so choosing the right one matters. This guide defines every type, compares them in one table, and covers the process, metrics and tools. For help choosing which test to run in a given situation, see our companion guide on the different types of performance testing. For the full programme view, read the software performance testing guide.
What performance testing measures
Performance testing is part of performance engineering. Unlike functional testing, which asks “does it work?”, it asks “how well does it work under pressure?”. It looks at three things:
- Speed: is the response time fast enough to keep users engaged?
- Scalability: how much load can the system carry, and does it grow with added resources?
- Stability: does it keep performing under varied, changing and long running load?
It is vital for systems that must run without interruption, such as payments, healthcare and logistics. Slow or unavailable software costs real revenue, so the aim is to find problems before customers do.
The types of performance tests at a glance
| Type | Question it answers | How the load behaves |
|---|---|---|
| Load testing | Does it meet targets at expected traffic? | Ramps up to normal and peak expected levels |
| Stress testing | Where does it break, and how does it recover? | Goes beyond limits until failure |
| Spike testing | Can it survive a sudden surge? | Jumps sharply, then drops |
| Soak (endurance) testing | Does it stay healthy over hours or days? | Steady, realistic load for a long time |
| Scalability testing | Does performance grow as resources are added? | Increases load while changing capacity |
| Volume testing | Can it handle very large amounts of data? | Large data sets, normal user load |
Load testing
Load testing raises the workload to anticipated production levels and checks that the application still meets its targets, such as a response time under two seconds for 1,000 concurrent users. It also finds bottlenecks before go live. It is the test most teams run first.
Stress testing
Stress testing pushes the application beyond normal limits, with extreme traffic, limited memory or failing dependencies. The goal is to find the breaking point and to learn whether the system fails safely and recovers cleanly.
Spike testing
Spike testing applies a sudden and large jump in load, like a flash sale or a viral link, and then watches response and recovery. It differs from stress testing because the focus is on speed of change rather than total volume.
Soak (endurance) testing
Soak testing, also called endurance testing, runs a normal or slightly high load for a long period, often many hours or days. It exposes slow problems such as memory leaks, connection pool exhaustion and disk growth that short tests never show.
Scalability testing
Scalability testing checks how performance changes as load grows and as resources are added or removed. It measures response time, throughput, requests per second, transaction speed and CPU and network use, and tells you whether adding servers actually helps.
Volume testing
Volume testing (sometimes called flood testing) fills the system with large amounts of data and checks the effect on response time, storage, reports and batch jobs. A database that is fast with 10,000 rows can crawl with 100 million.
Common performance problems these tests find
- Long load time: slow start up or first page render.
- Poor response time: too long between request and first response.
- Poor scalability: the system cannot serve the expected number of users.
- Bottlenecks: code or hardware limits that cut throughput at certain loads.
- Resource leaks: memory, threads or connections that never get released.
The performance testing process
- Identify the environment: compare test and production, and list the tools you have.
- Set acceptance criteria: targets for response time, throughput and resource use.
- Plan and design tests: choose the key user journeys and expected usage patterns.
- Configure the environment: prepare data, monitoring and load generators.
- Implement the tests: script the scenarios.
- Run and monitor: execute and watch both the application and the infrastructure.
- Analyse, tune and retest: share results, fix bottlenecks and repeat to confirm gains.
Performance testing metrics
Track response time (use percentiles such as p95, not only averages), throughput, error rate, concurrent users, CPU, memory, disk time and network bandwidth. A passing average can hide a slow tail that real users feel. See our guide to throughput for more on the key measure, and benchmark testing for comparing results over time.
Performance testing tools
The right load testing tools depend on the protocols you need, licence cost, hardware needs and platform support. Common choices include:
Others, such as k6, LoadRunner and NeoLoad, are also widely used. For mobile apps, see performance testing mobile apps.
Conclusion
Each performance test answers a specific question: load for expected traffic, stress for limits, spike for surges, soak for long running health, scalability for growth and volume for data. Match the test to the risk, set clear targets first and retest after every fix.
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.
One Response