测试用例复用率衡量一个统计周期内被重复使用的测试用例占可用用例资产的比例，常用口径为“被引用次数≥2的用例数÷被引用过的用例总数”。这个数字能说明用例库被重复调用的程度，但要得出质量或效率结论，还需要固定统计范围、引用事件定义和去重规则，并与缺陷逃逸、执行耗时、维护成本等指标一起看。下文给出一套可复算的计算方法，并说明结果如何落到用例库的日常管理中。
要点总览（TL;DR）
- 复用率常用口径为“被引用次数≥2的用例数÷被引用过的用例总数”，也可按引用次数加权计算复用次数占比，两种口径不能混用。
- 计算前要固定用例库范围、时间窗、引用事件定义和去重规则，并写明分母为零、用例改版、归档用例的处理方式。
- 复用率反映资产被重复调用的程度，没有通用达标线，需与缺陷逃逸率、执行耗时、维护成本组合解读，并防范重复挂载凑数。
- 算出结果后应落到管理动作：排查粒度过细与场景绑定过强、建立公共用例层、核查引用真实性、配合评审与归档。
- ONES TestCase 的用例库、测试计划与执行记录可作为引用事件的取数基础，复用率是否内置统计需以实际环境为准。
评估目标：复用率要回答什么问题
复用率首先服务于一个具体判断：团队沉淀的测试用例，有多少在后续测试活动中被再次调用。它衡量的是资产被重复使用的程度，回答“用例库是否在被使用、哪些部分被反复使用、哪些部分长期闲置”。测试负责人可以用它决定用例库的投入方向，用例库维护者可以用它识别需要整理、合并或归档的用例，项目测试团队可以用它了解本项目的用例有多少来自既有资产。
需要把复用率和另外两类问题分开。测试质量关注的是缺陷发现能力和漏测情况，通常用缺陷逃逸率、线上问题数、用例覆盖的需求比例来衡量；测试效率关注的是单位时间内完成的工作量，通常用执行耗时、自动化执行占比、回归周期来衡量。复用率提高可能带来执行准备时间下降，也可能只是同一批用例被反复挂进不同计划而并未真正执行。把复用率单独当作质量结论或绩效结论，容易把“资产被调用”误读为“测试做得更好”。
因此，在开始取数之前，建议先写清楚这张指标要支撑的决策问题，例如：
- 本季度用例库中新增用例的后续复用情况如何，是否值得继续按当前粒度沉淀？
- 核心模块与边缘模块的用例复用差异在哪里，公共用例层是否需要补充？
- 跨项目引用是否在发生，哪些项目在贡献可复用资产？
- 长期零引用的用例是否应进入归档评审？
每个问题对应不同的统计范围和分层方式，先定问题再定口径，可以避免算出一个无法指导行动的数字。
指标与范围：分子、分母和统计边界
复用率有两种常用口径，选择哪一种取决于要回答的问题。
按用例条数计算：复用率 = 统计期内被引用次数≥2的用例数 ÷ 统计期内被引用过的用例总数 × 100%。这个口径衡量“有多少条用例真正被重复使用”，适合评估用例库资产结构。
按执行次数加权计算：复用次数占比 = 统计期内超出首次引用的引用次数 ÷ 统计期内总引用次数 × 100%。这个口径衡量“引用量中有多少来自重复使用”，适合观察复用对测试工作量的实际贡献。
两种口径的分子分母含义不同，不能混用，也不能互相替代。对外汇报时应注明采用哪一种。
| 定义项 | 说明 | 需要固定的内容 |
|---|---|---|
| 统计单位 | 用例条数或引用次数 | 选定后全周期保持一致 |
| 时间窗 | 季度、月度或版本周期 | 起止日期，引用事件按发生时间归入 |
| 用例库范围 | 项目内、跨项目、全组织 | 明确纳入哪些项目或用例库 |
| 用例状态 | 在用、草稿、归档 | 明确哪些状态计入分母 |
| 分层维度 | 用例类型、模块、优先级 | 至少按模块和优先级分层输出 |
统计范围直接决定结果的可比性。项目内口径只统计本项目用例被本项目测试计划引用的情况，适合项目级复盘；跨项目口径统计用例被其他项目引用的情况，适合评估共享资产的价值；全组织口径把全部用例库纳入，适合用例库维护者做整体盘点。三种范围算出的数字不能直接比较，跨团队对比时必须确认双方采用同一范围。
分层统计同样必要。总体复用率会被用例数量最多的模块主导，核心模块的高复用可能被大量边缘模块的零引用稀释。按模块、用例类型（功能、接口、性能、兼容性等）和优先级分别输出，才能看出结构性问题。
数据口径与证据：引用事件怎么记
复用率的可靠性取决于“引用事件”定义得是否清楚。一条用例被复用的典型事件包括：被其他用例前置引用或步骤引用、被多个测试计划纳入、在同一计划或不同计划中被多次执行、被关联到多个需求或研发任务。团队需要从中选定计入的事件类型，并写进口径说明。
数据来源通常分布在几处：用例管理系统提供用例清单、模块归属和用例间引用关系；测试计划记录用例被纳入哪些计划、由谁执行；执行记录提供实际执行次数和结果；需求关联记录提供用例与需求的对应关系。取数时应把这些来源的字段对齐，例如用例唯一标识、用例所属项目、引用发生时间、引用来源对象。
| 字段 | 来源 | 用途 | 质量要求 |
|---|---|---|---|
| 用例ID | 用例管理系统 | 去重主键 | 全局唯一，改版后保持不变 |
| 所属项目/模块 | 用例管理系统 | 分层统计 | 与统计范围一致 |
| 引用来源 | 测试计划、用例引用关系 | 判定复用事件 | 记录引用对象与时间 |
| 执行时间与结果 | 执行记录 | 区分真实执行与仅挂载 | 执行人、时间完整 |
| 需求关联 | 需求管理 | 辅助判断复用场景 | 关联关系可追溯 |
去重规则要提前写明。同一用例在同一测试计划中被多次执行，按条数口径只计为一次引用；按次数口径则按实际执行次数累计。同一用例被多个计划引用，条数口径计一次，次数口径按计划数或执行次数累计。用例改版后，如果用例ID保持不变，历史引用继续归属该用例；如果改版产生新ID，应在口径中说明新旧ID的映射方式，否则改版会被误算为新增用例。归档用例一般不计入分母，但其历史引用记录仍可用于追溯。
数据缺失的处理原则也应写入说明：引用来源字段缺失的记录不计入分子，并在报告中注明缺失比例；执行记录缺失但计划中存在挂载的，按“仅引用未执行”单独统计，不混入真实执行次数。
计算与评估步骤：从取数到出结果
下面五步可以让其他人按同一口径复现结果。
步骤一：确定统计周期与用例库快照。选定起止日期，导出周期结束时点的用例清单作为分母基础，包括用例ID、模块、类型、优先级、状态。快照时点要与引用事件的统计窗口对齐，避免周期内新增用例被漏计或重复计入。
步骤二：抽取引用事件并去重。从测试计划、用例引用关系和执行记录中抽取周期内的引用事件，按用例ID归集，剔除重复记录。输出一张“用例ID—引用次数—引用来源数—执行次数”的明细表。
步骤三：按公式计算总体与分层复用率。先算总体：被引用次数≥2的用例数除以被引用过的用例总数。再按模块、类型、优先级分别计算，并同时给出按次数加权的复用次数占比。分层结果应附各层用例数量，避免小样本层被过度解读。
步骤四：与执行记录、缺陷数据交叉核对。抽查复用率较高的用例，确认其引用是否伴随真实执行；对比执行耗时和缺陷发现数据，判断复用是否带来实际测试活动。若某模块复用率显著高于其他模块，核对该模块是否存在大量计划挂载但未执行的情况。
步骤五：记录口径版本以便复算。把统计范围、时间窗、引用事件定义、去重规则、数据缺失处理方式写成版本化的口径说明，与结果一起存档。下一周期沿用同一版本，才能做趋势对比；口径调整时保留新旧两版结果，注明变化原因。
例子：一个季度复用率的完整算例
以下为演示数据，用于说明计算过程，不代表任何团队的实际水平。
某项目2024年第三季度用例库快照共800条在用用例，其中核心模块300条、边缘模块500条。周期内被引用过的用例共400条，其中被引用次数≥2的有160条；周期内总引用次数为1000次，其中超出首次引用的引用次数为600次。
按条数口径：复用率 = 160 ÷ 400 × 100% = 40%。按次数口径：复用次数占比 = 600 ÷ 1000 × 100% = 60%。两个数字差异较大，说明少数用例被高频引用，而多数被引用用例只用了两次左右。
| 分层 | 在用用例数 | 被引用用例数 | 引用≥2次的用例数 | 条数口径复用率 |
|---|---|---|---|---|
| 核心模块 | 300 | 240 | 132 | 55% |
| 边缘模块 | 500 | 160 | 28 | 17.5% |
| 合计 | 800 | 400 | 160 | 40% |
分层结果显示核心模块复用率明显高于边缘模块，后续管理动作应优先检查边缘模块的用例是否场景绑定过强、粒度过细。
分母为零的情形：若某新项目本季度尚未建立测试计划，被引用用例数为0，此时复用率不计算，报告中标注“本期无引用事件”，而不是记为0%。记为0%会与“有用例但无人复用”混淆。
用例改版的情形：某条核心用例在周期内拆分为三条，若沿用原ID并保留映射，原用例的历史引用仍归属原ID，拆分后的新用例从拆分时点起单独统计；若未保留映射，拆分会被计为三条新增用例，复用率被人为拉低。口径说明中应明确采用哪种处理方式。
解读与限制：复用率高说明什么、不能说明什么
复用率没有通用达标线。不同产品形态、不同测试阶段的合理区间差异很大，稳定运行的产品回归用例复用率通常高于快速迭代的新功能测试。解读时应以自身历史趋势为主，同口径对比上一周期、上一版本，观察变化方向和变化来源，而不是对照一个外部数字判断好坏。
跨团队、跨项目比较需要格外谨慎。用例粒度、引用事件定义、统计范围、是否包含自动化用例，任何一项不同都会让结果不可比。确需比较时，先对齐口径说明，再比较分层结果，并注明样本量。
复用率需要与其他指标组合解读：
- 与缺陷逃逸率一起看：复用率上升而缺陷逃逸率同步下降，说明既有用例在回归中发挥了作用；复用率上升但缺陷逃逸率恶化，可能说明复用的用例覆盖不到新风险。
- 与执行耗时一起看：复用带来的准备时间下降是否真实发生，可以用回归执行总耗时和单条用例执行耗时验证。
- 与维护成本一起看：用例被高频引用时，改版和维护的连带影响更大，需要评估维护投入是否随之上升。
还要防范指标被刷高。常见做法包括：把同一用例重复挂入多个计划但不执行、把一条用例拆成多条互相引用、用无实际测试意义的引用关系凑数。核查方式是抽查引用事件的执行记录，比较引用次数与执行次数的比例，对引用集中度过高的用例做人工复核。
把复用率纳入用例库日常管理
复用率偏低时，先排查原因再动手。常见原因有三类：用例粒度过细，一条用例只覆盖一个操作步骤，难以在其他场景中整体调用；场景绑定过强，用例描述中写死了特定项目的数据和环境，换项目就无法使用；缺少公共用例层，登录、权限、基础配置等通用场景没有沉淀为可被引用的基础用例。对应动作分别是合并过细用例、把项目相关数据抽为参数或前置条件、建立公共用例模块并在评审中要求优先引用。
复用率异常偏高时，重点核查引用真实性。抽取引用次数排名靠前的用例，核对执行记录是否匹配；检查是否存在批量挂载计划而未执行的情况；对拆分后互相引用的用例组做合并评估。核查结果应反馈到用例评审环节，把“引用是否有实际执行支撑”作为评审检查项。
用例评审与归档机制需要与指标配合。新用例入库时评审其可复用性，明确适用场景和前置条件；长期零引用的用例进入归档评审，由维护者判断是补充适用说明、合并到其他用例，还是归档。归档动作本身会让分母变化，因此归档应在周期结束后统一执行，并在口径说明中记录。
这些管理动作依赖可追溯的引用数据。在 ONES 中，TestCase 支持编写测试用例并组织用例库，用例库采用树状模块结构，用例属性支持筛选，便于按模块和类型做分层盘点；用例可与产品需求、研发任务关联，测试计划与迭代关联，测试计划中可为用例分配执行人，执行记录由此沉淀。测试负责人可以基于用例库、测试计划与执行记录整理出“用例—计划—执行”的对应关系，作为复用事件的取数基础，再按本文口径自行计算复用率。需要说明的是，复用率是否已有现成统计报表、引用事件能否直接导出，需以实际使用环境为准；在缺少内置报表时，按上述字段从用例库和测试计划中导出明细再计算，同样可以得到可复算的结果。
常见问题
统计期内用例库有新增用例，分母应该用期初快照还是期末快照？
两种做法都可以，关键是全周期保持一致并写进口径说明。用期末快照会把周期内新增的用例纳入分母，这些用例在周期内可被引用的时间较短，可能拉低复用率；用期初快照则只统计周期开始时已存在的用例，新增用例留到下个周期评估。若希望同时观察新增用例的后续复用情况，可以按入库时间分层输出，把周期内新增用例单独列为一层，与存量用例分开计算。
一条用例被多个测试计划引用，但只在其中一个计划中执行过，算复用吗？
取决于选定的引用事件定义。按条数口径，只要该用例在本周期内被引用次数≥2，通常计入复用；按次数口径，则应按实际执行次数累计，仅挂载未执行的计划不计入执行次数。建议在明细表中把“引用来源数”和“执行次数”分列记录，报告中同时给出仅引用未执行的比例，避免把计划挂载直接当成真实复用。
跨项目引用用例时，复用率应该按哪个项目的口径算？
先明确指标服务对象。若评估用例库资产价值，应以用例所属项目或全组织为统计范围，统计该用例被其他项目引用的次数；若评估某个项目的测试准备情况，则以该项目为范围，统计其引用了多少外部用例。两种范围的结果含义不同，不能直接比较。跨项目引用还涉及权限与可见性配置，取数前需确认引用关系在系统中可被完整记录。
复用率连续两个周期下降，应该先查什么？
先确认口径是否变化，包括统计范围、引用事件定义、用例状态是否调整，以及是否有归档动作改变了分母。口径一致的前提下，再按模块和用例类型分层看下降集中在哪一层：新增用例多而尚未被再次引用、公共用例层被拆分、测试计划数量减少，都会带来下降。分层结果指向具体原因后，再决定是调整用例粒度、补充公共用例，还是等新增用例进入下一轮回归后再观察。
ONES 中能否直接导出复用率报表？
现有官方资料介绍了 ONES TestCase 的用例库、测试计划、执行人分配与质量统计报表能力，未说明是否提供复用率或引用次数的现成统计。实际使用时可先确认所用环境中的报表覆盖范围；若没有现成报表，可从用例库导出用例清单，结合测试计划与执行记录整理“用例—计划—执行”的对应关系，再按本文口径自行计算。
