pytest默认不重试失败用例，因重试会掩盖资源竞争、状态残留、时序等真实缺陷；官方主张从测试设计和环境治理提升稳定性，而非依赖重试兜底。
测试用例执行失败不一定是代码问题，很可能是环境抖动或异步依赖未就绪；pytest 默认不重试，得靠插件或自定义逻辑补上这一环。
为什么 pytest 默认不重试失败用例
因为重试会掩盖真实缺陷：比如资源竞争、状态残留、时序 bug，这些在重试后可能“恰好通过”，反而让问题更难定位。官方认为稳定性应从测试设计和环境治理入手，而非靠重试兜底。
但现实是：CI 环境 DNS 不稳、数据库连接偶发超时、第三方 API 限流、Selenium 元素加载延迟——这类非业务逻辑失败，重试确实能提升流水线成功率。
- 重试只适合
IO类、网络请求、浏览器交互等外部依赖强的测试 - 禁止对数据库写入、消息发送、支付回调等有副作用的操作重试
-
pytest-xdist并行运行时，重试可能加剧资源争抢，需配合--maxfail=1控制
用 pytest-rerunfailures 插件最省事
这是目前最成熟、兼容性最好的重试方案，支持 Python 3.7+ 和 pytest 7.x/8.x，安装后无需改测试代码。
立即学习“Python免费学习笔记（深入）”；
安装与启用：
pip install pytest-rerunfailures
运行时加参数即可：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 重试 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。
