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

原创申言方转转QA

一、背景介绍

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

从业务层面来说，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监听动作，并结合用例并发执行，用例集的执行成功率大幅上升，终于可以向下一阶段迈进了。

继续滑动看下一个