一直想仔細研究框架，寫個流水賬似的測試程序不難，寫個低維護成本的測試框架就很難了，所以研究多種測試框架還是很有必要的，知道孰優孰劣，才能在開始編寫框架的時候打好基礎，今天讀到了KiKi Zhao的翻譯文章，覺得很是不錯，寫了一點學習心得，有不正確之處，請指出。
中文原文地址：http://www.cnblogs.com/nckiki/articles/244202.html
英文原文地址：http://www.ibm.com/developerworks/rational/library/591.html
原文對自動化測試架構做了如下四種分類：
- 數據驅動測試框架（The Data-Driven Testing Framework）
說明：
僅僅是將測試數據從測試腳本中分離出來，開始了非混沌狀態的第一步，這也是所有測試架構中最簡單的一種
優點：
至少測試數據可以單獨維護了
缺點：
任何被測試程序的變更所導致的工作量是所有架構中最多的，因此維護成本非常高
- 測試腳本模塊化框架（The Test Script Modularity Framework）
說明：
l 箭頭方向代表的是被調用和調用關系
l 測試腳本中包含了各功能點中涉及到的控件識別和業務邏輯操作，其中包含了外部測試數據的調用
l 測試腳本的維護由自動化測試開發工程師負責，要求必須懂自動化編程和業務邏輯
l 測試數據的維護由測試工程師負責
優點：
控件和業務邏輯一旦發生變化，要進行修改和維護的是底層的測試腳本（比無任何抽象封裝的自動化測試程序稍好一些）
缺點：
l 幾乎所有大的變更引起的工作量都由自動化測試開發工程師完成
l 控件識別和業務邏輯本身屬於不同的領域，沒有很好進行抽象封裝
- 測試庫構架框架（The Test Library Architecture Framework）
說明：
l 箭頭方向代表的是被調用和調用關系
l 將所有的針對測試系統本身的控件識別和控件支持的操作封裝在測試庫中
l 測試腳本調用測試庫的同時傳遞外部的測試數據
l 測試庫的編寫由自動化測試開發工程編寫（可以不懂業務），負責控件的變更和維護
l 測試腳本的編寫可由對業務比較掌握的自動化測試開發工程編寫，負責業務邏輯的變更和維護
l 測試數據由測試工程師維護（可以不懂自動化開發）
優點：
l 被測試系統無論是哪層發生變化，只需要相應的人員進行變更維護即可
l 完成了控件識別操作和業務邏輯的抽象分離
缺點：
變更引起的工作量還是附加在自動化測試開發工程師身上
- 關鍵字驅動或表驅動測試框架（The Keyword-Driven or Table-Driven Testing Framework）
說明：
l 說到關鍵字驅動，當然得說QTP。確實當對象庫（很類似測試庫架構中的測試庫）添加完成后，測試case步驟的組織就相當於是在關鍵字試圖中選擇控件對象（Control），動作（Action），參數（Parameters）。
l 仔細想想，當QTP在完成對被測試程序的錄制后，完成了對象庫的記錄，關鍵字驅動測試case的步驟設置，如果再在table中存放一些測試數據，在測試步驟中進行調用的話，似乎以上三種架構所涉及的內容都得到了很好的運用，但再仔細一想，就QTP錄制的測試程序來講，其實什么架構都沒有做，因為錄制下來的腳本的維護成本是非常高昂的，因為從測試數據的維護，對象庫的維護，業務邏輯的維護等等都必須要求維護者懂的QTP的使用，而且是具備一定水平的。這違背了架構的本身理念。所以得基於QTP做更上層次的對象抽象，最終QTP僅僅是個識別對象和運行VBScript腳本的工具，這一層次的架構設計就體現在VBScript的腳本組織上了。
l 換個角度，框架到底用來做什么，最終的目的無非是將不同層次的對象和邏輯進行抽象和分離封裝，從而使得被測試程序的變更所導致的測試腳本框架的變更維護工作量減少到最少，更進一步，如果不懂自動化編程的普通測試工程師能不需要了解測試工具和框架本身的知識就能維護控件對象和業務邏輯，這樣就可以將自動化測試工程的工作量進行很好的分攤。具體實施就是將控件對象，動作，參數等等從框架或工具本身剝離出來放在普通Excel表格中，組織成如下形式：
| Window |
Control |
Action |
Arguments |
| Calculator |
Menu |
View, Standard |
|
| Calculator |
Pushbutton |
Click |
1 |
| Calculator |
Pushbutton |
Click |
+ |
| Calculator |
Pushbutton |
Click |
3 |
| Calculator |
Pushbutton |
Click |
= |
| Calculator |
Verify Result |
4 |
|
| Calculator |
Clear |
||
| Calculator |
Pushbutton |
Click |
6 |
| Calculator |
Pushbutton |
Click |
- |
| Calculator |
Pushbutton |
Click |
3 |
| Calculator |
Pushbutton |
Click |
= |
| Calculator |
Verify Result |
3 |
框架本身所要做的就是識別Excel表格中的這些控件對象以及Action
注：以上表格中還可以將數據剝離出去，以單獨的數據Excel表格進行維護
優點：
極大的減少了自動化開發工程師維護量，畢竟在測試團隊中，自動化開發工程師占的比較少
普通測試工程師，可以很好的維護自身負責的模塊中涉及的測試case和測試數據
缺點：
框架的抽象程度比較高，對自動化測試工程師的開發能力比較高
總結：個人認為以上的四種架構是存在遞進關系的，至少前三個是肯定的，原文中最后總結的圖認為還是需要多種框架特點組合在一起的，還是有很好的借鑒意義的，這里一並附上
