公共用例过期通常指用例库中的共享用例长期未随需求、接口或业务规则变化而更新，导致执行结果失真、复用价值下降。处置时先界定过期范围与影响面，再逐类验证原因，按“停用—修订—复核—重新发布”分批处理，最后用指标验证恢复效果并把定期复审写入维护机制。下文按这一顺序展开。
要点总览（TL;DR）
- 判断公共用例是否过期，先看执行结果是否长期失真、需求变更后是否同步、负责人是否缺位，再按分组、最近执行时间、引用项目数和失败率叠加筛出范围清单。
- 原因排查按“先查变更同步，再查责任归属，最后查机制缺口”的顺序推进，缺少变更记录、负责人或评审记录时只能列为待验证假设。
- 处置按直接废弃、合并去重、修订后保留、拆分维护分级，统一走“停用并通知引用方—修订—复核—重新发布”，批量操作前先备份并确认引用项目。
- 处置后一个发布周期内复测过期用例占比、共享用例执行通过率、引用覆盖率和复审完成率，确认恢复效果。
- 把复审周期与到期提醒、共享用例负责人、需求变更同步更新和归档清理写入用例库维护机制，防止再次过期。
公共用例过期有哪些表现，影响范围怎么界定
公共用例过期在用例库里通常有迹可循，先识别症状再圈定范围，可以避免把个别用例的问题扩大成整库重写。判断一条共享用例是否过期，核心看它是否还能反映当前需求与业务规则，以及是否仍有人在维护。
典型症状清单
- 执行结果与预期长期不符：同一用例连续多个版本执行失败，或实际结果与步骤描述明显脱节。
- 需求已变更但用例未改：需求文档、接口定义已更新，用例中的前置条件、输入数据、预期结果仍是旧版本。
- 无人认领的共享用例：用例负责人字段为空或指向已离职、已转岗人员，出现问题找不到修订人。
- 被多项目引用却无人维护：引用项目数不少，但最近一次修订时间停留在很久以前，也没有人反馈过问题。
- 步骤与数据明显陈旧：引用的接口地址、字段名、页面路径已不存在，或数据依赖早已下线。
界定范围的筛选口径
建议按以下维度组合筛出候选集，而不是凭印象逐条翻看：
| 筛选维度 | 口径示例 | 用途 |
|---|---|---|
| 用例库分组 | 按业务模块或公共用例分组圈定范围 | 限定排查边界，避免全库扫描 |
| 最近执行时间 | 超过一个或多个发布周期未执行 | 识别长期闲置的共享用例 |
| 引用项目数 | 被两个及以上项目引用 | 优先处理影响面大的用例 |
| 失败率 | 近若干次执行失败比例偏高 | 定位结果失真的用例 |
| 最近修订时间 | 长时间未更新且需求已变更 | 发现内容滞后的用例 |
把上述条件叠加后得到的清单，就是本次处置的过期公共用例范围清单。清单中应记录用例标识、所属分组、引用项目、最近执行结果、最近修订时间和负责人，作为后续原因排查与处置的底稿。
区分过期、设计缺陷与环境问题
执行失败不等于用例过期。判断时先排除两类干扰：一是设计缺陷，即用例本身步骤不完整、断言不合理，从一开始就写错了，这类问题应走用例修订而非按过期处理；二是环境问题，即测试环境、数据或依赖服务异常导致的失败，用例内容本身仍然有效。区分方法是看失败是否随环境恢复而消失、是否在多个环境中稳定复现、预期结果是否与当前需求一致。只有确认用例内容与当前需求或业务规则脱节，才归入过期范围。
过期原因怎么验证：假设与排除证据
过期原因不能凭直觉下结论，应按假设逐项找证据。下面把常见原因假设与可验证证据对应起来，便于逐条核对。
| 原因假设 | 可验证证据 | 排查动作 |
|---|---|---|
| 需求或接口变更未同步 | 需求变更记录、接口文档版本与用例最近修订时间的比对 | 抽取变更点，核对对应用例是否同步更新 |
| 维护责任人缺位 | 用例负责人字段为空、指向离职或转岗人员 | 统计负责人缺失或失效的用例占比 |
| 共享用例缺少归属 | 引用关系清单中无人对内容负责 | 按引用项目反查是否有明确的维护方 |
| 评审与归档机制缺失 | 评审记录缺失、旧版本未归档、停用用例仍被引用 | 检查用例变更是否经过评审、废弃用例是否清理 |
| 复制粘贴导致分支漂移 | 同一业务存在多条高度相似但内容不一致的用例 | 比对相似用例的步骤与预期结果差异 |
排查顺序建议
建议按“先查变更同步，再查责任归属，最后查机制缺口”的顺序推进。先比对需求与接口变更记录和用例修订时间，能快速确认是否存在系统性滞后；再统计负责人字段的完整性，判断维护是否有人承接；最后检查评审、归档与引用清理机制，找出让问题反复出现的结构性原因。这个顺序的好处是先处理影响面最大、证据最容易获取的原因，再逐步深入到机制层面。
缺少证据时的处理
如果某类原因找不到变更记录、负责人信息或评审记录等证据，只能把它列为待验证假设，不能直接当作结论写进处置方案。此时可以先做小范围抽样验证，例如选取若干条典型用例回溯其变更历史，确认假设成立后再扩大排查范围。把假设与已证实原因分开记录，能避免后续处置建立在错误判断上。
按过期类型分批处置：停用、修订与重新发布
确认过期范围和原因后，按类型分批处置比一次性重写更可控。处置前先对候选用例分级，再按统一顺序操作，并守住风险边界。
处置分级
| 类型 | 适用情形 | 处置方式 |
|---|---|---|
| 直接废弃 | 对应功能已下线、业务规则已取消 | 标记停用并归档，通知引用方解除引用 |
| 合并去重 | 多条用例内容高度相似、仅细节不同 | 保留一条主用例，其余合并后停用 |
| 修订后保留 | 用例思路仍有效，仅步骤、数据或预期结果过时 | 更新内容后重新发布 |
| 拆分后分别维护 | 一条用例覆盖多个场景，变更节奏不一致 | 按场景拆分，各自指定负责人 |
操作顺序
- 先标记停用并通知引用方：把确认过期的用例状态改为停用，同时告知引用这些用例的项目，避免继续基于旧用例执行。
- 再修订：由用例负责人按当前需求更新步骤、数据和预期结果，修订时保留变更说明。
- 再复核：由测试负责人或指定评审人检查修订后的用例是否与需求一致、是否可执行。
- 最后重新发布：复核通过后恢复为可用状态，并同步更新引用关系。
风险边界
批量删除或覆盖前，先导出备份并确认引用项目清单，保留历史版本以便回溯。对仍被多个项目引用的用例，停用前要与引用方确认替代方案，避免影响在跑的测试活动。破坏性操作应设置停止点：一旦发现引用关系未清理干净或备份不完整，暂停批量操作，改为逐条处理。
责任分工
用例负责人负责修订内容，测试负责人负责复核与发布把关，引用方负责确认停用或替换是否影响自身测试安排。三方确认后再执行状态变更，可以减少处置过程中的反复。
在用例库中承载这套流程时，可以把负责人字段、用例状态流转和引用关系作为管理抓手。ONES 测试管理支持在用例上记录负责人、维护用例状态，并按用例库组织共享用例，便于在停用、修订、复核、发布各环节留下可追溯的记录，让引用方及时看到状态变化。
如何验证恢复效果并防止再次过期
处置完成后需要用指标确认恢复情况，并把复审写入日常维护，让过期问题从一次性清理转为持续管理。
验证指标清单
- 过期用例占比：处置后仍处于过期状态的用例数量占共享用例总数的比例，用于判断清理是否彻底。
- 共享用例执行通过率：处置后重新执行的共享用例通过比例，反映内容是否与当前需求一致。
- 引用覆盖率：被引用的共享用例中，有明确负责人且近期修订过的比例，反映维护是否到位。
- 复审完成率：按周期应复审的用例中实际完成复审的比例，反映机制是否在运转。
建议在处置后一个发布周期内复测一次，对比处置前后的指标变化，确认恢复效果；若通过率仍偏低，回到原因排查环节检查是否有遗漏的过期类型。
复发预防机制
设置复审周期与到期提醒，按业务模块或用例重要度确定复审频率，到期未复审的用例在库中标记提示。明确每条共享用例的负责人，新增共享用例时要求填写负责人和适用项目，作为准入检查。把用例更新纳入需求变更流程，需求或接口变更评审时同步确认受影响的公共用例是否需要修订。定期清理与归档规则也要固定下来，停用用例及时归档并从引用清单中移除，避免旧用例继续被误用。
这些机制落到工具上，可以通过用例库的复审提醒、负责人字段和状态流转来承载。ONES 测试管理支持按用例库组织用例并记录负责人与状态，配合定期复审安排，可以把到期提醒和复审完成情况纳入日常管理，减少共享用例长期无人维护的情况。
常见问题
公共用例被多个项目引用，停用前需要做哪些确认？
停用前先导出该用例的引用项目清单，逐个确认引用方是否仍在执行这条用例、是否有替代用例可用。对仍在跑的测试活动，要与引用方约定替换时间，再执行状态变更。若引用关系未清理干净，暂停批量停用，改为逐条处理，避免影响其他项目的测试安排。
需求变更频繁时，公共用例的复审周期怎么定比较合适？
复审周期可以按业务模块的变更频率和用例重要度分别设定：变更频繁、影响核心流程的模块缩短复审间隔，变更较少的模块适当放宽。更关键的是把用例更新挂到需求变更流程上，需求或接口评审时同步确认受影响的公共用例，这样复审就不只依赖固定周期，还能在变更发生时及时触发。
用例执行失败，怎么判断是过期、设计缺陷还是环境问题？
先看失败是否随环境恢复而消失、是否在多个环境中稳定复现。环境问题通常在环境修复后不再出现；设计缺陷表现为用例步骤不完整或断言不合理，从一开始就写错；只有预期结果与当前需求或业务规则脱节，才归入过期。三类问题处置方式不同，混在一起处理容易把有效用例误停用。
批量清理过期公共用例时，如何避免误删仍在使用的内容？
批量删除或覆盖前先导出备份并保留历史版本，确认引用项目清单和替代方案。设置停止点：一旦发现引用关系未清理干净或备份不完整，暂停批量操作，改为逐条处理。对仍被引用的用例，先标记停用并通知引用方，确认后再归档，不要直接删除。
处置完成后，怎么确认公共用例库已经恢复正常？
建议在处置后一个发布周期内复测一次，对比处置前后的过期用例占比、共享用例执行通过率、引用覆盖率和复审完成率。若通过率仍偏低，回到原因排查环节检查是否有遗漏的过期类型或未同步的需求变更。指标恢复后再把复审安排固定下来，转入日常维护。
