前言：为什么我们需要关注耐久性测试？
作为一名软件工程师或测试人员，你可能遇到过这样的情况：在开发环境中运行完美的应用，上线运行几天后却莫名其妙地变慢，甚至直接崩溃。这往往不是功能性的错误，而是系统在长时间运行下暴露出的稳定性问题。
这时候，我们就需要进行耐久性测试。
在本文中，我们将深入探讨耐久性测试的核心概念。我们将一起学习它是什么，为什么它与普通的压力测试不同，以及我们如何在项目中实际编写代码、执行测试并分析结果。我们将通过实际的代码示例和最佳实践，帮助你掌握确保系统长期稳定运行的技能。
> 阅读前必读：这是性能测试系列的一部分，如果你对性能测试的基础（如负载测试）还不熟悉，建议先了解一下相关概念，以便更好地理解本文的内容。
什么是耐久性测试？
定义与核心目标
耐久性测试，通常也被称为浸泡测试，是一种非功能性测试类型。简单来说，它的目的是验证系统在持续较长时间（通常是数小时、数天甚至数周）的高负载运行下，是否能保持稳定、高效，并且不会出现性能退化。
让我们想象一下：普通的负载测试可能只持续30分钟到1小时，旨在验证系统在峰值负载下的响应能力。而耐久性测试则更像是马拉松，它关注的是系统在“长跑”过程中的表现。我们要观察的是，当系统运行了24小时后，内存占用是否呈线性增长？是否存在没有关闭的连接？垃圾回收（GC）是否变得越来越频繁？
耐久性测试 vs. 其他测试
为了更清晰地理解，我们可以将耐久性测试与压力测试做一个简单的区分：
- 压力测试：试图通过不断增加负载，直到系统崩溃，以找到系统的极限上限。它关注的是“峰值承受力”。
- 耐久性测试：使用预期的正常或略高于正常的负载，持续运行很长时间。它关注的是“长期稳定性”。
关键检测指标
在执行耐久性测试时，我们通常会重点监控以下几个指标，以发现潜在的故障点：
- 内存泄漏：这是最主要的目标。我们观察内存使用量是否随时间无限增长，而从不回落。
- 数据库连接池泄漏：检查连接是否在请求结束后正确释放。
- 响应时间退化：系统在运行初期可能响应很快，但随着时间推移，响应时间是否显著增加。
- 磁盘空间与I/O：日志文件是否写满了磁盘？缓存数据是否溢出？
耐久性测试为何如此重要？
你可能会问：“我的系统已经通过了压力测试，为什么还需要做耐久性测试？”
这是因为某些缺陷只在特定的时间维度上才会显现。例如，一个未被关闭的线程在单次请求中微不足道，但在处理了100万次请求后，可能会导致线程池耗尽。耐久性测试对于确保生产环境的可靠性至关重要，它能帮助我们在用户受影响之前，发现那些隐蔽的性能瓶颈和资源耗尽问题。
耐久性测试流程详解
为了有效地进行测试，我们需要遵循一套严谨的流程。让我们一步步来看如何搭建和执行。
1. 建立测试环境
首先，我们需要确保测试环境尽可能模拟真实的生产环境。
- 硬件配置：服务器的CPU、内存、硬盘大小应与生产环境保持一致，或至少成比例缩小。
- 软件配置：操作系统版本、数据库版本、网络带宽等都需要对齐。
- 数据隔离：确保测试数据不会污染生产数据，同时数据量级（如数据库初始行数）也应模拟真实情况。
2. 创建测试计划
在这一步，我们需要定义详细的测试策略。这不仅仅是写个脚本，而是要明确：
- 测试时长：我们要跑多久？通常建议至少持续24小时到72小时。
- 负载模型：我们要模拟多少用户？这些用户在做什么（浏览、下单、查询）？
- 成功标准：内存增长不超过X%？响应时间不超过Y秒？系统不能出现崩溃。
3. 测试评估与工具选择
在开始之前，我们还需要评估所需的软硬件资源。选择合适的自动化工具是成功的关键。
#### 常用工具推荐
- Apache JMeter：开源、免费，功能强大，非常适合编写复杂的负载脚本。
- LoadRunner：企业级工具，功能全面，支持多种协议。
- Gatling：基于Scala，性能强劲，适合生成高并发。
- K6：基于Go和JavaScript，开发者友好，适合CI/CD集成。
实战演练：代码与脚本示例
理论讲多了容易枯燥，让我们通过实际的代码和脚本来看看如何做。我们将结合监控脚本来演示如何发现问题。
场景一：模拟内存泄漏的 Java 程序
为了演示耐久性测试能发现什么，我们首先故意写一段有“Bug”的代码——一个会发生内存泄漏的简单 Java 服务。
import java.util.ArrayList;
import java.util.List;
public class LeakyService {
// 故意使用静态 List 来模拟长生命周期的对象存储
// 如果数据只进不出，就会导致内存泄漏
private static List memoryLeakBucket = new ArrayList();
/**
* 模拟处理请求的方法
* 每次处理都会加载 10MB 的数据并“不小心”保留在内存中
*/
public void handleRequest() {
// 模拟分配内存 (每次 10MB)
byte[] dataChunk = new byte[10 * 1024 * 1024];
// 故意的 Bug：将数据放入静态集合中，且从不清理
// 在实际业务中，这可能是未清理的缓存、监听器或未关闭的连接
memoryLeakBucket.add(dataChunk);
System.out.println("Request processed. Current leaked items: " + memoryLeakBucket.size());
}
public static void main(String[] args) throws InterruptedException {
LeakyService service = new LeakyService();
// 模拟系统运行，不断处理请求
while (true) {
service.handleRequest();
// 稍微休眠一下，模拟请求间隔
Thread.sleep(500);
}
}
}
代码解析：
在这个例子中，INLINECODEb25e16c0 方法每秒会被调用两次。每次调用都会分配 10MB 的内存并添加到静态列表中。随着时间推移，堆内存会被填满，最终导致 INLINECODE3c8ec9bb。普通的单元测试可能不会发现这个问题，因为单次测试内存占用很少，但耐久性测试运行几分钟后就能看到内存飙升。
场景二：使用 JMeter 进行耐久性测试脚本编写
现在，让我们看看如何使用 Apache JMeter 来对上述应用进行测试。
JMX 结构建议：
- Thread Group (线程组)：设置线程数为 50（模拟50个并发用户）。
- Loop Count (循环次数)：设置为“永远”，因为我们要测试的是耐久度，直到我们手动停止。
- Duration Assertion (持续时间断言)：虽然不需要断言来决定结束，但我们需要在测试计划中设置一个预期时长，比如 24 小时。
简单的 JMeter 测试计划逻辑：
你可以创建一个 HTTP 请求默认值，指向你的本地 Java 应用端口（如果有暴露 REST 接口）。或者，更直接的方式是配合监控工具观察系统资源。
86400
10
场景三：自动化监控脚本 (Python)
在进行耐久性测试时，光有负载是不够的，我们还需要监控。下面是一个简单的 Python 脚本，用于监控 Java 进程的内存使用情况。
这个脚本模拟了我们在测试过程中需要持续做的事情：记录数据以便后续分析。
import psutil
import time
import matplotlib.pyplot as plt
def monitor_memory(duration_seconds, interval_seconds, pid_to_monitor):
"""
监控特定进程的内存使用情况
:param duration_seconds: 总监控时长
:param interval_seconds: 采样间隔
:param pid_to_monitor: 要监控的进程ID
"""
data_points = []
timestamps = []
start_time = time.time()
# 查找进程
try:
process = psutil.Process(pid_to_monitor)
print(f"开始监控进程 {pid_to_monitor}...")
except psutil.NoSuchProcess:
print("未找到指定的进程！")
return
while True:
current_time = time.time()
if current_time - start_time > duration_seconds:
break
# 获取 RSS (Resident Set Size) 内存占用，单位 MB
mem_info = process.memory_info()
mem_mb = mem_info.rss / (1024 * 1024)
data_points.append(mem_mb)
timestamps.append(current_time - start_time)
print(f"[运行时长: {int(current_time - start_time)}s] 内存占用: {mem_mb:.2f} MB")
time.sleep(interval_seconds)
# 简单的可视化 (可选)
plt.figure(figsize=(10, 5))
plt.plot(timestamps, data_points, label=‘Memory Usage (MB)‘)
plt.xlabel(‘Time (seconds)‘)
plt.ylabel(‘Memory (MB)‘)
plt.title(‘Endurance Test: Memory Leak Detection‘)
plt.grid(True)
plt.savefig(‘endurance_result.png‘)
print("监控结束，图表已保存为 endurance_result.png")
# 示例：假设我们的 Java 应用 PID 是 12345，运行 600 秒 (10分钟)
# 注意：你需要将 12345 替换为你实际运行 LeakyService 的 PID
if __name__ == "__main__":
# 实际使用时请替换 PID
# monitor_memory(600, 5, 12345)
pass
如何验证：
- 运行上面的 Java 程序。
- 获取该 Java 进程的 PID（可以使用
jps命令或任务管理器）。 - 运行 Python 脚本。
- 观察控制台输出的内存占用是否持续上升。在耐久性测试中，你会看到一条陡峭上升的曲线，这明确指示了内存泄漏的存在。
场景四：数据库连接池模拟
除了内存，数据库连接也是耐久性测试的重点。让我们看一段可能导致连接池耗尽的伪代码。
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
public class DBService {
public void processData() {
Connection conn = null;
try {
// 获取数据库连接
conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/test", "user", "pass");
// 执行业务逻辑...
} catch (SQLException e) {
e.printStackTrace();
} finally {
// 故意的 Bug：在这里忘记调用 conn.close()
// 在长时间运行下，连接池会被占满，新的请求将无法获取连接
System.out.println("Processing complete (but connection not closed).");
}
}
}
实战建议：在耐久性测试中，我们不仅要监控 CPU 和内存，还要监控数据库的 INLINECODE8905eb70 或当前连接数。如果连接数随着测试时间线性增长直至达到最大值，说明代码中存在连接泄漏。修复方法是确保在 INLINECODE92fc44cf 块中关闭连接，或者使用 try-with-resources 语法。
最佳实践与性能优化建议
在我们的实战经验中，仅仅跑测试是不够的，如何跑测试以及如何分析同样重要。以下是我们总结的一些实用见解：
1. 渐进式增加负载
不要一开始就给系统施加 100% 的负载。我们可以先在 50% 的负载下运行 4 小时，然后再增加到 75%。这有助于我们在问题变得复杂之前定位早期的瓶颈。
2. 监控是核心
测试不是一劳永逸的。我们建议在测试期间保持实时的监控仪表盘（如 Prometheus + Grafana）。重点关注：
- Heap Usage (堆内存使用率)
- GC Frequency (垃圾回收频率)：如果 Full GC 越来越频繁，说明系统在苟延残喘。
- Thread Count (线程数)
3. 自动化恢复
耐久性测试往往在夜间或周末进行。我们需要设定自动化的报警机制（如邮件或钉钉通知），一旦系统崩溃或指标异常，立即通知团队，而不要等到周一早上才发现测试失败了。
4. 区分“慢”与“停”
在分析结果时，要区分响应变慢是因为网络波动还是系统资源耗尽。耐久性测试更关注系统在“稳定”状态下的资源消耗趋势，而不是瞬时的网络抖动。
总结与后续步骤
通过本文的探索，我们了解到耐久性测试不仅仅是“让程序多跑一会儿”，它是一门关于发现和解决系统深层隐患的技术。我们通过定义、对比、流程分析以及具体的 Java 和 Python 代码示例，掌握了如何在实际项目中应用这一测试手段。
关键要点回顾：
- 目的：发现内存泄漏、连接泄漏和长时间运行后的性能退化。
- 方法：模拟真实负载，持续运行长时间（24小时+）。
- 工具：JMeter 负责施压，代码级监控和系统工具负责观察。
- 心态：我们要像医生一样，通过长期的监测数据来诊断系统的慢性病。
作为下一步，我们建议你：
- 审查你的现有系统：检查代码中是否有未关闭的流或连接。
- 引入自动化监控：搭建 Grafana 仪表盘来可视化你的 JVM 或应用性能。
- 执行一次小型耐久性测试：选择一个非核心服务，尝试运行 12 小时的稳定性测试，看看会有什么惊喜（或惊吓）。
耐久性测试是保障生产环境高可用性的最后一道防线。希望这篇文章能帮助你在构建稳健软件的道路上更进一步。让我们一起构建更稳定、更可靠的系统吧！