Python中如何利用pytest-xdist插件实现多核CPU并行测试？

用 pytest-xdist 做并行测试，本意是让测试跑得更快，但很多人装完插件，一句 pytest -n auto 敲下去，却发现耗时纹丝不动，甚至更慢了。问题不出在插件本身，而在于测试用例是否满足并行的前提条件。

根本症结在于：每个测试用例必须是相互隔离的独立个体。一旦存在共享状态或资源竞争——比如共用一个数据库连接、写入同一个临时文件路径、修改同一个全局变量——并行执行非但不会提速，反而会因为锁竞争、资源等待而拖慢整体速度。此外，如果测试用例总数少于10个，并行的收益也极其有限，因为进程创建和调度的开销可能超过执行本身。遇到这种情况，不要急着怀疑插件，先检查测试的隔离性。可以这样操作：用 pytest --collect-only 确认用例数量是否足够；排查是否有人在测试中修改了模块级变量，比如 conftest.py 里定义了一个 shared_counter = 0；避免在 setup_method 里创建全局临时目录，改用 tmp_path fixture——它会为每个进程生成独立的路径。

既然 -n auto 不够靠谱，那该如何指定核心数？-n auto 默认调用的是 os.cpu_count()，但在实际环境中，可用核心经常被系统保留，或者被超线程技术干扰，算出来的数字并不准确。尤其在 CI 环境（比如 GitHub Actions 默认只分配 2 核）下，直接用 auto 反而容易踩坑。稳妥的做法是显式指定一个合理的数字。首先，可以用 python -c "import os; print(os.cpu_count())" 查一下真实可用的逻辑核数。然后，给系统调度留出 1 个核心——比如一台 4 核机器，建议用 -n 3 而不是 -n auto。如果遇到内存敏感型测试，还可以加上 --max-sla ve-restart=0 来防止子进程 OOM 后反复重启。一个经过验证的示例命令是：pytest -n 3 --dist=loadgroup -v。loadgroup 会按测试类分组分发任务，比默认的 load 策略更均衡，能有效避免某个 worker 被大量耗时长的用例拖累。

并行测试一旦失败，定位问题就像大海捞针——不同 worker 的日志混在一起，错误堆栈也被截断，根本分不清哪个进程出了问题。关键是要让输出变得清晰可追溯。可以加上 --tb=short 避免长 traceback 刷屏，同时配合 -v 显示完整的测试名。如果需要更细粒度的日志，用 --log-file=test.log --log-file-level=INFO 把各 worker 的日志分开写入（这需要配合项目的 logging 配置）。最有效的方式是启用 --boxed 参数——它让每个测试在独立进程中运行，即使某个测试崩溃，也不会污染其他 worker 的状态。不过要注意，--boxed 会显著降低性能，所以建议只在调试阶段启用。

pytest 生态虽好，但不是所有插件和 fixture 都与 xdist 兼容。最常见的冲突点在于那些依赖进程内单例或共享内存的工具。比如 pytest-cov 需要升级到 4.0 及以上版本，同时显式加上 --cov-report=term-missing --cov=myproject，否则覆盖率统计会莫名其妙地丢失。再比如 pytest-asyncio，在 --asyncio-mode=auto 下可能导致死锁，建议固定为 --asyncio-mode=strict。对于自定义 fixture，如果用了 atexit.register() 或 threading.local()，需要将其改为进程安全的版本，比如用 multiprocessing.Manager 来管理共享数据。

这里有个容易被忽视的细节：conftest.py 里的 pytest_runtest_makereport hook 其实是在 worker 进程中执行的，因此不能假设它和主进程共享任何变量。遇到这类问题，最好的办法是重新检查 fixture 的设计，确保每个 worker 拥有独立的状态空间。