开源 基于Nodejs的Api 测试工具 - 更新 v0.4,支持Pre Request Script及require任何上传的脚本
发布于 3 个月前 作者 brookshi 2132 次浏览 最后一次编辑是 9 天前 来自 分享

Github: https://github.com/brookshi/Hitchhiker/ 觉得不错的话麻烦 Star 支持下,谢谢。

在线体验: http://www.hitchhiker-api.com/ 可以用 try without login 来免登录使用。(在线演示不支持压力测试及上传js,虚拟机单核的,撑不住)。

v0.4

Pre Request Script

这个算是之前就想实现的,拖了会,不过也是有朋友在github里的issue里提出,正好促使我完成这个功能。 在Pre Request Script里写的脚本会在请求发送前执行,这就使得可以在请求发送前处理一些事情,比如生成一个md5给请求使用,或者读取文件内容,再或者在请求前先请求一个数据,把这个数据做为变量给现在的请求使用,可以做的事有很多,发挥的余地很大。

现在在脚本里可以使用的方法有:

require             // 这个做js的都懂,有了这个就有无限可能,内置了'lodash', 'request', 'cypro-js'等库,重要的是支持上传js库
readFile            // 读取文件
readFileByReader    // 使用自定义的方法读取文件,比如读取excel
saveFile            // 保存文件
removeFile          // 删除文件
setEnvVariable      // 设置环境变量
getEnvVariable      // 获取环境变量
removeEnvVariable   // 删除环境变量
environment         // 获取当前环境的名字

当然上面的函数同样可以在Test中使用,下面这些只在Test里支持:

responseBody
responseObj
responseHeaders
responseTime
responseCode.code
responseCode.name 

项目文件夹

对每个项目来说都有一个data文件夹和一个lib文件夹。 data文件夹用于上传一些测试所需要的数据,可以是任何格式,只要你能读取。 lib文件夹则用于上传一些js库,需要先压缩成zip格式,上传后会自动解压。 然后在脚本里就可以通过 readFile 读取 data文件夹下的文件,或者通过 saveFile保存文件到这个文件夹。 同样可以在脚本通过require来引用上传的js库,然后使用它。

除了项目文件夹外其实还有一个全局的文件夹,这个文件夹可以放一些全局的js库或数据,比如已经内置了一些常用的js库:uuidlodash等。

schedule支持以小时或分钟为单位

这个算是呼声比较高的,之前只是做到按天来跑schedule,后来收到不少这方面的需求,所以增加了以小时或分钟为单位的schedule。

支持自定义邮件发送接口

这个也算是刚需了,因为很多公司会过滤一些来源不明的邮件,所以 Hitchhiker发出的邮件很可能会收不到,现在增加了一个自定义的邮件接口,Hitchhiker会把数据post到这个接口上,就可以使用公司的邮箱来接发邮箱了。

开放schedule的run now接口以便其他程序调用

有朋友表示想在Jenkins里调用Schedule的Run接口,这是个好方法,所以开放了这个接口出来,方便其他程序调用。

Bug fix

  • schedule的顺序执行无效
  • sync有时会覆盖用户已经更改的数据
  • sync时环境变量编辑对应框里的内容会被清掉

v0.3

这次发布主要增加一个增强协作的功能 - 自动同步更新:

我们写code时通常会用git或svn等工具来协同工作,但是Api case也用这种方式的话就显得有点麻烦了,一个接口的属性毕竟就那个几个,没必要修改前fetch & rebase,修改后还要push,Api的协作应该更简单,相信很多人用过Atlassian的wiki,我们在编辑文档的时候常常会收到提醒:某某更改了此文档,是否合并 之类,API的协作也应该这样,简单方便,所以就有这次的更新:

默认每30s会同步一次,有三种表现:

  1. 本地没有修改的API,这时数据会自动更新。
  2. 本地编辑过的,也就是tab上显示上红点的,这时如果别人更改了API,数据同步后tab里仍会保持编辑的数据,但是会提示些API有人更改过,可以view changes来看是被谁改了些什么,然后决定是否覆盖或放弃本地内容。
  3. 远程上面被删除的,同步会提示此API已经被删除掉了,也就是说再在上面更改已经没有意义,可以关掉此API了。

下面的图片展示了同步过程:

  1. 首先有两个人在同时维护,左边一个(chrome),右边一个(firefox),可以看到左边建立了一个Collection和一个request,右边马上得到了更新。
  2. 然后左边更改了url,在后面加上?a=A,同时右边也做了更改,在url后面加上了?b=B并保存,这时左边得到了case被改的提示,view changes看了更改的内容,选择了覆盖,所以右边的也同步成?a=A了。
  3. 左边把case删掉,右边得到case被删的提示。

图中的时间间隔设为了5秒,所以会比较快

其他改动

  1. Url Query支持中文

后续计划

下个版本的目标是 pre request script以及项目folder,实现初始变量数据源以及在脚本中保存或打开文件的功能,可以借此来实现动态参数输入源

v0.2

这次发布的算是一个大版本,主要增加一个重磅功能 - 压力测试:

双11快到了,经常会有整点秒杀的活动,秒杀就是一个典型的压力场景,所以建了一个简单的Case来表现这种场景,来展示Hitchhiker压力测试功能:

Hitchhiker使用一个基于Golang的分布式压力节点,这是一个单独的项目:Hitchhiker-Node。得益于Golang的交叉编译,轻松跨平台生成文件,所以只有一个可执行文件和一个配置文件,没有环境依赖,直接执行。

使用时在release页面先选择对应平台的zip文件下载下来,解压后会有两个文件,一个可执行文件和一个配置文件config.json,打开配置文件,把Address的值从localhost改为部署Hitchhiker机器的ip,然后再执行Hitchhiker-Node文件,这样就弄好了一个压力点。

如果想压出很大的请求就可以考虑部署到多台机器上,Hitchhiker会自动根据机器的CPU核数来分配任务,当然,一般情况下直接部署到Hitchhiker同一台机器就够用了。

压力测试用的也是CollectionRequest,可以选择性的挑出合适的Request用来做Case,压力测试的参数有:

  • Repeat: 运行整套请求的次数
  • Concurrency: 并发个数
  • QPS: 1秒内限制单个节点请求的个数,默认为0,即没有限制
  • Timeout: 请求的超时时间设置,单位为秒,默认为0,即没有超时设置
  • Keeplive: 设置请求是否使用Keeplive

运行压力测试任务时会实时显示运行状态,包括节点的状态(闪烁表示正在工作),当前任务及任务的数量,下方有三个图表,分别表示

  1. 当前的运行进度,包括完成的数量及TPS
  2. 各个Request的请求消耗时间,包括 DNS, Connect, Request, Min, Max 这五个
  3. 请求失败的状态,包括 No Response, Server Error(500), Test失败 这三种情况

其他改动

  1. 源码部署时支持改端口,之前固定用的8080,要改需要改js文件,现在只需在部署文件时改就好了。

  2. 改正Schedule空跑时的异常。

后续计划

压力测试在国庆后总算做出来,后来又花了一些时间来测试,0.2这个版本算是告一段落。 接下来版本计划要改下,涉及新功能的都是大版本,bug是小版本。 下个模块功能是支持API文档,希望能是一个自定义的,所见即所得,支持导出常用格式的API文档系统。 小功能和bug会持续改进。

v0.1.3

这次版本主要增加一个重磅功能 - 参数化请求:

参数化请求

什么是参数化请求,就是把一个Api里可变的点提取出来,参数化,这样就可以用一个Case覆盖到所有可变请求。

参考下图(比较大,可能会比较慢出来):parameters就是用来构建参数化请求的,请求通常有很多参数,比如query string, body里的变化点等,这些参数可能会有不止一个值,每个都要覆盖的话需要写很多request。

举个例子:比如一个request有三个可变的参数A, B, C,每个参数又分别有3个值,A的1,2,3, B的4,5,6, C的7,8,9,这样随机组合下来会有3*3*3=27个request:

147 148 148 157 158 159 167 168 169
247 248 248 257 258 259 267 268 269
347 348 348 357 358 359 367 368 369

很麻烦有没有,如果再多两个参数呢,轻松过百了呀,想想都头大,但其实它们之间只是一点不同,何必要费这么大劲呢,参数化请求可以帮你做这个事,只需要把可变的参数写在parameter里面,Hitchhiker会自动构建出所有request。

parameters有两种组合方式,一种是所有组合Many to Many,另一种是一对一组合One to One,上面生个27个request的就是ManytoMany,如果用一对一组合的话就只有3个,分别是:147, 258, 369

Parameters的格式是一个json对象,对象的下一层是变量以及它的值:数组。看个例子:

{
    "A": [1, 2, 3],
    "B": [3, 4, 5], 
    "C": [7, 8, 9]
}

使用的方式同变量一样,用{{}}包起来。

下图就展示了参数化请求的使用方式,可变的三个参数namepwdagename有两个值:tomjerrypwd有两个值:123456age也是两个值:2018,使用OnetoOne时会生成两个请求:name:tom, pwd:123, age:20name:jerry, pwd:456, age:18,一一对应的,可以分别请求,也可以一起请求。 如果选了ManytoMany就会有8个请求,这里就不一一列举出来。 参数化请求的request保存后左边对应的item里会显示出请求的真正个数,如图中的8。 参数化请求跑schedule一样没问题,会自动拆分开跑和显示。

大图:右键新标签打开图片

处理对比数据

Hitchhiker的一个重要功能就是可以对比不同环境的返回数据,之前是直接对比response,但实际上往往想要对比的是其中一部分或去掉可变部分,考虑一种情况,返回的response里带有一个当前时间,也就表示每次返回的数据都是不同的,因为时间肯定不一样,这样就影响了对比结果,但是这个时间没什么对比意义,所以我们需要在对比前把它去掉,这时可以用这个功能了。

具体用法:在test里用js处理responseObj,然后用$export$(data)函数导出处理后的数据(data就是处理后的数据),然后跑schedule时就会用导出的数据进行对比了。

默认Headers

之前有加一个header收藏功能,方便使用一些常用的header,但是有些server会校验一些请求头,比如Accept,UserAgent等,这个是每个请求都需要带的,每个request都写也有些麻烦,现在可以配置一些默认header,这些header可以在根目录下的appconfig.json里配置,默认定义的是这些:

"defaultHeaders": [
    "Accept:*/*",
    "User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36",
    "Cache-Control:no-cache"
]

可以根据需要自行修改。

后续计划

本来的计划是两周一版本,其中一周做小版本的新功能和改bug,另一周做大版本的压力测试。不过这次参数化请求比预想的要麻烦些,上面两周时间基本都花这上面了,压力测试这块就没进展,下两周除了改bug外就全力做压力测试这块,希望国庆过后能做到差不多。

Github: https://github.com/brookshi/Hitchhiker, 觉得不错的话麻烦 Star 支持下,谢谢。

v0.1.2

这次版本主要是增加一些体验方面的更新:

request的header提示及自动完成

request的header种类基本就那些,但纯靠手写有时会写错,导致请求不到数据,很麻烦。于是把常用header加到自动提示里面,方便使用。

header的收藏功能

一个项目的request的header其实用来用去都是那几个,每个request都去写这些重复的即使有提示也显得麻烦,这时可以添加到收藏,下次再用直接选进来就可以了。(可以右键选新标签中打开图片,看起来清楚些)

tests的全局函数

很多request的tests里会用到同样功能的函数,每个都写的话麻烦不说,维护起来也不方便,考虑像写代码一样,应该提取共同部分,所以增加了一个全局脚本,可以在Project里定义,其下的Request可以直接使用。

清除本地Cache功能

Hitchhiker会把用户所有的更改都记在浏览器的indexDB中,但有时会有一些情况比如说想放弃所有更改,可以清除本地cache,所有数据全部用最新的数据库里的。

UI调整

主要是字体改了,之前统一用的adobe开源的一款SourceCodePro字体,因为是等宽字体,有朋友反应说看起来不舒服,想想有道理,所以把除了代码之外的都使用系统字体,看起来紧凑点。

后续计划

0.2大版本的分布式压力测试还是开发中,测试tool用go写的,代码基本差不多,接下来主要是通信方面。

0.1.3小版本的主要还是小功能和体验上的改进,计划引入一个比较有用的新功能:参数化请求,因为很多需要测试的api大体上差不多,只是query或者body里变了一点,如果重复添加request的话显得麻烦且维护不便,参数化可以把这些变化封装到参数里,一个request就可以了,系统根据参数自动生成多个请求。


v0.1.1

Hitchhiker 是一款开源的 Restful Api 集成测试工具,你可以在轻松部署到本地,和你的team成员一起协作管理Api。

先上图看看:

https://github.com/brookshi/Hitchhiker/raw/master/doc/images/collection.png

https://github.com/brookshi/Hitchhiker/raw/master/doc/images/history.png

https://github.com/brookshi/Hitchhiker/raw/master/doc/images/env.png

https://github.com/brookshi/Hitchhiker/raw/master/doc/images/schedule.png

能做什么

  • Team协作开发Api

  • Api历史修改记录及支持diff展示

  • 支持多环境变量及运行时变量

  • 支持Schedule及批量run

  • 不同环境下的请求数据对比 (eg: stage vs product)

  • 易部署 (支持 docker, windows, linux), 数据都存在自己这里,不会上传及丢失

  • 会记往任何修改,不用怕没保存时session失效或系统重启

  • 支持导入Postman v1 collections

  • 性能测试 (开发中…)

  • Api文档 (计划中…)

如何部署

首推使用 docker 部署,简单快捷,具体操作参考 deploy with docker

如果没有docker环境也可以使用源码部署,也很简单

linux 请参考 deploy to linux

windows 请参考 deploy to win

如何使用

参考 使用说明

用到的技术

前后端分离,前端采用 React + Redux + AntDesign,后端基于 Nodejs, 采用 Koajs + TypeORM + MySQL。

语言统一用的 Typescript。

测试的话,前端用Jest,覆盖了逻辑最多的 reducer,后端使用的就是本工具来测试自己,这对时间有限的我来说算是最有性价比的选择。

开源

可以访问 http://www.hitchhiker-api.com/ 来使用,点击 try without login 免注册登录,另外,为了免备案,服务器在海外的,所以速度上可能会有点慢,抽疯时甚至可能访问不了,请谅解。

当然最好还是在本地局域网部署,用起来会比较爽。

Github: https://github.com/brookshi/Hitchhiker, 觉得不错的话麻烦 Star 支持下,谢谢。

17 回复

看起来不错的样子

先mark

来自酷炫的 CNodeMD

更新 v0.1.2

@yuu2lee4 暂时可以认为是实现了一部分postman pro功能的内部部署版

@i5ting 谢谢狼叔支持

更新 v0.1.3

不错不错,挺感兴趣的,可以加入参与一起开发吗?

@luluzero 当然可以,可以先看下源码看看有兴趣不

更新 v0.2, 压力测试

很好。没明白

Hitchhiker使用一个基于Golang的分布式压力节点,这是一个单独的项目:Hitchhiker-Node。得益于Golang的交叉编译,轻松跨平台生成文件,所以只有一个可执行文件和一个配置文件,没有环境依赖,直接执行。

是说测试的请求都是通过这个golang的程序发起的吗?

@stonephp 是的,压力测试的请求是由golang程序发起来的

更新 v0.3, 自动同步更新

更新 v0.4, 超强脚本

回到顶部