pytest-rerunfailures能在测试失败时自动重跑指定次数，但仅对执行阶段失败（如assert失败、未捕获异常）生效，setup/teardown错误、skip、强制退出等不触发重试；安装后通过--reruns N启用，支持--reruns-delay和@pytest.mark.flaky细粒度控制。
直接说结论：pytest-rerunfailures 能在测试失败时自动重跑指定次数，但仅对「执行阶段失败」有效，捕获异常后主动 assert False 或 raise 也算；而 setup_method、teardown 报错或跳过（skip）不触发重试。
安装与基础启用方式
先确认已安装 pytest：如果没装，运行 pip install pytest；再装插件：pip install pytest-rerunfailures。它不依赖额外配置就能用，只要加命令行参数就行。
最常用启动方式是：
pytest --reruns 3
表示每个失败的测试最多重试 3 次（含首次运行，实际最多执行 4 次）。也可以写成 --reruns 3 --reruns-delay 1，让每次重试前等 1 秒，避免瞬时资源争抢。
立即学习“Python免费学习笔记（深入）”；
-
--reruns必填，整数，设为 0 则禁用重试 -
--reruns-delay可选，单位秒，支持小数（如0.5） - 不加参数直接运行
pytest --reruns会报错，必须带数字
@pytest.mark.flaky 的细粒度控制
全局重试太粗放？可以用装饰器单独标记某些不稳定测试，比如第三方 API 调用或 UI 自动化场景。
示例：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
import pytest
@pytest.mark.flaky(reruns=2, reruns_delay=1)
def test_external_api_call():
assert requests.get("https://httpbin.org/delay/2").status_code == 200
注意点：
- 装饰器优先级高于命令行参数，
@pytest.mark.flaky(reruns=1)会覆盖--reruns 3 -
reruns_delay在装饰器里也支持小数 - 若函数本身有
@pytest.mark.parametrize，每个参数组合独立计数重试次数
哪些失败不会被重试？常见误判点
很多人以为「测试没过就重试」，其实插件只响应特定类型的失败信号。以下情况 完全不触发重试：
- 测试被
pytest.skip()或@pytest.mark.skip跳过 -
setup_method、teardown_class等 fixture 执行出错（属于「收集/准备阶段失败」） - 测试函数内用
sys.exit(1)或os._exit()强制退出 - 超时（
--timeout插件中断）或内存溢出等非 Python 异常终止
另外，重试时 self 不复用——每次都是全新实例，所以别在 setup_method 里存状态指望重试能接着用。
CI 环境中要特别注意日志和报告
在 Jenkins/GitLab CI 里跑带重试的测试，原始失败日志默认会被覆盖。想保留每次尝试的 traceback，得加参数：
pytest --reruns 2 --reruns-report rerun_report.json
生成的 rerun_report.json 包含每次运行的 exit code、耗时、错误信息。配合 --junitxml=report.xml 使用时，JUnit 报告里会把重试记录为多个 <testcase></testcase>，但 name 后自动加 [1]、[2] 后缀，CI 工具可能误判为重复用例。
建议做法：
- 本地调试用
--reruns 1 --verbose看实时输出 - CI 中固定用
--reruns 2 --reruns-report，后续用脚本解析 JSON 做归因 - 避免和
pytest-xdist并发运行时加--dist=loadgroup，否则重试可能分配到不同 worker 导致环境不一致
真正麻烦的是网络抖动类失败——重试能压低失败率，但掩盖了环境问题。上线前最好单独跑一次无重试的全量回归，确认不是假阳性。
