淺談接口Diff測試

轉自：https://mp.weixin.qq.com/s/6H-AGaqpwf47gcxs2Sw9fQ

所有的手工CASE和自動化CASE都跑了，上線為啥還經常有問題呢？

服務端語言由PHP語言改成GO了，原來的接口邏輯我又不了解，怎麽測試？

測試環境測的好好的，上線後由於開發部署的版本問題導致的事故，開發非要說是我漏測，這鍋怎麽甩？

別急，嘗試下接口Diff測試...

接口Diff測試，簡單來說就是比對相同接口在不同版本/不同環境下面的返回內容是否符合預期。對於日常叠代的接口來說，Diff測試是我們接口基本功能測試的有效補充，因為采用的是自動化的手段，它可以利用線上大量的請求日誌在新舊兩個版本中進行回放，而我們手工/自動化的接口回歸往往只局限於少量的測試數據，很難覆蓋到大量的、在生產環境真實會發生的異常請求數據。

如果你曾有過大量的接口測試實踐，相信對上面的說明會深有感觸，單純的依靠有限的CASE進行接口功能覆蓋，上線後或多或少還是會發現一些異常。過多的美言我們不再累述，下面我們就一起看下實現思路和主要的實現細節吧。

實現思路

其實呢，整體思路比較簡單，見下圖：

用Unittest做過接口自動化的同學看上圖是不是感覺很熟悉？沒錯！接口Diff測試和接口自動化用的就是同一套東東。區別在於，Diff測試需要同時向兩套環境發相同的接口請求，拿到返回後進行比較（上圖中的“主要函數：json遞歸比較”就是實現比較功能的）；另外，優化了常用的HtmlTestRunner測試報告，采用了更加美觀的BeautifulReport報告模板。

主要實現細節

項目的目錄結構

• config—接口請求地址維護

• data--接口請求數據（線上回放日誌存放）

• logs--項目日誌文件

• testCase—unittest組織的接口CASE

• testReport—測試報告存放

• utils—工具、公用方法存放

測試報告

我們從測試報告往回說。一份“美觀、清晰”的測試報告，往往會讓測試工作顯得更加專業。因此，項目中報告部分采用了BeautifulReport（html模板及部分細節有改動）,BeautifulReport是一套開放源碼的報告工具，此部分有以下幾點說明：

1. BeautifulReport可從https://github.com/TesterlifeRaymond/BeautifulReport 上面下載

2. 建議把該工具放到項目目錄下進行調用，方便維護和擴展，例如我就放到了util目錄下。

3.BeautifulReport在代碼中調用類似HtmlTestRunner,需要傳入待執行的測試用例集，如下圖

4. 對於失敗的CASE，對應的結果下面也有清晰的錯誤原因，方便問題定位。

測試用例組織

測試用例部分需要說明的：

1. 建議每個接口單獨一個.py文件，這樣加上多線程可以支持同時跑，提高效率

2. 用例采用的是數據驅動方式，數據放在csv文件中（關於數據驅動網上有很多例子）

3. Diff測試有一項重要的工作就是兩個接口返回值的比對，現在多數http接口數據格式都采用json。因此，需要實現個簡單的json比對的方法，部分代碼如下（當然JSON比較網上也有很多例子可以參考）

4. 上面代碼中帶有HTML標簽的提示信息，完全是為了優化測試報告中的錯誤信息。否則比對結果看起來比較雜亂。

其它細節

拿到線上接口請求日誌，用腳本簡單處理下，只保留請求參數部分。

其它，其它….就沒什麽了。

是不是很簡單？即使作為一個新手，只要有一定的python基礎。熟悉下uinittest、request，網上load下BeautifulReport，找一個json比對算法，基本上就搞定了。

總結

我們來回答下開頭的三個問題：

第一個，設計CASE時考慮的異常與實際線上大量的請求數據比，難免會有想不到的。無論是功能還是性能測試，最接近實際用戶場景的測試，才是最好的測試。

第二個，系統那麽龐大，沒有人能把細節都了如指掌，更何況你可能還是團隊的新人、抑或項目之前沒有任何資料積累。這種情況下，diff測試效果更明顯，起碼更高效。

第三個，把CASE數據、日誌、報告亮出來，讓開發把鍋取走.

淺談接口Diff測試