接口测试新思路-基于流量回放的接口自动化测试
随着接口越来越多，变更也越来越频繁，传统的通过编写脚本的方式来测试接口所花费成本已经成为了不能承受之重。所以衍生出一些接口测试的新方法、新思路，其中当前最有效率的要数基于线上流量回放的自动化测试。
其中一种是黑盒测试思路，它复制线上流量，然后使用和线上环境相同的环境下用复制到的流量重新触发请求，然后断言被请求URL的返回值是不是和录制时的一致。这种方法一般只能对Get类型的接口进行测试，由于流量的时效性、数据状态、环境依赖性等因素，所以这种测试方式具有一些局限性。
另一种是白盒测试思路，通过智能化的Mock手段，能够Mock程序对外的依赖中有可能产生变化的内容，使测试更关注接口的代码逻辑，这种方式目前已经在一些大厂内部广泛使用。
目前公开出来的工具有doom（阿里）、ares（去哪儿）、jvm-sandbox&jvm-sandbox-repeater（阿里）、RDebug（滴滴），由于这种方式的可靠性和效率很高，下面主要介绍一下这种方式。
当一个接口被请求到，这个接口会产生相应的IO以及一些返回内容不确定的调用，例如读写数据库、调用第三方接口、处理数据、返回Http对象、时间和随机数等。当这些调用的返回结果不确定时，如果回放不成功，我们就没办法判断接口是不是真的有bug。
接口需要在“依赖”存在的情况下才能运行，那么依赖是什么呢，一般来说调用者和被调用者的关系称为“依赖”，在运行时依赖发生的过程中就会有数据在依赖中传输。举个例子，我们通过测试程序调用接口的过程中，其实是测试程序依赖了被测接口，被测接口依赖了数据库和第三方接口等。
根据测试三角理论，我们需要大量的测试自己编写的代码，而对于第三方的调用依赖则不需要过多的测试。测试的主要目的之一就是来测试我们自己代码逻辑的正确性（通过流量回放自动生成测试用例）。所以，录制的核心其实是录制该接口运行时对外的所有依赖，并且将”依赖“存储起来，同时能够在运行时更改接口的依赖路径，当以同样的数据再次驱动该接口运行时，该接口对外的真实依赖路径变更为录制到的”依赖“。
所以我们需要思考如何动态替换掉子调用，我们还需要Mock过程需要的数据，也就是Mock成什么；需要找到要Mock的点，即一个单元调用另一个单元的调用点。
当然Mock还要稍微智能化一点，它可以接受我们的参数，进行不同的Mock。
拿我们日常的应用来举例，应用接收到一个http请求后，一般会依次向下调用Controller，Service、Dao层的方法，在每个层也会调用一些公共类库和自己定义的一些方法。如果把http请求录制下来后，当使用录制到的http请求回放时，代码依然会向下调用Controller，Service、Dao层的方法，直到通过某个边界对外产生IO，或者代码中调用生成随机数的函数，如果没有进行Mock，外部IO返回的数据以及随机数的因素就会导致回放失败，所以需要解决回放的时候把这些依赖的子调用自动mock掉。
这里就需要录制时把“流量”贯穿主入口是的参数和返回以及子调用的参数和返回绑定起来同时录制下来。回放的时候，用某一条录制的请求数据调用http入口时，当代码执行到子调用也需要用事先录制到的“调用”数据进行Mock。由于我们录制时是将调用参数和返回绑定起来的，所以回放的时候Mock服务就会根据我们的参数去给我们返回对应的返回内容。
这种流量回放测试思路具有很多优点，第一不需要完整的测试环境，只需要将测应用搭建起来即可，应用所依赖的数据库等中间件统统不需要。第二各种get、post类型的接口都可以进行回放，不会真的对数据库产生操作。第三问题容易定位，由于Mock了对外依赖，出现的问题一定就在代码内部。
标签:
