不稳定测试
Flaky Test
中级通用不稳定测试（Flaky Test）是指代码和测试条件看似没变，同一个测试却有时通过、有时失败。识别它能帮你追查偶发失败的原因，而不是把每次失败都当成新改动造成的回归。
你可能会说：「这条测试没改代码也一会儿过一会儿不过，能帮我查清原因，让结果稳定吗？」
读之前建议先了解
动手看看登录测试的偶发超时
切换三次运行快照，再开关耗时详情。这里模拟的是同一测试的重复执行，不是在切换代码版本，也不会实际运行测试。
代码没变，这次却等到超时。先前通过、随后失败，是不稳定测试的典型信号，但还不能仅凭它断定原因。
十次里夹着三次失败，比单次红灯更能看出波动。这只是这批样本的结果，不代表长期失败率一定是三成。
失败耗时越过等待上限，提示你查接口延迟、异步等待和环境负载。超时是线索，别只调大上限就当修好了。
要点为什么同一条测试会时过时不过？
- 1
先确认失败能否反复出现
你可以在相同代码版本下重复运行，并记下失败时的日志和运行环境。如果结果忽过忽败，就有理由怀疑测试不稳定；但仅凭一次失败，还分不清是偶发问题还是稳定缺陷。
- 2
留意测试依赖的外部条件
比如网站的登录测试依赖共享账号、网络请求或后台任务。其他测试改了账号状态，或请求完成时间变化，结果就可能不同。我们要找的是哪项条件没有被测试固定住。
- 3
修复导致波动的具体原因
如果页面数据还没加载完，测试就去找按钮，我们可以等待可观察的加载结果，而不是固定暂停几秒。如果问题来自共享数据，就给测试准备独立数据；单纯重跑只会掩盖线索。
容易混淆的地方
不稳定测试说的是同一测试在条件看似相同的运行中结果摇摆；如果它每次都稳定失败，更像是代码缺陷或测试预期过时。它也不等于“测试写错了”：偶发失败可能暴露产品里的竞态问题，排查时要同时检查测试和被测功能。
什么时候用
适合用
- 持续集成里同一条用例偶尔失败、重跑又通过时，用它描述现象，并追查时间、数据和环境依赖。
- App 的端到端测试在不同运行中随机卡在登录步骤时，用它帮助团队区分测试波动与稳定回归。
- 合并请求被偶发失败挡住时，用它要求 AI Agent 保留失败证据、定位原因，而不是只建议重跑。
不适合用
- 一个新功能还没有测试，眼下要做的是设计测试用例；“不稳定测试”不能替代测试范围和预期结果。
- 某个接口测试每次都报同一个断言错误，先核对实现和预期；稳定复现的失败不属于不稳定测试。
- 你想确认产品上线后整体是否可用，可以安排冒烟测试；“不稳定测试”是对现有测试结果波动的描述。
练一练选一个答案，看看解释
你的网站测试在持续集成中偶尔找不到“提交订单”按钮，重跑通常通过；截图显示失败时页面还在加载。下一步怎么做更合适？
让 AI 帮你做复制给 AI Agent 直接用
请排查这条不稳定测试：在相同代码版本下记录通过与失败时的日志、页面状态和运行条件，找出结果波动的原因。优先修复等待条件、测试数据或被测功能中的实际问题；修改后重复运行验证，并说明是否仍有未排除的原因。