用例库管理平台操作指南：分层、标签与用例复用的实操方法

用例库管理平台是否好用，通常不取决于用例写了多少条，而取决于三件事：分层有没有定规矩、字段维度够不够用、已经写好的用例能不能被下一轮迭代直接复用。前两件事决定团队能否从上千条用例中筛出本轮要执行的那几十条，第三件事决定回归测试要不要每次从零开始。

下文按操作依赖顺序展开：先分清模块树、用例库、套件的职责，再定分层粒度与命名规则，补齐字段与列表标签之后，落到三条复用路径，并用测试单执行与 Bug 闭环中的可观察结果做验证。涉及菜单路径的操作以禅道官方文档为准，版本相关的说明标注了对应出处。

一、先分清三者职责：模块树、用例库、套件

在禅道中，测试用例挂在产品维度下组织。进入测试-用例页面，左侧是该产品的模块列表，列表下方提供模块维护入口，可以维护一级模块和子模块（参见官方手册《创建测试用例》）。模块树决定一条用例长期归属在哪里。

用例库回答的是另一个问题：这条用例以后还能不能再用。项目里常用的用例可以导入用例库，用来积累用例资产、支持复用和管理（参见官方手册《撰写用例》）。

套件回答第三个问题：这一轮要跑哪些场景。在测试单里关联用例时，既可以按测试单所关联构建中的需求检索，也可以按套件筛选。这里的构建指开发提交、等待测试的版本包。

三者的职责不同，混用是后续返工的主要来源。

解读很直接：模块树需要稳定，套件需要灵活，把一个功能域的用例和一轮测试的场景混为一谈，后续往往要返工。

二、模块树分层：粒度与命名规则

模块树的维护入口在测试-用例页面左侧的模块列表下方，可以维护一级模块与子模块。粒度上，实践中比较稳的做法是止步于三层：第一层按产品线或子系统，第二层按功能域，例如登录、订单、支付，第三层按页面、接口或业务规则分组。再往下不要继续建层，模块内部的差异用字段区分，比不断加层级更容易维护。

命名有两条规则。模块名用名词，不用动词；避免出现其他、临时、待定这类兜底模块，这类模块出现后通常会快速堆积难以归属的用例。模块名尽量对齐需求模块，这样建用例时所属模块与相关研发需求能一致对应，需求到用例的追溯才能成立。

单条用例只放一个测试点。禅道把用例步骤拆成独立记录，每个步骤可以设置自己的预期值，步骤支持在前、在后插入和删除。官方手册提示，不要把若干条用例作为步骤写进一条用例里，那样不利于测试管理和统计。

调整已有用例的归属不必逐条编辑：用例库的用例列表支持批量设置所属模块（禅道 21.4 版本发布说明）。分层规则定完之后，存量用例要一次性迁到新模块下，避免新旧结构长期并存。

三、字段维度：内置分类字段、自定义字段与列表标签

字段维度决定了用例库管理平台的检索效率。禅道用例本身带有若干分类字段：用例类型包括功能测试、性能测试、配置相关、安装部署、安全相关、接口测试，另外还有适用阶段（指用例适用的测试阶段，例如冒烟、回归，支持多选）、优先级，以及所属模块与相关研发需求。这些字段就是现成的检索维度：回归范围按适用阶段筛，接口专项按用例类型筛，比逐层翻模块树更快。

需要说明的是，禅道用例没有单独的标签字段，团队日常说的用例标签，由内置分类字段和自定义字段共同承担。团队自己的维度，例如业务线、终端类型、数据链路，可以在后台的用例字段设置中自定义，部分版本位于自定义下、部分版本位于功能配置下，以当前版本为准（参见官方手册《自定义》）。字段建好之后要一并决定三件事：是否设为必填、导出模板里是否保留、由谁维护取值。同一维度的取值必须统一，不能既写安卓又写 Android 又写移动端，否则筛选结果会对不上。

用例列表中的 B、R、S 同样是可用维度。B 指该用例产生的 Bug 数，R 指执行结果数，S 指步骤数。可以把它们作为盘点参考：B 高而 R 低，通常说明这条用例能稳定发现问题，值得优先保留；R 持续累积而 B 长期为零的用例，可以在评审时讨论合并或降低执行频率。需要提醒的是，B 高也可能反映该功能改动频繁或本身质量较弱，判断时要结合需求变更情况，不宜只看这一个数值。

盘点出来的结论要落地，就得有评审机制承接：用例评审流程默认关闭，在后台的用例评审流程设置中开启后，新建用例的状态为待评审，评审权限在权限设置里为测试-用例分配，不同版本入口位置不同，以当前版本为准（参见官方手册《创建测试用例》）。规模化团队要在用例量上来之前决定是否开启评审，中途再改，会留下一批状态不一致的历史用例。

四、用例复用的三条路径

三条路径解决的复用范围不同：一条把项目用例变成可跨项目使用的公共资产，一条把零散用例组合成可重复执行的场景，一条让同一批用例在版本之间延续下去。

1. 把项目用例沉淀进用例库

操作入口是测试-用例页面的导入功能，也可以先用导出中的导出模板功能得到模板文件，在模板里填好标题、步骤等内容再批量导入。填模板前先确认规则：步骤与预期逐步换行，序号与内容之间用点号分隔，某一步没有预期要留空；如果某一步没有填写步骤，这一步的预期无效；用例的默认必填项是用例类型和用例标题，缺失的记录会被忽略（参见官方手册《导入 excel、csv 参考文档》）。导入完成后会进入导入数据查看页，确认无误再保存。

导入完成只是第一步。21.4 版本起，批量导入页面的步骤与预期组件与批量创建页面保持一致，批量创建和批量编辑都能直接维护步骤与预期，历史用例批量入库不必逐条重写。

2. 用套件把跨模块用例串成场景

当同一组用例在一个迭代以上反复一起执行时，值得建套件。套件在测试管理的套件管理入口下维护，创建套件后把这条业务链路上相关的用例加入进去，不同版本入口位置可能不同，以当前版本界面为准。套件的价值在测试单关联用例时体现最明显：按套件筛选，一次就能选中这组用例，不用按模块逐个勾选。

3. 跨版本与跨场景复用

按官方手册说明，关联用例时默认关联最新版本的用例，也可以通过下拉框切换到历史版本，具体默认行为以当前版本界面为准（参见官方手册《管理测试版本》）。前置条件和附件的修改会更新用例版本，用例标题的版本管理也在同一版本中得到优化，用例详情的历史记录中会展示每次执行的结果。复用旧用例之前先看它的执行历史，比直接沿用更稳妥。

复用的边界也要说清楚：复用不等于免维护。跨版本复用前确认适用阶段与影响模块没有变化，否则旧用例会带着过期的预期进入新版本，失败结果反而增加排查成本。

五、验证配置是否生效：从测试单执行到 Bug 闭环

配置是否生效，看测试单能不能跑通。新建测试单后关联用例，逐一执行并记录结果，包括通过、失败、阻塞等，测试单状态会随执行进展从未执行变为进行中、已完成。禅道 21.4 版本发布说明（2025 年 1 月）中写明，执行用例后测试单状态会自动更新，测试单列表也增加了开始、关闭、激活操作，状态维护不再依赖手工修改（见版本发布说明）。

失败用例提 Bug 的链路要提前接通。同一版本中，提 Bug 页面增加了来源用例的选择，Bug 可以直接挂到来源用例上，用例详情页的相关 Bug 也会展示状态信息。只有这条链路接通，用例列表中的 B 值才有判断价值。

一轮回归跑完后，用三条可观察结果验收：

• 用例库列表能按模块与字段筛出本轮回归范围；
• 执行用例后测试单状态自动变化，不需要人工干预；
• 失败用例能带出来源提 Bug，用例详情能看到对应 Bug 及其状态。

六、落地顺序与常见问题

1. 落地顺序：四周跑完一遍

• 第 1 周：确定三层模块规则，维护一级与二级模块；
• 第 2 周：明确必填字段与自定义字段的取值，同步更新导出模板；
• 第 3 周：选 20 到 30 条高频用例导入用例库，形成首批公共资产；
• 第 4 周：用一轮真实回归验证，建测试单、关联用例、执行、失败用例带来源提 Bug，并复盘 B、R、S 三个数值。

顺序不宜调换：先定分层，再补字段，之后才谈复用。 反过来做，复用会把错误的分层和缺失的字段一起放大。

2. 常见问题

本轮迭代的需求已经排进去，怎么确认它有没有对应用例？

在项目或执行的用例列表中，可以用零用例需求筛选条件筛出尚未对应用例的需求（禅道 21.4 版本发布说明）。先补齐这部分覆盖，再谈用例复用，顺序更合理。

一条用例步骤特别多，能不能在用例内部再分组？

可以。创建用例支持用例分组，能够根据测试需要创建分组并填写子步骤，适合主流程步骤较长的场景。分组只在一条用例内部生效，跨用例的场景组合仍然用套件。

需要把用例导出去给外部团队评审或归档，怎么做？

用例支持把选中的记录或全部记录导出，也可以自定义导出字段并把模板命名保存，供下次直接使用（参见官方手册《撰写用例》）。归档时建议固定使用同一套模板，避免每次导出的列不一致。

用例库管理平台的价值不在功能数量，而在于分层稳定、字段可用、用例能复用这三件事同时成立。先把模块树定成较长时间不用调整的结构，再把字段取值收敛成团队自己能维护的范围，复用的收益才会出现在下一轮回归里。