整合測試是用來驗證所提交的系統的地方，也是企業可以實際檢視應用程式並確認已構建的開發是否是其所需要的開發的地方。隨著軟體系統變得越來越元件化，而且由越來越多的服務組成，從程式碼更改到整合測試的延遲時間成為了產品投入市場和開發人員生產力的一個關鍵指標。

理想的過程很簡單。每次開發人員更改程式碼，就快速執行所有測試，並將反饋提交給開發人員。發生更改的元件被構建、單元測試、部署到一個整合環境，所有整合測試只需幾分鐘即可執行完。

不幸的是，對於許多團隊而言，理想過程是不現實的。自動化測試要麼進行的次數太少或進行的時間太長，可能無法實現持續整合。複雜應用程式的自動化部署可能需要特殊的工具。

目前，我們對如何解決這些難題已經有了很好的瞭解。應該使用大量的 API 測試來自動化測試。建立一個連續自動構建流程很簡單，所以沒有理由不建立這樣的流程。現在，讓我們來了解一些部署自動化工具。

然而，許多組織面臨一個越來越常見的挑戰，那就是缺乏整合測試環境。這些整合測試環境可能是不完整的，或者可能是不一致的。只瞭解這些可能是不夠的。本文將考察為什麼存在這些問題，以及如何處理它們。

環境方面的限制

瞭解如何獲得更多、更高質量的測試環境來加速反饋，您需要了解環境方面的一些約束條件。以下這些知識可以幫助您解決問題。

• 有限的硬體：執行測試環境所需的資源。這些資源並不是免費的。
• 昂貴的設定費用：建立一個新的測試環境需要配置伺服器、配置中介軟體並讓應用程式執行。這些任務需要做相當多的工作。
• 昂貴的維護費用：需要努力維護配置、補丁水平等，與此同時，測試環境的數量也在增加。
• 不一致的利用率：有時一個團隊需要多個環境，有時他們需要幾個環境。
• 昂貴的元件：一些應用程式元件在用於測試時非常昂貴，這限制了您使用它們進行測試的頻率。按照事務、主機元件和裝置應用進行收費的第三方 Web 服務事務也是制約因素。
• 缺失的元件：有時另一個團隊擁有一個您需要測試的服務，但他們還沒有交付該服務。這使得您擁有了一個不完整的解決方案。
• 被破壞的元件：當許多元件可能經常發生更改的時候，給定元件遭到破壞的可行性很高。

通常，這些整合測試環境特徵是相輔相成的。例如，對於長期存在的環境，昂貴的環境設定費用是可以容忍的，但是，由於不一致的利用率，對環境的需要可能是短暫的。維護那些一直受到維護的環境會容易一些。不幸的是，由於硬體成本，合理的做法是在不使用它們時關閉它們。

解決瓶頸的技術

有三種技術可用來消除整合測試環境中的問題並提高它們的可用性：環境預留（environment reservation）、環境即服務和服務虛擬化。每項技術負責解決問題的不同部分。

環境預留

最簡單的策略是積極安排和管理環境。這通常是釋出經理（release manager）的責任。整合環境被視為寶貴資源，整合環境是根據釋出優先順序和距離釋出日期的時間被分配用於版本測試的。現代版本管理工具（比如 IBM UrbanCode Release）可以提供正式的環境跟蹤、排程和衝突檢測，但電子表格仍被經常使用。

優勢

清楚地描述哪些版本可以使用某個環境，何時為開發和測試團隊提供所需的可預見性，並從有限的資源中獲得最大的價值。

侷限性

雖然環境預留有助於確保有限的資源得到很好的使用，但它並不會提供更多的環境或導致環境不一致。

環境即服務

請求一個適合您的應用程式的測試環境並在幾分鐘內配給好它的能力是非常強大的。將雲技術（公共雲或私有云）與環境模式引擎（比如 UrbanCode Deploy with Patterns 相結合，使用它們來搭建環境、配置環境並在需要的時候退出環境。

優勢

使用環境即服務解決方案可以大大減少搭建測試環境需要做的工作。這些解決方案還適當地更新了配置，以便有效地控制維護費用，同時改進生成環境。總而言之，團隊可以在需要的時候得到他們所需的整合環境。環境即服務技術應該是您的整合測試策略的基石。

侷限性

以較低的成本創造環境往往會鼓勵建立更多的環境。硬體費用可能是一個問題，特別是在非常大的整合環境中。使用相對廉價的雲資源來構建環境有助於降低環境搭建成本。因為環境易於建立和退出，所以人們經常使用環境。相反，您可以在不使用資源的時候回收資源，並在需要的時候執行環境備份。

因為這個策略是建立在雲端計算和虛擬化之上，許多 “珍貴” 的元件無法作為一種服務策略巧妙地融合到環境中。它們需要由多個已配置好的環境進行共享，或者需要虛擬化。

來自其他團隊的遭到破壞的元件可能是一個問題，但是，如果各大團隊都有自己的整合環境，而且使用了其他元件的惟一已知良好版本的自動化部署，那麼他們可以使用環境即服務（environments as a service）來實現隔離的環境作為一種服務。

虛擬化服務

服務虛擬化使用 “存根（Stub）” 或 “模擬物（mocks）” 替換了系統中的一些元件。模擬是我們已經使用了很長一段時間的一種方法。開發人員編寫了一個功能類似於完整服務的一項服務，並對它進行了測試。例如，如果一個股票報價服務提供了每筆交易的第三方費用，那麼開發人員就可以建立一個替代服務，該服務將會提供相同的 API，但總是返回相同的值來進行測試。服務虛擬化工具類似於 IBM Rational Test Workbench 中的那些工具，簡化了建立存根的過程，並對執行它們的地方和執行它們的方式進行管理。

優勢

服務虛擬化提供了一個簡便方法來處理這些 “珍貴” 元件。存根可以替代那些按使用進行收費的元件，或者替代那些獨一無二的元件（主機、昂貴的中介軟體或裝置）。

存根還可以替代那些來自其他團隊的元件。存根有三個主要優勢：

• 一定程度的隔離。您有一個很有用的整合測試環境，甚至在另一個團隊破壞了他們的元件的時候也很有用。
• 資源的使用。不再需要那些用來執行其他元件所需的伺服器容量。
• 存根可以替代那些尚未完成的元件，讓您在生命週期的早期就能訪問整合的測試場景。

侷限性

在測試真實的東西而不是存根的時候，測試是更加相關的。隔離功能可以防止另一個團隊破壞您的工作，但也會推遲整個整合系統的測試。推遲測試會帶來一定的成本，因為它減緩了反饋。服務虛擬化無法幫助管理已經存在的元件環境。
在這裡想大家推薦一個資料分享群：175317069

彙總了一些技巧的一個現實場景

一個被稱為 Marketplace 的主系統的虛擬示例展示瞭如何組合使用這些工具。Marketplace 由許多部件組成。

• 60 個緊密耦合的 Web 服務。四個團隊，每個團隊擁有 15 項服務。
• 主機元件促成了 20% 的交易；這些元件很少發生更改，而且屬於另一個團隊。
• 前端網站（位於服務的前端）是屬於網站團隊的。
• 使用了來自兩個第三方的資料提要（通過 Web 服務）。一個是按交易進行計算的，另一個不是。

Marketplace 版本團隊有一個大型的整合測試環境 (INT) 和一個性能測試環境 (PERF)。每六個團隊擁有一個小型的測試實驗室，在該實驗室裡，他們可以測試一些元件，但是他們不能測試任何整合場景。整合測試是按照版本釋出時間表進行的，而版本管理控制了對 INT 和效能環境的訪問。

團隊級整合環境

為了提高開發人員的生產力，Marketplace 組織決定確保每個開發團隊都有自己的整合測試環境，如果他們想要測試額外的程式碼行或者想要達到更高的發展高峰，他們能夠獲得額外的環境。

• 環境即服務 (EaaS)：EaaS 工具提供了使用公司內部雲應用的一份副本。使用了獲得開發團隊的服務所需的足夠多的虛擬機器器，以及最新的 UI 工作副本。
• 服務虛擬化：來自其他 Web 服務團隊的服務和主機被虛擬化。已計量的第三方服務被虛擬化，但其他服務是被實時使用的。
• 環境預留：為了獲得可見性，讓 Release Management 工具中的預留系統知道在哪個環境中託管了版本釋出工作。不過，由於不缺少環境，所以團隊級別的環境沒有被保留。

最後，每個開發團隊都有一些大量使用了服務虛擬化的小型的、廉價的環境。儘管他們能夠在更大的系統中測試他們的元件，但他們是獨立於其他團隊的。其他團隊可能破壞了自己的元件，或者擔心自己會破壞其他團隊的元件。然而，大量利用虛擬化意味著跨服務的整合問題不會立即被發現。

版本級別的整合環境

每個版本的系統整合測試環境都已配置好。這些環境大部分都是完整的，而且只使用了最低限度的服務虛擬化。要進入該環境，必須在團隊級別環境中成功地將更改傳遞給一組可靠的自動化測試。

• 環境即服務：EaaS 可以提供許多可能長期存在的環境：
  • 一個測試環境，用於為當前版本提供補丁
  • 一個大量使用的環境，用於即將釋出的版本
  • 一個偶然使用的環境，用於稍後執行的大量開發工作EaaS 主要負責讓環境與正確的基礎架構相一致。
• 服務虛擬化：只有主機和已計量的 Web 服務被虛擬化。
• 環境預留：這些環境都是大型環境，所以硬體都比較昂貴。在需要額外的環境時，可能會使用環境預留來觀察例項，儘可能地減少對額外環境的使用。與團隊環境類似，此係統主要用於確保每個人都對正確的版本使用了正確的環境。

因為大量的整合測試都是在團隊級別環境中執行的，所以在這個環境中，干擾測試的更改非常少。對於手動測試者，這些環境可能會花費他們的時間，他們可以從高可用性的組合中受益，而且總是採用最新的好程式碼。

效能測試

效能測試基本上沒什麼大的變化，仍然是最大的環境。服務虛擬化對 Web 服務和主機均可用。對於主機和計量服務，在執行事務數量較多的測試過程中偶爾會使用虛擬化。在其他效能測試場景中，用於兩個第三方 Web 服務的存根均被設定為緩慢迴應請求，以便在第三方供應商遇到麻煩時驗證應用程式的行為。

最終的整合測試

整合測試環境被用於最終的整合驗證。因為它提供了對一些稀有資源（比如計量服務的實時版本和主機元件）的訪問。環境預留系統仍用於將此資源分配給所期望的版本。

模式

上述示例中經過檢查的模式是一種非常常用的模式。開發人員更喜歡使用小型的、高度虛擬化的環境。因為他們可能經常使用和關閉環境，並積極地利用環境配置。在這種環境中，環境配置被用於構建更完整的整合環境，而服務虛擬化提供了更少的東西。在後期的測試環境中，以前的資源被安排並分配給版本。在最能發揮每種方法的作用的地方使用它們，用其他方法的優勢來彌補每種方法的侷限性。通過這種方式，團隊可以從資源排程、服務虛擬化和環境即服務的組合使用中獲得最大的好處。

當真正開始學習的時候頻繁踩坑，最終浪費大量時間，所以有一套實用的視訊資料用來跟著學習是非常有必要的。

這套視訊資料詳細講解了（自動化程式設計，mysql調優，自動化框架rf使用）。

那麼，這套視訊我們應該怎麼獲取呢？

對以上測試資料，測試技術 感興趣的朋友，歡迎加QQ群：175317069，一起學習，相互討論。

群內已經有小夥伴將知識體系整理好（筆記，學習視訊，面試題），歡迎加群免費取。