跳转至

异常闭环、回归与发布判定

测试结束不是文件生成完毕，而是每项要求、异常、偏差和未覆盖风险都有明确状态，并且发布决定与证据强度匹配。

异常处置与回归闭环

异常不等于根因

异常记录的是观察事实：

在TEST-042第3测试点，
电流记录于12.4秒出现饱和，
同时温度通道缺失0.8秒。

“电调故障”“软件错误”是待验证假设，不能直接写进事实字段。

异常分类

类别 示例 首要处理
产品偏差 输出、结构或状态不满足要求 隔离样件，建立假设
测试系统偏差 夹具、仪器或脚本异常 标记数据有效性
程序偏差 步骤、顺序或环境不符合计划 判断测试是否无效
配置偏差 固件、参数或部件与基线不符 停止并重建配置
安全事件 人员、设施或能量边界被突破 应急与正式报告
需求问题 判据含糊、矛盾或不可测 返回需求管理

一次事件可能同时属于多类，但要分别处理。

立即处置

  1. 保护人员并隔离能量；
  2. 保全受测件和工装；
  3. 保存原始数据；
  4. 记录时间、条件和配置；
  5. 标记受影响测试点；
  6. 通知有权角色；
  7. 判断法规、事故或安全报告义务；
  8. 未经批准不重新运行。

重复运行可能扩大损伤或覆盖证据。

数据有效性判定

异常后分别判断：

  • 异常前数据；
  • 异常期间数据；
  • 异常后数据；
  • 同批其他测试；
  • 使用同一仪器或工装的历史结果。

仪器校准失效可能影响过去一段时间的数据。不能只把当前文件标红。

根因与纠正

07专题负责完整故障诊断方法。测试管理侧要求：

  • 每个假设有支持和反证；
  • 区分直接原因、促成因素和系统原因；
  • 纠正措施对应已证实机制；
  • 不用“更换后正常”单独证明根因；
  • 软件、硬件、程序和培训措施分别验证；
  • 新风险进入危害分析。

处置类型

处置 含义
修复并复测 纠正产品或测试系统后重新执行
按现状使用 有权角色接受明确剩余风险
返工 按受控程序恢复到要求
报废 不再用于目标用途
要求变更 正式修改基线和影响范围
偏离批准/豁免 在限定对象、时间和条件下批准不满足
测试无效 方法或数据不足，不能判产品通过失败

“按现状使用”不能隐藏在测试报告备注里。

回归测试

变更影响可能沿以下路径传播：

  • 共享代码；
  • 公共电源；
  • 总线和端口；
  • 参数默认值；
  • 构建配置；
  • 机架和载荷；
  • 工装与数据处理；
  • 安全和恢复路径。

回归选择要基于影响分析，不只重跑失败用例。

回归层级

修复点单元测试
→ 直接接口测试
→ 相关子系统
→ 关键端到端场景
→ 安全功能与恢复
→ 必要的台架或飞行回归

高风险实物回归只在低层证据通过后执行。

基线回归集

长期保留：

  • 启动和身份；
  • 关键输入输出；
  • 安全状态；
  • 失联与恢复；
  • 日志质量；
  • 资源与时序；
  • 当前批准包线核心点；
  • 历史严重缺陷；
  • 配置迁移；
  • 回滚。

每次发布要记录哪些用例执行、跳过和失败。

测试债务

未执行、环境缺失、工具失效和数据不足形成测试债务。记录：

  • 对应要求；
  • 原因；
  • 风险；
  • 临时限制；
  • 关闭计划；
  • 责任人；
  • 期限。

测试债务不能用“后续补测”一行长期保留，也不能在发布摘要中消失。

资格鉴定与验收

资格鉴定通常面向冻结设计和规定代表样件；验收通常面向交付单元的制造与工艺状态。

不要推导：

  • 一个样件鉴定通过，所有生产单元自动通过；
  • 每台验收通过，设计已覆盖所有环境；
  • 工程筛查通过，已经完成正式资格鉴定；
  • 资格鉴定通过，已经取得法规认证。

正式项目应按适用合同、标准和质量体系定义样件、程序和批准权限。

发布评审

输入：

  • 需求验证矩阵；
  • 配置基线；
  • 测试计划和执行记录；
  • 原始数据和分析；
  • 异常与处置；
  • 回归结果；
  • 测试债务；
  • 已知限制；
  • 合规状态；
  • 恢复方案。

问题：

  1. 每项适用要求是否有客观证据？
  2. 证据是否属于交付配置？
  3. 测量能力是否足以判定？
  4. 失败和无效是否全部可见？
  5. 高风险异常是否独立关闭？
  6. 回归是否覆盖变更传播？
  7. 未覆盖包线是否进入限制？
  8. 发布后如何监测和回滚？

发布状态

状态 含义
拒绝 存在不可接受风险或关键要求失败
阻断 证据、设施、授权或配置不足
限定发布 仅在明确构型、环境和任务范围使用
发布 在批准范围内满足要求
撤回 新证据使原结论不再成立

限定发布必须把限制放到用户、操作和配置入口，不能只留在内部报告。

报告结构

1. 目的和范围
2. 需求与风险
3. 受测件和配置
4. 方法、环境和仪器
5. 偏差
6. 数据质量
7. 结果和不确定度
8. 异常与处置
9. 回归
10. 未覆盖与限制
11. 结论
12. 审查和批准

报告中的“通过”要能链接到原始证据，不能只有汇总表。

变更后的处理

发生以下变化重新评估历史证据：

  • 硬件修订；
  • 固件或编译选项；
  • 参数和校准；
  • 供应商或材料；
  • 工装和仪器；
  • 测试方法；
  • 任务、载荷或环境；
  • 法规和标准；
  • 新故障或现场事件。

影响分析可以决定部分证据仍有效，但必须记录理由。

关闭清单

  • 要求矩阵没有未知空白；
  • 所有失败和无效项有处置；
  • 异常编号全部闭环或正式接受；
  • 配置与交付物一致；
  • 回归结果完整；
  • 测试债务可见；
  • 限制进入使用文档；
  • 原始数据和脚本可复现；
  • 合规与安全批准有效；
  • 回滚路径已验证；
  • 独立复核完成。

检查理解

  1. 异常事实和根因假设有什么区别？
  2. 为什么仪器异常可能影响历史测试？
  3. 回归为何不能只重跑失败用例？
  4. 资格鉴定和验收分别面向什么？
  5. 限定发布为什么要把限制传递给使用者？

主要参考