持续演进的接口自动化测试方案
点击关注“有赞coder”
获取更多技术干货哦～
部门：美业测试
接口自动化测试是个老生常谈的话题，基本上每个测试团队都会涉及，市面上大部分文章会从如何设计框架去讲解。但是这一次我想回归自动化的根本价值，从持续演进的解决方案出发，讲解有赞测试团队的心路历程和对于接口自动化的理解，欢迎交流。
一、价值
有赞测试团队肩负的一个使命是：打造高效且可靠的产品交付能力。为了完成这个使命，我们会借助各种工具，而接口自动化就是其中的一把利器。
如何让接口自动化的价值最大化，首先需要想清楚如何去评估接口自动化的质量，有赞测试团队是这样思考的：
最大化提升回归测试的效率
消灭更多的测试盲点
接下来介绍的持续演进的方案都是基于这两个方向去努力的
为了让大家更好地理解我们的演进思路，我先简单介绍一下我们业务的服务器架构，接口自动化的测试目标。
客户端：渠道较多，分Web、H5、小程序、APP、Pad，通过youzan.com域名请求，统一接入到公司网关层Nginx集群，反向代理转发到对应业务的Web服务器。
Web服务器：这一层是Nodejs实现，涉及逻辑主要是路由转发、登陆态校验。
后端服务器：电商系通用的Java微服务架构，API1和API2是接入层，涉及逻辑主要是请求转发和非业务相关的通用处理。Service1这一层才是真正的业务逻辑层，大概有30多个微服务应用，互相之间使用dubbo协议通信。
所以，接口自动化面临2种选型：
模拟客户端进行HTTP请求，优势是能快速覆盖用户场景，劣势是需要构建大量的数据，后期维护成本高。
基于dubbo协议进行请求，优势是能Mock依赖数据，劣势是前期脚本编写成本高，且不支持预发执行。
该如何选择呢？小朋友才做选择题，成年人我们都要了，两者互相结合，扬长避短。
三、如何提升回归测试效率
这里需要从三个阶段来看：回归测试前、回归测试中、回归测试后。
回归测试前，我们通过2个事情来提升效率：
1、精准定位自动化测试覆盖范围
最原始的范围依据是根据功能测试用例来，但这不是客观合理的，我们从对外暴露的接口数和后端Service层应用的代码覆盖率去评估。
我们基于JaCoCo进行二次开发实现增量代码覆盖率统计，可以拿到每次执行自动化后的指令级覆盖(Instructions,C0coverage)，分支（Branches,C1coverage）、圈复杂度(Cyclomatic Complexity)、行覆盖(Lines)、方法覆盖(non-abstract methods)、类覆盖(classes)。通过这些信息我们可以对我们的自动化进行查漏补缺。
通过解析前端路由文件，获取线上正在使用的接口数，作为基准，对比自动化执行请求的接口数，可以快速告诉各个模块负责人覆盖盲点。
可以自定义指定线程池，例如大小，超时等等 降低资源消耗：通过重用已经创建的线程来降低线程创建和销毁的消耗
每一项测试数据的清理，都是一个任务类，所有的任务类都继承了一个抽象类，在action方法里定义了数据清理的接口请求 在每次创建数据后，实例化任务类，然后添加到队列里 所有测试用例执行完成后，afterTest里遍历队列依次数据清理
采用这个方式的优势：
自动化测试任务中途异常退出结束了，也可以清理掉已创建的数据
支持多份的同样数据清理，数据之间不受影响
无需用完立刻删除，统一清理，且支持并发，高效
四、消灭更多的测试盲点
在对应的后台应用上找到购买商品的Topic A 在BCP平台建立一个监听A广播消息的Channel B 消费A的广播消息时触发接口请求，查询买家的权益信息，检查是否对于的优惠券信息 接口请求回来的数据和A广播发出的消息体，作为对账规则的数据来源 在规则库创建好对账规则，进行线上每一笔数据的校验
Agent包括阿里开源的Sandbox和我们开发的插件，插件里实现了流量抓取、保存和回放的逻辑。以Java Agent的方式挂载到生产环境的机器，就可以开始采集流量了 一次流量录制包括一次入口调用和若干次子调用（Dubbo、NSQ、MyBatis、Redis、HBase），通过traceid将入口调用和子调用绑定成一次完整的记录，监听BEFORE、RETRUN、THROW事件机制获取每次调用的传参和返回 每一个完整流量的traceid和调用链路，会生成一个MD5值，判断是否有重复，若有，测试用例热度+1，若无，创建新的测试用例保存 测试环境部署被测代码，也挂载上Agent，创建任务执行线上流量保存下来的测试用例，支持Mock dubbo consumer和中间件调用 执行返回的response和线上采集的进行Json diff，分析差异化判断是否是BUG。下图是我们项目实际的使用流程：
线上流量采集，还原真实用户场景，覆盖率高
自动分析生成测试用例，省去手动编写和后期维护工作，大大提升效率
支持自定义Mock，将后端服务隔离，进行模块化测试，代替单元测试的完美方案
拓展阅读：
有赞业务中台测试团队介绍 Dubbo 压测插件 2.0 —— 基于普通 API 调用 有赞精准测试实践 K8S 在有赞 PaaS 测试环境中的实践 一次 Logback 发现的隐患 有赞持续集成容器化实践 前端精准测试探索：覆盖率实时统计工具