一、先确认是否属于 Flaky Test

建议先重复运行同一个测试：

或者连续执行多次：

需要记录：

• 失败出现的频率；
• 是否只在 CI 中失败；
• 单独运行是否通过；
• 与其他测试一起运行是否失败；
• 失败日志是否完全一致；
• 是否与执行顺序有关。

可以把这些结果交给 Codex：

二、重点排查五类原因

1. 异步操作没有等待完成

例如页面仍在请求数据，测试已经开始断言：

更合理的方式是等待元素出现：

但不能简单地把所有等待时间延长。真正需要确认的是：测试是否等待了明确的业务结果。

2. 测试之间共享状态

某个测试修改了全局变量、缓存或 Mock，却没有清理，可能影响后续测试。

重点检查：

• localStorage；
• 全局状态管理；
• 数据库测试数据；
• Mock 请求；
• 单例对象；
• 环境变量；
• Fake Timer。

建议在每个测试结束后恢复状态：

3. 依赖真实时间

如果测试与当前日期、时区或倒计时有关，在不同时间和环境中可能得到不同结果。

例如：

可以在测试中固定时间：

这样本地和 CI 执行时会得到一致结果。

4. 使用随机数据

测试中直接使用随机数、随机用户名或随机订单状态，会导致结果不可复现。

不建议：

更推荐固定输入，或者记录随机种子：

测试的目标是验证确定行为，而不是每次制造不同条件。

5. 依赖外部服务

如果测试直接请求真实 API、数据库或第三方服务，网络延迟和服务状态都会影响结果。

更稳定的方式是：

• 单元测试使用 Mock；
• 集成测试使用独立测试环境；
• 外部服务设置明确超时；
• 测试数据可重复创建和清理；
• 将外部依赖测试与普通单元测试分开。

三、不要用重试掩盖根因

一些 CI 平台支持失败后自动重试。重试可以作为临时保护，但不能代替修复。

如果一个测试重试三次后通过，仍然说明它不稳定。

需要警惕这些修改：

可以让 Codex审查：

四、修复时坚持最小范围

假设问题来自用户状态没有清理，本次修改只需要涉及：

不应该顺便重构完整用户模块。

可以明确限制：

如果确认生产代码本身存在竞态条件，再单独建立业务修复任务。

五、修复后如何证明稳定？

一次测试通过不能说明 Flaky Test 已经解决。

建议完成三层验证。

第一层：重复运行当前测试

连续执行 20—50 次，确认不再偶发失败。

第二层：与完整测试集一起运行

检查是否存在测试顺序依赖。

第三层：在 CI 环境验证

确认 Linux、不同 Node.js 版本或并行执行时仍然稳定。

同时运行：

最后检查：

确认没有通过删除测试、放宽断言或修改无关文件获得“稳定”。

六、让 Codex 输出测试修复报告

任务完成后可以要求：

例如：

七、什么时候适合评估升级 Pro？

偶尔分析一个失败测试，现有方案通常能够满足需求。

但如果每天都需要 Codex：

• 阅读大量 CI 日志；
• 重复运行测试；
• 分析异步和竞态问题；
• 修改多个测试与业务文件；
• 连续处理多轮失败结果；
• 同时维护多个仓库；

任务会形成较长的调试链路。

这时应先通过限定测试范围、固定时间、清理共享状态和拆分任务减少无效消耗。如果工作流已经优化，但测试分析、修改和重复验证仍经常因使用限制中断，就可以重新评估当前方案。

对于长期把 Codex 用于测试、调试和项目交付的开发者，Pro 更适合持续推进多轮工程任务，减少在问题尚未验证完成时反复恢复上下文的成本。

总结

Flaky Test 的难点不是让它“这一次通过”，而是证明它以后能够稳定通过。

更可靠的处理流程是：

记录失败频率 → 定位不确定因素 → 最小范围修复 → 重复运行验证 → 完整测试与 CI 检查。

Codex 可以帮助分析异步逻辑、共享状态、时间和外部依赖，但不能通过重试或降低测试标准掩盖问题。

只有测试结果可重复、失败原因可解释、修改范围可审查，才算真正完成修复。