返回质量体系与测试架构模块
Quality Architecture / Tutorial 22
测试报告、效能度量与质量复盘教程
把前一篇的线上证据转成发布判断和改进动作：不是证明测试做了很多，而是说明风险是否可接受、机制是否有效。
9 个章节报告 + 指标 + 复盘反无意义 KPI
01
测试报告首先服务决策
结论先于数字从数据到决策的链路
版本变化优惠与支付回调
风险与范围重复扣款、超卖
验证证据用例、缺陷、指标
剩余风险未测与已知问题
发布建议阻断 / 有条件 / 允许
一页报告必须回答
- 测的是哪个版本、环境和时间窗口？
- 最重要的业务风险验证结果如何？
- 哪些内容失败、阻塞、未执行，为什么？
- 遗留问题影响谁，是否有规避、监控和负责人？
- 最终建议是什么，依据是什么？
“执行 500 条、通过率 98%”不是发布结论。若失败的 2% 包含重复扣款，就必须阻断；若是低风险文案，可在责任明确后有条件发布。
02
用多维覆盖率寻找盲区
覆盖不只一个百分比五类覆盖率
| 维度 | 回答的问题 | 商城例子 |
|---|---|---|
| 需求覆盖 | 高风险验收规则是否有验证证据 | 重复支付、超卖、退款失败规则覆盖 |
| 风险覆盖 | 已识别风险中被验证的比例 | P0 风险必须逐项有结论 |
| 层级覆盖 | 单元、接口、集成、E2E 是否分工合理 | 金额规则不靠大量 UI 用例穷举 |
| 代码覆盖 | 哪些代码被执行 | 辅助发现盲区，不能证明断言有效 |
| 环境覆盖 | 浏览器、设备、配置、依赖组合 | 只覆盖风险相关组合 |
风险覆盖率示意
risk_coverage = 已有有效验证证据的风险数 / 已识别风险数
P0_risk_coverage = 12 / 12 = 100%
P1_risk_coverage = 21 / 24 = 87.5%
# 同时列出未覆盖的 3 项，不只展示百分比用例：当新增“取消后自动退款”规则时，报告应显示退款风险覆盖变化
- 把退款金额、重复回调、超时补偿列为独立风险。
- 关联接口、消息、E2E 和对账用例。
- 对未验证的第三方超时场景标记未覆盖，而不是默认通过。
03
按分布与根因读懂缺陷
数量只是入口按发现阶段分析缺陷
| 阶段 | 典型问题 | 改进方向 |
|---|---|---|
| 需求阶段 | 规则冲突、边界遗漏 | 加强评审和示例化验收 |
| 开发阶段 | 状态机、幂等、异常处理 | 补单元与契约测试 |
| 测试阶段 | 跨服务一致性、环境差异 | 补集成和故障演练 |
| 线上阶段 | 长尾流量、监控盲区 | 补可观测性、灰度和回归 |
至少保留这些维度
- 模块、严重度、发现阶段、引入版本和发现手段。
- 需求、设计、编码、数据、配置、环境等根因。
- 用户影响、资金影响、逃逸原因和修复时长。
- 重复缺陷与同源缺陷聚类，避免把一个根因算成十项成绩。
缺陷多不一定测试有效，也可能代表版本质量差；缺陷少不一定质量好，也可能是覆盖不足。必须结合风险、变更量、线上逃逸与历史趋势解释。
04
衡量测试是否更早发现重要问题
有效性而非忙碌度有效性指标
| 指标 | 定义 | 使用边界 |
|---|---|---|
| 缺陷逃逸率 | 线上发现缺陷 / 全部有效缺陷 | 按严重度和发布频率看趋势 |
| 阶段移除效率 | 某阶段发现 / 进入该阶段的问题 | 用于发现防线薄弱处，不评价个人 |
| 高风险命中率 | 发现高风险问题的用例 / 高风险用例 | 低值时审查用例设计和风险判断 |
| 误报率 | 无产品问题的失败 / 全部失败 | 拆分脚本、环境、数据和产品原因 |
| 反馈时间 | 变更到可靠结果的时间 | 同时保证结果可信，不能只求快 |
缺陷逃逸要同时看数量、严重度与趋势
- 同样是一条线上缺陷，资金错误与文案错误不能等重解释。
- 团队可以给严重度设置内部权重，但权重与分级阈值必须书面化并保持跨版本一致。
- 加权结果用于识别趋势和突变，不用于评价个人，也不应脱离样本量单独发布。
- 线上缺陷必须正确标记发现环境，否则逃逸统计会系统性漏数。
用例：当自动化通过但线上出现重复退款时，应反查哪道防线失效
- 确认该风险是否在测试策略中被识别。
- 检查是否有重复消息和并发退款用例。
- 检查断言是否只看状态码而未核对退款流水数量。
- 把逃逸原因归到机制，不归咎某个人。
05
计算自动化的真实收益
维护成本必须入账收益模型
saved_hours = manual_duration * useful_runs - triage_hours
net_value = saved_hours * hourly_cost - build_cost - maintenance_cost
reliable_rate = trusted_results / all_runs
# 失败无人处理、长期跳过的用例不计入有效覆盖不要只看自动化数量
| 观察项 | 好信号 | 坏信号 |
|---|---|---|
| 稳定性 | 失败可复现且归因清楚 | Flaky 导致团队默认重跑 |
| 反馈速度 | P0 回归几分钟给出可靠结果 | 全量套件数小时且无人等待 |
| 维护投入 | 变更影响集中、可预测 | 每次 UI 微调大面积修脚本 |
| 缺陷价值 | 拦截过真实高风险回归 | 只验证页面能打开 |
| 使用频率 | 在 PR、发布中真正参与决策 | 只在汇报前运行 |
06
构建能下钻的质量看板
趋势、分母、上下文从数据到决策的链路
业务结果成功率与线上事故
风险防护P0 覆盖与门禁
交付效率反馈与修复时长
资产健康Flaky 与维护成本
下钻证据版本、缺陷、用例
看板验收用例
- 当发布日期筛选变化时，所有图表使用同一时间范围。
- 当执行重跑时，同一次结果不会重复计数。
- 当用例被跳过时，覆盖率分母和原因可见。
- 当点击线上缺陷时，可下钻到版本、风险、遗漏用例和复盘。
- 当数据源延迟时，看板显示更新时间，不展示伪实时结果。
07
从事故时间线走向系统改进
复盘不追责线上支付问题复盘时间线
发现
支付告警与投诉
止损
关闭重试开关
恢复
补偿订单并对账
防复发
幂等约束 + 回归
质量复盘五问
- 发生了什么，用户与业务影响是什么？
- 为什么现有测试、门禁和告警没有更早阻止或发现？
- 哪些事实来自日志、Trace、数据对账，哪些仍是推测？
- 修复当前问题后，要补哪条需求规则、用例、监控或恢复机制？
- 改进项由谁在何时完成，怎样验证确实生效？
用例：当支付回调重复导致重复退款时，复盘应落到防复发
补充 eventId 幂等约束、重复消息集成用例、退款流水唯一性告警和上线对账，而不是只写“开发加强自测、测试认真回归”。
08
拒绝会驱动错误行为的 KPI
指标用于学习反无意义 KPI
| 不要这样考核 | 会导致什么 | 更好的问法 |
|---|---|---|
| 每人每月发现 Bug 数 | 拆分缺陷、对抗协作 | 高风险问题是否更早被发现 |
| 自动化用例越多越好 | 重复、低价值、无人维护 | 哪些回归被稳定缩短或拦截 |
| 通过率必须 100% | 隐藏跳过和已知失败 | 失败是否被解释并有决策 |
| 代码覆盖率越高越好 | 为数字写无断言测试 | 关键风险是否有有效断言 |
| 线上零缺陷 | 压制上报、漏记问题 | 影响是否下降、恢复是否更快 |
好指标帮助团队提出问题，坏 KPI 让人优化数字。任何指标都应有清楚分母、数据来源、使用目的和配套行动，不用于脱离上下文评价个人。
09
交付一份可行动的质量复盘
练习与检查清单练习
- 为一次商城发布写一页决策报告，列出三项最高风险。
- 计算风险覆盖、缺陷逃逸、自动化可靠率与反馈时间。
- 选一个线上支付问题，画出从发生到恢复的证据时间线。
- 计算一组自动化用例的净收益，说明是否继续维护。
- 识别现有看板中两个可能被误用的 KPI，并改写为问题导向指标。
- 输出三项有负责人、期限和验收方式的改进动作。
报告
- 版本范围清楚
- 风险结论优先
- 未测项可见
- 建议可执行
度量
- 口径和分母明确
- 趋势可下钻
- 成本已计入
- 不评价个人
复盘
- 事实与推测分开
- 系统根因明确
- 防复发可验证
- 负责人和期限明确