一、引言
这里说的 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)。
原文链接:
评论 1 条评论