网络测试不稳定？重试机制来兜底
做接口自动化测试时，经常会遇到一种让人头疼的情况：明明逻辑没问题，但某次运行突然报错。翻日志一看，是某个请求超时或者服务短暂不可用。这种情况在网络环境复杂、依赖第三方接口多的项目里尤其常见。
比如我们之前做过一个电商系统的压测任务，高峰期调用支付网关的接口偶尔会失败。一开始以为是代码问题，反复排查后发现，其实是对方服务在高负载下响应变慢，导致我们的测试用例直接判定为失败。后来引入了失败重试机制，同样的用例通过自动重试3次后再标记结果，通过率立马从82%提升到了99.6%。
重试不是简单地“再跑一遍”
很多人觉得重试就是把失败的用例再执行一次，其实没那么简单。盲目的重试可能带来副作用，比如重复下单、数据污染。关键是要判断哪些场景适合重试。
一般来说，网络抖动、HTTP 5xx错误、连接超时这类非业务性失败才考虑重试。而像400参数错误、断言失败这种属于逻辑问题，重试也没用，反而浪费资源。
Python + pytest 实现重试示例
我们在一个基于 pytest 的测试框架中集成了 pytest-rerunfailures 插件，配置起来非常轻量。
pip install pytest-rerunfailures然后在执行命令中加入重试参数：
pytest test_api.py --reruns 3 --reruns-delay 2上面的命令表示：失败用例最多重试3次，每次间隔2秒。也可以在用例上加装饰器精细化控制：
@pytest.mark.flaky(reruns=2, reruns_delay=1)
def test_network_request():
response = requests.get("https://api.example.com/status", timeout=5)
assert response.status_code == 200自定义重试逻辑更灵活
有些场景需要更复杂的判断，比如只对特定异常重试。这时候可以用 tenacity 库实现函数级重试。
from tenacity import retry, stop_after_attempt, wait_fixed, retry_if_exception_type
import requests
@retry(
retry=retry_if_exception_type((requests.ConnectionError, requests.Timeout)),
stop=stop_after_attempt(3),
wait=wait_fixed(2)
)
def call_remote_api():
return requests.get("https://slow-service.com/data", timeout=3)这样只有出现连接错误或超时时才会触发重试，其他异常直接抛出，避免误判。
结合报告看清重试价值
我们在Allure报告里看到，很多用例第一次运行失败，但在重试后恢复正常。这些信息帮助我们区分了“真失败”和“假失败”，也让开发更关注服务稳定性而非单纯修复用例。
重试机制不是掩盖问题，而是让测试结果更真实反映系统健壮性。特别是在CI/CD流水线中，合理的重试能减少误报，提升交付效率。