簡介
測試框架是在所有不同的測試自動化階段定義的一整套指導準則：需求分析階段、腳本設計階段、執行階段、報告和維護階段�？蚣芗磳τ趦炔繌碗s架構的一種包裝，這樣的包裝可以使得最終用戶方便的使用�？蚣苓�具有對于流程標準的強制執行性。
問題描述
目前為止，還沒有一種關于如何開發測試框架以及在開發過程中需要考慮哪些因素的準則。有很多記載著各式各樣的測試框架以及它們各自是如何工作的 白皮書，但是這些白皮書中還沒有任何一篇文檔是記錄著測試框架設計共同需要考慮的因素。本文基于測試框架需求，涵蓋了測試框架各個方面以及一些必備的基本 要素。
1. 自動化測試框架的類型 – 目前普遍存在的框架有以下幾種：
數據驅動框架 – 當測試對象流程固定不變(僅僅數據發生變化)，可以使用這種測試框架。測試數據是由外部提供的，比如說Excel表、XML等等
關鍵字驅動框架 – 這種自動化測試框架提供了一些通用的關鍵字，這些關鍵字適用于各種類型的系統。它還為自動化測試工具和被測系統提供了抽象性。舉個例子，它可以使用相同的測試用例來測試類似的Web和Windows系統。
混合型的框架 – 混合型自動化測試框架同時具有數據驅動型和關鍵字驅動型框架的優點。這種測試框架不但具有通用的關鍵字，還有基于被測系統業務邏輯的關鍵字。例如“登錄”、“退出”是可以被使用的僅局限于某系統的關鍵字。
2. 不要過分的改造 – 自動化測試框架應該盡可能的使自動化測試工具發揮它自己強大的功能，而不是通過實現新的關鍵字來重新定義整套語言。開發一套關鍵字驅動的自動化測試框架的 代價是很大的而且非常耗時。開發一套混合型的自動化測試框架的代價就相對較小而且開發周期短。
3. 可重用性 – 測試框架應該盡最大可能提高可重用性。把單獨的Action組合成業務邏輯可以提供可重用性。舉個例子，可以把類似于“輸入用戶名”、“輸入密碼”和“點擊登錄”這些Action組合成一個可被重用的模塊：“登錄”
4. 支持系統的不同版本 – 自動化測試框架應該允許重復使用基線化腳本，這樣可以保證這份腳本能被用來對被測系統的多個版本進行測試。對不同系統的支持有兩種方式：
復制和修改 – 這種方法包含了新建基線腳本的一個拷貝、修改這份拷貝用以測試特定版本的項目。
重用和升級 – 這種方法包含了重用基線腳本、提供一個此腳本的升級和優化用以測試特定版本的項目。這樣做可以最大化的保障可重用性，這也是推薦的方法。
5. 支持腳本版本化 – 測試腳本應該被儲存在類似于CVS、微軟的VSS等版本控制工具中。這樣做可以保障在災難發生的時候可以被恢復。
6. 將開發和發布環境分開 – 自動化應當和其它開發項目同等看待。測試腳本應當在一個測試環境下創建和調試。一旦測試腳本測試通過后唯一該做的就是將它部署到發布環境。在緊急發布版本的情況也同樣適用這種方法。
7. 外部可配置性 – 腳本的可配置項應當被保存在一個外部文檔中。系統的URL、版本、路徑等都可以被視作可配置項放在外部文件中。這樣做可以使得在不同的環境中都可以執行測 試腳本。需要注意的是外部配置文件的路徑不要寫死，如果把它寫死了雖然在任何環境中都還是可以運行腳本，但是每次只能在一個環境運行。配置文件的路徑使用 相對路徑即可解決這個問題。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
