4. 压测脚本设计：参数化、关联、断言、思考时间、集合点等核心脚本要素

脚本设计，说白了就是压测的「灵魂」。工具选得再好，脚本写成一坨，结果也是白搭。我见过太多团队，LoadRunner 或 JMeter 用得贼溜，但脚本里全是硬编码，跑一次改一次，累得半死。

今天咱们就把脚本设计的几个核心要素掰开揉碎。参数化、关联、断言、思考时间、集合点——这五个东西，你吃透了，压测脚本这块基本就稳了。

4.1 参数化：别让数据成为瓶颈

先问个问题：你压测登录接口，1000 个虚拟用户都用同一个账号登录，结果会怎样？

嗯，大概率是服务器没挂，账号先被踢下线了。更别说有些系统会缓存用户信息，你测出来的根本不是真实性能。

参数化，就是让每个虚拟用户使用不同的数据。我个人的习惯是，能用 CSV 文件就别用函数生成，因为真实业务场景的数据分布往往更接近实际文件中的数据。

4.1.1 常见的参数化方式

方式	适用场景	我踩过的坑
CSV 数据文件	用户信息、订单号等真实数据	文件编码问题导致乱码，后来统一用 UTF-8 无 BOM
数据库查询	需要动态获取最新数据	查询太频繁把数据库打挂了，记得加缓存
函数生成	随机字符串、时间戳等	随机数重复率太高，UUID 更靠谱
计数器	需要唯一递增的 ID	并发时计数器冲突，加锁或使用原子操作

我曾经在一个金融项目里，用 CSV 参数化了 10 万条用户数据。结果跑压测时发现，数据读取成了瓶颈——磁盘 IO 扛不住了。后来改成预加载到内存，问题才解决。你想想看，脚本设计时连数据读取效率都得考虑进去。

4.1.2 参数化策略选择

参数化不只是「换个数据」那么简单。数据怎么分给虚拟用户，也是个讲究活。

• 顺序分配： 每个 VU 按顺序拿数据，适合测试数据不重复的场景
• 随机分配： 每个 VU 随机拿数据，模拟真实用户行为
• 唯一分配： 每个 VU 拿到的数据全局唯一，适合订单号、交易流水

我个人建议，压测登录场景用「唯一分配」，压测查询场景用「随机分配」。为什么？登录场景数据重复会导致冲突，查询场景随机更贴近真实用户行为。

4.2 关联：让脚本学会「接话」

关联，说白了就是让脚本能「接住」服务器返回的动态数据，再用到后面的请求里。

举个栗子：你登录后，服务器返回一个 session ID。后面的每个请求都得带上这个 ID，不然服务器不认识你。如果你在脚本里硬编码这个 ID，那跑一次就失效了。

4.2.1 关联的两种主流方式

在 JMeter 里，关联通常用「正则表达式提取器」或「JSON 提取器」。LoadRunner 里则是用 web_reg_save_param 函数。

// JMeter 正则提取器示例
// 从响应中提取 token
// 正则表达式： "token":"([^"]+)"
// 模板： $1$
// 匹配数字： 1

嗯，这里要注意一点：正则表达式写得太宽泛，会匹配到不该匹配的东西；写得太严格，又可能匹配不到。我一般会先用调试工具验证正则，再放到脚本里。

4.2.2 关联的边界处理

关联还有个坑：如果服务器返回的数据格式变了，你的提取器可能就废了。比如原来返回 JSON，后来改成 XML，你的 JSON 提取器直接罢工。

我建议你养成一个习惯：关联时加个默认值。如果提取失败，用默认值兜底，至少脚本不会直接报错。然后通过断言来发现提取失败的问题。

4.3 断言：让脚本学会「判断对错」

压测脚本跑完了，结果全是绿色的成功？别高兴太早。服务器可能返回了 200，但页面里显示的是「系统繁忙，请稍后重试」。

断言，就是让脚本能判断「这次请求到底对不对」。没有断言的压测，就像闭着眼睛开车——你以为在直行，其实已经偏到沟里了。

4.3.1 常用的断言类型

断言类型	检查内容	使用场景
响应状态码	HTTP 200/404/500	基础检查，所有请求都该加
响应文本	包含/不包含特定字符串	检查关键业务字段
JSON 断言	JSON 字段的值	接口返回 JSON 时最常用
响应时间	请求耗时是否超阈值	性能达标检查

我个人习惯，每个请求至少加两个断言：一个状态码断言，一个业务断言。状态码保证网络层面没问题，业务断言保证逻辑层面也没问题。

4.3.2 断言失败的后果

断言失败时，脚本该怎么处理？是直接报错停止，还是记录下来继续跑？

我的建议是：压测过程中不要停止。把断言失败记录下来，等压测结束后统一分析。为什么？因为压测的目的是发现系统的瓶颈，而不是让脚本完美运行。如果因为几个断言失败就停了，你可能会错过更严重的问题。

4.4 思考时间：模拟真实用户的「犹豫」

真实用户不会像机器一样「哒哒哒」地连续点击。他们会看看页面，想想下一步，喝口水，接个电话。这些停顿，就是思考时间。

没有思考时间的压测，相当于让 1000 个用户同时疯狂点击——这根本不是真实场景。你测出来的 TPS 会虚高，但服务器可能早就扛不住了。

4.4.1 思考时间的设置策略

• 固定思考时间： 每个请求之间停顿固定时长，简单但不够真实
• 随机思考时间： 在范围内随机停顿，更贴近真实用户行为
• 基于业务的思考时间： 复杂操作停顿长，简单操作停顿短

我建议你，如果拿不准思考时间设多少，可以先设一个范围（比如 1-3 秒），然后观察压测结果。如果 TPS 太低，说明思考时间偏长了；如果服务器错误率飙升，说明思考时间偏短了。

4.5 集合点：模拟「万人抢购」的瞬间

集合点，说白了就是让所有虚拟用户「等一等，一起上」。它模拟的是高并发瞬间的场景，比如秒杀、抢票、抢红包。

我记得有一次帮一个电商平台做压测，他们上线了秒杀功能。我用了集合点，让 500 个用户在同一秒发起请求。结果服务器直接 502 了——原来他们的连接池只配了 200 个。

4.5.1 集合点的使用场景

• 秒杀/抢购： 大量用户在同一时刻发起请求
• 登录风暴： 大量用户同时登录，测试认证系统的并发能力
• 定时任务触发： 模拟定时任务同时执行时的压力

4.5.2 集合点的配置要点

在 JMeter 里，集合点用「同步定时器」实现。配置时有两个关键参数：

• 超时时间： 等多久？如果一直等不到足够多的用户，超时后先到的用户先释放
• 等待用户数： 等多少个用户到齐了再一起释放？一般设为虚拟用户总数

4.6 知识体系总览

说了这么多，咱们用一张图把脚本设计的核心要素串起来。这张图是我自己总结的，每次设计脚本前都会过一遍。

这张图我每次培训都会用。你看，脚本设计不是孤立的技术点，而是一个完整的体系。参数化解决数据问题，关联解决动态交互问题，断言解决验证问题，思考时间解决真实性问题，集合点解决并发问题。五个要素配合好了，脚本才能真实反映系统的性能。

好了，脚本设计的核心要素就聊到这儿。记住一句话：好的压测脚本，不是跑得快的脚本，而是跑得准的脚本。

想要更多资料，联系可可