编程开发 编辑复核
不稳定测试定位与隔离
把偶发失败的用例按重跑证据分类,判断是真缺陷还是环境抖动,给出隔离范围与修复顺序。
PROMPT WORKBENCH
复制后替换变量
保留结构,先填真实信息,再把结果交给模型运行。
你是一名测试稳定性治理工程师。请根据失败记录判断哪些用例是真缺陷、哪些是环境抖动,并给出隔离与修复计划。
先把已知事实、合理假设和待核验信息分开;资料不足时写“待验证”,不要为了完整而猜测。
请按以下结构输出:
1. 汇总每个用例的失败次数、失败分支、运行机器和时间分布
2. 给出复现方案,说明本地重复运行次数、并发设置和需要关闭的自动重试
3. 按失败比例分类,区分疑似真缺陷、环境相关和用例本身写错
4. 标注可能的成因方向,例如时序等待、用例间数据污染、共享资源竞争
5. 给出隔离规则,说明哪些用例暂时不阻塞合并以及如何保持可见
6. 排出修复顺序,写明负责人、期限和解除隔离的判据
输入变量:
- 失败记录({{failure_records}}):粘贴失败用例名称、次数、日志片段和运行环境。
- 测试套件情况({{suite_context}}):说明框架、并发方式、重试策略和运行环境。
- 影响范围({{impact_scope}}):说明这些失败对合并和发布造成的阻塞。
约束:保留原始上下文和限定条件;每个结论都说明依据;涉及个人资料、合同、财务、医疗或安全信息时先提示脱敏和人工复核。HOW TO USE
使用说明
- 先关掉自动重试再复现,否则看不到真实失败率。
- 失败率超过一半的用例按缺陷处理,不要放进隔离清单。
WHEN IT FITS
适用判断
适合这些情况
- 团队已经养成失败就重跑的习惯。
- 同一批用例反复失败但改完代码又能通过。
- 需要一份可执行的隔离与修复清单。
换个做法更好
- 所有用例都在失败:先查构建和环境,不要按不稳定处理。
- 失败与最近改动明显相关:按普通缺陷排查。
- 只想让流水线变绿:直接跳过测试会掩盖真实缺陷。
FAILURE MODES
常见翻车与修正
- 把真缺陷当成不稳定测试隔离掉了。
要求给出重跑样本量和失败比例,样本不足时输出证据不足而不是结论,并保留失败日志对比。
- 隔离清单越来越长,没人再去修。
为每个用例登记负责人、到期时间和解除条件,并在看板上跟踪清单规模。
ACCEPTANCE
怎么判断输出合格
- 每个用例的分类都有重跑数据支撑。
- 复现方案可以直接执行。
- 隔离规则写明了可见性与到期条件。
- 修复顺序有负责人和解除判据。
SAFETY BOUNDARY
使用边界
- 支付、登录和权限相关用例不要自动隔离,必须人工判断后再决定。
- 隔离只是临时措施,要配到期时间,避免变成永久跳过。