测试用例库目录的更新与维护，核心是建立“变更触发—目录调整—用例归位—评审确认—定期巡检”的闭环。它适用于用例数量持续增长、产品模块频繁调整的测试团队。下面按流程、角色、示例和检查项展开，说明每一步的输入、动作与完成标志。
要点总览（TL;DR）
- 目录维护的核心是“变更触发—目录调整—用例归位—评审确认—定期巡检”闭环，先约定层级与命名规则，再嵌入日常变更动作。
- 新增、修改、废弃用例以及模块拆分合并时，都要判断目录是否同步调整，调整后确保每条受影响用例有唯一归属。
- 提出、执行、评审、巡检四类职责需要分开，交付物统一为变更记录，包含触发原因、调整内容、影响用例和评审结论。
- 巡检可按迭代或每月轮换模块进行，用例归属准确性和变更记录完整性属于阻断项，缺失时判定维护未完成。
- ONES TestCase 的树状用例模块、属性筛选与用例库权限配置，可承载目录调整、归位查找和权限收敛等动作。
目录更新维护的核心做法与操作步骤
目录维护要解决的是用例资产与产品结构脱节的问题。团队先约定一套目录规则，再把它嵌入日常变更动作，最后用巡检兜底。以下五个步骤构成一个可重复执行的闭环。
第一步：确定目录层级与命名规则
目录规则是所有后续调整的判定依据，应在维护开始前形成书面约定。常见做法是按“产品线—功能模块—子功能—用例类型”分层，层级深度控制在团队能快速定位的范围内。命名规则需要统一：模块名与产品需求文档中的模块名保持一致，避免同义词并存；用例标题采用“模块_场景_预期”的结构，便于按目录检索。规则确定后写入目录说明文档，作为评审时的对照标准。
这一步的输入是现有用例清单和产品模块划分；动作是梳理层级、统一命名；输出是目录说明文档；完成标志是团队内对规则达成一致并可以据此判断某条用例应归入哪个目录。
第二步：识别变更触发条件
目录调整由具体事件触发，而非凭感觉定期大改。需要纳入触发的条件包括：新增用例时判断是否已有对应目录；修改用例时判断所属模块是否发生变化；废弃用例时判断所在目录是否已无有效用例；产品模块拆分、合并或下线时判断目录是否需要同步增删。触发条件明确后，用例作者和测试负责人在日常工作中就能判断何时需要发起目录调整。
第三步：执行目录调整与用例归位
目录调整包括新增目录、重命名目录、合并目录、拆分目录和归档目录五类动作。调整目录后必须同步处理用例归位：受影响的用例逐条确认归属，迁移到新目录；失效用例标记废弃或移入归档目录，不留在活跃目录中。归位时以目录说明文档为准，遇到规则未覆盖的情况，记录到待议清单，交由评审环节决定。
这一步的输入是变更触发事件和目录说明文档；动作是增删改目录并迁移用例；输出是调整后的目录结构和归位后的用例清单；完成标志是每条受影响用例都能在新结构中找到唯一归属。
第四步：评审确认与记录
目录调整完成后，由测试负责人或指定评审人对照目录说明文档检查：层级是否符合规则、命名是否统一、是否有用例遗留在旧目录、废弃用例是否已处置。评审结论以变更记录的形式留存，记录内容包括触发原因、调整前后的目录结构、迁移用例数量、评审人和日期。变更记录既是追溯依据，也是下次巡检的对照材料。
第五步：定期巡检
巡检节奏可按团队发布周期设定，例如每个迭代结束或每月一次。巡检内容覆盖三项：目录结构与产品当前模块是否一致；活跃目录中是否存在长期未更新或已失效的用例；变更记录是否完整。巡检发现的问题进入下一轮调整，形成闭环。巡检不需要每次全量检查，可以按模块轮换，保证一个季度内覆盖主要目录。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 确定规则 | 现有用例清单、产品模块划分 | 梳理层级、统一命名 | 目录说明文档 | 团队可按规则判断用例归属 |
| 识别触发 | 新增、修改、废弃、模块调整事件 | 判断是否影响目录 | 目录调整需求 | 触发事件有明确处理人 |
| 调整归位 | 调整需求、目录说明文档 | 增删改目录、迁移用例 | 新目录结构、归位清单 | 受影响用例归属唯一 |
| 评审记录 | 调整结果、目录说明文档 | 对照检查、留存结论 | 变更记录 | 评审结论可追溯 |
| 定期巡检 | 变更记录、当前目录 | 抽查一致性、完整性 | 巡检问题清单 | 问题进入下轮调整 |
角色分工与各环节交付物
目录维护能否持续，取决于每个环节是否有明确的责任人。角色不必与岗位一一对应，小团队可以一人兼任多个角色，但提出、执行、评审、巡检四类职责需要分开，避免同一人既改目录又做最终确认。
| 角色 | 主要动作 | 输入 | 交付物 |
|---|---|---|---|
| 用例作者 | 新增或修改用例时判断目录归属，提出目录调整需求 | 需求文档、目录说明文档 | 用例归属建议、调整申请 |
| 测试负责人 | 审批目录调整，组织评审，决定拆分或合并方案 | 调整申请、影响范围说明 | 调整决定、评审结论 |
| 评审人 | 对照规则检查目录结构与命名，确认用例归位 | 调整后的目录、用例清单 | 评审意见、通过或退回结论 |
| 配置或资产管理员 | 执行目录增删改，维护变更记录，组织巡检 | 调整决定、评审结论 | 变更记录、巡检问题清单 |
各角色的衔接点在于交付物的传递：用例作者提出调整申请后，测试负责人给出决定，管理员执行并形成变更记录，评审人确认后记录归档。巡检由管理员组织，发现的问题回到测试负责人处决定是否进入下一轮调整。交付物形式可以统一为变更记录模板，包含触发原因、调整内容、影响用例、评审结论和责任人，减少口头沟通造成的遗漏。
在工具层面，目录调整和变更记录需要有承载位置。ONES TestCase 支持编写测试用例、组织用例库，用例模块采用树状结构并支持拖拽排序，目录调整可以直接在结构中完成；用例库中所有用例属性都支持筛选，便于在归位时按模块、状态等条件找出需要迁移的用例。团队还可以为用例库单独配置权限，把目录调整权限收敛到管理员和测试负责人，降低误改风险。变更记录和评审结论可以随用例库文档一并留存，供巡检时对照。
示例：一次模块重构后的目录调整
以下为演示情景，用于说明流程如何落地，不代表特定团队的真实案例。
某产品的“订单管理”模块在版本重构中被拆分为“订单创建”“订单履约”“订单售后”三个子模块，原目录下约有 240 条用例。测试负责人在需求评审阶段识别到这一变化，将其登记为目录变更触发事件，并指定一名管理员负责执行。
影响范围识别。管理员按原目录导出用例清单，逐条标注涉及哪个新子模块。约 30 条用例同时覆盖多个子模块，暂不迁移，列入待议清单。另有 18 条用例对应的功能在新版本中下线，标记为废弃。
目录拆分处理。在原“订单管理”目录下新增三个子目录，命名与需求文档中的子模块名一致。原目录保留为父级，不再直接存放用例。拆分方案经测试负责人确认后执行。
用例迁移与失效处置。管理员将已标注归属的用例逐条迁移到对应子目录；18 条废弃用例移入“归档”目录并标注废弃原因；30 条跨模块用例由用例作者补充归属说明后，按主要场景归入一个子目录，并在用例描述中注明关联的其他子模块。
评审与记录。评审人对照目录说明文档检查：三个子目录命名统一，无用例遗留在原目录，归档目录中的用例均有废弃标注。评审通过后，管理员在变更记录中登记触发原因、调整前后结构、迁移数量、废弃数量和评审结论。
巡检确认。下一个迭代的巡检中，管理员抽查“订单履约”子目录，确认新增用例均归入正确位置，变更记录与当前目录一致。巡检未发现遗留问题，本次调整关闭。
完成检查：目录维护是否到位的核对项
判断一次目录维护是否完成，可以按以下清单逐项核对。清单同时适用于单次调整后的验收和定期巡检。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 目录结构与命名一致性 | 目录层级是否符合说明文档，模块名是否与需求文档一致 | 无同义目录并存，层级未超出约定深度 |
| 用例归属准确性 | 活跃目录中的用例是否属于该模块，是否存在跨目录重复用例 | 每条用例有唯一归属，重复用例已合并或标注 |
| 冗余与失效清理 | 是否存在长期未更新、对应功能已下线的用例 | 失效用例已移入归档或标记废弃 |
| 变更记录完整性 | 触发原因、调整内容、影响用例、评审结论是否齐全 | 记录可追溯到具体评审人和日期 |
| 责任人与证据留存 | 调整申请、评审结论、巡检问题清单是否归档 | 每项调整均有对应责任人和留存材料 |
其中，用例归属准确性和变更记录完整性属于阻断项：存在无归属用例或变更记录缺失时，本次维护判定为未完成，需补齐后再验收。目录命名不一致、归档不及时等问题可列为限期整改项，在下一轮巡检中复查。
检查结果建议由管理员汇总为一份巡检记录，附上问题清单和整改责任人，与变更记录一并保存。这样每次维护都有可核对的证据，目录与用例资产的一致性也能在后续迭代中持续保持。
常见问题
团队用例数量不多，也需要建立完整的目录更新维护流程吗？
可以按规模裁剪，但闭环中的关键动作建议保留。用例较少时，目录层级可以只保留两层，评审与巡检可由同一人兼任，变更记录简化为一条登记即可。需要保留的是“调整有依据、归位有确认、记录可追溯”这三件事，否则用例增长后容易出现目录与模块脱节、旧用例无人清理的情况。
目录调整和用例迁移应该由用例作者自己做，还是统一交给管理员？
取决于调整范围。单条用例新增或修改时的归属判断，由用例作者在提交时完成更高效；涉及目录拆分、合并、重命名等结构性调整，建议由配置或资产管理员统一执行，避免多人同时改动造成结构冲突。无论哪种方式，结构性调整都需要测试负责人确认方案、评审人对照规则检查后再关闭。
模块频繁调整时，每次都同步改目录会不会成本过高？
可以把调整分为两类处理：影响用例归属的结构性变化，随模块调整同步执行；仅涉及命名或展示顺序的变化，合并到巡检时统一处理。同时，跨模块用例不必强行拆分，按主要场景归入一个目录并在描述中注明关联模块，可以减少反复迁移。关键是让触发条件明确，避免所有变化都走全量调整。
巡检发现问题后，如何避免问题一直挂在清单里没人处理？
巡检记录需要写明问题、整改责任人和复查时间，并区分阻断项与限期整改项。阻断项在补齐前不通过验收，限期整改项在下一轮巡检中复查。巡检由管理员组织，问题是否进入下一轮调整由测试负责人决定，这样每项问题都有明确的处理路径和关闭条件。
用工具管理用例库时，目录调整权限应该怎么设置？
建议把目录结构性调整的权限收敛到管理员和测试负责人，普通用例作者保留用例编写与归属建议的权限。ONES TestCase 支持为不同用户组配置不同权限，也支持为用例库单独配置权限，团队可以据此把目录增删改与日常用例维护分开，降低误改风险。具体权限粒度以团队实际配置为准。
