当我们在做接口测试的时候，会遇到这么一种情况，一个接口会一直请求，直到请求返回想要的数据后才会停止请求。
最近我就遇到一个这样的接口，一个异步导出应用的接口，首先发送一个导出应用的接口请求，发送后，服务器开始打包，再次发送一个查询状态的请求，查询状态的请求每3秒钟请求一次，直到返回的请求中返回了打包好的导出应用路径。
这里面就会遇到查询打包状态，每3秒查询一次，直到返回打包路径才会停止。
这种情况就需要用到jmeter里面的循环控制器了。
设计如下：
我使用的是while循环控制器。
首先一个异步导出应用的接口，一个查询状态的接口，然后添加一个while控制器。
在while控制器里面加上一个查询状态的接口进行循环。
从上可以看出来，当查询状态接口返回的'falag':'false'时，说明打包还未完成。当'flag':'true'时data数据里会返回一个压缩包路径。说明已经打包完成。
我们在循环里面就可以用查询状态的接口来做一个判断。
如上，通过外面的查询状态接口，提取data的值。
然后如上，在while控制器中，通过data的值进入循环内部，请求while控制器内部的查询状态接口。
接下来如上，while控制器下的查询状态接口也需要加提取data的值。在while控制器下添加一个用户定义的变量，把查询的data的值赋值给data，这样每次请求后，就相当于data重新赋值了。
当while循环监测到data的值不是0时，就会跳出循环。不然的话，不就进入死循环了嘛！
接下来如上，还得加上一个定时器，应为查询接口是每3秒请求一次。
如上，加上我们的断言就行了。
应为接口分为了两种情况，所以只能用BeanShell断言自己写判断了。
语句也很简单，data==0或者data包含了/description/zip
当打包未完成时，data==0，当打包完成时，应为生成的路径不确定，所以只能用包含关系了。
if('${data}'=='0' || '${data}'.contains('/description/zip'))
{
Failure=false;
FailureMessage='success:断言成功';
}
else
{
Failure=true;
FailureMessage='error:断言失败';
}
文章为作者独立观点，不代表 股票程序化软件自动交易接口观点
股民评论