自動化測試并不只是利用自動化測試工具進行錄制回放操作。雖然基本是每一個自動化測試工具都必須提供的功能,但如果只是這么應用,從嚴格意義上來說,這并不能算是自動化測試。最多只能說是實現了一定的自動化操作。因為這時自動化腳本都是寫死的,自動化測試使用的數據也是寫死的,沒有靈活性可言,也沒有對腳本進行容錯性處理,腳本基本是運行不完。且也沒有添加測試驗證,不能驗證執行結果是否符合預期的結果。
早期使用QTP,可以利用QTP提供的功能實現三層架構:測試數據,測試對象和測試腳本三個結構的分離。QTP提供DataTable對象來保存測試數據,且也提供了把腳本中的測試數據參數化到DataTable而腳本中只引用了參數化的名稱的功能,而DataTable存儲的是一個Excel文檔,方便修改測試數據,這樣便實現了測試數據與測試腳本分離;QTP也把自動化測試中要操作的對象放到了對象庫中進行管理者,實現了對對象的統一管理,也實現了測試對象與測試腳本的分離。
進一步的深入,會發現自動化腳本中的邏輯結構的功能實現緊密的結合在一起,給后期的維護和修改造成的很大的麻煩。這時就會想到需要把測試腳本進行細分。因此除了按上面說到的把測試數據,測試對象分離出腳本外,還需要把腳本細分為:邏輯控制和功能實現腳本。也即實現了自動化腳本的四層架構設計。功能實現腳本即為把腳本把每個小功能細分出來并編寫成一個個獨立的小的功能實現腳本,如登錄,登記等等。然后編寫邏輯控制腳本來實現這些小的功能實現腳本執行的先后和次數,如,實現流程等。
實際應用自動化后,會發現很多腳本實現方法相同或相似,而且功能小腳本拼接不容易修改。這時可以再上面四層架構的基礎再增加一個框架結構,實現五層架構。利用框架封裝一些常用的方法、函數和小腳本,以實現公共腳本的復用,減少自動化腳本的開發時間。在框架中還可以把上面的四層架構的內容包含到框架中進行統一管理和調度。當然還可以利用配置文檔(如ini文件)來實現流程或其他功能的可配置測試(如,網址,用戶名,密碼。方便改變測試環境后修改)。
以上只是針對整體的大的自動化方面來區分,當然還可以對一些小的部分進行細分,以達到更好的可配置性和容錯性,降低腳本的修改成本??梢栽偌毞值脑O計如下(暫時想到的):
1.測試對象的定制
首先可以應用QTP的對象管理來實現對象維護功能,但是這個功能在實現對象的定制上還是比較弱。QTP支持使用描述性編程來實現對象的識別,即可以通過定制的識別對象的屬性名和屬性值來實現對象的識別。這樣就可以把對象的類型和識別對象的屬性名和屬性值維護在框架中的對象識別Excel文檔中,格式如下,這樣就能實現更強的對象定制功能:
表--對象識別表
對象名 | 對象類型 | 識別對象屬性及值 |
登錄按鈕 | WebButton | Name:=登錄 |
|
|
|
2. 邏輯配置到外部文檔,實現事件與腳本分離
通過把要實現的邏輯按順序配置到外部文件,然后再QTP腳本中調用此配置文件,最后根據配置文件中的信息調用不同的腳本、對象、測試數據來進行測試。配置樣表如下:
表--登錄流程表
序號 | 對象 | 事件 |
1 | 用戶名輸入框 | Set |
2 | 用戶密碼輸入框 | Set |
3 | 登錄按鈕 | Click |
4 | 登錄后頁面 | Check |
|
|
|
原文轉自:http://www.uml.org.cn/Test/200905218.asp