（十二）jmeter接口自动化难点系列---重复请求接口，直到返回正确的数据

当我们在做接口测试的时候，会遇到这么一种情况，一个接口会一直请求，直到请求返回想要的数据后才会停止请求。

最近我就遇到一个这样的接口，一个异步导出应用的接口，首先发送一个导出应用的接口请求，发送后，服务器开始打包，再次发送一个查询状态的请求，查询状态的请求每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:断言失败";
}