【章节】
一、背景介绍
二、疑难问题处理
三、另辟蹊径
四、效果验证
从代码层面来说，订单作为数据流，理论上直接调订单服务的接口就能完成订单状态的变更，实际上涉及实物的订单，线上线下会有联动关系，订单状态的变更依赖实物的流转状态。
从业务层面来说，B2C业务作为公司核心业务之一，订单的服务对B2C流程做了很多针对性处理，日常需求的改动时，如果能够自动化的回归B2C流程的正逆向流程，对于QA来说会起到事半功倍的效果。
B2C业务流程举例说明，用户在APP下单支付后，订单服务会调用仓储服务的接口，创建出库单，质检仓发货成功后，对外发送MQ消息，订单服务收到MQ消息后，才会修改订单状态为【已发货】状态，用户签收后，订单收到物流签收消息，状态变更为【交易成功】。
示意图：
在完成梳理B2C业务场景后，找各业务方QA寻求帮助，拿到业务的数据构造接口，按场景类型分工录入接口测试平台，单个场景执行时，一切正常，简直完美。
集成到一个用例集，并在公司的CICD平台beetle上设置触发场景后，噩梦来了，每次执行不能说肯定失败吧，但也总有场景因为各种原因失败，造成用例集执行结果为【部分通过】，从类型上可以分为以下几种：
1）商品相关
查询不到可用商品、商品被其他订单支付成功；
2）服务节点相关
无可用节点、正在被debug、正在重新部署；
3）环境相关
中间转发服务线程池太小无可用线程、nginx默认超时时间太短，服务响应时间太长，造成超时；