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

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

測試自動化方案

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

如何確定邊界？

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

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

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

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

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

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

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

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

一種推薦方法

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

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

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

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

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