一、前言
今天我将和大家一起探讨我们的“自动化mock系统1.0版本”。
二、测试人员面临的测试问题
我公司目前用的是基于dubbo的微服务改造，服务之间的调用链路冗长，每个服务又是单独的团队在维护，每个团队又在不断的演进和维护各个服务，那么对测试人员将是非常大的挑战。
测试人员每次进行功能测试的时候，测试用例每次都需要重新写一遍，无法将测试用例的数据沉淀，尤其是做自动化测试的时候，测试人员准备测试数据就需要很长时间，效率非常低。
目前接口自动化测试框架也多种多样，testng，junit，fitnesse等，但都需要测试人员具备测试代码编写能力，如果要做好和手工接口测试一样效果的自动化测试更是需要大量的代码堆积，后期维护代码成本非常大。因此做成简单配置用例流，无需编写测试代码的系统是更贴合实际工作要求。
举个例子：拿互联网支付系统来说，某个团队新增了支付交易的需求，这时候要进行测试，测试人员除了要测试支付交易需求本身是否正确，同时也要结合上下游的服务整体进行回归测试，这时候开发人员往往在支付交易系统中采用“硬编码”的方式对上下游的系统进行“挡板”，如果测试人员对测试数据有所调整那么“挡板”也要跟着调整，同时在项目正式上线的时候，如果开发人员没有将“挡板”程序去除干净，将面临严重的线上问题。
三、dubbo的mock功能
dubbo自带的mock功能首先是为了做服务降级，比如某验权服务，当服务提供方全部挂掉后，客户端不抛出异常，而是通过mock数据返回授权失败。
我们从官网上举一个例子来说明：
我们可以在期望的reference标签上加一个mock="force"，就可以将当前服务设置为mock。但是设置完mock属性后还没有结束，需要有一个mock类对应我们的服务接口类。
规则如下：
接口名 + mock后缀，服务接口调用失败mock实现类，该mock类必须有一个无参构造函数。
对应到com.foo.barservice的话，则创建barservicemock类。
经过以上设置后，当调用barservice进行远程调用的话，直接请求到barservicemock类上面进行模拟测试。
在dubbo的配置文件中
<code>classpath:/meta-inf/dubbo/internal/com.alibaba.dubbo.rpc.cluster.cluster</code>
可以看到如下配置列表：
我们可以看到配置文件中实际上有五大路由策略：
availablecluster: 获取可用的调用。遍历所有invokers判断invoker.isavalible,只要一个有为true直接调用返回，不管成不成功。
broadcastcluster: 广播调用。遍历所有invokers, 逐个调用每个调用catch住异常不影响其他invoker调用。
failbackcluster: 失败自动恢复， 对于invoker调用失败， 后台记录失败请求，任务定时重发, 通常用于通知。
failfastcluster: 快速失败，只发起一次调用，失败立即保错，通常用于非幂等性操作。
failovercluster: 失败转移，当出现失败，重试其它服务器，通常用于读操作，但重试会带来更长延迟。
dubbo中默认使用的是failovercluster策略，而在实际执行的过程中是failovercluster会被先被注入到mockclusterwrapper中，过程就是：
mockclusterwrapper内部会创建一个mockclusterinvoker对象。实际创建是封装了failoverclusterinvoker的mockclusterinvoker，这样就成功地在invoker之中植入了mock机制。
我们来看mockclusterinvoker的内部实现：
如果在没有配置之中没有设置mock，那么直接把方法调用转发给实际的invoker(也就是failoverclusterinvoker)。
如果配置了强制执行mock，比如发生服务降级，那么直接按照配置执行mock之后返回。
如果是其它的情况，比如只是配置的是mock=fail:return null，那么就是在正常的调用出现异常的时候按照配置执行mock。
dubbo的mock功能主要是为了做服务降级而使用的，服务提供方在客户端执行容错逻辑，在出现rpcexception(比如网络失败，超时等)时进行容错，然后执行降级mock逻辑。自身并不适合做mock测试系统。
四、自动化mock系统的实现
为了基于dubbo实现mock功能，需要对dubbo源码进行一些必要的修改，通过上面的架构图我们可以看到，实际上我们正是利用了dubbo的filter chain过滤器链这一机制实现的，为了方便大家更好的理解，下面将简单介绍一下dubbo的filter机制。
2.1、dubbo的filter原理分析
filter：是一种递归的链式调用，用来在远程调用真正执行的前后加入一些逻辑，跟aop的拦截器servlet中filter概念一样的。
filter接口定义：
filter的实现类需要打上@activate注解, @activate的group属性是个string数组，我们可以通过这个属性来指定这个filter是在consumer, provider还是两者情况下激活，所谓激活就是能够被获取，组成filter链。
关于spi的详细介绍请大家参考我之前写的另一篇文章http://www.jianshu.com/p/46aa69643c97
protocolfilterwrapper：在服务的暴露与引用的过程中根据key是provider还是consumer来构建服务提供者与消费者的调用过滤器链，filter最终都要被封装到wrapper中的。
构建filter链，当我们获取激活的filter集合后就通过protocolfilterwrapper类中的buildinvokerchain方法来构建。
2.2、mock流程介绍
注：我们在<dubbo:application name>中新加了自定义的“env=test”这样的属性配置用来标明当前环境是测试的还是正式的，用户每次通过dubbo请求的远程服务的时候，都会首先经过我们自定义的filter，我们自定义的filter会首先判断当前的环境是test还是正式，如果是test的环境则直接访问mock配置中心获取提前配置好的mock数据并封装成用户定义的response对象返回。
mock配置中心就是用户将mock数据与应用环境建立关系的系统，整个系统就像一个工作流引擎：
环境设置->应用名称设置->挡板规则设置->facade服务接口设置->方法规则设置
环境设置
注：如果尚未映射来源ip地址到环境，则点击环境列表导航链接，进入环境列表页面，点击添加，输入源ip及环境名，点击确定按钮，实现源ip到所设环境的映射。每个用户都可以建立属于自己的测试环境。
应用名称设置
注：创建所使用系统的应用名称，mock配置中心默认使用<dubbo:application name>中的名称作为应用名称。
挡板规则
注：每一个挡板规则都是由一个环境名称和应用名称组成的唯一挡板，在挡板设置中选择环境名称和应用名称，并且设置挡板的有效状态。
facade规则
注：每一个facade就是一个dubbo的服务接口类，在这里将自己的facade名称与全路径与挡板名称对应，以标识哪些facade服务接口类是属于哪个挡板的。
方法规则
注：方法规则是用来设置每个facade中的需要mock的方法的，可以对不同的方法设置方法执行时间、方法抛出的异常等等。
由于不少应用项目开发完后想对其进行单独压测，而很多时候应用系统和其他业务系统形成了依赖关系，如果不布署其他应用系统则无法完成压测，为了更好的支持性能测试组进行挡板压测，mock系统支持压测功能，而mock系统自身也可以达到单台服务器1000tps以上（8c8g)。（全文完）
来源：中生代技术
<a href="https://mp.weixin.qq.com/s/lyimtkcgdeh8dqjmrf-vmw" target="_blank">原文链接</a>