Mock 技术是一种软件开发与测试中用于模拟（Mock）测试数据和对象的技术。主要用于消除测试中的依赖关系，提高测试的独立性和可重复性，帮助测试人员进行有效地测试。Mock 技术也可用于前后端和微服务架构下服务间的分离开发。 Mock 技术的主要思想是使用模拟对象或数据，替换测试环境中的真实对象或数据，以达到如同真实环境一般的测试效果。通过 Mock 技术可以提供独立性的测试数据或者环境，为软件开发过程中的单元测试、集成测试、系统测试和性能测试各种阶段提供必要的测试支持。
在互联网金融业务领域，我们面临的挑战包括：长链路业务流程、众多外部服务依赖以及复杂的业务场景。在软件生命周期过程中，多个团队同时参与开发和测试会出现以下情况非常依赖 Mock 服务。
当前 Mock 方法存在的问题
随着业务和技术不断发展，以及测试效率提升要求，原有 Mock 技术方法在复杂技术架构和业务场景的后端服务中应用存在如下问题：
1、Mock 服务与真实服务不能同时工作
服务调用方每次只能请求一个服务地址，Mock 服务地址或真实三方服务地址只能选择其一，无法针对于不同业务场景访问 Mock 服务和真实服务，Mock 服务和真实服务无法同时工作。
同时工作允许部分业务场景与真实三方服务交互，其他场景使用 Mock 测试验证。其优势如下：
1） 降低测试成本
将小金额划扣还款与真实支付渠道服务对接联调保证了功能验证准确性。将大金额划扣还款走 Mock 服务降低测试成本。
图1-真实服务和Mock服务无法同时工作
2） 提升测试效率
将已验证通过的功能切换到 Mock 服务上进行测试，降低三方服务不稳定对我方的测试影响。同时新增独立功能点继续走真实联调测试。
2、Mock 服务与真实服务切换效率低
传统方法需要修改调用方请求地址，更新配置并重启服务加载生效，无法一键迅速切换。
图2-全部流量不支持一键切换
支持动态 Mock 响应且支持反向代理的 Mock 技术服务才能实现部分流量切换。 传统的动态切换方法需要编写切换逻辑脚本。脚本因包含 Mock 的所有动态响应逻辑，频繁修改可能会引入额外风险导致原有 Mock 响应异常。脚本修改进行流量切换是重复性的工作，每次切换均需要熟悉脚本逻辑和修改。
图3-部分流量不支持一键切换
3、多测试环境下不同环境期望使用不同的 Mock 规则
测试和开发环境是多环境的，当不同的环境或者不同用户数据访问同一个 Mock 服务同一个 API 接口时，如果期望返回不同的 Mock 响应，因为不支持虚拟 Mock 服务只能通过调用方请求增加环境标识和动态 Mock 响应实现，实现效率低下且支持度不完善。
图4-不支持环境差异化的Mock规则
综上所述，传统的 Mock 方式很难实现 Mock 服务与真实服务同时工作的模式，无法支持虚拟 Mock 服务（用来区分隔离环境或者业务场景），需要将能实现的逻辑全部放入动态响应脚本，导致脚本内容臃肿复杂且无法复用，每次 Mock 响应逻辑修改均需要重构脚本。
Mock 的切入模式
在介绍好分期 Mock 服务如何解决上述问题之前，先简单说明下好分期中后台技术架构。随着业务和技术不断发展，因包含了历史留存业务系统目前主要有如下两种技术架构，针对不同架构采用不同的方式来切入 Mock 服务。
服务的发现、调度由发布平台和网关实现，服务之间调用通过 API 网关。
图5-切入Mock服务前
图6-切入Mock服务后
Mock 服务切入后，将作为前置网关服务根据路由规则，返回动态 Mock 响应内容或者转发到其他服务。
切入方法：
微服务架构由微服务治理框架组件支撑，服务间调用节点信息来自注册中心。
图7-切入Mock服务前
图8-切入Mock服务后
Mock 服务切入后，微服务通过注册中心获取到的均为 Mock 服务地址，访问 Mock 服务地址后，由 Mock 服务将请求根据环境、API 接口、数据内容等路由到对应的其他微服务或者返回动态 Mock 响应。
切入方法：拦截或者转移微服务的注册，不再注册到所属区域的注册中心。Mock 服务向注册中心注册服务地址。微服务从注册中心拉取待调用的服务节点时，拉取到 Mock 服务地址，并请求到 Mock 服务网关，Mock 服务根据路由规则请求到对应的微服务或者返回动态 Mock 响应。
好分期 Mock 服务整体实践方案
Mock 服务作为统一的访问入口，所有 API 请求均被引导到 Mock 服务。Mock 服务根据请求的特定信息（如访问域名、API 路径、参数、请求头等）进行路由，将请求转发到相应的后端服务或返回动态 Mock 响应。“Mock 路由规则”来定义请求路由行为，包含 3 种工作模式：Internal Forward(内部路由转发）、Upstream（上游转发）、Mock（Mock 响应）。每一个“Mock 路由规则”下可以包含任意多个“条件规则路由”，如果命中“条件规则路由”则执行对应的路由动作。如果未命中“条件规则路由”则使用其所属的“Mock 路由规则”作为兜底的路由动作。通过路由规则的创建和修改即可以实现“Mock 服务和真实服务同时工作（根据命中不同路由条件转发 Upstream 和返回 Mock 响应）”、“流量切换迅速切换（修改路由规则的工作模式）”、“环境隔离区分（虚拟 Mock 服务地址来区分）”。
图9-好分期Mock服务整体方案
Mock 服务作为统一的服务访问入口，使用动态配置生效的“Mock 路由规则”对访问请求进行路由，转发到真实服务或直接返回 Mock 响应。
图10-Mock服务网关特征
创建虚拟 Mock 服务地址（Virtual Host）后可以通过虚拟服务地址域名访问 Mock 服务，便于针对各环境的 Mock 响应结果独立管理。
如果希望 testa.mock.com 和 testb.mock.com 返回同样 Mock 响应，则可以将如上两个服务地址对应的 Mock 路由规则经“内部路由转发（Internal Forward)”到 default.mock.com 虚拟 Mock 服务。仅针对 default.mock.com 虚拟 Mock 服务配置 Mock 响应。
图11-虚拟Mock服务应用场景1
如果希望 testa.mock.com 和 testb.mock.com 分别返回不同的 Mock 响应，则分别定义各自路由规则和对应的 Mock 响应即可。
图12-虚拟Mock服务应用场景2
如果希望请求 testa.mock.com 转发（Upstream）到真实的 a.real.com，而请求 testb.mock.com 时返回 Mock 响应，那么将 testa.mock.com 的虚拟服务更改“Mock 路由规则”转发到 a.real.com 即可。
图13-虚拟Mock服务应用场景3
“Mock 路由规则”包含 3 种工作模式：Internal Forward(内部路由转发）、Upstream（上游转发）、Mock（Mock 响应）。“Mock 路由规则”可以把期望的 Mock 结果模块化，从而可以快速关闭、启用、复用。满足复杂环境及业务场景下动态 Mock 响应、Mock 服务与真实服务的流量的切换。
1）修改路由规则工作模式在 Upstream（上游转发）、Mock（Mock 响应）之间切换，可快速进行 Mock 服务和真实环境迅速切换；
2）Internal Forward(内部路由转发）工作模式可以在 Mock 服务中进行内部实现路由规则复用。如“图 11-虚拟 Mock 服务场景 1”，可将 testa.mock.com 和 testb.mock.com 的“Mock 路由规则”全部“Internal Forward(内部路由转发）”到 default.mock.com 的“Mock 路由规则”。因此我们只需要定义 default.mock.com 的 Mock 路由规则和响应内容。不需要在 testa 和 testb 两个虚拟 Mock 服务上重复配置两次。
3) 根据环境信息、请求数据信息路由到不同的服务或者返回动态 Mock 响应。
图14-Mock路由规则界面
实例：测试团队同时并行着 3 套测试环境，同一时刻都用到某资方借款试算接口，各环境场景如下：
则“Mock 路由规则”处理如下：
图15-Mock路由规则应用场景1
使用场景二：个人维度——同一套测试环境同一接口请求可以根据使用者不同给予不同的应答。
示例：
测试人员 A/B/C 三人在同一套环境调用机构的还款试算接口，各场景如下：
则“Mock 路由规则”处理如下：
图16-Mock路由规则应用场景2
除了常用的内建变量、内建方法之外，好分期 Mock 服务还支持通过 JSR223 标准 Groovy 脚本在线编译和执行来实现访问外部数据库、外部服务，模拟延时。
图17-Mock动态响应
将 Mock 响应和真实服务的响应日志全部记录下来，将 Mock 路由流转路径留存下来，方便针对测试数据进行分析。使用真实服务的响应日志也可以快速完成 Mock 响应报文的制作生成。
总结
好分期 Mock 服务方案应用后，已接入 7 套测试环境服务超 50 个系统。在集成测试、系统测试、自动化测试过程中极大地提升了开发联调、测试效率，证明了这一方案的有效性。同时也帮助开发工程师更加全面地测试系统性能。
未来，会进一步提升 Mock 服务自身性能，支持更多服务和团队。还会继续探索将更加智能化、自动化的 Mock 技术，为开发和测试提供更为准确和实用的模拟数据。
作者介绍
李豪，微财数科 测试高级工程师
畅悦秀，微财数科 测试高级经理
李军，微财数科 技术负责人
吴迪，微财数科 副总裁
