--- title: "Types of Performance Testing: When to Use Each | Evaluat" description: "The types of performance testing explained for beginners: load, stress, spike and soak, plus smoke, capacity, volume and scalability, and which to run when." url: "https://www.evaluat.com/blog/types-of-performance-testing" last_modified: "2026-09-09" --- [Blog](https://www.evaluat.com/blog) [Testing Types](https://www.evaluat.com/blog/category/testing-types) # The types of performance testing, and when to use each Load, stress, spike, soak: the names get used interchangeably, but each test answers a different question about your site. This guide maps every major type of performance testing to the question it answers and the traffic shape it uses, in one table, with an honest order to run them in. Start with the question, and the right test picks itself. Written by: [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · 9 September 2026 [Beginner's guide](https://www.evaluat.com/blog/beginners-guide) Part 3Foundations ![The four main types of load testing as four traffic shapes: load testing ramps to expected traffic and holds; stress testing climbs until the system breaks; spike testing jumps to a sudden surge and drops back; soak testing holds a steady load for hours. Each shape answers a different question.](https://www.evaluat.com/blog/types-of-performance-testing-cover.svg) Summary Performance testing is a family of tests, and each member answers one question. The four main types of load testing are load testing, which checks expected traffic; stress testing, which finds the breaking point beyond it; spike testing, which rehearses sudden surges; and soak testing, which runs a steady load for hours to catch slow degradation like memory leaks. Around those four sit the supporting types. A smoke test is a tiny run that proves your test and system work at all. Capacity testing measures the maximum load you can serve while still meeting your targets. Volume testing asks whether performance survives production-sized data, and scalability testing asks whether adding resources actually adds capacity. The order matters more than beginners expect: smoke first, because it costs minutes and catches broken setups; then a load test at expected traffic, because most sites fail that before any extreme; then stress and spike to find the edges; and soak before any long, unattended commitment. You rarely need every type. You almost always need to know which question you are asking, because a passing test of the wrong type is how sites fail with a green report on the wall. Listen to this article · 1:18 [Download the audio summary (MP3)](https://www.evaluat.com/blog/audio/types-of-performance-testing.mp3) ## What are the main types of performance testing? Performance testing is the family name for every test that measures how a system behaves under conditions you define. The members differ in one thing only: the shape of the traffic they apply. Change the shape, and the test answers a different question about the same site. The four main types of load testing are load testing, stress testing, spike testing, and soak testing. Load testing checks how the system behaves at expected traffic. Stress testing pushes past expected traffic to find the breaking point. Spike testing applies a sudden surge and an equally sudden drop. Soak testing holds a realistic load for hours to expose slow degradation. That is the answer to the question this page most often gets asked, and it is worth keeping crisp. The rest of the family, smoke, capacity, volume, and scalability testing, supports those four rather than competing with them; [Wikipedia’s taxonomy](https://en.wikipedia.org/wiki/Software_performance_testing) adds further variants like breakpoint and configuration testing, and [Grafana’s k6 guide](https://grafana.com/docs/k6/latest/testing-guides/test-types/) teaches six with a recommended running order. Frameworks differ at the edges; some, like [RadView’s](https://www.radview.com/performance_testing/4-types-of-load-testing-and-when-each-should-be-used/), swap spike for capacity in their top four. The questions stay the same, which is why this guide organises everything around them. ## Load testing: will it hold at expected traffic? A load test simulates the number of visitors you realistically expect, at their realistic pace, and watches whether pages stay fast and requests keep succeeding. It is the workhorse of the family and the first real answer most teams need, because most sites do not fail at some exotic extreme. They fail at a peak that was entirely foreseeable. The traffic shape is a ramp up to the target, a steady plateau long enough to trust the reading, and a ramp down. The output is a curve of response times against concurrent users, and the useful number is where that curve begins to bend relative to your target. If the term is new territory, the full explainer covers scenarios, sizing, and reading results: [what load testing is](https://www.evaluat.com/blog/what-is-load-testing). ## Stress testing: where does it break, and how? A stress test deliberately exceeds expected traffic and keeps climbing until the system degrades or fails. The point is not cruelty; it is knowledge. You learn the ceiling’s real number, which failure arrives first, timeouts, errors, a crashed dependency, and whether the system recovers gracefully once load drops. Stress results turn vague confidence into a margin: if peak forecast is 1,500 concurrent users and degradation starts at 2,100, you know your headroom is 40 percent, and you know what Monday morning looks like if you are wrong. A breakpoint test is a disciplined variant of the same idea, ramping steadily until a predefined failure condition trips. The walkthrough lives in [how to stress test a website](https://www.evaluat.com/blog/stress-testing-a-website). ## Spike testing: what happens when everyone arrives at once? A spike test jumps from quiet to very busy in seconds or a couple of minutes, holds briefly, and drops back. It exists because arrival rate is its own risk: infrastructure that comfortably serves a level of traffic can still fail while getting there, when autoscaling needs minutes that a stampede does not grant and cold caches all miss at once. Spike shapes match real moments: a sale opening, an email blast landing, a TV or social mention. If your calendar contains any of those, the spike question is your question. The explainer, including what a realistic spike profile looks like, is at [what spike testing is](https://www.evaluat.com/blog/what-is-spike-testing). ## Soak testing: does it survive hours, not minutes? A soak test, also called endurance testing, runs a realistic load steadily for an extended period, hours rather than minutes, and watches for slow decay: memory climbing run after run, connections leaking, queues quietly building, disk filling with logs. Short tests structurally cannot catch these, because the whole failure mode is time. Soak testing earns its slot before long unattended commitments, a weekend sale, an overnight batch window, any period where nobody is watching dashboards. The deep dive, with duration guidance, is at [soak testing explained](https://www.evaluat.com/blog/soak-testing). ## The supporting types: smoke, capacity, volume, scalability **Smoke testing** is the tiny run that comes first: a handful of virtual users proving the scenario works, the environment responds, and nothing is obviously broken. It costs minutes and prevents the embarrassing failure mode of debugging your own test at full load. Where it fits next to full performance tests is covered in [smoke testing vs performance testing](https://www.evaluat.com/blog/smoke-testing-vs-performance-testing). **Capacity testing** measures the maximum load you can serve while still meeting your targets, the usable ceiling rather than the breaking point. It produces the number planning conversations need. [Part 5 of this guide](https://www.evaluat.com/blog/what-is-capacity-testing) covers it in full. **Volume testing** holds traffic steady and scales the data instead: the 400,000-product catalogue, the years of order history, the search index at production size. Systems that fly on a seeded test database can crawl on real data. Part 13 takes it apart. **Scalability testing** asks whether adding resources actually adds capacity: double the servers, and does the ceiling double, or does a shared bottleneck flatten the gain? It is how you learn whether “we will just scale up” is a plan or a hope. Part 53 covers it later in this guide. ## How do the types compare? The types compare most usefully on three axes: the question each answers, the traffic shape it applies, and the moment on your calendar that calls for it. The table below is the whole taxonomy in one view; if you keep only one artifact from this page, keep this and let each row’s deep link carry the detail. | Type | Question it answers | Traffic shape | Run it when | | ----------- | ----------------------------------- | ------------------------------------ | ------------------------------------- | | Load | Does it hold at expected traffic? | Ramp, hold, ramp down | Before releases, launches, and events | | Stress | Where does it break, and how? | Climb past the target until failure | After a load baseline exists | | Spike | Does it survive a sudden surge? | Jump, brief hold, drop | Before sales, drops, and campaigns | | Soak | Does it degrade over hours? | Steady realistic load, extended | Before long or unattended periods | | Smoke | Does anything work at all? | Minimal users, minutes | First, always, and after changes | | Capacity | What is the usable ceiling? | Step up in plateaus, measure at each | For planning and growth decisions | | Volume | Does real-sized data hurt? | Normal load, production-scale data | Before data grows past the test set | | Scalability | Does adding resources add capacity? | Same test across resource levels | Before trusting a scale-up plan | ## Which test should you run first? Run them in the order that spends effort where the risk is: smoke, then load, then the event shapes. A smoke test first, always, because it is nearly free and catches broken setups. Then a load test at expected traffic, because that is the question with money on it. Only then do stress, spike, and soak earn their slots, chosen by the risk on your actual calendar, a sale coming means spike, a long quiet period means soak, an architecture change means stress. Grafana’s k6 documentation [recommends essentially this progression](https://grafana.com/docs/k6/latest/testing-guides/test-types/), and it matches what we see in practice. Two practical notes soften all of this. First, the types share their ingredients: the same user journey, the same environment, the same metrics, with only the load profile changing. Build a scenario once. Use it everywhere. That is also how Evaluat treats them, one scenario driven through different traffic shapes, measured in real browsers so each shape shows what visitors would actually see. Second, the names matter less than the questions. If your tool calls capacity testing “stress testing”, nothing bad happens as long as you know which question you asked. ## Common mistakes when choosing a test type - **Running stress before load.** Finding the breaking point is exciting, but the question with revenue attached is expected traffic. Baseline first, extremes second. - **Treating a passed load test as spike readiness.** Steady-state capacity says nothing about arrival rate. If traffic comes in bursts, rehearse bursts. - **Skipping smoke tests.** Debugging a broken scenario at 1,000 virtual users costs an afternoon; at 5 users it costs a coffee. - **Confusing the ceiling with the breaking point.** The load you can serve within targets (capacity) is lower than the load at which you fail (stress). Plan with the first, learn from the second. - **Collecting types like stamps.** Eight passing tests of the wrong shapes protect nothing. One load test on the journeys that earn money beats them all. The family, then: four main types answering four questions, four supporting types for the questions behind them, and an order that starts cheap and ends thorough. Pick the question that matches the risk on your calendar this quarter, and the right test picks itself. Test in real browsers. Debug in real sessions. [Book a demo](https://www.evaluat.com/demo?intent=performance) and we will run your first scenario through the shapes that match your calendar. [Previous · Part 2What is website performance, and why does speed matter?](https://www.evaluat.com/blog/what-is-website-performance) [Next · Part 4What is a virtual user?](https://www.evaluat.com/blog/what-is-a-virtual-user) ![Ahmad Farzan, Founder at Evaluat](https://www.evaluat.com/authors/ahmad-farzan.jpg) About the author [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · Founder at Evaluat Founder of Evaluat. Has spent years building and load-testing Adobe Commerce and Magento storefronts, and built Evaluat to test sites the way real browsers actually hit them. [Ahmad Farzan on LinkedIn](https://www.linkedin.com/in/ahmadfarzan/) [Ahmad Farzan on GitHub](https://github.com/farzanahmad) [More from Ahmad →](https://www.evaluat.com/authors/ahmad-farzan) Common questions ## FAQ ### What are the four main types of load testing? Load testing, stress testing, spike testing, and soak testing. Load testing checks behaviour at expected traffic, stress testing pushes beyond it to find the breaking point, spike testing rehearses sudden surges, and soak testing holds a steady load for an extended period to catch slow degradation. ### How many types of performance testing are there? Most taxonomies name seven to ten, but they cluster into four main types (load, stress, spike, soak) plus supporting types: smoke, capacity, volume, and scalability testing. Vendors slice the names differently; the questions each test answers are the stable part. ### Is endurance testing the same as soak testing? Yes. Endurance testing and soak testing are two names for the same practice: running a realistic, steady load for an extended period, often several hours, to expose problems that only appear over time, such as memory leaks, connection pool exhaustion, and slow resource creep. ### Which performance test should you run first? A smoke test, then a load test. The smoke test proves your scenario and system work at minimal load, which takes minutes and catches broken setups cheaply. The load test at expected traffic answers the question most teams actually have. Stress, spike, and soak come after that baseline exists. ### What is the difference between capacity testing and stress testing? Capacity testing finds the maximum load you can serve while still meeting your response-time targets, a business planning number. Stress testing keeps pushing past that point to learn how the system fails and recovers. One measures the usable ceiling, the other explores what lies beyond it. ### Do I need to run every type of performance test? No. Most teams get the bulk of the value from a smoke test, a regular load test, and one event-shaped test that matches their risk, a spike test before sales, or a soak test before long unattended periods. Add the others when their specific question becomes yours. ### Which performance test matters most before a product launch? A load test at your forecast launch traffic, on the real user journeys, plus a spike test if the launch lands in a burst, an email blast or a public announcement tends to produce a surge, not a gentle ramp. Stress testing is useful afterwards to learn the margin you launched with. Related reading ## More from the blog [![Three test types, three load shapes: load testing ramps to a steady plateau, stress testing climbs past the breaking point, and performance testing is the umbrella over both.](https://www.evaluat.com/blog/load-vs-stress-vs-performance-testing-cover.svg)](https://www.evaluat.com/blog/load-vs-stress-vs-performance-testing) ### [Load testing vs stress testing vs performance testing: how the three actually differ](https://www.evaluat.com/blog/load-vs-stress-vs-performance-testing) [Three terms, endless confusion. Performance testing is the umbrella; load testing checks whether you survive the traffic you expect; stress testing pushes past that to find where you break. This guide shows how the three actually differ, when to run each, and which one your team needs first.](https://www.evaluat.com/blog/load-vs-stress-vs-performance-testing) [Ahmad Farzan · 3 June 2026](https://www.evaluat.com/blog/load-vs-stress-vs-performance-testing) [![A capacity test steps the load up in plateaus, from 500 to 1,750 virtual users, while the 95th percentile response time is read at each step. Response time stays under the two second target up to 1,250 users, which is the usable ceiling, crosses the target at 1,500, and the site only breaks at 1,750. Capacity is the last step that still meets the target, not the breaking point.](https://www.evaluat.com/blog/what-is-capacity-testing-cover.svg)](https://www.evaluat.com/blog/what-is-capacity-testing) ### [What is capacity testing?](https://www.evaluat.com/blog/what-is-capacity-testing) [Most teams can tell you when their site falls over. Far fewer can tell you when it stops being good enough, and that second number is the one customers feel. Capacity testing, in performance testing, finds it. It measures how many users your site can serve while still meeting the speed and error targets you set in advance.](https://www.evaluat.com/blog/what-is-capacity-testing) [Ahmad Farzan · 18 September 2026](https://www.evaluat.com/blog/what-is-capacity-testing) [![Response time chart for the same checkout: at one user the page answers in under a second; as concurrent users approach 3,000 the curve bends and the same page takes eight seconds. Load testing measures that curve before real traffic does.](https://www.evaluat.com/blog/what-is-load-testing-cover.svg)](https://www.evaluat.com/blog/what-is-load-testing) ### [What is load testing?](https://www.evaluat.com/blog/what-is-load-testing) [Load testing tells you what happens to your site when real traffic shows up at once. This guide explains what it is, why slow pages cost conversions, how a test actually runs, and how to size your first run, with no prior testing background assumed.](https://www.evaluat.com/blog/what-is-load-testing) [Ahmad Farzan · 12 July 2026](https://www.evaluat.com/blog/what-is-load-testing) See it on your site Test in real browsers.\ Debug in real sessions. ## Want to see this measured on your app? 30 minutes. We build a scenario on your real customer journey, run a small test, and walk you through the report. [Book a demo](https://www.evaluat.com/demo?intent=performance) [How it works](https://www.evaluat.com/how-it-works)