4. 测试脚本设计:请求模型设计、参数化策略、思考时间设置、断言与检查点
脚本设计这章,我把它看作是性能测试的「施工图纸」。图纸画不好,后面跑出来的数据全是废的。咱们直接切入正题,把这四个核心模块拆开揉碎了讲。
4.1 请求模型设计:别让脚本变成「死脚本」
很多人写脚本就是录个回放,完事。这其实是个大坑。我见过太多团队,脚本跑得飞快,但压测结果跟线上表现完全对不上。为什么?因为请求模型没设计好。
请求模型的核心,是模拟真实用户的行为路径。不是简单的「发一个请求」,而是「用户怎么发起这个请求」。
关键原则:请求模型要覆盖「正常路径」和「异常路径」。正常路径验证功能,异常路径验证容错。
我个人习惯把请求模型分成三类:
- 线性模型:用户按固定顺序操作,比如登录→搜索→下单→支付。适合业务流程固定的场景。
- 分支模型:用户有多个选择路径,比如有的用户直接搜索,有的用户逛首页。适合电商、内容平台。
- 随机模型:完全模拟真实用户的随机行为,权重按业务比例分配。适合复杂系统。
举个例子,我之前做一个电商压测项目,脚本里只写了「首页→商品详情→下单」这条线。结果上线后,大量用户是从「搜索」进来的,导致搜索服务直接被打爆。嗯,从那以后,我每次设计请求模型都会先拉一份线上用户行为日志,看看真实分布。
4.2 参数化策略:别让所有用户用同一个身份证
参数化,说白了就是让每个虚拟用户用不同的数据。你想想看,如果1000个用户都用同一个账号登录,那测出来的结果能信吗?
参数化策略我一般分三步走:
- 数据源准备:从生产环境脱敏抽取,或者造一批符合业务规则的数据。
- 参数绑定:把脚本里的硬编码值替换成变量。
- 分配策略:决定每个用户怎么拿数据。
这里有个坑,我踩过好几次——数据唯一性。比如注册接口,如果两个用户用了同一个手机号,第二个请求必然失败。所以参数化时,一定要保证数据不重复,或者接口本身做了幂等处理。
我的经验:参数化数据量至少是并发用户数的3倍以上。比如你压1000并发,至少准备3000条数据。否则跑着跑着数据用完了,脚本就开始报错,结果全乱套。
常用的参数化策略对比:
| 策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 顺序分配 | 数据有顺序要求 | 简单可控 | 数据用完就报错 |
| 随机分配 | 无状态接口 | 模拟真实分布 | 可能有重复 |
| 唯一分配 | 注册、下单等 | 保证数据不冲突 | 数据量要求大 |
| 组合分配 | 多参数关联 | 灵活度高 | 配置复杂 |
4.3 思考时间设置:别让脚本跑得像「机关枪」
思考时间,就是用户操作之间的停顿。比如你看完一篇文章,思考几秒再点下一页。这个时间如果设成0,那你的压测就是在「打机关枪」,而不是模拟真实用户。
我记得有一次,一个团队压测结果特别好看,TPS高得离谱。结果上线后,实际吞吐量只有压测的一半。后来一查,他们脚本里思考时间设成了0,所有请求像洪水一样涌出去,服务器根本扛不住真实用户的「慢速请求」。
思考时间怎么设?我一般用两种方式:
- 固定思考时间:比如每个操作之间停顿2秒。适合简单场景。
- 随机思考时间:比如1-5秒之间随机。更接近真实用户行为。
注意:思考时间不是越长越好。太长的思考时间会拉低TPS,导致你测不出系统的真实上限。我一般建议从业务日志里统计用户操作间隔,取P50或P90值作为参考。
举个例子,一个搜索页面,用户平均停留3秒才点下一页。那思考时间就设成3秒左右,上下浮动1秒。这样压出来的结果,才跟线上表现对得上。
4.4 断言与检查点:别让「假成功」骗了你
断言和检查点,是脚本的「质检员」。没有它们,你看到的成功可能全是假象。
我见过最离谱的事:一个压测跑了8小时,所有请求都返回200,但业务方说数据全没写进去。后来一查,接口返回了200,但body里是个错误码「-1: 系统繁忙」。嗯,这就是典型的「假成功」。
断言的核心逻辑:
- HTTP状态码断言:检查返回码是不是200、201等。这是最基础的。
- 响应体断言:检查返回的JSON或XML里有没有关键字段。比如「success: true」。
- 响应时间断言:检查请求耗时是否超过阈值。比如超过5秒就算失败。
我个人习惯在每个关键业务节点都加断言。比如登录成功后,检查返回的token字段是否存在;下单成功后,检查订单号是否生成。
避坑指南:我曾经在一个项目中,只做了状态码断言,结果压测报告显示成功率99.9%。但业务方反馈,大量订单的金额是0元。后来发现,接口返回了200,但金额字段被截断了。从那以后,我所有涉及金额、数量的接口,都会加一个「数值范围断言」。
检查点的设置原则:
- 关键路径必加:登录、支付、下单等核心操作。
- 边界值必加:比如金额为0、数量为负数等异常情况。
- 性能阈值必加:响应时间、错误率等。
4.5 本章知识体系
下面这张图,把脚本设计的四个核心模块串起来了。你可以把它当作一个检查清单,每次写脚本前过一遍。
这张图把四个模块的关系理清楚了。每个模块都有对应的子实践,比如请求模型要参考用户行为日志,参数化要做好数据脱敏。你写脚本时,对着这张图过一遍,基本不会漏东西。
4.6 实战中的常见问题
最后,我总结几个实战中经常遇到的问题,你写脚本时多留个心眼:
- 关联参数没处理好:比如登录后拿到的token,没传到后续请求里。结果所有请求都返回401。
- 数据污染:多个脚本共用同一份参数化数据,导致数据冲突。我建议每个脚本独立一份数据文件。
- 思考时间设成固定值:所有用户都在同一秒发请求,形成「脉冲式」流量。用随机分布会好很多。
- 断言太宽松:只检查状态码,不检查业务逻辑。结果压测报告全是「假成功」。
一个小技巧:写脚本时,先跑一遍单用户调试模式,把每个请求的返回都打印出来,肉眼过一遍。确认断言都通过了,再上并发。这一步能省掉后面80%的排查时间。