一、引言
这里说的 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 配置客户端。
servlet agent（开关）：设置被测应用所在 JVM 的网络代理相关系统变量，导出应用对外请求，转发至“本地 Mock 代理”。同时提供 API 供“Mock 配置客户端”调用，以供人员或者脚本控制 Mock 的链接可断开。就是被测应用 Mock 与否的热开关。如图：
本地 Mock 代理（桥梁）：根据自身维护的路由配置转发请求至 Mock server 或者原始目标服务器。同时提供 API 供“Mock 配置客户端”进行路由表的配置。在 Mock 启用的状态下，作为被测应用到 Mock 服务或者真实依赖之间桥梁。如图：
Mock server：就是原本意义上的 Mock。根据 Mock 的配置内容进行具体 response 的返回。市面上也有不少开源的 Mock 工具可以放在这块来用，最好选择提供了 API 供外部调用进行设置的。这样跟“Mock 配置客户端”对接起来工作量就很小了，在方案中的位置如上图。
Mock 配置客户端：提供简单的 API，在方案中的问题如上图。
供测试脚本调用，在测试脚本中直接控制 Mock 的链接，断开，启动，停止，和具体 Mock 的设置。
供 GUI 工具调用，让测试人员可以控制 Mock 行为。
最终对测试脚本暴露出来就是这个“Mock 配置客户端”吐出的具体 API。这部分可以发挥想象力，结合具体场景包装的使用起来方便些就行了。
Mock 的开关和配置过程简图：
Mock 打开时的依赖请求过程简图：
四、小结
我们通过使 Mock 本地化，给 Mock 加开关（servlet agent），做桥梁（本地 Mock 代理）的方法解开了 Mock 工具同服务架构之间的耦合关系，解决了启用 Mock 时的串扰和延时问题。
我们发现这个方案存在一定的普适性，未来可以考虑把 Mock 开关从 JVM 层（servlet agent）下降到系统层，那么也就具备了服务其他语言应用的能力了。
作者介绍：
Peter Sun，携程高级测试经理。
本文转载自公众号携程技术（ID：ctriptech）。
原文链接：
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论 1 条评论