作者简介
Peter Sun，携程高级测试经理。
一、引言
这里说的Mock指的是系统测试或者接口测试场景下，模拟被依赖的其他服务接口进行响应返回的工具。测试人员通过服务接口级Mock的手段隔绝真实外部依赖，创造可控、稳定的测试运行环境，以提升问题的查全率和查准率。
然而，随着业务的发展和微服务化的进程，我们系统的结构越发的庞杂，Mock工具的实际效果开始变得差强人意。这里给大家分享我们遇到的挑战以及解决思路。
二、问题的出现
随着业务发展和微服务化进程，系统结构越发庞杂。服务化场景下使用Mock，有两个问题开始浮现出来。
1）工作串扰，启用Mock影响其他应用的测试工作
理想中的场景：
操作注册中心，使依赖指向Mock服务。
现实中的场景：
通过注册中心切换被测应用的依赖指向到Mock服务的动作，同样会影响到环境中其他应用的依赖指向，引发串扰（上图中应用B受到影响）。
PS：有被问及为何不调整被测应用的代码或者配置指向目标Mock，避免串扰其他应用。这种入侵代码的手段是下策。常在河边走哪有不湿鞋，总会有忘记改回来造成生产事件的时候的。
2）生效延迟
Mock的生效依赖注册中心的服务注册生效过程。由于缓存的存在，实际的生效时间是无法确定的，存在几秒到几分钟的延时。
对于功能测试场景而言，这些延时并无大碍，而在接口自动化测试场景中，这些延时将导致结果的不稳定性激增。为了避免延时带来的不确定性，通常会在测试框架中添加隐式等待的机制，重试调用被测接口，直到期望结果的出现，或者在达到最大等待时间后抛出异常。这么做的代价是测试执行效率的牺牲。在case数量很大时，这累计起来的等待时间就让人有些痛苦了。
现在问题比较清楚了，由于Mock的生效过程依赖服务架构中的“注册中心”，所以导致了Mock的串扰和延迟的出现。看着不是大问题，但确实用着不舒服。抽象一点说就是，“测试的过程依赖了被测系统的一个基础组件，造成测试执行稳定性的下降”。
三、解决思路
1）Mock 边车化，为应用提供本地化的Mock，使Mock同具体服务架构解耦。Mock一对一服务被测应用，以隔绝多应用间串扰的可能。
2）Mock 的启用和断开，通过控制被测应用所在JVM代理相关系统变量进行。即Mock的存在对应用透明，不依赖服务架构也不侵入应用代码和配置。
下图展示了应用与Mock的概要部署关系：
解决方案概述：
上述问题的解决方案由四部分组成——servlet agent、本地 Mock代理、Mock server、Mock 配置客户端。
1) servlet agent（开关）：设置被测应用所在JVM的网络代理相关系统变量，导出应用对外请求，转发至“本地 Mock代理”。同时提供API供“Mock配置客户端”调用，以供人员或者脚本控制Mock的链接可断开。就是被测应用Mock与否的热开关。如图：
2) 本地 Mock代理（桥梁）：根据自身维护的路由配置转发请求至Mock server或者原始目标服务器。同时提供API供“Mock配置客户端”进行路由表的配置。在Mock启用的状态下，作为被测应用到Mock服务或者真实依赖之间桥梁。如图：
3) Mock server：就是原本意义上的Mock。根据Mock的配置内容进行具体response的返回。市面上也有不少开源的Mock工具可以放在这块来用，最好选择提供了API供外部调用进行设置的。这样跟“Mock 配置客户端”对接起来工作量就很小了，在方案中的位置如上图。
4) Mock 配置客户端：提供简单的API，在方案中的问题如上图。
供测试脚本调用，在测试脚本中直接控制Mock的链接，断开，启动，停止，和具体Mock的设置。
供GUI工具调用，让测试人员可以控制Mock行为。
最终对测试脚本暴露出来就是这个“Mock配置客户端”吐出的具体API。这部分可以发挥想象力，结合具体场景包装的使用起来方便些就行了。
Mock的开关和配置过程简图：
Mock打开时的依赖请求过程简图：
四、小结
我们通过使Mock本地化，给Mock加开关（servlet agent），做桥梁（本地Mock代理）的方法解开了Mock工具同服务架构之间的耦合关系，解决了启用Mock时的串扰和延时问题。
我们发现这个方案存在一定的普适性，未来可以考虑把Mock开关从 JVM层（servlet agent）下降到系统层，那么也就具备了服务其他语言应用的能力了。
【推荐阅读】
“携程技术”公众号
分享，交流，成长
来源：oschina
链接：https://my.oschina.net/u/4313521/blog/4254289