偶发用例的隔离流程
隔离（quarantine）流程：确认 flaky 的用例先移出阻塞门槛（标记或迁入独立套件），记录责任人与期限；隔离数量与滞留时长都纳入跟踪。隔离的本质是止血：把不稳定用例从影响合并判断的位置挪开，同时保留它继续运行、继续暴露，等修复验证后再回归常规套件。
基本信息
| 判定入口 | 连续失败与重跑结果不一致，先归因再隔离 |
|---|---|
| 隔离形态 | 标记排除、迁入独立套件或降级为非阻塞 |
| 记录要素 | 责任人、原因、期限、关联缺陷单 |
| 跟踪指标 | 隔离数量、滞留时长、修复率 |
| 保持运行 | 独立套件周期执行，保留暴露通道 |
| 解除条件 | 修复验证稳定后回归常规套件 |
| 修复入口 | 先复现根因（等待策略、数据竞争）再动手 |
隔离形态示意
隔离形态示意
pytest -m "not quarantined" -q # 标记排除
# Playwright：test.fixme() 或独立 project 单独运行
# 隔离清单每周巡检：责任人、期限、状态隔离状态跟踪
| 状态 | 动作 | 出口 |
|---|---|---|
| 新隔离 | 归因并登记责任人与期限 | 进入观察期 |
| 观察中 | 独立套件继续执行 | 稳定后解除隔离 |
| 已修复 | 回归常规套件并观察 | 无复发即关闭 |
| 超期 | 升级处理或评估用例价值 | 重新决策去留 |
典型使用场景
- 合并阻塞：主干被 flaky 拦住时快速止血。
- 发布窗口：不因个别不稳定用例延迟发布，但保留跟踪。
- 治理周会：按隔离清单过责任人、期限与进展。
- 根因分析：高频隔离的用例反查等待策略与数据隔离。
- 度量汇报：隔离比例与平均滞留时长作为测试健康度指标。
- 框架迁移：迁移期用隔离控制不稳定面。
隔离不等于关闭：缺少期限与责任人的隔离会演变为长期忽略。
高频失败用例优先修复：隔离名单按影响排序，而不是先来先修。
重跑通过不是修复证据：先归因（时序、数据、并发）再决定动作。