What is Endurance Testing in Software Testing? (with Example)

By : Thomas Hamilton Thomas Hamilton
Hours Updated

⚡ Smart Summary

Endurance Testing runs an application under a normal expected load for an extended period to reveal whether performance degrades over time. It is the test that catches the defects a one-hour load run cannot reach.

  • 🕒 Sustained Load: Expected production traffic held for hours or days rather than minutes.
  • 📉 Degradation Focus: The question is whether response times drift upward, not whether the target is met once.
  • 💧 Common Findings: Memory leaks, connection pool exhaustion, and unbounded log or cache growth.
  • 📊 Monitoring Set: Memory, CPU, response time, throughput, and database connections across the full run.
  • 🛠️ Tooling: Standard load tools drive the traffic while APM tooling records the resource curves.
  • ⚖️ Trade-off: Results are high value but slow to obtain, which limits how often the test can run.
Read More

What is Endurance Testing

What is Endurance Testing?

Endurance Testing is non-functional type of software testing where a software is tested with high load extended over a significant amount of time to evaluate the behavior of software application under sustained use. The main purpose of endurance testing is to ensure that the application is capable enough to handle extended load without any deterioration of response time.

This type of testing is performed at the last stage of the performance run cycle. Endurance testing is a long process and sometimes lasts for even up to a year. This may include applying external loads such as Internet traffic or user actions. This makes endurance testing differ from Load Testing, which usually ends in a couple of hours or so.

Endurance means capacity so in other words, you can term Endurance Testing as Capacity Testing.

Goals of Endurance Testing

  • Primary goal of Endurance testing is to check for memory leaks.
  • To discover how the system performs under sustained usage.
  • To ensure that after a long period, the system response time will remain the same or better than the start of the test.
  • To determine the number of users and/or transactions a given system will support and meet performance goals.
  • To manage the future loads, we need to understand how many additional resources (like processor capacity, disk capacity, memory usage, or network bandwidth) are necessary to support usage in future.
  • Endurance testing is generally done by either overloading the system or by reducing certain system resources and evaluating the consequences.
  • It is performed to ensure that defects or memory leaks do not occur after what is considered to be a relatively “normal” usage period.

What to Monitor in Endurance Testing

Endurance Testing

In Endurance Testing following things are tested.

  • Test memory leakage– Checks are done to verify if there is any memory leakage in the application, which can cause crashing of the system or O.S.
  • Test connection closure between the layer of the system – If the connection between the layers of the system is not closed successfully, it may stall some or all modules of the system.
  • Test database connection close successfully– If the database connection is not closed successfully, may result in system crash
  • Test response time – System is tested for the response time of the system as the application becomes less efficient as a result of the prolonged use of the system.

How to Perform Endurance Testing

Below is the basic testing approach for Endurance Test

  • Testing Environment – Identify the hardware, software, operating system require for the endurance testing, assigning roles and responsibilities within the team, etc. The environment should be ready before the test execution. You also need to estimate common database production size and yearly growth. This is required as such you need to test how your application will respond after a year, two or five.
  • Creating the Test Plan, Scenarios – Based on nature of testing – manual or automation or combination of both, Test Case design, reviews, and execution should be planned. Testing to stress the system, break point testing, etc. should also be part of the test plan. Testing to stress the system determines the break point in the application.
  • Test Estimation – Provide the estimation of how long it will take to complete the testing phase. It should be analyzed on the basis of a number of testers involved and the number of test cycles required.
  • Risk Analysis – Analyzing the risk and taking an appropriate action for the prevention. Prioritization of test cases as per the Risk factor and identify the below risk and issues tester may phase during the endurance test.
  • Will performance remain consistent over time?
  • Are there other minor issues that have not yet been detected?
  • Is there external interference that was not addressed?
  • Test Schedule – Determine the budget, deliverables within the time frames. As Endurance Testing applies a huge but natural load arrangement of transactions to the system/application for a continuous period of time.

Endurance Testing Example

While Stress testing takes the tested system to its limits, Endurance testing takes the application to its limit over time.

For Example, the most complex issues – memory leaks, database server utilization, and unresponsive system – happen when software runs for an extended period of time. If you skip the endurance tests, your chances of detecting such defects prior to deployment are quite low.

Endurance Testing Tools

RELATED ARTICLES

Advantages of Endurance Testing

  • It helps in determining how workload can the System Under Load handle.
  • Provides accurate data that customer can use to validate or enhance their infrastructure needs.
  • Identifies performance problems that may occur after a system has been running at a high level for longer period of time
  • Typical issues are identified in smaller targeted performance tests, which means it ensures application remain available even when there is huge load in a very short span time.
  • The endurance test is also used to check whether there is any performance degradation after a long period of execution

Disadvantages of Endurance Testing

  • It is often hard to define how much stress is worth applying.
  • Endurance Testing could cause application and/or network failures that may result in significant disruption if Test Environment are not isolated.
  • Permanent Data loss or corruption can occur by over-stressing the system.
  • Resource utilization remains very high after the stress is removed.
  • Some application components fail to respond.
  • Unhandled exceptions are observed by the end user.

How This Test Fits the Performance Testing Family

Performance testing is an umbrella term. The variants below differ only in the shape of the load applied and the duration it is held for, which is why they are so often confused with one another.

Test type Load pattern Question it answers
Load testing Expected peak load, short duration Does the system meet its targets under normal peak traffic?
Stress testing Increased beyond capacity until failure Where does it break, and does it fail gracefully?
Spike testing Sudden extreme surge, then withdrawal Does it survive and recover from a traffic shock?
Endurance testing Normal load held for many hours Does performance degrade over time?
Soak testing Sustained load over an extended period Are there memory leaks or resource exhaustion?
Stability testing Varying load across conditions Does the system stay reliable as conditions change?
Volume testing Normal users, very large data volume Does it cope as the database grows?

Endurance and soak testing are frequently treated as synonyms. In common usage they are: both hold a sustained load for a long period. Where teams do distinguish them, endurance testing focuses on whether response times drift upward, while soak testing focuses on resource consumption such as memory, file handles, and connection pools. Running one usually gives you the evidence for both.

Key Metrics to Capture During the Test

A performance run is only as good as what you record while it executes. Capture these six on the server and the client side, then compare them against the baseline rather than against a gut feeling.

Metric What it tells you Warning sign
Average response time Typical user experience Any upward drift across the run
95th percentile response time The experience of the slowest users Far above the average, meaning inconsistency
Throughput Requests handled per second Falling while load stays constant
Error rate Share of failed or timed-out requests Any rise above the agreed threshold
CPU and memory use Server resource headroom Memory that climbs and never returns
Database connections and threads Pool exhaustion Counts that grow steadily without release

Read the average and the percentile together. An average of 800 ms with a 95th percentile of 900 ms describes a consistent system. The same average with a 95th percentile of 9 seconds means one user in twenty is having a bad time, and the average is hiding it.

Watch the shape, not just the value. In any long-running test, a flat resource line is a pass and a rising one is a leak, even when the absolute number is still comfortably inside the limit at the moment the run ends.

Endurance Testing: Key Takeaways

  • In Software Engineering, Endurance testing is a subset of load testing.
  • Endurance testing is a long process and sometimes last for even up to a year
  • Checks are done to verify
  • Test memory leakage
  • Test response time
  • Test database connection, etc.

FAQs

Load testing verifies the system meets its targets at peak load over a short run. Endurance testing holds a normal load for hours to reveal whether those targets still hold at the end of the run.

Any sustained upward trend in response time or resource use, even if no threshold is breached. The defect is the drift itself, because it will eventually cross the limit in production.

After functional and load testing pass, and early enough that a discovered leak can still be fixed. Running it the night before release leaves no time to act on the result.

AI-based monitoring detects the point at which a metric changes trend and correlates it with deployments or scheduled jobs, turning hours of graphs into a specific suspect.

It can help prioritise. Risk models highlight which releases touch leak-prone code, so full runs are reserved for the changes most likely to need them.

Summarize this post with: