不能。pytest-repeat仅支持重复执行测试用例，无并发控制、无性能指标采集、无用户行为模拟，本质是重试工具而非压测框架；其--count和--until-fail适用于排查不稳定用例，如验证修复效果或定位偶发缺陷，但不可用于测量吞吐量或响应时间。
pytest-repeat 能不能直接当压测工具用？
不能。它只是重复执行测试用例，不控制并发、不采集性能指标、不模拟用户行为——本质是“重试工具”，不是压测框架。想靠 pytest --count=100 看响应时间或失败率，结果不可信：单线程串行跑，没负载压力，还可能被 pytest 缓存或 fixture 重置干扰。
怎么用 --count 和 --until-fail 合理排查不稳定用例？
这是它最靠谱的用途：暴露偶发缺陷。比如某个测试偶尔因时序问题失败，你需要确认是不是真 bug，而不是环境噪声。
-
--count=N：固定重复 N 次，适合验证修复效果（如修完后跑 50 次全过） -
--until-fail：一直跑直到失败，适合定位 flaky 用例的触发条件（注意设超时，避免卡死） - 务必加
--tb=short和-v，否则失败堆栈被刷屏淹没 - 禁用缓存：
--cache-clear，否则pytest可能跳过重复执行
示例命令：pytest test_flaky.py --count=30 --until-fail --tb=short -v --cache-clear
为什么不能用 --count 测接口吞吐或响应时间？
因为 pytest-repeat 是在 pytest 的测试生命周期里逐个调用 test_* 函数，每次都会重建 fixture（比如重新连数据库、初始化 mock），实际耗时包含大量 setup/teardown 开销，和真实压测场景完全脱节。
立即学习“Python免费学习笔记（深入）”；
- 测出的“平均耗时”反映的是单次完整测试流程，不是接口本身性能
- 没有并发控制，
--count=100≠ 100 并发请求 - 无法区分是代码慢、网络慢、还是 fixture 初始化慢
- 日志和报告也不支持聚合统计（如 p95、错误分布）
真要压测，该换什么工具？
明确目标再选工具：
- 只想看单请求稳定性 → 用
pytest-repeat+ 日志打点（比如在测试里用time.time()记接口耗时，写到临时文件再分析） - 需要并发请求 + 统计指标 → 直接上
locust或artillery，写 HTTP 场景脚本 - 已有 pytest 用例想复用 → 用
pytest-benchmark测单次调用性能，或把核心逻辑抽成函数，丢给concurrent.futures手动压测
别硬塞 pytest-repeat 到它不负责的环节——它连请求间隔都控制不了，更别说 ramp-up、think time 这些压测基本要素。
