测试用例复用要解决的核心问题，是让用例从个人电脑里的文档变成团队可检索、可判断适用范围、有人维护的共享资产。复用的前提是能准确找到并放心使用，因此分类字段、版本关联和定期清理比用例数量更重要。本文按建库、分层、分工、示例和验证的顺序，说明一套可执行的测试用例复用机制，并说明ONES TestCase在用例库组织和协作流程中可承载的环节。
要点总览（TL;DR）
- 测试用例复用要先判断用例是否值得入库：覆盖稳定业务规则或高频回归、有明确适用前提、有确定的维护人，三条同时满足再进入共享资产库。
- 实施路径分五步：盘点现状、建库分层、定义复用规则、建立维护机制、验证效果，每步都要有可检查的交付物。
- 资产库按业务模块、测试类型、通用与专用用例分层，字段至少覆盖用例编号、适用版本、前置条件、关联需求、维护人、最近验证时间和复用记录。
- 通用用例只保留与项目无关的规则性步骤，项目差异通过参数和差异说明记录在复用记录中，不改写用例本体。
- 效果验证先固定复用率、失效用例占比和回归覆盖的口径，再按字段完整、Owner明确、复用记录可追溯、定期清理已执行逐项核对。
测试用例复用的核心答案与操作步骤
判断一条用例是否值得进入共享资产库，可以看三个条件：它覆盖的是稳定的业务规则或高频回归场景；它有明确的前置条件和适用范围，别人能判断自己是否适用；它有确定的维护人，能在需求变化时被及时更新或下线。一次性验证、强依赖某台测试机或某个临时数据的用例，留在项目内更合适。
满足条件的用例进入资产库后，按以下五步推进。每一步都要有可检查的交付物，避免停留在口头约定。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 盘点现状 | 各项目现有用例文档、测试计划、缺陷记录 | 收集散落用例，按业务模块归类，标记重复与过期内容 | 用例现状清单，含重复项和候选入库项 | 候选入库用例有明确清单和初步归属模块 |
| 2. 建库分层 | 现状清单、业务模块划分 | 确定分层结构和字段，把候选用例录入资产库 | 可检索的用例资产库 | 每条入库用例的关键字段填写完整 |
| 3. 定义复用规则 | 资产库结构、项目测试流程 | 约定哪些用例可跨项目复用、复用时如何记录差异、变更如何通知 | 复用规则说明 | 规则经测试团队确认，新项目启动时按规则取用 |
| 4. 建立维护机制 | 复用规则、角色名单 | 指定模块Owner和评审人，设定定期验证与清理周期 | 角色分工表与维护日历 | 每个模块有明确Owner，清理周期已排入计划 |
| 5. 验证效果 | 复用记录、资产库状态 | 统计复用率、失效用例占比和回归覆盖情况，复盘调整 | 效果评估记录与改进项 | 指标口径固定，能按月或按版本输出 |
五步中，第2步和第4步决定机制能否长期运转。库建得再整齐，如果没人负责更新，半年后资产库就会积累大量与实际不符的用例，复用者失去信任，复用行为自然退回个人复制。建议把第4步的维护责任在第2步建库时就同步确定，而不是等库建完再补。
用例资产库的分层与字段设计
资产库的分层要服务于“找到”和“判断适用”两个动作。常见的组织方式是按业务模块作为一级目录，测试类型作为二级分类，再在模块内区分通用用例与项目专用用例。业务模块对应产品功能域，测试类型可包括功能验证、边界与异常、兼容性、性能等。层级不宜过深，三级以内通常足够，过深会让维护人难以判断用例该放哪里。
通用用例与项目专用用例的边界需要提前约定。通用用例只保留与具体项目无关的规则性步骤和预期结果，项目之间的差异通过参数、前置条件或差异说明记录，不改写通用用例本体。项目专用用例单独存放，并在字段中标注所属项目，避免被其他项目误用。当某个项目专用用例在多个项目中反复出现时，再评估是否提炼为通用用例。
字段设计以支撑检索和适用范围判断为准，不必追求大而全。建议至少包含以下字段：
| 字段 | 作用 | 填写要求 |
|---|---|---|
| 用例编号 | 唯一标识，便于引用和追溯 | 按模块加序号规则生成，入库后不随意变更 |
| 所属模块 | 定位业务范围 | 与分层目录一致 |
| 测试类型 | 区分验证目的 | 从约定枚举中选择 |
| 适用版本 | 判断用例是否对当前版本有效 | 标注适用版本范围或关联的需求版本 |
| 前置条件 | 说明执行前提 | 写清数据、环境、账号等必要条件 |
| 关联需求 | 追溯需求变更影响 | 关联到对应需求条目 |
| 维护人 | 明确更新责任 | 具体到人，不用团队名代替 |
| 最近验证时间 | 判断用例是否仍然可信 | 每次执行或复核后更新 |
| 复用记录 | 记录被哪些项目或测试计划使用 | 复用时追加，含差异说明 |
字段确定后，检索能力决定复用效率。用例库中所有属性都支持筛选，能让执行人员按模块、测试类型、适用版本快速缩小范围。ONES TestCase支持编写用例、组织用例库，并可自定义用例属性以适配不同业务场景；用例模块支持树状结构和拖拽排序，便于按上述分层组织用例。这些能力对应的是“库怎么建、怎么找”，字段的具体取值规则仍需团队自行约定。
角色分工与交付物
复用机制涉及四类角色。测试负责人对机制本身负责，模块用例Owner对用例内容负责，执行测试人员对复用后的差异回写负责，评审人对入库和重大变更把关。角色可以兼任，但职责要落到具体交付物上，否则资产库容易变成无人认领的公共目录。
| 角色 | 主要职责 | 入库环节交付物 | 复用环节交付物 | 更新与下线环节交付物 |
|---|---|---|---|---|
| 测试负责人 | 制定分层与字段标准、复用规则和维护周期 | 资产库规范文档 | 复用规则说明与培训记录 | 定期清理计划与执行结果 |
| 模块用例Owner | 负责本模块用例的入库质量、更新与下线判断 | 经自检的模块用例集 | 对复用咨询的答复与适用范围确认 | 更新记录或下线说明 |
| 执行测试人员 | 按规则取用用例，记录实际差异和执行结果 | — | 复用记录，含参数调整与差异说明 | 执行中发现的问题反馈 |
| 评审人 | 评审入库用例和重大变更 | 评审意见与通过结论 | — | 重大变更的评审记录 |
评审和交接需要设定触发时机，避免所有变更都走评审造成负担。建议在三种情况下触发评审：新用例首次进入通用资产库；通用用例的步骤或预期结果发生实质性修改；用例因需求下线而标记失效。日常的参数调整和差异记录由执行人员直接回写，不需要评审。交接发生在维护人变更或模块负责人调整时，交接内容应包括未完成的更新项和已知的适用范围限制。
在工具层面，ONES TestCase支持为不同用户组配置不同权限，并支持为用例库、测试计划单独配置权限，可用于区分Owner的编辑权限与执行人员的查看和复用权限。用例与产品需求、研发任务关联，测试计划与迭代关联，能让复用记录和需求变更在同一流程中被追溯。
示例：一条通用用例如何被复用
以下为演示情景，用于说明复用过程，不代表真实项目数据。
假设资产库中有一条通用用例“用户登录失败次数达到阈值后锁定账户”。入库时，它归属“账号与权限”模块下的“功能验证”分类，标记为通用用例。关键字段填写为：用例编号ACC-LOGIN-012；适用版本为当前主版本及后续兼容版本；前置条件为存在可用的测试账号且锁定策略已配置；关联需求为账号安全策略需求；维护人为账号模块Owner；最近验证时间为入库当月；复用记录初始为空。
项目A在迭代中需要验证登录安全，执行人员按模块和测试类型筛选到这条用例。项目A的锁定阈值为5次，与用例默认参数一致，执行人员直接引用，在复用记录中登记项目A和测试计划编号，执行后在最近验证时间字段更新日期。
项目B的锁定阈值为3次，且增加了管理员解锁步骤。执行人员没有改写通用用例本体，而是在复用记录中登记项目B，并写明参数差异：阈值改为3次，增加管理员解锁验证步骤。执行完成后，项目B的差异说明保留在复用记录中，供后续类似项目参考。
两个项目复用后，账号模块Owner在定期复核时查看复用记录，发现项目B的管理员解锁步骤在多个项目中重复出现，评估后将其提炼为通用用例的一个可选步骤分支，并更新适用版本说明。若某次需求变更取消了账户锁定策略，Owner将该用例标记失效并注明原因，而不是直接删除，保留追溯依据。
复用效果的验证与完成检查
判断复用机制是否运转，需要先固定指标口径，再逐项核对。口径不统一时，数字容易好看但说明不了问题。以下口径供参考，团队可结合自身流程调整：
- 复用率：被复用到至少一个测试计划的用例数除以资产库用例总数。该指标反映资产被实际使用的比例，统计周期建议与版本节奏一致。
- 失效用例占比：超过约定周期未验证或已标记失效的用例数除以资产库用例总数。该指标反映资产的可信程度，占比持续上升说明维护机制没有执行。
- 回归覆盖：复用用例覆盖的回归场景数除以回归场景总数。该指标反映复用对回归测试的实际支撑程度。
完成检查可按以下清单逐项核对：
| 检查项 | 判断标准 | 未达标时的调整方向 |
|---|---|---|
| 字段完整 | 入库用例的关键字段无空缺，维护人和适用版本均已填写 | 补充必填字段校验，入库前由Owner自检 |
| Owner明确 | 每个模块有具体维护人，无空白模块 | 按模块重新指派，纳入测试负责人考核范围 |
| 复用记录可追溯 | 每次复用都有项目、测试计划和差异说明 | 简化记录模板，把回写作为执行完成的必要动作 |
| 定期清理已执行 | 按约定周期完成复核，失效用例已标记并说明原因 | 把清理排入版本计划，设置固定复核时间点 |
| 指标可输出 | 复用率、失效占比、回归覆盖能按周期统计 | 先固定口径和统计范围，再逐步补齐数据来源 |
如果复用率偏低，先检查检索是否方便、字段是否足以判断适用范围，而不是直接要求提高复用数量。如果失效占比偏高，优先补维护责任和复核节奏。如果回归覆盖不足，检查通用用例是否集中在少数模块，评估是否需要补充高频回归场景的用例。ONES TestCase支持从Excel批量导入用例并在线管理，也支持用例导出与本地备份，便于在盘点阶段迁移存量用例，并在需要时保留本地副本。复用统计和失效标记等专门能力，建议结合团队实际配置方式在试用中确认。
常见问题
用例数量很多但复用率一直上不去，应该先查什么？
先查检索和判断适用范围的环节，而不是直接要求团队提高复用数量。常见原因有三类：一是分层过深或分类字段取值不统一，执行人员按模块和测试类型筛选后仍要逐条打开确认；二是适用版本、前置条件等字段空缺，看到用例也无法判断是否适用；三是资产库长期无人复核，执行人员对内容失去信任，宁可自己重写。
对应调整方式：把层级控制在三级以内，统一测试类型的枚举值；把适用版本和维护人设为入库必填；按模块指定Owner并排定复核周期。检索顺畅、内容可信之后，复用率才有提升的基础。
通用用例被多个项目复用时，项目差异应该记在哪里？
差异记在复用记录里，不改写通用用例本体。具体做法是：执行人员在引用用例时登记项目名称、测试计划编号和差异说明，差异说明写清改了哪个参数、增删了哪些步骤、预期结果是否变化。通用用例的步骤和预期结果保持稳定，这样其他项目引用时看到的仍是同一份基准内容。
当某个差异在多个项目的复用记录中反复出现时，由模块Owner评估是否把它提炼为通用用例的可选步骤分支，并同步更新适用版本说明。这样差异从个案记录逐步沉淀为通用能力，而不是每次复用都重新口头沟通。
用例因为需求下线而不再适用，应该删除还是标记失效？
建议标记失效并注明原因，保留追溯依据。直接删除会让历史测试计划和缺陷记录失去对应关系，后续排查“这个场景当时怎么验的”时无从查起。
标记失效的触发时机可以定为：关联需求正式下线、业务规则被新策略替代、连续多个复核周期无人使用且Owner确认不再适用。失效用例从默认检索结果中排除，但仍可按状态查回。失效用例占比本身也是观察维护机制是否执行的指标，删除会让这个信号消失。
评审应该覆盖所有用例变更吗？
不需要。全部变更都走评审会让流程变重，团队很快会绕过流程。建议只在三种情况下触发评审：新用例首次进入通用资产库；通用用例的步骤或预期结果发生实质性修改；用例因需求下线而标记失效。
日常的参数调整、差异说明回写、最近验证时间更新，由执行人员直接完成，不需要评审。评审人关注的是内容是否准确、适用范围是否写清、是否与已有用例重复，而不是逐字校对格式。
存量用例散落在各项目文档里，迁移时要注意什么？
迁移前先做去重和归类，避免把历史包袱整体搬进资产库。按业务模块归集后，标记出重复项、明显过期项和候选入库项，只把满足入库条件的用例迁入。迁移过程中保留原有用例编号或建立新旧编号对照，便于追溯历史执行记录。
工具层面，ONES TestCase支持从Excel批量导入用例并在线管理，也支持用例导出与本地备份，可用于存量用例的批量迁移和本地留档。导入前建议先统一字段模板，把适用版本、维护人等必填项在表格中补齐，减少导入后的二次整理。
