Types of performance testing, by the question each one answers
The five types differ in one thing: what the load does over time. Everything else follows from that shape. So do not start by asking which type to run. Start by asking what you are worried about, and the type falls out of the answer.
Load testing: does it hold up at the traffic we expect?
The shape: ramp up to the expected traffic, hold it steady, ramp back down.
This is the baseline test and the one most teams mean when they say performance testing. It answers the narrowest question in the set: at the volume we plan for, does the system stay inside its targets?
Run it when you have a number for expected traffic and a target to check it against. It is also the right test to repeat, because a stable load test is the thing a regression shows up against.
What it will not tell you is anything about the margin. A pass means you are fine at that level and says nothing about the level above it, which is the next test.
Stress testing: where does it break, and how?
The shape: a staircase, climbing past the expected load, step after step, until something gives.
The point is not the number at which it breaks, although that is useful. The point is the manner of the breaking.
A system that degrades gracefully slows down, sheds load, returns clear errors and recovers when pressure drops. A system that fails badly locks up, cascades into dependent services, corrupts state, or stays broken after the load is removed. Those two systems can have identical load test results and completely different Saturday nights.
Run this before any event you cannot predict the size of, and run it at least once on anything important, because the recovery behaviour is a fact about your system that you would rather learn deliberately.
Watch the recovery, because most teams stop the test at the break. The valuable minute is the one after you remove the load, because that is where you find out whether the system comes back on its own.
Spike testing: what happens when traffic arrives all at once?
The shape: flat and low, then a sudden tall column, then flat again.
This is a different question from stress, and the difference is the rate of change. A system that copes with a gradual climb to ten thousand users can fail at two thousand arriving in five seconds, because autoscaling has not reacted, caches are cold, connection pools are empty and everything queues at once.
Run it if your traffic is event-driven. A campaign, a broadcast, a ticket release, a market open, a notification sent to every user simultaneously. If your traffic graph has vertical edges, the gradual tests are not testing your reality.
Soak testing: does it survive a week?
The shape: a modest, ordinary load, held for a very long time, hours rather than minutes.
This catches the class of problem that only appears with duration. A memory leak that adds a little each hour, a connection pool that loses one connection per thousand requests, a log file nobody rotates, a cache that grows without eviction, a queue that drains slightly slower than it fills.
None of these show up in a twenty-minute load test. All of them show up on day three in production, usually as a gradual slowdown followed by a restart that appears to fix it, which is how a leak survives for a year.
Run it before a release you cannot easily roll back, and run it long enough to be boring. The value is in the trend line, not the peak.
Scalability testing: does adding capacity actually help?
The shape: stepped increases in load, with capacity added at each step, and a second line for the capacity you added.
The question is whether the two lines track. Double the servers, double the throughput, is the hope. Reality is usually less, and the gap is what you are measuring.
It matters because the answer decides your architecture rather than your tuning. If throughput stops improving as you add capacity, something is shared and serialised: a single database, a lock, a queue, an external service with its own limit. No amount of extra application capacity moves a constraint that lives somewhere else.
Run this before committing to a growth plan that assumes you can buy your way out. The honest finding is often that you can, up to a point, and the point is closer than expected.
