摘要自动化测试有时通过、有时失败通常被称为 Flaky Test。这类问题比固定报错更难排查因为它可能与异步操作、时间、随机数据、测试顺序或外部服务有关。本文介绍如何使用 Codex 收集失败证据、定位不稳定因素并通过重复运行和 Git Diff 验证修复结果。在项目开发中最难处理的测试不一定是“每次都失败”而是下面这种情况第一次运行通过 第二次运行失败 第三次运行通过这类偶发失败会影响 CI/CD 稳定性也容易让团队误以为是构建平台出了问题。不少开发者会直接让 Codex把这个测试改到可以通过。这种要求很危险。Codex 可能通过增加重试、延长等待时间或降低断言标准让失败暂时消失却没有解决真正原因。一、先确认是否属于 Flaky Test建议先重复运行同一个测试npm run test -- user-profile.test.ts或者连续执行多次for i in {1..20}; do npm run test -- user-profile.test.ts || break done需要记录失败出现的频率是否只在 CI 中失败单独运行是否通过与其他测试一起运行是否失败失败日志是否完全一致是否与执行顺序有关。可以把这些结果交给 Codex当前测试连续运行 20 次其中失败 4 次。 单独运行通常通过 与完整测试集一起运行时更容易失败。 请先分析不要修改测试。 输出 1. 最可能的不稳定因素 2. 如何验证每个原因 3. 需要检查哪些文件 4. 最小修复方案 5. 如何证明问题已经解决。二、重点排查五类原因1. 异步操作没有等待完成例如页面仍在请求数据测试已经开始断言render(UserProfile); expect(screen.getByText(张三)).toBeInTheDocument();更合理的方式是等待元素出现expect( await screen.findByText(张三) ).toBeInTheDocument();但不能简单地把所有等待时间延长。真正需要确认的是测试是否等待了明确的业务结果。2. 测试之间共享状态某个测试修改了全局变量、缓存或 Mock却没有清理可能影响后续测试。重点检查localStorage全局状态管理数据库测试数据Mock 请求单例对象环境变量Fake Timer。建议在每个测试结束后恢复状态afterEach(() { localStorage.clear(); vi.clearAllMocks(); vi.useRealTimers(); });3. 依赖真实时间如果测试与当前日期、时区或倒计时有关在不同时间和环境中可能得到不同结果。例如const today new Date();可以在测试中固定时间vi.useFakeTimers(); vi.setSystemTime(new Date(2026-07-23T10:00:00Z));这样本地和 CI 执行时会得到一致结果。4. 使用随机数据测试中直接使用随机数、随机用户名或随机订单状态会导致结果不可复现。不建议const quantity Math.floor(Math.random() * 10);更推荐固定输入或者记录随机种子const quantity 3;测试的目标是验证确定行为而不是每次制造不同条件。5. 依赖外部服务如果测试直接请求真实 API、数据库或第三方服务网络延迟和服务状态都会影响结果。更稳定的方式是单元测试使用 Mock集成测试使用独立测试环境外部服务设置明确超时测试数据可重复创建和清理将外部依赖测试与普通单元测试分开。三、不要用重试掩盖根因一些 CI 平台支持失败后自动重试。重试可以作为临时保护但不能代替修复。如果一个测试重试三次后通过仍然说明它不稳定。需要警惕这些修改增加等待时间 降低断言标准 跳过失败测试 设置多次重试 捕获异常后不处理。可以让 Codex审查请检查当前修复是否只是隐藏 Flaky Test。 重点确认 1. 是否增加了无依据的延迟 2. 是否降低了断言 3. 是否加入重试但没有修复根因 4. 是否遗漏状态清理 5. 是否仍依赖真实时间或外部服务。四、修复时坚持最小范围假设问题来自用户状态没有清理本次修改只需要涉及用户状态测试 测试初始化文件 相关 Mock。不应该顺便重构完整用户模块。可以明确限制允许修改 - tests/user - tests/setup.ts - 用户状态相关 Mock 禁止修改 - 生产业务逻辑 - 路由配置 - 权限规则 - package.json - 无关测试文件。如果确认生产代码本身存在竞态条件再单独建立业务修复任务。五、修复后如何证明稳定一次测试通过不能说明 Flaky Test 已经解决。建议完成三层验证。第一层重复运行当前测试连续执行 20—50 次确认不再偶发失败。第二层与完整测试集一起运行npm run test检查是否存在测试顺序依赖。第三层在 CI 环境验证确认 Linux、不同 Node.js 版本或并行执行时仍然稳定。同时运行npm run type-check npm run lint npm run build最后检查git status git diff --stat git diff确认没有通过删除测试、放宽断言或修改无关文件获得“稳定”。六、让 Codex 输出测试修复报告任务完成后可以要求请输出 Flaky Test 修复报告 1. 问题现象 2. 失败频率 3. 根本原因 4. 修改文件 5. 修复方式 6. 重复运行结果 7. 完整测试结果 8. 仍然存在的风险。例如## 根本原因 测试使用 Fake Timer 后没有恢复真实时间 导致后续用户状态测试的超时逻辑异常。 ## 修复内容 - 在 afterEach 中恢复真实时间 - 清理用户状态和 Mock - 补充测试顺序验证。 ## 验证结果 - 当前测试连续运行 50 次全部通过 - 完整测试集通过 - 类型检查通过 - 项目构建通过七、什么时候适合评估升级 Pro偶尔分析一个失败测试现有方案通常能够满足需求。但如果每天都需要 Codex阅读大量 CI 日志重复运行测试分析异步和竞态问题修改多个测试与业务文件连续处理多轮失败结果同时维护多个仓库任务会形成较长的调试链路。这时应先通过限定测试范围、固定时间、清理共享状态和拆分任务减少无效消耗。如果工作流已经优化但测试分析、修改和重复验证仍经常因使用限制中断就可以重新评估当前方案。对于长期把 Codex 用于测试、调试和项目交付的开发者Pro 更适合持续推进多轮工程任务减少在问题尚未验证完成时反复恢复上下文的成本。总结Flaky Test 的难点不是让它“这一次通过”而是证明它以后能够稳定通过。更可靠的处理流程是记录失败频率 → 定位不确定因素 → 最小范围修复 → 重复运行验证 → 完整测试与 CI 检查。Codex 可以帮助分析异步逻辑、共享状态、时间和外部依赖但不能通过重试或降低测试标准掩盖问题。只有测试结果可重复、失败原因可解释、修改范围可审查才算真正完成修复。CSDN 文章描述自动化测试有时通过、有时失败怎么办本文介绍如何使用 Codex 排查异步操作、共享状态、时间、随机数据和外部服务导致的 Flaky Test。推荐标签CodexFlaky Test自动化测试CI/CDChatGPT Pro参考资料Vitest 官方文档Jest 官方文档Testing Library 官方文档GitHub Actions 官方文档
)
