pytest测试失败自动重试方法详解

本文深入探讨了pytest测试失败时是否应自动重试这一关键实践问题：一方面明确指出官方不默认启用重试的深层原因——避免掩盖资源竞争、状态残留、时序缺陷等真实bug，强调稳定性必须源于良好的测试设计和环境治理；另一方面也坦诚面对CI中DNS抖动、API限流、元素加载延迟等现实痛点，系统对比了成熟插件（如pytest-rerunfailures）与手写重试逻辑的优劣，警示装饰器方案对fixture生命周期和错误堆栈的破坏，并精准划定了重试的适用边界——仅限无副作用的IO类外部依赖失败，同时提供可落地的异常类型识别指南和CI优化建议，帮助开发者在“盲目重试”和“放任失败”之间做出理性、稳健的技术决策。

测试用例执行失败不一定是代码问题，很可能是环境抖动或异步依赖未就绪；pytest 默认不重试，得靠插件或自定义逻辑补上这一环。

为什么 pytest 默认不重试失败用例

因为重试会掩盖真实缺陷：比如资源竞争、状态残留、时序 bug，这些在重试后可能“恰好通过”，反而让问题更难定位。官方认为稳定性应从测试设计和环境治理入手，而非靠重试兜底。

但现实是：CI 环境 DNS 不稳、数据库连接偶发超时、第三方 API 限流、Selenium 元素加载延迟——这类非业务逻辑失败，重试确实能提升流水线成功率。

• 重试只适合 IO 类、网络请求、浏览器交互 等外部依赖强的测试
• 禁止对数据库写入、消息发送、支付回调等有副作用的操作重试
• pytest-xdist 并行运行时，重试可能加剧资源争抢，需配合 --maxfail=1 控制

用 pytest-rerunfailures 插件最省事

这是目前最成熟、兼容性最好的重试方案，支持 Python 3.7+ 和 pytest 7.x/8.x，安装后无需改测试代码。

安装与启用：

pip install pytest-rerunfailures

运行时加参数即可：

• 重试 2 次（共执行最多 3 次）：pytest --reruns 2
• 仅对特定标记重试：pytest -m "flaky" --reruns 3，再给用例加 @pytest.mark.flaky
• 失败后等待 1 秒再重试：--reruns-delay 1

注意：--reruns 参数必须放在命令末尾，否则会被 pytest 当作测试路径解析，报 FileNotFoundError。

自己写重试逻辑？小心装饰器陷阱

有人用 @retry 装饰器封装测试函数，看似灵活，实则容易破坏 pytest 的 fixture 生命周期和错误堆栈。

• fixture（如 tmp_path、caplog）在每次重试中不会重新初始化，状态会累积
• 断言失败时，堆栈指向装饰器内部，不是原始测试行号，排查成本陡增
• 无法和 pytest-asyncio 或 pytest-mock 安全组合，容易出现 RuntimeError: Event loop is closed

如果真要手写，建议只在测试函数内部用 for 循环 + try/except，且限定最大尝试次数和明确异常类型：

def test_api_timeout():
    for i in range(3):
        try:
            resp = requests.get("https://api.example.com/health", timeout=2)
            assert resp.status_code == 200
            return
        except (requests.Timeout, requests.ConnectionError):
            if i == 2:
                raise

重试不是万能解药，关键看失败模式

先跑几次 pytest --tb=short -v，盯住失败用例的错误类型和堆栈位置。如果是 AssertionError（断言不成立）、KeyError（数据结构错）、AttributeError（对象没某属性），重试毫无意义——这说明测试本身或被测逻辑有问题。

真正该重试的，只有那些带明显外部依赖特征的异常：

• ConnectionRefusedError
• TimeoutError（非 pytest 自身超时，而是 socket 层）
• WebDriverException（Selenium 找不到元素）
• OperationalError: server closed the connection unexpectedly（PostgreSQL 连接中断）

CI 日志里反复出现同一类网络错误，才值得加重试；如果每次失败原因都不同，说明环境太脏，该修的是 Docker Compose 配置或资源配额，不是加 --reruns 5。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《pytest测试失败自动重试方法详解》文章吧，也可关注golang学习网公众号了解相关技术文章。