背景
随着业务系统的增多,开发人员提测速度的不一,mock 测试在各个公司的使用越来越广,但是在使用过程中也会遇到一系列弊端:
没有统一的平台或基本框架,个人独立编写 mock 脚本成本较高;
过往数据没有平台沉淀,后期需要使用时,不便于后期数据修改及重复利用;
各自启动,各自维护,不便于调试,出错率很高;
代码维护没有统一标准,冗余文件随之增加。
参考及调研市场上类似平台后,基于自身遇到的一些问题及思考,开发实践更贴合我们使用的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月加入团队,目前主要负责资产端项目测试与自动化测试平台研发。
更多精彩内容,请扫码关注 “铜板街技术” 微信公众号。