為服務虛擬化增添生命力：有狀態和狀態轉換測試

---

在服務虛擬化中，創建現實的虛擬服務的關鍵部分是確保服務具有狀態行為，以便可以在測試運行之間保留其狀態。但是極限是什么？模擬何時會成為過多的模擬？在這篇文章中，了解狀態轉換測試以及如何知道何時需要它。

為了加速功能測試，至關重要的是必須不受限制地訪問可信賴的現實測試環境。完整的測試環境包括被測應用程序（AUT）及其所有相關組件（例如API、第三方服務、數據庫、應用程序和其他端點）。

服務虛擬化使團隊能夠（1）訪問所需的完整測試環境，包括所有關鍵的從屬系統組件，以及（2）以分階段的測試環境無法實現的方式更改這些從屬組件的行為。從而使團隊能夠更快、更完整地進行測試。

狀態測試

創建現實的虛擬化依賴項的關鍵部分是有狀態行為。換句話說，虛擬化依賴項可以在測試運行之間保留其狀態。考慮一個模擬虛擬購物車組件的示例。一個簡單的API允許從購物車中搜索、添加、檢索和刪除商品。采用無狀態行為，模擬搜索并將商品保存到購物車不會改變購物車的狀態。測試從購物車中檢索和刪除數據的過程將失敗，因為購物車將保持其初始狀態（空），如下所示：

但是，如果為虛擬購物車提供了有狀態行為，則在測試之間保留其狀態（空或其中有多個項目），并且還根據被測試應用程序的輸入進行更改，您可以開始有意義地測試過程。

使用狀態測試，虛擬化服務現在可以將狀態從空更改為“已添加項目”，并返回適當的信息。如果將商品添加到購物車，并且AUT查詢購物車，則返回適當的數據。使用狀態測試可以進行更實際的測試，現在查詢購物車將返回添加的項目，如下所示：

總而言之，要擁有可信賴且可重用的虛擬服務，至關重要的是，它們必須充分模仿真實的服務，以將有意義的結果返回給被測應用程序，這可能需要狀態測試。

除了虛擬服務本身的狀態之外，您可能還需要根據不同的潛在輸入來模擬狀態變化，這稱為狀態轉換測試。

什么是狀態轉換測試？

狀態轉換是有限狀態機的動作組件，定義為：

“……一個抽象機器，在任何給定時間都可以恰好處于有限數量的狀態之一。 FSM可以響應某些外部輸入而從一種狀態更改為另一種狀態。從一種狀態到另一種狀態的變化稱為過渡。FSM由其狀態、其初始狀態和每個過渡的條件的列表定義。”——維基百科

狀態機是描述對象的有用方法，通常被明確用作編程模型。在其他情況下，例如我們的購物車，可能會有一個隱式狀態機來描述其行為。對于上面的購物車示例，請考慮以下狀態機：

購物車的初始狀態為空，并且在將商品添加到購物車時，狀態從“空”轉換為“購物車中的商品”。根據事件（在這種情況下，從購物車中添加或刪除商品）啟動轉換。

過渡通常需要先確定條件，例如，僅當項目數再次為零時，才發生過渡回“空”狀態的情況。在此示例中，轉換通常會執行操作，例如增加購物車中的物品計數。盡管不太可能將購物車編程為狀態機，但是有一個隱式的購物車可用于定義其行為。

考慮另一個簡單的用戶登錄組件示例，該組件在重試一定次數后將用戶鎖定：

在登錄組件中，初始狀態已注銷。只有輸入正確的PIN才能登錄用戶。在定義次數的登錄嘗試（MAX_RETRIES）之后，該帳戶將被阻止。在這種情況下，帳戶阻止可以被視為最終狀態，因為現在有從其轉移的方法。

使用Parasoft Virtualize模擬狀態

那么，這對測試和虛擬服務有何幫助？好吧，可以使用Parasoft Virtualize模擬狀態行為，以便服務在測試運行之間返回適當的響應，以表示AUT期望的實際值。

虛擬化服務對測試的輸入做出反應，并根據需要保留值，從而擴展了捕獲和模擬的測試數據的有用性，除非通過有狀態行為加以增強，否則這些數據將保持靜態。在Parasoft Virtualize中，服務被虛擬化為“CRUD”（創建、讀取、更新、刪除），以指示其測試數據源是持久性的，并且可以在測試過程中根據需要進行操作。請參見下面的屏幕截圖：

Parasoft Virtualize支持與每個虛擬服務關聯的測試數據源（或引擎）中的狀態行為，該狀態行為不僅存儲測試數據，而且還提供CRUD工具以根據對收到的API請求的反應來操縱數據。測試日期源中數據的這些更新基于輸入事件（如上面狀態轉換圖中討論的那些更新——輸入事件到達，狀態轉換發生，操作發生）。

為了支持所有這些，Parasoft Virtualize中的測試數據管理工具被配置為基于數據源和到達事件執行更新：

測試日期源的更新可以是單個數據項，也可以是整個對象。該工具還允許您根據所需的業務規則創建和刪除記錄。實際上，它足夠強大，可以模擬復雜的行為，這就引出了一個問題：何時進行過多的模擬，過多的模擬？

有狀態虛擬化的利與弊

使用純虛擬化在測試中非常有幫助，因為它消除了處理真實服務的復雜性并隔離了受測應用程序。此外，刪除實時服務意味著可以在多個桌面上同時并行運行測試，而不會影響生產系統或對服務的專用副本的需求。但是，純虛擬服務器僅返回確認，如“是，已調用此API”。在很多情況下，這是足夠的，當然，直到事實并非如此。隨著越來越復雜的用例的出現，我們需要虛擬化的服務器來“提高智能”。

使用上面的購物車示例，您的虛擬購物服務不僅要確認已將商品添加到購物車中，還可以模擬向購物車中添加商品，這對您的虛擬購物服務更加有用。這樣，確定購物車中物品數量的查詢將以正確的值成功執行。我們還可以模擬“購物車已滿”狀態，如上述狀態機表示中所述。有狀態的行為對于使我們的測試獲得更有意義的結果并增加用例的覆蓋范圍是必要的。

但是有一點使模擬業務邏輯變得太復雜了。虛擬化的目的是減少工作量并提高生產率，因此模擬復雜性的回報越來越小。界限很難說，但是如果復雜度遠遠超出了我們的購物車或登錄示例，那么很難證明這一努力的合理性。您如何確定模擬的行為正確？您不希望您的應用程序被構建為可與模擬服務一起使用，但實際上卻無法正確地與真實服務一起使用！驗證仍然需要使用實時服務（幸運的是，Parasoft的Environment Manager模塊使切換變得容易）。

總結

有狀態行為是創建現實的虛擬化服務的關鍵部分，有助于隔離測試中的應用程序。保留測試之間的測試數據狀態的能力對于更實際和有用的測試是必需的。 Parasoft Virtualize提供了全面的測試數據管理解決方案，通過對API調用的輸入進行有狀態且基于狀態的響應，使虛擬化服務的生命得以延續。

應當謹慎使用模擬，因為模擬復雜的業務邏輯的收益遞減，并且有可能偏離“真實事物”。明智地使用模擬在隔離方面帶來了巨大的好處，這反過來又解除了對實時服務器的依賴。但是，由于實時服務器仍在最終驗證中發揮作用，因此需要諸如Parasoft Virtualize之類的服務虛擬化工具來無縫支持這些環境的混合和匹配。