在自动化测试项目中我们通过pytest_report_teststatus钩子收集用例结果并上报服务端。本地调试一切正常可一旦给启动命令加上-n参数无论是-n 1还是-n 5同一个用例就会被上报两次——用例明明只执行了一次服务端却收到两条一模一样的记录。本文从 pytest-xdist 的进程模型入手剖析 “master worker 双重触发钩子” 这一根因给出基于report.worker_id的推荐修复方案与流水线配置建议并附上服务端幂等兜底思路帮你绕开这个看似诡异、实则必然的坑。一、问题背景本文的问题源于此前两篇系列文章的工作在 《别再干等测试报告了用 pytest 钩子实时追上用例执行进度》 中我们介绍了如何通过pytest的pytest_report_teststatus钩子来上报用例状态在 《pytest 动态报告数据可视化篇 —— 用 Golang Echo 打造自动化测试任务可视化平台》 中则完整地使用该钩子上报数据实现了一套动态测试报告功能。在这套上报机制里我们通常会在conftest.py中通过pytest_report_teststatus钩子收集每个用例的执行结果然后上报到服务端# conftest.pydefpytest_report_teststatus(report):if(report.whensetupandreport.outcome.lower()skipped)orreport.whencall:ifnotUPLOAD_FLAG:return...在继续深入开发新功能的过程中本地无论是用 PyCharm 直接运行用例还是执行命令pytest-vscases/demo数据都完全正常每条用例对应一条记录干净且无重复。然而一旦进入流水线并在启动命令中追加并发参数pytest-vs-lcases/demo-n1问题立刻出现同一个用例被上报了两次。更诡异的是数据规律——-n 5是两次-n 1也是两次不多不少恰好翻倍。这种稳定地翻倍通常意味着不是随机竞态而是有确定性的结构原因。二、现象启动方式用例执行次数上报次数pytest -vs cases/demo正常正常pytest -vs cases/demo -n 1正常× 2pytest -vs cases/demo -n 5正常× 2这里有两个关键观察点用例本身只执行了一次pytest 输出里每个用例也只出现一次PASSED上报次数与并发量无关-n 1和-n 5都是两次。也就是说重复发生在上报这一环而不是执行这一环。三、原因分析1.-n会启动 master worker 两组进程pytest-xdist的-n参数表示启动并行 worker 的数量。不同启动方式对应的实际进程数如下命令实际进程不带-n只有 1 个主进程-n 1master 1 个 workergw0共 2 个进程-n 5master 5 个 workergw0 ~ gw4共 6 个进程关键点在于pytest_report_teststatus钩子在 master 和 worker 里各会被调用一次。worker 侧xdist 的 worker 是独立运行的 pytest 进程它自己执行用例时也会触发本进程内的pytest_report_teststatusmaster 侧master 进程在汇总各 worker 回传的结果时同样会再次触发这个钩子。因此只要开启-n哪怕只有-n 1钩子就会在 master 和 gw0 里各执行一次同一个用例自然被上报两次。2. 为什么-n 5也是两次而不是六次因为 xdist 默认调度策略下每个用例只会被分配给一个 worker 执行。worker 只对自己实际执行的用例触发pytest_report_teststatus而 master 会对所有用例再触发一次。所以上报次数 worker 上报 1 次 master 上报 1 次 2 次这个结果与 worker 数量无关——无论开几个 worker单个用例的执行侧上报始终只有一次汇总侧上报也只有一次。3. 为什么不带-n就正常不带-n时没有 xdist只有 1 个进程pytest_report_teststatus只被调用一次自然不会有重复。四、解决办法推荐方案通过report.worker_id判断当前是否处于 xdist 模式# conftest.py# 用于修改测试报告的状态单个用例执行完成后defpytest_report_teststatus(report):# 输出用例状态可以进行数据上报ifnothasattr(report,worker_id):# 只有在 pytest 测试命令中使用 -n 参数设置了并发量才会触发上报returnif(report.whensetupandreport.outcome.lower()skipped)orreport.whencall:ifnotUPLOAD_FLAG:return...这个写法有两个好处本地调试不会上报本地不带-n运行时report上没有worker_id属性hasattr(report, worker_id)为False直接return不会触发任何上报逻辑也就不会产生脏数据。流水线才上报流水线里使用-n 1或-n N时report上带有worker_id属性上报逻辑才会生效。原理提醒report.worker_id是 pytest-xdist 注入的属性仅存在于 xdist 模式下。它的存在与否恰好可以作为当前是否处于并发模式的判别依据。流水线配置建议流水线中可以设置默认并发量为-n 1同时允许用户自定义# 默认值PYTEST_CONCURRENCY${PYTEST_CONCURRENCY:--n 1}pytest-vs-lcases/demo$PYTEST_CONCURRENCY--alluredir./allure-results这样本地开发时直接执行pytest -vs cases/demo不会上报只有流水线里才会触发上报逻辑。兜底方案服务端加幂等去重无论客户端怎么控制网络重试、重复启动、rerun插件都可能导致重复上报。因此建议服务端用唯一键如pipeline_id task_id node_id 执行序号做幂等让重复上报在落库时被吞掉。客户端过滤负责少发服务端幂等负责万无一失。五、常见误区误区 1--distworksteal能解决重复不能。--dist只影响用例如何分配给 worker不影响 “master / worker 都会触发 hook” 这一事实。改变调度策略重复问题依旧。误区 2-n 1等于不带-n不等。-n 1仍然处于 xdist 模式会启动 master gw0 两个进程只有不带-n才是纯单进程模式。这正是本地正常、流水线翻倍的根源所在。误区 3在pytest_collection_finish里判断了并发模式就够了不够。pytest_collection_finish只控制用例清单的上传而pytest_report_teststatus是另一个钩子需要单独加判断。两个钩子各管一段不能混为一谈。六、总结场景行为是否重复不带-n单进程无worker_id不上报-n 1master 1 worker钩子带worker_id否× 1-n Nmaster N workers钩子带worker_id否× 1核心结论通过hasattr(report, worker_id)判断当前是否处于 xdist 并发模式——本地单进程无此属性、直接跳过流水线并发模式下才执行上报。这样既能避免本地调试时产生脏数据又能保证流水线里正常上报同时配合服务端幂等兜底方能万无一失。一句话记住这个坑钩子会在 master 和 worker 两侧各跑一次-n一开就翻倍——用worker_id判断自己是否处于并发模式只在流水线上报才是正解。
