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為一個文本框;
總結
我們應該把自動化測試看作是一個開發項目，而不僅僅是記錄和回放事件。先有一個良好的框架，再開始自動化測試，這樣可以確保較低的維護成本。當你在開發一個框架，進行框架的需求分析時，可以參考本文談到的這些準則。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
