用例库管理平台落地指南：把散放的测试用例变成可复用资产

回归测试开始前，一个常见的场景是在几个人的聊天记录里翻找上一版登录用例：桌面上放着两份不同版本的 Excel，脑图工具里还挂着一份没有导出的清单。版本对不上，最后只能全量重跑一遍。

用例库管理平台要解决的是用例能不能被再次找到并使用，而不是用例写得够不够多。

一、散放用例卡在哪：三个断点与一次自查

1. 断点一：同一份用例存在多个版本

用例分散在个人 Excel、脑图、聊天记录和个人笔记里，每个位置都存着一份。谁改过、改的是哪一版，往往没人说得清。回归开始前先花时间核对版本，最后常常选择全量重跑，代价不在写用例上，而在每次回归前的重复确认。

2. 断点二：常见场景在每个项目里反复重写

登录、权限、审批、导入导出这几类场景，几乎每个项目都要重新写一遍。用例总量在增长，检索速度却在下降，团队会在新写的用例里反复看到过去已经验证过的场景。

3. 断点三：执行数据、Bug 与需求各在一处

测试执行记录、Bug、需求分散在不同工具或不同表格里。追一个 Bug 要翻几个地方，测试进度靠人工维护，需求变更之后受影响的用例只能靠回忆去找。

用例、执行记录、Bug 与需求能不能落在同一份数据上，决定了追溯是否成立。

4. 动手前的一次自查

在决定用什么方案之前，建议先记录两组事实。

第一组是用例分布：用例放在几个位置、每个位置由谁维护、更新频率如何。这份记录不用给别人看，它是评估迁移工作量的依据。

第二组是一次完整回归的耗时构成。把找用例、确认版本、执行、补写缺失用例四段分开计时，这一步通常会暴露出一个事实：找用例和确认版本占用的时间比预想的多。

二、用例库管理平台管什么、不管什么

1. 它提供的四件事

统一入口、分类层级、版本与复用标记、与需求及 Bug 的关联，这四件事构成用例库的基本形态。 它们指向同一个目的：让用例能被再次找到并使用。它管的是用例的组织与复用，不管用例本身写得好不好。

2. 三条边界

第一，它不等于文档网盘。 把 Excel 批量上传上去，不会自动产生复用；没有分类与命名规则，统一入口很快会退回散放状态。

第二，它不替代测试执行与 Bug 跟踪。 用例库管用例本身的组织，测试执行和 Bug 闭环属于另外的环节，但两者需要落在同一套数据上，否则关联关系是断的。

第三，它不等于自动化脚本库。 人工用例可以先复用起来，回归范围稳定之后，脚本与流水线的接入属于后续延伸。

3. 什么样的团队适合现在动手

判断依据不是团队规模，而是三个条件：是否已有专职或半专职的测试角色；回归频率是否足够高；跨项目重复的场景是否较多。三条都成立时，用例库带来的复用收益比较明确。

如果用例总量很少、一年只做一两次回归，先把表格的字段和命名规范起来，通常比引入平台更划算。

三、继续用表格、自建轻量库，还是引入平台

1. 三条路线的适用条件与代价

容易忽略的是第三列。表格在用例量小时够用，人工维护成本会随规模上升；自建方案前期灵活，后期要为检索、权限和版本持续投入；引入平台的成本集中在迁移和命名治理阶段，往后维护成本相对更低。

2. 判断顺序：先看复用和追溯

选型时建议按这个顺序判断：用例复用能不能做起来、追溯链路能不能贯通、执行数据能不能回流。这三件事决定了用例库管理平台是否值得引入。

功能清单放在后面看。它容易让人在还没想清楚链路的情况下比较参数，最后选出的工具功能齐全，但关键环节仍然是断的。

3. 选型时值得逐项确认的四件事

第一，分类与检索。 是否支持按产品、模块、功能点分层，是否支持标签检索。

第二，版本与基线。 需求变更时能否定位受影响的用例，能否对比版本差异。

第三，关联能力。 用例能否与需求、Bug、执行记录落在同一套数据上，而不是靠导出表格人工拼接。

第四，生成用例的纳管规则。 批量生成之后的导入、去重、命名、归属有没有明确的处理流程，这决定了生成结果能不能沉淀成资产。

这四项在不同工具上的实现方式差别不小，判断时建议对着实际界面确认一遍。以禅道为例，按官网测试管理功能页与使用手册的描述，用例的创建、排序、管理与复用属于基础能力，用例步骤最多支持三层，支持 Excel 与 Xmind 格式的导入导出；测试流程覆盖创建测试单、关联用例、执行用例与结果处理，并输出测试报告；用例可以关联需求，Bug 可以关联到来源用例。

四、第一步：定层级与命名，把权限收拢

1. 层级先定，命名后定

层级决定检索效率。层级过深，找一条用例要点开好几层；过浅，又不好归类。建议控制在三层左右，顶层按产品线划分。登录、权限这类跨产品共用的用例，单独设一个公共目录，避免在每个产品下重复建一套。

层级一旦确定，迁移期间不要频繁调整，否则已经归位的用例需要重新搬一遍。

2. 用例标题与字段规范

用例标题建议统一成模块、场景、预期三段式，让人一眼看出验证对象。以登录为例，可以写成：登录-密码错误-提示账号或密码不正确，三段分别对应模块、场景和预期。

字段方面，前置条件、操作步骤、预期结果这三项建议在迁移前统一补齐。预期结果要写成可判定的描述，写成功能正常这类表述的用例，执行时无法判断通过与否。

3. 规则由谁定、目录由谁维护

规则和权限如果没人负责，迁移初期容易出现各自建目录的情况，返工成本很高。

建议明确两类角色：QA 负责人负责层级与命名规则，并审批新目录的创建；用例库维护角色负责日常的目录调整与失效用例清理。目录创建权限收拢到指定角色，比事后合并目录省力得多。

五、第二步：清洗与分批迁移

1. 先迁哪些，后迁哪些

迁移不是把旧文件整体搬运，而是重建。建议按这个优先级排：高频回归场景排在前面，跨项目重复用例紧随其后，低频用例和一次性用例后置处理。

已经失效的用例不要迁进新库。它们如果继续参与回归执行，会拉长执行时间，也会让统计口径失真。

2. 清洗的五个动作

• 去重：合并同一场景的多个版本，保留描述较完整的一版。

• 合并：把同一功能点下粒度过细的用例合并，减少条目数量。

• 补全：补齐前置条件、操作步骤与预期结果。

• 标记：给跨项目可用的用例打上复用标记，这是复用率统计的基础。

• 归档：失效用例单独标记归档，与在用用例分开存放。

这五个动作建议在迁移前完成，不要把问题带进新库。

3. 不停线迁移的做法

迁移期间不需要停止正常的测试工作。常见的做法是按模块分批：先迁一个模块，新旧两份并行一段时间，确认新库里的用例能正常执行、关联关系正确之后，再停用旧文件。

每迁完一个模块做一次验收，比全部迁完之后统一检查更容易发现问题。用例导入可以借助 Excel、Xmind 格式的导入功能批量完成，字段对齐的工作要在导入前做好。

六、第三步：把用例与需求、Bug、执行记录接上

1. 需求变更后的影响定位与基线维护

需求变更时，同步更新受影响的用例版本并标记影响范围，不要等到回归前临时对版本。这个动作的价值在下一轮回归时体现：能顺着关联关系直接找到受影响的用例，不必靠回忆。

发布前设定基线，回归范围按基线确定，可以减少每次全量跑的情况。基线调整权限建议明确到人，改动留记录，避免基线被修改后无人知晓。

2. 执行记录按测试单归集

一次提测对应一个测试单，执行记录归到对应的版本下，这样每一轮测试的范围和结果都能单独核对。有两类记录方式容易出问题：多个版本共用一个测试单，追溯会断在版本这一层；用用例库总量代替本轮计划用例数，会低估实际未执行的数量。

执行结果的口径要提前统一。以禅道为例，执行结果分为忽略、通过、失败、阻塞四种，默认结果为通过。如果团队把点了执行就记为通过，通过率会偏高，发布前还要重新核对一遍。

3. 用例转 Bug 与来源追溯

执行失败的用例应该能直接转成 Bug，并且保留来源关系。在禅道中，用例执行结果不是通过时，可以通过转 Bug 生成对应记录，在 Bug 的其他相关区域能看到来源用例；用例列表里也会显示该用例产生的 Bug 数、执行次数和步骤数。

这几个字段对判断用例价值有用。产生的 Bug 数长期为零、执行次数也很低的用例，可以纳入清理评估。

七、第四步：AI 生成用例与自动化怎么接

AI 生成用例和自动化脚本都属于延伸能力，接入顺序建议是先纳管生成用例，等回归范围稳定之后再接自动化。

1. AI 生成用例入库前三件事

批量生成的用例不建议直接导入。入库前先做三件事：先过命名与层级规则，再按模块归位，最后标记生成来源与待确认状态。

直接全量导入的结果，通常是重复和版本混乱比原来更严重。生成结果往往缺少统一的粒度标准，同一个场景可能被写成多条，人工复核的成本反而更高。

2. 按置信度分层复核

人工复核如果没有重点，很容易变成逐条看一遍，看完一轮就没有第二轮了。公开实践中较常见的做法是按置信度分层：字段级重复、格式规范校验这类结果可以直接采纳；模型判断两条用例是否在测同一件事、给出的优先级排序建议，需要人工确认；涉及核心业务逻辑是否等价、安全与合规相关的用例删减，要慎重决策（来源：腾讯云开发者社区公开实践分享）。

另一个经验是把重复检测放在用例创建环节，比事后批量清洗更省力。新用例提交时提示是否与已有用例高度重叠，能从源头减少冗余。

3. 回归范围稳定后再接自动化

自动化脚本与流水线的接入建议放在用例复用稳定之后。更合理的顺序是：先让用例入口和版本治理扎实下来，回归范围清晰，再按场景把脚本接进来。

脚本与用例之间建议建立对应关系，执行结果回传用例库，避免脚本和用例两套数据各走各的。如果团队还没有稳定的回归范围，先不上流水线集成。

八、怎么判断复用真的成立

1. 三个自查指标与统计口径

这三个指标不需要和行业基准比较，用团队自己的历史数据做纵向对比即可。按模块拆分统计，还能看出复用集中在哪些场景，便于判断下一步该补哪一类用例。

2. 不能只看用例总量

用例总数增长不说明复用发生了，有时只说明重复变多了。只统计用例数量、不统计执行记录和关联情况，数据看起来会更好，但反映不了用例库管理平台是否真的在用。

关联比例长期偏低时，用例库容易退化成结构更复杂的文件存储：检索入口有了，追溯链路没有建立。

3. 做成了的可观察信号

一个直接的验证方式：随机抽一条已完成的用例，确认能否看到执行人、执行时间和执行结果；顺着需求能否找到对应用例，顺着 Bug 能否找回来源用例。

这些信息齐全，说明链路是通的；只有状态没有结果记录，说明执行口径还没有真正落地。

九、常见问题解答

用例总量上万条，历史上已经执行过的测试记录要不要一起迁？

不建议一起迁。历史执行记录属于已经结束的测试轮次，迁进新库后会与当前在用版本的记录混在一起，让统计口径变得难以区分。需要留存时，可以按版本归档在外，只把仍在使用的用例迁进来。

老用例里的截图和附件怎么处理？

附件会明显增加迁移工作量，建议分两步：先只迁文本字段，保证用例本身可用；与当前在用版本相关的截图和附件，在同模块验收时再补。失效用例的附件随用例一起归档，不再迁入。

用例库上线后，还允许成员各自留一份 Excel 吗？

迁移期间可以保留，用于新旧对照；迁移完成后建议只保留一份在用数据。个人副本继续存在，版本问题会重新出现，前面的迁移工作量会打折扣。需要离线查看时，用导出功能临时导出即可。

用例库建好之后，多久做一次清理？

建议跟着回归节奏走，每个发布周期或每个季度清理一次失效用例、重复用例和长期未执行的用例，并记录清理结果。频率不必过高，但要有固定的责任人和固定的节奏，否则清理动作容易停下来。