质量体系建设之路---可视化的MockServer

一、 背景

福禄网络作为一家数字权益商品及服务提供商，覆盖了我们衣食住行的各种生活场景的权益内容，对接了如支付宝、京东、银行APP各种渠道，如何能够快速的响应渠道需求，提供稳定的接口服务，这就要求我们电商团队能够做到比渠道快一步的接口测试；
同时作为一家集团化的公司，内部的信息化系统对接了众多银行的相关支付业务，涉及到查余额、下流水、支付、对账等日常资金业务，这要求信息化部门能够确保资金支付相关场景能够在上线前进行完整覆盖，业务方新的业务接入或者需求场景变更比较频繁，版本的快速迭代背景下如何保证众多的场景能够快速覆盖，通过完全真实的业务操作成本是巨大的；

二、 引入MOCK

基于上述的业务系统测试痛点，质量管理团队决定引入mock服务。我们首先想到的是以最低的成本来完成，市面上有许多的mockserver的开源软件，但在调研了相关的开源产品之后，我们发现没有一款比较贴合我们业务需求的产品；
比如我们的资金支付相关场景对接的银行方，都是以xml报文的格式作为请求和返回；有些场景对返回模板的数据是动态要求的，比如某个支付状态第一次请求是处理中，第N次请求变为成功；而有些银行通信协议是socket等，通过调研后我们决定自己来开发一套mock服务。

三、框架选型

1. 界面可视化操作
   为了保持系统风格的统一，我们决定沿用QECS平台的前端框架(QECS详细介绍移步至：https://www.cnblogs.com/fulu/p/15419208.html)
2. 高性能
   为了满足高性能的需求，模板数据存储我们采用redis；开始我们准备沿用QECS的后端框架flask，在进行了一系列的性能测试后，我们发现无法支撑我们5KTPS的需求，后来我们改用了springBoot，经过测试能够达到我们的需求；

四、具体实现

4.1 设计方案

外部请求打入Mock服务，监听服务获取到请求通过Redis中的已有模板进行规则匹配，满足匹配规则返回对应模板数据；不满足返回无法匹配的数据提示。

4.2 功能说明

数据格式
目前匹配规则支持json、form、query、xml这几种参数类型；返回支持j