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庫，虛擬機單核的，撐不住）。