What Is Performance Testing? 7 Types, Metrics, and Examples

Every application has a breaking point. Performance testing finds it before your users do.

A checkout that slows under Friday traffic, a dashboard that crashes during a product launch, a server that degrades after 3 days of uptime: each failure traces to a performance question nobody asked. This guide answers those questions systematically.

It covers what performance testing is, the 7 types with an example for each, the metrics that matter, and when to run every test.

What Is Performance Testing?

Performance testing is a non-functional software testing method that measures a system’s speed, stability, scalability, and responsiveness under a defined workload. It identifies performance bottlenecks before users meet them.

Functional testing asks whether the system works; performance testing asks whether it works at scale.

The method answers 3 practical questions. Does the application crash when traffic spikes? Does it slow down as data grows? Does it degrade after running for days?

QA performance testing sits inside non-functional testing in software testing, next to security and usability testing. Teams run it on websites, mobile apps, APIs, and backend systems alike.

What Does Performance Testing Measure?

Performance testing measures 4 attributes: speed, scalability, stability, and reliability.

• Speed. The time the system takes to respond to a request under expected load. Response time and latency define it.
• Scalability. The system’s capacity to handle growing user traffic or data volume without redesign.
• Stability. Stability performance testing verifies the system runs without failure under fluctuating load over time. Memory leaks, resource exhaustion, and gradual slowdowns are its targets, and endurance testing is its primary method.
• Reliability. The system’s ability to operate consistently and recover from failure across long periods.

The 4 attributes connect: a system can be fast and unstable, or stable and unscalable. The 7 types below exist because no single test measures all 4.

What Are the 7 Types of Performance Testing?

There are 7 types of performance testing: load, stress, spike, endurance, volume, scalability, and capacity testing.

Each type targets a different attribute under a different workload shape.

1. Load Testing

Load testing measures application behavior under the expected number of users or transactions. The test simulates real-world traffic at normal and peak levels within a fixed period. Database locks, bandwidth limits, and slow queries surface here first.

Example: An e-commerce site simulates 5,000 concurrent shoppers browsing, adding to cart, and checking out for 1 hour.

Run it before every major release, with results compared against the previous baseline. The complete mechanics live in Load Testing Explained.

2. Stress Testing

Stress testing pushes the system beyond its normal operating limits to find the breaking point. Traffic climbs past expected peaks until responses fail, then the test observes how the system recovers. Stress testing is distinct from endurance testing: stress applies extreme load briefly, endurance applies normal load for a long time.

Example: A ticketing platform raises simulated users from 10,000 to 60,000 until error rates climb, then measures recovery time after the load drops.

Run it before launches, marketing pushes, and seasonal peaks. The full comparison sits in Performance Testing vs. Load Testing vs. Stress Testing.

3. Spike Testing

Spike testing evaluates the system’s reaction to sudden, sharp surges in traffic. Load jumps from normal to extreme within seconds instead of climbing gradually. The test reveals whether the system crashes, throttles, or absorbs the burst.

Example: A flash-sale page jumps from 500 to 25,000 users in under a minute when a discount goes live.

Run it before any event that concentrates traffic into a narrow window.

4. Endurance (Soak) Testing

Endurance testing, called soak testing, subjects the system to a steady workload for an extended period. Runs last from 8 hours to several days. Memory leaks, connection-pool exhaustion, and gradual response degradation only appear at this timescale.

Example: A banking API holds 2,000 concurrent sessions for 72 hours while memory usage is tracked per hour.

Run it before production go-live and on every long release cycle. Endurance testing is the direct measure of the stability attribute above.

5. Volume Testing

Volume testing processes massive amounts of data rather than massive numbers of users. The database fills toward production scale, and the test measures query times, indexing behavior, and storage handling.

Example: A reporting module generates analytics against a database seeded with 50 million records.

Run it before milestones that multiply data: migrations, integrations, and archival changes.

6. Scalability Testing

Scalability testing determines whether the system scales up and down smoothly as demand changes. User load increases in defined increments while the test measures whether added infrastructure delivers proportional capacity.

Example: A SaaS platform doubles simulated users from 5,000 to 10,000 to 20,000, checking response times at each step.

Run it during capacity planning and before architectural commitments.

7. Capacity Testing

Capacity testing identifies the maximum number of users the system supports while meeting its performance targets. The result is a number: the ceiling at which response times still hold. Teams plan infrastructure and growth budgets against it.

Example: A streaming service establishes that quality holds up to 38,000 concurrent viewers per node.

Run it before infrastructure purchases and scaling decisions.

Which Metrics Does Performance Testing Track?

Performance testing tracks 6 metrics: response time, throughput, error rate, resource utilization, latency, and concurrent users.

• Response time. Total time from request to complete response.
• Throughput. Transactions or requests processed per second.
• Error rate. The percentage of requests that fail under load.
• Resource utilization. CPU, memory, disk, and network consumption during the test.
• Latency. Network travel time before the server begins processing.
• Concurrent users. Simultaneous active sessions the system sustains.

Percentiles turn these metrics honest. The 90th percentile (p90) means 90% of requests completed at or below that response time. Averages hide outliers; p90, p95, and p99 expose the slow tail that real users feel.

How Do You Perform Performance Testing?

Performance testing follows a 6-step process from environment definition to retesting.

1. Define objectives and acceptance thresholds. Set numeric targets per metric.
2. Identify the test environment. Mirror production hardware, data, and network.
3. Design workload scenarios. Model real user behavior, not uniform requests.
4. Configure tools and scripts. Build the simulation against the scenarios.
5. Execute and monitor. Run tests while tracking all 6 metrics.
6. Analyze, tune, and retest. Fix the bottleneck, then prove the fix under load.

Each step carries its own deliverables and pitfalls. The stage-by-stage breakdown lives in the Performance Testing Life Cycle.

Which Tools Are Used for Performance Testing?

Apache JMeter is the most commonly used performance testing tool, alongside LoadRunner, Gatling, and k6.

Open-source tools cover most web and API scenarios; commercial platforms add enterprise protocols and reporting. Selection criteria and comparisons sit in Top 8 Performance Testing Tools.

What Is the 80/20 Rule in Performance Testing?

The 80/20 rule in performance testing applies the Pareto principle: roughly 80% of performance problems trace back to 20% of system components. A handful of slow queries, one chatty API, or a single unindexed table usually drives most of the degradation.

The rule changes test strategy. Profiling comes before fixing, because optimizing the vital 20% delivers most of the gain. Teams that tune components at random spend 5x the effort for the same result.

Will AI Replace Performance Testing?

No, AI will not replace performance testing; it accelerates script creation, workload modeling, and results analysis while engineers own workload design and bottleneck judgment.

AI drafts the simulation; humans decide what realistic load means for their users.

The broader division of labor between AI and QA teams is covered in AI in Software Testing.

When Should You Use Professional Performance Testing Services?

Professional performance testing pays off when load profiles outgrow in-house simulation: multi-region users, microservice backends, and releases where downtime costs revenue by the minute.

Building realistic test infrastructure costs more than most teams expect; renting expertise costs less than one production outage.

Testscenario’s Performance Testing services cover all 7 types with production-mirrored environments and per-metric reporting. API-layer engagements run through API Performance Testing.

FAQs

What is an example of a performance test?

A typical performance test simulates 5,000 concurrent users completing an e-commerce checkout while measuring response time, error rate, and server resource usage.

How many types of performance testing are there?

There are 7 types of performance testing: load, stress, spike, endurance, volume, scalability, and capacity testing.

What is the difference between performance testing and load testing?

Performance testing is the umbrella discipline measuring speed, stability, and scalability; load testing is one of its 7 types, focused on behavior under expected traffic.

Why is performance testing important?

Performance testing is important because it prevents revenue-costing failures: crashes under traffic, slowdowns under data growth, and degradation over time.

When should performance testing be done?

Performance testing starts at the first integrated build and repeats before every major release, with load and endurance tests on a fixed cadence.

Is performance testing functional or non-functional?

Performance testing is non-functional testing: it measures how well the system performs rather than whether its features work.