4、长时间运行测试（Soak Testing）：设计7x24小时测试方案、日志记录策略、关键性能指标（KPI）的持续采集
4.1 为什么7x24小时测试如此重要？
说实话，很多团队在语音系统测试时，跑个一两个小时没问题就急着上线了。我见过太多这样的案例——测试环境一切正常，上线三天后系统开始卡顿，一周后直接崩溃。
为什么会这样？因为语音系统有个特点：资源泄漏是慢慢积累的。内存泄漏、线程泄漏、句柄泄漏，这些在短时间测试里根本看不出来。你想想看，一个语音识别服务，每处理一次请求就泄漏1KB内存，一小时可能才泄漏几MB，但跑上24小时呢？那就是几十GB。
我个人习惯，任何语音系统上线前，必须跑满7x24小时的Soak Testing。这不是拍脑袋定的，而是我在项目中吃过亏后总结出来的铁律。
核心原则：Soak Testing不是简单的「跑着别停」，而是要在长时间运行中持续验证系统的稳定性、资源回收能力和性能衰减趋势。
4.2 7x24小时测试方案设计
4.2.1 测试场景设计
嗯，这里要注意，Soak Testing的场景不能太单一。我建议至少包含以下三类场景：
- 稳态场景（占60%）：模拟正常业务负载，比如每分钟50次语音识别请求，每次请求时长3-5秒。这是系统最常面对的情况。
- 峰值场景（占20%）：模拟业务高峰，比如每分钟200次请求，持续15分钟。我在项目中遇到过，有些系统平时跑得挺好，一到峰值就崩。
- 异常场景（占20%）：模拟网络抖动、音频质量差、并发超时等情况。说白了，就是要看看系统在「被折腾」的时候能不能自己恢复。
4.2.2 测试执行策略
我一般这样安排7x24小时的执行节奏：
| 时间段 | 执行内容 | 监控重点 |
|---|---|---|
| 0-2小时 | 稳态场景 + 基线采集 | 建立性能基线（CPU、内存、响应时间） |
| 2-6小时 | 稳态场景 | 观察资源使用趋势，是否有缓慢增长 |
| 6-8小时 | 峰值场景（模拟早高峰） | 峰值下的资源消耗和恢复能力 |
| 8-20小时 | 稳态场景 + 随机异常注入 | 长时间运行下的稳定性 |
| 20-22小时 | 峰值场景（模拟晚高峰） | 对比早高峰数据，看是否有性能衰减 |
| 22-24小时 | 稳态场景 + 最终数据采集 | 对比基线，评估系统健康度 |
我的小技巧：在测试开始前，先跑一次「干跑」——不加载任何业务逻辑，只启动系统。这样能排除系统本身启动时的资源消耗干扰，拿到更干净的基线数据。
4.3 日志记录策略
日志记录是Soak Testing的命脉。没有好的日志，你根本不知道系统在哪个时间点出了什么问题。我曾经有一次7x24小时测试跑完了，发现日志只记录了「正常」两个字，那叫一个崩溃。
4.3.1 日志分级策略
我建议采用三级日志策略：
- ERROR日志：记录所有异常、超时、失败请求。必须包含时间戳、请求ID、错误码、堆栈信息。
- WARN日志：记录资源使用接近阈值、响应时间变慢、重试次数增多等情况。这些是系统可能出问题的前兆。
- INFO日志：记录每个请求的开始和结束，包含处理时长、资源消耗。注意，INFO日志要控制频率，别把磁盘写爆了。
4.3.2 日志轮转策略
7x24小时测试会产生海量日志。我见过有人把日志写满了磁盘，导致系统直接挂掉。所以日志轮转必须提前设计好：
# 日志轮转配置示例
log_rotation:
max_file_size: 100MB # 单个日志文件最大100MB
max_backup_files: 10 # 保留最近10个备份
compress: true # 压缩历史日志
delete_after: 7d # 7天前的日志自动删除
注意：日志轮转本身也会消耗资源。我建议在测试开始前先验证日志轮转功能是否正常，别等到磁盘满了才发现轮转没生效。
4.4 关键性能指标（KPI）的持续采集
KPI采集是Soak Testing的核心。说白了，你要通过数据来判断系统是不是「健康」的。我一般把KPI分成三类：
4.4.1 系统级KPI
| 指标 | 采集频率 | 告警阈值 | 说明 |
|---|---|---|---|
| CPU使用率 | 1秒 | > 80% 持续5分钟 | 过高可能表示资源泄漏或负载异常 |
| 内存使用量 | 1秒 | 持续增长超过24小时 | 内存泄漏的典型信号 |
| 磁盘I/O | 5秒 | > 90% 利用率 | 日志写入可能成为瓶颈 |
| 网络连接数 | 5秒 | 连接数持续增加不释放 | 连接泄漏的征兆 |
| 句柄数 | 10秒 | 持续增长超过12小时 | 文件句柄泄漏 |
4.4.2 业务级KPI
- 平均响应时间：正常应在200ms以内，超过500ms需要关注。我习惯看P50、P95、P99三个分位值。
- 请求成功率：应保持在99.9%以上。注意，这里要区分「系统错误」和「业务错误」。
- 并发处理能力：记录最大并发数，看系统在长时间运行下是否出现性能衰减。
- 音频处理质量：比如语音识别的准确率、合成音频的MOS分。这些指标在长时间运行后可能会下降。
4.4.3 趋势分析KPI
这部分是我特别看重的。单点数据说明不了问题，趋势才能暴露问题：
# 趋势分析示例：内存使用趋势
# 每10分钟采集一次内存使用量
# 计算线性回归斜率
# 如果斜率 > 0.01（每小时增长超过1%），触发告警
def check_memory_trend(memory_data):
"""
检查内存使用趋势
memory_data: 最近24小时的内存使用数据
"""
slope = calculate_linear_regression_slope(memory_data)
if slope > 0.01:
return "WARNING: 内存持续增长，可能存在泄漏"
elif slope > 0.005:
return "INFO: 内存有轻微增长趋势，建议关注"
else:
return "OK: 内存使用稳定"
我的经验：不要只看平均值。我遇到过内存使用平均值很稳定，但P99值一直在涨的情况。后来发现是某个线程池在慢慢泄漏，但被其他线程回收掩盖了。所以，分位值比平均值更能暴露问题。
4.5 测试结果评估标准
7x24小时跑完后，怎么判断系统是否通过？我一般用这个标准：
- 零崩溃：整个测试期间没有出现进程崩溃或重启。
- 资源稳定：CPU、内存、句柄等资源在测试结束时与开始时相比，增长不超过10%。
- 性能不衰减：测试最后1小时的响应时间与测试开始1小时相比，增长不超过5%。
- 日志完整：所有请求都有对应的日志记录，没有丢失。
- 自动恢复：异常场景注入后，系统能在30秒内自动恢复到正常状态。
避坑指南：我曾经遇到过一个系统，7x24小时测试全部通过，但上线后第三天就崩了。后来发现是测试环境的内存是生产环境的2倍，资源泄漏在测试环境被「掩盖」了。所以，测试环境一定要和生产环境保持一致，尤其是内存、CPU、磁盘这些关键资源。
好了，关于7x24小时Soak Testing的设计，我就讲这么多。记住一句话：短时间测试看功能，长时间测试看稳定性。下一章我会讲如何通过日志和KPI数据快速定位问题根因，到时候见。