Python长耗时测试怎么处理？pytest标记慢用例方法

在Python测试中，合理管理长耗时用例是提升开发效率与CI稳定性的关键——pytest通过`@pytest.mark.slow`装饰器提供轻量、语义清晰的“慢测试”标记机制，其核心在于由开发者基于业务上下文（如数据库操作、外部API调用、浏览器启动等）主动定义“慢”的含义，而非依赖不可靠的运行时耗时测量；只需在配置文件中注册marker，即可用`pytest -m slow`精准执行或`pytest -m "not slow"`高效跳过，完美适配本地快速验证、CI分层调度（如拆分为fast/slow双流水线）等场景，零性能开销且避免误判，真正实现可维护、可自动化、可协作的测试治理。

pytest怎么标记一个测试为“慢”

用 @pytest.mark.slow 装饰器，这是最直接、最被 pytest 原生支持的方式。它不依赖插件，也不需要改配置就能生效，但前提是你的项目里没禁用自定义 marker。

常见错误现象：加了 @pytest.mark.slow 却发现 pytest -m slow 没反应——大概率是 pytest 报告 “unknown marker”，说明你没在 pytest.ini 或 pyproject.toml 里注册它。

• 在 pytest.ini 中加：

  [tool:pytest]
  markers =
      slow: marks tests as slow (deselect with '-m "not slow"')

• 如果用 pyproject.toml，写成：

  [tool.pytest.ini_options]
  markers = ["slow: marks tests as slow (deselect with '-m \"not slow\"')"]

• 标记单个测试函数：@pytest.mark.slow 放在 def test_xxx(): 上方
• 标记整个类：@pytest.mark.slow 放在 class TestLongRun: 上方，类内所有方法自动继承

如何只跑慢测试或跳过慢测试

核心靠 -m 表达式筛选，不是靠开关或环境变量。它的行为是“选中”，不是“启用”，所以逻辑要反着想。

使用场景：CI 流水线里拆分任务，本地开发时快速验证主干逻辑，或者夜间定时全量跑一次慢用例。

• 只运行慢测试：pytest -m slow
• 跳过慢测试（日常开发推荐）：pytest -m "not slow"
• 同时匹配多个标签：pytest -m "slow and integration"，前提是你也定义并用了 integration marker
• 注意：如果命令行没加 -m，所有测试照常执行，@pytest.mark.slow 不会自动禁用任何用例

为什么不能只靠 time.sleep() 判断是否“慢”

因为耗时不可控：同一段测试在 CI 机器、M1 Mac、Windows WSL 下跑出的耗时可能差 3 倍；而且 setup/teardown、fixture 加载、网络抖动都会干扰测量。靠硬编码时间阈值做自动分类，维护成本高、误报多。

真正该做的，是把“慢”的语义交给开发者判断——比如涉及数据库迁移、外部 API 调用、大文件生成、真实浏览器启动的测试，人眼就知道不该进 PR 检查流。

• 别写这种逻辑：if time.time() - start > 5: pytest.mark.slow —— pytest 不支持运行时动态打标
• 别依赖 --durations=0 输出后人工筛选——无法用于自动化调度
• 性能影响：标记本身零开销；但如果你在 fixture 里偷偷做了耗时操作再打标，那就本末倒置了

CI 中如何安全隔离慢测试

关键不是“怎么跑”，而是“谁来跑、什么时候跑”。直接在主 CI job 里加 -m "not slow" 最省事，但容易漏掉标记遗漏的用例；更稳的做法是显式拆成两个 job：一个 fast-only，一个 slow-only。

容易踩的坑：在 slow job 里忘了加超时限制，导致某个测试卡死拖垮整条流水线。

• GitHub Actions 示例片段：

    slow-tests:
      runs-on: ubuntu-latest
      timeout-minutes: 30
      steps:
        - run: pytest -m slow --tb=short

• GitLab CI 同理，用 timeout: 字段约束 job 总时长，比在 pytest 里设 --timeout 更可靠
• 不要在 conftest.py 里全局 pytest_runtest_makereport 拦截慢测试——这属于过度设计，且和 -m 机制冲突

复杂点在于：有些测试“慢”是条件性的，比如只在特定 ENV=prod 下才触发重试逻辑。这种得靠参数化 + 组合 marker，而不是指望 pytest 自动识别。

到这里，我们也就讲完了《Python长耗时测试怎么处理？pytest标记慢用例方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！