前言：
集成測驗是用來驗證所提交的系統的地方，也是企業可以實際查看應用程式并確認已構建的開發是否是其所需要的開發的地方，隨著軟體系統變得越來越組件化，而且由越來越多的服務組成，從代碼更改到集成測驗的延遲時間成為了產品投入市場和開發人員生產力的一個關鍵指標，
理想的程序很簡單，每次開發人員更改代碼，就快速運行所有測驗，并將反饋提交給開發人員，發生更改的組件被構建、單元測驗、部署到一個集成環境，所有集成測驗只需幾分鐘即可運行完，不幸的是，理想是美好的，現實卻是殘酷的，
自動化測驗要么進行的次數太少或進行的時間太長，可能無法實作持續集成，復雜應用程式的自動化部署可能需要特殊的工具，
那么，我們對如何解決這些難題已經有了很好的了解，應該使用大量的 API 測驗來自動化測驗，建立一個連續自動構建流程很簡單的，所以現在，讓我們來了解一些部署自動化工具有哪些？許多組織面臨一個越來越常見的挑戰，那就是缺乏集成測驗環境，這些集成測驗環境可能是不完整的，或者可能是不一致的，接下來就和大家為什么存在這些問題，以及如何處理它們，要知道他們從何處來，要到哪里去，
正文：
一.環境方面的限制
了解如何獲得更多、更高質量的測驗環境來加速反饋，您需要了解環境方面的一些約束條件，以下這些知識可以幫助您解決問題，
有限的硬體：運行測驗環境所需的資源，這些資源并不是免費的，
昂貴的設定費用：建立一個新的測驗環境需要配置服務器、配置中間件并讓應用程式運行，這些任務需要做相當多的作業，
昂貴的維護費用：需要努力維護配置、補丁水平等，與此同時，測驗環境的數量也在增加，
不一致的利用率：有時一個團隊需要多個環境，有時他們需要幾個環境，
昂貴的組件：一些應用程式組件在用于測驗時非常昂貴，這限制了您使用它們進行測驗的頻率，按照事務、主機組件和設備應用進行收費的第三方 Web 服務事務也是制約因素，
缺失的組件：有時另一個團隊擁有一個您需要測驗的服務，但他們還沒有交付該服務，這使得您擁有了一個不完整的解決方案，
被破壞的組件：當許多組件可能經常發生更改的時候，給定組件遭到破壞的可行性很高，
通常，這些集成測驗環境特征是相輔相成的，例如，對于長期存在的環境，昂貴的環境設定費用是可以容忍的，但是，由于不一致的利用率，對環境的需要可能是短暫的，維護那些一直受到維護的環境會容易一些，不幸的是，由于硬體成本，合理的做法是在不使用它們時關閉它們，
二.解決瓶頸的技術
有三種技術可用來消除集成測驗環境中的問題并提高它們的可用性：環境預留（environment reservation）、環境即服務和服務虛擬化，每項技術負責解決問題的不同部分，
A.環境預留
最簡單的策略是積極安排和管理環境，這通常是發布經理（release manager）的責任，集成環境被視為寶貴資源，集成環境是根據發布優先級和距離發布日期的時間被分配用于版本測驗的，現代版本管理工具（比如 IBM UrbanCode Release）可以提供正式的環境跟蹤、調度和沖突檢測，但電子表格仍被經常使用，
優勢
清楚地描述哪些版本可以使用某個環境，何時為開發和測驗團隊提供所需的可預見性，并從有限的資源中獲得最大的價值，
局限性
雖然環境預留有助于確保有限的資源得到很好的使用，但它并不會提供更多的環境或導致環境不一致，
B.環境即服務
請求一個適合您的應用程式的測驗環境并在幾分鐘內配給好它的能力是非常強大的，將云技術（公共云或私有云）與環境模式引擎（比如 UrbanCode Deploy with Patterns 相結合，使用它們來搭建環境、配置環境并在需要的時候退出環境，
優勢
使用環境即服務解決方案可以大大減少搭建測驗環境需要做的作業，這些解決方案還適當地更新了配置，以便有效地控制維護費用，同時改進生成環境，總而言之，團隊可以在需要的時候得到他們所需的集成環境，環境即服務技術應該是您的集成測驗策略的基石，
局限性
以較低的成本創造環境往往會鼓勵創建更多的環境，硬體費用可能是一個問題，特別是在非常大的集成環境中，使用相對廉價的云資源來構建環境有助于降低環境搭建成本，因為環境易于創建和退出，所以人們經常使用環境，相反，您可以在不使用資源的時候回收資源，并在需要的時候執行環境備份，
因為這個策略是建立在云計算和虛擬化之上，許多 “珍貴” 的組件無法作為一種服務策略巧妙地融合到環境中，它們需要由多個已配置好的環境進行共享，或者需要虛擬化，
來自其他團隊的遭到破壞的組件可能是一個問題，但是，如果各大團隊都有自己的集成環境，而且使用了其他組件的惟一已知良好版本的自動化部署，那么他們可以使用環境即服務（environments as a service）來實作隔離的環境作為一種服務，
C.虛擬化服務
服務虛擬化使用 “存根（Stub）” 或 “模擬物（mocks）” 替換了系統中的一些組件，模擬是我們已經使用了很長一段時間的一種方法，開發人員撰寫了一個功能類似于完整服務的一項服務，并對它進行了測驗，例如，如果一個股票報價服務提供了每筆交易的第三方費用，那么開發人員就可以創建一個替代服務，該服務將會提供相同的 API，但總是回傳相同的值來進行測驗，服務虛擬化工具類似于 IBM Rational Test Workbench 中的那些工具，簡化了創建存根的程序，并對運行它們的地方和執行它們的方式進行管理，
優勢
服務虛擬化提供了一個簡便方法來處理這些 “珍貴” 組件，存根可以替代那些按使用進行收費的組件，或者替代那些獨一無二的組件（主機、昂貴的中間件或設備），
存根還可以替代那些來自其他團隊的組件，存根有三個主要優勢：
一定程度的隔離，您有一個很有用的集成測驗環境，甚至在另一個團隊破壞了他們的組件的時候也很有用，
資源的使用，不再需要那些用來運行其他組件所需的服務器容量，
存根可以替代那些尚未完成的組件，讓您在生命周期的早期就能訪問集成的測驗場景，
局限性
在測驗真實的東西而不是存根的時候，測驗是更加相關的，隔離功能可以防止另一個團隊破壞您的作業，但也會推遲整個集成系統的測驗，推遲測驗會帶來一定的成本，因為它級訓了反饋，服務虛擬化無法幫助管理已經存在的組件環境，
在這里想大家推薦一個資料分享群：175317069
匯總了一些技巧的一個現實場景
一個被稱為 Marketplace 的主系統的虛擬示例展示了如何組合使用這些工具，Marketplace 由許多部件組成，
60 個緊密耦合的 Web 服務，四個團隊，每個團隊擁有 15 項服務，
主機組件促成了 20% 的交易；這些組件很少發生更改，而且屬于另一個團隊，
前端網站（位于服務的前端）是屬于網站團隊的，
使用了來自兩個第三方的資料提要（通過 Web 服務），一個是按交易進行計算的，另一個不是，Marketplace 版本團隊有一個大型的集成測驗環境 (INT) 和一個性能測驗環境 (PERF)，每六個團隊擁有一個小型的測驗實驗室，在該實驗室里，他們可以測驗一些組件，但是他們不能測驗任何集成場景，集成測驗是按照版本發布時間表進行的，而版本管理控制了對 INT 和性能環境的訪問，
D.團隊級集成環境
為了提高開發人員的生產力，Marketplace 組織決定確保每個開發團隊都有自己的集成測驗環境，如果他們想要測驗額外的代碼行或者想要達到更高的發展高峰，他們能夠獲得額外的環境，
環境即服務 (EaaS)：EaaS 工具提供了使用公司內部云應用的一份副本，使用了獲得開發團隊的服務所需的足夠多的虛擬機器，以及最新的 UI 作業副本，
服務虛擬化：來自其他 Web 服務團隊的服務和主機被虛擬化，已計量的第三方服務被虛擬化，但其他服務是被實時使用的，
環境預留：為了獲得可見性，讓 Release Management 工具中的預留系統知道在哪個環境中托管了版本發布作業，不過，由于不缺少環境，所以團隊級別的環境沒有被保留，
最后，每個開發團隊都有一些大量使用了服務虛擬化的小型的、廉價的環境，盡管他們能夠在更大的系統中測驗他們的組件，但他們是獨立于其他團隊的，其他團隊可能破壞了自己的組件，或者擔心自己會破壞其他團隊的組件，然而，大量利用虛擬化意味著跨服務的集成問題不會立即被發現，
E.版本級別的集成環境
每個版本的系統集成測驗環境都已配置好，這些環境大部分都是完整的，而且只使用了最低限度的服務虛擬化，要進入該環境，必須在團隊級別環境中成功地將更改傳遞給一組可靠的自動化測驗，
環境即服務：EaaS 可以提供許多可能長期存在的環境：
一個測驗環境，用于為當前版本提供補丁
一個大量使用的環境，用于即將發布的版本
一個偶然使用的環境，用于稍后執行的大量開發作業EaaS 主要負責讓環境與正確的基礎架構相一致，
F.服務虛擬化：
只有主機和已計量的 Web 服務被虛擬化，
環境預留：這些環境都是大型環境，所以硬體都比較昂貴，在需要額外的環境時，可能會使用環境預留來觀察實體，盡可能地減少對額外環境的使用，與團隊環境類似，此系統主要用于確保每個人都對正確的版本使用了正確的環境，
因為大量的集成測驗都是在團隊級別環境中執行的，所以在這個環境中，干擾測驗的更改非常少，對于手動測驗者，這些環境可能會花費他們的時間，他們可以從高可用性的組合中受益，而且總是采用最新的好代碼，
G.性能測驗
性能測驗基本上沒什么大的變化，仍然是最大的環境，服務虛擬化對 Web 服務和主機均可用，對于主機和計量服務，在執行事務數量較多的測驗程序中偶爾會使用虛擬化，在其他性能測驗場景中，用于兩個第三方 Web 服務的存根均被設定為緩慢回應請求，以便在第三方供應商遇到麻煩時驗證應用程式的行為，
H.最終的集成測驗
集成測驗環境被用于最終的集成驗證，因為它提供了對一些稀有資源（比如計量服務的實時版本和主機組件）的訪問，環境預留系統仍用于將此資源分配給所期望的版本，
模式
上述示例中經過檢查的模式是一種非常常用的模式，開發人員更喜歡使用小型的、高度虛擬化的環境，因為他們可能經常使用和關倍訓境，并積極地利用環境配置，在這種環境中，環境配置被用于構建更完整的集成環境，而服務虛擬化提供了更少的東西，在后期的測驗環境中，以前的資源被安排并分配給版本，在最能發揮每種方法的作用的地方使用它們，用其他方法的優勢來彌補每種方法的局限性，通過這種方式，團隊可以從資源調度、服務虛擬化和環境即服務的組合使用中獲得最大的好處，
對以上測驗資料，測驗技術感興趣的朋友，歡迎加QQ群：602830685,群中會不期的分享軟體測驗資源，測驗面試題以及行業資訊，大家也可以關注我的微信公眾號，程式媛一菲，有更多的學習資源與大家共享，
**寫在最后：
看累了專業知識，我們也來吟詩，我們談談積少成多，**
1、騏驥一躍，不能十步；駑馬十駕，功在不舍，
2、鍥而舍之，朽木不折；鍥而不舍，金石可鏤，
3、不積小流，無以成江河，
4、不積跬步，無以至千里，
5、千里之行，始于足下，
最后讓我們每天努力一點點，期待屬于大家的一飛沖天，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/252499.html
標籤：其他