需要定义、追踪并落地 QA 指标时用：把测试覆盖率…

当团队要建立或改进质量指标体系（覆盖率、flakiness、缺陷逃逸率、MTTR、CI 时长、自动化 ROI、质量门禁）时，用公式、目标值和红灯行动方案把仪表盘变成反馈回路。

适用场景

解决思路

1. 先检查 `.agents/qa-project-context.md`，若存在则以其为基础，跳过其中已回答的内容；再通过 Discovery Questions 澄清现状（当前追踪哪些指标、测试数据在哪、有无仪表盘、CI 工具）、干系人（工程/产品/领导/客户各自关心什么、谁拥有每个指标）、质量问题（近期生产事故、哪些决策缺数据）和目标（健康测试套件的定义、合规要求、快速见效还是全面可观测）。
2. 遵循五条核心原则：指标必须驱动行动而非只做仪表盘（每个指标定义触发阈值、行动、负责人）；同时追踪领先指标（flakiness、覆盖率变化、跳过测试数）和滞后指标（缺陷逃逸率、MTTR），工程师日常关注领先指标；看趋势而非快照（用时间序列评估方向）；每个指标都要有目标值和负责人；避免虚荣指标（如“有 4000 个测试”但 800 个被禁用、200 个 flaky）。
3. 定义并追踪代码覆盖率：行覆盖率 =（测试执行的行数 / 可执行总行数）× 100，分支覆盖率 =（测试执行的分支数 / 总分支数）× 100；目标为应用代码行覆盖 70-85%、分支 60-75%、关键路径（支付、认证）90%+；覆盖率下降时阻止合并或标记，关键模块低覆盖时创建专项任务，停滞时检查死代码与未测逻辑；注意覆盖率只衡量执行不衡量断言质量，需配合变异测试（StrykerJS v9.6+、mutmut），monorepo CI 中用 `incremental: true` 控制成本。
4. 定义并追踪需求覆盖率 =（至少有一个测试的功能数 / 总功能数）× 100，P0/P1 功能目标 100%、P2 目标 80%+；用测试标签（如 `@feature:checkout`、`@story:PROJ-1234`）建立可追溯性。
5. 定义并追踪风险覆盖率 =（有自动化测试的高风险区域数 / 总高风险区域数）× 100，高风险区域目标 95%+；维护风险登记册并按模块与覆盖率数据交叉比对。
6. 定义并追踪 flakiness rate =（结果不稳定的测试运行数 / 总测试运行数）× 100；可接受 <2%、警告 2-5%、严重 >5%；红灯时立即隔离 flaky 测试，每周调查 top 3，常见原因包括时序/竞态、共享状态、外部依赖、顺序依赖，flaky 超过 30 天的测试应删除或重写；检测工具可用 Buildkite Test Analytics、Datadog Test Optimization、Trunk Flaky Tests，或写脚本比较同一 commit 的多次运行结果。
7. 定义并追踪 7 天滚动通过率 =（绿色 CI 运行数 / 总 CI 运行数）× 100；健康 >95%、警告 90-95%、损坏 <90%；7 天滚动平均可平滑日常噪声、揭示真实趋势。
8. 统计被禁用和跳过的测试数（`skip`、`disabled`、`pending`、`xit`、`xdescribe` 等）；目标趋近于零，超过 2 个 sprint 的跳过测试要修复或删除，在 CI 中加一步：跳过测试超过总数 5% 就失败；注意跳过测试是隐藏的覆盖缺口（如 500 通过 + 150 跳过 = 23% 缺口）。
9. 追踪测试套件时长（从开始到完成的墙钟时间）；目标为单元 <5 分钟、集成 <10 分钟、E2E <15 分钟、完整流水线 <30 分钟（各阶段目标是真正的预算，<30 分钟是总和而非独立宽松标准）；红灯时分析最慢的 10% 测试（常占 50% 运行时间）、提高并行度、把慢测试移到合并后、检查不必要的 setup/teardown，并绘制时长趋势、对一周内 >20% 的阶跃变化告警。
10. 定义并追踪缺陷逃逸率 =（生产环境发现的缺陷数 / 总缺陷数）× 100；优秀 <5%、可接受 5-10%、需改进 10-20%、严重 >20%；示例：一次发布共 15 个缺陷、其中 2 个在生产 → 2/15×100 = 13.3%，属于“需改进”；红灯时按层（单元/集成/E2E/评审）分类逃逸缺陷、为每个写回顾性测试、识别是否集中在特定区域并针对性投入；用 `escaped-defect` 标签标记生产 bug，在 sprint 回顾中统计逃逸与发布前缺陷。
11. 定义并追踪 MTTR = 各缺陷解决时间之和 / 缺陷数；目标为 P0 <4 小时、P1 <24 小时、P2 <1 sprint、P3 <2 sprint；高 MTTR 往往反映流程瓶颈（评审慢、责任不清、部署复杂）而非技术难度，可拆分为分诊、分配、修复、部署各阶段定位瓶颈；注意这是 QA 缺陷解决时间，与 DORA 的恢复指标不同。
12. 定义并追踪缺陷密度 = 发现的缺陷数 / KLOC（或每交付功能）；以自身基线为准，行业基准为每 KLOC 1-10 个缺陷；某模块密度是其他模块 5 倍时，需要重构或提升覆盖率。
13. 追踪严重程度分布：健康分布为 P0 <5%、P1 10-15%、P2 40-50%、P3 30-40%；用堆叠柱状图展示随时间变化，P0/P1 集中说明测试漏掉了关键问题。
14. 追踪 CI 流水线时长（按阶段）；目标为 lint <2 分钟、单元 <5 分钟、集成 <10 分钟、E2E <15 分钟、完整 <30 分钟；红灯时先优化最慢阶段，把快速检查（每次 push）与慢速检查（PR 合并）分开，分析 setup 与执行时间占比，并行化串行阶段。
15. 计算 CI 每次运行成本 =（计算分钟数 × 每分钟成本）+ 固定成本；例如每天 50 次构建、每次 $0.50 = 每月 $750；通过缓存依赖、使用 spot 实例、合理配置 runner、跳过未变更的测试套件来优化。
16. 计算并行效率 =（串行总时间 /（墙钟时间 × worker 数））× 100，目标 >80%；示例：4 个 worker 分别耗时 3、3、3、12 分钟 → 墙钟 12、串行总 21，效率 = 21/(12×4) = 44%，远低于目标，因为三个 worker 各空闲 9 分钟；修复方法：按预估时长（而非文件数）拆分、拆解慢测试文件、使用动态分片（Playwright sharding、Jest `--shard`）。
17. 追踪自动化率 =（自动化测试用例数 / 总测试用例数）× 100；目标为回归 90%+、冒烟 100%、探索性 0%（按定义）、整体 70-85%；优先自动化执行最频繁的场景。
18. 追踪测试创建速度：每个 sprint 新增的自动化测试数（净新增，不含重构）；目标为每个交付的用户故事至少 3-5 个自动化测试；一个 sprint 交付 20 个功能却 0 个新测试，说明覆盖缺口在扩大。
19. 计算自动化 ROI：手工成本 =（每轮手工时间 × 每年轮数）× 时薪；自动化成本 =（编写时间 + 年度维护时间）× 时薪；ROI =（手工成本 - 自动化成本）/ 自动化成本 × 100；示例：手工回归 8 小时/次 × 26 次/年 × $75/小时 = $15,600/年；自动化编写 120 小时 + 每年维护 40 小时 × $75/小时 = 第 1 年 $12,000、之后每年 $3,000；第 1 年 ROI = (15,600-12,000)/12,000 = 30%，第 2 年 ROI = (15,600-3,000)/3,000 = 420%；用此向干系人论证投入。
20. 用 DORA 指标作为领导层交付仪表盘的标准词汇，与缺陷逃逸率配对（DORA 追踪交付吞吐，QA 指标追踪交付质量）：变更前置时间（commit → 生产，top-15% <1 天）、部署频率（top-15% 每天多次）、失败部署恢复时间（原 MTTR，变更引发的故障恢复时间，top-15% <1 小时）、变更失败率（top-15% 约 5%，旧的高绩效标准为 <15%）、返工率（因上次坏部署而产生的非计划修复占比，越低越好）；注意 DORA 2025 将返工率正式列为第五个指标并重新分组（前三项为吞吐，变更失败率 + 返工率为不稳定性），可靠性（可用性、延迟、错误预算）作为独立维度与 SLO 一起追踪；DORA 2025 取消了 Elite/High/Medium/Low 分级，改用百分位分布和七种团队原型，该列应读作百分位基准而非“等级”；失败部署恢复时间（2023/2024 报告改名）将变更引发的故障与外部故障分开，是交付指标，与 QA 缺陷 MTTR 不同；数据来源 https://dora.dev/research/，从 Git/CI 数据生成 DORA 的工具包括 Sleuth、Faros、LinearB、Jellyfish、Swarmia。
21. 把测试影响分析（TIA）作为杠杆：根据代码变更（用覆盖率数据）选择要运行的测试，以测试广度换 CI 成本；追踪每个 PR 因 TIA 跳过的测试百分比（越高 CI 越便宜，若上升而覆盖率不降说明 TIA 有收益）以及因跳过测试导致的逃逸缺陷数（安全校验，若非零则收窄 TIA 选择或扩大始终运行的集合）；托管方案有 Datadog Test Optimization (TIA)、CloudBees Smart Tests、NCrunch（IDE 内），自建方案可从覆盖率数据 + git diff 推导。
22. 按公司阶段设定现实目标：种子轮到 A 轮 / B-C 轮 / 大型企业分别为——单元覆盖率 60%/75%/85%，分支覆盖率 45%/60%/75%，E2E 覆盖（关键路径）top 5 流程/top 15 流程/所有 P0/P1 流程，flakiness <5%/<3%/<1%，7 天通过率 >90%/>95%/>98%，缺陷逃逸率 <20%/<10%/<5%，P0 MTTR <8 小时/<4 小时/<2 小时，CI 流水线时长 <20 分钟/<15 分钟/<10 分钟，自动化率 50%/75%/90%，追踪指标数 3-5 个核心/8-10 个带仪表盘/全套带告警。
23. 按渐进路径推进：先上 3 个指标（代码覆盖率、flakiness rate、缺陷逃逸率）；CI 成本或速度成为痛点时加执行指标；团队超过 5 名工程师时加流程指标；质量成为产品差异化或合规要求时上全套；完整分阶段 rollout（逐周）、三种仪表盘布局和数据源提取表见 `references/rollout.md` 和 `references/dashboards.md`。
24. 避免反模式：不要把覆盖率当作质量证明（需配合变异测试）；不要脱离上下文看指标（“覆盖率 74%”需配目标 80%、趋势从 69% 上升、分布 92% 关键路径 / 40% 管理后台）；不要刷指标（用琐碎测试凑覆盖率，需用缺陷逃逸率配对制衡）；不要追踪过多指标（追踪 25 个等于一个都不行动，从 3 个开始，只有能说清触发什么行动才加）；不要只测量不行动（没人看的 Grafana 仪表盘；若某指标一个季度都没触发过行动就退役它）；不要跨团队比较（支付服务与管理后台的覆盖率不可比，应看自身随时间改进而非跨团队排名）。
25. 验证反馈回路真正跑通：1）覆盖率工具输出机器可读格式（`coverage/coverage-final.json`、`lcov.info`），而不只是人读的 HTML；2）CI 历史可查询——调用 CI 提供商 API 取最近 7 天运行结果，确认能算出通过率和 flakiness；3）逃逸标签存在——在 issue tracker 中查询 `escaped-defect`（或等价）标签，确认至少标签约定已就位；4）门禁真的会拦——开一个临时 PR 降低覆盖率或加 `.skip`，确认 CI 会失败，从不触发的门禁证明不了任何事。
26. 完成标准：关键指标已用明确公式定义（行/分支覆盖率、flakiness rate、缺陷逃逸率、按严重程度的 MTTR）；每个指标基于至少 2 周收集的数据建立基线，并按公司阶段表设定目标；数据采集通过 CI 集成自动化（覆盖率来自测试运行器、flakiness 来自 CI 运行历史、缺陷来自 issue tracker 标签），无手工步骤；CI 中配置质量门禁，在 flakiness 超阈值、覆盖率下降或关键测试失败时阻止合并或部署（用失败的临时 PR 验证）；每个指标有具名负责人，回顾模板（或固定日历邀请）中有指标区块——是可检查的产物而非意图。

适用边界 · 注意事项

• 不适用于构建仪表盘 UI（Allure/Grafana）——那属于 qa-dashboard 技能。
• 不适用于测量覆盖缺口和变异分数——那属于 coverage-analysis 技能。
• 不适用于尚未有任何 CI/测试数据可采集的团队（需先有 CI 运行历史和覆盖率输出，否则无法建立基线）。