Day30-16｜9.5.4 可靠性测试的实施：把测试方案转化为可审计的运行证据

一、教材定位

可靠性测试的实施，是把测试目标、运行剖面和测试用例真正放入环境中执行，并对过程、结果和异常进行控制。前面已经完成了运行剖面定义和测试用例设计，但如果执行过程缺乏基线、监控、故障控制和数据治理，最终结果仍然可能不可信。可靠性测试不是启动脚本后等待一个通过标志，而是一个需要持续观察、及时判断和严格留痕的工程活动。

本节在考试中的价值主要体现在案例分析。题目可能给出某系统经过可靠性测试仍在生产发生故障，要求分析测试实施过程中的问题；也可能要求设计一套可靠性测试执行方案。答题时应覆盖测试前准备、测试中控制、故障后的记录与恢复、测试结束后的分析和改进，形成完整闭环。

二、可靠性测试实施的总体流程

可靠性测试可以按以下阶段实施：

任何阶段都应有明确的进入条件和退出条件。比如没有确认监控和日志链路正常，就不能进入故障注入；没有确认测试数据已经隔离，就不能开始产生有副作用的业务事务。

三、测试前准备

1. 明确测试范围和风险边界

测试计划应说明被测系统、依赖系统、版本、配置、测试时段、参与人员、目标指标和不测试的内容。尤其要明确是否允许真实支付、是否允许写入生产数据、是否会触发外部通知、是否会影响其他租户。

可靠性测试可能包含破坏性故障注入，必须设计风险边界。例如只能在隔离环境操作，只允许停止测试节点，禁止向真实客户发送消息；网络隔离和磁盘填满等操作要设置自动恢复和人工停止按钮。没有边界控制的故障注入，测试本身可能成为事故来源。

2. 固化软件和配置基线

记录应用版本、依赖版本、操作系统、容器镜像、数据库结构、配置版本、证书、特性开关和拓扑。测试过程中如果版本或配置被临时修改，必须重新登记，否则无法解释结果。

基线还包括初始业务数据、队列积压、缓存状态和资源使用。对于长期测试，最好生成一份可恢复的环境快照或自动化部署脚本，确保每轮测试可以从可描述状态开始。

3. 准备测试数据

测试数据应与运行剖面相匹配，覆盖代表性、边界、异常和大规模数据。生产数据需要脱敏，敏感字段不能直接复制到非生产环境。对于会产生状态变化的数据，要设计清理、回滚或隔离方案。

数据准备还要考虑关联完整性。例如订单测试需要用户、商品、库存、支付账户和配送信息；只准备订单表而没有配套数据，会导致测试失败来自数据缺失，而不是系统可靠性问题。

4. 验证监控和观测能力

测试开始前要确认日志、指标、链路、告警、审计、业务对账和故障注入工具均能正常工作。应先执行一个可预期的小场景，检查请求是否能够通过关联标识串联，异常是否能在监控平台呈现，告警是否能通知正确人员。

如果测试中发生失败却没有完整日志和时间线，后续只能得到“系统不稳定”的模糊结论，无法定位和改进。因此可观测性本身也是测试前置条件。

5. 明确人员职责与应急通道

可靠性测试通常需要测试、开发、架构、运维、数据库和业务人员协同。应明确谁负责启动和停止测试，谁负责注入故障，谁判断是否暂停，谁执行恢复，谁确认业务数据，谁批准继续扩大范围。

应急通道包括值班电话、即时通信群、回滚命令、环境恢复脚本和升级路径。出现超过风险边界的现象时，任何参与者都应有权暂停测试，不能等待层层审批。

四、测试执行与过程控制

1. 先基线、后刺激

开始正常运行前，记录吞吐量、响应时间、错误率、CPU、内存、连接数、队列、数据库延迟和业务成功率。故障注入前再次采集快照，确认系统处于预期状态。只有有了基线，才能判断故障带来的变化。

2. 按阶段递进执行

可以采用单节点、单服务、小流量、单可用区到全量集群的递进策略。每一阶段都设置观察窗口，验证错误率、延迟、积压、数据一致性和恢复能力。若指标越过停止阈值，应暂停扩散并分析原因，而不是继续执行以“完成计划”。

3. 控制故障注入

故障注入记录至少包括故障类型、目标对象、开始时间、结束时间、注入工具、注入参数和预期效果。注入应与业务事务建立关联，例如在支付提交前后分别注入网络中断，以便分析状态差异。

组合故障要谨慎。先验证单故障的处理路径，再按照风险和生产可能性组合。如果同时注入大量故障导致系统完全失效，既不能证明架构一定不可靠，也无法定位具体机制。

4. 实时监控和动态判断

测试人员要同时看技术面板和业务面板。技术面板关注错误率、延迟分位数、资源、队列、连接和切换状态；业务面板关注订单成功率、金额、库存、消息数量、对账差异和用户可见状态。技术指标恢复后，业务指标可能仍在修复或补偿，不能过早结束观察。

监控应关注趋势和长尾，而不是只看平均数。平均延迟正常但 P99 持续升高，可能说明部分用户已经受到影响；错误率很低但错误集中在核心交易，也可能超过业务可接受范围。

5. 暂停、停止和恢复

测试计划应提前定义暂停条件，例如核心交易失败、数据出现不可逆损坏、错误率持续超过阈值、队列积压无法下降、资源接近耗尽或故障越过隔离边界。暂停后先保护现场、保存证据，再执行恢复，不要立即清理环境导致关键信息丢失。

恢复动作要区分测试环境恢复和业务状态恢复。前者是让服务重新启动，后者是确认订单、支付、库存、消息和对账回到正确状态。恢复后必须重新采集基线，不能把恢复过程中的指标直接混入正常运行统计。

五、数据采集与时间线

可靠性测试最重要的产物之一是事件时间线。时间线应统一时钟，记录流量开始、故障注入、故障暴露、告警产生、人工介入、服务切换、恢复完成和业务补偿完成等事件。没有统一时间线，日志和指标很难关联。

采集数据可以分为四层：第一层是请求和事务数据，如请求标识、事务状态和响应结果；第二层是应用数据，如异常、线程、连接和缓存；第三层是基础设施数据，如节点、网络、磁盘和容器；第四层是业务数据，如订单、金额、库存、账务和对账。四层数据要能通过时间、实例、链路和业务标识关联。

数据采集也要控制成本。日志级别不能长期无限提高，采样策略不能丢失故障上下文，敏感数据要脱敏，原始数据要设置保留期限。对于关键故障，可以临时提高采集级别，但要记录开启和关闭时间。

六、测试结果分析

1. 故障分类

将结果分为产品缺陷、配置缺陷、环境问题、测试工具问题、数据问题和预期限制。产品缺陷还可以按输入校验、状态管理、并发、事务、资源、依赖、恢复和安全分类。分类不是推卸责任，而是帮助确定整改路径。

2. 计算和比较指标

根据测试目标计算成功率、故障率、平均无故障时间、平均恢复时间、检测时间、切换时间、数据差异量、积压峰值和积压恢复时间。比较故障前基线、故障期间和恢复后数据，判断系统是否真正回到稳定状态。

指标必须注明分母和观察窗口。例如“成功率 99%”要说明是全部请求、核心请求还是排除预期拒绝后的请求；“恢复 30 秒”要说明从故障发生、告警产生还是人工开始处理计算。

3. 根因分析

可使用事件时间线、日志关联、链路追踪、配置对比、代码分析和数据对账定位根因。要区分直接原因和系统性原因：节点宕机可能是直接刺激，未配置合理超时和重试边界才是导致级联故障的系统性原因。

根因分析还应检查为什么测试没有提前发现。可能是运行剖面不真实、用例未覆盖、观察窗口太短、判定准则缺失或测试环境与生产差异过大。这样才能改进测试体系，而不是只修复一个缺陷。

七、复测与上线决策

缺陷修复后应优先重放原故障场景，证明问题已消失；然后执行相关回归，确认修复没有破坏其他路径；最后在代表性负载和长期运行条件下观察，验证改进效果持续存在。

上线决策不应只有“通过”或“不通过”两个选项，还可以给出条件放行、限制范围、增加监控和延期整改等结论。条件放行必须明确剩余风险、影响对象、监控指标、回滚方案、责任人和截止时间。严重数据一致性问题通常不能用“加强观察”替代修复。

八、案例分析：文件服务故障注入实施

某文件服务需要验证高可用能力。测试计划要求模拟主节点宕机并观察备用节点接管。第一次实施时，测试人员没有记录初始文件数量和校验摘要，也没有确认客户端重试策略；注入故障后只看到服务重新可访问，就宣布测试通过。上线后发现部分上传请求重复，少量文件元数据和实际对象不一致。

正确的实施过程应先固化软件、配置、存储和副本基线，记录文件数量、大小、摘要和元数据。测试前执行小规模上传、下载和删除，确认链路追踪与监控正常。正式测试中按照运行剖面生成上传、下载、查询和删除事务，并在上传提交前、对象写入后、元数据提交前后分别注入节点故障。故障期间采集客户端响应、重试、服务切换、存储副本和队列数据。

恢复后不能只检查端口和进程，而要重新计算文件摘要，核对元数据、对象数量和业务记录，确认重复上传是否被幂等机制抑制、失败任务是否进入补偿队列。测试结果应按照故障检测时间、接管时间、数据差异量、重复事务数和积压恢复时间判定。若存在差异，应保留现场、定位事务边界并复测，不能用服务“已经能访问”作为通过依据。

九、综合知识练习

题1

可靠性测试为什么要在故障注入前记录基线？

参考答案：基线用于说明故障前系统的版本、配置、资源、性能、业务状态和数据状态，便于比较故障造成的影响、判断恢复是否完成，并帮助排除测试前已有问题。没有基线，测试结果无法解释。

题2

测试中发现服务恢复，但业务数据仍有差异，是否可以判定测试通过？

参考答案：不能。服务可达只说明技术层面恢复，可靠性还要求业务结果正确和数据一致。应继续检查补偿、对账和状态恢复，若差异超过目标则测试失败或条件不通过。

题3

可靠性测试报告为什么必须注明指标的统计口径？

参考答案：同一个指标在不同分母、时间窗口和故障分类下含义不同。注明口径才能复核、比较和避免用平均值掩盖核心业务或长尾问题，也能为上线决策提供可信证据。

十、论文写作素材

论文中可以这样描述测试实施：

“在实施可靠性测试前，我固化应用、依赖、配置、数据和拓扑基线，确认日志、指标、链路、告警和业务对账均可用，并制定故障注入边界和应急恢复方案。测试执行采用由小范围到大范围的递进策略，先采集正常基线，再按运行剖面产生业务流量，在关键事务时机注入节点、网络、存储和依赖故障。测试期间统一记录事件时间线，关联请求、应用、基础设施和业务数据；故障恢复后从技术状态、业务状态和数据一致性三个层面验证恢复结果。对失败场景保留证据、分析根因、修复并重放，最终依据明确的统计口径和通过准则提出上线建议。”

案例题中要突出“前置条件、过程控制、实时监测、暂停恢复、结果分析、复测放行”六个方面，这比单纯列出测试类型更能体现架构师的工程能力。

十一、今日复盘

1. 可靠性测试实施的核心是基线、控制、观察、证据和闭环。
2. 测试前要固化版本、配置、数据、拓扑和风险边界。
3. 测试中要先基线后刺激，按阶段递进，并设置暂停和停止条件。
4. 恢复判断必须同时覆盖技术、业务和数据三个层面。
5. 结果分析要有统一时间线、明确统计口径和根因分类。
6. 修复后必须重放原故障并执行回归，才能形成可靠的上线决策。