BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

HTTPServerMock从手工到平台的演变

| 作者 李乐 关注 14 他的粉丝 发布于 2015年10月22日. 估计阅读时间: 42 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

不管是Web系统、还是移动APP,各自在与内部、外部系统之间进行数据交互时,大多数情况下都是依赖接口。在基于接口约定开发的模式下,依赖接口的产出时间如果延迟,将直接影响了整个研发调试的效率;如果不能对接口进行及早测试,那发现问题的时间就要被推迟了。既然双方约定了接口格式,为何不按照这个规范直接测试,何必在乎依赖接口什么时候产出,优先做到及早自测,后续只要替换接口联调通过即可。本文主要讲解基于HTTP协议的API接口模拟,从手工Mock到平台的演变过程。

遇到的困惑

曾经遇到的困扰:在研发过程中接口调试对接难的问题:

场景一:

【需求阶段】新功能开发,Portal依赖计费的接口,双方约定基于接口开发(内部、外部依赖接口场景均通用)

【开发阶段】Portal在开发进行中,计费尚未开发完毕,Portal迟迟不能与计费对接调试(也有可能版本迭代步伐不一致的情况),测试阶段一直被推迟;

另外,即使计费接口开发完毕,Portal需要修改计费约定的接口数据进行调试,当发现没有对方接口权限或者计费没有过多人力资源来配合时,也无法进入更丰富的数据细节调试;

【测试阶段】测试人员无法及早介入到调试阶段进行接口测试,造成发现缺陷的最佳时期被推迟;

场景二:

【需求阶段】Portal前、后端约定基于接口开发

【开发阶段】前端开发完毕,后端接口尚未开发完毕,前端只能硬编码数据进行测试,造成接口对接调试延后,而且每次进行更多场景的数据调试,需要频繁重启服务、本地部署;

研发自测阶段无法及早开展,依赖接口约束大。

场景三:

【需求阶段】移动APP项目依赖后端获取带宽数据的接口

【开发阶段】移动APP端通过后端系统API获取带宽数据,绘制带宽图,APP端绘图工具开发完毕,后端API带宽接口尚未开发完毕,移动APP端只能硬编码数据进行测试,造成对接延后,每次进行更丰富的数据调试,需要频繁重启服务、本地部署;

研发自测阶段无法及早开展,依赖接口约束大。

总而言之,如图所示:

依赖接口开发完毕,才能够进入到接口联调测试阶段,即使Portal的功能开发已经完成,也无法进行自测联调,消耗的等待时间代价是不可估量的,效率低,。

图-1-传统的接口对接调试流程

野蛮的石器时代:手工作坊-Nginx反向代理

要解决在研发过程中接口对接调试难的问题,无非是所需即所有,减少等待时间,增加研发自测环节,同时也让测试及早参与进来,因此需要能够把依赖接口模拟出来(白盒方面的Mock有许多解决方案,这里主要讲的是基于HTTP请求的API Server Mock),以便提高生产效率,改进流程如图所示:

图-2-改进的接口对接调试流程

当前最简单的想法是要解决:基于HTTP请求、固定url、能够正则匹配,在这个需求的驱动下,通过Nginx的反向代理能够解决问题。

匹配具体路径下某html文件

location ~ ^/live/(.*)\.html$ {
		   root /home/htmlfile/ms;
}
location ~ ^/live/([A-Z0-9]+)$ {       
}

定义具体返回码

location ~ ^/schedule/.*\.(json)$ {                
                error_page  404     /404.html;
 }

请求http://info.schedul.com/schedule/1234.json返回404。

定义其它状态码也是同样道理:

error_page 403 /error/403.html;
error_page 500 501 502 503 504 /error/500.html;

俗话说:术业有专攻,Nginx并不擅长做Mock API的工具,在管理配置文件即使可以通过svn进行管理,依然是维护比较困难,对于不熟悉Nginx的测试工程师,也有一定的学习成本。

拿来主义:不重复造轮子-开源WireMock

经历了Nginx的配置繁琐,决定另寻新路,有开源的WireMock(http://wiremock.org/):

Ø WireMock 是一个灵活的库,用于 Web 服务测试,和其他测试工具不同的是:WireMock 创建一个实际的 HTTP服务器来运行你的 Web 服务以方便测试;

Ø 支持 HTTP 响应存根、请求验证、代理/拦截、记录和回放;

创建一个基于WireMock的JavaProject(运行在tomcat下管理):

图-3-ServerMock Project

web.xml配置如下:

<?xml version="1.0" encoding="UTF-8"?> 
<web-app id="WebApp_9"
 version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"  
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
 http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> 
 <listener> 
 	<display-name>wiremock-startup-listener</display-name> 
	<listener-class>com.github.tomakehurst.wiremock.servlet.
                    WireMockWebContextListener</listener-class> 
  	<description>Loads WireMock and populates the servlet
                     context with its services</description> 
  </listener> 
  <context-param> 
  	<param-name>WireMockFileSourceRoot</param-name> 
  	<param-value>/WEB-INF/wiremock</param-value> 
  </context-param> 
  <context-param> 
    <param-name>verboseLoggingEnabled</param-name> 
    <param-value>false</param-value> 
  </context-param> 
  <servlet> 
  	<servlet-name>wiremock-mock-service-handler-servlet</servlet-name> 
	<servlet-class>com.github.tomakehurst.wiremock.jetty6.
                Jetty6HandlerDispatchingServlet</servlet-class> 
  	<init-param> 
  		<param-name>RequestHandlerClass</param-name> 
                <param-value>com.github.tomakehurst.wiremock.http.
                   StubRequestHandler</param-value> 
  	</init-param> 
  </servlet> 
  <servlet-mapping> 
  	<servlet-name>wiremock-mock-service-handler-servlet</servlet-name> 
  	<url-pattern>/*</url-pattern> 
  </servlet-mapping>   
  <servlet> 
  	<servlet-name>wiremock-admin-handler-servlet</servlet-name>  	
<servlet-class>com.github.tomakehurst.wiremock.jetty6. 
          Jetty6HandlerDispatchingServlet</servlet-class> 
  	<init-param> 
  		<param-name>RequestHandlerClass</param-name> 
                <param-value>com.github.tomakehurst.wiremock.http.
                         AdminRequestHandler</param-value> 
  	</init-param> 
  </servlet> 
  <servlet-mapping> 
  	<servlet-name>wiremock-admin-handler-servlet</servlet-name> 
  	<url-pattern>/__admin/*</url-pattern> 
  </servlet-mapping>    
  <welcome-file-list> 
  	<welcome-file>index.json</welcome-file> 
  	<welcome-file>index.xml</welcome-file> 
  	<welcome-file>index.html</welcome-file> 
  	<welcome-file>index.txt</welcome-file> 
  </welcome-file-list> 
  <mime-mapping> 
  	<extension>json</extension> 
  	<mime-type>application/json</mime-type> 
  </mime-mapping> 
  <mime-mapping> 
  	<extension>xml</extension> 
  	<mime-type>application/xml</mime-type> 
  </mime-mapping> 
  <mime-mapping> 
  	<extension>html</extension> 
  	<mime-type>text/html</mime-type> 
  </mime-mapping> 
  <mime-mapping> 
  	<extension>txt</extension> 
  	<mime-type>text/plain</mime-type> 
  </mime-mapping>  
</web-app> 

web.xml的这项配置可以改变源文件位置

<context-param> 
  	<param-name>WireMockFileSourceRoot</param-name> 
  	<param-value>/WEB-INF/wiremock</param-value> 
  </context-param> 

使用Maven管理依赖,配置如下:

<dependency>
    <groupId>com.github.tomakehurst</groupId>
    <artifactId>wiremock</artifactId>
    <version>1.53</version>
   <!-- Include everything below here if you have dependency conflicts -->
    <classifier>standalone</classifier>
    <exclusions>
        <exclusion>
          <groupId>org.mortbay.jetty</groupId>
          <artifactId>jetty</artifactId>
        </exclusion>
        <exclusion>
          <groupId>com.google.guava</groupId>
          <artifactId>guava</artifactId>
        </exclusion>
        <exclusion>
          <groupId>com.fasterxml.jackson.core</groupId>
          <artifactId>jackson-core</artifactId>
        </exclusion>
        <exclusion>
          <groupId>com.fasterxml.jackson.core</groupId>
          <artifactId>jackson-annotations</artifactId>
        </exclusion>
        <exclusion>
          <groupId>com.fasterxml.jackson.core</groupId>
          <artifactId>jackson-databind</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.apache.httpcomponents</groupId>
          <artifactId>httpclient</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.skyscreamer</groupId>
          <artifactId>jsonassert</artifactId>
        </exclusion>
        <exclusion>
          <groupId>xmlunit</groupId>
          <artifactId>xmlunit</artifactId>
        </exclusion>
        <exclusion>
          <groupId>com.jayway.jsonpath</groupId>
          <artifactId>json-path</artifactId>
        </exclusion>
        <exclusion>
          <groupId>net.sf.jopt-simple</groupId>
          <artifactId>jopt-simple</artifactId>
        </exclusion>
     </exclusions></dependency>

具体的部署这里就不介绍了,说说WireMock的配置:

Ø WireMock的文件目录

如图所示:

mappings:存放映射描述的文件

__files:存放映射匹配结果的文件

图-4-WireMock的文件目录

WireMock的匹配规则示例

分两种:完整Url匹配和正则UrlPattern

Url:完全匹配

mappings:cities-mapping.json

{        
    "request": {                                    
        "method": "GET",                        
        "url": "/cities"
    },                                      
    "response": {                                   
        "status": 200,                          
        "bodyFileName": "/cities.json",
        "headers": {
            "Content-Type": "application/json",
            "Cache-Control": "max-age=86400"
        }
    }                                               
}

__files:cities.json

{
    "cityName": "公司操作间",
    "shortname": "WS",
    "provinceName": "北京",
    "provinceNameEn": "BeiJing City",
    "code": "0001",
    "cityNameEn": "Workshop"
  }

UrlPattern:正则匹配任何6位数的,例如:/customer/123456/

mappings:cities-mapping.json

{        
    "request": {                                    
        "method": "GET",                        
        "urlPattern": "/customer/[0-9]{6}/"
    },                                      
    "response": {                                   
        "status": 200,                          
        "bodyFileName": "/customer.json",
        "headers": {
            "Content-Type": "application/json",
            "Cache-Control": "max-age=86400"
        }
    }                                               
}

__files:customer.json

{
  "channels": [],
  "code": "781",
  "companyName": "",
  "enable": true,
  "name": "163",
  "password": "CC@ne.com",
  "userState": "COMMERCIAL"
}

自给自足:平台化

使用WireMock通过mappings和__files文件夹可以有效管理映射和返回内容文件,但是所有文件的有部分可抽取未固定模板,而这些部分目前是手动编辑,关注这些部分会分散业务的精力,如果可以做成平台化管理,所有接口通过创建完成,文件命名规则全部由系统进行管理,将节省的时间更多投入业务关注和及早进行自测,这样子的收益将会更大。

那怎么样的平台才算能够满足当前需求呢?

  • 基于HTTP协议
  • 支持Url、UrlPattern匹配
  • 支持数据存储
  • API接口规范化管理
  • 提交表单即可生成mapping和__files所需文件
  • 不同项目接口有不同的前缀
  • 能够返回指定格式(json|xml|文本)内容

图-4-ServerMock-v1.0-架构图

根据架构图,做了总体规划如下:

(点击放大图像)

图-5-ServerMock-v1.0规划

技术选型

由于原来的测试平台使用Python编写,为了保持风格一致,从界面录入到文件生成处理依然采用Python,后台工具使用WireMock的standalone模式,通过shell脚本进行一键启停管理,以及实时刷新url、mapping映射;

HTTP API Mock项目管理Web前台

使用Python+Django+MySQL进行开发,分为项目配置和接口配置两大部分。

项目配置页

介绍:配置协议、进行mock服务器的重启、重新加载(有新的接口文件生成系统会自动reset即可,当然手工reset也可以,即时加载无须重启服务等待)。

图-6-项目配置页

接口列表页

介绍:展示列表,列出相关URL、方法、是否正则、返回码、返回类型。

图-7-接口列表页

接口配置页

介绍:选择方法、URL类型,填写URL(如果选择URL类型为UrlPattern,则填写正则表达式),填写状态码、返回接口,以及返回头,就可以完成一个mock接口的创建。

图-8-接口配置页

接口配置有三种输入形式:

直接输入返回结果

(点击放大图像)

图-9-手工输入

一般场景在返回结果500k以内的内容,可以直接输入,保存进入数据库;

通过url抓取返回结果

图-10-url抓取

一般场景在返回结果超过500k以上内容,目标Mock接口已经存在,可以直接抓取生成文件;

通过文件上传返回结果

图-11-上传文件

一般场景在返回结果比较大|目标Mock接口还未开发完成,手工上传返回内容的文件即可。

以上三种灵活的保存返回内容方式,最终保存的接口会按照以下格式生成mapping和__files所需文件:

图-12-mapping和__files文件格式

Mock项目管理Server后台

使用Java-WireMock进行后台服务,在项目配置页通过按钮:重启、重新加载,调用后台脚本:wiremock_controller.sh,仅供参考:

#!/bin/bash
if [ "$#" = 0 ];then
    echo "Usage: $0 (start|stop|restart|reset)"
    exit 1
fi

dirWiremock=`pwd`
getCount=`ps -ef | grep "wiremock-1.53-standalone" | grep -v "grep" |wc -l`
wiremock_jar=${dirWiremock}/wiremock-1.53-standalone.jar
port=9999
wiremock_url=http://localhost:${port}

stop(){
    count=${getCount}
    if [ 1==${count} ];then
	curl -d log=aaa ${wiremock_url}/__admin/shutdown
	echo "Stop success!......"
    else
        echo "Already stop"
    fi
}

start(){
    count=${getCount}
    if [ 0==${count} ];then
       nohup java -jar ${wiremock_jar} --verbose=true --port=${port} &    
       echo "Start success!......"
    else
        echo "Already start"
    fi
}

if [ "$1" = "restart" ];then
    count=${getCount}
    if [ 1==${count} ];then
          echo "Wiremock is running,wait for restarting! ...."
          stop  
          echo "Start wiremock......"
          start  
    else
        start
    fi

elif [ "$1" = "start" ];then
        echo "Start wiremock......"
        start

elif [ "$1" = "stop" ];then
        echo "Stop wiremock......"
        stop

elif [ "$1" = "reset" ];then
    count=${getCount}
    if [ 0==${count} ];then
          echo "Wiremock must be running before reset,wait for starting! ...."
          start
    fi
        curl -d log=aaa  ${wiremock_url}/__admin/mappings/reset
	echo "Reset success!......"
fi

其中:

“nohup java -jar ${wiremock_jar} --verbose=true --port=${port} &”:在linux系统后台运行WireMock;

“curl -d log=aaa ${wiremock_url}/__admin/mappings/reset”:是通过发送POST请求,重新加载新生成的配置文件,在WireMock的源码中可以看到:reset的作用:

public interface Admin {
	void addStubMapping(StubMapping stubMapping);
    ListStubMappingsResult listAllStubMappings();
    void saveMappings();
	void resetMappings();
	void resetScenarios();
    void resetToDefaultMappings();
	VerificationResult countRequestsMatching(RequestPattern requestPattern);
    FindRequestsResult findRequestsMatching(RequestPattern requestPattern);
	void updateGlobalSettings(GlobalSettings settings);
    void addSocketAcceptDelay(RequestDelaySpec spec);
    void shutdownServer();
}

通过一系列源码追溯,可以找到重置:

@Override
	public void reset() {
		mappings.clear();
        scenarioMap.clear();
	}

可以推测映射文件是存放到列表的:

public class SortedConcurrentMappingSet implements Iterable<StubMapping>{

	private AtomicLong insertionCount;
	private ConcurrentSkipListSet<StubMapping> mappingSet;
......
}

当WireMock启动,日志有以下描述:

2015-02-12 11:38:37.844 Verbose logging enabled
2015-02-12 11:38:38.657:INFO::Logging to STDERR via wiremock.org.mortbay.log.StdErrLog
2015-02-12 11:38:38.664 Verbose logging enabled
 /$$      /$$ /$$                     /$$      /$$                     /$$      
| $$  /$ | $$|__/                    | $$$    /$$$                    | $$      
| $$ /$$$| $$ /$$  /$$$$$$   /$$$$$$ | $$$$  /$$$$  /$$$$$$   /$$$$$$$| $$   /$$
| $$/$$ $$ $$| $$ /$$__  $$ /$$__  $$| $$ $$/$$ $$ /$$__  $$ /$$_____/| $$  /$$/
| $$$$_  $$$$| $$| $$  \__/| $$$$$$$$| $$  $$$| $$| $$  \ $$| $$      | $$$$$$/ 
| $$$/ \  $$$| $$| $$      | $$_____/| $$\  $ | $$| $$  | $$| $$      | $$_  $$ 
| $$/   \  $$| $$| $$      |  $$$$$$$| $$ \/  | $$|  $$$$$$/|  $$$$$$$| $$ \  $$
|__/     \__/|__/|__/       \_______/|__/     |__/ \______/  \_______/|__/  \__/

port:                         9999
enable-browser-proxying:      false
no-request-journal:           false
verbose:                      true

图-13-WireMock启动

成功处理请求的日志:

2015-02-12 11:41:10.320 Received request: GET /test/today/dkfDF123/1234/ HTTP/1.1
Host: 192.168.32.55:9999
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: csrftoken=alXbvCtMyTBI1wnSnRoljguTaBnTDbPo; sessionid=tvoi9rzs66umnt1a26wsj36eqry2e2lo
Connection: keep-alive

总结

HTTP API接口测试痛点是什么?很多公司划分不同研发组,各组系统之间的数据交互通过接口来实现,那很多时候就是集中在接口开发不同步,测试无法及早参与,对接调试难的问题。或许很多团队遇到这种问题,就是选择同步开发或者等待。当你选择等待的时候,你的产品质量就得不到及时验证,因为根本没有测试过,在当前快速迭代的开发模式中,时间是最致命的要素,如果不能及时交付,交付的质量又得不到保证,那是相当被动的局面,最后返工的成本比你当时愿意追加测试的成本会来的更高。

遇到这类问题是想办法解决,而不是回避,我们可以借鉴《自动化单元测试实践之路》在单元测试中,使用Mockito对依赖进行Mock,那同样道理,使用Mock技术也可以对HTTP API进行Mock,按照这个思路探索下去,看看有没有开源解决方案,是否能够解决当前问题,如果可以就不用重复写一套解决方案;如果不行,那能否基于开源的做二次开发呢?当团队经历过测试痛点,调研收集了一定的数据,这些问题的答案就会浮出水面了。

或许有人要问,使用之后能够提高多少效率呢?看回《图-2-改进的接口对接调试流程》,根据我们的经验,要统计当前迭代中有多少API需要对接调试,如果对比旧的模式来说,API接口调试效率提升至少有10%;可想而知,迭代中全是依赖API接口开发的话,那提升的效率就相当可贵了。

作者简介

李乐,测试经理,8年以上工作经验,目前就职于ChinaCache质量部,博客:jooben.blog.51cto.com,微博:weibo.com/iamlile


感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群InfoQ好读者)。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

赞! by 林 城城

在这浮躁的行业状态下,能在测试领域做出探索性创新和解决方案,实属不易!

看看moco by X Ray

文章中的好几张图都裂了 by Jiang hk

文章中的好几张图都裂了

Re: 文章中的好几张图都裂了 by li le

infoq通知已经修复

by 李 智

二次开发代码有木有开源

赞赞赞 by 王 瑾

文章中的图都看不到

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

6 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT