qa-metrics

一套拥有 4,000 个测试的测试套件，其中 800 个被禁用、200 个不稳定，在幻灯片上看起来很健康，到了生产环境却会暴露问题。本技能定义了真正能改变行为的指标——每项指标都有公式、目标、负责人，以及指标变红时的具体行动——让仪表板成为反馈闭环，而不是装饰。

快速导航

你的情况	可参考的指标	章节 / 参考资料
还没有指标，不知从何入手	代码覆盖率、不稳定率、缺陷逃逸率	核心原则 + references/rollout.md
覆盖率很高，仍有 Bug 逃逸	缺陷逃逸率 + 变异分数	覆盖率指标、缺陷指标
测试不稳定，开发者忽略 CI	不稳定率、通过率	测试健康度指标
流水线缓慢，反馈滞后	测试套件耗时、并行效率	执行指标
需要证明自动化投入的价值	自动化投资回报率	流程指标
为当前阶段选择目标	公司阶段表	设定切合实际的目标
领导层关注交付和质量	DORA + 逃逸率	工程质量指标（DORA）
构建仪表板视图	（前往 qa-dashboard）	—

---

调研问题

先检查 .agents/qa-project-context.md——如果该文件存在，就以它为基础，并跳过其中已有答案的问题。然后：

当前状态

• 你们目前在跟踪哪些指标？（即使只是“偶尔看一下 CI 通过率”也算。）
• 测试数据存放在哪里？（CI 系统、覆盖率报告、Bug 跟踪器、电子表格，或者没有）
• 你们已有仪表板吗？谁会看，多久看一次？
• CI 流水线使用什么工具运行？（GitHub Actions、GitLab CI、Jenkins、CircleCI）

利益相关方

• 质量指标涉及哪些利益相关方？（工程、产品、领导层、客户）
• 他们各自关注什么？工程师关注不稳定性；领导层关注逃逸趋势；产品关注发布信心。
• 谁负责每项指标？如果没人负责，就没人会采取行动。

质量问题

• 哪些质量问题需要纳入监控？（回归、流水线缓慢、测试不稳定、覆盖率缺口、事件）
• 最近生产环境中出了什么问题？指标能否更早发现？
• 目前有哪些决策是在缺少数据的情况下做出的？

目标

• 对你们团队来说，“健康的测试套件”意味着什么？
• 是否有合规或合同规定的质量要求？（SLA、SOC2、ISO）
• 你们更倾向于快速见效，还是全面可观测性？愿意投入多少资源建设指标基础设施？

---

核心原则

1. 指标应驱动行动，而不只是填充仪表板

没有行动计划的指标只是装饰。每项指标都要明确：什么阈值会触发行动、要采取什么行动，以及由谁负责。如果不稳定率超过 5%，值班工程师应在当周调查最不稳定的 3 项测试。不要留有歧义。

2. 领先指标与滞后指标——两者都要跟踪，重点关注领先指标

缺陷逃逸率和 MTTR 是滞后指标：用户受到影响后，你才会得知问题。不稳定率、覆盖率变化和跳过的测试数量是领先指标：它们能在缺陷逃逸之前发出预警。滞后指标告诉领导层质量是否在改善；领先指标则是工程师日常关注的重点，因为他们仍有机会改变结果。

3. 看趋势，而非单个快照

单个数字几乎毫无用处。覆盖率为 72% 本身说明不了什么；覆盖率在三个冲刺周期内从 68% 升至 72%，才能说明情况。以时间序列展示指标，并评估趋势方向，而非绝对值。

4. 每项指标都需要目标和负责人

目标让指标可用于行动；负责人则让指标有人担责。缺少其中任何一项，指标都会沦为背景噪声。根据团队的成熟度设定目标（参见目标表），并指定真正能推动指标变化的负责人。

5. 虚荣指标浪费所有人的时间

“我们有 4,000 个测试”听起来很了不起，直到你发现其中 800 个已禁用，200 个不稳定。要统计真正重要的内容：实际运行、稳定通过并能捕获真实错误的测试。最终指标是用户是否遇到了损害业务的错误——从这个结果倒推。缺陷逃逸率直接关联用户体验；测试代码行数则毫无关联。

---

必备 QA 指标

每项指标都包括：定义、公式、建议目标、重要原因，以及指标变红时应采取的行动。

测试覆盖率指标

我们的系统有多少经过自动化测试验证？（先行指标）

代码覆盖率

自动化测试执行过的代码所占百分比（按行、分支或语句级别统计）。

Line coverage   = (lines executed by tests / total executable lines) × 100
Branch coverage = (branches executed by tests / total branches) × 100

**目标：**应用代码的行覆盖率：70-85%。分支覆盖率：60-75%。关键路径（支付、身份验证）：90% 以上。

**重要原因：**覆盖率可以发现盲点——从未被测试执行过的代码，正是错误可能藏匿且无法被发现的地方。

**指标变红时：**PR 中覆盖率下降：阻止合并或标记出来。关键模块覆盖率低：创建有针对性的任务。覆盖率停滞：检查是存在死代码，还是确实有未经测试的逻辑。

**警告：**覆盖率衡量的是代码执行情况，而非断言质量。结合变异测试（StrykerJS v9.6+、mutmut），才能更准确地评估。Stryker 的 Vitest 运行器会跟进近期的 Vitest 发布版本——固定 Vitest 版本前，请检查该运行器的 peer-dependency。在 monorepo CI 中使用 incremental: true，以降低变异测试的运行成本。有关深入的覆盖率／变异分析，请参阅 coverage-analysis。

需求覆盖率

Requirement coverage = (features with at least one test / total features) × 100

**目标：**P0/P1 功能达到 100%，P2 达到 80% 以上。

**重要原因：**即使周边代码覆盖率很高，某个功能仍可能完全没有测试。使用测试标签（@feature:checkout、@story:PROJ-1234）以便追踪。

风险覆盖率

Risk coverage = (high-risk areas with automated tests / total high-risk areas) × 100

**目标：**高风险领域达到 95% 以上。维护风险登记表，并与各模块的覆盖率数据交叉对照。

---

测试健康度指标

我们能信任测试套件吗？（先行指标）

不稳定率

代码未发生变化时，测试运行结果不一致的百分比。

Flakiness rate = (test runs with flaky results / total test runs) × 100

**目标：**可接受：<2%。警告：2-5%。严重：>5%。

**重要原因：**不稳定测试会侵蚀信任。一旦开发者认为“可能只是测试不稳定”，就会完全不再关注测试结果。不稳定性是对测试套件可信度的最大威胁。

**指标变红时：**立即隔离不稳定测试。每周调查排名前 3 的测试——大多数不稳定问题都集中在少数测试上。常见原因：时序／竞态条件、共享状态、外部依赖、测试顺序依赖。不稳定超过 30 天的测试应删除或重写。

**检测工具：**Buildkite Test Analytics、Datadog Test Optimization（原名 Datadog CI Visibility——提供 Flaky Test Management、Auto Test Retries、Early Flake Detection、Failed Test Replay 和 Test Impact Analysis；其 Bits AI Dev Agent 可以自动创建 PR 来修复不稳定测试）、Trunk Flaky Tests，或用于比较同一提交在多次运行中结果的脚本。

通过率趋势（7 天滚动）

Pass rate = (green CI runs / total CI runs) × 100  [rolling 7 days]

**目标：**健康：>95%。警告：90-95%。故障：<90%。

7 天滚动平均值可以平滑每日波动，揭示真实趋势。构建持续显示红色，意味着开发者会忽视流水线。

已禁用和跳过的测试数量

标记为 skip、disabled、pending、xit、xdescribe 或等效状态的测试总数。

**目标：**持续趋近于零。跳过超过 2 个冲刺周期的测试：修复或删除。添加一个 CI 步骤，在跳过测试数超过测试总数的 5% 时使构建失败。

**重要原因：**跳过的测试会形成隐蔽的覆盖率缺口。一个有 500 个通过测试和 150 个跳过测试的套件，存在 150 / (500 + 150) = 23% 的缺口，但仪表板会将其隐藏。

测试套件耗时

从套件开始运行到完成的墙钟时间。

目标： 单元测试：<5 分钟。集成测试：<10 分钟。端到端测试：<15 分钟。完整流水线：<30 分钟（各阶段的目标才是真正的预算；<30 分钟是各阶段耗时之和，而不是另一个更宽松的门槛）。

重要性： 测试耗时过长会打断反馈循环。45 分钟后才出结果时，开发者早已切换到其他上下文。

指标变红时： 分析耗时最长的测试（通常 10% 的测试占总运行时间的 50%）。提高并行度。将耗时较长的测试移到合并后运行。检查是否存在不必要的设置和清理步骤。绘制耗时趋势图，并在出现突变时发出警报（一周内增长 >20%）。

---

缺陷指标

我们能否在用户发现之前捕获 Bug？（滞后指标）

缺陷逃逸率

在发现的所有缺陷中，生产环境中发现的缺陷所占的比例。

Defect escape rate = (defects found in production / total defects found) × 100

目标： 优秀：<5%。可接受：5-10%。需要改进：10-20%。严重：>20%。

计算示例： 某个版本共暴露出 15 个缺陷，其中 2 个出现在生产环境中 → 2 / 15 × 100 = 13.3% 的逃逸率，属于“需要改进”。

重要性： 这是最重要的单项质量指标。它直接衡量测试能否在用户发现 Bug 之前将其捕获。

指标变红时： 按层级对逃逸缺陷分类（单元测试？集成测试？端到端测试？代码审查？）。为每个缺陷编写一个回归测试。找出逃逸是否集中在特定领域，并针对这些领域进行投入。

跟踪方法： 为生产环境中的 Bug 添加标签（escaped-defect）。在冲刺回顾中统计逃逸缺陷与发布前缺陷的数量。

平均修复时间（MTTR）

MTTR = sum(resolution_time for each defect) / number of defects

目标： P0：<4 小时。P1：<24 小时。P2：<1 个冲刺。P3：<2 个冲刺。

MTTR 偏高通常说明存在流程瓶颈（审查缓慢、职责不明确、部署复杂），而非技术难题。将处理过程拆分为不同阶段（分诊、分配、修复、部署），以找出瓶颈所在。（这是 QA 的缺陷解决时间，与下文的 DORA 恢复指标不同。）

缺陷密度

Defect density = defects found / KLOC  (or per feature shipped)

目标： 跟踪你自己的基准；行业基准为每 KLOC 1-10 个缺陷。如果某个模块的缺陷密度是其他模块的 5 倍，就需要重构或提高覆盖率。

严重程度分布

健康分布：P0 <5%，P1 10-15%，P2 40-50%，P3 30-40%。按时间绘制堆叠柱状图。P0/P1 占比过高，意味着测试未能发现关键问题。

---

执行指标

我们的 CI 流水线是否快速、可靠且成本效益高？（先行指标）

CI 流水线耗时

按阶段统计总墙钟时间。目标： Lint：<2 分钟。单元测试：<5 分钟。集成测试：<10 分钟。端到端测试：<15 分钟。完整流水线：<30 分钟（=上述各阶段耗时之和，并与套件耗时预算保持一致）。

指标变红时： 优先优化耗时最长的阶段。将快速检查（每次推送时运行）与慢速检查（PR 合并时运行）分开。分析设置时间与执行时间。将顺序执行的阶段并行化。

每次 CI 运行成本

CI cost per run = (compute minutes × cost per minute) + fixed costs

每天进行 50 次构建，每次 $0.50 = 每月 $750。可以通过缓存依赖项、使用竞价实例、为运行器选择合适规格，以及跳过未更改的套件来优化成本。

并行效率

Parallelism efficiency = (total sequential time / (wall-clock time × workers)) × 100

目标： >80%。示例：4 个工作进程分别用时 3、3、3 和 12 分钟完成 → 墙钟时间为 12 分钟，顺序执行总计 21 分钟，因此效率 = 21 / (12 × 4) = 44%，远低于目标，因为有 3 个工作进程各空闲了 9 分钟。可通过按预估耗时（而非文件数量）拆分任务、拆分耗时较长的测试文件，以及使用动态拆分（Playwright 分片、Jest --shard）来解决。

---

流程指标

我们的 QA 流程是否在持续改进？（先行与滞后指标兼有）

自动化率

Automation rate = (automated test cases / total test cases) × 100

目标： 回归测试：90% 以上。冒烟测试：100%。探索性测试：0%（按定义如此）。总体：70-85%。

手动测试无法规模化。自动化的收益会不断累积——测试编写完成后，可以运行数千次。优先自动化执行频率最高的场景。

测试创建速度

每个冲刺新增的自动化测试数量（净新增，不包括重构）。

目标： 每交付一个用户故事，至少新增 3-5 个自动化测试。如果一个包含 20 项功能的冲刺没有新增任何测试，就说明覆盖率缺口正在扩大。

自动化投资回报率

Manual cost     = (manual time per cycle × cycles per year) × hourly rate
Automation cost = (write time + annual maintenance) × hourly rate
ROI             = (manual cost - automation cost) / automation cost × 100

示例： 手动回归测试：每次发布 8 小时 × 每年 26 次发布 × $75/小时 = $15,600/年。自动化：编写测试需 120 小时 + 每年维护 40 小时 × $75/小时 = 第 1 年 $12,000，之后每年 $3,000。第 1 年投资回报率：(15,600 - 12,000) / 12,000 = 30%。第 2 年投资回报率：(15,600 - 3,000) / 3,000 = 420%。用这些数据向利益相关方证明投资的合理性。

---

工程质量指标（DORA）

DORA 指标是领导层交付仪表板采用的标准术语。它们与缺陷逃逸率相辅相成——DORA 跟踪交付吞吐量，QA 指标跟踪交付质量。

指标	衡量内容	基准（前 15%）
变更前置时间	提交 → 生产环境	< 1 天
部署频率	发布频率	每天多次
部署失败恢复时间（以前称为 MTTR）	在由变更引起的故障后恢复服务所需时间	< 1 小时
变更失败率	导致事故的部署占比	~5%（较早的“高绩效”标准为 <15%）
返工率	为修复先前有问题的部署而进行的非计划部署占比	低且持续下降

DORA 2025 将返工率正式确定为第五项指标，并重新划分了指标类别：上述前三项属于吞吐量（恢复时间被归入此类，因为高效团队会迅速发布修复）；变更失败率和返工率属于不稳定性。可靠性（根据 SLO 跟踪可用性、延迟和错误预算）作为单独维度一并跟踪——它将 QA/缺陷逃逸的视角与 SRE 联系起来，因为错误率和可用性是缺陷逃逸影响用户的最终表现。DORA 2025 还废除了 Elite/High/Medium/Low 这些命名等级，改用百分位分布和七种团队类型——应将该列视为百分位基准，而不是团队所属的“等级”。部署失败恢复时间这一更名（2023/2024 年报告）将由变更引发的故障与外部中断区分开来；它是交付指标，与上文 QA 缺陷 MTTR 不同。

来源：https://dora.dev/research/。可从 Git/CI 数据呈现 DORA 指标的工具：Sleuth、Faros、LinearB、Jellyfish、Swarmia。

将测试影响分析（TIA）作为一种杠杆

TIA 根据代码变更情况（利用覆盖率数据）选择要运行的测试。它以测试广度换取 CI 成本。跟踪以下指标：

• 通过 TIA 跳过的 PR 测试占比——比例越高，CI 成本越低；如果比例上升而覆盖率没有下降，说明 TIA 正在发挥作用。
• 由跳过的测试导致的逃逸缺陷——安全检查指标。如果不为零，应缩小 TIA 的选择范围，或扩大始终运行的测试集。

托管服务：Datadog Test Optimization（TIA）、CloudBees Smart Tests、NCrunch（IDE 内）。自行构建：根据覆盖率数据和 git diff 得出。参见 coverage-analysis。

---

设定切合实际的目标

目标应与团队的成熟度相符。种子轮阶段的初创公司若一味追求企业级指标，只会浪费精力。

指标	初创公司（种子轮至 A 轮）	成长期（B 轮至 C 轮）	企业（上市公司/大型企业）
单元测试覆盖率	60%	75%	85%
分支覆盖率	45%	60%	75%
端到端覆盖率（关键路径）	前 5 个流程	前 15 个流程	所有 P0/P1 流程
不稳定率	<5%	<3%	<1%
通过率（7 天）	>90%	>95%	>98%
缺陷逃逸率	<20%	<10%	<5%
MTTR（P0）	<8 小时	<4 小时	<2 小时
CI 流水线时长	<20 分钟	<15 分钟	<10 分钟
自动化率	50%	75%	90%
跟踪的指标	3-5 个核心指标	8-10 个并配有仪表板	完整指标套件并配有告警

推进路径：

1. 从 3 项指标开始：代码覆盖率、不稳定率、缺陷逃逸率。
2. 当 CI 成本或速度成为痛点时，加入执行指标。
3. 当团队规模超过 5 名工程师时，加入流程指标。
4. 当质量成为产品差异化因素或合规要求时，采用完整指标套件。

有关完整的分阶段推行方案（按周安排）、三种仪表板布局以及数据源提取表，请参见 references/rollout.md 和 references/dashboards.md。

---

反模式

• 把覆盖率当作质量证明。 覆盖率衡量的是执行情况，而非验证效果。应结合变异测试来检验测试的有效性。
• 指标缺少上下文。 “覆盖率为 74%”毫无意义，除非同时提供目标（80%）、趋势（从 69% 上升）和分布情况（关键路径 92%，管理功能 40%）。始终同时呈现目标、趋势和明细。
• 钻指标空子。 编写简单测试来达到覆盖率指标。可同时考察缺陷逃逸率作为制衡——如果覆盖率很高，但仍有缺陷逃逸，说明测试不够有效。
• 指标太多。 跟踪 25 项指标，往往一项也无法据此采取行动。先从 3 项开始。只有在能够明确说明某项指标会触发什么行动时，才添加它。
• 衡量却不采取行动。 Grafana 仪表板无人查看。如果某项指标一个季度内都没有触发过行动，就将其弃用（参见 references/rollout.md 中的指标半衰期检查）。
• 跨团队比较。 支付服务与管理工具的覆盖率不可直接比较。应跟踪随时间的改进情况，而非跨团队排名。

---

验证

核心在于建立有效的反馈闭环——在宣布完成前，先证明数据确实能够流通：

1. 覆盖率会生成机器可读的输出。 运行覆盖率工具，并确认它会写入 JSON/LCOV（coverage/coverage-final.json、lcov.info），而不只是供人查看的 HTML 报告。
2. 可以查询 CI 历史记录。 调用 CI 提供商的 API，获取最近 7 天的运行结果，并确认能够据此计算通过率和不稳定率。
3. 存在缺陷逃逸标签。 在问题跟踪系统中查询 escaped-defect（或同等）标签，并确认至少已建立标签使用规范。
4. 质量门禁确实会阻止操作。 创建一个临时 PR，降低覆盖率或添加 .skip，并确认 CI 会使其失败——从未触发过的门禁毫无证明力。

---

完成标准

• 明确定义关键指标的计算公式：覆盖率 %（行和分支）、不稳定率、缺陷逃逸率，以及按严重程度划分的 MTTR。
• 根据至少 2 周的收集数据，为每项指标建立基线，并按照公司发展阶段表设定目标。
• 通过 CI 集成自动收集数据（覆盖率来自测试运行器，不稳定率来自 CI 运行历史，缺陷来自问题跟踪系统标签），不需要人工操作。
• 在 CI 中配置质量门禁，当不稳定率超过阈值、覆盖率下降或关键测试失败时，阻止合并或部署（通过会失败的临时 PR 验证）。
• 每项指标都有明确的负责人，并且定期回顾模板中包含指标区块（或设有固定日历邀请）——这是一项可核查的产物，而非仅仅停留在意向上。

参考文件（位于 references/）

• dashboards.md — 工程（每日）、管理层（每月）和冲刺健康度仪表板布局，以及发布信心评分示例权重。
• rollout.md — 按周划分的四阶段实施计划、数据源提取表，以及指标半衰期弃用实践。

相关技能

• qa-dashboard — 构建展示这些指标的 Allure/Grafana/SaaS 仪表板 UI；此处关注衡量什么，该技能负责呈现方式。
• coverage-analysis — 深入分析覆盖率缺口和变异分数；为此处的覆盖率指标提供断言质量输入。
• ci-cd-integration — 配置生成这些指标所依赖原始数据的 CI 流水线，包括作为成本杠杆的测试影响分析。
• release-readiness — 使用质量门禁以及 DORA 变更失败率 / 部署失败恢复时间来作出是否放行的决定。
• test-reliability — 对不稳定率标记出的不稳定测试进行逐项运行时修复。
• quality-postmortem — 行动项关闭率与逃逸率配对，作为复盘侧指标。
• qa-project-context — 为指标跟踪提供目标和基线。