當你準備給自己所負責的項目搭建接口自動化測試時，面對市面上多種多樣的工具或者框架，是否遇到不知該選哪個工具的困惑？本片文章通過對時下使用廣泛的接口自動化工具進行對比來介紹自動化工具或者框架選擇策略，協助處於困惑中的小夥伴選擇適合項目的接口自動化工具。
在講工具選擇策略前，我們先思考一下這三個問題
搭建自動化的價值是什麼？
覆蓋接口的哪些內容？
如何降低接口自動化測試維護成本？
對於以上三個問題，你有自己的答案了麼？以下是筆者對以上三個問題的思考。
搭建自動化的價值
搭建自動化的目的是覆蓋全面且能快速反饋被測應用質量。想像一下對於一個功能複雜的系統，開發在上線前剛剛修復了幾個bug，測試問開發影響範圍，開發可能會說“不好說，都測試一遍吧”。如果你遇到這樣的答案是不是要抓狂，實際項目中這樣的情況不僅存在，而且可能還比較頻繁。此時如果有個覆蓋全面的自動化腳本該多好，讓自動化腳本跑起來，茶水間喝杯咖啡回來就知道質量結果了。
接口覆蓋策略
1. 系統自己使用的接口覆蓋測試場景而不是單個接口的response。
比如一個更新用戶個人信息的接口，試想一下如果是手動測試，你會如何做？肯定是在頁面上更新某個信息或某幾個信息，然後查看對應的數據字段是否更新或者頁面是否顯示新的內容。你會單獨查看接口的response是否和需求文檔一致麼？大部分情況下都不會。所以在搭建接口自動化測試時建議覆蓋測試場景以此保證業務功能是否正確。
2. 對外提供的接口重點檢查接口的response body和response schema。
有些小夥伴讀到這裏是否會犯迷糊，第二點似乎和第一點矛盾了呢？實際不矛盾，對於對外的接口，因爲接口使用方是第三方，對於第三方在哪些業務場景下如何使用該接口不是接口提供方的測試範疇，故接口提供方只需保證接口返回的內容與格式與之前定義的一致即可。
3. 只要提供接口的地方就嘗試進行覆蓋，保證接口測試足夠全面。
降低維護成本策略
1.管理測試數據，保證測試case獨立性。即每一個測試案例需要的測試數據在案例運行前自動準備，案例運行完後自動清理。任何用例的執行不依賴其他用例是否執行成功。
2.管理配置信息，保證多環境運行無障礙。即當測試環境切換後，能通過環境變量簡單快速切換到所測環境，無需任何手動介入，相同的一套測試腳本DEV環境能運行，切換到UAT環境同樣能全部正常運行。
3.已實現的自動化腳本能快速重用。例如一個系統有3個角色，已經完成了“初始化用戶爲系統任意角色”的測試腳本，假設此時新增了一個功能，此功能只有系統某個角色才能操作，那麼在準備測試數據時就可以調用之前的代碼快速初始化所需用戶。
4.清晰的代碼分層。讓新上項目的人也能快速上手開始自動化腳本編寫。
5.默認等待機制，解決數據延遲問題。例如調用一個接口到數據全部落入數據庫需要時間，如果沒有默認等待機制，調用接口後立刻查詢數據庫數據可能出現錯誤假象。對於微服務，這類問題可能更突出。
6.Retry機制，對於部分不穩定的接口，適當的retry機制可以保證自動化用例成功率。
7.管理接口reqeust body，接口的request body修改頻繁，要儘量引入其他工具協助更好的維護接口的request body，否則接口body的任何修改可能都會引起自動化的大面積修改。
8.集成到CICD平臺，定時運行持續優化。
9.詳細的日誌打印，流水線上清晰知道錯誤原因。
10.測試工具是否支持腳本語言，是否有完善的幫助文檔，github上start數量，是否還在持續維護。
在思考和回答了上面的問題後我們再來看目前市面上使用較廣泛的能實現接口自動化的工具或者語言。
接口測試工具對比
Postman/SoapUI/Jmeter：
這三個工具放在一起的原因是都屬於配置類工具，簡單易上手，利用該工具可以很快調通一個接口，後續再學習一下如何配置測試集、如何進行斷言、如何配置全局變量等，基本就可以實現接口的半自動化了。但如果要搭建覆蓋全面且較低維護成本的接口自動化腳本，有太多理由否定採用postman或者soapUI。比如：無法連接數據庫準備測試數據，即無法實施“降低維護成本”中第一條策略，一旦測試環境中測試數據遭破壞，case就會運行失敗。再比如接口的request body都是寫死在用例裏面，即無法實施“降低維護成本”的第七條策略，開發修改任何一個接口，都可能需要修改多個測試用例的reqeust body。
Groovy+Rest-Assured
Rest-assured是一款測試REST api的自動化測試工具，除支持接口調用外，還提供了接口校驗、日誌打印、錯誤顯示等功能，非常適合接口自動化腳本。Rest-assured配合腳本語言groovy前面提到的10點降低維護成本策略都能實施。例如利用腳本語言groovy可以方便連接數據庫準備測試數據，可以用csv文件管理測試數據，yaml文件管理配置信息，輕鬆對接口返回的json格式或者xml格式數據進行解析處理等等。
Java+Httpclient
Httpclient是apache common下的一個子項目，引入該jar包即可完成接口調用，相比與rest-assured這類專門的接口測試工具，httpClient不提供接口response校驗、接口request、response打印、錯誤信息顯示等功能，這些都需要自己單獨寫代碼實現。
Python+Request
Request是python下的一個包，引入該包後即可完成接口調用，和httpclient一樣該包僅僅完成接口調用，如果需要接口response的校驗、日誌打印等都需要自己單獨寫代碼實現。相比與java+httpClient組合，這個組合使用了腳本語言python，就實現接口測試而言，學習python的成本要遠低於學習java的成本。相比groovy+rest-assured組合，python語言官網沒有提供配套的BDD一類的框架，所以選用該組合還需要配合其他測試框架一起服用纔行。
Python+Pyresttest
Pyresttest是一款rest api測試工具，和groovy+rest-assured的組合很像，都選用腳本語言作爲編程語言，選用專門的接口測試框架調用接口。Pyresttest在github上的start是900+，rest-asssured在github上的star是4000+，要相信羣衆的眼睛是雪亮的，所以一定要選擇，那肯定還是選擇groovy+rest-assured組合。當然如果你一定要用python語言，那可以深入研究下pyresttest是否可實施前面“降低維護成本”的十個策略，如果可以，那選它也是ok的。
結束語
對比上述工具旨在告訴大家在選擇工具或者框架時，首先需要明確你的項目需要完成怎樣的自動化，然後再查看市面上的工具，看看這些工具以及支持的語言是否滿足你的需求，只要有了明確的目標，選擇就不再困難。比如要搭建覆蓋全面且較低維護成本的接口自動化，選擇工具時首先需要考慮是否能輕鬆獲取到接口response body和校驗response schema，另外還需考慮能否實施“降低維護成本”中提到的10個策略，如果都能實施，那就用它了。
如果對如何使用rest-assured+groovy編寫接口自動化腳本感興趣的小夥伴可以訂閱gitchat上“接口自動化實戰” 專欄約。https://gitbook.cn/gitchat/column/5dbbe297e29af65d1d01b8fc