現在很難找到一個完全沒有任何云遷移策略的可行公司。

領先的公司將采取全有或全無的方式進行此遷移——堅持要求所有業務功能最終都必須解決某種彈性云的使用問題，無論是在領先的IaaS（如AWS或Azure）中，還是在本地或定制私有云。

即使是市場落后者，也有計劃將至少一個應用程序轉移到按需云實例上——在嘗試之前先試試水。

企業可以使用云來加速開發并實現交付環境的現代化，但是一件事永遠不會改變的：客戶仍然希望軟件能夠在生產環境中按預期的方式運行和運行，無論部署在何處。

他們需要應用程序具有高可用性、安全性和彈性，否則它們將移至其他地方。這使測試自動化成為成功的關鍵門控功能。

當云發布速度超過測試速度時

一家全球500強金融服務公司John Hancock最近宣布與云服務提供商CGI一起啟動一個向私有云IaaS過渡的項目，該項目估計耗資1.42億美元。

沒錯，大部分預算不是云費用，而是勞力。為云重新配置企業應用程序顯然不是一件容易的事。集成、測試和持續驗證應用程序需要艱巨的工作，而在每次發行后維護測試時，這項工作通常會被取消。

但這并不是什么新鮮事。這樣的返工成本肯定在云計算之前就已經存在。

發生了什么變化？在現代云環境中，釋放速度呈指數增長。DevOps團隊正在使用基礎架構代碼（IaC）定義，基于服務的快速集成和數據饋送，自動化部署管道以及無處不在的容器化。

在KubeCon的主題演講中，Airbnb運營工程師Melanie Cebula表示，她的團隊每周推出超過20000個容器化版本——那是一年前！盡管大多數企業可能永遠不會跟上Netflix和Airbnb的速度，但我們仍希望任何在正確的云環境中運行的公司的部署速度都可以提高一千倍。

那么，那些不是誕生于云中的公司又會離開世界其他地方呢？

任何高級開發人員或測試工程師都認為代碼本身是一種責任。您編寫的代碼越多，您測試該代碼的需求就越多——隨著時間的推移，您編寫和維護的測試代碼也就越多。

如果我們不能解決維持測試代碼所伴隨的阻力系數，則達到逃逸速度不再是提高部署和發布速度的問題。

達到逃逸速度以應對變化

隨著公司擁抱DevOps運動，他們轉向功能強大的自動化管道，以在動態云體系結構中實現連續發布和環境部署自動化。

測試必須是該管道的一流方面。未能及早且經常在現實環境中測試軟件，并且在生產中出現的最終故障修復成本可能太高。

大多數測試和開發小組在實際情況下將商業工具和開源結合使用，以實現自動化的測試和依賴關系的模擬（也稱為“服務虛擬化”）。最受歡迎的開源Web測試自動化工具是Selenium，它允許測試人員通過被測系統重現基于瀏覽器的工作流。

盡管Selenium的核心元素已經存在多年了，但合作伙伴活動和開發人員對該項目的貢獻最近已經升溫。在過去的3-5年中，Selenium已成為大多數業務開發/測試團隊的工具鏈的一部分。

無論軟件團隊運行多少代碼級、集成和性能測試，使用諸如Selenium之類的工具從用戶角度進行功能測試仍然是最終的選擇。在所有目標瀏覽器和設備上重復測試Web UI對于成功至關重要。

現在，可重復性——事情變得如此繁瑣。當后端業務邏輯和數據在運行時在Web UI中動態表示時，無論是通過瀏覽捕獲還是由測試人員手動修改，屏幕上都會發生無數異常現象，這些異常破壞了Selenium測試腳本。

例如，項目可能以不同的順序加載到頁面上的不同位置，或者包含超出Selenium測試腳本期望值的數據值或圖像。

測試人員和SRE（站點或服務可靠性工程師）可以嘗試創建自定義處理程序來解決錯誤的故障，調整代碼以允許某些參數具有靈活性，但是不久之后，將無法信任任何手動維護功能套件的結果測試，這是由于云后端體系結構的根本變化，這些變化永遠不會停止在動態Web UI中產生不一致。

使測試與架構一樣具有彈性

抵消云不斷超越應用程序測試的最佳方法？將相同的DevOps原則“一切自動化”應用于測試自動化本身的維護！

盡管市場上有一些專有的自動化工具可以覆蓋整個測試生命周期，但也有一些方法可以使用開源工具來增強測試人員的能力。

一家大型旅行公司正面臨著這樣的挑戰，他們開始將關鍵業務的忠誠度計劃應用程序從現有的舊服務器群集遷移到具有公共云溢出功能的預留云應用程序實例。

最初的版本已經過全面測試，并且相當成功，但是隨著另外三個點的發布過程中增加了更多的客戶，他們的第一批Selenium測試套件開始以很高的比率失敗。更改測試的人工成本，以及由于冗余計算使用導致的云成本增加，開始對項目產生負面的管理看法。

幸運的是，他們能夠使用一個增強其Selenium測試套件的工具，應用基于AI的方法來解釋頁面上的對象，并“自我修復”測試以適應網絡用戶界面中觀察到的變化情況。

如此高的測試彈性可將公司的測試維護成本降低多達75％，同時使他們可以提前兩周完成Selenium和Selenic的上線工作，并且隨著遷移的進行，故障風險大大降低。

The Intellyx Take

公司有明確的意圖將應用程序遷移到云中，但是遷移的后果和成本還遠遠不夠。

如果要對現有的整體進行現代化改造并更快地發布新功能以滿足客戶需求，則仍然需要進行大量功能和回歸測試。實際上，測試是如此之多，以至于即使是最熟練，最高效的測試工程師也無法編寫代碼并運行足夠的測試來跟上進度。

確保測試的彈性（通過具有可以自我測試并自我修復的測試）是測試能夠跟上云帶來的快速變化的唯一途徑。

下一步：避免開源沖突，降低使用開源軟件進行開發的風險。