公共用例过期通常指用例库中共享复用的用例长期未维护，与当前需求、接口或产品行为脱节，导致执行结果失真、缺陷误判或回归覆盖缺口。处理这类问题，先界定过期范围和影响，再按需求变更、产品行为变更、维护责任缺失、复用方式不当四类假设逐项取证，然后按风险分级更新、归档或下线，最后用抽样回放与定期评审验证恢复效果。
要点总览（TL;DR）
- 先按用例库、模块、业务线、复用团队统计过期规模，区分单条失效与公共资产整体失准，再判断回归覆盖缺口和缺陷误判的影响。
- 原因排查用假设加证据：依次核对需求变更、接口与页面变化、维护责任缺失、复用场景错配，留下排除记录，避免把时间久当成主因。
- 处置按核心链路、高频复用、低频边缘分级，先标注弃用止血、补充替代用例，再分批清理；批量修改或删除前导出备份并经评审确认。
- 处置后用抽样回放和回归执行验证覆盖恢复，跟踪过期率与更新及时率，并通过定期评审、需求变更联动和责任人机制防止复发。
公共用例过期有哪些表现，影响范围怎么界定
判断一条公共用例是否过期，依据是用例描述与当前需求、产品行为是否一致，创建时间长短只能作为线索。公共用例被多个团队、多个测试计划复用，单条失效容易被放大成“整个用例库不可用”的印象，因此第一步要把症状记录清楚，再按维度统计规模，避免用个别问题否定整体资产。
典型症状清单
- 执行结果与预期不符：按步骤操作后，实际结果与用例预期持续不一致，且确认产品行为符合当前需求。
- 步骤引用已下线入口：用例中的菜单、页面、按钮、接口地址在产品中已不存在或已改名。
- 前置条件失效：用例依赖的账号、数据、配置、环境在现状下无法构造或已变更。
- 长期无人更新：用例关联的需求已关闭或多次变更，用例内容仍停留在旧版本。
- 复用场景错配：用例被套用到与设计前提不同的业务线或产品版本，步骤本身正确但前提不成立。
范围界定表
建议按下表逐项填写，用数量而非感受描述过期规模。统计口径要统一，例如“最近一个迭代执行失败且确认为用例原因的用例数”。
| 统计维度 | 记录内容 | 用途 |
|---|---|---|
| 用例库 | 各用例库的过期用例数与占比 | 判断是个别库失准还是普遍问题 |
| 模块 | 按功能模块统计过期分布 | 定位集中失准的模块 |
| 业务线 | 各业务线受影响用例数 | 评估业务影响面 |
| 复用团队 | 哪些团队在引用这些用例 | 确定通知与交接对象 |
| 关联需求 | 用例关联需求的状态与变更次数 | 为原因排查提供线索 |
区分单条失效与整体失准
如果过期集中在少数模块、且多数用例仍能正常执行，属于局部失效，按单条处置即可。如果同一批公共用例在多个复用团队中同时出现步骤失效、前置条件失效，且关联需求普遍发生过变更，则说明这批公共资产整体与现状脱节，需要按批次评估，而不是逐条修补。影响判断重点看三项：回归覆盖是否出现缺口、是否已造成缺陷误判、是否有新人按过期用例学习业务。
过期原因假设与排除证据
原因排查采用假设加证据的方式：先列出可能原因，再为每类假设指定可采集的证据，按顺序排除。不要看到“用例很久没改”就直接归因为维护不力，时间久只是伴随现象，主因可能是需求变更未同步。
原因假设与证据对照
| 假设 | 可采集证据 | 排查顺序 |
|---|---|---|
| 需求或产品行为变更未同步到用例 | 用例关联需求的变更记录、需求评审结论、产品当前行为截图或接口文档 | 第一步，优先核对关联需求 |
| 接口、页面或环境变化导致步骤失效 | 接口文档版本、页面结构变更记录、环境配置差异、失败步骤的复现记录 | 第二步，在需求无变更时核对 |
| 维护责任与更新机制缺失 | 用例负责人字段、最近修改记录、评审记录、是否有明确的更新触发规则 | 第三步，在前两类排除后核对 |
| 复用方式不当，套用到不匹配场景 | 用例设计前提、复用团队的适用场景说明、错配用例的执行记录 | 第四步，结合复用团队反馈核对 |
如何区分主因与伴随现象
主因通常能解释一批用例同时失效，并且有可追溯的变更记录支撑；伴随现象往往只解释个别用例，或与其他证据相互矛盾。例如，某模块用例集体失效，同时该模块需求在上个季度做过重构，那么需求变更就是主因，维护不及时是结果而非独立原因。若需求无变更、接口也无调整，但用例负责人长期空缺、无人评审，则维护机制缺失是主因。排查时建议每条假设都留下证据记录，写明“已核对、结论、排除或确认”，便于后续复核和交接。
在用例与需求、任务已建立关联关系的情况下，排查可以从关联需求的状态和变更记录入手，减少逐条翻查的成本。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，用例库中的属性支持筛选，便于按模块、负责人、关联需求等条件圈定待排查范围。
按风险分级处置过期公共用例
处置的目标是先控制影响，再清理存量。所有涉及批量修改、删除、下线的操作，都要先备份、再评审、设停止点，避免在清理过程中制造新的覆盖缺口。
分级标准与处置动作
| 风险级别 | 判定条件 | 建议处置 |
|---|---|---|
| 高：核心链路 | 覆盖主流程、支付、登录等关键路径，或缺陷误判已发生 | 优先更新，当日完成修订并复核；无法立即修订的先标注弃用并补充替代用例 |
| 中：高频复用 | 被多个团队或多个测试计划频繁引用 | 更新或拆分为场景化用例，通知复用团队确认适用性 |
| 低：低频边缘 | 引用少、覆盖边缘功能、与当前需求关联弱 | 标注弃用或归档，保留历史记录，暂不删除 |
处置顺序：先止血后清理
- 冻结影响：对已确认失效且被高频引用的用例，先标注弃用状态，阻止继续被错误执行。
- 补充替代：核心链路的过期用例，先补齐或修订可执行的替代用例，再处理原用例。
- 批量清理：按模块分批处理低频用例，每批处理前导出备份。
- 归档留痕：确认不再使用的用例归档而非直接删除，保留追溯依据。
操作边界与停止条件
- 批量修改或删除前，先导出用例数据做本地备份；ONES 支持用例导出与本地备份，可作为处置前的留底动作。
- 删除操作需经用例负责人和复用团队代表评审确认，单人不得直接批量删除公共用例。
- 设置停止条件：若某批次处置后抽样执行失败率上升，或核心链路出现覆盖缺口，立即停止后续批次并回退。
- 责任分工明确：用例负责人确认失效事实，测试负责人审批处置方式，复用团队代表复核替代用例是否满足其场景。
处置过程中，按用例库、测试计划单独配置的权限可以约束谁能修改、谁只能查看，降低误操作风险；树状结构的用例模块便于按层级分批处理，避免一次性改动过大。
验证恢复效果与防止再次过期
处置完成不等于问题解决，需要用执行结果证明覆盖已恢复，并建立机制让过期问题不再积累。
验证清单
- 抽样回放：从处置过的用例中按模块抽取样本，在对应环境执行，确认步骤可走通、预期结果与当前产品一致。
- 回归执行：将修订后的核心链路用例纳入下一轮回归，观察通过率是否回到正常水平。
- 覆盖核对：对照需求清单确认核心链路无覆盖缺口，替代用例已生效。
- 误判复查：回查此前因用例过期导致的缺陷误判记录，确认结论已更正。
观察指标
建议持续跟踪三项指标：过期用例数及占比、用例更新及时率（关联需求变更后在一定周期内完成用例修订的比例）、复用团队的失效反馈数量。指标口径由团队自定，例如“需求变更后两周内未修订的用例计为待更新”，关键是口径稳定、可对比。
复发预防机制
- 定期评审：按迭代或按月组织用例评审，重点检查高频复用和核心链路用例，明确评审责任人和输出记录。
- 变更联动：需求变更评审时同步确认受影响用例，把用例更新作为需求关闭的前置检查项。ONES 支持用例与需求、任务关联，可在此基础上建立变更时回查关联用例的习惯。
- 责任人机制：为公共用例设置负责人，负责人变更时同步交接，避免出现无人维护的用例。
- 复用准入：公共用例被新团队引用前，由引用方确认设计前提与自身场景匹配，减少错配型过期。
若验证阶段发现过期率回升或同类问题再次集中出现，回到原因排查环节重新取证，重点检查变更联动是否被绕过、评审是否流于形式，而不是直接进入又一轮批量清理。
常见问题
公共用例多久没更新才算过期？
没有统一的行业阈值，判断依据是用例描述与当前需求、产品行为是否一致，创建或修改时间只能作为线索。团队可以自定口径，例如“关联需求变更后两周内未修订的用例计为待更新”，关键是口径稳定、可对比。若某条用例步骤仍与产品一致、前置条件可构造，即使长期未改也不构成过期。
批量删除过期公共用例前需要做哪些准备？
先导出用例数据做本地备份，再经用例负责人和复用团队代表评审确认。删除范围要按模块分批，每批处理前记录清单；核心链路用例先补齐替代用例再处理原用例。建议设置停止条件：某批次处置后抽样执行失败率上升或出现覆盖缺口，立即停止后续批次并回退。归档优先于删除，保留追溯依据。
需求变更后，如何快速找到受影响的公共用例？
前提是用例与需求、任务已建立关联关系。排查时从关联需求的状态和变更记录入手，圈定该需求下的用例，再按模块和复用团队筛选。ONES 测试管理支持测试用例与需求、任务关联，用例库中的属性支持筛选，可减少逐条翻查的成本。若关联关系不完整，需要先补齐关联，否则只能按模块人工核对。
过期用例已造成缺陷误判，处置时要注意什么？
先把误判记录单独列出，回查对应缺陷的结论并更正，避免错误结论继续影响质量判断。这类用例通常属于核心链路或高频复用，应优先更新并复核，无法立即修订的先标注弃用并补充替代用例。处置完成后，在验证阶段复查误判记录是否已全部更正。
如何约束公共用例的修改权限，降低误操作风险？
按角色划分权限：用例负责人可修改，测试负责人审批处置方式，复用团队代表复核替代用例。ONES 支持为不同用户组配置权限，并支持为用例库、测试计划单独配置权限，可据此限制批量修改和删除的操作范围。权限粒度需按组织实际配置核验。
