MQ消息在自动化CASE中的应用

1 阅读6分钟

【章节】

一、背景介绍

二、疑难问题处理

三、另辟蹊径

四、效果验证

一、背景介绍

从代码层面来说,订单作为数据流,理论上直接调订单服务的接口就能完成订单状态的变更,实际上涉及实物的订单,线上线下会有联动关系,订单状态的变更依赖实物的流转状态。

从业务层面来说,B2C业务作为公司核心业务之一,订单的服务对B2C流程做了很多针对性处理,日常需求的改动时,如果能够自动化的回归B2C流程的正逆向流程,对于QA来说会起到事半功倍的效果。     

B2C业务流程举例说明,用户在APP下单支付后,订单服务会调用仓储服务的接口,创建出库单,质检仓发货成功后,对外发送MQ消息,订单服务收到MQ消息后,才会修改订单状态为【已发货】状态,用户签收后,订单收到物流签收消息,状态变更为【交易成功】。

示意图:

图片

二、疑难问题处理

在完成梳理B2C业务场景后,找各业务方QA寻求帮助,拿到业务的数据构造接口,按场景类型分工录入接口测试平台,单个场景执行时,一切正常,简直完美。     

集成到一个用例集,并在公司的CICD平台beetle上设置触发场景后,噩梦来了,每次执行不能说肯定失败吧,但也总有场景因为各种原因失败,造成用例集执行结果为【部分通过】,从类型上可以分为以下几种:

1)商品相关        

查询不到可用商品、商品被其他订单支付成功; 

2)服务节点相关        

无可用节点、正在被debug、正在重新部署;

3)环境相关          

中间转发服务线程池太小无可用线程、nginx默认超时时间太短,服务响应时间太长,造成超时; 

4)用例相关问题          

单步执行后,等待时间太短,断言失败、断言条件太严格; 

5)其他问题        

多个出库单被合单、出库单状态不对等;       

前4类问题通过增加锁、调用服务前增加状态校验、找架构和运维协助处理等都一一解决,这里不再花篇幅赘述。       

着重说一下“钉子户”——出库单问题,出库单为用户支付成功后,此时商品还在仓储站点,仓储站点需要打包>预约物流>复核完成等步骤,完成出库流程。并且如果符合同一收货地址、同一手机号、同一收件人时,还会把多个商品“合单”发货,在找业务QA沟通N次后,发现业务系统就是存在各种各样的出库单流程和规则,不能保证在N秒内一定达到某一状态,但能保证正常情况下一定能达到这个状态。 

每个用例都单独使用一个收货地址,避免“合单”场景下多个订单之间相互干扰;出库单状态不确定的问题,只能使用“力大飞砖”的解决办法——增加单步之后的等待时间,一共16个场景的用例集从最初的900+秒到最后要执行2000+秒。

开始时的900+秒截图:

图片增加耗时后,2000+秒截图:图片       

但从结果上看,并没有起到预期的效果,【部分通过】的次数还是很多,无法在实际环境中应用。

三、另辟蹊径

某一天在排查问题时,发现中台服务没有收到业务方系统发送的MQ消息,造成销售单卡在中间状态了,重发一下MQ消息,就能让流程继续下去。既然实际业务是由MQ消息来驱动销售单的流转,那能不能应用到自动化用例上呢?在找架构部负责MQ消息的同事了解相关信息后,RocketMQ的PullConsumer模式满足诉求。使用demo模拟后,流程可以跑通,因此扩展接口测试平台的能力就提上日程。技术方案流程图如下: 图片       

在用例中添加监听某一topic和tag的MQ监听动作,用例执行时,遇到MQ监听动作会先根据topic和tag拉取一下过去3min内的MQ消息,如果断言通过,则用例继续向下执行。如果断言失败,构建对应的内容放到redis中,包含断言条件、过期时间、当前用例剩余的动作等内容。       

在zzschedule中添加每2min执行一次的定时任务,定时任务模糊匹配拉取以【mqPending__】开头的key,根据value获取到具体的内容信息,再根据topic和tag拉取过去3min的MQ消息,进行后续的处理。         

在自测过程中,发现如果定时任务间隔2min执行,实际拉取消息时,需要拉取的时间更长一点,防止临界情况的出现,所以实际方案为定时任务间隔2min执行,每次拉取3min间隔的消息;PullConsumer是设置起始偏移量来循环拉取数据,自测过程中,发现如果一个topic的消息很少,根据时间获取beginOffset时,会正好命中想要拉取的那一条MQ消息,造成拉取不到实际已经发送成功的MQ消息,需要beginOffset - 1才行;拉取MQ消息:

图片

再次执行挂起的用例:

图片改造后的用例举例:图片

PS:MQ监听动作还可以作为长等待使用,如果一个用例需要等待10min后,再继续执行,可以发送一个延迟10min的MQ消息,再监听该topic和tag的MQ消息,10min后收到符合条件的MQ消息,用例就会继续执行。这种方式避免了Sleep方式对线程的占用。

四、效果验证

用例中增加MQ监听动作,并结合用例并发执行,用例集的执行成功率大幅上升,终于可以向下一阶段迈进了。

图片

作者:申言方

转转研发中心及业界小伙伴们的技术学习交流平台,定期分享一线的实战经验及业界前沿的技术话题。

关注公众号「转转技术」(综合性)、「大转转FE」(专注于FE)、「转转QA」(专注于测试),更多干货实践,欢迎交流分享~