[[323920]]

【51CTO.com快譯】現如今，無論是軟件測試人員，還是利益相關者，都已經認識到：實現測試自動化框架對于軟件項目的成功是至關重要的。它不但能夠提高測試的效率，而且可以減少人工干預的工作量。

在本文中，我們將深入探討什么是真正的測試自動化框架，自動化腳本是如何工作的，以及此類框架是如何在測試過程中給團隊提供競爭優勢的。

定義測試自動化

在任何行業中，自動化通常被解釋為通過智能算法，來自動處理各種流程，而且幾乎不需要人工的干預。在軟件行業中，測試自動化意味著：使用受許可版本或開源版本的自動化工具，對軟件應用程序執行各項測試。從技術角度來說，測試自動化框架是一組定制的交互式組件，它可以協助執行腳本化的測試，并全面地報告測試結果。

為了成功地構建自動化框架，軟件質量保證專家必須通過全面考慮與設計，來控制和監視整個測試過程，并提高結果的準確性。與此同時，那些經過精心設計的自動化框架也能夠讓測試人員以實用、簡化的方式，來執行各項自動化的測試。

通常，根據自動化需求目標的不同，我們可以選擇并創建如下不同的框架：

以工具為中心的框架

無論是商業版工具還是開源的自動化工具，它們都擁有自己的系統框架，可以在各種測試環境中提供測試套件，實施分布式測試，并最終生成報告。最典型的示例當屬Selenium自動化框架。該框架的主要組件是WebDriver。作為基于Web的瀏覽器插件，該組件可被用于控制和操作Web瀏覽器中應用程序的DOM模型。此外，Selenium自動化框架還帶有各種實用的編碼庫，以及支持記錄回放的工具。

Serenity是另一個自動化工具的框架。它圍繞著Selenium Web驅動構建了一個加速器。為加快測試自動化實施過程的速度，Serenity還能夠將特定的組件與社區內的其他工具相組合。

除了上述兩種工具，業界還有TestComplete、以及Ranorex HP QTP等工具。作為已部署的預構建框架，它們都帶有用戶行為模擬器、報告和腳本IDE等功能。

面向項目的框架

定制此類框架主要是用于實現特定應用項目的自動化。特定項目的框架既可以支持某些目標應用的測試自動化需求，又能夠被開源庫構建的組件所驅動。此類框架圍繞著被測系統(System Under Test，SUT)創建了一個友好的測試環境，以運行和覆蓋各種基本功能。其中包括：對已開發的應用進行部署，運行，并且通過包裝器(Wrapper)的控制以簡化編碼，執行測試用例，以及輸出測試結果報告。面向特定項目的框架還應該通過組件，以支持在不同的操作系統和瀏覽器上，進行跨多種云端環境的測試。

關鍵字驅動的框架

這是一些旨在給開發人員和測試人員帶來較少代碼體驗的框架。那些被應用于代碼之中的關鍵字集(如：Login、NavigateToPage、Click、以及TypeText)會被安裝到代碼庫中，作為一個關鍵字的存儲庫。根據給定的關鍵字，測試人員可以參考編寫處對應的腳本，并以電子表格的形式，傳遞到關鍵字解釋器中，予以執行和測試。因此，對于技能不足的人員來說，他們能夠據此輕松地編寫和理解各種自動化腳本。

理想的測試自動化框架的主要組件

如果您想實現功能強大、且性能卓越的測試自動化框架，那么無論采用開源的、還是商用的框架，都必須包括一些核心的構成組件。它們分別是：

1.測試庫

a)單元測試

您需要將單元測試庫用于：

• 通過特定的形式注解(例如@Test或[Test])，來定義正在使用的測試方法。
• 執行能夠影響自動化測試最終結果的斷言(assertion)。
• 運行簡單明了的測試。

無論您是通過命令行、IDE、專用工具、還是CI(持續集成)系統，來運行測試，都需要確保單元測試能夠以直觀的方式得到運行，并能夠提供相應的單元測試庫。

通常，單元測試庫可以支持幾乎每一種編程語言。其中包括：

• 針對Java的JUnit和TestNG。
• 針對.Net的NUnit和MSTest。
• 適用于Python的unittest(以前叫做PyUnit)。

b)集成和端到端測試

在執行集成和端到端測試自動化時，我們往往需要檢驗現有測試庫所提供的各項功能。為了消除不必要的編碼負擔，那些由應用UI驅動的API級別的測試，需要通過組件，輕松地與被測應用進行交互。因此，我們不能僅專注于如下方面的編碼工作：

• 連接到應用程序。
• 發送各種請求。
• 接收各種結果回應。

此環節涉及到的重要測試庫有：

• Selenium(主流語言都可使用)。
• Protractor(特定于JavaScript)。
• Karate DSL(特定于Java的API級集成測試，請參見：https://github.com/intuit/karate)

c)行為驅動開發(Behavior-Driven Development，BDD)

專門針對BDD的測試庫往往以行為規范為目標，以可執行代碼的形式創建各種可執行的規范。盡管它們不能像測試工具那樣直接與被測應用進行交互，但是我們可以將不同的功能和預期的行為場景轉換為代碼。通過對BDD流程的支持，我們可以創建與自動測試范圍和意圖相一致的實時文檔。如下是典型的BDD庫：

• Cucumber(主流語言都可使用)。
• Jasmine(特定于JavaScript)。
• SpecFlow(特定于.Net)。

2.測試數據管理

在軟件測試自動化、以及測試的創建過程中，我們面臨的最大挑戰是如何利用好測試數據的管理系統。因此，隨著自動化測試數量的增加，我們需要能夠為特定測試的開展，提供可用的測試數據。而且，我們的自動化框架需要提供必要的措施，來輸入、創建、以及最終按需清除測試數據。通常的做法是：采用一套合適的仿真工具，以使數據更加簡化、清晰且易于處置。

3.模擬、存根(Stub)和虛擬化

在研究自動化測試的方案時，您可能會遇到如下情況：

• 需要將模塊與在單元測試中連接的組件隔離開來。
• 需要處理應用程序集成、或端到端測試中常見的繁瑣依賴項關系。

無論上述哪種情況，在開發自動化測試框架的過程中，您都需要創建模擬已連接的組件行為模式、存根(請參見：https://www.infoq.com/articles/stubbing-mocking-service-virtualization-differences)，以及選擇實用的虛擬化工具。

實施模型的通用機制

除了上面討論的自動化框架組件之外，還有一些實用的機制可以幫助我們創建，使用和維護各種自動化的測試，其中包括：

• 包裝器方法：在使用Selenium WebDriver組件時，我們可以通過創建自定義包裝器來處理各種錯誤。因此，在創建了可用于Selenium API調用的自定義包裝器后，您將能夠更好地處理各種超時、異常、以及故障報告，從而更加關注于自動化測試的本身。
• 抽象方法：抽象機制代表了提高可讀性，淡化了多余的實現細節。例如：在創建Selenium WebDriver測試時，我們可以使用頁面對象(Page Objects)在頁面上發現用戶輸入的憑據或單擊某處等操作。同時，我們通過跳過頁面上某個特定元素之類的方法，來達到高級測試的目標。而且，此類方法適用于許多相似的應用程序和自動化測試場景。

測試結果報告

在為“如何將測試結果報告到自動化框架中”，這一問題選擇相應的庫或機制時，您應該著眼于閱讀與查看此類報告的目標受眾。在此，您需要注意如下方面：

• 那些Junit和TestNG之類的單元測試框架所生成的報告，主要針對的是諸如CI(持續集成)服務器之類的接收系統。這些系統最終會對結果進行解釋，并以其他軟件可使用的XML格式進行呈現。
• 如果您需要產生可讀性較強的報告，那么可以考慮諸如Junit的UFT Pro、NUnit、以及TestNG類，與單元測試框架相兼容的商業工具。
• 當然，您也可以利用諸如ExtentReports之類的第三方庫，輸出包括餅圖、圖表、圖像之類帶有直觀說明的報告格式。

CI平臺

為了以更快、更一致的方式進行應用程序的測試，持續集成(CI)平臺可以幫助您定期構建軟件，并為新的版本運行各項測試。當開發和部署新的功能，以及更新現有功能的時候，CI方法可以讓開發人員和利益相關者有機會就應用程序的質量，獲得定期的反饋和更快的響應。目前，TeamCity、CircleCI、Jenkins、Atlassian Bamboo等都屬于高品質的CI平臺。

源代碼管理

與手動測試相似，自動化測試也涉及到編寫和存儲源代碼的版本。各個開發公司都會運用一套源代碼和版本控制系統，來保存與保護自己的源代碼。目前，以Git、Mercurial、Subversion和TFS為代表的源代碼管理系統，不但能夠便捷地管理系統在生產環境中的代碼，而且能夠進一步完善自動化測試。

創建依賴項管理器

依賴項管理器的主要目的是：協助收集和管理在自動化軟件方案的功能中，所使用的現有依賴性和庫的過程。其中Maven和Gradle之類的工具，能夠起到依賴項管理，協助從源代碼和支持庫中開發自動化軟件，以及運行測試等作用。此外，業界其他常見的依賴項管理工具還有：Ant、npm和NuGet。

建立和實施框架的過程

我們通常可以通過如下方法，來計劃與實現自動化測試的方案。

• 從客戶的角度來探究自動化的實際適用性，也就是說：從產品的界面和外觀上建立測試，以發現使用上的不足。
• 密切關注被測系統所用到的技術，通過模擬用戶的真實行為，來采用合適的測試自動化工具。
• 建議采用基于階段的實現方法。其中，每個階段都具有交付自動化測試腳本的優先級。同時，我們也可以通過添加各種框架功能，讓各種腳本能夠按期執行。
• 在啟動軟件測試自動化之前，我們需要事先計算和估計實施后的投資回報率(ROI)，概念證明(concept proof)，運行手動回歸或冒煙測試的時間，以及每個版本的發布周期。

如果我們能夠認真地規劃和執行上述測試自動化框架的過程，那么整個軟件的開發和測試環境會得到如下方面的收益：

• 最少的時間與最大的收益：通過構建某種可行的測試自動化框架和腳本，我們將能夠最大程度地減少在編寫與運行測試用例上所花費的時間，進而在更短的時間內獲得更大的輸出。可以說，有了出色的自動化框架，我們可以解決諸如：同步問題、錯誤管理、本地配置、報告生成與解釋等方面的難點。
• 可重用和可讀性的自動化代碼：各種既有的組件庫代碼不但能夠在一段時間內保持可讀性和可重用性，并且能夠讓諸如：報告、同步和故障排除等相關任務變得更加易于訪問和實現。
• 資源優化：自動化系統的靈活性，很大程度上決定了自動化測試的效率，各個組件團隊的協同能力，以及企業是否能夠在資源優化和知識共享方面受益。

總結

在如今快節奏的軟件開發生態系統中，自動化的測試和腳本在軟件測試周期的效率和覆蓋面上都起著不可或缺的作用。當然，這些都離不開精心設計的框架和基礎性的組件策略。我們可以從最小處入手，通過反復測試和改進，來避免在測試自動化的后期階段產生沖突或被迫妥協的狀況。希望上述有關測試自動化框架的討論，能夠讓軟件測試人員在執行測試項目中有所受益。

原文標題：The ABC of Test Automation Frameworks，作者：Mitul Makadia

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