Docker容器中Pytest收集15个测试用例耗时超75秒的排查求助

场景概述 #

现有15个测试用例（仅2个测试文件），pytest的--collect-only收集操作耗时长达75秒，本地与Docker环境下均出现该问题，已排除文件扫描范围过大的因素，此前该操作耗时不足1秒。

排查步骤 #

• 检查测试模块的顶层执行逻辑
  pytest收集测试时会执行测试文件及导入模块的顶层代码（非测试函数内的代码），如果这些代码包含耗时操作（如数据库连接、远程API调用、大文件读取、复杂初始化计算），会直接拖慢收集速度。

  • 临时注释测试文件中的非必要导入或顶层初始化代码，重新执行收集命令，验证是否提速。
  • 使用poetry run pytest --collect-only -s ./src/e2e/test_*，查看收集过程中的实时输出，定位卡顿环节。

• 排查pytest插件的影响
  当前启用的插件包括pspec-0.0.4、mock-3.10.0、anyio-3.6.2，插件的逻辑可能在收集阶段引入额外开销：

  • 禁用所有插件执行收集：poetry run pytest --collect-only -p no:pspec -p no:mock -p no:anyio ./src/e2e/test_*，若速度恢复，逐个重新启用插件，定位问题插件。
  • 尝试升级问题插件到最新稳定版，或替换为功能类似的替代插件。

• 回溯依赖版本变化
  对比此前正常运行时的依赖版本，排查是否因依赖升级导致性能退化：

  • 回滚到之前的poetry.lock文件，执行poetry install后重新测试。
  • 用poetry show --tree查看依赖树，重点关注pytest、py、pluggy等核心库的版本差异。

• 性能 profiling 定位瓶颈
  使用工具分析收集过程的耗时分布：

  • 用Python内置的cProfile：poetry run python -m cProfile -s cumulative -m pytest --collect-only ./src/e2e/test_*，报告中会显示累计耗时最高的函数/模块。
  • 安装pytest-profiling插件，执行poetry run pytest --collect-only --profile生成可视化的性能报告。

• 检查Python路径与文件系统

  • 打印sys.path（可在测试文件顶层添加import sys; print(sys.path)），确认PYTHONPATH是否包含大量无关目录，导致导入时扫描过多文件。
  • 检查项目目录是否存在大量临时文件、缓存文件，或目录权限异常，导致文件读取效率下降。

常见可能原因 #

1. 测试模块或其导入的库中，顶层代码包含隐式的耗时IO/计算操作
2. pytest插件版本兼容性问题，导致收集逻辑低效
3. pytest或其依赖库升级后引入的性能退化
4. Python搜索路径配置异常，增大了导入时的文件扫描范围

内容的提问来源于stack exchange，提问作者rbhalla