如何進行「花式」HTTP介面測試

2019 年 10 月 4 日
筆記

現如今每當我們談起自動化測試的時候，首先想到的不在是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套系統同時回放請求，在對比二者的返回內容是否一致。這種影子測試的方式就解決自動生成數據的難題。