Skills × pytest：回归一上CI就红，问题藏在“测试顺序”里

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

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

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

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

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

一个配置开关，怎样影响了另一条用例
设想一个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。

人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇

先找“污染源”，再讨论要不要重写框架
发现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同时修改。进程隔离能隔开一部分内存变量，隔不开公共数据库和对象存储。

共享对象
常见污染方式
可落地的隔离方法
环境变量与模块状态
改完未恢复、导入时缓存
fixture管理、配置显式注入
临时文件
都写report.json
每条用例使用tmp_path
外部测试数据
共用固定订单或用户
运行ID＋workerID＋用例ID命名
后台线程或任务
主测试结束后仍在写
等待退出并验证资源释放
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测试的全链路：大模型能力评测、智能体Harness工程、Skill技能体系、CLI与MCP工具体系、RAG知识图谱——最后直接上手打造一个能自动生成测试用例的智能体。

关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。