开源测试工具 强大的 API 测试工具 Hitchhiker v0.9 基于 UI 的断言测试，回顾 2017
v0.9 是 Hitchhiker 在 2017 农历年的最后一个版本，而起点正是刚过完 2016 农历年，农历 2018 即将到来，一年轮回，今天写点东西稍微回顾下 hitchhiker 的 2017。
先还是说 v0.9，这次版本发布主要带来一个新的辅助测试功能：免脚本的断言测试，这是一个携程的朋友提出来的需求。
之前 Hitchhiker 支持在 test 脚本里写 tests['assert'] = value 这样来断言，但很多 QA 其实并不会编程，或者会其他语言但对 js 不熟，这样断言写起来就不太方便，所以这次应朋友的需求加了这个功能：
上面动图已经展示了功能和用法，具体就不多说了。
回头看下 Hitchhiker 的 2017，一年过来，对这个项目来说结果还不错，大小版本发了 14 个，github 上有了 1k+ 的 star，我也因此认识了一些朋友，对技术上有也不少提升，总体看对我来说是成功了。
https://github.com/brookshi/Hitchhiker
起初，大概是 2016 年年中，我开始负责公司一个 API 项目，因为是金融公司，对数据准确性要求很高，所以产生想法，做一个工具来辅助这个 API 项目的测试，减少沟通成本以及 QA 做 regression 时的压力。后面准备了下，在 2016 年农历年后，也就是 17 年的 3 月份，正式开始编码实现功能。
由于不懂设计，所以 UI 上参考了比较熟悉的一个成名已久的测试工具：Postman，这也导致：即使后来除了 UI 外，实现了很多 Postman 没有的功能也还是摆脱不了 Postman 的影子，不少人一看跟 Postman 一样，觉得没有意义，在这点上算是一个败笔。不过也因为类 Postman UI 的易用性，让使用 Hitchhiker 的人很容易上手，这又是一大优势，算是两者抵消吧。
当时，想要通过这个工具解决的问题只有 2 个：
减少开发的沟通成本，原因是我们的 API 是面向用户的，依赖公司其他 Team 的众多 API，我们写一个接口可能要调用公司好几个 API 才能整合出想要的数据，这就需要开发去和好几个 team 打交道，沟通成本很大。而如果要所有开发都做一遍同样的事情，浪费的时间可想而知。
减少浪费 QA 人力做无聊的数据对比，这个算是自动化的一部分，上面说了，金融数据的准确性是非常关键的，我们的产品又是直面用户的，有问题第一个找到我们头上，所以 QA 在这方面也非常头痛，以往都是依赖人眼去对比线上和 UAT 两个版本的报表是否匹配，容易疏忽不说，时间有效的情况下，覆盖率也很难达到要求，且对 QA 来说，这类事情是最应该自动化的。
解决这 2 个问题的方案是：
很多工具需要互相 share，有更新就 share 的话也很麻烦。 Hitchhiker 支持多人同时在线维护同一份 API，支持实时更新，一个开发在完成沟通后，把依赖的 API 都整理在一起，写好 case，其他开发就可以直接借鉴使用了，只花一个人的时间，成果所有开发共享。
使用 Schedule 来实现 Case 的自动化运行，以及用脚本做断言来判断数据是否正确，但金融数据上经常有动态值，比如求上个月的回报，对今天来说，上个月是 1 月，但过一个月后，上个月就是 2 月了，数据很可能就不一样了，所以对这类动态值用断言方式很难解决，Hitchhiker 支持在做自动化测试时对比不同环境的数据，我们以线上的数据为准的话就可以知道没上线环境的 API 运行是否正常了。
这两个功能在 17 年 7 月左右先后实现，我的 API 项目的接口测试也陆续加了进去，基本上满足了需求。
由于项目的 API 的并发量比较大，在服务器有限的情况下，需要尽量提前优化来提高吞吐，避免上线后出问题，所以需要在测试阶段给到服务器压力，然后在 10 月份时用 Go 语言为 Hitchhiker 实现了压力测试。
在 0.5 版本时用 gitbook 重写了文档： Hitchhiker 使用文档
接下来的一个版本又大幅加强了脚本功能，支持 require，支持上传脚本库和数据文件，标志着 NPM 里几十万的 js 库尽可以拿来用了。
不过可惜的是基于 Go 语言写的压力测试由于对 js 支持有限，不得不放弃，转而使用 Node 重写了一份压力测试的功能并在 v0.6 版本上线。
其实到这时为止，Hitchhiker 已经满足我的 API 项目的需求了，但随着使用者越来越多，需求不断出现，后续的版本基本都在实现这些需求了：
v0.7：支持自定义 smtp，为请求生成各种语言的 code，schedule 数据不同时的 diff 展示
v0.8: 自动化测试结果统计
v0.9: 基于 UI 的断言测试
还有很多功能想要实现，文档，Mock，管理平台等等，将会在接下来的 2018 里陆续实现。
在线体验： http://www.hitchhiker-api.com/， 可以用 try without login 来免登录使用（在线演示不支持压力测试和上传 js 库，虚拟机单核的，撑不住）。
pre requestScript 参数预处理，简单写了下用法，可以参考https://testerhome.com/topics/11971
wholegale39
回复
是的，set 之后才能使用，parameters 的概念可能确实和其他的不一样，具体可以参考下文档的 parameters 的部分 : http://doc.hitchhiker-api.com/cn/Variable/Param_Var.html
wholegale39
回复
脚本没错，最后的 sign 需要 toString() 一下，因为它是个对象
另外看起来你只是想用变量，这样不一定需要在 Parameters 里写，直接写在要用的地方就好。
如果用在 Parameter 里，最好用不同的名字，比如你两个都是 sign，这样系统不能分辨指变量还是 parameter
目标值不确定的话可以用 console.log 打出来，在浏览器的 F12 里可以看
debugtalk
回复
是啊，快快弄好 httprunner 有人扒了 Locust https://testerhome.com/topics/11853 的新衣，性能请求不足，您老怎么看。
赞！我要好好学习下，HttpRunner 的中文使用文档也得抓紧了
看到前面以为完全就是 postman，看到下面。。。碉堡，点个赞
Brook Shi
回复
1 是否支持同步， HITCHHIKER_SYNC_ONOFF 同步什么内容，和谁同步？ docker 镜像里 是否开启同步了？ 怎么查 docker 镜像中配置的环境变量？
2 "api": "http://ip:port/api/", // API 接口，调试用， 环境变量使用上面的 这个具体怎么用 后边接哪些 去哪查？
3 "safeVM": false, // 是否使用安全脚本，如 require HITCHHIKER_SAFE_VM 安全具体怎么个安全法？
4 "enableUpload": true, // 是否支持上传脚本和数据， HITCHHIKER_ENABLE_UPLOAD 同问题 1 docker 镜像里 是否开启了？ 怎么查 docker 镜像中配置的环境变量？
其他问题都类似， 就是怎么安装 docker 镜像前，如何查当前配置的 Hitchhiker 环境变量。。。。
Karaser
回复
这个工具本就是给用户自己部署用的，我的那个线上的只是个 demo，用户自己部署才能保证自己数据的安全性，而且很多 api 也是内网才能用的。
Brook Shi
回复
一个问题，如果是内网地址就用不了了吧？
接口测试的时候调试接口有很大段的时期都是使用内网的接口的。
或者我需要将这个部署到本地来解决这个问题么？
wholegale39
回复
可以的，脚本功能比 postman 只强不弱，内置了一些常用的 js 库，里面有 base64 的，另外还可以在 project 里上传任何脚本库，然后在脚本里调用，具体参考： http://doc.hitchhiker-api.com/cn/Script/API.html 部署完后，里面应该有些例子，里面的脚本可以参考下。
我也想问，怎么解决跨域问题？晓得了，还是发到了后端跑得噢。。
老马
回复
- 都可以改，但一般只需要改 HITCHHIKER_APP_HOST，其他的按需修改，这里面只需要写要改的环境变量即可
- 哪些不清楚可以说一下，我可以补充下文档
- 这些参数不支持热修改，其实也没必要，修改后一行命令 docker-compose up -d 就更新好了
@brookshi appconfig.json 也就是 http://doc.hitchhiker-api.com/cn/installation/configuration.html
里边注释的这些 都可以写进 docker-compose.yml 中对应各节配置的 environment: 的吧？
我都提取了出来，您看下 是不是下边的格式或支持的都可以写到 docker-compose.yml
有几个问题：
1 都可以改吗？ 哪些不推荐更改 使用默认？
2 有些使用效果不明，能更详细说明吗？
3 这些参数支持，docker 安装部署后，热修改更新吗？会立即生效吗？ 还是初始化后不可改？
hitchhiker:
environment:
- HITCHHIKER_APP_HOST=http://localhost:6666/ # 修改为本机ip及端
- HITCHHIKER_APP_LANG # 语言，目前只对邮件内容起作用
- HITCHHIKER_SYNC_ONOFF # 是否支持同步
- HITCHHIKER_SYNC_INTERVAL # 同步间隔，单位(秒)
- HITCHHIKER_DEFAULT_HEADERS # 请求默认带的headers
- HITCHHIKER_SCRIPT_TIMEOUT # 脚本执行时间（毫秒）
- HITCHHIKER_SAFE_VM # 是否使用安全脚本
- HITCHHIKER_ENABLE_UPLOAD # 是否支持上传脚本和数据
- HITCHHIKER_APP_INVITE_DIRECTLY # 不通过邮件验证来邀请成员
- HITCHHIKER_DB_HOST # mysql 的host
- HITCHHIKER_DB_PORT # mysql端口
- HITCHHIKER_DB_USERNAME # mysql 用户名
- HITCHHIKER_SCHEDULE_DURATION # schedule 监测时间间隔（秒）
- HITCHHIKER_SCHEDULE_STORE_UNIT # schedule 存储的单位，支持按个数存 count 和按天存: day
- HITCHHIKER_SCHEDULE_COUNT # schedule 存储的大小
- HITCHHIKER_SCHEDULE_STORE_CONTENT # schedule record response 是否存储, all表示所有都存下来, forFail表示只存失败的, none表示都不存（这会很大影响数据库大小和性能）
- HITCHHIKER_SCHEDULE_PAGESIZE # schedule record 在浏览器端显示的一页的个数
- HITCHHIKER_SCHEDULE_MAILFORFAIL # 只在失败时发邮件
- HITCHHIKER_STRESS_COUNT # 压力测试表最大长度
- HITCHHIKER_STRESS_PORT # 压力测试的端口
- HITCHHIKER_STRESS_UPDATE_INTERVAL # 压力测试实时更新时的间隔（毫秒）
- HITCHHIKER_MAIL_CUSTOM #是否需要自定义mail，可以使用 "api" 或 "smtp"
- HITCHHIKER_MAIL_API # custom为"api"时会使用这个mail接口, Hitchhiker会post {target, subject, content}到这个接口
- HITCHHIKER_MAIL_SMTP_HOST # "smtp.qq.com"
- HITCHHIKER_MAIL_SMTP_PORT
- HITCHHIKER_MAIL_SMTP_TLS # 是否需要走tls加密
- HITCHHIKER_MAIL_SMTP_USER # smtp用户名 "***@qq.com"
- HITCHHIKER_MAIL_SMTP_PASS # smtp密码
- HITCHHIKER_MAIL_SMTP_From # 发邮件的邮箱，默认空会使用user
- HITCHHIKER_MAIL_SMTP_NICKNAME # nickname昵称
- HITCHHIKER_MAIL_SMTP_RU # 证书验证不通过时是否报错
- MYSQL_ROOT_PASSWORD=hitchhiker888 # mysql密码
- MYSQL_DATABASE=hitchhiker-prod # mysql 数据库
@zyanycall
坛子里的人用 Hitchhiker 的多吗?
看了这几天有人评 Locust
https://testerhome.com/topics/11853
感觉还不如目前公司在用的 jmeter 了,一直在找替代方案.HttpRunner 也使用过,里边也有用 Locusts 做压测端.
不知道谁评测过 Hitchhiker 的压测能力和水平.@zyanycall 要不来一波啊,看看他的皇帝的新衣能被扒否?
哈哈，这界面风格太像 postman