测试用例库的分类，先确定一套主维度，通常选业务模块或产品功能，再用标签补充版本、优先级、用例类型等属性，避免多套层级互相冲突。维护依靠机制：明确责任人、设定新增与废弃规则、按节奏评审清理，并用重复率、失效占比、最近执行时间等指标检验库的健康度。下文按分类骨架、操作步骤、角色分工、维护节奏、示例和检查清单展开。
要点总览（TL;DR）
- 分类骨架只保留一套主层级（通常为业务模块→功能点），版本、优先级、用例类型等属性全部转为标签，主层级负责定位、标签负责筛选。
- 新增用例先检索重复再入库，命名按“模块-功能点-验证点-条件”格式；修改时确认影响范围并保留变更记录；废弃改为状态标记并注明替代编号，不直接删除。
- 角色分工落到用例作者、模块负责人、测试负责人和评审人四类，分类字典由测试负责人维护，模块负责人有提议权。
- 维护靠固定节奏加触发条件：按迭代或按月评审，重大需求变更、缺陷集中暴露时启动触发式评审，失效用例分级清理。
- 健康度用分类一致性、维护及时性和重复率、失效占比、最近执行时间等指标检查，阈值由团队自定，重点看趋势而非单次数值。
先定分类骨架：主维度与辅助标签怎么分工
分类骨架要回答一个问题：一条用例放进库里，别人凭什么路径找到它。可行的做法是只保留一套主层级，把其余属性全部转为标签。主层级负责“定位”，标签负责“筛选”，两者分工清晰，库才不会越整理越乱。
主维度候选与选择依据
常见的主维度有三类，选择时看团队日常检索用例的起点在哪里。
| 主维度 | 适用条件 | 优点 | 风险 |
|---|---|---|---|
| 业务模块 | 产品按业务域划分清晰，如订单、支付、账户 | 与需求、缺陷的归属一致，便于按模块分配责任人 | 模块边界模糊时容易重复挂载 |
| 产品功能 | 功能粒度稳定，版本迭代以功能为单位 | 检索路径短，贴近测试执行视角 | 功能重组时层级需要迁移 |
| 用户场景 | 以端到端流程测试为主，如注册到下单全链路 | 贴近业务价值和用户旅程 | 单功能用例难以归入场景 |
多数团队适合以业务模块作为一级、功能点作为二级，形成两到三层的树。层级超过三层后，检索收益下降，维护成本上升，此时应把更深层的区分交给标签。
辅助标签承载哪些属性
标签字典建议在库建立初期就固定下来，每个标签有明确取值，不允许随手新建。常用标签包括：
- 用例类型：功能、接口、性能、兼容性、安全、异常。
- 优先级：P0 至 P3，与执行排期挂钩。
- 适用版本或迭代：标明用例从哪个版本开始有效。
- 执行方式：手工、自动化，自动化用例可再标脚本位置。
- 关联需求或缺陷编号：用于追溯变更影响。
- 状态：有效、待评审、已废弃。
标签适合承载“一条用例可能同时具备多个取值”的属性，例如一条用例既属于回归集又属于接口类型。主层级适合承载“一条用例只能属于一个位置”的属性。判断标准很简单：如果某属性允许一条用例同时取多个值，就做成标签；如果必须二选一，就放进主层级。
多层级与扁平标签的取舍
多层级树便于浏览和分配责任人，适合作为主结构；扁平标签便于组合筛选，适合作为辅助结构。两者并用时，要约定标签不承担导航功能，用户找用例先走树，再用标签缩小范围。若团队规模小、用例量在数百条以内，可以只用一层模块加标签，减少维护负担。
避免一条用例挂多套层级的冲突规则
冲突通常来自同一份用例被不同团队按不同逻辑归档。可以用三条规则约束：
- 一条用例在主层级中只能有一个归属节点，跨模块场景用例归入主场景所在模块，其他模块通过标签引用。
- 标签取值来自字典，新增标签需经模块负责人确认后写入字典，不允许个人临时创建。
- 主层级调整时，由测试负责人统一发起迁移，迁移记录保留在原用例的变更历史中。
交付物是一份分类骨架定义：主层级树的前两到三层结构，加上标签字典初稿，字典中每个标签写明名称、取值、适用对象和维护人。
用例入库与变更的操作步骤
分类结构定好后，每条用例的进出都要走固定动作。下面按新增、修改、废弃三类操作说明输入、动作、输出和完成标志。
新增用例的入库检查与命名规范
输入：需求文档或用户故事、测试设计产出、已有相似用例的检索结果。
动作与检查项：
- 检索库中是否已有覆盖同一场景的用例，有则合并或补充，不重复新建。
- 确认主层级归属节点，选择对应标签，标签取值必须在字典范围内。
- 按命名规范填写标题，建议格式为“模块-功能点-验证点-条件”，例如“订单-提交订单-库存不足时提示-单品超卖”。
- 填写前置条件、步骤、预期结果，并关联需求编号。
- 标注优先级和执行方式。
输出：一条结构完整、归属明确、标签齐全的用例。完成标志：用例通过评审人检查，状态置为“有效”，并能在主层级和标签两个路径下被检索到。
修改用例时的影响范围确认
输入：需求变更说明、缺陷分析结论或评审意见。
动作：先判断变更影响的是步骤、预期结果还是适用范围。若涉及适用范围，同步检查关联的自动化脚本、回归集和上下游用例；若涉及主层级归属，按迁移规则处理并记录原因。修改后保留原版本，便于追溯。
输出：更新后的用例及变更记录。完成标志：变更记录中写明修改原因、影响范围和确认人，关联的自动化脚本或回归集已完成同步确认。
废弃与归档的触发条件与处理方式
触发条件包括：对应功能已下线、需求被取消、用例被新用例完全替代、连续多个版本未执行且确认无保留价值。
动作：将状态改为“已废弃”，注明废弃原因和替代用例编号，从常规回归集中移除，保留在库中供追溯。确认无追溯需求后再归档到独立分区，不直接删除。
输出：废弃记录与归档清单。完成标志：废弃用例不再出现在默认执行视图中，替代关系可查，归档操作有审批记录。
角色分工与各环节交付物
分类和维护要落到人。角色不必多，但每个角色的边界和交付物要写清楚，避免出现“大家都觉得该整理、但没人动手”的情况。
| 角色 | 职责边界 | 主要交付物 |
|---|---|---|
| 用例作者 | 按骨架新建和修改用例，保证命名、标签、关联信息完整 | 合格用例、变更记录 |
| 模块负责人 | 审核本模块用例的归属和标签，维护模块内用例质量 | 模块评审意见、标签新增申请 |
| 测试负责人 | 维护分类字典和主层级结构，组织定期评审与清理 | 分类字典、维护日历、清理决议 |
| 评审人 | 在入库和变更环节检查覆盖度、重复度和可执行性 | 评审记录 |
分类字典的维护归属建议放在测试负责人，模块负责人有提议权，避免字典被随意改动。评审与清理的交付物包括评审记录和清理清单，前者记录每次评审的用例范围、结论和待办，后者列出待合并、待废弃、待补充的用例及处理人和期限。
跨团队共用用例库时，需要额外约定：各团队的主层级节点独立，公共标签字典统一；跨团队引用用例通过标签和关联编号实现，不复制副本；一方修改公共用例前通知使用方，重大变更进入联合评审。
在工具承载上，用例可以作为工作项管理，分类树对应模块或组件字段，标签对应自定义属性，评审记录和清理清单以文档形式与用例关联，状态流转记录保留在变更历史中。ONES 的测试管理模块支持用例与需求、缺陷的关联，评审和清理结论可以在同一工作项视图内追踪，便于把上述角色动作落到具体记录上。
维护节奏：定期评审、清理与复用检查
维护机制的核心是固定节奏加触发条件，两者配合才能覆盖日常变化和突发变更。
定期评审的周期与触发条件
常规评审建议按迭代或按月进行，评审范围为本周期内新增和修改的用例。触发式评审在以下情况启动：重大需求变更、版本上线后缺陷集中暴露、组织架构或模块划分调整、新团队接入共用库。评审内容聚焦归属是否正确、标签是否齐全、是否存在重复。
失效用例识别与清理规则
识别失效用例可以看三个信号：关联需求已关闭或变更、最近若干版本未被执行、执行结果长期无法判定。清理规则建议分级处理：先标记“待确认”，由模块负责人核实；确认失效后改为“已废弃”并注明原因；连续两个评审周期无人认领的待确认用例，进入归档流程。
复用检查：重复与相似场景的合并判断
重复用例的判断标准是前置条件、步骤和预期结果三者高度重合。相似场景则保留为独立用例，通过标签建立关联，例如同一功能在不同数据条件下的验证。合并时保留覆盖更全的一条，另一条的关键差异点补充进保留用例，原编号在变更记录中注明合并去向。
需求变更后用例同步的衔接方式
需求变更进入开发排期时，同步在用例库中标记受影响用例，由模块负责人在需求评审后一个工作日内完成影响确认，确定修改、新增或废弃。变更完成后更新关联编号，确保需求、用例、缺陷三者可追溯。
交付物是维护日历和清理检查表。维护日历写明评审周期、责任人和输出物；清理检查表按模块列出待处理用例、处理动作、处理人和完成时间。
示例：一个模块的用例库分类与维护落地
以一个电商系统的“订单”模块为例，演示分类与维护如何组合。以下为演示情景，用于说明方法，不代表真实项目数据。
分类层级与标签填写
主层级：订单 → 提交订单 → 库存校验。该节点下存放库存相关的功能用例。一条典型用例的标签填写为：类型=功能，优先级=P0，适用版本=V3.2 起，执行方式=自动化，关联需求=REQ-1042，状态=有效。
一条用例从新增到废弃的完整轨迹
- 新增：需求 REQ-1042 提出库存不足时的下单拦截，作者检索库中无重复用例后新建，归入“订单-提交订单-库存校验”，填写标签并关联需求，提交评审。
- 评审通过：模块负责人确认归属和标签无误，状态置为有效，纳入回归集。
- 修改：V3.4 需求调整提示文案和拦截时机，作者修改预期结果，同步更新自动化脚本，变更记录写明原因和确认人。
- 废弃：V4.0 库存校验逻辑并入统一风控服务，原用例被新用例替代，状态改为已废弃，注明替代编号，从回归集移除，保留在库中供追溯。
维护评审中发现的典型问题及处理
某次月度评审发现三类问题：同一库存场景存在两条步骤几乎相同的用例，判定为重复，合并保留覆盖更全的一条；五条用例的适用版本标签缺失，由模块负责人补齐；两条用例关联的需求已关闭但状态仍为有效，标记待确认后核实废弃。处理结果记入清理清单，并在下次评审时复核完成情况。
完成检查：用例库健康度怎么判断
分类和维护是否到位，可以用一组可逐项核对的检查项来判断。建议每季度做一次完整检查，每月抽查一个模块。
| 检查类别 | 检查项 | 判断标准 | 不通过时的处理 |
|---|---|---|---|
| 分类一致性 | 用例是否都有唯一主层级归属 | 抽查样本中无归属缺失或重复挂载 | 由模块负责人限期迁移并记录原因 |
| 分类一致性 | 标签取值是否都在字典范围内 | 无字典外标签 | 清理非法标签，补充字典或调整用例 |
| 维护及时性 | 需求变更后用例是否同步更新 | 变更需求对应的用例在约定时限内完成修改 | 列入清理清单，指定责任人补做 |
| 维护及时性 | 废弃用例是否及时标记 | 已下线功能对应用例状态为已废弃 | 集中核实并批量处理 |
| 可观察指标 | 重复率 | 抽查样本中重复用例占比处于团队设定阈值内 | 组织合并，更新关联编号 |
| 可观察指标 | 失效用例占比 | 待确认与已废弃用例占比不超过设定阈值 | 加快清理节奏，增加评审频次 |
| 可观察指标 | 最近执行时间 | 核心模块用例在最近一个回归周期内被执行过 | 排查是否遗漏纳入回归集 |
阈值由团队根据用例总量和执行频率自行设定，关键是每次检查用同一口径对比，观察趋势而非单次数值。检查不通过时，处理动作要落到具体用例和责任人，并在下一周期复核。把检查结果与维护日历结合，分类骨架和维护机制就能持续运转，用例库也会随着版本迭代保持可用。
常见问题
团队用例量不大，还需要建多层级分类树吗？
用例量在数百条以内时，可以只用一层模块加标签，减少维护负担。层级的作用是缩短检索路径，当用例总量还不足以让检索变慢时，多层级反而增加归属判断和迁移成本。等模块内用例增长到难以浏览时，再把功能点拆成二级节点，迁移时由测试负责人统一发起并保留变更记录。
同一条用例同时涉及多个模块，主层级应该挂在哪里？
按主场景所在模块归属，其他模块通过标签引用，保证一条用例在主层级中只有一个位置。跨模块的端到端流程用例，归入流程起点或核心业务模块，并在标签中标注涉及的关联模块。这样既避免重复挂载，也能让其他模块的负责人在筛选时找到它。
需求变更频繁时，用例同步跟不上怎么办？
把同步动作前置到需求评审环节：需求变更进入开发排期时，就在用例库中标记受影响用例，由模块负责人在需求评审后一个工作日内完成影响确认，明确修改、新增还是废弃。同步完成后更新关联编号，使需求、用例、缺陷三者可追溯。若变更量大，可临时提高评审频次，把同步情况纳入清理清单跟踪。
标签字典由谁维护，个人能不能临时新建标签？
字典维护建议放在测试负责人，模块负责人有提议权。个人临时新建标签会让取值发散，筛选结果失去可比性，因此新增标签需经模块负责人确认后写入字典，写明名称、取值、适用对象和维护人。检查时发现字典外标签，应清理并补充字典或调整用例。
健康度指标没有历史数据，阈值怎么定？
首轮检查可以先记录现状数值作为基线，不急于判定合格与否。之后每季度用同一口径复测，观察重复率、失效占比的变化趋势，再结合团队用例总量和执行频率设定阈值。关键是口径稳定，避免每次换算法导致数据不可比。检查不通过时，处理动作要落到具体用例和责任人，并在下一周期复核。
