原文首發： http://www.testqa.cn/article/detail/234
現如今每當我們談起自動化測試的時候，首先想到的不在是UI自動化，而是接口自動化。因爲大家在被UI自動化“坑”多了之後，都變了聰明瞭。那麼今天我們就來聊聊HTTP接口測試的那些“花式”測試方式。
最Old-School的方式
曾經接手過一個HTTP的接口項目，主要業務邏輯是一個分倉發貨的物流子系統。可以通過HTTP的POST方式發送請求，並返回一個XML格式的內容。
對於這樣的一個HTTP接口項目，前任OWNER在做自動化測試的時候，是這麼做的：
- 直接通過QTP打開瀏覽器
- 訪問一個定製表單頁
- 然後選擇不同的子項組合
- 最後提交表單
- 通過QTP從瀏覽器中獲取返回內容
- 進行內容檢查
簡單來講，這就是一個通過UI的方式來測試API接口的方法。不能說這種方式不好，只能說在效率和擴展性上不夠優秀。主要體現在以下幾個方面：
- 150多個用例執行需要半天
- 換一個其他項目腳本都得重寫
- 需要爲每個項目編寫至少一個表單頁輔助測試
當然，後來這個項目被我優化了，後面會介紹具體的方式。
最普通的方式
如果說讓一個新手來做HTTP接口的自動化測試，那麼他首先會考慮的方式，肯定是基於單元測試框架。然後針對每一個接口編寫多個不同檢查點的Case。
說它普通，那是因爲大多數人都會選擇或者曾經使用過這種方式，算是HTTP接口測試的入門方式。對於聰明點的同學可能會進行寫稍微的改進，比如：
- 對同一個接口只開發一個用例，通過參數化請求數據和期望結果來實現多檢查點覆蓋
- 對同一個項目只開發一套邏輯，通過參數化URL、請求參數、請求方式、期望結果等實現項目邏輯的覆蓋
如果一個HTTP接口測試已經被完全的參數化了，那麼可以認爲你已經正式的“畢業”了！可以開始開拓其它更好的好的測試方式了。
最文藝的方式
如果你對100個測試人員說，你正在使用RF（RobotFramework）進行自動化接口測試，那麼肯定有一半人覺得疑惑，一半人表示“欽佩”。因爲畢竟RF在江湖中已經失傳已久了。
覺得疑惑的同學，是因爲他們可能只是聽過說RF，但是從來沒有使用甚至瞭解過。不知道它具體能幹嘛，或者只以爲是一個UI的自動化框架。
表示“欽佩”的同學，是因爲他們曾經嘗試過RF，但最終肯定是放棄過RF。RF如果沒有被設計成2類用戶使用，那麼它可能會是一個“噩夢”。畢竟直接使用Python原語言開發用例，總比多套一層RF再開發用例要清爽的多。
簡單來講，RF本質上與單元測試框架一樣，也是一個執行框架，它可以支持任意的測試類型，包括UI、接口自動化。但是讓它獨樹一幟的，是它能提供的Keyword機制，一切拋棄“keyword”理念的RF實踐基本上等同於耍“流氓”。
最認真的方式
誠然RF並不是毒藥，就要比毒藥可以殺人，也可以救人一樣。使用得當的情況下，RF也是有它的魅力的。曾經參加過某一個線下沙龍，一位嘉賓分享過他們公司基於RF框架的HTTP接口自動化測試實踐。
之所以把它歸爲最認真的方式，是因爲他們基於RF進行了深度的定製，具體體現在如下方面：
- 自主開發了在線的WEB用例編輯器（支持keyword選取）
- 優化用例存儲方式（改進爲直接存放在DB中）
- 扁平化RF用例層次結構（WEB用例編輯器下面只有一層keyword封裝函數，且都是使用python開發的keyword）
經過定製之後，可以說是取其精華，去其糟粕。完美的重用了RF的keyword機制，同時摒棄了RF繁雜難用的語法。另外以服務的方式對外提供調用，集中管理了測試用例和測試報告。
最“期望”的方式
上一小節，我們已經初步體會到了以WEB服務提供HTTP接口測試的好處。但是以RF爲基礎的方式，畢竟還是避免不了開發keyword函數。而我們所期望的方式可能是僅僅在UI上面點點、選選就可以完成接口用例的開發，而無需再開發keyword了。
如你所想，我曾經就有過這樣的想法，並且開發過這樣的一個用於接口測試的WEB工具。主要用來替代了最old-school的那種方式。
起初開發這個WEB測試工具的時候，期望的內容是這樣的。
- 不需要寫代碼直接通過UI操作,就可以在線編寫接口測試用例，並且統一保存在服務端
- 直接通過UI觸發就可以在服務端執行指定的測試用例
- 報告統一存放在服務端可供查看，並且保存用例的歷史測試記錄
- 支持通過API接口執行單個用例或用例集
- 通用的邏輯可以支持到所有項目
待到開發完成後，發現前面的所有條目都可以實現，唯獨最後一條是一個“坑”。畢竟針對簡單HTTP的API接口還好對付，對於API間有複雜邏輯關係的業務就非常麻煩。即使該工具也提供了插件技術，支持開發擴展功能。
最後，這個工具主要用來維護一些單接口API測試需求的項目。對於複雜的還是推薦直接通過開放性的框架或者工具來完成。
最“偷懶”的方式
之所以說是偷懶的方式，是因爲大多數人在接觸API接口一段時間之後，都會有無聊和懈怠；畢竟新鮮勁過了，API測試也就這個樣子，跟手動UI測試一樣無聊。
最關鍵的是也發現不了幾個bug，但是卻要一個一個的反覆開發API用例，感覺又要回到“解放前”。所以就會想API測試雖然挺好，但還需要手工編寫，能不能有一種方式可以自動生成呢？
答案是有的！！！俗話說的好：每當有人懶起來的時候，就是社會進步的時候了！！
具體而言，就是通過錄制的方式來完成API接口用例的生成。這樣接口測試的工作就變得即好用就便捷了，只要錄製用例，執行用例就行了。具體而言可以有如下幾種方式可以實現：
- 通過代理軟件錄製HAR文件，導入到POSTMAN中
- 錄製HAR文件，導入到YAPI中
- 錄製HAR文件，導入到HTTP Runner中
- 通過代理工具二次開發，直接錄用用例數據到DB中
除了最後一種方式，需要自己編寫一些代碼來實現；其它的都是“先懶”們早就已經想到的了。最後一種也是我最近在項目中使用到的方式。
最“理想”的方式
通過錄制的方式雖然方便，但是它有一個前提要求，就是錄製的內容可以重複去執行。如果一個接口每次獲得的內容是變化的，或者每次提交的內容也是變化的，那麼錄製的方式就不是很適合了，或者通過一些限定的手段來保證這一點。
再回過頭來想想，API測試最終極的理想方式，應該是自動生成用例，並且自動生成正確的測試數據。雖然現在AI很火，但是還遠沒有達到這種自動化生成測試用例數據的能力。
而在AI還不能完成之前，我們可以通過真正的“人工智能”的方式，來解決一些特定需求的項目。
比如：對於重構項目的測試，就可以通過拉去線上請求歷史日誌，在線下同時對新舊2套系統同時回放請求，在對比二者的返回內容是否一致。這種影子測試的方式就解決自動生成數據的難題。
總結
相信上面的這麼多種方式，大部分人都曾經遇到或者使用過。當然各有利弊，沒有最好只有最適合。如果你還有其它的方式，希望你能關注公衆號並回復給我哈！
PS：公衆號文章不能發評論，但是可以給公衆號發信息的哦！
新書推薦
獲取更多關於Python和自動化測試的文章，請掃描如下二維碼！
