開發測試自動化腳本以及自動化框架

在進行測試自動化項目顧問工作的早期階段，經常有人請我對于自動化的實現進行評估。而當我給出一個初步的估算時，很快就會遇到下一個問題：“這個估算所針對的是一個測試套件還是框架呢？”

這種問題經常會讓我感到難以回答，因為我不清楚他們問的到底是什么……哪些東西屬于測試腳本？哪些東西屬于框架？他們之間到底如何區分？

讓我們首先來明確幾個定義。

自動化工具

自動化工具/指令的作用是與UI進行交互，例如模仿單擊按鈕、輸入文本及驗證文本框中的值。至少這個定義是我所能夠確認的，不存在任何含糊的地方

框架

我從前對于框架的認知是偏具體的，即可重用的、與SUT（待測試系統）無關的、并且與自動化工具無關的庫，它能夠加速自動化的實現。

但在IT業界中，框架這個詞的使用非常頻繁，甚至即使僅僅談論自動化測試的時候，這個單詞在不同的上下文中也會具有不同的含義

圖1 – 不同的框架示例

特定于工具的框架

一般來說，商業級自動化工具的提供者，乃至開源社區往往會為他們的工具打造一個完整的基礎設施，在其中實現報表生成、測試套件的運行、分布式測試的運行，并與測試的執行環境相集成。舉例來說，Selenium工具的主要組件是WebDriver，它作為web瀏覽器的插件運行，對于在web瀏覽器中運行的web應用進行DOM模型（即web頁面的一種基于xml文檔對象模型）的操作。但Selenium還包括大量的額外編碼庫，以及一個實現了錄制-重播功能的工具（Selenium IDE）。所有這一切工具共同組成了Selenium自動化測試框架

Serenity是另一個很好的例子，它也是一種特定于工具（圍繞著Selenium Web Driver而創建）的框架。但它的目標不在于提供大量的可選組件或插件，因為特定的組件已經由社區專家合而為一了。你可以將它設想為一種加速器，通過它提供對更快的測試自動化實現的啟動的支持，同時也支持BDD類型的測試。

而在商業產品中，更難以找出測試命令本身所在，原因是商業級的特定于工具的框架（例如HP QTP、Ranorex和TestComplete）通常是一種經過完整構建與部署的基礎設施，包含了行為的模擬器、編寫腳本的IDE及報表工具。

特定于項目的框架

這種框架是在特定的應用開發階段為了實現自動化而開發的，用于支持特定的應用的自動化測試的需求。這種框架的組件可以由其他開源庫實現，針對SUT建立一種特定的環境，以支持以下功能中的部分或全部：

將經過構建的應用（包括它的組件，例如數據庫、服務庫和后端）部署到某個環境中；

啟動應用；

運行測試用例；

將測試的運行結果報告直接發送給某個測試管理系統

提供控件的封裝，以支持通過某些特定的控件（例如grid或自定義控件等等）簡化自動化的編碼工作。

另一個需要考慮的重要組件是測試用具（test harness），它能夠支持在不同的云環境中運行測試用例，允許在所支持的操作系統與瀏覽器的運行產生不同的結果?？梢赃x擇自行創建這些操作，也可以選擇某種工具框架中的組件。

最佳實踐框架

框架是個非常吸引人的詞，一旦你提到這個詞，就會令人產生深刻的印象。舉例來說，Zachman框架與開發組件之間沒有任何關聯，它只是一種用于定義企業架構的方法。同樣的道理也適用于自行開發的自動化構建框架，它們可以包含用于自動化測試的組件，也可以包含描述如何以最佳方式對某個測試進行自動化的方法。對于那些希望首次嘗試自動化測試，或是試圖理解現有的自動化項目的運行情況的客戶來說，自動化測試專家（包括我）通常會為他們推薦這種框架。

關鍵字驅動的框架

還有一種類型的框架也不可不提，這是一種針對編碼經驗較少的員工、特定于工具或項目的框架。這種框架能夠讓他們編寫或維護自動化腳本。經過代碼化的關鍵字（例如Login、Click、NavigateToPage和TypeText等等）是在代碼中的某處實現的，這里的代碼被實現為了一種關鍵字的庫。

原文轉自：http://www.uml.org.cn/Test/201610172.asp