最让测试工程师头疼的红灯，有时不是一直失败，而是你点进去重跑，它又好了。

于是大家给它加一次重试。过几天，重试两次。再过几天，失败报告里只留下最后一次的绿色结果。

可如果问题来自用例之间互相污染，重试只是让污染碰巧没有发生。

今天讨论一种具体情况：某条用例单跑通过，放在另一条用例后面就失败。 它和模型回答措辞变化、网络偶发超时不是同一种问题，排查方法也应该不同。

一个配置开关，怎样影响了另一条用例

设想一个AI报告生成服务：正式模式读取真实模板，演示模式使用简化模板。产品约定，未设置REPORT_DEMO时必须使用正式模式。

业务代码这样读配置：

import os

def report_mode():
    return "demo" if os.getenv("REPORT_DEMO") == "1" else "formal"

第一条测试把环境变量改成演示模式，验证完成后没有恢复。第二条测试以为自己处在默认环境里。单独运行第二条没问题，第一条先运行，第二条就失败。

注意：这不是说“CI的执行顺序一定不对”。正常情况下，两条测试就不应该依赖谁先谁后。顺序变化只是把缺陷暴露出来了。

下面是pytest中的修复写法：

def test_demo_mode(monkeypatch):
    monkeypatch.setenv("REPORT_DEMO", "1")
    assert report_mode() == "demo"

def test_default_is_formal(monkeypatch):
    monkeypatch.delenv("REPORT_DEMO", raising=False)
    assert report_mode() == "formal"

第一条用例的修改会在fixture清理时恢复；第二条明确建立“未设置变量”的前置条件，不再把运行机器的现状当作测试夹具。

但如果业务模块在import时就读取环境变量，之后缓存为模块常量，上面这套改环境变量的方法不会自动刷新常量。此时要修正配置注入设计，或者在明确的位置重新构造配置对象，而不是不停增加monkeypatch。

先找“污染源”，再讨论要不要重写框架

发现B单跑通过、整套失败，可以先做一组很小的实验：

python -m pytest test_report.py::test_default_is_formal -q
python -m pytest test_report.py::test_demo_mode test_report.py::test_default_is_formal -q
python -m pytest test_report.py::test_default_is_formal test_report.py::test_demo_mode -q

比较B、A→B、B→A三个结果。若只有A→B失败，就获得了一条可验证线索：A很可能改变了B依赖的状态。

这还不能直接断言A是唯一根因。真实套件可能是A创建目录、C写入文件，最后B读到了文件；也可能只有多个条件组合才触发。排查时应保留失败的用例列表、顺序、随机种子、worker数量和运行目录，逐步删减前序用例，找到最小的失败组合。

只保存“重试成功”四个字，等于把最值钱的线索扔掉。

换成并行执行，隔离边界还得再检查一遍

有的团队看到串行跑太慢，会直接增加worker。执行时间缩短了，用例共享的东西却没跟着拆开。

同一个固定账号、同一个下载文件名、同一份数据库记录，都可能被不同worker同时修改。进程隔离能隔开一部分内存变量，隔不开公共数据库和对象存储。

tmp_path能解决的是用例临时目录隔离，不会自动处理已经上传到远端的文件。远端资源也需要唯一标识和清理机制，且清理操作要只针对本轮创建的对象。

import json

def test_report_file(tmp_path):
    path = tmp_path / "report.json"
    payload = {"status": "ready", "items": ["case-01"]}
    path.write_text(json.dumps(payload), encoding="utf-8")

    restored = json.loads(path.read_text(encoding="utf-8"))
    assert restored == payload

这个例子很小，但前提很明确：文件归当前测试所有，不需要依靠“别人没有碰它”。实际项目再把被测报告生成函数接到path参数上，就能沿用这条隔离边界。

AI生成测试的Skill，也要约束资源生命周期

给AI一个函数，它通常很容易补出几个assert。真正需要写进测试生成Skill的，是assert之外的约束：

每条测试显式声明前置条件。
修改全局状态时必须有恢复机制。
临时路径由测试框架分配，不使用固定公共路径。
后台任务必须等待结束或确认取消。
外部资源以本轮运行标识隔离，清理范围不能扩大。
遇到失败先保留首次证据，不自动用重试掩盖。

也可以让AI分析失败顺序、找出共同读写资源，但判断污染源必须回到复现结果。两个用例都访问同一张表，只能说明有关联，不能据此认定谁写坏了数据。

对已有套件，没必要一次性推倒重来。先选出一条反复重试的用例，补齐前置条件和资源清理，再比较修复前后的顺序敏感性。这个改动往往比再增加一百条正常路径更有价值。

一套让人信任的自动化，不只是能把问题测出来，还要让人愿意相信：它红的时候，确实值得停下来查。

关于我们

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。