做系统上线前的压力测试，最怕什么？机器跑了一半突然断电，或者网络抖动导致测试中断。之前跑了几个小时的数据全没了，只能从头再来。这种情况在实际工作中并不少见，尤其是一些长时间、高并发的稳定性压测场景。
断点续测不是玄学，是刚需
很多开发者以为压力测试工具一旦中断就得重来，其实现在主流工具早就支持“断点续测”功能。简单说，就是测试过程中如果意外中断，重启后能接着上次的位置继续跑，而不是一切归零。这就像看视频时断网，恢复后能从断掉的地方接着播放，不用重新开始。
比如你用 JMeter 做一个持续 8 小时的接口压测，跑到第 6 小时服务器崩溃了。没有断点续测，前面 6 小时白忙；有这个功能，重启后直接从第 6 小时继续，省下大把时间。
如何实现断点续测？以 JMeter 为例
JMeter 本身不直接提供图形化断点续测按钮，但可以通过日志和命令行参数实现。关键在于启用结果日志记录，并在重启时指定从哪个位置读取。
jmeter -n -t testplan.jmx -l result.jtl -j jmeter.log --forceDeleteResultFile其中 -l result.jtl 指定结果文件路径。下次启动时，只要保留这个文件，JMeter 会自动追加新数据。虽然不能精确到“第几千个请求”继续，但结合 CSV 数据文件分段读取，完全可以做到分批执行、逐步完成。
其他工具的做法
Gatling 天生支持这种模式。它的测试运行会生成结构化的时间戳日志，每次运行结束后都能看到详细的请求记录。下次启动时，只需调整脚本中的起始时间或用户数偏移量，就能模拟接续行为。
// 在 Scala 脚本中控制起始阶段
setUp(scn.inject(atOnceUsers(100)).protocols(httpProtocol))
.maxDuration(1.hour)
通过设置 maxDuration 和分段注入策略，可以把一次大压测拆成多次小任务，手动实现“续测”逻辑。
自己写脚本也能搞定
如果你用 Python + Locust，控制起来更灵活。可以把总请求数拆成批次，每次运行记录当前进度到本地文件。
import json
progress_file = 'progress.json'
try:
with open(progress_file, 'r') as f:
progress = json.load(f)
except FileNotFoundError:
progress = {'current_user': 0}
# 下次启动时从上次的位置开始
start_user = progress.get('current_user', 0)
这种方式虽然多写几行代码，但自由度高，适合复杂场景。
别忽略数据一致性
断点续测有个隐藏坑：中间状态可能影响结果。比如前半段已经创建了一批测试订单，后半段再跑一遍，会不会重复下单？所以设计测试逻辑时，要确保每个请求具备幂等性，或者用唯一标识隔离不同批次的数据。
还有就是环境状态。中断期间，被测系统是否发生了变更？数据库有没有被清空？缓存是否失效？这些都会让“续测”失去意义。最好配合自动化部署脚本，保证每次重启环境一致。
配置建议
在做压测配置时，主动考虑中断风险。比如：
- 把大任务拆成多个小批次运行
- 定期保存结果文件到稳定存储
- 使用带时间戳的文件名避免覆盖
- 在 CI/CD 流程中加入重试机制
有些团队干脆把压测安排在凌晨，怕中途被打断。其实只要配置得当，就算白天被人误关了终端，也能快速接上，根本不用挑时间。”