pytest-repeat 不适合压测,因其仅串行重复执行测试,无并发控制、无性能指标统计(如耗时分布、吞吐量、错误率),无法模拟真实高负载场景,易误判问题根源。

pytest-repeat 不能用来压测,它只做重复执行,不控制并发、不统计性能指标,拿它压测会误判问题根源。
为什么 pytest-repeat 不适合压测
它本质是测试重试工具,设计目标是排查偶发失败(比如网络抖动、资源竞争),不是模拟高负载。它按串行方式反复跑同一个 test 函数,没有并发控制,也不记录耗时分布、吞吐量或错误率——这些才是压测的关键维度。
- 用
--count=100跑 100 次,实际是单线程顺序执行,和“100 个用户同时请求”完全不是一回事 - 失败时默认不中断,容易掩盖真实稳定性边界(比如第 99 次才爆内存泄漏,但你只看到“1 次失败”)
- 无 request-level 日志、无响应时间直方图、不支持阶梯加压,没法定位瓶颈点
真正该用什么替代 pytest-repeat 做压测
根据场景选工具,别硬套:
- 想验证接口在并发下的稳定性 → 用
locust或artillery,写简单脚本定义用户行为和并发数 - 想复现某个测试里资源竞争导致的崩溃 → 先用
pytest-xdist的-n 4并行跑多次,再结合pytest-repeat在每个 worker 内部加--count=5 - 只想快速看某函数在高频调用下是否出错/变慢 → 直接写个裸循环 +
time.perf_counter(),比套 pytest 更透明
示例:不用任何插件,5 秒内尽可能多跑 my_unstable_func() 并捕获异常
import time start = time.perf_counter() runs = 0 errors = [] while time.perf_counter() - start <h3>如果非要用 <code>pytest-repeat</code>,至少避开这几个坑</h3><p>仅限临时排查偶发失败,且必须配合其他手段:</p>
- 加上
--failed-first和--maxfail=1,避免重复浪费时间在已知失败上 - 禁用缓存:
--cache-clear,否则某些 fixture 可能被复用,掩盖初始化问题 - 用
--tb=short缩短 traceback,失败时快速定位是哪次出的问题(默认只报最后一次) - 别单独依赖它下结论:一次
--count=50全过 ≠ 稳定,可能只是没撞上 race condition 的窗口
真正压测要问的是“系统在什么并发量下开始超时?错误率何时突破 0.1%?”,pytest-repeat 连第一个问题都回答不了。别让它承担它没被设计去做的事。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!











