整套解决方案：持续演进的接口自动化测试方案

　　不断发展的界面自动化测试解决方案

　　前言

　　接口自动化测试是一个常见的话题，基本上每个测试团队都会参与其中，并且市场上大多数文章都会解释如何设计框架。但是这次我想回到自动化的基本价值。从解决方案的不断发展开始，我将解释Youzan测试团队的心态和对界面自动化的理解。欢迎交流。

　　一、值

　　Youzan测试团队的任务之一是创建高效，可靠的产品交付功能。为了完成此任务，我们将使用各种工具，并且接口自动化就是其中之一。

　　如何最大化界面自动化的价值，您首先需要弄清楚如何评估界面自动化的质量。友赞测试团队是这样认为的：

　　最大限度地提高回归测试的效率并消除更多的测试盲点

　　接下来介绍的持续发展计划基于这两个方向。

　　二、业务服务器架构

　　为了让每个人都更好地理解我们的进化思想，让我简要介绍一下我们公司的服务器体系结构和接口自动化的测试目标。

　　客户端：有很多渠道，包括Web，H5、applet，APP和Pad。通过域名请求，可以统一访问公司的网关层Nginx集群，并将反向代理转发到相应的业务Web服务器。

　　因此，界面自动化面临两种选择：

　　模仿客户端发出HTTP请求。优点是它可以快速覆盖用户场景，但是缺点是需要构建大量数据并且后续维护成本很高。基于dubbo协议的请求具有能够模拟依赖数据的优点，但缺点是预脚本的成本很高，并且不支持预执行。

　　如何选择？孩子们会做选择题，我们希望他们适合大人。两者结合在一起可以最大限度地发挥优势，避免出现弱点。

　　三、如何提高回归测试的效率

　　要检查三个阶段：回归测试之前，回归测试期间和回归测试之后。

　　在进行回归测试之前，我们通过两件事提高了效率：

　　1、准确定位自动化测试的范围

　　最原创的范围基础是基于功能测试用例的，但这不是客观且合理的。我们从公开的接口数量和后端服务层应用程序的代码覆盖率对其进行评估。

　　基于JaCoCo的二次开发以实现增量代码覆盖率统计，我们可以在每次执行自动化之后获得指令级覆盖率（Instructions，C0coverage），分支（C1coverage）和循环复杂度（Cyclomatic Complexity）。 ，行覆盖率（行），方法覆盖率（非抽象方法），类覆盖率（类）。有了这些信息，我们可以检查自动化中的遗漏。

　　通过解析前端路由文件以获得在线使用的接口数量（作为基准），比较用于自动执行请求的接口数量，您可以快速告诉每个模块负责人以了解盲点。

　　2、有效编写自动化脚本

　　我们需要使用数据包捕获工具来获取请求信息，其中包括请求过滤，数据格式化，复制，顺序调用等。我们制作了Chrome插件来替换这些重复性工作，以提高自动化程度写作效率。

　　如下图所示，首先开始开始捕获数据包，操作测试的页面，停止停止，列表将过滤并显示合格的XHR类型请求，请求信息将自动格式化，并支持手动单删除或复制，然后单击复制以调用将接口批量上传到自动化测试平台，大大简化了早期获取本机数据的工作。

　　用例的第二次编辑是在我们的测试平台上进行的，所有这些都支持接口化。

　　在回归测试中，只有一件事需要关注：执行时间。随着业务的持续增长，在线界面的数量已接近2000+，相应的自动界面请求的数量也超过10000+。每个完整的执行时间需要1个多小时。这样的速度是不可接受的。为了在10分钟内解决战斗，我们做了三件事：

　　1、延迟队列

　　取消睡眠模式，将具有延迟验证的数据放入延迟队列中，可以在第一级模块或第二级模块之后自定义验证。

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

　　我们使用官方的CompletableFuture异步线程类来实现执行逻辑，并且Executors线程池管理与业务帐户池相关联。一个线程对应一个执行帐户资源。该项目的实际多模块并发代码如下：

　　合理使用线程池可以带来以下明显的好处：

　　您可以自定义指定的线程池，例如大小，超时等，以减少资源消耗：通过重新使用创建的线程来减少创建和销毁线程的消耗

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

　　每个测试数据清除都是一个任务类。所有任务类都继承一个抽象类。数据清理的接口在action方法中定义。每次创建数据时都会实例化任务类。 ，然后添加到队列中。执行完所有测试用例后，afterTest遍历队列并顺序清理数据

　　使用此方法的优点：

　　自动测试任务在中间异常结束，创建的数据也可以清除。可以清除同一数据的多个副本。数据将不受影响，并且将立即删除数据而不会耗尽。还支持统一清理，并发高效。

　　回归测试完成后，我们当然必须分析结果。具有全面信息和良好交互性的测试报告可以大大提高自动化结果分析的效率。

　　四、消除测试中的更多盲点

　　Youzan测试团队将定期分析在线漏掉的BUG。从后端BUG的分析结果来看，主要原因集中在偶尔出现的数据不一致和复杂的用户场景覆盖这两个方面，反映了装配接口的要求。自动测试范围的局限性。如何消除这两个盲点已经成为我们发展的方向。我们将界面自动化测试场景转移到了生产环境中。

　　1、自动验证在线业务

　　在公司日益复杂的分布式体系结构下，不可避免地会发生远程呼叫失败，消息发送失败，并发错误和其他问题，最终将导致系统之间的数据不一致。传统的接口请求方法找不到此类问题。我们需要使用BCP业务验证平台。

　　采取实际的BUG方案：买家在商家的商店购买商品以享受全额折扣，但是所提供的优惠券很长一段时间都没有交付。让我们谈谈如何掩盖这个场景：

　　找到在相应的后台应用程序上购买产品的主题A。创建一个频道B，在BCP平台上*敏*感*词*A的广播消息，以在消费A的广播消息时触发接口请求，查询购买者的权益，并检查优惠券是否有效。信息接口请求的数据并使用A广播的消息正文作为对帐规则的数据源，以在规则库中创建对帐规则，并在线验证每个数据

　　这可以做到。我们会自动验证用户购买产品所生成的每条数据，以确保每条数据的一致性。偶尔的错误无处藏身吗？

　　2、流量记录和播放

　　上面提到的传统界面自动化解决方案，无论如何优化，对于用户场景覆盖和效率提高都有一定的局限性。

　　因此，为了继续发展，我们需要引入新的解决方案。基于阿里巴巴开源JVM AOP的能力，Youzan测试团队引入的流量记录和回放功能可以将沙盒安装到经过测试的应用程序中，并执行字节码注入。以达到在线记录流量和测试环境回放流量的目的。

　　上图是Youzan流量记录和回放平台的体系*敏*感*词*。完整的流量记录和回放是这样的：

　　Agent包括由我们开发的Ali的开源Sandbox和插件。这些插件实现了流量捕获，存储和回放的逻辑。以Java Agent的形式安装到生产环境中的计算机上，可以启动采集流量记录，其中包括一个条目调用和几个子调用（Dubbo，NSQ，MyBatis，Redis，HBase），并且该条目称为通过traceid与子调用绑定成一个完整的记录，*敏*感*词*BEFORE，RETRUN，THROW事件机制以获取参数并返回每个调用

　　对于完整流量的每个traceid和呼叫链接，将生成MD5值以确定是否重复。如果存在，则测试用例的流行度为+1。如果没有，请创建一个新的测试用例以保存测试环境并部署经过测试的代码。还安装了Agent，以创建由任务执行在线流量保存的测试用例，支持Mock dubbo使用者和中间件调用执行返回响应以及在线采集 Json diff，分析差异以确定其是否为BUG。下图是我们项目的实际使用过程：

　　从这个角度来看，与传统的接口自动化相比，流量记录和回放具有以下优点：

　　在线流量采集，还原实际用户场景，覆盖面广，自动分析和生成测试用例，节省手动编写和后期维护工作，大大提高效率，支持自定义模拟，隔离后端服务以及模块化测试，是取代单元测试的完美解决方案

　　以上愚见，我希望它能起到启发作用。欢迎所有测试同事分享。

　　本文转载自公共帐户Youzan编码器（ID：youzan_coder）。

　　原创链接：