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

测试团队在季度复盘会上报出一个用例复用率，换个人用同一套工具重新统计，数字往往对不上。分歧通常不在公式，而在两个约定：哪些用例进分母，什么情况才算被复用。约定没有落到记录上，公式再标准也只是一个说法。

要让这个数字可用，需要把它拆回测试用例管理工具里真实存在的三类记录：用例清单、测试单的用例关联记录、用例执行历史。取全这三项，用例复用率就能算成可复现、可解释的数值，而不是一次性的口头汇报。

一、用例复用率度量的是哪一类问题

测试用例复用，通常指把已经执行过的用例，不同程度地应用到同一软件新阶段的测试中，或者应用到其他软件的测试中。用例复用率衡量的就是：存量用例里有多少条被再次投入使用。

常见的计算口径是：

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

单位为百分比。这属于行业内的通用做法，不是强制性标准定义，团队可以按自己的统计范围调整分子与分母的边界。真正影响结果的是已复用和总数这两个判定怎么落到记录上。

同一张报表里还有三个指标经常和它挨着出现，含义差别不小。下表按各自回答的问题把它们分开。

四者分母不同，混用会让结论失真。复用率反映的是用例资产的周转情况，属于效率与资产类指标，不能直接当成质量结论来用。

二、算准的两个前提：分子怎么判定，分母取到哪

分母写的是测试用例总数，但工具里的用例记录总和并不等于它。中大型研发团队的用例库里往往同时存在草稿态和已废弃的用例，还有因需求下线而被合并的用例。这些记录仍占着表里的行数，通常不会被任何测试轮次使用。把它们算进分母，复用率会被系统性拉低，这个偏差通常还会随着用例库沉淀时间变长而扩大。更合理的做法是以状态和版本作为过滤条件，取有效用例作为分母，并把过滤规则写进指标定义。

分子的判定关键在于有证据，而不是凭记忆。这里说的测试范围，指一次测试所覆盖的产品与版本组合，通常对应一张测试单。可核验的判定是：同一条用例在统计周期内进入了两个及以上测试范围，也就是被关联到不同产品、不同版本或不同迭代的测试单中。这里有两种常见误判：把同一张测试单里重复关联的同一条用例算作复用，或者把用例的复制版本当作复用。复制出来的新用例有独立编号，属于新增，不属于复用。如果用例是在原用例基础上修改而来，先看它是否保留原编号：保留的是同一条用例，另建编号的按新增处理。

分子还有两种统计口径，选哪一种会直接改变数值大小。按用例数统计，回答的是有多少条用例被再次使用；按次数统计，回答的是这些用例被使用了多少次。前者的上限是 100%，后者可以超过 100%。两个口径都可以用，前提是同一个指标在连续周期里保持不变，否则趋势对比没有意义。

三、需要采集的 3 个数据

三项数据分别落在用例记录、测试单记录和执行记录里，各自承担不同的作用。

1. 用例清单，决定分母

需要采集的字段包括用例编号、所属产品与模块、状态、当前版本、是否已自动化，以及创建和最后修改时间。用例编号用于去重，产品与模块用于区分复用发生的范围，状态和版本用于过滤出有效用例。少了状态和版本这两个字段，分母就难以定义。

2. 测试单与用例的关联记录，决定分子

关联记录要能说明三件事：用例被关联进了哪张测试单，这张测试单属于哪个产品与哪个版本，关联发生在什么时间。有了这三项，才能判断一次关联是否构成跨测试范围的复用，也才能按统计周期截取数据。只导出关联总数而不带归属信息，分子就失去了判断依据。

3. 用例执行历史，决定数据可不可信

执行历史包含执行时间、执行人、执行结果以及所属构建或版本。它的作用有两个。一是验证复用是否真实发生，一条用例被关联多次却一直没有执行记录，说明留下的只是引用关系，不是实际的测试活动。二是提供时间维度，让跨迭代复用和同一轮次内的重复关联能被区分开。

下图把三类记录的关系画成一条链路：用例清单是基数，关联记录提供复用证据，执行历史负责验证与切分。

下表把三项数据的采集位置、关键字段和容易被忽略的地方汇总在一起。

三项数据缺一项，得出的数字就只能当作粗略估计。其中最容易被忽略的是执行历史，它决定了复用率描述的是测试活动，还是只描述了引用关系。

四、把三项数据拼成一次计算

1. 先定口径和统计周期

口径要回答三个问题：分母是否只取有效用例，分子按用例数还是按次数统计，统计周期取多久。中大型团队的项目周期通常跨月甚至跨季度，周期太短会漏掉回归测试带来的复用，周期太长又会掩盖变化。比较常见的做法是按迭代或按月统计，按季度看趋势。

2. 按同一时间窗取三份数据

三份数据必须来自同一个时间窗口和同一批产品范围，否则分子分母对不上。用例清单可以用当前状态快照，关联记录和执行历史必须按时间窗口过滤。如果一份按季度取、一份按年度取，算出来的比值没有解释价值。

3. 两种口径各算一遍

按用例数统计：复用率 = 统计周期内被关联进两个及以上测试范围的有效用例数 ÷ 有效用例总数 × 100%。

按次数统计：复用率（次数口径）= 统计周期内用例被关联的总次数 ÷ 有效用例总数 × 100%。

两个数值建议同时保留，前者看有多少条用例被再次使用，后者看这些用例被使用的频次。两个口径共用同一个分母，结果可以并列汇报，也方便做跨周期比较。同一份数据在两种口径下会得到明显不同的数值，下图示意其中差异。

4. 用执行记录交叉验证

计算完成后至少做三项核对。关联的用例是否都有对应的执行记录；跨范围关联的用例是否落在不同的版本或迭代上；是否存在已废弃用例仍被关联进新测试单的情况。三项都过了，这个数字才具备对外使用的基础。

五、数值怎么读，怎么变成改进动作

复用率没有通用的合格线，它受产品形态影响很大，平台类产品与定制交付类项目的合理区间本来就不一样。更可靠的读法是看趋势和结构：连续几个周期是升是降，低复用的用例集中在哪些模块，是确实没有被使用，还是被用了却没有留下记录。

常见的低复用有几种成因。公共用例库缺失时，跨产品的通用用例只能靠复制维护，复用不会发生。命名和标签不规范时，测试人员需要用例却检索不到，明明存在的资产也用不上。需求变更后用例没有同步更新时，旧用例的执行结果长期失败，团队会逐渐不再关联它们。

相应的改进动作也围绕这几类成因展开。把跨产品、跨模块的通用用例沉淀到公共用例库，并允许从其他用例库导入；为用例补充统一的命名规则和标签，让检索能按功能点和场景命中；把用例的复用情况纳入回归测试计划的制定过程，让复用成为计划动作，而不是统计时才发现的结果。

需要防的是为了把指标做高而改变动作。为了提升复用率给用例批量挂关联，或者继续把已废弃的用例关联进新测试单，数值会上涨，覆盖漏洞和回归盲区也会随之扩大。指标涨了、测试反而变得更不可靠，这是复用率被误用后比较典型的表现。

六、这些记录在测试用例管理工具里长什么样

口径和方法定下来以后，能不能真的算出这个数字，取决于工具里有没有留下对应的记录。在禅道中，前面三项数据都对应到具体功能。用例归属于产品，也可以放在独立于产品的公共用例库中维护。公共用例库用于存放跨产品复用的用例，并支持从其他用例库导入，这两点直接决定了跨产品复用的数据能不能成立。用例本身记录所属产品、模块、用例类型、适用阶段与相关研发需求，用例的前置条件、附件等修改会更新用例版本，详情的历史记录中可以看到每次执行的结果。

测试环节对应的记录是测试单。创建构建并提交测试后，在测试单中关联测试用例，从用例列表筛选并关联，可以按测试单所关联的需求检索用例，也可以按套件筛选，随后逐一执行并记录通过、失败、阻塞等结果。复用率所需的关联与执行数据都在这个环节产生，具体的操作路径与字段以官方说明为准，可参考禅道测试管理、撰写用例、提交测试单以及公共用例库的维护。

补充一个可核验的背景：禅道官方披露的资料显示，在 2025 年软件测试行业现状调查报告中，禅道已连续 11 年入选常用测试管理工具。禅道项目管理软件集产品管理、项目管理、质量管理、效能管理于一体，在内置的项目集、项目、产品、执行四个核心管理结构下提供用例、任务、Bug 等核心概念。功能与版本差异以官网说明为准。

七、取数清单：从导出到出数的五个动作

把口径落成一次实际取数，可以按下面五个动作走。每一步的核对项都通过之后，再进入下一步；核对没过的数据不必急着计算，先处理数据质量问题。各列表页支持按筛选条件查看或导出明细，具体支持的导出格式以工具官方说明为准。

五步里最容易被跳过的是第 3 步和第 4 步。只导测试单数量，分子就没有复用证据；不看执行记录，复用率描述的只是引用关系，不是测试活动。

合表时以用例清单为主表，按用例编号左连接关联明细和执行记录，出现两次及以上的用例记为被复用，再按两种口径分别计算。导出文件建议连同导出时间和过滤条件一起留档，下个周期用同一套规则复算，趋势才有可比性。

八、常见问题

跨产品复用和同一产品跨迭代复用，要不要分开统计？

建议分开。两者的改进动作不同：跨产品复用偏低，通常是公共用例库没有建起来；跨迭代复用偏低，通常是回归测试计划没有把存量用例纳入进来。合成一个数字，问题会互相掩盖。只对外报一个数时，可以先看整体值，再按这两种范围拆开做内部分析。

同一条被多个产品共用的用例，算在哪个产品的分母里？

按产品分别统计时，容易把同一条共用用例重复计入多个产品的分子和分母，总量因此虚高。可行的处理是给共用用例设一个统一归属，例如归到公共用例库，各产品只统计从库中引用的次数；或者把口径改为按产品统计关联次数，不再统计用例条数。关键是归属规则要写进指标定义。

需求变更后失效的用例，要不要从分母里剔除？

需要，但剔除动作要有依据。判断标准通常是用例对应的需求已经下线或已被替代，并且该用例在最近一个统计周期内没有被任何测试单关联。只按状态字段筛选并不充分，废弃状态可能没有及时维护，建议把关联记录和执行记录一起作为判断条件。

用例复用率和自动化率是一回事吗？

不是。自动化率看的是用例有多少条已经由脚本执行，衡量执行方式的覆盖情况；复用率看的是用例有多少条被再次使用，衡量资产的使用情况。一条用例可以既被自动化又被多个项目复用，也可以完全手工但反复使用。两个指标经常一起看，但不能互相替代。

回到最初的问题：用例复用率算不算得准，取决于用例清单、测试单关联记录、用例执行历史这三项数据是否取全、是否同源同周期，公式只是最后一步。先把分母的过滤规则和复用的判定证据写进指标定义，再让工具按同一口径出数，这个指标才具备跨周期比较和驱动改进的价值。