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

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

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

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

自動化工具

自動化工具/指令的作用是與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），它能夠支持在不同的云環境中運行測試用例，允許在所支持的操作系統與瀏覽器的運行產生不同的結果。可以選擇自行創建這些操作，也可以選擇某種工具框架中的組件。

最佳實踐框架

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

關鍵字驅動的框架

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

測試人員將獲得一份關鍵字的參考引用，因此他們可以在表格中直接編寫腳本。這些表格隨后將導入某些關鍵字解釋器中，并通過調用某個庫中的特定實現而開始執行測試。

測試自動化方案

我傾向于將特定于某個項目的測試腳本與所有相關的底層框架統稱為 測試自動化方案 ，它包含了與整個項目、測試環境管理、測試方案架構以及最佳實踐相關的所有特定或一般性的框架，同時也包含了測試腳本。因此在進行評估時，我傾向于討論整個測試自動化方案。

如何確定邊界？

實現測試自動化通常來說意味著巨大的投入，因此重要的是盡早理解并使投入的回報清晰化，否則項目很可能會被取消

沒錯，在某些場景下，你可能需要開發一種特定的測試用具，而這非常耗時。但不能因此就決定選擇一種獨立于測試腳本之外的實現。你需要時刻牢記以最佳實踐實現自動化測試腳本（以便于日后的維護），這才是最重要的。這種做法實際上只會節省你在項目上投入的時間。

舉一個真實的案例：我曾經參與評估了一個“首次嘗試”的自動化項目，它最終被取消了。其原因是所有的精力都投入到開發某個環境管理實驗之中，以支持運行自動化的各種操作系統。經驗豐富的開發者為此投入了數月的開發時間，但管理人員在開發過程中看不到任何投資收益。最后還是延續了手動的測試周期。

那么，如果在一開始選擇僅支持一到兩個最高優先級的環境，首先部署手動測試，隨后對某個測試進行自動化，這種做法會不會更好一些呢？

其實，只要你能夠減少測試的成本（或者至少能夠預期成本的減少），同時交付可維護的自動化腳本，這正是控制成本的管理人員所樂于見到的。在實際實現背后的測試用具或許規模龐大，并且對于運行這些測試用例來說更為重要，但我們應具體情況具體分析。一般來說，在運行第一批腳本的時候，你不大會用到所有的測試用具。因此，我認為更重要的地方在于提供一個一致的測試自動化方案的架構，它能夠允許你今后對測試用具進行擴展，而不是一上來就要完成所有的測試用具。

你可以在這里找到一種可擴展的測試自動化架構的描述，這是一種分層的測試方案。它的做法是將代碼分解為多個獨立的層，并創建相應的Page Object對象。這種做法不需要你投入大量的時間，卻能夠為最終的方案帶來很大的可維護性。而且，最終的方案能夠在一種還是多種操作系統、web瀏覽器上工作，這一點真的并不重要，我們可以隨后為其添加多平臺的支持。

另一個值得一提的重要領域就是關鍵字驅動的框架，這種途徑意味著你首先需要開發出一個框架（一個關鍵字的集合），隨后才能夠通過將這些關鍵字鏈接在一起的方式開發測試腳本。

我個人認為這種做法是一種糟糕的實踐。首先，在電子表格中進行開發非常容易出錯，任何一個拼寫錯誤都會造成錯誤，并且難以通過調試發現。此外，如果你在編寫業務邏輯，而生成的測試卻不會調用這些邏輯，那就好像在開發應用程序的業務邏輯時不提供任何單元測試、或是不提供用戶界面一樣。另外，你永遠都無法預先估計你需要開發多少條關鍵字，才能夠讓一定特定的測試得到足夠的關鍵字，從而滿足測試腳本的需求。

一種推薦方法

我將描述一種我個人對測試自動化方案進行計劃的方法，按照我的經驗來看，這種方式已經證實了它的正確性，不過它也只是“正確的做法”之一。

1. 客戶對于引入測試自動化這種做法的期待是什么？對于當前項目的時間表與技術能力來說，測試自動化是否真的可行？我的看法是，在某些時候，在這一階段對此問題的回答是“測試自動化完全不適合于實現你的目標”。出現這種情況的一種可能是：自動化的開發工作與所獲的益處相比，所投入的精力過于巨大。

2. 了解將測試系統的技術，并且選擇最適合的自動化工具以模擬用戶的行為也非常重要。

3. 那么，我們應當選擇怎樣的方式呢？我在這里要區分兩種主要的方式，即“快速而粗糙”的方式，以及“基于解決方案”的方式。“基于解決方案”的方式在上文已經描述過了，“快速而粗糙”則意味著可以說這種方式“只能夠在我的機器上運行”。只需一些最基本的投入，你就能夠立即得到一些結果。對于性能測試來說，這種方式不失為一種良好的選擇，因為獲取系統的性能參數有時（但也并非總是如此）就是一種一次性的活動。

4. 計算整個實現方式的實際收益率，建立一個小型的概念驗證，以了解每次發布時手動運行回歸測試與冒煙測試的時間，以及運行的次數。這樣一來，我們就能夠理解這種方式所減少的時間成本（也就意味著金錢）。

5. 為測試的實現提出一種基于階段的路線圖。在每一階段，主要的交付內容是一些自動化的測試腳本，以及使這些腳本實現最優化所必需的框架特性。

結論

在進行測試評估時，我傾向于討論測試自動化的解決方案。在整個產業都在選擇敏捷開發的現階段，應用程序的各個部分將陸續交付，并保證能夠工作及一致性。那么，為什么在進行測試自動化時不選擇同樣的策略呢？對于完全專注于開發框架這種策略，我們應當堅決說不！我們應當進行增量式的交付（即自動化腳本的部分子集，以及運行這些腳本所必需的部分測試用具），以實現最優的、最快的收益率

關于作者

Sasha 是一位博士及測試自動化方面的專家，在 Softserve Inc. 擔任測試自動化的經理。他也是測試自動化方面的傳教士及顧問，幫助小型的創業公司以及財富500強公司建立正確的質量保證文化，無論產品的開發環境是敏捷還是瀑布式流程。他還是一位講師以及培訓師，也是 StepsToReproduce 的開發者，這是一個免費的探索性測試工具，其功能可取代Windows系統下的Problem Steps Recorder（一個問題記錄組件）。

查看英文原文： Developing Test Automation Scripts and Automation Frameworks