[[323920]]

【51CTO.com快譯】現(xiàn)如今，無(wú)論是軟件測(cè)試人員，還是利益相關(guān)者，都已經(jīng)認(rèn)識(shí)到：實(shí)現(xiàn)測(cè)試自動(dòng)化框架對(duì)于軟件項(xiàng)目的成功是至關(guān)重要的。它不但能夠提高測(cè)試的效率，而且可以減少人工干預(yù)的工作量。

在本文中，我們將深入探討什么是真正的測(cè)試自動(dòng)化框架，自動(dòng)化腳本是如何工作的，以及此類框架是如何在測(cè)試過(guò)程中給團(tuán)隊(duì)提供競(jìng)爭(zhēng)優(yōu)勢(shì)的。

定義測(cè)試自動(dòng)化

在任何行業(yè)中，自動(dòng)化通常被解釋為通過(guò)智能算法，來(lái)自動(dòng)處理各種流程，而且?guī)缀醪恍枰斯さ母深A(yù)。在軟件行業(yè)中，測(cè)試自動(dòng)化意味著：使用受許可版本或開(kāi)源版本的自動(dòng)化工具，對(duì)軟件應(yīng)用程序執(zhí)行各項(xiàng)測(cè)試。從技術(shù)角度來(lái)說(shuō)，測(cè)試自動(dòng)化框架是一組定制的交互式組件，它可以協(xié)助執(zhí)行腳本化的測(cè)試，并全面地報(bào)告測(cè)試結(jié)果。

為了成功地構(gòu)建自動(dòng)化框架，軟件質(zhì)量保證專家必須通過(guò)全面考慮與設(shè)計(jì)，來(lái)控制和監(jiān)視整個(gè)測(cè)試過(guò)程，并提高結(jié)果的準(zhǔn)確性。與此同時(shí)，那些經(jīng)過(guò)精心設(shè)計(jì)的自動(dòng)化框架也能夠讓測(cè)試人員以實(shí)用、簡(jiǎn)化的方式，來(lái)執(zhí)行各項(xiàng)自動(dòng)化的測(cè)試。

通常，根據(jù)自動(dòng)化需求目標(biāo)的不同，我們可以選擇并創(chuàng)建如下不同的框架：

以工具為中心的框架

無(wú)論是商業(yè)版工具還是開(kāi)源的自動(dòng)化工具，它們都擁有自己的系統(tǒng)框架，可以在各種測(cè)試環(huán)境中提供測(cè)試套件，實(shí)施分布式測(cè)試，并最終生成報(bào)告。最典型的示例當(dāng)屬Selenium自動(dòng)化框架。該框架的主要組件是WebDriver。作為基于Web的瀏覽器插件，該組件可被用于控制和操作Web瀏覽器中應(yīng)用程序的DOM模型。此外，Selenium自動(dòng)化框架還帶有各種實(shí)用的編碼庫(kù)，以及支持記錄回放的工具。

Serenity是另一個(gè)自動(dòng)化工具的框架。它圍繞著Selenium Web驅(qū)動(dòng)構(gòu)建了一個(gè)加速器。為加快測(cè)試自動(dòng)化實(shí)施過(guò)程的速度，Serenity還能夠?qū)⑻囟ǖ慕M件與社區(qū)內(nèi)的其他工具相組合。

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

面向項(xiàng)目的框架

定制此類框架主要是用于實(shí)現(xiàn)特定應(yīng)用項(xiàng)目的自動(dòng)化。特定項(xiàng)目的框架既可以支持某些目標(biāo)應(yīng)用的測(cè)試自動(dòng)化需求，又能夠被開(kāi)源庫(kù)構(gòu)建的組件所驅(qū)動(dòng)。此類框架?chē)@著被測(cè)系統(tǒng)(System Under Test，SUT)創(chuàng)建了一個(gè)友好的測(cè)試環(huán)境，以運(yùn)行和覆蓋各種基本功能。其中包括：對(duì)已開(kāi)發(fā)的應(yīng)用進(jìn)行部署，運(yùn)行，并且通過(guò)包裝器(Wrapper)的控制以簡(jiǎn)化編碼，執(zhí)行測(cè)試用例，以及輸出測(cè)試結(jié)果報(bào)告。面向特定項(xiàng)目的框架還應(yīng)該通過(guò)組件，以支持在不同的操作系統(tǒng)和瀏覽器上，進(jìn)行跨多種云端環(huán)境的測(cè)試。

關(guān)鍵字驅(qū)動(dòng)的框架

這是一些旨在給開(kāi)發(fā)人員和測(cè)試人員帶來(lái)較少代碼體驗(yàn)的框架。那些被應(yīng)用于代碼之中的關(guān)鍵字集(如：Login、NavigateToPage、Click、以及TypeText)會(huì)被安裝到代碼庫(kù)中，作為一個(gè)關(guān)鍵字的存儲(chǔ)庫(kù)。根據(jù)給定的關(guān)鍵字，測(cè)試人員可以參考編寫(xiě)處對(duì)應(yīng)的腳本，并以電子表格的形式，傳遞到關(guān)鍵字解釋器中，予以執(zhí)行和測(cè)試。因此，對(duì)于技能不足的人員來(lái)說(shuō)，他們能夠據(jù)此輕松地編寫(xiě)和理解各種自動(dòng)化腳本。

理想的測(cè)試自動(dòng)化框架的主要組件

如果您想實(shí)現(xiàn)功能強(qiáng)大、且性能卓越的測(cè)試自動(dòng)化框架，那么無(wú)論采用開(kāi)源的、還是商用的框架，都必須包括一些核心的構(gòu)成組件。它們分別是：

1.測(cè)試庫(kù)

a)單元測(cè)試

您需要將單元測(cè)試庫(kù)用于：

• 通過(guò)特定的形式注解(例如@Test或[Test])，來(lái)定義正在使用的測(cè)試方法。
• 執(zhí)行能夠影響自動(dòng)化測(cè)試最終結(jié)果的斷言(assertion)。
• 運(yùn)行簡(jiǎn)單明了的測(cè)試。

無(wú)論您是通過(guò)命令行、IDE、專用工具、還是CI(持續(xù)集成)系統(tǒng)，來(lái)運(yùn)行測(cè)試，都需要確保單元測(cè)試能夠以直觀的方式得到運(yùn)行，并能夠提供相應(yīng)的單元測(cè)試庫(kù)。

通常，單元測(cè)試庫(kù)可以支持幾乎每一種編程語(yǔ)言。其中包括：

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

b)集成和端到端測(cè)試

在執(zhí)行集成和端到端測(cè)試自動(dòng)化時(shí)，我們往往需要檢驗(yàn)現(xiàn)有測(cè)試庫(kù)所提供的各項(xiàng)功能。為了消除不必要的編碼負(fù)擔(dān)，那些由應(yīng)用UI驅(qū)動(dòng)的API級(jí)別的測(cè)試，需要通過(guò)組件，輕松地與被測(cè)應(yīng)用進(jìn)行交互。因此，我們不能僅專注于如下方面的編碼工作：

• 連接到應(yīng)用程序。
• 發(fā)送各種請(qǐng)求。
• 接收各種結(jié)果回應(yīng)。

此環(huán)節(jié)涉及到的重要測(cè)試庫(kù)有：

• Selenium(主流語(yǔ)言都可使用)。
• Protractor(特定于JavaScript)。
• Karate DSL(特定于Java的API級(jí)集成測(cè)試，請(qǐng)參見(jiàn)：https://github.com/intuit/karate)

c)行為驅(qū)動(dòng)開(kāi)發(fā)(Behavior-Driven Development，BDD)

專門(mén)針對(duì)BDD的測(cè)試庫(kù)往往以行為規(guī)范為目標(biāo)，以可執(zhí)行代碼的形式創(chuàng)建各種可執(zhí)行的規(guī)范。盡管它們不能像測(cè)試工具那樣直接與被測(cè)應(yīng)用進(jìn)行交互，但是我們可以將不同的功能和預(yù)期的行為場(chǎng)景轉(zhuǎn)換為代碼。通過(guò)對(duì)BDD流程的支持，我們可以創(chuàng)建與自動(dòng)測(cè)試范圍和意圖相一致的實(shí)時(shí)文檔。如下是典型的BDD庫(kù)：

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

2.測(cè)試數(shù)據(jù)管理

在軟件測(cè)試自動(dòng)化、以及測(cè)試的創(chuàng)建過(guò)程中，我們面臨的最大挑戰(zhàn)是如何利用好測(cè)試數(shù)據(jù)的管理系統(tǒng)。因此，隨著自動(dòng)化測(cè)試數(shù)量的增加，我們需要能夠?yàn)樘囟y(cè)試的開(kāi)展，提供可用的測(cè)試數(shù)據(jù)。而且，我們的自動(dòng)化框架需要提供必要的措施，來(lái)輸入、創(chuàng)建、以及最終按需清除測(cè)試數(shù)據(jù)。通常的做法是：采用一套合適的仿真工具，以使數(shù)據(jù)更加簡(jiǎn)化、清晰且易于處置。

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

在研究自動(dòng)化測(cè)試的方案時(shí)，您可能會(huì)遇到如下情況：

• 需要將模塊與在單元測(cè)試中連接的組件隔離開(kāi)來(lái)。
• 需要處理應(yīng)用程序集成、或端到端測(cè)試中常見(jiàn)的繁瑣依賴項(xiàng)關(guān)系。

無(wú)論上述哪種情況，在開(kāi)發(fā)自動(dòng)化測(cè)試框架的過(guò)程中，您都需要?jiǎng)?chuàng)建模擬已連接的組件行為模式、存根(請(qǐng)參見(jiàn)：https://www.infoq.com/articles/stubbing-mocking-service-virtualization-differences)，以及選擇實(shí)用的虛擬化工具。

實(shí)施模型的通用機(jī)制

除了上面討論的自動(dòng)化框架組件之外，還有一些實(shí)用的機(jī)制可以幫助我們創(chuàng)建，使用和維護(hù)各種自動(dòng)化的測(cè)試，其中包括：

• 包裝器方法：在使用Selenium WebDriver組件時(shí)，我們可以通過(guò)創(chuàng)建自定義包裝器來(lái)處理各種錯(cuò)誤。因此，在創(chuàng)建了可用于Selenium API調(diào)用的自定義包裝器后，您將能夠更好地處理各種超時(shí)、異常、以及故障報(bào)告，從而更加關(guān)注于自動(dòng)化測(cè)試的本身。
• 抽象方法：抽象機(jī)制代表了提高可讀性，淡化了多余的實(shí)現(xiàn)細(xì)節(jié)。例如：在創(chuàng)建Selenium WebDriver測(cè)試時(shí)，我們可以使用頁(yè)面對(duì)象(Page Objects)在頁(yè)面上發(fā)現(xiàn)用戶輸入的憑據(jù)或單擊某處等操作。同時(shí)，我們通過(guò)跳過(guò)頁(yè)面上某個(gè)特定元素之類的方法，來(lái)達(dá)到高級(jí)測(cè)試的目標(biāo)。而且，此類方法適用于許多相似的應(yīng)用程序和自動(dòng)化測(cè)試場(chǎng)景。

測(cè)試結(jié)果報(bào)告

在為“如何將測(cè)試結(jié)果報(bào)告到自動(dòng)化框架中”，這一問(wèn)題選擇相應(yīng)的庫(kù)或機(jī)制時(shí)，您應(yīng)該著眼于閱讀與查看此類報(bào)告的目標(biāo)受眾。在此，您需要注意如下方面：

• 那些Junit和TestNG之類的單元測(cè)試框架所生成的報(bào)告，主要針對(duì)的是諸如CI(持續(xù)集成)服務(wù)器之類的接收系統(tǒng)。這些系統(tǒng)最終會(huì)對(duì)結(jié)果進(jìn)行解釋，并以其他軟件可使用的XML格式進(jìn)行呈現(xiàn)。
• 如果您需要產(chǎn)生可讀性較強(qiáng)的報(bào)告，那么可以考慮諸如Junit的UFT Pro、NUnit、以及TestNG類，與單元測(cè)試框架相兼容的商業(yè)工具。
• 當(dāng)然，您也可以利用諸如ExtentReports之類的第三方庫(kù)，輸出包括餅圖、圖表、圖像之類帶有直觀說(shuō)明的報(bào)告格式。

CI平臺(tái)

為了以更快、更一致的方式進(jìn)行應(yīng)用程序的測(cè)試，持續(xù)集成(CI)平臺(tái)可以幫助您定期構(gòu)建軟件，并為新的版本運(yùn)行各項(xiàng)測(cè)試。當(dāng)開(kāi)發(fā)和部署新的功能，以及更新現(xiàn)有功能的時(shí)候，CI方法可以讓開(kāi)發(fā)人員和利益相關(guān)者有機(jī)會(huì)就應(yīng)用程序的質(zhì)量，獲得定期的反饋和更快的響應(yīng)。目前，TeamCity、CircleCI、Jenkins、Atlassian Bamboo等都屬于高品質(zhì)的CI平臺(tái)。

源代碼管理

與手動(dòng)測(cè)試相似，自動(dòng)化測(cè)試也涉及到編寫(xiě)和存儲(chǔ)源代碼的版本。各個(gè)開(kāi)發(fā)公司都會(huì)運(yùn)用一套源代碼和版本控制系統(tǒng)，來(lái)保存與保護(hù)自己的源代碼。目前，以Git、Mercurial、Subversion和TFS為代表的源代碼管理系統(tǒng)，不但能夠便捷地管理系統(tǒng)在生產(chǎn)環(huán)境中的代碼，而且能夠進(jìn)一步完善自動(dòng)化測(cè)試。

創(chuàng)建依賴項(xiàng)管理器

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

建立和實(shí)施框架的過(guò)程

我們通?？梢酝ㄟ^(guò)如下方法，來(lái)計(jì)劃與實(shí)現(xiàn)自動(dòng)化測(cè)試的方案。

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

如果我們能夠認(rèn)真地規(guī)劃和執(zhí)行上述測(cè)試自動(dòng)化框架的過(guò)程，那么整個(gè)軟件的開(kāi)發(fā)和測(cè)試環(huán)境會(huì)得到如下方面的收益：

• 最少的時(shí)間與最大的收益：通過(guò)構(gòu)建某種可行的測(cè)試自動(dòng)化框架和腳本，我們將能夠最大程度地減少在編寫(xiě)與運(yùn)行測(cè)試用例上所花費(fèi)的時(shí)間，進(jìn)而在更短的時(shí)間內(nèi)獲得更大的輸出。可以說(shuō)，有了出色的自動(dòng)化框架，我們可以解決諸如：同步問(wèn)題、錯(cuò)誤管理、本地配置、報(bào)告生成與解釋等方面的難點(diǎn)。
• 可重用和可讀性的自動(dòng)化代碼：各種既有的組件庫(kù)代碼不但能夠在一段時(shí)間內(nèi)保持可讀性和可重用性，并且能夠讓諸如：報(bào)告、同步和故障排除等相關(guān)任務(wù)變得更加易于訪問(wèn)和實(shí)現(xiàn)。
• 資源優(yōu)化：自動(dòng)化系統(tǒng)的靈活性，很大程度上決定了自動(dòng)化測(cè)試的效率，各個(gè)組件團(tuán)隊(duì)的協(xié)同能力，以及企業(yè)是否能夠在資源優(yōu)化和知識(shí)共享方面受益。

總結(jié)

在如今快節(jié)奏的軟件開(kāi)發(fā)生態(tài)系統(tǒng)中，自動(dòng)化的測(cè)試和腳本在軟件測(cè)試周期的效率和覆蓋面上都起著不可或缺的作用。當(dāng)然，這些都離不開(kāi)精心設(shè)計(jì)的框架和基礎(chǔ)性的組件策略。我們可以從最小處入手，通過(guò)反復(fù)測(cè)試和改進(jìn)，來(lái)避免在測(cè)試自動(dòng)化的后期階段產(chǎn)生沖突或被迫妥協(xié)的狀況。希望上述有關(guān)測(cè)試自動(dòng)化框架的討論，能夠讓軟件測(cè)試人員在執(zhí)行測(cè)試項(xiàng)目中有所受益。

原文標(biāo)題：The ABC of Test Automation Frameworks，作者：Mitul Makadia

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】