测试用例管理工具的用例复用率怎么算：3 个可采集的数据

想从一个测试用例管理工具里点开报表就看到现成的"用例复用率"，多半会失望。这个指标在行业里没有强制统一的口径，公开的 TMMi 测试度量体系整理资料把它归为可选的效率类指标，给出的公式是 已复用的测试用例数 ÷ 测试用例总数 × 100%（TMMi 测试度量体系整理，2024 年）。分子怎么认定、分母框多大，会让同一批用例算出 20% 和 60% 两个完全不同的结果。

与其纠结哪个公式更标准，不如先把数据来源固定下来。只要工具里能稳定取到三类数据，用例复用率就能按月复算、跨版本对比：用例库的导入记录、用例的来源与创建方式、测试单关联用例的历史构成。

下面按"定口径、取数据、代入计算、排错验证、形成趋势"的顺序展开，取材步骤以禅道为例，换其他工具思路一致，只是字段名称不同。

先定口径：分子和分母各有几种取法

公式本身只有一个骨架。

用例复用率 = 本期复用的测试用例数 ÷ 本期测试用例总数 × 100%

真正需要拍板的是"复用的用例"怎么认定。常见的分子取法有三种。

分母也有三种常用范围：本期新增用例、本期实际执行用例、本期测试单关联用例。选哪个取决于你想回答什么问题。关心资产是否在沉淀，看新增侧；关心回归测试的投入是否下降，看执行侧。

一套口径至少要写清四件事：统计周期、统计对象是产品或团队、分子的认定标准、分母的范围。口径换过之后，历史数据不能直接连成趋势线，需要重新起一条基线，并在报告里注明断点。

数据一：用例库的导入记录

用例库解决的是跨产品复用的取数问题。禅道的用例库把不同测试模块或测试功能点所引用到的测试用例做分类管理，库中的用例可以导入到所有产品，常见于浏览器兼容性测试、安全测试、性能测试这类跨产品场景。

这项只需要采集四个字段：导入时间、导入人、来源分类、目标产品。四个字段合起来，就构成跨项目复用的分子。

取数入口在测试管理的用例库视图里：用例库的创建在「测试 - 用例库」视图完成；需要引用时，在用例视图点击右上角的「导入」，选择「从用例库中导入」。

需要留意的是，用例库如果长期没人整理分类，导入记录会越来越少，复用率也跟着往下走。这个下降反映的是库本身的质量问题，不是团队不愿意复用。把这层区分讲清楚，指标才不会被误读。

数据二：用例的来源与创建方式

分子和分母都依赖这一项，所以用例的来源字段必须能被区分出来。至少覆盖四种：新建、从用例库导入、Excel 或 Xmind 批量导入、复制已有用例。

本期新增用例条数，是新增侧口径的分母；其中带导入来源的条数，就是分子。禅道的用例支持 Excel、Xmind 格式的导入导出，批量核对可以直接用导出的文件做，用例步骤最多支持三层，够覆盖大部分业务场景。

复制是最难采集的一类。复制出来的用例不会留下导入记录，系统里看就是一条新建用例。两种补救方式：在用例命名规则或标签里带上来来源标识；或者把复制改造的用例单独归类，不计入严格口径的分子，只在需要观察时统计。

数据三：测试单关联用例的历史构成

前两项数据取自用例资产本身，这一项取自执行侧。测试单用来明确测试范围、工作优先级和期望完成时间，是针对特定构建创建的测试用例清单，通常由开发人员发起、测试人员接收。

要统计的是：本期测试单关联的用例里，有多少条不是本期新建的。这个比例更贴近"复用到底省下了多少回归工作量"。

取数方式很直接：在「测试 - 测试单」视图打开测试单，通过「关联用例」按需求、Bug 范围筛选，也可以按套件和之前的测试版本快速关联；创建测试单时还可以选择「按套件关联」。关联完成后，测试单的用例清单就是现成的统计底表。

有一个计数偏差要避开。同一条用例出现在多个测试单里时，按用例条数统计会把重复执行算成多次复用；如果关注的是执行成本，就按关联次数统计，并在报告里标明单位。单位不同，数字之间不能直接比较。

把三个数据代入公式：一个可复算的示例

下面这组数字是示例，不是行业基准，只用来演示两种口径的差异。

代入后得到两个数字。

• 新增侧口径：46 ÷ 120 × 100% ≈ 38.3%，反映新写的用例里有多少直接来自共享资产。

• 执行侧口径：208 ÷ 320 × 100% = 65.0%，反映这一轮测试里有多少用例属于复用。

两者差出一倍多，原因是分母不同：新增侧只统计本期新写的用例，执行侧统计所有被执行的用例。判断资产是否在沉淀看前者，判断回归成本是否下降看后者。把两条线画在同一张趋势图上，比争论哪个数字更准更有价值。

读数之前，先排掉三个常见误判

复制粘贴被算成复用。 复制一条用例改两个字段，在系统里和新建没有区别。这类操作计入分子，复用率会虚高，而且掩盖了用例质量没有提升的事实。

分母只统计新增用例。 新增少的时候，复用率反而显得高。一个版本只写了 10 条新用例、导入 6 条，算出来是 60%，但这不代表测试效率好，只说明这个版本的新增测试需求本来就少。

废弃用例没有清理。 库里躺着不再执行的用例，会同时污染分子和分母。建议按版本或季度做一次失效标记，把停用的用例排除在统计范围外。

配套的验证方法是抽查。每月抽一部分标记为复用的用例，核对前置条件、测试数据和预期结果是否被改动，改动比例超过约定的线就归入改造复用，单独统计。抽查不必追求覆盖率，能暴露口径漂移就够了。

让复用率变成一条可用的趋势线

采集动作本身不复杂，难的是坚持下去。把三件事固定下来，指标才有对比价值。

责任与周期。 由测试负责人或 QA 负责人每月或每迭代导出一次，随版本报告一起归档，避免临时补数。

口径文档。 把前文那四件事写进团队的测试规范，口径变更时同步更新基线，换人接手也不用重新解释一遍。

配套指标。 和用例执行率、缺陷逃逸率放在一起看。复用率高、缺陷逃逸率同时上升，说明被复用的那批用例没有跟上需求变化，需要回到用例维护上找原因。

数据尽量留在系统里。效能分析类看板可以把用例执行情况和缺陷分布放在同一处查看，减少手工台账；用例散落在个人文档里的团队，可以先用文档管理统一归档，再考虑迁移。口径定好之后，用自己的用例库在在线演示里试算一次，比讨论公式更快达成一致。

常见问题

用例复用率有没有公认的合格线

没有。TMMi 的度量体系把它列为可选指标，本身就说明它是按组织目标取用的。不同团队的产品形态、用例库成熟度差别很大，与其对标外部数字，不如先和自己的上个月比。

用例复用率和用例执行率、通过率有什么区别

执行率看的是计划执行的完成度，通过率看的是执行结果，复用率看的是用例资产被重复使用的程度。三个指标回答不同问题，混在一起汇报最容易产生误读。

用例还放在 Excel 里，怎么统计复用

两种做法。一种是统一迁移到测试管理工具，用导入记录和测试单关联清单自动取数；另一种是保留 Excel，在用例表里加一列"来源"，用固定取值标记新建、导入、复制，代价是每次统计都要人工核对，适合用例量不大的团队。

参考来源

• 《TMMi 测试成熟度模型集成：建立目标驱动的测试度量体系》，知乎专栏，2024 年 11 月，https://zhuanlan.zhihu.com/p/3948512844

• 禅道产品说明：质量管理功能（用例库、测试单、用例管理），https://www.zentao.net/qa-management.html