某项目的 jmeter 性能压测 挖雷 探秘

2025年11月26日 在对某知名智造业大公司 旗下的一个大型营销系统 - 结算子系统 进行性能压测时 遇到的问题 做一个 挖雷的经验教训总结。

挖雷1：jmeter自定义变量的锅

出现了这样一个问题：

1、我拿jmeter在本地调试的时候，接口请求成功，系统页面 和 数据库中都查到了 传入的 测试数据

2、我拿jmeter脚本放入 压测负载机 进行多线程循环测试时，结果 页面和 数据库中都没查到 应有的 数据，页面数据条数都没有增加。这说明接口请求成功，但是数据并没有插入数据库。

问题定位：

一开始还是很纳闷，为啥我本地调试OK，放入测试环境平台上的 压测场景中 就失效了呢，

第一反应想到的 就是 请求参数的校验，沿着这个思路，在本地jmeter中 循环请求了2次，对比 2次请求的post参数

发现了罪魁祸首，一个叫 upstreamBillNo 字段的值 在循环多次的情况下，都是不变的，

但是 这个upstreamBillNo 我是做了自定义变量的 随机数赋值的。

这时 我把 upstreamBillNo的入参变量的 位置分别放入了 线程组下全局、请求接口前置，发现jmeter的自定义变量 都还是只取值了1次，一直沿用第一次线程请求的数值。

因此基本就确定了  一个事实： jmeter中的自定义变量 设置的 动态数值，在一次赋值后 就形成一个 固定常量了。

后面直接就把  动态数据 放入  post请求的 变量值中赋值，这样就动态变化了。 

这时再请求，数据库和 页面上就能查到  60的并发 TPS 为 155.73，插入数据库中的数据为 47113条记录， 事务响应平均时间 才381.54毫秒，错误率0%。

已经远超 目标值：平均响应时间<=3秒  TPS>=50   错误率<=0.1% 

 

挖雷2：压测结果错误率1%的问题

在10并发、20并发、30并发的过程中，3次连续 错误率为1%，这就让人有点纳闷了，正常情况下不会出现 如此规律一致的错误率

随后在排查脚本的过程中，猛然发现 CSV文件中的其中一条数据行的末尾 把首行中的一个头字段名加入到了其中一行的尾部，导致这一行的数据错误

刚好是100条测试数据，其中1条测试数据传参错误，导致了刚好1%的错误率，纠正这条数据，错误率变成了0%。

这里有人会有疑问，你这100条测试数据够用吗？其实对于这些数据 只要 ID不同，就可以循环利用使用，哪怕1条测试数据 都是没问题的！

 

挖雷3： CSV变量名顺序位置 不小心弄错的问题

在检查 POST请求参数时，发现请求的参数值 不对，然后发现传成其他参数的值了，对于某些特殊字段存在校验的情况下，这时就会出现校验失败的情况。

这时大家不仅要检查CSV文件里面的首行变量名 与 变量值的 对应关系，还要去CSV 数据文件设置 的变量名 这行检查 变量名的 顺序是否正确。

 

本次的经验教训是：

1、在调试脚本过程中要检查 CSV、变量赋值的 数据正确性，以及变量名的顺序

2、调试脚本的时候 不仅要请求一次，还要请求至少2次，对比下 请求POST参数 的差异，对于 动态变化的字段值要检查是否存在一致的地方

如果出现 2次请求，某个字段值一致，一定是传参的变量赋值 存在问题。

3、利用CSV传参的时候，一定要检查 每个传参的 数据 与 变量位置是否正确。

 

本次利用 阶梯式 压测的方式 精准得定位了 系统在 负载测试方法下，TPS  的拐点，找到最大TPS。评估出 本次接口的性能非常良好，远超当前的预期值。

由于保密问题，更多内容细节不便于分享，在此表示抱歉！~