【51CTO.com快譯】朋友，您還記得小時候聽過的《三只小豬》的故事嗎?面對大灰狼的來襲，只有建造了堅固的房屋(基礎設施)的第三只小豬，才能逃過一劫。現如今，面對各種高速發展的持續集成與交付要求，我們同樣需要構建好具有自動化特征的基礎環境，以便快速地開展各種高性能的測試。

[[328829]]

下面，我們來看看如何通過目標、技術和團隊的準備，在快速增長的環境中，實現敏捷地高性能測試與發布。

定義高性能測試

從理論上說，那些具有高增長特征的初創企業最渴望高性能的測試。它們通常具有如下的“敏捷”特征：

• 混亂狀態–需要適應瞬息萬變的內、外部環境。
• 更少的用時–所有問題都需要得到全員的重視，并需要得到及時的解決。
• 更少的資源–由于現有資源有限，因此需要善于向外部“借勢”，以促進當前項目的集成與交付。
• 市場壓力–需要了解和評估外部風險，以迅速調整內部策略。
• 獎勵–善于發現點滴改進，及時反饋并鼓勵整個團隊。

為何要進行高性能測試?

縱觀整個行業，應用業務技術在過去十年中發生了如下巨大的變化：

• 使用范圍–當前的應用服務往往可以運行在多個平臺(Web應用端、或移動設備)上，而非某個專有的應用程序、或單個瀏覽器上。
• 發布頻率-我們經常按需且頻繁地發布應用程序。
• 流程–我們已經從瀑布式的開發方式，轉變成為了持續交付。
• 框架-過去的單棧本地部署(singe-stack on-premise)軟件模式，已經轉變成為如今使用開源、基于云端的開發與交付模式。

總之，我們沿用了十年的“最后再進行測試”的模式，已經不再行之有效。我們正在建立一種新的測試模式。

如何實現高性能測試

為了滿足快速增長的環境需求，軟件團隊需要盡早了解現有的情況，以著手解決各種矛盾和問題。例如：您既可以使用思維導圖將情況可視化，也可以通過劃分短期和長期目標，讓功能性團隊專注于測試，讓框架團隊專注于系統的長期架構。

另一個值得關注的目標是：如何通過測試左移，盡早地發現缺陷。為此，我們需要了解現有的工具和需要添置的工具，軟件質量的行業標準，本團隊當前在構建自動化架構方面的實力，以及如何通過AI和機器學習(ML)的支持來提高效率。

建立團隊

接下來，我們來討論如何建立一支高性能測試的團隊。

過去我們依靠的是專職的質檢(QA)服務團隊。如今，我們需要配備了集成Pod的真正敏捷團隊。質量工程師作為他們的團隊資源，在整個開發和交付過程中提供協助。在團隊中，我們需要有人熟悉行為驅動設計(behavior-driven design)和測試驅動設計(test-driven design)，有人會選擇并使用自動化工具，有人需要考慮可測試性設計(design-for-testability)。

由于測試自動化的大部分會涉及到框架，因此我們需要熟悉構建代碼的技能集，通過自動識別元素定位符(self-identifies element locators)，來構建用于自動化控件的鉤子(hooks)，進而確保每次構建的一致性和實現自動化的可重復性。

測試自動化

過去，我們需要從單個供應商那里購買一整套測試工具。如今，開源的解決方案為自動化提供了豐富的資源。開源的方式不但可以降低維護的成本，而且能夠讓您更快、更容易地交付出具有可擴展性的軟件產品。作為開源工具的“衍生品”，用戶社區往往能夠提供某些工具的最佳實踐，以及各種寶貴的課程可供學習。

通常，我們可以在軟件部署過程中的如下方面實現自動化：

• 斷言行為(Assertions on Action)
• 初始化和清理
• 數據建模與模擬
• 配置
• 各種安全建模的抽象
• 包和幫助
• API的使用情況
• 各項面向未來的功能
• 本地和云端設置
• 速度
• 各種調試功能
• 跨瀏覽器
• 模擬器與真實設備
• 內置的報告與插件

行業標準

如今，對于自動化測試，業界基本上形成了如下四種類型的標準：

• 質量–至少要能夠通過全部測試的90%。
• 運行時間–所有測試的平均運行時間應控制在兩分鐘之內。
• 平臺覆蓋率–平均覆蓋五個關鍵性的被測平臺。
• 并發性–在使用高峰期，測試至少要占用75%的可用運能。

生產環境的測試

您是否考慮過將測試移至生產環境(Shift Right)?我們提出該方法的原因有如下四個方面：

• 功能標記–在生產環境中進行測試，可以采集到真實的數據，以用于測試。
• 流量分配–我們可以逐步引入新的功能，并在不影響整個客戶群體驗的情況下，針對被測案例，跟進獲取到的部分目標用戶的實時數據。
• 內部測試(Dog Fooding) –采用CDN之類的快速部署功能，將內部用戶引導到新的功能服務上。
• 凈減少–通過減少額外的開銷，使應用程序可以使用真實的數據集進行測試，并且能在不影響整個客戶群的情況下快速定位問題。

總之，生產環境中的測試，可以讓累計的大型發布，變成一組組基于通用代碼的小型迭代。由于有不同職能的人員參與測試，因此也確保了客戶群不會因為大幅度升級而感到不適。

人工智能(AI)/機器學習(ML)

AI/ML工具的使用不但能夠提高整個團隊的工作效率，而且還能夠滿足高性能測試環境的質量需求。其中，Applitools就是一個被AI賦能了的測試工具。它通過自動化視覺AI，來開展各種回歸式的視覺測試，自動驗證頁面的提交，進而幫助企業以更低的成本，更快地發布軟件項目。例如：某個醫藥網站有著上百個介紹藥物適應癥和注意事項的頁面。為了確保這些頁面一致性，我們可以使用Applitools去進行驗證。它可以在不到12分鐘的時間內完成完整的視覺回歸，并運行350個測試案例，其中包括2500項檢查。而我們如果采用手動驗證的話，則需要六個小時以上。

ReportPortal.io

作為一個統一的自動化測試平臺，ReportPortal.io可以實現報告的收集，分析，可視化，以及集成多種測試框架，其中包括：TestNG和Selenium等。在實際應用中， Reportportal.io能夠顯示一天中不同時段的測試運行方式，發現其中的錯誤，進而幫助團隊實現無縫的發布和改善其統計的信息。同時，Reportportal.io中任何失敗的測試用例，都可以被作為測試結果日志，直接鏈接到Reportportal.io的用戶界面中。

此外，我們可以配合使用行為驅動設計(BDD)，來描述被測功能的所需行為，進而滿足客戶所需的高性能和高可用性。

設立質量目標

我們在快速增長的環境中，需要事先設立軟件的質量目標，以滿足用戶和運行環境的需求。其中包括：

• 有分布式質量檢查小組，提供7*24的質量檢查支持。
• 有專門從事測試的SDET(軟件測試開發人員)團隊。
• 有一個能夠簡化任何POC(為觀點提供證據)的即插即用式強大框架。
• 一個使用Travis(自動化集成部署服務)測試的穩定管道。
• 通過完全自動化將回歸的時間減少90%。

建立團隊和技術棧

當然，為了實現上述目的，我們需要雇用一個具有開發素養和測試素養的團隊，也就是說，他們應當同時具備編程和測試自動化的相關能力。同時，我們在技術棧方面的投入包括如下方面：

• Python和Selenium WebDriver。
• BDD。
• 能夠在云端運行的Browserstack。
• 針對視覺回歸的Applitools。
• Jenkins、Travis和Google Drone for CI。
• Jira和TestRail的相關文檔。

在此基礎上，我們可以確定CI/CD的四項成功標準：

• 速度與并行化(parallelization)。
• BDD易于調試與閱讀。
• 在CI/CD中實現跨瀏覽器、跨設備的覆蓋。
• 實現視覺驗證。

為CI/CD測試設定QA期望

在CI/CD的環境中，測試和構建往往并非同步進行的。因此，我們需要事先設定好構建與測試的頻率。您可以借鑒如下公司的設定標準：

• 質量檢查人員每小時針對最新的版本運行73次測試，以檢查目標站點是否能正常運行。
• 任何新的構建都需要在6種跨瀏覽器上試運行，并確保涉及到所有的關鍵性業務路徑。
• 除部分測試外，每晚例行執行300個回歸測試。

當然，上述只是某些個案，您可以根據自身企業和項目的特點，不斷地進行增加和完善。

結論

俗話說：“工欲善其事，必先利其器”。正如我們開頭提到的《三只小豬》的故事那樣，要想在高速增長的公司內部，讓質量工程師能夠迅速地開展成功有效的高性能測試，我們需要對自動化、團隊人員、AI/機器學習、乃至基礎架構，事先進行有針對性的投資、改造和完善。

【原標題】Acing High-Performance Tests for CI/CD (作者: Michael Battat )

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】