API 测试工具 Hitchhiker 0.1.2 发布,增强体验 - 开源中国社区
API 测试工具 Hitchhiker 0.1.2 发布,增强体验
不白兄 2017年09月11日

API 测试工具 Hitchhiker 0.1.2 发布,增强体验

不白兄 不白兄 发布于2017年09月11日 收藏 45

腾讯云 十分钟定制你的第一个小程序>>>  

在线体验: http://www.hitchhiker-api.com/, 可以用 `try without login` 来免登录使用。

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

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就可以了,系统根据参数自动生成多个请求。

GitHub: https://github.com/brookshi/Hitchhiker

码云:https://gitee.com/iwxiaot/Hitchhiker

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:API 测试工具 Hitchhiker 0.1.2 发布,增强体验
分享
评论(9)
最新评论
0

引用来自“sdvdxl”的评论

用这个 https://getgauge.io/ 比较好

引用来自“不白兄”的评论

谢谢推荐,官网看了下,这个工具思想挺好的,不过看起来它更倾向于做单元测试做的事,有自己的语法加上对原代码略有侵略性,感觉复杂了点
跟源代码没关系,这个可以做你想做的,单元测试也行,api测试也行,tcp啥的都行,可以单独搞一个项目,而不跟原项目耦合
0

引用来自“sdvdxl”的评论

用这个 https://getgauge.io/ 比较好
谢谢推荐,官网看了下,这个工具思想挺好的,不过看起来它更倾向于做单元测试做的事,有自己的语法加上对原代码略有侵略性,感觉复杂了点
0
用这个 https://getgauge.io/ 比较好
0

引用来自“布尔值”的评论

又造了个轮子,唉.说下我的想法.
这工具做调试工具还可以,但是做测试工具(自动化测试)还不行.
1,如果postman开源了,这个东西分分钟完蛋.差距不是1点2点.
2,跟postman一样不满足测试工具的必要条件
1)接口请求往往串行相关(要传值)
2)有些脚本要公用(要有公用机制)
3)公用请求头(全局性的)
4)请求会膨胀(就如角色A添加,角色B查询=>导致到处是登陆脚本.)
5)没有测试用例的概念(怎么多人协作!?)
感觉跟着postman走,会走错路的.

非常感谢你的建议 :+1:,不过还是要说明下:
1,如果postman开源了,这个东西分分钟完蛋.差距不是1点2点.
* postman是商业工具,会放弃收入来开源?目前虽然有差距,但也并非那么大
2,跟postman一样不满足测试工具的必要条件
1)接口请求往往串行相关(要传值)
* 我这个是支持运行时变量的,跑schedule时可以串行跑,前面定义变量给后面用
2)有些脚本要公用(要有公用机制)
* 上面文章上说了这次的更新加入了global function
3)公用请求头(全局性的)
* 全局性的请求头会引入一些麻烦,比如某个api不想要这个头,想去掉反而不便,另外api也显得不直观。所以引入了收藏,收藏后在其他地方一点就可以用。
4)请求会膨胀(就如角色A添加,角色B查询=>导致到处是登陆脚本.)
* 这个是不需要登录脚本的,请求一次cookie后,cookie会记下,同一host或collection下的都会自动用这个cookie
5)没有测试用例的概念(怎么多人协作!?)
* 概念不同而已,一个Request就表示一个测试用例了,多人协作是指可以多人一起维护同一Project下的Collection,当然现在的多人协作还不完善,后续会加上定时自动更新及提示

postman既然能做到这个市场是有一定道理的,不是所有工具都想一统,覆盖到某些场景就可以了。
0

引用来自“绿薯”的评论

很给力.能把react 和nodejs 写得那么好的开源很少了.
谢谢
0

引用来自“今天星期一”的评论

postman ?
样子是很像了
0
又造了个轮子,唉.说下我的想法.
这工具做调试工具还可以,但是做测试工具(自动化测试)还不行.
1,如果postman开源了,这个东西分分钟完蛋.差距不是1点2点.
2,跟postman一样不满足测试工具的必要条件
1)接口请求往往串行相关(要传值)
2)有些脚本要公用(要有公用机制)
3)公用请求头(全局性的)
4)请求会膨胀(就如角色A添加,角色B查询=>导致到处是登陆脚本.)
5)没有测试用例的概念(怎么多人协作!?)
感觉跟着postman走,会走错路的.

0
很给力.能把react 和nodejs 写得那么好的开源很少了.
0
postman ?
顶部