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

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

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

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

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

當云發(fā)布速度超過測試速度時

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

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

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

發(fā)生了什么變化？在現(xiàn)代云環(huán)境中，釋放速度呈指數(shù)增長。DevOps團隊正在使用基礎(chǔ)架構(gòu)代碼（IaC）定義，基于服務(wù)的快速集成和數(shù)據(jù)饋送，自動化部署管道以及無處不在的容器化。

在KubeCon的主題演講中，Airbnb運營工程師Melanie Cebula表示，她的團隊每周推出超過20000個容器化版本——那是一年前！盡管大多數(shù)企業(yè)可能永遠不會跟上Netflix和Airbnb的速度，但我們?nèi)韵Ｍ魏卧谡_的云環(huán)境中運行的公司的部署速度都可以提高一千倍。

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

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

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

達到逃逸速度以應(yīng)對變化

隨著公司擁抱DevOps運動，他們轉(zhuǎn)向功能強大的自動化管道，以在動態(tài)云體系結(jié)構(gòu)中實現(xiàn)連續(xù)發(fā)布和環(huán)境部署自動化。

測試必須是該管道的一流方面。未能及早且經(jīng)常在現(xiàn)實環(huán)境中測試軟件，并且在生產(chǎn)中出現(xiàn)的最終故障修復(fù)成本可能太高。

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

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

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

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

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

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

使測試與架構(gòu)一樣具有彈性

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

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

一家大型旅行公司正面臨著這樣的挑戰(zhàn)，他們開始將關(guān)鍵業(yè)務(wù)的忠誠度計劃應(yīng)用程序從現(xiàn)有的舊服務(wù)器群集遷移到具有公共云溢出功能的預(yù)留云應(yīng)用程序?qū)嵗?

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

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

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

The Intellyx Take

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

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

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

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