What Is Performance Testing? Types, Metrics, Process and Tools

Performance testing is a type of non-functional software testing that evaluates how quickly, reliably, and efficiently a system operates under a defined workload. It measures response time, throughput, stability, scalability, and resource consumption to identify bottlenecks before they affect users.

Unlike functional testing, which checks whether a feature produces the correct result, performance testing examines how well the system produces that result when traffic, data volume, or processing demand changes.

Why performance testing matters

A feature can be functionally correct and still fail as part of a real product. A checkout may process payments successfully for ten test users but time out when several thousand customers arrive at once. A reporting module may return accurate data yet consume so much memory that the application becomes unstable after several hours.

Performance problems affect more than loading speed.

1. Downtime has a measurable business cost

The Uptime Institute’s 2025 outage analysis found that 54% of respondents said their most recent significant outage cost more than $100,000. One in five reported costs exceeding $1 million.

Performance testing cannot prevent every outage. It can, however, reveal saturation points, configuration limits, resource exhaustion, and failure behavior before the same conditions occur in production.

2. Performance affects conversion and customer behavior

Slow systems create friction at the exact moment a user is trying to complete a task. This may mean abandoning a purchase, repeating a payment, closing a mobile app, or contacting support.

A recent T-Mobile performance case study reported a 20% reduction in user site issues and a 60% improvement in the visit-to-order rate after the company connected real-user performance data with business metrics and addressed Core Web Vitals problems.

These results should not be treated as a universal conversion formula. They demonstrate why each company should correlate its own performance data with abandonment, conversion, retention, and support metrics.

3. Real users experience conditions that test environments often miss

Production traffic is distributed across devices, locations, networks, user behaviors, and third-party dependencies. Tests performed from one powerful workstation over a stable office connection provide only a partial picture.

The 2024 Web Almanac found that only 43% of mobile websites achieved good Core Web Vitals when Interaction to Next Paint was included, compared with 54% on desktop. Device processing power and network quality continue to create a meaningful mobile performance gap.

4. Performance is part of the SLA

Service-level agreements may define availability, response-time, throughput, or recovery commitments. Performance tests help determine whether the architecture can meet those commitments under expected and exceptional workloads.

Averages are rarely enough. If an API has an average response time of 300 milliseconds but its p99 response time exceeds five seconds, a meaningful portion of users may still receive an unacceptable experience.

Types of performance testing

Performance testing is an umbrella term covering several related test types. Each answers a different question about system behavior.

Load testing

Load testing measures performance under an expected workload. The workload may be represented by concurrent users, requests per second, transactions per hour, messages in a queue, or jobs processed within a given period.

A load test can answer questions such as:

• Can the system support the expected number of active users?

• Does response time remain within the target?

• Can the database process the forecast transaction rate?

• Does throughput increase as load rises?

• Are resources used efficiently?

Suppose an eCommerce platform expects 5,000 concurrent users during a regular evening peak. A load test would simulate a realistic mix of browsing, search, cart, checkout, and account activity at that level.

Load testing should not simply send as many requests as possible. The workload model must reflect production traffic, including user distribution, think time, session duration, caching, and request dependencies.

Stress testing

Stress testing deliberately pushes the system beyond expected capacity. Its purpose is to identify the breaking point, observe how the application fails, and confirm whether it can recover after the excessive load is removed.

A stress test may reveal:

• exhausted database connections;

• thread-pool limits;

• memory or CPU saturation;

• queue growth;

• cascading service failures;

• ineffective autoscaling;

• data corruption during interrupted operations;

• slow recovery after overload.

A well-designed stress test does not stop when the first error appears. The team should determine what failed, whether degradation was gradual or sudden, how users were affected, and how long recovery took. Our detailed guide explains what stress testing is and how to automate it.

Spike testing

Spike testing evaluates behavior during a rapid increase or decrease in workload. The total volume may be similar to a stress test, but the defining characteristic is the speed of the change.

Relevant scenarios include:

• a push notification sent to millions of users;

• ticket sales opening at a specific time;

• a flash sale;

• a breaking-news event;

• an authentication surge at the beginning of a workday;

• a sudden batch of webhook events.

The test should examine whether scaling occurs quickly enough, whether queues absorb the burst, and whether the system stabilizes when traffic returns to normal.

Soak or endurance testing

Soak testing applies a defined workload for an extended period. It targets problems that do not appear during a short test.

Examples include:

• memory leaks;

• unreleased database connections;

• growing cache or temporary storage;

• thread accumulation;

• log-volume problems;

• gradual response-time degradation;

• token expiration;

• scheduled jobs competing for resources.

A system may perform well during a 30-minute load test and become unstable after six hours. The appropriate test duration depends on the product’s traffic cycle and the suspected failure mode.

Volume testing

Volume testing evaluates system behavior with large amounts of data. The workload may remain stable while database size, file volume, event history, or record count increases.

For example, a reporting feature may work quickly with 50,000 records but require several minutes when the database contains 50 million. Volume testing helps expose inefficient queries, missing indexes, memory-intensive data processing, and storage limitations.

Test data must be realistic. Generating millions of identical records may produce different query plans, compression behavior, and cache patterns from varied production data.

Scalability testing

Scalability testing measures how effectively performance changes when demand and infrastructure resources increase.

It can evaluate:

• Horizontal scaling: adding instances, containers, workers, or nodes.

• Vertical scaling: adding CPU, memory, or storage capacity.

• Database scaling: adding replicas, partitioning data, or changing connection capacity.

• Application scaling: increasing workers or processing concurrency.

The objective is not merely to confirm that scaling occurs. Teams need to determine whether capacity grows proportionally, how quickly new resources become useful, and where another dependency becomes the next bottleneck.

Capacity testing

Software capacity testing establishes the maximum workload a system can support while still meeting agreed performance criteria.

For example, the goal might be to determine the highest number of concurrent users that can complete checkout while:

• p95 response time remains below two seconds;

• the error rate stays below 1%;

• CPU usage remains below 75%;

• database connections remain available;

• no critical queue exceeds its processing limit.

Capacity testing supports infrastructure planning, SLA negotiations, traffic forecasting, and release readiness. Unlike stress testing, it focuses on the maximum acceptable operating point rather than behavior far beyond normal limits.

Key performance testing metrics

A result such as “the application handled 10,000 users” is incomplete. It does not explain what those users did or whether the resulting experience was acceptable.

Use a balanced set of user-facing and system-level metrics.

Why p95 and p99 matter

Averages can make unstable performance look acceptable.

Imagine 100 API requests:

• 95 complete in 200 milliseconds;

• four complete in two seconds;

• one takes 15 seconds.

The average may still appear manageable, but the slowest users experience a substantially different service. Percentiles make that tail visible.

Use p95 for a broad view of slower interactions and p99 for critical systems where even a small percentage of delayed transactions creates material risk. Always report the workload, time window, sample size, and error rate alongside the percentile.

Performance testing process

Performance testing produces reliable evidence only when the workload, environment, data, and acceptance criteria reflect the intended use of the system.

1. Define business and technical objectives

Start with the decision the test must support.

Possible objectives include:

• validating readiness for an expected traffic peak;

• confirming an SLA;

• estimating infrastructure requirements;

• finding the system’s maximum capacity;

• comparing two architectural options;

• verifying a performance optimization;

• preventing regression before a release.

Convert each objective into measurable acceptance criteria. “The application must be fast” is not testable. “The search API must maintain a p95 response time below 500 milliseconds at 300 requests per second” is.

2. Select critical user journeys

Do not model every feature with equal weight. Focus first on workflows that are frequent, resource-intensive, revenue-generating, or operationally critical.

Examples include:

• authentication;

• product search;

• checkout;

• money transfers;

• media upload;

• report generation;

• API data synchronization;

• batch processing.

Include dependencies between actions. A checkout scenario may require authentication, product retrieval, cart creation, inventory validation, payment authorization, and order confirmation.

3. Build a realistic workload model

The workload model describes how users and systems generate demand.

Define:

• concurrent users or virtual users;

• requests or transactions per second;

• scenario distribution;

• ramp-up and ramp-down patterns;

• think time;

• session duration;

• geographic distribution;

• device and network conditions;

• expected data volume;

• background jobs;

• third-party traffic.

Use production analytics when available. If the product has not launched, base the model on business forecasts and document the assumptions so they can be revised later.

4. Prepare the environment and test data

The environment should resemble production in the areas that influence performance:

• compute resources;

• database configuration and size;

• network topology;

• caching;

• autoscaling rules;

• load balancers;

• queues;

• external integrations;

• logging and monitoring levels.

An identical copy of production is not always affordable. If the environment is smaller, document the differences and avoid assuming that results will scale linearly.

Prepare enough varied data to prevent unrealistic cache behavior. Protect personal and financial information through synthetic data, masking, or controlled generation.

5. Create and validate test scripts

Build scripts that reproduce complete user or system behavior rather than isolated requests.

Validate that scripts:

• send the correct parameters and headers;

• maintain sessions;

• extract and reuse dynamic values;

• handle authentication;

• check meaningful responses;

• use realistic pauses;

• report business transaction failures;

• clean up generated data where required.

Run the scripts with a very small load first. If one virtual user cannot complete the scenario correctly, increasing the load only creates misleading results faster.

6. Establish a baseline

Run a low-load test before executing larger scenarios. The baseline provides a reference for response times, throughput, and resource use when the system is not under pressure.

It also helps identify script defects, environment problems, and existing bottlenecks before concurrency complicates the investigation.

7. Execute tests incrementally

Avoid jumping directly to the maximum workload.

A typical sequence may include:

Monitor the application during every run. A response-time chart alone cannot explain whether the bottleneck is in the application, database, network, infrastructure, or an external service.

8. Analyze the results

Correlate user-facing symptoms with system telemetry.

For example:

• Rising response time plus saturated CPU may indicate compute-intensive processing.

• Rising latency with low CPU but exhausted database connections points elsewhere.

• Stable internal services with slow third-party calls suggest dependency risk.

• Increasing memory throughout a soak test may indicate a leak.

• Growing queue depth shows that work arrives faster than it can be processed.

Separate tool-generated errors from genuine application failures. Report the point at which performance began to degrade, not only the final result.

9. Optimize and rerun the same test

Changes may include query optimization, caching, connection-pool tuning, code improvements, asynchronous processing, load-balancer configuration, or infrastructure scaling.

Rerun the same validated workload after each meaningful change. Changing the script, data, environment, and application simultaneously makes comparisons unreliable.

Performance testing is complete only when the team can explain the bottleneck, verify the improvement, and confirm that the change did not create a different constraint.

Performance testing tools

Tool selection depends on protocols, programming languages, team skills, infrastructure, and reporting needs. The following options cover many common use cases.

The tool should not define the test strategy. A perfectly configured load generator will still produce weak evidence if the workload model, environment, or acceptance criteria are unrealistic.

See our comparison of the best load testing tools for a more detailed discussion of capabilities and selection criteria.

Performance testing by application type

The core process remains similar, but the workload model and metrics change depending on the product.

Web application performance testing

Web testing covers backend response time, page rendering, browser behavior, APIs, static assets, third-party scripts, caching, and Core Web Vitals.

A web application can have a fast API but still feel slow because of large images, excessive JavaScript, rendering delays, or third-party tags. Combine protocol-level load generation with browser-based measurement and real-user monitoring.

Our guide to web application performance testing explains how to test frontend and backend performance together.

Mobile application performance testing

Mobile performance depends on more than server capacity. Device hardware, operating-system versions, battery consumption, application startup time, network changes, background behavior, and local storage all affect the experience.

Test on representative physical devices and under Wi-Fi, 4G, 5G, weak-signal, high-latency, and interrupted-network conditions. Measure CPU, memory, battery, data transfer, startup time, rendering, and API behavior.

See the dedicated guide to mobile application performance testing for mobile-specific scenarios and metrics.

Banking application performance testing

Banking systems must combine speed with transaction accuracy, security, auditability, and resilience. Relevant workloads include salary runs, market events, bill-payment deadlines, interest calculations, batch processing, fraud checks, and third-party payment traffic.

A banking test must verify that transactions are not duplicated, lost, or left in an inconsistent state when the system slows down. Percentile latency, queue depth, database locks, error recovery, and idempotency are often more informative than average page-load time.

Our guide to performance testing for digital banking apps covers banking-specific workloads and benchmarks.

Common performance testing mistakes

Testing without measurable requirements

Without response-time, throughput, error-rate, and capacity targets, the team can collect data but cannot determine whether the system passed.

Using unrealistic workloads

A test that sends identical requests at a constant rate rarely represents actual user behavior. Include scenario distribution, pauses, session state, traffic peaks, and background processing.

Reporting averages only

Averages hide slow outliers. Report p50, p95, and p99 together with throughput and errors.

Ignoring the client side

Protocol tests can validate backend capacity but miss rendering delays, mobile resource use, and frontend JavaScript problems.

Testing in an unrepresentative environment

A small database, disabled integrations, different caching, or simplified infrastructure can make results misleading. Document every important difference from production.

Generating load from an insufficient machine

The load generator itself can become the bottleneck. Monitor its CPU, memory, network, and connection capacity separately from the application under test.

Skipping script validation

A script may report successful HTTP responses while the business transaction actually failed. Add response checks and validate generated data.

Treating every slowdown as an infrastructure problem

Adding servers cannot fix inefficient queries, lock contention, synchronous dependencies, or poor algorithms. Scaling should follow diagnosis.

Running performance tests only before launch

Performance regressions can be introduced by code, configuration, data growth, dependencies, and infrastructure changes. Run smaller checks regularly and schedule broader tests before high-risk releases or traffic events.

Failing to retest

A performance recommendation is only a hypothesis until the same workload confirms the improvement.

Build performance evidence before users generate it

Performance testing should answer a business decision: whether a system can support an expected workload, meet its SLA, survive a traffic spike, scale efficiently, or recover after overload.

Reliable answers require more than a load-generation tool. They depend on realistic workloads, representative environments, meaningful percentiles, system telemetry, and repeatable retesting.

If you need help defining workloads, finding bottlenecks, or validating capacity, explore DeviQA’s performance testing services.

See how your QA could grow with you

Schedule a call

Frequently asked questions

What is performance testing in software testing?

Performance testing in software testing is the evaluation of a system’s speed, responsiveness, stability, scalability, and resource efficiency under a defined workload. It is non-functional testing because it examines how the system operates rather than whether individual features produce the correct functional result.

What is the difference between load testing and performance testing?

Performance testing is the broader category. Load testing is one type of performance testing focused on behavior under an expected workload. Other types include stress, spike, soak, volume, scalability, and capacity testing.

What is software capacity testing?

Software capacity testing determines the maximum workload a system can support while meeting defined performance criteria. The result may be expressed as concurrent users, transactions per second, jobs per hour, data volume, or another workload measure relevant to the product.

Are there performance testing standards?

There is no single standard that prescribes universal response-time or throughput targets for every application. Targets must come from product requirements, user expectations, SLAs, regulations, and system context.

The ISO/IEC 25010:2023 product quality model includes performance efficiency as a software quality characteristic, while the ISO/IEC/IEEE 29119 series defines general software testing processes, documentation, and techniques. Industry-specific systems may also need to follow accessibility, financial, healthcare, telecommunications, or safety standards.

When should performance testing be performed?

Begin when critical workflows and architecture can be tested meaningfully, then continue throughout development. Run focused tests after performance-sensitive changes and broader tests before major releases, migrations, infrastructure changes, anticipated traffic peaks, or SLA reviews.

About the author

Anastasiia Sokolinska

Chief Operating Officer

Anastasiia Sokolinska is the Chief Operating Officer at DeviQA, responsible for operational strategy, delivery performance, and scaling QA services for complex software products.