编程开发 编辑复核

不稳定测试定位与隔离

把偶发失败的用例按重跑证据分类,判断是真缺陷还是环境抖动,给出隔离范围与修复顺序。

场景:流水线频繁误报、测试时红时绿时的处理输出:失败样本归类 + 复现方案 + 隔离与看护规则 + 修复顺序更新于 2026-09-01

复制后替换变量

保留结构,先填真实信息,再把结果交给模型运行。

你是一名测试稳定性治理工程师。请根据失败记录判断哪些用例是真缺陷、哪些是环境抖动,并给出隔离与修复计划。

先把已知事实、合理假设和待核验信息分开;资料不足时写“待验证”,不要为了完整而猜测。

请按以下结构输出:
1. 汇总每个用例的失败次数、失败分支、运行机器和时间分布
2. 给出复现方案,说明本地重复运行次数、并发设置和需要关闭的自动重试
3. 按失败比例分类,区分疑似真缺陷、环境相关和用例本身写错
4. 标注可能的成因方向,例如时序等待、用例间数据污染、共享资源竞争
5. 给出隔离规则,说明哪些用例暂时不阻塞合并以及如何保持可见
6. 排出修复顺序,写明负责人、期限和解除隔离的判据

输入变量:
- 失败记录({{failure_records}}):粘贴失败用例名称、次数、日志片段和运行环境。
- 测试套件情况({{suite_context}}):说明框架、并发方式、重试策略和运行环境。
- 影响范围({{impact_scope}}):说明这些失败对合并和发布造成的阻塞。

约束:保留原始上下文和限定条件;每个结论都说明依据;涉及个人资料、合同、财务、医疗或安全信息时先提示脱敏和人工复核。

使用说明

  1. 先关掉自动重试再复现,否则看不到真实失败率。
  2. 失败率超过一半的用例按缺陷处理,不要放进隔离清单。

适用判断

适合这些情况

  • 团队已经养成失败就重跑的习惯。
  • 同一批用例反复失败但改完代码又能通过。
  • 需要一份可执行的隔离与修复清单。

换个做法更好

  • 所有用例都在失败:先查构建和环境,不要按不稳定处理。
  • 失败与最近改动明显相关:按普通缺陷排查。
  • 只想让流水线变绿:直接跳过测试会掩盖真实缺陷。

常见翻车与修正

  • 把真缺陷当成不稳定测试隔离掉了。

    要求给出重跑样本量和失败比例,样本不足时输出证据不足而不是结论,并保留失败日志对比。

  • 隔离清单越来越长,没人再去修。

    为每个用例登记负责人、到期时间和解除条件,并在看板上跟踪清单规模。

怎么判断输出合格

  1. 每个用例的分类都有重跑数据支撑。
  2. 复现方案可以直接执行。
  3. 隔离规则写明了可见性与到期条件。
  4. 修复顺序有负责人和解除判据。

使用边界

  • 支付、登录和权限相关用例不要自动隔离,必须人工判断后再决定。
  • 隔离只是临时措施,要配到期时间,避免变成永久跳过。