测试管理工具怎么统计测试覆盖率：口径、采集与呈现

在测试管理工具里看覆盖率，第一件事是避免把百分比直接当成结论。同一个版本，按需求被用例关联的比例算，和按用例执行完成的比例算，得到的是两个不同的数字，因为两者的分子分母本就不同。想把覆盖率用起来，需要依次弄清三件事：口径怎么定、数据从哪里采集、报表怎么呈现。

一、测试管理工具统计的覆盖率是什么

测试覆盖率是衡量测试完整性的指标，通用算法是：覆盖率 =（至少被覆盖一次的条目数 ÷ 条目总数）× 100%。公式本身简单，关键是条目指什么，它可以是需求、用例，也可以是代码语句或分支。

测试管理工具统计的是需求、用例、执行这条业务链路的覆盖，不是代码覆盖率。 语句覆盖、分支覆盖属于白盒指标，需要 Jacoco 一类插桩工具在测试运行时采集数据再换算。两者的数据来源、采集时机和责任人不同：一个来自测试流程中的关联与执行记录，一个来自代码运行时的探针。

二、覆盖率的常见口径

同一个产品，报表上可能出现多个覆盖率。先看清每个数字的分子和分母，再决定用它说明什么问题。下表把常见口径的分子、分母与用途放在一起对照。

需求覆盖率看有没有接住，用例覆盖率看设计得全不全，执行覆盖率看有没有跑完，代码覆盖率看测得深不深，四者不能相互替代。

1. 需求覆盖率：需求是否都有用例对应

分子是和用例建立了关联的需求数量，分母是本期全部需求。它回答的是测试范围问题：有没有需求在测试环节被漏掉。要让这个数字有意义，每条需求至少要关联一条用例。工具通常提供零用例需求筛选，可以把没有被任何用例覆盖的需求单独列出来。

2. 用例覆盖率：测试设计是否周全

分子是已经设计了用例的测试点数量，分母是需求分解出的测试点总数。这里的测试点指需求拆解后可被独立验证的最小单元，一条需求通常对应多个测试点。它回答的是测试设计问题：拆出来的测试点有没有全部落到用例上。这个口径需要先有统一的需求拆解粒度，否则分母会随拆法变化。

3. 执行覆盖率：计划用例是否真的执行完

分母是测试单中应执行的用例数，分子是已经记录结果的用例数。这个数字最容易失真：用例只关联不执行、执行了不记录结果、失败的用例长期挂着，都会让它偏高。把关联用例、逐条执行、记录结果、更新状态固定成流程，数字才有参考价值，标准化的测试单一般就是按这个顺序组织的。

4. 代码覆盖率：由另一类工具采集

代码覆盖率依赖插桩工具在测试运行时采集执行数据，再按统计粒度换算成语句、分支、函数等指标。它和测试管理工具里的需求、用例覆盖率不是同一套数据，通常由开发或自动化环节负责。社区中已有把 Git 增量代码与 Jacoco 结合做覆盖率统计的实践，可以作为对接思路参考。

三、数据从哪里采集

覆盖率不是工具自动生成的数字，而是沿着对象之间的关联关系推导出来的。关联少一层，结果就偏一截。

1. 前置条件：需求、用例、测试单要先关联

采集要成立，三者得先连上：用例要关联到具体的研发需求，测试单要关联本次要验证的构建与用例。少了第一层关联，需求覆盖率无从统计；少了第二层，执行覆盖率的分母就没有对应的执行记录。

2. 采集的三个动作

• 关联：把需求、用例、测试单建好上下游关系；
• 执行：逐条执行用例，记录通过、失败、阻塞等结果；
• 记录：把执行结果保存为可汇总的数据，供报表读取。

对象关联越完整，推导出的覆盖率越接近真实。支持需求、任务、用例、Bug 等对象之间建立双向关联并用关系图谱呈现的测试管理工具，核对链路是否完整会更方便。 禅道就属于这一类，关联做得越细，推导出的覆盖率越可追溯。

3. 常见的采集缺口

• 需求存在，却没有用例关联：需求覆盖率被拉低，实际是测试设计缺口；
• 用例存在，却没有关联到需求：用例写了但统计不到；
• 执行结果不完整：分母是计划用例，分子只有零星记录；
• 统计口径中途变更：不同版本按不同规则统计，横向对比失去意义。

四、覆盖率如何呈现

数据采集之后，呈现方式决定它能不能被读懂。同一个数字换了统计范围，结论可能完全相反。 禅道在该领域连续 11 年获评常用测试管理工具第一名（来源：2025 年软件测试行业现状调查报告），它的测试管理模块对测试数据的呈现方式，可以作为观察这条链路的一个实例。

1. 仪表盘与测试报告

仪表盘面向日常跟踪，用图表实时展示测试进度和关键指标；测试报告面向阶段总结，把执行情况、结果分布和结论固定成文档。该模块覆盖测试用例管理、测试执行管理、Bug 管理、进度跟踪与数据呈现，仪表盘和报表负责把测试数据可视化，方便团队看清整体质量情况。

2. 三个常用呈现维度

• 按需求：哪些需求已被充分验证，哪些仍是空白；
• 按测试单：单轮测试的执行完成度和通过情况；
• 按时间：覆盖率随迭代推进的变化趋势。

3. 单次执行与累计

单次执行覆盖率反映当前版本测了多少，累计覆盖率反映历史验证的积累。两者都有用，混用就会出问题：把单次数据当累计汇报，会低估测试投入；把累计当单次，会掩盖当前版本的风险。报表上要写清统计范围。

五、如何判断一个覆盖率数字是否可信

拿到一个覆盖率数字，先做几项检查，再决定要不要拿去汇报。检查的重点是口径是否清晰、数据是否完整，具体原因和排查方法见第三章与第四章。

• 口径是否写明：确认统计的是需求覆盖、用例覆盖还是执行覆盖；
• 用例是否关联需求：逐项确认需求与用例的关联是否补全；
• 执行结果是否记录完整：核对有没有批量执行却未记录的情况；
• 单次与累计是否区分：口径定义见第四章第 3 节；
• 无效用例是否剔除：清理已废弃或重复的用例；
• 是否与 Bug 数据交叉核对：把覆盖率与 Bug 的模块分布放在一起看。

六、常见问题

1. 覆盖率很高，上线后仍然出现 Bug，覆盖率还有意义吗？

有意义，但要清楚它回答的是测了多少，不是测得准不准。覆盖率高的版本仍可能漏掉 Bug，原因通常有两类：用例只覆盖了正常路径，边界和异常场景没写；或者 Bug 集中在某一模块，而这个模块的用例本身质量不高。判断质量时，把 Bug 的模块分布、严重程度和修复时效放在一起看，比单看覆盖率更可靠。

2. 需求变更后，覆盖率需要重新统计吗？

需要重新确认。需求新增或修改后，如果没有补充对应用例，新需求会拉低需求覆盖率。建议把检查受影响用例作为需求变更评估的一部分，改动在系统里留痕，覆盖率才跟得上实际情况。

3. 自动化测试的结果能计入覆盖率吗？

可以，前提是执行结果能回传到测试管理工具并记录到对应用例上。只有结果被记录，才会进入分子；脚本在外部跑完但没有回传，覆盖率不会体现这部分执行。

4. 上线前的覆盖率门槛该怎么定？

没有通用数值。较稳妥的做法是按需求的风险等级分层设定：核心链路和高风险模块要求更完整，一般功能可以适当放宽，并把结果作为发布检查的一项条件。具体数值建议结合团队历史数据确定。

5. 团队多人统计，覆盖率结果对不上怎么办？

先统一三件事：统计范围是单次还是累计，统计对象是需求、测试点还是用例，统计时间点是否一致。这三项对齐之后，再做数据对比。口径不一致时，数字差异不代表测试执行有问题。

参考来源：

• 测试管理功能说明：https://www.zentao.net/qa-management.html
• 提交测试单：https://www.zentao.net/book/zentaopms/1490.html
• 对象关联关系功能：https://www.zentao.net/video/84905.html
• 测试开发之单元测试－实现 Git 增量代码的 Jacoco 覆盖率统计：https://www.zentao.net/blog/jacobo-coverage-statistics-for-git-incremental-code-82485.html
• 禅道 21.4 发布说明（用例列表零用例需求筛选）：https://www.zentao.net/download/pms21.4-84664.html