本文描述了一个关于接口业务场景的压测过程，涉及while控制器实现重复请求直到结果，事务控制器记录总耗时。遇到的问题在于用户定义变量影响了后续循环，通过修改为BeanShell预处理程序解决了这个问题。最后，文章强调了输出报告中使用事务控制器的重要性以获取准确的业务流程统计。
我是小白，我很菜
这次压测的接口有个业务：获取局部区域的用户详单，先调用创建任务接口创建任务返回任务ID，后台创建任务后开始计算，再调用获取详情接口发送任务ID请求，若任务未有结果则返回计算中，任务完成计算后，返回详单数据
这种业务场景使用while控制器和事务控制器
while控制器用于实现获取到结果就跳出循环的重复请求
事务控制器用来统计任务创建开始到获取到结果为止的总体时间（后台真正的计算时间）
1、实现第一个接口调用，这个很简单，添加Json提取器，提取每次接口返回的taskId
2、实现第二个接口的调用，主要是获取1的taskId并实现循环请求
（1）获取上个接口的任务ID，上一步json提取器已经实现了taskId的参数化，下面${taskId}就能拿到
（2）实现第二个接口的重复请求就要while控制器了，并设置终止条件，将第二个接口放在while控制器下，提取接口的code的值
这里判断条件为第二个接口的code==0退出，code != 0执行while里的循环
添加用户定义的变量（此处大错特错，后面说）
（3）到这里执行测试计划，设置3个线程，循环1次，（创建3个任务，获取3次详情）成功！
再改变循环为2次，理论应该有6次sample（创建6个任务，获取6次详情），结果每次线程组只有第一次执行了while，后面的循环没有执行，只创建了任务没有获取详情（创建了6个任务，获取了3次详情？？？）
查阅发现，第二个接口的json提取器获取到第一个返回值后（code==0），就一直被UDV保存了code=0，变量影响了后面的循环，因为变量的作用域是线程组，所以无论该线程无论循环多少次都不会执行while了
笔记：
如果用户参数、预处理器或正则表达式提取器定义了与 UDV 变量之一同名的变量，则 JMeter 将替换 UDV 下定义的初始值，线程中的所有其他测试元素将看到更新后的值。
如果有多个线程组，建议为不同的值使用不同的名称，因为 UDV 在线程组之间共享。
如果有多个线程组，则可以在测试计划下定义引用变量并使其全局化。因为变量在元素被处理一次之后才可用。
去掉用户定义的变量，改为BeanShell 预处理程序，给个默认值code为1，放在while控制器之前
跑起来了，每个线程的每一次循环都会执行while了
3、实现输出报告的统计
每次重复请求时，设置一个固定定时器，因为我的接口每次去查询都会将日志写入数据库，为了防止太过频繁导致数据库那边先瓶颈了，需要等待一下
程序从创建任务后到获取任务结果才是真正的计算时间，输出报告时每个接口都有自己的统计数据，不能表现业务流程的统计，那就用到事务控制器了，把接口一、二都添加到事务控制器里，勾选上这两个，非GUI执行就能输出体面的测试报告啦！！
扫一扫
870
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
