可靠性测试实战手册

先说人话

功能测试关心「功能是否按要求实现」，可靠性测试关心「系统在异常、压力和时间考验下是否还能持续正确地提供服务」。对支付系统来说，一次扣款重复、一次重启丢账，比界面丑一百倍都严重。

与功能、性能测试的区别

可靠性不等于性能

• 性能好只说明负载下响应快，不代表断电重启后数据不丢。
• 可靠性是时间维度的属性：短期全对，长期可能因泄漏而崩。
• 性能测试压力大、时间短；可靠性测试压力常态、时间长、伴随故障。
• 高可用是设计出来的，也是长期演练验证出来的。

核心指标与金融系统参考阈值

重点盯四类缓慢恶化

• 内存与连接泄漏：堆、线程、连接池、文件句柄逐小时增长。
• 日志与磁盘增长：日志轮转失效或过期数据不清理会拖垮磁盘。
• 定时任务漂移：任务越跑越慢、越跑越乱，触发点不断后移。
• 资源回收失效：缓存、临时文件、线程池队列只进不出。

时长与场景怎么选

典型故障场景

注入纪律

• 先生产后测试：每次只注入一个故障，观察完整影响面再注入下一个。
• 全程可回滚：混沌工具要支持秒级撤销，避免演练变真事故。
• 结合真实架构：在容器、K8s、网关各层分别演练，而不只在应用层。
• 每次注入都要留证据：时间线、指标曲线、日志与告警一一对应。

常见恢复场景

恢复验证两个要点

• 时间要量：RTO/RPO 是硬指标，切换、重启、恢复都要计时并留趋势。
• 数据要对平：恢复完成后必须跑对账，账平才算真正恢复。

降级手段

验证降级时的支付语义

• 降级不能破坏幂等：限流放行的请求依旧按原订单号去重。
• 兜底页面要让用户知道钱的状态：支付中、成功、失败都要可查。
• 熔断后要有恢复路径：半开试探、限流放量，而不是一键全开。

数据可靠性验证点

与数据质量测试的衔接

• 数据质量测试管「数据本身对不对」：字段、格式、关联、完整性约束。
• 数据可靠性测试管「故障下数据会不会丢、会不会错」：断电、重启、重复投递。
• 先过数据质量，再做可靠性：脏数据场景会放大故障注入时的异常表现。
• 对账脚本既是质量检查，也是可靠性验证，建议两者复用同一套规则。

方案六步

1. 基于风险与变更选场景：核心链路、高风险组件、历史故障点优先。
2. 确定时长与负载模型：结合业务峰谷与真实流量回放，避免空转。
3. 定义监控指标与基线：可用性、错误率、资源水位、依赖健康度。
4. 设定通过标准：指标阈值 + 故障注入后的恢复要求逐项写明。
5. 明确停止条件：致命缺陷、资损风险、长时间无法恢复时立即叫停。
6. 规划回归：修复缺陷后重跑故障场景，并与基线对比。

方案里必须写清的五个要素

• 场景选取：为什么选这个场景，对应什么业务风险。
• 测试时长：短跑和长跑分别覆盖什么。
• 监控指标：每个指标的数据来源与采集频率。
• 通过标准：数字说话，不能写「基本正常」。
• 停止条件：什么情况下立刻终止并上报，避免演练扩大化。

报告结构

缺陷怎么归类

• 资源类：泄漏、耗尽，通常伴随内存、连接数曲线单调上涨。
• 代码类：竞态、重试风暴、死循环，通常在某次注入后被放大。
• 依赖类：第三方超时、中间件切换，通常表现为上游症状。
• 数据类：幂等缺失、脏数据，通常在对账和重放时暴露。