一、關於Mock測試

1、什麼是Mock測試？

Mock 測試就是在測試過程中，對於某些不容易構造（如 HttpServletRequest 必須在Servlet 容器中才能構造出來）或者不容易獲取的比較複雜的物件（如 JDBC 中的ResultSet 物件），用一個虛擬的物件（Mock 物件）來建立以便測試的測試方法。

2、為什麼要進行Mock測試？

Mock是為了解決不同的單元之間由於耦合而難於開發、測試的問題。所以，Mock既能出現在單元測試中，也會出現在整合測試、系統測試過程中。Mock 最大的功能是幫你把單元測試的耦合分解開，如果你的程式碼對另一個類或者介面有依賴，它能夠幫你模擬這些依賴，並幫你驗證所呼叫的依賴的行為。比如一段程式碼有這樣的依賴：

當我們需要測試A類的時候，如果沒有 Mock，則我們需要把整個依賴樹都構建出來，而使用 Mock 的話就可以將結構分解開，像下面這樣：

3、Mock物件適用場景

（1）需要將當前被測單元和其依賴模組獨立開來，構造一個獨立的測試環境，不關注被測單元的依賴物件，只關注被測單元的功能邏輯。

　　-----比如被測程式碼中需要依賴第三方介面返回值進行邏輯處理，可能因為網路或者其他環境因素，呼叫第三方經常會中斷或者失敗，無法對被測單元進行測試，這個時候就可以使用mock技術來將被測單元和依賴模組獨立開來，使得測試可以進行下去。

（2）被測單元依賴的模組尚未開發完成，而被測單元需要依賴模組的返回值進行後續處理。

1）前後端專案中，後端介面開發完成之前，介面聯調；

2）依賴的上游專案的介面尚未開發完成，需要介面聯調測試；

　　-----比如service層的程式碼中，包含對Dao層的呼叫，但是，DAO層程式碼尚未實現

（3）被測單元依賴的物件較難模擬或者構造比較複雜。

　　-----比如，支付寶支付的異常條件有很多，但是模擬這種異常條件很複雜或者無法模擬，比如，查詢聚划算的訂單結果，無法在測試環境進行模擬。

4、Mock測試的優勢

（1） 團隊可以並行工作

有了Mock，前後端人員只需要定義好介面文件就可以開始並行工作，互不影響，只在最後的聯調階段往來密切；後端與後端之間如果有介面耦合，也同樣能被Mock解決；測試過程中如果遇到依賴介面沒有準備好，同樣可以藉助Mock；不會出現一個團隊等待另一個團隊的情況。這樣的話，開發自測階段就可以及早開展，從而發現缺陷的時機也提前了，有利於整個產品質量以及進度的保證。

（2）開啟TDD模式，即測試驅動開發

單元測試是TDD實現的基石，而TDD經常會碰到協同模組尚未開發完成的情況，但是有了mock，這些一切都不是問題。當介面定義好後，測試人員就可以建立一個Mock，把介面新增到自動化測試環境，提前建立測試。

（3）可以模擬那些無法訪問的資源

比如說，你需要呼叫一個“牆”外的資源來方便自己除錯，就可以自己Mock一個。

（4）隔離系統

假如我們需要呼叫一個post請求，為了獲得某個響應，來看當前系統是否能正確處理返回的“響應”，但是這個post請求會造成資料庫中資料的汙染，那麼就可以充分利用Mock，構造一個虛擬的post請求，我們給他指定返回就好了。

（5）可以用來演示

假如我們需要建立一個演示程式，並且做了簡單的UI，那麼在完全沒有開發後端服務的情況下，也可以進行演示。說到演示了，假如你已經做好了一個系統，並且需要給客戶進行演示，但是裡面有些真實資料並不想讓使用者看到，那麼同樣，你可以用Mock介面把這些敏感資訊介面全部替換。

（6）測試覆蓋度

假如有一個介面，有100個不同型別的返回，我們需要測試它在不同返回下，系統是否能夠正常響應，但是有些返回在正常情況下基本不會發生，比如，我們需要測試在當介面發生500錯誤的時候，app是否崩潰，別告訴我你一定要給服務端程式碼做些手腳讓他返回500 。而使用mock，這一切就都好辦了，想要什麼返回就模擬什麼返回，不用再擔心我的測試覆蓋度了！

5、Mock測試存在的問題

使用Mock測試有時可以提高團隊的開發效率，但當B、C都開發完成程式碼後，這時應該把E2E測試程式碼從使用Mock測試改為呼叫真實的模組，以避免出現模組之間整合部分漏測的問題。這裡說mock存在的問題，主要是讓開發和測試不要過分的依賴/相信mock介面。

使用mock時，切記的幾點：

1）測試人員不應該被覆蓋率高的E2E自動化測試所迷惑，覆蓋率高不代表沒有問題。尤其在接手新專案中，需要檢視E2E測試中有沒有使用Mock測試，進一步去判斷這些地方使用Mock測試是否合理，這些Mock測試是否應該換成真實模組間的呼叫和整合。

2）當把mock介面換成實際介面後，測試/開發也必須把之前的測試重新做一遍。

ps: 當你使用mock介面來提高效率，請注意：你的工作量其實是比 直接只用實際介面 多了 一倍的。如果測試時，偷懶，替換成實際介面後，只是簡單測試，那麼 當實際介面和mock預期介面有差異時，故障便和你相遇了。

建議： mock介面只能主流程聯調/ 異常返回測試，不要過分依賴mock介面進行測試。

3）測試完畢，上線前，請一定確保 為了mock而做的相關程式碼/配置檔案的修改，已經完全恢復了。

建議：上線checklist中條條列出，並上線前review

---------------------

原文：https://blog.csdn.net/huazhongkejidaxuezpp/article/details/67018676

二、Mock測試方式

1. Mock Server-Moco

這是一個jar包，只要執行該jar包，指定配置檔案，就可開啟一個http伺服器提供服務，並且修改配置檔案後也無需重啟服務，支援動態載入。我使用的是moco-runner-0.10.2-standalone.jar，執行方式如下：

```java -jar moco-runner-0.10.2-standalone.jar start -p 8080 -c XXX.json```

XXX.json就是我們的mock配置檔案，比如：

[ { "description": "api 1", "request" :{ "method" : "get", "uri" : "/foo" }, "response": { "json": {"foo":"bar"} } } ]

以上就可以實現當我們訪問127.0.0.0:8080/foo時，返回一個json為{"foo":"bar"}。

具體其他使用方法請參照官方文件：https://github.com/dreamhead/moco/blob/master/moco-doc/apis.md

2. fiddler

fiddler大家都很熟了，在windows環境可以隨便自定義返回內容，但一個很大的缺點是，它不跨平臺，而我們平時的很多場景下，是需要在Linux下進行mock的。

還有一些其他mock工具，大多都是通過編寫js程式碼或者python、java等程式碼來達到mock目的，此處就不再介紹了。

在選擇mock工具時，可參考以下幾個方面：

一是資料要好管理，別讓我管理一堆檔案；

二是mock介面最好可以設定成和真實介面完全一致，這樣就只需要切換hosts就可以切換mock介面和真實介面，不需要修改程式碼；

三是跨平臺，mock介面在windows和Linux下都需要可用。至於跨域、動態載入什麼的，這是必須條件。

三、Mock測試示例

1、使用Fiddler進行Mock測試

------這種除錯方式適用於rest介面除錯，web介面除錯等。

測試工程師在做測試時，也需要伺服器返回一些特殊的資料來做測試，使用 Fiddler AutoResponder功能來偽造測試資料（建立虛擬物件），能大大減少測試工程師的工作量。

1.1 Fiddler AutoResponder工作原理

使用Fiddler可以替換自動返回的一個【偽造】的HTTP響應，這與使用斷點修改HTTP響應類似，只不過AutoResponder是自動的，操作更加方便。即，瀏覽器發出的HTTP請求並沒有到達伺服器，而是被Fiddler直接返回了一個【偽造】的HTTP響應。

1.2 使用Fiddler進行Mock測試

（1）介面抓包-----找到要mock的介面

以掘金首頁為例，找到下面的介面 https://gold-tag-ms.juejin.im/v1/categories

（2）複製介面資料到本地

在介面上進行右鍵點選，選擇save -> …and Open as Local File -> 預設會儲存至桌面，示例中的資料，儲存到了桌面的test.json

（3）修改資料

修改儲存到本地的json檔案，示例中僅修改了頁面的標籤資料。

（4）替換json檔案

在web session 面板中找到對應的請求，然後將其拖到AutoResponder面板中，在RuleEditor中單擊“Find a file...”，選擇本地json檔案的路徑。

（5）啟用規則

選中“Enable rules”，啟用規則。選中“Unmatched requests passthrough"，放行不匹配的HTTP請求。

（6）save，重新整理頁面

單擊“Save”按鈕。只需修改本地儲存的json檔案，然後重新整理瀏覽器（或直接訪問介面），就可以看到效果了。

*PS：部分內容根據網上資源整理，此部落格僅作個人學習使用。
————————————————
版權宣告：本文為CSDN博主「ecessary」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/qq_35716699/article/details/90581880