mock測試方法及實踐改進

阿新 • • 發佈：2018-11-01

此文已由作者翟曜授權網易雲社群釋出。

歡迎訪問網易雲社群，瞭解更多網易技術產品運營經驗。

mock測試常見的定義為：在測試過程中，對於某些不易構造或不易獲取的物件，通過建立虛擬物件的方式來模擬測試的測試方法。

提到mock測試工具，java領域內可能首先想到的是Jmock、EasyMock、JMockit等。通常在單元測試中，由於物件、方法不是獨立的，測試程式碼難以構造，所以業界提出了Mock Object技術來孤立被測試的物件。以上幾種Mock 框架都限於一個Mock概念：即Mock Object 是用來代替與程式碼協作的物件的物件。和這幾種框架一樣，其他的 mock 框架也基本都侷限於單元測試範疇，而在整合測試功能測試階段還沒有相應成熟的框架進行支援。所以本文提到的mock測試，更確切來說，是在功能測試階段解決如何與外部系統間的資料互動。

文章結合本人所在的專案【秀品】來做相關介紹。大多使用者直接接觸到的只是秀品商城，但實際整個秀品業務系統的運轉比較複雜，其中便涉及到和多個外部系統的對接及資料互動，比如倉儲和物流都會和EMS、順豐等有資料互動。而最近秀品開始涉及跨境業務，相應和電子口岸、境外的物流商等又會有資料互動。

當然，跟外部系統對接時系統間的聯調測試必不可少，有些外部系統提供測試環境，有些甚至不提供。即便是提供測試環境的外部系統，一般也僅在開發聯調階段配合提供聯調測試對接服務，一旦聯調測試結束，也不再繼續提供測試服務。那麼，當這些外部系統的聯調測試環境不可用時，我們就需模擬這些外部系統來和秀品系統進行資料互動，以便支援秀品完整業務測試流程的正常進行。針對這類mock測試需求，秀品QA做了幾種實踐，也是在實踐中總結再改進的過程。

秀品系統採用的通訊協議主要有：dubbo協議和http協議。和外部系統對接都是採用http協議，所以目前只需模擬外部系統對秀品系統的http請求回撥功能。

以秀品和EMS（倉儲物流商）的WMS（倉庫管理系統）互動為例，EMS會提供一份標準對外介面文件給秀品。不同業務介面的呼叫形式和介面引數基本是一致的，僅通過引數值傳遞與業務相關的資料。約定如下圖所示：

以其中一個WMS回傳訊息介面為例：【入庫單收貨確認回傳介面】，其處理業務說明：WMS系統在入庫單完成入庫（上架）後，將對應入庫資訊回傳給外部系統（即秀品）。EMS提供的文件說明如下圖：

結合秀品系統實現，EMS的回撥最終只需拼接成這樣一個請求：

秀品某測試機Ip+http埠號+呼叫路徑+servicename+appkey+content（xml格式）

其中：Ip+埠+呼叫路徑+appkey 與測試環境配置相關，基本不隨業務變化。

servicename+content（xml格式）和業務有關，頻繁變化。

針對該【入庫單收貨確認回傳介面】，則只需拼接並執行這樣一個請求：

http://host:port/oms/wms/ems?service=WmsStockInConfirm&appkey=xxxxxx&content=< RequestReceiveInfo> xxxxxxxx</RequestReceiveInfo>

說明：content為上圖中xml格式的資料集。

如何處理這類mock測試？

WAY1：尋找能傳送http請求(get\post)的測試工具，例如fiddler、postman。

fiddler大家都比較熟悉，主要介紹下專案中使用的postman。Postman 是Chrome 擴充套件，提供功能強大的 Web API & HTTP 請求除錯。它能夠傳送任何型別的HTTP 請求 (GET, HEAD, POST, PUT..)，附帶任何數量的引數+ headers。其具備兩個主要優點：

1.能夠保留歷史請求，這樣我們就可以很容易地重新發送請求；

2.有一個“集合（collection）”功能，用於儲存所有請求相同的API/域。

使用效果如圖：

Postman其實已足以滿足大部分同類測試需求，且使用成本不高，不需額外編寫測試程式碼。但結合我們專案特點，這些mock會影響每一次訂單流程扭轉的測試，使用頻率非常高，且存在許多需要mock的回撥介面。所以，針對這些影響可得出以下可改進點：

1.資料主要集中在xml中，每次執行需根據不同測試資料更改xml，改起來費時費力且易出錯。

2.雖有“集合”功能，但一個人的測試集也不便於及時共享給其他同學。

3.操作介面雖有b格，但過於簡陋，真心不便。

綜合postman的優缺點，不如嘗試把測試集固化到java程式碼裡，因此開始了嘗試WAY2：利用java程式碼，基於httpclient傳送請求。類似於http介面測試，測試集程式碼如下圖：

說明：

分別構造出請求url，xmlinfo及所需各引數後，執行請求即可。針對xml的處理，每次執行只需參照程式碼註釋更改相應框內的屬性值即可，減少編輯時間和出錯概率，且一人寫的程式碼其他同學都可以共用，總體還是提高了測試效率，基本滿足了測試需求，但仍存有可改進點：

1.執行時要基於IDE，需要更改xml檔案中相應屬性值，同時必須具備程式碼執行環境。

2.沒有視覺化操作介面，存在使用門檻，操作不夠方便。

如果傳參更為簡單，使用者無需接觸測試程式碼，不用基於本地執行環境且能夠視覺化執行，這樣可進一步提升測試效率，於是開始了嘗試WAY3：模板語言在mock測試中的應用，並結合jenkisn實現使用者介面。最便捷的方式首先想到了結合jenkins，通過執行jekins job，只需在視覺化的介面裡傳入引數值，便可“一鍵執行”成功模擬出介面的回撥，很好地解決待改進的問題。

針對該解決方案：

首先，測試程式碼需上傳伺服器，需解決伺服器上構建打包的規範問題，以便可以通過命令列傳入引數呼叫到不同測試類及模板檔案。

其次，針對xml檔案作為請求引數，考慮引入FreeMarker模板引擎，基於模板生成xml檔案輸出。提取出xml中在實際測試場景中需頻繁更新的屬性，重新定義成一個Java do類，向匹配的ftl檔案傳值。從而整體簡化測試程式碼的繁鎖度。

另外，從工具使用角度考慮，傳參過多，也會較繁鎖，所以考慮將輸入的引數合併為長字串，傳遞到程式後再做拆分處理。

總之，在設計程式碼結構及編寫程式時，秉承著一個原則：儘可能通用化。

結合最終需拼接並執行的請求形式：

Ip+埠+呼叫路徑+servicename+appkey+content（xml）；

其中Ip+埠+呼叫路徑+appkey 與測試環境配置相關，基本不變；

servicename+content（xml）和業務有關，頻繁變化。

做了如下改進：

1.將請求url中環境配置相關的共通部分抽取，定義為CommonURLDo，以便可以靈活執行在不同的測試環境。

2.將不同業務介面（servicename）對應的xml定義為不同的ftl模板檔案。並將模板需頻繁變化的變數提取，定義成業務DO類，建立DO和ftl的對映，通過DO向ftl傳參。