详解自建Mock平台解决开发测试难题
一、背景介绍
在日常开发测试中，我们常常会遇到手动去数据库改数据，构造数据等一系列需要改变正常返回数据的情况，操作相对较为麻烦，同样的前端在开发过程中依赖的后端接口没有准备好，导致前端的自测工作被耽误；在历史故障分析中，很多前端故障都是因为某个数据的特殊性导致的前端不兼容，且这部分数据日常测试过程中很难复现，同样的，在故障解决后的故障演练中，我们无法精准地改变某一个参数，去简单地模拟出之前的故障；在ui自动化用例编写维护中，我们常常因为数据的不稳定性，导致部分自动化场景无法稳定地去实现，面对如此情况，要么选择放弃该场景，要么不停地维护数据。面对上述场景中的各种阻碍，我们需要一款工具能够简单方便地解决我们的问题，且上手简单，应用场景广泛，所以基于此推出了Mock平台，一种功能强大的开发工具，该平台提供了以下主要能力：
解耦需求开发测试过程中对后端的强依赖：
在定义好接口后，前端开发人员可以利用Mock数据独立进行开发。这意味着前端团队不需要等待后端服务的实现和部署，而可以使用模拟数据进行界面设计和业务逻辑的开发。这样一来，前端开发和后端开发可以同时进行，大大提高了项目的开发效率。
更好的适配诸如新手任务、图片链接失效等不容易构造，出现一次就不再出现的依赖后端接口的场景
UI自动化的Mock数据能力：
对于UI自动化测试来说，通常需要依赖后端服务来获取真实数据。但是Mock平台允许开发人员使用虚拟数据来代替真实数据，从而降低对后端服务的依赖。如此，UI自动化测试可以独立运行而无需依赖后端服务的可用性，极大地简化了测试环境的搭建和配置。
更稳定的数据也会带来更稳定的UI自动化脚本
录制后端请求以定位多服务间传参问题：
在微服务架构中，多个服务之间的参数传递往往变得复杂。Mock平台允许录制后端请求，帮助开发人员定位并解决多服务间传参问题。通过记录和回放请求，开发人员可以更好地理解和调试服务间的通信，从而提高系统的稳定性和可靠性。
异常场景（故障演练）测试:
Mock平台还支持在日常测试中进行异常场景的模拟。通过模拟各种异常情况，如网络故障、数据错误等，开发人员和测试人员可以更全面地评估系统的鲁棒性和健壮性。这种测试方法可以帮助发现潜在的问题并改善系统的质量。
综上所述，Mock平台是一个功能丰富的工具，为软件开发过程中的前后端协同、UI自动化测试、微服务场景下的参数传递和异常场景测试等提供了有力的支持。通过使用Mock平台，开发人员可以更加高效地开发和测试应用程序，提高开发速度和质量。
二、方案设计
平台的实现调研了通过现成的服务的方式，使用类似 apifox 工具本地/线上打桩。apifox 不仅有基于 Swagger 的 API 管理的能力，同时也具备 API Mock 的功能。具体使用方法可以访问： https://www.apifox.cn/
下图列举了该方式的优缺点
| 优点 | 缺点 |
|
|
基于该方式优缺点，我们考虑Mock平台需要满足如下要求：
无感知支持酷家乐加密数据（展示出来可编辑的数据是解密的，Mock的Response是加密的）
类Fiddler仅做指定接口的Mock，其它接口正常返回，方便前端页面测试
支持多种Mock添加方式，如现有接口的修改，自定义添加接口
支持模拟接口状态码异常、接口延时
三、具体实现
Mock服务消息流图如下所示
第一步，通过修改域名（通过域名转发配置），访问指定的规则的域名请求将转发到mock server；
第二步，mock server将进行地址解析，然后发送请求到真实的服务器，并取得返回结果。
第三步，如果对应的api不需Mock(根据字段type)，则返回结果会落库并返回给前端页面；若要Mock，就返回预先编辑的Mock的数据。
此外，在Mock平台可视化界面，我们可查询之前页面访问过程中（即流量录制中）的接口及相关数据（对加密数据进行了自动解密展示），并进行数据编辑（支持修改响应数据、响应码、延迟时间）和配置是否需要对其Mock。
接口数据存储的数据库的表结构如下，其中字段type用于标记是否需进行Mock
Mock平台可视化界面如下
四、功能使用介绍
用户实现的操作流程图如下
在测试环境管理平台，新建feature环境域名，比如feature.feat.qunhequnhe.com
浏览器访问带mock的域名（在域名中feat后加上.mock http://feature.feat.mock.qunhequnhe.com)，进行业务操作，就可访问过程中的api数据
在Mock平台可查询刚导流的所有接口的请求和返回数据(加密的数据支持了自动解密) ，并可编辑任一接口的数据，包括（状态码、延迟时间、响应数据）,并可设定是否对其Mock
在Mock接口后，重新访问域名http://feature.feat.mock.qunhequnhe.com 对应的接口就会按预期返回Mock的数据 （接口是按method+url+parm维度区分的）
如果熟悉接口数据，也支持自己添加。
具体应用场景简介
case1:验证普通个人账号每周只能使用3次积分，用完后应引导该用户升级会员
在设计UI自动化覆盖这个场景时，希望Mock该接口每次返回都是用户用完积分的状态，于是找到对应的接口，然后更改其返回数据的部分字段，最后指定UI自动化访问的域名是配置域名就完成了正常UI自动化回归。
case2:新增业务，需要验证新增接口不影响主流程核心链路；
具体业务场景：会员水印实验需求中，有试用次数的用户，才可以发起试用渲染，这个新需求改动了渲染核心流程，需要验证即便该接口异常，也不影响用户其他非实验渲染。于是配置该接口状态码500进行验证。
验证发现：该接口500只影响试用分辨率渲染，不影响其他常规免费/用券/用积分发现渲染的流程，符合预期
case3:故障演练，尤其是前端部分针对部分后端接口数据缺失&异常的降级，Mock该后端接口数据，比如返回null。
具体业务场景：在实时渲染这个功能中，依赖ksg数据的正常加载才能进行页面编辑操作，于是可以配置接口返回空的情况。
验证时发现，当前界面不仅页面无法加载，而且都没法退出，这势必将影响用户的体验。于是后面又推进产品层面对该种场景进行优化，让45秒内还没完成加载时出现提醒及重试按钮，并提供退出的开关。
五、总结思考
目前仅支持http协议的Mock，所以目前还是在线下环境上运行；后面需要调研实现对https协议的Mock，这样的话可以实现对线上预发环境的Mock
目前针对加密字符的识别是通过总结归纳的方法，依然存在部分漏解密的情况，虽然目前可以通过手动添加的方式去兼容这种问题，但是依然希望能完全解决识别加密字符串的问题
推荐阅读