借助服務虛擬化，您可以簡化模擬過程，并創建共享核心功能的可重用虛擬服務庫，因此您可以一遍又一遍地停止創建虛擬服務。

對于開發人員而言，沒有比從頭開始不斷重建事物更令人沮喪的了。面向對象設計的一個核心原則是能夠為每一項工作創建一個對象或一個參考點，因此您不必重復自己。

盡管有這一核心原則，但在進行模擬時，開發人員經常會發現自己一遍又一遍地重復相同的過程。

但為什么？當開發人員編寫應用程序代碼時，他們通常與相同的外部API通信并以不同的方式對相同的服務進行相同的調用。傳統模擬的問題在于它們是在代碼級別編寫的，并且經過專門設計以與正在開發的功能一起使用。這樣，每次需要行使功能時，都必須創建一個新的模擬。

使用傳統的模擬框架時，很難共享已經創建的模擬，這不僅是因為可能不知道它們在代碼庫中的位置，而且還因為難以理解特定模擬與哪個需求相關聯至。這樣，最終發生的事情是，各個團隊成員經常創建與坐在他們旁邊的人相同的模擬對象。這簡直是浪費精力，浪費了開發人員的時間。

我的模擬在哪里？

 一旦開發人員創建了模擬，進行協作也將變得充滿挑戰。沒有可用的魔術儀表板，您可以在其中發布有關已創建的模擬的通知，以使團隊保持知情。

我最近在一家醫療機構中使用模擬作為一種常見的開發實踐，并且他們有一個始終脫機的服務提供商，這使其成為模擬的共同目標。這樣，每個單獨的開發人員都在自己的代碼庫中為其創建了模擬接口。它們都稍有不同，但達到了相同的目的。當我采訪開發人員時，我發現大約存在20個相同的模擬。這甚至令他們感到驚訝。當被問到重復的工作時，用安靜的語調回答并不是完全出乎意料的：“我們太忙了，無法溝通。”

聽起來有點熟？（我希望我在這里能得到很好的統計，以使您感覺好些。）

但是，正如任何開發人員或測試人員都會解釋的那樣，模擬是必需的，因為在進行開發時，您需要具有使自己與世界其他地方脫鉤的能力。模擬是一種在可保護的環境中包圍您的應用程序的方法-但是該解決方案具有其固有的挑戰，包括：

• 從頭開始重建每個模擬都是乏味的，浪費時間
• 試圖發現現有的模擬游戲很困難
• 嘲笑是無目的存在的-它們不受特定API的約束，也無法重用
• 人們盡管需要合作，卻忙于無法溝通

輸入：服務虛擬化。通過這種測試實踐，您可以簡化模擬過程，并創建共享核心功能的可重用虛擬服務庫。因此，您可以一次又一次停止創建虛擬服務。

使用服務虛擬化

讓我們來看一個例子。假設有一個現有的服務，它通過獲取一個傳入的帳號并返回該人的響應來提供有關該人的身份的信息，并且需要開發一個新的虛擬服務，在該服務中，該虛擬服務將基于帳號返回財務細節。

通過服務虛擬化，在創建新的虛擬服務時可以利用許多原始服務。將兩個服務分開的唯一內容是架構和數據。隨著組織構建越來越多的虛擬服務，可重復使用的工件庫也變得越來越大。這解決了最初的挑戰，即必須一遍又一遍地創建相同的虛擬服務。

共享虛擬服務

與模擬不同，虛擬服務是高度可共享的，內部模塊也可以重用。虛擬服務或pva文件可以存儲為XML，并且可以輕松地檢查到源代碼管理中。如果該服務模擬了特定API的特定功能，則可以在源代碼控制中或更在共享的虛擬化服務器上搜索工件。隨著團隊使用服務虛擬化的方式不斷增長，他們可以通過將桌面直接連接到服務器以搜索所需的工件，然后將其下拉到桌面并立即開始使用，來利用現有的服務器共享功能。這就解決了發現已創建的虛擬服務并立即對其進行訪問的挑戰。

捆綁虛擬服務

Parasoft Virtualize還提供了根據通用虛擬化用例構建的私有和公共工件的市場。這使您可以快速入門，并在整個組織中建立內部知識庫，從而簡化以后創建虛擬服務的過程。在開始利用虛擬服務時，您可以輕松地將該虛擬服務及其初始API綁定到命名約定或通過描述或標記。

然后，您的開發合作伙伴可以在網絡瀏覽器中搜索要為其模擬的API創建的任何虛擬資產，并準確查看已創建的內容并立即部署到其桌面：

這解決了將虛擬服務與特定的API和要求綁定在一起的挑戰。

與虛擬服務合作

最后，有了上述所有解決方案，您的團隊可以構建可持續的工作流程，使開發人員和測試人員在意識到需要模擬時可以選擇。無需花時間來回回蕩，他們可以向Parasoft生態系統查詢適合自己特定需求的模擬，如果存在，他們可以立即訪問它。如果沒有，他們可以創建一個虛擬服務，團隊可以重用該虛擬服務，將來任何需要它的人都可以發現它。這解決了相關協作的挑戰。

所以現在怎么辦？

您可以使用Parasoft Virtualize的免費版本（Virtualize Community Edition）來開始與您的虛擬基礎架構進行協作。我上面提到的所有內容都可以在此處找到，下載開始就可以開始－資產可以檢查到源代碼控制中，提升為共享的團隊服務器，然后上傳到團隊的私有市場。虛擬化快樂！