首先,此文非技术类博文,为思路类的博文,敬请参阅,欢迎共同探讨!
今天在编写 JMeter 接口监控脚本时,遇到了一个问题,在解决问题的时候,思路出现了偏差,导致了自己在解决问题时,绕了弯,浪费了些时间。换句话说,是自己当时解决问题的思路出现了定式思维,没有及时变通,矬了 ^_^。具体的问题场景如下。
日常测试开发工作中,测试脚本对应的场景有很多,其中必不可少的场景就是重要的状态码验证。此时,不同的状态码对应着不同的页面显示,以及后续不同的业务逻辑处理操作,因而测试脚本需要对不同请求对应的请求响应中不同的状态码进行判断,以判断经过之前的操作后状态码的变更是否正确,若正确则可继续执行后续相关的验证操作,否则终止后续相关联的操作,进而发送通知给产品组的相关成员,以及时进行处理。那么如何获取、判断状态码正确与否呢?下面以电商网站中订单状态码为例,进行简单描述我当时解决此问题的思路,步骤如下:
第一种:通过断言直接判断验证码
操作方法:获取订单列表,直接设置响应断言。
此种判断方式,非常的简单,只需在请求响应中设置断言即可。但此判断方法有一个极大的限制条件(订单列表中返回的所有订单状态不允许有相同的状态),否则此种判断方式无法确定要判断订单状态是否正确(若要判定订单的状态不是期望状态,而其他订单的状态却存在了期望状态,则此判断方式错误)。
第二种:订单列表中获取订单状态后通过逻辑控制器等进行判断
操作方法:获取订单列表,通过 正则表达式提取器 获取对应订单的订单状态(通过正则提取器获取状态方法,敬请参阅之前的博文:单参获取、多参获取,多参引用),然后通过 Bean Shell Assertion、BSF Assertion 等方式对订单的状态进行判断,验证是否符合预期,从而通过逻辑控制器控制是否执行后续操作。
此种判断方式稍显复杂,且需要一定的脚本基础,建议各位朋友研究一下,提升一下自己的脚本能力。
第三种:订单列表中获取订单状态后通过断言进行判断
操作方法:通过正则提取器获取订单信息,例如从订单编号开始获取到订单状态之前的字符,然后拼接期望状态后,将拼接的字符串设置为断言即可。例如订单数据信息如下所示:
1
|
{"errno":0,"data":{"single_coupon":"","cash_per_month":0,"order_id":"34567890","order_char_id":"1234567890","status":-2,"receiver_tel":"","receiver_addr":"华夏","receiver_mobile":"1234567890","shipping_cost":0,"shop_guide_cost":"0","businessId":2,"dealType":2,"buy_total":3,"order_cost":14700,"coupon_code":"","coupon_amt":0,"pOrderId":"0101234567890","subOrderNum":0,"subOrderIds":[]}}
|
那么正则提取器对应的正则表达式为:
order_id":"${order_id}","order_char_id":"12${order_id}","status":
|
正则提取器对应的模板为: 0 0
最终获取的订单信息为:order_id":"34567890","order_char_id":"1234567890","status":
断言的信息为(假定此时订单状态为:4):order_id":"34567890","order_char_id":"1234567890","status":4
此种方法与第二种的方法类似,不同之处在于提取域(第二种提取的是单独的一个订单状态,此处取的是订单信息)、判断方式(第二种是通过其他方式进行判断,此处直接使用断言),此种较为简单,推荐。
第四种:通过订单详情数据判断
操作方法:请求对应订单的订单详情,直接设置响应断言(例如:"status":4)进行判断。
此种判断方式,同样简洁,同样只需在请求响应中设置断言即可,而且保证了订单的唯一性,不存在其他订单干扰的情况发生,建议采取此种方式。
PS:解决问题的过程中,也尝试过其他的验证方式,在此不再一一赘述,以上是我自己想到的比较有效的方法,藉此分享给大家。若是有更好的方法,欢迎告知,不胜感激!
至此, JMeter学习-016-思路篇之-山重水复柳暗花明 顺利完结,希望此文能够给初学 JMeter 的您一份参考。
最后,非常感谢亲的驻足,希望此文能对亲有所帮助。热烈欢迎亲一起探讨,共同进步。非常感谢! ^_^
PS:若有错误,敬请告知,不胜感激!
Copyright @范丰平 版权所有,如需转载请标明本文原始链接出处,严禁商业用途! 我的个人博客链接地址:http://www.cnblogs.com/fengpingfan