Mock测试的平台化实践-challenger

背景

随着业务系统的增多，开发人员提测速度的不一，mock 测试在各个公司的使用越来越广，但是在使用过程中也会遇到一系列弊端：

1. 没有统一的平台或基本框架，个人独立编写 mock 脚本成本较高；

2. 过往数据没有平台沉淀，后期需要使用时，不便于后期数据修改及重复利用；

3. 各自启动，各自维护，不便于调试，出错率很高；

4. 代码维护没有统一标准，冗余文件随之增加。
   

参考及调研市场上类似平台后，基于自身遇到的一些问题及思考，开发实践更贴合我们使用的mock 测试平台。

平台化解决方案的思考

首先，需要整理出平台实现的一些功能场景：

• url mapping（统一入口管理）

• mock 基本配置模块

• 参数管理模块

• 规则配置模块

整体架构图如下：

工作流程图如下：

url mapping - 请求接收与解析

拿 HTTP 响应 mock 举例，在系统请求后，一改以往每次用不同脚本去接收不同请求，统一入口去做接收，如下：

1 @RequestMapping(value = "/")
2 public String main(HttpServletRequest request) {
3    String contextPath = request.getContextPath();
4    String url = request.getRequestURI();
5    String path = url.substring(contextPath.length());复制代码

拿到实际请求地址，截掉请求上下文。

请求类型有很多种，也在代码中实现根据请求类型进行判定，获取请求类型：

1 String method = request.getMethod();

2 String contentType = request.getContentType();复制代码

mock 基本信息配置模块

配置模块主要用于配置不同种协议mock基本配置，如下图举例，分为http协议mock与dubbo接口mock，统一维护入口，可增删改接口信息，方便测试人员配置与维护：

1）HTTP配置主要由请求自定义URL，请求类型，与请求体中包含字段组成：

2）DUBBO基本配置由注册中心（注册地址、超时时间）、协议名称、服务名称、应用名称等相关信息组成，用户在配置完成后，选择响应接口，录入方法名，方法名与需要mock的系统提供的接口中方法名一致。

注册配置如图：

注册后效果如图：

参数管理模块

为了解决目前 mock 测试中，请求回调后，参数无法往下传递的情况，该模块主要提供以下功能：

• 使响应体中信息可进行向下传递，在后一次请求中能得到响应中信息值

• 参数初始化，将参数值与请求配置信息解耦，在改动参数值的同时，不会影响请求配置信息，降低配置出错概率。

参数化配置界面如图：

规则配置模块

该模块为整个平台中业务处理模块，根据请求字段，做相应规则判断，如图：

将规则从以往脚本中提取，存储于数据库中，方便测试人员管理维护，DUBBO规则配置也是如此。

平台结果输出如图

实践总结

目前平台已开始运行，测试的弊端问题得到一定程度的解决，总结优点如下：

• 降低测试人员代码水平不一的影响

• 参数与规则脚本分离，降低配置出错率，并可使参数在流程中向下传递

• 规则统一管理，独立保存，方便更改

后期展望：

• 解析接口文档，可在规范接口文档的同时，在编写后直接导入系统，由系统自己解析并生成mock 脚本

• 流程定制，让响应数据更加符合业务逻辑与现实数据。

作者简介

仙道，铜板街测试研发工程师，2015年3月加入团队，目前主要负责资产端项目测试与自动化测试平台研发。

                                

                      更多精彩内容，请扫码关注 “铜板街技术” 微信公众号。