在服務虛擬化之前，康卡斯特的性能測試團隊經常會遇到圍繞共享測試基礎設施的調度沖突。有時，下游系統(tǒng)無法使用。其他時候，測試工程師會試圖同時進行測試，但是這可能會影響測試結果。這導致了測試之間的差異性，這使得隔離特定的問題具有挑戰(zhàn)性。本文將會介紹康卡斯特在Parasoft成功實施服務虛擬化后取得的成果，以及為什么服務虛擬化們DevOps計劃的關鍵組成部分。

挑戰(zhàn)

測試團隊在康卡斯特的團隊在公司的多個垂直領域執(zhí)行性能測試--從業(yè)務服務，到企業(yè)服務平臺，到面向客戶的用戶界面，再到為康卡斯特網絡上的用戶進行設備配置和激活的后端系統(tǒng)。雖然測試目標（AUT）通常擁有能夠準確代表生產系統(tǒng)性能的暫存環(huán)境，但AUT依賴的暫存系統(tǒng)卻沒有。

使問題更加復雜的是，這些環(huán)境很難進入。在能夠訪問時，有時會關閉較低的環(huán)境（QA或集成測試環(huán)境），因為它們沒有得到充分的擴展，無法處理負載。即使系統(tǒng)能夠承受負載，從這些系統(tǒng)中得到的響應時間也非常差。這意味著性能測試結果并不能真正預測真實世界的性能。

另一個問題是不得不在中轉環(huán)境中解決頻繁而漫長的停機問題。在頻繁的升級或軟件更新期間，暫存環(huán)境無法使用。因此，無法運行完整的性能測試。性能測試團隊不得不在關鍵時間段關閉關鍵項目，以保持忙碌--他們知道他們將無法從事他們的主要職責，因為他們需要訪問的系統(tǒng)無法使用。

這些挑戰(zhàn)導致成本增加，降低了團隊的效率，并影響了性能測試的可靠性和可預測性。康卡斯特知道他們必須采取行動--這就是開始研究服務虛擬化的原因。最終，發(fā)現(xiàn)實施服務虛擬化的時間和成本遠遠低于在所有這些暫存環(huán)境中實施各種系統(tǒng)或在不同暫存環(huán)境之間建立連接所需的時間和成本。

服務虛擬化帶來的可衡量成果

康卡斯特轉向服務虛擬化有兩個主要原因。首先，希望提高性能測試結果的準確性。第二，解決階段性的頻繁而漫長的停機問題。

他們最初關注的是性能測試團隊內部的調度沖突、不可用的系統(tǒng)以及測試會影響其他開發(fā)或測試組的系統(tǒng)等方面的最大痛點。自Parasoft開始以來，已經能夠將測試中涉及的約98%的接口虛擬化，并且看到每年用于創(chuàng)建和維護測試數(shù)據(jù)的時間減少了65%（考慮了用于創(chuàng)建和更新虛擬資產的時間）；還將暫存環(huán)境的停機時間減少了60%。

由于現(xiàn)在可以在開發(fā)環(huán)境中開始處理腳本與虛擬資產，所以Comcast的團隊通常在每個沖刺階段很早就準備好了一切。過去需要兩周的時間來對代碼進行性能測試，現(xiàn)在一旦把代碼放在暫存環(huán)境中（例如，平均負載測試、峰值負載測試、耐久性測試等等），就可將這個時間縮減到兩三天。

解決方案的優(yōu)勢

Parasoft使康卡斯特測試更可預測，更一致，更能代表生產中的情況。此外，還能夠在很多情況下增加測試的范圍。例如，不能將生產負載放在某些實際服務上，但當在使用虛擬服務時，可以用生產級負載來提升它，并在數(shù)據(jù)和性能方面得到真實的響應。可以真正地隔離AUT，不僅從性能測試的角度，而且從性能剖析的角度。

服務的虛擬化和DevOPS

除了在暫存環(huán)境中進行性能測試之外，還能夠將服務虛擬化用于從開發(fā)環(huán)境中的單元測試和回歸測試，到早期下游環(huán)境中的基線性能測試，再到QA/集成環(huán)境中的功能和回歸測試，以及在相當接近生產的環(huán)境中進行手動/探索性測試。

作為DevOps基礎架構的一部分，各種環(huán)境的虛擬資產的所有配置和部署都是自動化的。環(huán)境會根據(jù)定義的業(yè)務規(guī)則--例如，根據(jù)流量來自哪個端點、測試數(shù)據(jù)包中包含的數(shù)據(jù)等--在虛擬資產和實際資產之間自動切換。這種服務虛擬化解決方案讓Comcast實現(xiàn)了持續(xù)測試，成為DevOps流程中不可或缺的一部分。

以上就是Parasoft在康卡斯特的實施案例，parasoft還在金融、教育、醫(yī)療等等行業(yè)都有應用，您是否感興趣呢？如果您有任何疑問或需求，請隨時聯(lián)系慧都客服，我們很高興為您提供查詢和咨詢。