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() 并捕获异常
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
立即学习“Python免费学习笔记（深入）”；
import time
start = time.perf_counter()
runs = 0
errors = []
while time.perf_counter() - start < 5.0:
try:
my_unstable_func()
runs += 1
except Exception as e:
errors.append(e)
print(f"Ran {runs} times, got {len(errors)} errors")如果非要用 pytest-repeat，至少避开这几个坑
仅限临时排查偶发失败，且必须配合其他手段：
- 加上
--failed-first和--maxfail=1，避免重复浪费时间在已知失败上 - 禁用缓存：
--cache-clear，否则某些 fixture 可能被复用，掩盖初始化问题 - 用
--tb=short缩短 traceback，失败时快速定位是哪次出的问题（默认只报最后一次） - 别单独依赖它下结论：一次
--count=50全过 ≠ 稳定，可能只是没撞上 race condition 的窗口
真正压测要问的是“系统在什么并发量下开始超时？错误率何时突破 0.1%？”，pytest-repeat 连第一个问题都回答不了。别让它承担它没被设计去做的事。
