Day30-05｜9.1.5 广义的可靠性测试与狭义的可靠性测试：从全生命周期质量保障到专门可靠性验证

一、教材定位

可靠性测试可以从广义和狭义两个角度理解。狭义的可靠性测试，通常指在规定条件下，通过长时间运行、故障注入、压力、恢复和统计分析，直接评价软件可靠性的专门测试；广义的可靠性测试，则把能够提高或验证软件可靠性的所有测试活动纳入视野，包括需求评审、设计评审、代码检查、功能测试、性能测试、安全测试、容错测试、恢复测试、运维演练和生产监控。

理解这种区别非常重要。若只采用狭义理解，可靠性会被推迟到测试阶段，错过需求和架构阶段降低风险的机会；若只采用广义理解，又可能把所有测试都笼统称为可靠性测试，失去对专门可靠性指标和故障模型的关注。高级架构师应根据目标和阶段选择合适的测试范围，并建立从预防、发现到恢复的完整体系。

二、广义可靠性测试

广义可靠性测试关注软件生命周期中所有会影响可靠性的活动。它的基本思想是：可靠性不是测试阶段“测出来”的单一结果，而是需求正确、设计合理、实现规范、测试充分、部署受控和运行可观测共同形成的属性。

广义范围包括：需求评审和一致性检查，架构评估和质量属性分析，设计走查，代码审查，静态分析，单元和集成测试，系统和验收测试，性能和压力测试，安全与兼容性测试，容错与恢复测试，部署回滚和灾备演练，以及运行监控、故障复盘和变更验证。

三、狭义可靠性测试

狭义可靠性测试以可靠性目标和故障模型为中心，直接观察系统在规定条件和时间内的失效、恢复和业务正确性。它通常包括可靠性增长测试、稳定性测试、压力测试、故障注入、容错测试、恢复测试、数据完整性测试和可靠性指标统计。

狭义测试的问题定义更集中。例如：连续运行72小时是否出现资源泄漏；在高峰负载下错误率是否低于阈值；随机关闭节点后是否在规定时间内恢复；消息重复和乱序是否影响业务状态；数据库恢复后是否满足数据丢失窗口；系统是否能够完成规定数量的任务而不发生严重失效。

四、两种范围的关系

广义可靠性测试是体系，狭义可靠性测试是其中针对可靠性属性的专门部分。广义活动能够预防和减少故障，狭义活动能够直接测量运行可靠性和恢复能力。二者不是互相替代，而是互相补充。

可以用“预防—发现—隔离—恢复—改进”理解：需求和架构评审偏重预防，功能和静态测试偏重发现，模块隔离和熔断偏重隔离，容错和恢复测试偏重恢复，生产监控和复盘偏重改进。

五、广义测试活动详解

1. 需求可靠性评审

检查需求是否明确、完整、一致、可验证，是否说明负载、异常、恢复、数据正确性和安全边界。对于“系统必须稳定”这类描述，应追问时间、条件、功能和指标，并补充异常和故障场景。

2. 架构可靠性评估

检查是否存在单点、故障传播、共享写入、循环依赖、不可恢复状态和缺少观测的路径。利用质量属性场景、架构走查、ATAM、原型和容量分析发现结构性风险。

3. 代码和静态分析

关注资源释放、异常处理、空值和边界、并发访问、线程安全、错误吞没、日志敏感数据、配置读取和依赖漏洞。静态分析不能替代运行测试，但能在低成本阶段发现许多缺陷。

4. 功能和集成测试

验证正常、边界、异常、重复、乱序、权限和版本兼容行为。可靠性视角要求不仅检查功能结果，还要检查多次执行、依赖失败和恢复后的状态。

5. 运维与发布测试

验证配置校验、灰度发布、回滚、备份、恢复、扩容、告警和故障处置。很多生产失效不是代码缺陷，而是错误配置、发布顺序和人工操作导致。

六、狭义测试活动详解

1. 可靠性增长测试

通过持续测试和修复缺陷，观察失效率是否下降、任务成功率是否提高。测试结果可用于判断版本是否接近目标，但要注意修复缺陷可能引入新缺陷，不能只看短期趋势。

2. 稳定性和耐久性测试

在代表性负载下长时间运行，观察内存、连接、线程、队列、磁盘、缓存和响应时间变化。测试周期要足以暴露周期性任务、日志增长、数据膨胀和资源泄漏问题。

3. 容错与故障注入

制造节点、网络、存储、数据库、消息和外部依赖故障，验证系统是否能够检测、隔离、切换、降级和恢复。测试要关注故障期间的业务结果和恢复后的数据正确性。

4. 可靠性统计

记录运行时间、失效次数、失效类型、故障间隔、恢复时间、任务次数、成功次数和数据错误，计算目标指标。统计应说明样本规模、环境、版本和限制，不应将不同条件下的数据直接合并。

七、广义与狭义测试的选型

如果项目处于需求和架构阶段，应优先采用广义可靠性活动，尽早识别目标和结构风险；如果系统已经实现，应在广义活动基础上安排狭义可靠性测试；如果是关键行业或高风险系统，二者都需要，并且要把可靠性活动纳入合规和运维流程。

八、案例分析：银行核心交易系统

银行核心交易系统的广义可靠性工作从需求阶段开始：明确扣款、冲正、日终、对账和监管报送的正确性要求；架构阶段分析事务、一致性、容灾和审计；设计阶段规定账户余额和交易状态的所有权；编码阶段执行静态检查和异常处理审查；集成阶段测试核心与渠道、清算和通知系统的协作；发布阶段执行双人复核、灰度和回滚；运行阶段监控失败交易、对账差异和恢复时间。

狭义可靠性测试进一步执行长时间交易、峰值并发、重复扣款请求、网络分区、数据库切换、消息重复、外部清算系统超时和灾备切换。测试不只检查交易接口是否返回成功，还要检查余额、流水、对账、审计和用户通知最终一致。

如果只有狭义测试，系统可能在发布前通过了故障演练，却因为需求没有定义冲正语义而产生业务争议；如果只有广义评审，没有长时间和异常测试，又无法证明具体实现具备可靠性。因此银行系统必须同时采用两种范围。

九、测试结果的闭环

广义和狭义测试都应形成问题闭环：发现问题，记录现象和条件；分析根因，区分需求、架构、实现、配置、环境和运维原因；制定修复方案，明确影响和回归范围；重新测试，确认问题关闭；更新风险、架构决策、测试用例和运维预案。

可靠性测试还应推动可靠性增长。每次失效都应沉淀故障模式、检测方法、恢复步骤和预防措施，逐步减少相同问题重复发生。

十、常见错误

第一，把广义可靠性测试等同于“所有测试随便做”。广义活动仍需围绕可靠性目标组织。第二，把狭义可靠性测试只理解为长时间运行，忽略故障注入、恢复和业务数据校验。第三，只测组件，不测端到端业务。第四，只看服务可用，不看结果正确。第五，测试通过后不建立运行监控和复评机制。

十一、练习题

题1

广义可靠性测试和狭义可靠性测试的核心区别是什么？

参考答案

广义可靠性测试覆盖软件生命周期中所有预防、发现、隔离、恢复和改进可靠性的活动；狭义可靠性测试专门针对可靠性目标和故障模型，通过稳定性、压力、故障、恢复和统计等测试直接评价可靠性。广义是体系，狭义是专门测试组成部分。

题2

为什么需求评审也属于广义可靠性活动？

参考答案

需求歧义、缺少异常条件和不可验证目标会导致架构和实现错误。通过需求评审明确条件、时间、功能、故障和指标，可以在缺陷进入设计和代码前预防可靠性问题。

题3

某系统狭义可靠性测试通过，但上线后频繁因配置错误故障，说明什么？

参考答案

说明测试范围可能只覆盖代码和运行故障，缺少广义可靠性活动中的配置评审、环境一致性检查、发布验证、灰度和回滚测试。应把配置和运维过程纳入可靠性保障体系。

十二、论文写作素材

论文中可以写“项目采用广义与狭义结合的可靠性测试体系。广义上，从需求评审、架构评估、代码审查、接口测试到发布回滚和运行监控，持续降低缺陷和变更风险；狭义上，针对关键场景开展稳定性、压力、故障注入、恢复和可靠性统计，验证节点宕机、消息重复、数据库切换和外部超时。所有结果均经过根因分析、修复、回归和运行复盘，形成可靠性增长闭环。”

十三、今日复盘

广义可靠性测试贯穿生命周期，强调预防、发现、隔离、恢复和改进；狭义可靠性测试聚焦可靠性属性本身，强调长期运行、故障、恢复和统计。考试答题时要说明二者区别、联系、适用阶段和证据，避免把可靠性测试简单等同于压力测试。