軟件測試中的服務虛擬化（Service Virtualization）

最近幾年雖然微服務十分火熱，可是仍然有很多人不喜歡微服務，甚至抵制它。其中最主要的緣由就是其成本高，難度大。就困難而言，主要是遇到了一些不易解決的問題，其中包括如下三個與測試數據和測試環境有關的問題：測試面試寶典

1問題一：測試環境被多個團隊共同使用

在大規模的微服務系統中，某些核心服務不少時候都是會被多個團隊在共同調用，而且它可能也有多個依賴服務。而當一個服務的某個測試環境被多個團隊（服務）共同使用的時候，主要會存在如下兩個困難點。一、同一測試數據可能會被不一樣的團隊修改。有些團隊經過建立多套測試環境來解決這個問題，可是這樣的成本很高。對於不少技術強大的互聯網公司，能夠經過 Docker 等技術手段來下降一些成本，可是對於不少傳統企業來說，高成本的多環境很難實施。二、同一測試數據可能被其餘團隊佔用，所謂的佔用就是一個測試數據一旦不當心被某我的使用了，他可能按本身的場景在進行使用，這個時候你去用它，極可能受到影響而得不到本身想要的結果。

2問題二：測試數據準備須要花費大量時間

當測試一些業務不是很複雜的系統時，準備測試數據也許不是一件困難的事情。可是在一些傳統行業的複雜系統中，準備測試數據是一項很是困難的事情，好比在銀行，保險，通訊等複雜系統中。我曾經測試過一個保險系統，要在測試環境中準備一套數據甚至須要幾個小時，由於整個系統的業務很是複雜，數據庫設計也很是複雜，並且仍是遺留系統，幾乎沒有人懂得直接操做數據庫來準備數據。所以，數據的準備必須由系統建立。而系統自己是基於 MainFrame 的，並且 UI 所有是 Console 下的 UI，操做十分繁瑣和複雜，致使建立一套測試數據須要花費很長時間。不少銀行和保險公司的核心繫統到如今也是保留這樣的模式。因此在這樣的傳統行業中的遺留系統中，測試數據的準備是一個很是大的問題， 其次不少系統中，測試數據一旦使用了，狀態就會改變，從而不能重複使用。因此再次測試就須要從新建立測試數據，這也是一個常見的嚴重的問題。

3問題三：服務部署或網絡等問題致使的測試環境不穩定以及版本不匹配

這個也是常常會遇到的狀況。對於一些穩定而沒有什麼變化的系統，也許這不是一個問題，可是對於一些正在開發過程當中，或者有大量修改或者自己不穩定的系統中，這個問題就十分常見。某些服務部署和網絡問題，這個容易理解了，就是依賴的服務正在部署。其次是依賴服務的正在調試，而調試的過程當中，服務自己的一些狀態可能在不停的改變。或者依賴服務存在 Bug，致使服務也存在問題。最終，用戶可能只須要 1.0 版的依賴服務，但在測試環境中已經部署了 2.0 版的服務，所以用戶沒法使用服務。

解決方案：服務虛擬化可使用服務虛擬化（Service Virtualization）技術來解決以上這些問題。下圖是服務虛擬化的簡單示意圖：

服務虛擬化看起來雖然簡單，可是其實現已經作到很是豐富的功能，好比 Hoverfly 等，從而解決上面那一系列問題。

4Hoverfly

Hoverfly 是一個開源免費（Apache 2）的服務虛擬化的一個工具，其虛擬數據是能夠複用的 Json 格式的 Simulation。它是基於 Go 開發的，輕巧，高效。同時支持 Python 和 Java 進行擴展，也提供 REST API 來對其進行控制。而且暫時提供模擬網絡延遲，隨機錯誤和限定速率。可是其支持的協議優先，暫時只支持 HTTP 和 HTTPS。可是其最重要的是其支持六種工做模型，它們分別是：Capture 模型，Simulate 模型，Spy 模型，Synthesize 模型，Modify 模型，Diff 模型。經過這六種模型，基本能夠實現服務虛擬化的各類功能。首先，經過 Capture 模型能夠獲取到在手工測試和系統正常使用的狀況下，各類服務的交互數據，而後再進行分析和修改，能夠得到更多類型的數據。將這些數據經過 Spy、Synthesize、Modify 和 Simulate 模型進行不一樣類型的服務虛擬。不一樣的團隊能夠根據基礎類型數據快速定製本身團隊的私有虛擬數據集，而且還能夠根據不一樣版本的服務，定製不一樣版本的虛擬數據集，從而隔離了不一樣版本服務之間的數據，避免了不一樣團隊之間的的測試數據衝突。

下面就來逐個介紹一下這六個模型。

4.1****Capture 模型

Capture 模型是標準的錄製功能。這個時候 Hoverfly 就是一個標準的 Proxy 服務。把它架設在被測的服務和外部服務之間，均可以把全部的交互數據錄製成特定的 Json 文件，稱之爲 Simulation。而後就能夠根據不一樣的需求更改 Simulation，並用到其餘模型裏面。

4.2****Simulate 模型

Simulate 是標準的 Stub 模型。能夠將經過 Capture 模型錄制到的 Simulation 或者手動編寫的 Simulation 直接加載進 Hoverfly，而後全部知足 Simulation 裏面的匹配規則的 Request 就會返回 Simulation 裏面的虛擬 Response，否則就不會返回任何正確的 Response。

4.3****Spy 模型

Spy 模型是一個最爲特殊的模型，也是我在正式項目中最經常使用的一種模型。它最特殊的功能就是可讓部分請求得到虛擬的 Response，而其餘部分請求得到真實的 Response。

所以，經過改變測試數據自己，能夠肯定使用的是實際依賴系統仍是虛擬依賴活動。而這種狀況下，在傳統已有的這種 Stub 工具裏面多是須要本身手工去實現的，至少它默認不支持。可是 Hoverfly 是默認就支持，因此只須要把規則加到 Hoverfly 的這個虛擬文件裏面，它就能實現這個功能。

其次有些時候在同一個測試環境裏面，我既須要虛擬的數據，又要真實數據的狀況下，Spy 模型是最佳解決方案。由於只有這樣才能以最低的成本，來實現了既能夠測真實的數據，又能夠測虛擬的數據。

爲何會須要這個模型？由於很多時候測試環境不穩定，大規模的迴歸測試不能依賴於外部服務，因此其須要依賴於虛擬的數據。可是依然要測一些外部的真實服務，爲何呢？由於擔憂外部服務的升級怎麼辦呢？那可能升級以後，服務的 Request 和 Response 的 Schema 改了，就會產生一個 Bug。現實中會把一些所謂的重要的場景，依然是跑真實的外部服務，這樣就算它的外部服務的 Schema 更改了，測試就能夠在第一時間發現這個更改。

因此，這是一個最爲經典和實用的模型。

4.4****Synthesize 模型

Synthesize 模型最主要解決的一個需求是根據不一樣的狀況返回動態的 Response 數據。

因此，這個時候實際上是 Hoverfly 提供一種中間插件的功能，能夠在開發一個基於 Python 或者 Java 的中間插件，當某個 Request 收到以後，能夠對這個 Request 進行加密解密，進行一個特定的判斷，以後再返回一個特定的 Response。

能夠對 Request 進行判斷、處理，對 Response 進行一些特定的組合，並非一個固定的值，或者說固定的某一到兩個值。

4.5****Modify 模型

Modify 模型要等待真正的 Request 收到後，才能將 Request 轉換爲特定的內容，併發送給外部依賴，而外部依賴返回到 Response，再返回到特定的模式，以實現特定狀態的虛擬。

好比須要模擬一個 Request 裏面被加了某些東西，或者是作一些混淆，產生一些特定的用例，或者更改真實的 Response 中的某些數據等。

4.6****Diff 模型

Diff 模型至關於一個變異版的契約測試方案。首先當被測系統的 API 的時候，它會將依賴服務的返回數據保存起來。當下一次執行相同的測試用例的時候，它會把上一次的和本一次的依賴服務返回的數據的進行比較。

若是下一次的和第一次存儲的的 Schema 有不同的，那這個時候 Hoverfly 會報警，並顯示出來兩次不同的內容。這個就至關於就作了一部分被測系統和依賴系統之間的一種被動的契約的檢查，雖然它不屬於一個完整契約測試方案，可是至少作了單邊的契約檢查。

爲何要選擇 Hoverfly？

首先服務虛擬中心化，它是基於 Proxy 模型的，因此在它只要加一臺機器搭建一個服務就能夠了。其次它是非侵入式的，它是不須要改動被測系統的代碼或者配置的，而只須要改動 JVM 本身的 property 或者是操做系統的 Proxy 配置。而後其靈活性很高，它支持各類模型，使用很是方便。最後它是開源軟件，因此若是有特定的定製化需求，能夠本身修改後供本身使用。

5總結

隨着傳統 Stub 和 Mock 服務技術的發展，以及微服務系統開發中對於服務測試的各類問題和需求，服務虛擬化孕育而生。服務虛擬化是對 Stub 以及 Mock 技術的提高和系統化，功能更爲強大，從而能夠更加容易使用和定製化，以便知足服務測試的各類新需求，解決各類新出現的問題。測試面試寶典