四種常用的自動化測試框架

一直想仔細研究框架，寫個流水賬似的測試程式不難，寫個低維護成本的測試框架就很難了，所以研究多種測試框架還是很有必要的，知道孰優孰劣，才能在開始編寫框架的時候打好基礎，今天讀到了KiKi Zhao的翻譯文章，覺得很是不錯，寫了一點學習心得，有不正確之處，請指出。

中文原文地址：http://www.cnblogs.com/nckiki/articles/244202.html

英文原文地址：http://www.ibm.com/developerworks/rational/library/591.html

原文對自動化測試架構做了如下四種分類：

1.       資料驅動測試框架（The Data-Driven Testing Framework）

說明：

僅僅是將測試資料從測試指令碼中分離出來，開始了非混沌狀態的第一步，這也是所有測試架構中最簡單的一種

 

優點：

至少測試資料可以單獨維護了

 

缺點：

任何被測試程式的變更所導致的工作量是所有架構中最多的，因此維護成本非常高

 

2.       測試指令碼模組化框架（The Test Script Modularity Framework）

   

 

說明：

l  箭頭方向代表的是被呼叫和呼叫關係

l  測試指令碼中包含了各功能點中涉及到的控制元件識別和業務邏輯操作，其中包含了外部測試資料的呼叫

l  測試指令碼的維護由自動化測試開發工程師負責，要求必須懂自動化程式設計和業務邏輯

l  測試資料的維護由測試工程師負責

 

優點：

控制元件和業務邏輯一旦發生變化，要進行修改和維護的是底層的測試指令碼（比無任何抽象封裝的自動化測試程式稍好一些）

 

缺點：

l  幾乎所有大的變更引起的工作量都由自動化測試開發工程師完成

l  控制元件識別和業務邏輯本身屬於不同的領域，沒有很好進行抽象封裝

 

3.       測試庫構架框架（The Test Library Architecture Framework）

   

 

說明：

l  箭頭方向代表的是被呼叫和呼叫關係

l  將所有的針對測試系統本身的控制元件識別和控制元件支援的操作封裝在測試庫中

l  測試指令碼呼叫測試庫的同時傳遞外部的測試資料

l  測試庫的編寫由自動化測試開發工程編寫（可以不懂業務），負責控制元件的變更和維護

l  測試指令碼的編寫可由對業務比較掌握的自動化測試開發工程編寫，負責業務邏輯的變更和維護

l  測試資料由測試工程師維護（可以不懂自動化開發）

優點：

l  被測試系統無論是哪層發生變化，只需要相應的人員進行變更維護即可

l  完成了控制元件識別操作和業務邏輯的抽象分離

缺點：
變更引起的工作量還是附加在自動化測試開發工程師身上

 

4.       關鍵字驅動或表驅動測試框架（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和測試資料

 

缺點：

框架的抽象程度比較高，對自動化測試工程師的開發能力比較高

 

總結：個人認為以上的四種架構是存在遞進關係的，至少前三個是肯定的，原文中最後總結的圖認為還是需要多種框架特點組合在一起的，還是有很好的借鑑意義的，這裡一併附上