测试用例库搭建，先把目标定清楚：不是把现有用例从Excel或文档搬进系统，而是让团队在需要时找得到、在新需求前复用得上、在发布前拿得出证据。按这三个结果倒推，测试用例管理工具的用法可以分成三个层次。
三层能力对应三个结果，也对应不同的工具用法。
只完成第一层，系统里留下的是一批静态文档；做到第二层，用例开始产生复用价值；走到第三层，用例才真正进入发布决策。
一、先判断建库目标
判断用例库是否建成，不看存量条数，看三个结果：找得到、复用得上、说得清。
判断当前该做哪一层，不看系统里已有多少条用例，而看三个问题。
- 新成员能否不问人找到目标用例？
- 新需求到来时，团队先查库还是先重写？
- 发布前能否从系统直接说明测了什么、漏了什么、遗留什么？
三个问题分别对应可用、复用、决策。多数团队卡在第一层，原因往往不是工具缺功能，而是字段、目录和关联关系没有统一。
二、第一层解决可用
第一层解决的是用例能不能被找到。先把字段、目录和导入规则定下来，再谈批量迁移。
1. 统一用例字段
用例至少要有标题、前置条件、操作步骤、测试数据、预期结果、优先级和关联需求。字段少而稳定，比字段多而没人填更有用。 预期结果必须可判定，写成功能正常就无法评审，也无法在失败时判断是产品问题还是用例问题。
2. 建好目录结构
目录按产品和模块分层，用例类型、适用阶段、优先级放进字段或标签。把所有维度都做成目录，会让同一批用例在多个路径下重复出现。禅道的用例模块按产品维护，创建用例时可以绑定需求模块、用例类型和适用阶段。
3. 定好导入规则
存量用例迁移前先清洗：合并重复项、补齐预期结果、标记失效用例，再通过CSV模板批量导入。禅道的用例支持单个创建、多项录入和CSV导入，常用用例可以导入用例库，具体操作可参考撰写用例。
4. 设好评审权限
用例评审只看三件事：需求点有没有遗漏、用例是否重复、预期结果是否可判定。评审通过后再进入执行，能减少后期反复改用例。权限按产品、用例库和操作类型分配，避免任何人都能批量修改公共资产。
这一层的验收信号很直接：新成员能在不询问他人的情况下找到目标用例，需求变更时能定位受影响用例。找不到，说明目录和字段还没有为检索服务。
三、第二层解决复用
第二层解决的是用例能不能被再次使用。公共库、套件和需求关联，是三个最容易被忽略的入口。
公共库解决共性，产品库解决差异。
1. 公共库与产品库
公共用例库放跨产品共用的内容，比如兼容性、安全、性能类用例；产品用例库放当前产品特有的业务场景。产品需要时从公共库导入，再按产品差异修改。禅道的公共用例库支持将用例导入不同产品，适合把通用检查项沉淀为组织资产，参见测试套件、报告和公共用例库的维护。
2. 用套件组织用例
测试套件是按同一测试目的或同一运行环境组织的一组用例。它解决的是查找和组合效率，不替代测试单。把冒烟、核心流程、异常场景分成不同套件，执行时按风险选择，不必每次从全量用例里筛。
3. 把用例挂到需求
用例关联研发需求后，需求变更时能顺着需求反查受影响用例。这样需求变更、开发完成、提测范围三者能对上。禅道的「建用例」页面可以选择相关研发需求，一次把用例与需求挂好，减少测试人员事后手工圈范围，参见撰写用例。
4. 让变更同步发生
需求变更后，先更新受影响用例，再关闭旧版本。用例长期不更新，库越大，误判越多。评审和版本记录要留下修改原因，避免只改步骤不改预期结果。
复用是否发生，看新需求启动时团队是否先查库。仍然每次从零写，说明公共库、套件和需求关联没有进入日常流程。
四、第三层解决决策
第三层解决的是用例能不能支撑发布判断。测试单、Bug回链和测试报告，把执行结果变成可追溯的证据。
1. 用测试单承接执行
测试单不是用例清单，而是一次测试任务的执行记录。 典型流程是创建构建、提交测试、生成测试单、关联用例、逐条执行、记录通过失败阻塞，最后生成测试报告。禅道的流程是创建构建、提交测试、执行测试单、生成测试报告，参见提交测试单和创建构建，提交测试。
2. 失败结果回到Bug
用例执行失败后直接转Bug，Bug保留来源用例；修复完成后回到同一用例回归，再补跑相邻用例。这样用例失败、Bug修复、回归验证是一条可追溯的链路，而不是三张互不相关的表。
3. 用报告回答发布
测试报告至少要回答：测试范围是什么、执行了多少、失败和阻塞多少、发现和遗留多少Bug、哪些用例发现了Bug。禅道的测试报告会统计测试范围、发现Bug、遗留Bug、有效Bug率和用例发现Bug率，参见测试套件、报告和公共用例库的维护。
4. 指标看趋势
需求用例覆盖率、用例通过率、有效Bug率、Bug重开率、发布后逃逸Bug，适合按版本看趋势。单次数字容易被口径和样本影响，连续几个版本的变化更能说明流程是否改善。指标用于复盘流程，不用于给个人打分。
发布前，测试负责人能直接从系统拉出报告，说明版本能不能发、风险在哪里。还需要人工拼接多张表，说明第三层还没打通。
五、按顺序落地验证
先统一字段与状态，再打通关联，最后建立评审与度量。
落地顺序不要反过来。三步同时上，团队会把精力花在补数据上，流程仍然跑不起来。
工具选择看四个能力：需求、用例、测试单、Bug是否在同一套结构里；公共用例库能否跨产品复用；执行结果能否回链到用例和需求；测试报告能否直接回答发布问题。禅道把需求、用例、任务、Bug组织在同一套结构中，测试管理覆盖用例库、用例、测试套件、测试单和测试报告，报告可导出为 Word、HTML（测试报告导出为付费版本功能，开源版不含）。据禅道官网表述，其已助力100万+团队构建研发管理平台；软件测试网（51Testing）《2025软件测试行业现状调查报告》显示，禅道在「公司常用测试管理工具」中的使用率为38.9%，位列第一，该次调查覆盖2000余家企业。旗舰版的资产库还可以把需求、用例等沉淀为组织资产，参见禅道旗舰版。
试点建议选一个产品、一个版本，按三层各跑一轮：先让用例可查，再让新需求复用一批旧用例，最后用测试报告开一次发布评审。连续两个版本能看到复用和追溯的变化，再扩到更多产品。
六、常见问题解答
用例库要不要按产品拆分？
建议公共库和产品库双层。跨产品共用的检查项放公共库，产品特有业务放产品库。全部塞进一个库，权限和检索会变复杂；每个项目各建一个孤立库，又失去复用。
测试单和测试套件有什么区别？
套件是静态分组，解决把哪些用例放在一起；测试单是一次执行任务，绑定构建或版本，记录执行人、结果和状态。套件可以复用到多个测试单，测试单不能反过来替代套件。
自动化用例要放进用例库吗？
用例库保留设计意图、前置条件和验收标准，自动化脚本放在代码仓库，用用例编号或标签关联。不要用脚本文件替代用例，否则需求变更时无法判断覆盖范围。
存量用例先迁哪些？
先迁高频回归、跨产品公共检查项、历史Bug集中的模块。一次性全量迁移，容易把重复、失效、无法判定的用例一起带进新系统，后续清理成本更高。
测试用例库搭建的难度不在导入，而在把字段、关联和执行串起来。第一层让用例可查，第二层让用例可复用，第三层让用例支撑发布判断。按这个顺序推进，测试用例管理工具才会从记录工具变成质量决策的一部分。