偶现 Bug 怎么排查：不稳定测试（flaky test）与时好时坏问题定位提示词
测试在 CI 里时过时不过、线上问题一天出现几次却本地复现不了时用：让 AI 按「时间、顺序、共享状态、环境、外部依赖」五类原因逐一排查，给出提高复现率的办法和要加的诊断日志，而不是直接猜一个修法。
通用大模型 对话模型通用
你是一名擅长排查「偶现问题」的资深工程师。偶现问题的特点是：直接看代码往往看不出错，必须先想办法让它稳定复现。 问题情况： - 技术栈与运行环境：[语言/框架/CI 平台] - 现象：[失败时的报错或表现] - 出现频率：[如 20 次跑 3 次失败] - 只在哪些条件下出现：[如只在 CI、只在并行跑、只在凌晨] - 相关代码（测试代码 + 被测代码）： [粘贴代码] - 已经试过的办法：[已尝试] 请按下面顺序工作： 1. 先判断属于哪一类，逐类说明「是否可能、依据是什么」： - 时间相关：依赖当前时间、时区、夏令时、超时设置太紧、sleep 等待； - 顺序相关：测试之间共享全局变量、数据库数据、缓存、单例，换顺序或单独跑结果不同； - 并发相关：异步未等待完成、竞态、线程池、事件循环； - 环境相关：CPU 慢、机器时区、语言区域、文件系统大小写、随机端口冲突； - 外部依赖：网络请求、第三方服务、未固定的随机数种子、未锁定的依赖版本。 2. 给出「提高复现率」的具体做法，例如循环跑 N 次、打乱测试顺序、限制 CPU、固定或改变随机种子、把等待时间调小放大问题，写出对应命令。 3. 列出要加的诊断信息：在哪几行打什么日志、记录哪些变量，能区分你列出的几种假设。 4. 针对可能性最高的两个原因，各给一个修复方案；说明为什么修复后不再偶现，而不是「把超时调大」「加重试」这种掩盖问题的做法。如果只能临时加重试，明确标注为临时措施并说明风险。 5. 给出验证方法：修复后要连续跑多少次、在什么条件下跑，才能说明问题解决了。 约束：不确定的地方写「需要以下信息确认」；不要建议直接删除或跳过这个测试，除非同时给出替代的覆盖方式。
高亮处换成你自己的内容：[语言/框架/CI 平台]、[失败时的报错或表现]、[如 20 次跑 3 次失败]、[如只在 CI、只在并行跑、只在凌晨]、[粘贴代码]、[已尝试]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[出现频率] 和 [只在哪些条件下出现] 是最关键的线索——「只在 CI 失败」多半是环境或并行问题，「单独跑能过、整套跑不过」几乎一定是测试之间共享了状态。测试代码和被测代码都要贴，只贴测试很难判断。
常见坑：
- 最常见的「修法」是把等待时间从 1 秒改成 5 秒，问题会变少但不会消失，还让整套测试变慢。正确做法是等待一个明确条件（元素出现、消息到达、任务完成）。
- 时间类问题经常藏在「月底、跨年、凌晨 0 点、夏令时切换」这些边界上，可以让 AI 写一个把系统时间固定到这些时刻的测试。
- 偶现问题修完要多跑几十次再下结论，跑一次通过说明不了什么。
追问技巧：加完诊断日志、拿到一次失败的完整日志后贴回去，说「根据这份日志，排除掉哪些假设、剩下哪个最可能」。
示例输出
示例，仅供参考（现象：订单列表测试在 CI 上约 15% 失败，本地单独跑全过）
| 类别 | 可能性 | 依据 |
|---|---|---|
| 顺序相关 | 高 | 测试用 created_at 倒序取第一条，而另一个测试也往同一张表插数据，未清理 |
| 时间相关 | 中 | 两条数据在同一毫秒插入时排序不稳定 |
| 并发相关 | 低 | 未见异步调用 |
提高复现率：
bash
# pytest：随机顺序 + 重复 50 次（需安装 pytest-randomly、pytest-repeat）
pytest tests/test_orders.py -p randomly --count=50 -x修复方案：每个测试在独立事务里运行并回滚；排序改为 ORDER BY created_at DESC, id DESC，保证同一时间戳下顺序稳定。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～