可設計為五層
一、測試用例層 ：主要存放用例的指令碼，分為主指令碼和子指令碼。主指令碼用來控制各個子指令碼，實現指令碼間的資料傳遞。子指令碼是實現各個功能點的指令碼，同時也會提取出一些共用的方法，一般放在提取層中。主指令碼中可使用資料驅動來控制指令碼實現各種場景的流程，如silktest的test suites and test plan,td中也類似，在qtp中，可建立乙個main的action來實現這樣的功能。
二、提取層：專案指令碼可維護性的關鍵，把專案共用的變數，通用的方法、函式放在該層。而這些方法和函式往往是這個自動化專案中最難設計的一塊,不同的專案可能使用的方法和思路也不一樣.專案中很大的一部分工作量會消耗在這裡.比如把指令碼進入的初始化的方法放在這裡,該方法將配置專案執行環境,從伺服器上拷貝資料,當然也會針對一些已知的或者或未知的異常情況進行處理,來恢復正常的下個指令碼的執行.在silktest中,一般會放在inc檔案下,而qtp則可寫一些vbs等外部檔案來存放和維護.
三、應用層：物件庫放在本層，自動化中，由於物件庫的好壞直接決定了該專案自動化的成敗,相對於qtp有強大的物件庫管理的功能, silktest相對就是乙個比較原始和底層的物件管理模式,更像使用描述性程式設計的qtp,當然兩者之間還是有很多差異.建議假如是大規模的專案,不妨專人負責物件庫的維護和管理,該人需要很高的自動化經驗,他的責任不僅僅在專案初期把底層的物件庫建立起來,在中期和後期對物件庫的維護,更多的是針對專案的特殊情況對工具層提供的方法進行繼承和擴充套件.比如我們可以對close的方法進行擴充套件,新增自己的log日誌,甚至可以結合普通層中對於效能的方法進行一些效能資料的採集等.在專案的實踐過程中,會有事半功倍的效果的.
四、普通層：該層是衡量乙個公司自動化水平的標誌,這裡集合了很多專案的經驗,是乙個通用的方法的集合,通常會把自己的log日誌的方法,對資料庫的操作等等,當然也有一些通用的函式方法放在這裡,比如說上面說到的採集效能資料的方法,捕獲異常的方法等等.
五、工具層:該層就是工具提供的一些方法,比如click,dbclick等
文件,備註的維護也是不可忽視的重點,一般的自動化測試都會持續半年以上,所以制訂相應的流程,文件規範化是乙個好的專案必備的要求.
注:摘自51testing部落格.
自動化測試框架 自動化測試呼喚開發
週末參加了testage 測試時代 組織的乙個專家討論會。主要討論測試自動化。說是專家討論會，我參加實在是慚愧，我對測試的理解實在是太淺薄了。只是因為在部落格上發表了一些謬論才收到邀請。想著可以幫助公司去接受一些新的思想，而自己也可以結識一些朋友，便去了。對於測試時代的會議組織，我以為定位和思路還是...
自動化測試框架指南
這 是我以前寫的一篇文章，用於整理自己對自動化測試的理解。當時寫這個文章的目的，是因為剛剛掌握qtp，又使用自動化測試參與公司乙個大專案的測試，結果 發現原來掌握qtp距離自動化測試還有很遙遠的路要走，原來一直以為掌握了qtp的指令碼編寫 可以寫出所有的測試方法指令碼則自動化測試就可以大功告成了。但...
UFT自動化測試框架
使用vbs的function代替指令碼中的action。uft工具自帶call action的方法進行指令碼復用，但本框架使用function的方法代替call action，每個function執行乙個測試步驟，通過組合多個function可完成乙個測試用例。資料檔案統一維護。所有需要用到的測試資...