专栏首页用户6296428的专栏持续演进的接口自动化测试方案

持续演进的接口自动化测试方案

点击关注“有赞coder”

获取更多技术干货哦~

作者:Henry

部门:美业测试

前言

接口自动化测试是个老生常谈的话题,基本上每个测试团队都会涉及,市面上大部分文章会从如何设计框架去讲解。但是这一次我想回归自动化的根本价值,从持续演进的解决方案出发,讲解有赞测试团队的心路历程和对于接口自动化的理解,欢迎交流。

一、价值

有赞测试团队肩负的一个使命是:打造高效且可靠的产品交付能力。为了完成这个使命,我们会借助各种工具,而接口自动化就是其中的一把利器。

如何让接口自动化的价值最大化,首先需要想清楚如何去评估接口自动化的质量,有赞测试团队是这样思考的:

  1. 最大化提升回归测试的效率
  2. 消灭更多的测试盲点

接下来介绍的持续演进的方案都是基于这两个方向去努力的

二、业务服务器架构

为了让大家更好地理解我们的演进思路,我先简单介绍一下我们业务的服务器架构,接口自动化的测试目标。

客户端:渠道较多,分Web、H5、小程序、APP、Pad,通过youzan.com域名请求,统一接入到公司网关层Nginx集群,反向代理转发到对应业务的Web服务器。

  • Web服务器:这一层是Nodejs实现,涉及逻辑主要是路由转发、登陆态校验。
  • 后端服务器:电商系通用的Java微服务架构,API1和API2是接入层,涉及逻辑主要是请求转发和非业务相关的通用处理。Service1这一层才是真正的业务逻辑层,大概有30多个微服务应用,互相之间使用dubbo协议通信。

所以,接口自动化面临2种选型:

  1. 模拟客户端进行HTTP请求,优势是能快速覆盖用户场景,劣势是需要构建大量的数据,后期维护成本高。
  2. 基于dubbo协议进行请求,优势是能Mock依赖数据,劣势是前期脚本编写成本高,且不支持预发执行。

该如何选择呢?小朋友才做选择题,成年人我们都要了,两者互相结合,扬长避短。

三、如何提升回归测试效率

这里需要从三个阶段来看:回归测试前、回归测试中、回归测试后。

回归测试前,我们通过2个事情来提升效率:

1、精准定位自动化测试覆盖范围

最原始的范围依据是根据功能测试用例来,但这不是客观合理的,我们从对外暴露的接口数和后端Service层应用的代码覆盖率去评估。

我们基于JaCoCo进行二次开发实现增量代码覆盖率统计,可以拿到每次执行自动化后的指令级覆盖(Instructions,C0coverage),分支(Branches,C1coverage)、圈复杂度(Cyclomatic Complexity)、行覆盖(Lines)、方法覆盖(non-abstract methods)、类覆盖(classes)。通过这些信息我们可以对我们的自动化进行查漏补缺。

通过解析前端路由文件,获取线上正在使用的接口数,作为基准,对比自动化执行请求的接口数,可以快速告诉各个模块负责人覆盖盲点。

2、高效编写自动化脚本

我们需要通过抓包工具来获取请求信息,这里面涉及到请求过滤、数据格式化、拷贝、顺序调用等工作,我们做了一个Chrome插件来代替这些大量的重复性工作,以提升自动化编写效率。

依下图所示,先Start开始抓包,操作被测页面,Stop停止,列表会过滤显示符合条件的XHR类型请求,请求信息自动格式化,支持手动单条删除or拷贝,点击Copy调用接口批量上传到自动化测试平台,是不是大大简化了前期获取原生数据的工作。

在我们测试平台进行用例的二次编辑,全部支持界面化。

回归测试中,只需要关注一个事情:执行时间。随着业务不断壮大,线上接口数接近2000+,对应的自动化接口请求数10000+,每次全量执行时间需要1个多小时,这样的速度是无法接受的,为了在10分钟之内解决战斗,我们做了3个事情:

1、延迟队列

废除了Sleep方式,将数据有延迟的校验放置到延迟队列中,支持自定义在一级模块or二级模块后再校验。

2、多级模块支持并发执行

我们采用官方的CompletableFuture异步线程类实现执行逻辑,Executors线程池管理,和业务账号池关联起来,一个线程对应一个执行账号资源,项目实际多模块并发的代码如下:

合理的使用线程池能够带来以下明显的好处:

  1. 可以自定义指定线程池,例如大小,超时等等
  2. 降低资源消耗:通过重用已经创建的线程来降低线程创建和销毁的消耗

3、数据清理采用命令模式

  1. 每一项测试数据的清理,都是一个任务类,所有的任务类都继承了一个抽象类,在action方法里定义了数据清理的接口请求
  2. 在每次创建数据后,实例化任务类,然后添加到队列里
  3. 所有测试用例执行完成后,afterTest里遍历队列依次数据清理

采用这个方式的优势:

  1. 自动化测试任务中途异常退出结束了,也可以清理掉已创建的数据
  2. 支持多份的同样数据清理,数据之间不受影响
  3. 无需用完立刻删除,统一清理,且支持并发,高效

回归测试完成后,当然要去分析结果了。一个信息全面,交互良好的测试报告可以让自动化结果分析效率大大提高。

四、消灭更多的测试盲点

有赞测试团队会定期分析线上漏测BUG,从后端BUG的分析结果来看,主要原因集中在偶现的数据不一致和复杂用户场景覆盖两个方面,反映出组装接口请求进行自动化测试覆盖的局限性。如何消灭这2个盲点,成为了我们演进的一个方向,我们将接口自动化测试场景转战到生产环境。

1、线上业务自动化校验

在公司越来越复杂的分布式架构下,难免会出现远程调用失败,消息发送失败,并发bug等问题,最终会导致系统间的数据不一致。传统的接口请求方式是无法发现这类问题的,我们需要借助BCP业务校验平台。

举个实际BUG场景:买家在有赞商家店铺购买商品参与了满减送,但是赠送的优惠券迟迟没有送达。我们来讲讲如何覆盖这个场景的:

  1. 在对应的后台应用上找到购买商品的Topic A
  2. 在BCP平台建立一个监听A广播消息的Channel B
  3. 消费A的广播消息时触发接口请求,查询买家的权益信息,检查是否对于的优惠券信息
  4. 接口请求回来的数据和A广播发出的消息体,作为对账规则的数据来源
  5. 在规则库创建好对账规则,进行线上每一笔数据的校验

这样能做到,用户购买商品产生的每一笔数据,都会经过我们自动化校验,确保每一笔数据的一致性,偶现的BUG是不是无处遁形

2、流量录制回放

前面提到的传统接口自动化解决方案,无论优化到什么程度,对于用户场景覆盖和效率提升,都是有一定的局限性的。

所以,为了不断演进我们需要引入新方案,有赞测试团队引进的流量录制回放,基于阿里开源的JVM AOP的能力,通过对被测应用进行挂载Sandbox,进行字节码注入,从而达到在线上录制流量和测试环境回放流量的目的。

上图是有赞流量录制回放平台的架构图,一次完整的流量录制回放是这样的:

  1. Agent包括阿里开源的Sandbox和我们开发的插件,插件里实现了流量抓取、保存和回放的逻辑。以Java Agent的方式挂载到生产环境的机器,就可以开始采集流量了
  2. 一次流量录制包括一次入口调用和若干次子调用(Dubbo、NSQ、MyBatis、Redis、HBase),通过traceid将入口调用和子调用绑定成一次完整的记录,监听BEFORE、RETRUN、THROW事件机制获取每次调用的传参和返回
  1. 每一个完整流量的traceid和调用链路,会生成一个MD5值,判断是否有重复,若有,测试用例热度+1,若无,创建新的测试用例保存
  2. 测试环境部署被测代码,也挂载上Agent,创建任务执行线上流量保存下来的测试用例,支持Mock dubbo consumer和中间件调用
  3. 执行返回的response和线上采集的进行Json diff,分析差异化判断是否是BUG。下图是我们项目实际的使用流程:

由此看来,对比传统接口自动化,流量录制回放有如下优势:

  1. 线上流量采集,还原真实用户场景,覆盖率高
  2. 自动分析生成测试用例,省去手动编写和后期维护工作,大大提升效率
  3. 支持自定义Mock,将后端服务隔离,进行模块化测试,代替单元测试的完美方案

以上拙见,希望能起到抛砖引玉的作用,欢迎各位测试同仁一起来交流分享。

本文分享自微信公众号 - 有赞coder(youzan_coder),作者:有赞技术

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-10-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 接口自动化对比工具实践

    接口自动化一直以来都是质量保障的重要一环,在接口自动化日常工作中,我们致力于场景的覆盖与结果校验。随着业务的高速发展,高效保质的迭代自动化用例成了我们的一个研究...

    有赞coder
  • 有赞搜索中台的探索与实践

    有赞搜索中台作为有赞企业级搜索能力复用平台,在解决各个业务域搜索问题时是如何探索与实践的,这个过程中有哪些心得,本文与大家一起分享探讨下。

    有赞coder
  • 有赞服务回归验证平台 - 对比引擎

    有赞作为一家 SaaS 公司,除了传统的微商城,还提供了零售、美业等产品解决方案。随着公司业务的快速发展,各业务系统也不断的进行着功能迭代或系统重构,如何保证这...

    有赞coder
  • 编写代码生成器的一些问题与思考

    去年7月开始参加工作,刚开始被先后分配了两个制作基础页面的任务,是常规的增删改查,包括前端页面的vue文件以及后端实体类和各逻辑层的接口、实现类,总共需要创建9...

    草捏子
  • 网站大规模并发处理方案:电商秒杀与抢购

    一、大规模并发带来的挑战 在过去的工作中,我曾经面对过5w每秒的高并发秒杀功能,在这个过程中,整个Web系统遇到了很多的问题和挑战。如果Web系统不做针对性的优...

    wangxl
  • 电商网站秒杀与抢购的系统架构

    一、大规模并发带来的挑战 在过去的工作中,我曾经面对过5w每秒的高并发秒杀功能,在这个过程中,整个Web系统遇到了很多的问题和挑战。 如果Web系统不做针对性的...

    架构师小秘圈
  • 电商网站秒杀与抢购的系统架构

    在过去的工作中,我曾经面对过5w每秒的高并发秒杀功能,在这个过程中,整个Web系统遇到了很多的问题和挑战。如果Web系统不做针对性的优化,会轻而易举地陷入到异常...

    哲洛不闹
  • 存储基础:DAS/NAS/SAN存储类型及应用

    一. 硬盘接口类型 1. 并行接口还是串行接口 (1) 并行接口,指的是并行传输的接口,比如有0~9十个数字,用10条传输线,那么每根线只需要传输一位数字,即可...

    小小科
  • SpringBoot 中的 Logback 配置:根据环境读取不同配置

    SpringBoot 默认使用 Logback 框架作为日志框架。最近有个想法“由于配置了多环境,比如开发环境,测试环境等,想根据不同环境指定日志文件的存储位置...

    zhangyunfeiVir
  • maven3.x上传jar

    由于工作需要,将原有的nexus2.x升级为nexus3.x,升级后创建仓库是非常方便,但是该如何将本地的jar上传到maven仓库呢?这个博主就像无头的苍蝇找...

    一笠风雨任生平

扫码关注云+社区

领取腾讯云代金券