簡介
測試框架是在所有不同的測試自動化階段定義的一整套指導準則：需求分析階段、腳本設計階段、執行階段、報告和維護階段。框架即對於內部複雜架構的一種包裝，這樣的包裝可以使得最終用戶方便的使用。框架還具有對於流程標準的強制執行性。
問題描述
目前爲止，還沒有一種關於如何開發測試框架以及在開發過程中需要考慮哪些因素的準則。有很多記載着各式各樣的測試框架以及它們各自是如何工作的白皮書，但是這些白皮書中還沒有任何一篇文檔是記錄着測試框架設計共同需要考慮的因素。本文基於測試框架需求，涵蓋了測試框架各個方面以及一些必備的基本要素。
1. 自動化測試框架的類型 – 目前普遍存在的框架有以下幾種：
● 數據驅動框架 – 當測試對象流程固定不變（僅僅數據發生變化），可以使用這種測試框架。測試數據是由外部提供的，比如說Excel表、XML等等
● 關鍵字驅動框架 – 這種自動化測試框架提供了一些通用的關鍵字，這些關鍵字適用於各種類型的系統。它還爲自動化測試工具和被測系統提供了抽象性。舉個例子，它可以使用相同的測試用例來測試類似的Web和Windows系統。關鍵字驅動的測試框架因爲使用了外部的數據源（比如Excel數據表）去讀取腳本中的關鍵字和測試過程，所以較難調試。
● 混合型的框架 – 混合型自動化測試框架同時具有數據驅動型和關鍵字驅動型框架的優點。這種測試框架不但具有通用的關鍵字，還有基於被測系統業務邏輯的關鍵字。例如“登錄”、“退出”是可以被使用的僅侷限於某系統的關鍵字。
2. 不要過分的改造 – 自動化測試框架應該儘可能的使自動化測試工具發揮它自己強大的功能，而不是通過實現新的關鍵字來重新定義整套語言。開發一套關鍵字驅動的自動化測試框架的 代價是很大的而且非常耗時。開發一套混合型的自動化測試框架的代價就相對較小而且開發週期短。
3. 可重用性 – 測試框架應該盡最大可能提高可重用性。把單獨的Action組合成業務邏輯可以提供可重用性。舉個例子，可以把類似於“輸入用戶名”、“輸入密碼”和“點擊登錄”這些Action組合成一個可被重用的模塊：“登錄”
4. 支持系統的不同版本 – 自動化測試框架應該允許重複使用基線化腳本，這樣可以保證這份腳本能被用來對被測系統的多個版本進行測試。對不同系統的支持有兩種方式：
● 複製和修改 – 這種方法包含了新建基線腳本的一個拷貝、修改這份拷貝用以測試特定版本的項目。
● 重用和升級 – 這種方法包含了重用基線腳本、提供一個此腳本的升級和優化用以測試特定版本的項目。這樣做可以最大化的保障可重用性，這也是推薦的方法。
5. 支持腳本版本化 – 測試腳本應該被儲存在類似於CVS、微軟的VSS等版本控制工具中。這樣做可以保障在災難發生的時候可以被恢復。
6. 將開發和發佈環境分開 – 自動化應當和其它開發項目同等看待。測試腳本應當在一個測試環境下創建和調試。一旦測試腳本測試通過後唯一該做的就是將它部署到發佈環境。在緊急發佈版本的情況也同樣適用這種方法。
7. 外部可配置性 – 腳本的可配置項應當被保存在一個外部文檔中。系統的URL、版本、路徑等都可以被視作可配置項放在外部文件中。這樣做可以使得在不同的環境中都可以執行測 試腳本。需要注意的是外部配置文件的路徑不要寫死，如果把它寫死了雖然在任何環境中都還是可以運行腳本，但是每次只能在一個環境運行。配置文件的路徑使用 相對路徑即可解決這個問題。
8. 自身可配置性 – 理想的測試框架應該是自身可配置的。一旦部署到系統中之後應當不需要再做任何手工配置，腳本應當自動配置完成一些必要的設置。
9. 任何對象改動引起的變動應該是最小的 – 自動化過程中最爲常見的問題是對象識別的變更。測試框架應該支持可以很容易的來完成這些修改。這可以通過將所有的對象識別設置儲存在一個共享文件來實現。這個文件可以是XML文件、Excel文件、數據庫或者自動化所特有的格式。這裏有兩種可能的方式來實現對象識別設置的方式：
● 靜態方法 – 這種方法中，所有對象定義都在測試最初被加載到內存中。任何對象定義變更只能通過停止和重新運行測試來實現。
● 動態方法 – 對象定義是通過需求拉動的。這種方式和靜態方式比較而言顯得較爲緩慢。但是對於非常大的腳本而言，並且對象識別需要在運行時做修正的情況下，動態方法是適用的。
10. 測試執行 – 自動化測試框架也許需要滿足以下需求（基於實際需求）
● 執行單獨的測試用例；
● 批量執行測試用例（一組測試用例）；
● 只執行失敗的測試用例；
● 可以在前一個（一組）測試用例執行結果的基礎上，執行下一個（一組）測試用例；
根據實際需求還會有許多其他情況。一個框架可能無法實現所有這些需求，但它應具有足夠的靈活性以適應今後此類需求。
11. 狀態監測 - 一個框架應允許實時監控執行狀態，一旦失敗能夠發出警報。這樣可以在出現failure之後迅速反饋。
12. 報表 – 不同的系統對報表有不同的需求，有時候需要一組測試的整體報表，有時候只需要單個測試用例級別的測試執行報表。一個好的測試框架應該有足夠的彈性來按需支持不同的報表。
13. 發生更改的時候對測試工具儘量小的依賴性 – 一些測試腳本的更改可能只能在打開測試工具後，在測試工具中進行修改，然後保存。測試腳本應該在沒有測試工具的情況下也可以對腳本進行更改。這樣的實現可 以減少license的購買從而爲公司節省開支。這樣的實現還可以讓所有想去修改腳本的人無需安裝測試工具也可以很方便的對腳本進行修改。
14. 方便的調試 – 調試在自動化過程中佔據了大量的時間，因此在調試這個過程中需要加以特別的關注。關鍵字驅動的測試框架因爲使用了外部的數據源（比如Excel數據表）去讀取腳本中的關鍵字和測試過程，所以較難調試。
15. 日誌 - 生成日誌是執行的重要組成部分。在一個測試案例的不同點生成調試信息這是非常重要的。這些信息有助於快速地找到問題的範圍，同時縮短了修改時間。
16. 易用性 - 該框架應易於學習和使用。對框架的人員培訓費時且昂貴。有一個好文檔的框架更容易理解和使用。
17. 靈活性 - 框架應該足夠的靈活，以適應任何改進，而不會影響已有的測試案例。
18. 性能的影響 – 框架還應考慮對執行性能的影響。一個複雜的框架會增加腳本的加載或執行時間，這一定不是我們所期望的。像緩存技術，當執行時編譯所有代碼到單個庫中等...只要可能都應該用於性能的改善。
19. 框架支持工具 – 開發一些外部工具來完成任務，這對框架設計會有幫助。這是一些例子：
● 從本地文件夾上傳腳本到QC
● 結合庫文件到當前打開的腳本
● 同步本地和QC上的腳本文件
20. 編碼標準 - 編碼標準應確保腳本的一致性，可讀性和易於維護。編碼標準應包含下列內容：
● 命名規範（變量、子程序、函數、文件名、腳本名稱等），例如i_VarName爲整數變量， fn_i_FuncName爲返回值是整數的函數；
● 庫、子程序、函數的頭部註釋。這應包含,如版本歷史，創建者，最後修訂者，最後修訂日期，說明，參數，示例；
● 對象命名規範。例如txt_FieldName爲一個文本框；
總結
我們應該把自動化測試看作是一個開發項目，而不僅僅是記錄和回放事件。先有一個良好的框架，再開始自動化測試，這樣可以確保較低的維護成本。當你在開發一個框架，進行框架的需求分析時，可以參考本文談到的這些準則。