什么是Mock測試

本篇內容介紹了“什么是Mock測試”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

初識mock

作為一個動詞，mock是模擬、模仿的意思;作為一個名詞，mock是能夠模仿真實對象行為的模擬對象。

在軟件測試中，mock所模擬的對象是什么呢?

它一定不是我們所測試的對象，而是 SUT 的依賴(dependency)。換句話說，mock 的作用是模擬 SUT 依賴對象的行為。

測試的對象一般稱之為SUT(Software Under Test)

文字不好理解，我們畫個圖，如下圖所示，被測試對象是 A，A 依賴的是B，B 依賴的是 C。而我們要 mock 的是 B 的行為。圖中 A 就是  SUT。

為什么需要模擬 B 的行為呢?

• (1)提高 A 的測試覆蓋率。A 依賴 B，本質上依賴的是 B 的返回結果，也就是說 B 的返回結果會影響 A 的行為。通過 mock B  我們可以構造各種正常和異常的來自 B 的返回結果，從而更充分測試 A 的行為。

• (2)避免 B 的因素從而對 A 產生影響。依賴真實的 B 去測試 A 可能有很多問題：B 的開發沒有完成時無法測試 A;B 有阻塞性bug 時無法測試  A;B 的依賴 C 有阻塞性 bug 時無法測試 A;

• (3)提高 A 的測試效率。B 的真實行為可能很慢，而 B 的模擬行為是非常快的，因此可以加快 A 的測試執行速度。

mock 種族

常見的 mock 類型如下圖所示：

從下往上依次解釋一下：

• (1)方法級別 mock：mock 的對象是一個函數調用，例如獲取系統環境變量。

• (2)類級別 mock：mock 的對象是一個類，例如一個 HTTP server。

• (3)接口級別 mock：mock 的對象是一個 API 接口。

• (4)服務級別 mock：mock 的對象是整個服務。比如前端工程師自測試時，可以講后端整個服務都 mock 掉，這其實等同于將后端的所有接口都  mock。

接口mock注入的五種方式

在使用 mock 進行接口測試時，一般要做兩件事情，即打樁和調樁。

其實打樁就是創建mock 樁，指定 API 請求內容及其映射的 mock 響應內容;所謂調樁就是被測服務來請求 mock 樁并接收 mock  響應。

事實上，在打樁和調樁之間還隱藏著一件不顯山露水、但是及其重要的事情，那就是 mock 樁的注入(mock injection)。

什么是 mock 注入?

mock 的本質就是用模擬樁來替換真實的依賴。所謂 mock 樁注入就是阻斷被測服務與真實服務之間的鏈路，建立被測服務與 mock  之間的鏈路過程。

如何注入 mock?

總的來說 mock 樁的注入方式與架構、被測服務的架構等因素相關，在實際中常見的 mock 樁注入方式包括但不限于以下五種。

(1)API 請求構造

在 mock 接口中被測服務是 API 的請求方，即客戶端;依賴服務是 API 的響應方，即服務端。根據 mock 工作的位置，mock 可以分為客戶端  mock 和服務端 mock。

客戶端 mock：mock 在被測服務內部工作，直接攔截被測服務的 API 請求方法(比如 HTTP Client方法)，在被測服務調用 API  請求方法時，直接從方法內部返回預定義的 mock 響應。

服務端 mock：mock 在被測服務外部工作，作為 HTTP 服務器接收被測服務發送的 API 請求，并返回預定義的 mock 響應。

客戶端 mock 的注入其實就是改造被測服務的 API 請求方法，即在 API 請求方法中加入 mock 處理邏輯。當滿足某些條件時執行 mock  分支，不滿足時執行真實分支。

可以通過兩種方式實現，一種是直接改造源代碼，另一種是利用字節碼增強技術對字節碼進行改造(Java 語言)。

API 請求改造這種注入方式適用于客戶端 mock，其優勢性能極好，其不足是實現成本較高。

(2)本地配置

對于服務端 mock，打樁之后會生成唯一的 mock  樁地址。被測服務要想調用這個樁需要知道樁地址，如何讓被測服務知道樁地址呢?一種最直接的方法就是被測服務提供一個依賴服務地址配置項，在需要使用 mock  時將依賴服務地址修改成 mock 地址。

本地配置的優勢是實現簡單，不足之處是修改配置項需要重啟被測服務，在需要進行 mock 服務與真實服務切換時不方便。

(3)配置中心

在服務端 mock 中，為了避免修改依賴服務地址配置項導致被測服務重啟，可以采用配置中心(如 Spring Cloud Config  Server)存儲和管理依賴服務地址配置，或者使用注冊中心(如 Spring Cloud Eureka)記錄服務與服務地址的映射關系。

使用配置或者注冊中心時，mock 注入的方法是修改配置中心，將依賴服務地址改成 mock  地址。這種注入方法不需要重啟被測服務，但是從配置改變到配置生效可以存在一定的延時。

(4)反向代理

在微服務架構下，被測服務與依賴服務之間可能不是直連的，而是經過了一層反向代理，例如 API 網關。在這種情況下，被測服務是通過調用 API  網關來間接調用依賴服務的接口。

在 API 網關模式下，mock 注入的具體做法就是修改 API 網關配置，將依賴服務 API 網關接口綁定的地址改成 mock 地址。

這種注入的優勢是對被測服務無侵入，并且實現更細粒度(接口級)的 mock。當然，根據 API 網關的實現不同，仍然可能存在一定的時延。亞馬遜 AWS 的  API 網關就是采用這種方式進行 mock。

(5)前向代理

服務端 mock 除了作為 HTTP 服務器，還可以兼備 HTTP 代理的功能，這種架構又叫做 mock 代理，例如 mock server  proxy。對于 mock 代理來說，它不僅能夠返回 mock 響應，而且能夠在需要的時候將 API  請求轉發給依賴服務，并將依賴服務的真實響應返回給被測服務。

使用前向代理模式，mock 注入的方式是將被測服務的依賴地址或網絡代理修改為 mock 地址，這種注入方法需要重啟被測服務，其優勢是能夠實現細粒度的  mock，并且能夠根據錄制的真實響應自動生成 mock。

五種注入方式對比

一張表格總結一下

不可忽視的mock兩大功能

關于 mock，經常容易被誤解的是：認為 mock 只是模擬返回的結果而已。

實際上 mock 還可以提供兩大功能：(1)記錄真實的調用信息;(2)生成模擬的返回信息;

對于測試用例來說，我們不僅關心 mock 是否返回了期望的結果，還需要關心 SUT 是否以期望的方式調用了 mock 對象。

如果 SUT 沒有以期望的方式調用，比如：沒有傳參或者參數不對，那么 SUT 就存在問題。

mock 需要詳細記錄來自SUT 的調用信息，并提供給用例來校驗。比如 Java mockito 就提供了此類校驗功能：

List<String> mockedList = mock(MyList.class); mockedList.size(); // 校驗 size 函數調用且只調用了1次 verify(mockedList, times(1)).size();

常用 mock 工具

單元測試級別

這個級別的mock工具有easymock、jMock、Mockito、Unitils  Mock、PowerMock、JMockit等，關于各自優劣勢大家可以上網查詢。

接口測試級別

接口級別的mock工具完成的主要功能是對一個用戶的請求，模擬server返回一個接口的響應數據。常用的有：

• Wiremock

• Mockserver

• Moco

• Mock.js

• RAP

mock 不是銀彈

說了這么多 mock 的好處，實際上 mock 也有很多不足，比如：

• (1)mock 可能導致問題遺漏。mock 的模擬行為與真實行為可能存在 GAP，導致基于 mock  的測試雖然通過了，但是基于真實對象的測試卻失敗了，這意味著問題被遺漏了。mock 很難模擬所有的真實情況。

• (2)mock 帶來較高的維護成本。基于 mock 的測試用例結構比較復雜，實現和維護都不容易，后期被測代碼有變動時需要適配 mock 代碼。

簡單一句話：mock 不是銀彈。

有態度的總結

mock 不是銀彈，mock 是有利有弊的，一張圖總結一下：

說了這么多，在工作中如何正確使用 mock 呢?這里提兩點建議，敲黑板啦。

(1)不要過度使用 mock。測試用例中掌握好使用 mock 的度。在涉及網絡訪問、數據庫讀寫、操作系統交互等系統級調用，優先使用 mock。

(2)不要過度依賴基于 mock 的測試結果。基于 mock 的測試無論多么充分，這都不能保證不出現問題的遺漏。一個完整的測試策略一定是由基于 mock  的測試和基于非 mock 的測試共同組成的，二者相輔相成缺一不可。

“什么是Mock測試”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！