可靠性测试核心目标：验证系统在长时间运行、高负载、异常输入、故障扰动、业务持续迭代下，维持规定功能、性能、数据一致性的能力，重点关注：稳定性、容错性、恢复能力、失效概率、平均无故障时间 MTBF。 可靠性不是单独一轮测试，是贯穿需求、设计、开发、测试、上线全流程的活动，不只是压测、稳定性跑脚本。
一、前期准备：明确可靠性基线与指标
没有指标，可靠性测试就没有判定标准。
1. 拆解可靠性需求，定义可量化指标
从业务、非功能需求提取，写入测试计划：
注意：区分核心业务链路和非次要功能，可靠性资源优先保障核心链路。
2. 识别可靠性风险点
梳理风险清单，作为测试重点：
资源类：内存泄漏、连接泄露、线程池耗尽、文件句柄打满、磁盘满
依赖类：数据库、缓存、MQ、第三方接口超时、宕机、限流
并发类：高并发、大流量、长事务、锁竞争
故障场景：网络丢包、断网、进程 crash、实例重启、节点宕机
业务：批量任务、定时任务、大数据导入导出、重复提交、重试风暴
3. 测试环境要求
可靠性测试不能直接在生产做，测试环境尽量仿真生产配置：
硬件、CPU / 内存、实例数量、中间件版本尽量对齐生产；
数据量要接近生产量级（存量历史数据），小批量环境跑稳定性没有参考意义；
支持故障注入：网络延迟、丢包、进程 kill、磁盘占满；
完整监控：JVM、CPU、内存、连接数、句柄、GC、数据库慢 SQL、错误日志、业务报错率。
二、可靠性测试主要类型与落地方法
1. 稳定性测试（耐久测试）
目的：长时间持续运行，发现内存泄漏、连接泄露、线程泄露、定时任务资源累积问题。
执行方式：混合真实业务场景，持续加压，72h / 7 天不间断运行；流量为日常峰值或者预期峰值；
观测重点：
内存是否持续上涨不回收，连接数持续增长；
GC 频率、FullGC 次数；
文件句柄、数据库连接、TCP 连接；
错误率、响应时间是否逐步恶化；
定时任务、批处理是否有资源未释放。
停止判定：出现业务错误、资源持续泄漏，或达到预设运行周期，无异常则通过。
2. 压力 / 负载可靠性测试
区别普通性能压测：不追求最大 TPS，关注长时间处于负载下系统是否稳健。
基准负载：日常业务负载持续跑；
峰值负载：业务峰值持续运行；
过载负载：略高于设计上限，验证系统拒绝策略、保护机制，不能直接雪崩。
3. 容错与故障注入测试（混沌测试核心）
模拟真实世界故障，验证系统容错、降级、熔断、恢复能力，是可靠性测试非常关键的一环。 常见故障场景：
依赖故障
数据库：慢查询、连接打满、实例重启；
Redis/MQ：宕机、超时、消息堆积；
第三方接口：超时、返回错误、限流。
验证：熔断是否生效，不会无限重试导致雪崩，业务友好降级，不连锁失败。
网络故障：网络延迟、丢包、断网后恢复；
系统故障：kill 进程、实例宕机、磁盘打满、CPU 打满；
测试重点：故障发生时业务表现；故障恢复后系统能否自动恢复，数据有没有错乱丢失。
建议从小范围开始，先单组件故障，再多组件组合故障，不要盲目搞大规模混沌。
4. 恢复性测试
验证故障发生之后的恢复能力：
进程崩溃后自动重启，业务是否正常；
主从切换、实例迁移，业务中断时长是否满足 MTTR；
断电、异常终止后重启，数据完整性校验；
消息堆积后，消费恢复，不能重复消费、丢失消息。
5. 数据可靠性测试
容易被忽略，但事故高发：
并发 + 异常中断下，事务一致性；
大批量导入、导出、定时任务异常中断，数据不残缺；
重试、幂等性测试：重复请求不能产生脏数据；
备份恢复测试：备份文件真实可用，恢复后业务可跑。
6. 边界与异常输入可靠性
海量异常参数、超长报文、非法请求，验证不会崩溃、内存暴涨。
三、测试执行流程
测试计划：明确指标、范围、环境、监控项、执行周期、通过 / 失败判定准则；
前置校验：功能、基础性能先过，不要带着已知 BUG 跑可靠性，浪费时间；
基线采集：采集正常状态 CPU、内存、GC、连接数作为基准；
执行测试：稳定性耐久、负载、故障注入、恢复测试；
持续观测：不仅看接口通不通，重点看系统内部资源指标；记录所有报错、告警；
事后分析
失败：定位根因（内存泄漏？没有熔断？连接未关闭？事务问题？），提交缺陷；
通过：输出可靠性测试报告，记录 MTBF、MTTR，风险与遗留隐患；
回归：BUG 修复完成后，针对场景重新做可靠性回归。
四、容易踩坑的实践问题
❌ 使用小数据量、低配环境跑 72h 稳定性：结果无效，很多泄露、慢 SQL 只有大数据量才暴露；
❌ 只看接口返回 200，忽略系统资源：接口正常，但是内存持续泄漏，上线运行几天就崩；
❌ 不做故障注入，只跑正常业务场景：很多可靠性问题只有故障发生才显现；
❌ 可靠性测试放到项目最后阶段：后期改架构成本极高，可靠性需求应该在设计阶段就考虑；
❌ 忽略定时任务、后台批任务：大量线上故障来自后台任务内存、线程泄露；
❌ 缺少幂等、重试策略，没有熔断降级：依赖出问题直接拖垮整个系统。
五、研发、测试、运维协同保障
可靠性不是测试单方面的责任：
需求设计阶段：架构设计就要考虑降级、熔断、重试、超时、资源隔离，而不是靠测试发现后补；
开发编码：资源释放，避免内存 / 连接泄漏；合理设置超时时间；实现幂等；线程池限制；
CI/CD 左移：单元测试、接口测试加入简单异常场景；代码审计检查资源泄露风险；
测试：执行可靠性、混沌测试；输出可靠性报告；
运维：线上监控告警、限流防护、备份预案；小范围线上混沌演练。
六、输出交付物
可靠性测试方案（指标、范围、环境、场景）
可靠性测试报告：MTBF、MTTR 结果，各场景测试结果，资源监控截图，发现缺陷，遗留风险，上线建议。
七、简单落地建议（中小项目）
如果团队资源有限，不用追求大型混沌平台，优先做高收益动作：
核心链路做72 小时混合业务稳定性测试，重点盯内存、连接、GC；
对外部依赖做故障模拟：第三方超时、Redis 挂掉，看系统会不会雪崩；
验证进程重启、实例重启后业务和数据是否正常；
重点校验定时任务、批量处理程序；
备份恢复一定要实际跑一遍。
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢