這 是我以前寫的一篇文章，用於整理自己對自動化測試的理解。當時寫這個文章的目的，是因為剛剛掌握qtp，又使用自動化測試參與公司乙個大專案的測試，結果 發現原來掌握qtp距離自動化測試還有很遙遠的路要走，原來一直以為掌握了qtp的指令碼編寫、可以寫出所有的測試方法指令碼則自動化測試就可以大功告成了。 但是現實是殘酷的，實際和自己所想的相差太遠了——實際的情況是需求變化快，甚至有段時間開發還沒有需求變化快，自動化測試指令碼的維護工作量就可想而知 了。 因此我當時就諮詢了一下其他的測試同行，他們都認為測試**復用是很重要的問題，要搭建乙個好的測試框架，這就是我當時寫這篇文章的目的。
但是在寫了這篇文章 後，因為工作原因沒有用實踐去驗證文章裡的思想，直到今天才有時間來溫習以前的教訓。今天來按實際來做時，發現了乙個問題——用什麼方式來劃分test level service function 的顆粒呢？打個比方來說，我要寫乙個測試函式，實現以下功能：我要測試的是登入乙個系統，開啟乙個頁面，然後新建一條記錄。因為還有其他的測試函式，肯定 與這個函式有相同的**部分，比如登入就是顯而易見，但是還有一些**肯定也是重複，而且是隱藏的，那麼用什麼方法把它們挖掘出來，細分的原則是什麼？我 實在想不清楚，需要大家的指點．文章裡的一些內容取自別人的帖子或與同行的交流，所以只能算是半原創．
自動化測試框架指南
以下只是測試框架的一點設想，需要以後修改；
這套方案的最終結果是實現測試自動化，但是因為目前人力、實力有限，只能逐步完善設想中的功能；最終的目的是要實現define the driver——定義驅動測試。
本文的自動化測試以mi公司的quicktest professional 為例
1定義：
1.1services function 的分類及分類原則
service function的顆粒大小需求不一，靠自己來掌握，總之應該是盡量少的service function滿足所有case function的需要
common level——所有專案測試都可以使用的函式，比如驗證小數精度、寫測試結果到報告等等。
common level是公用的函式庫，不需要經常修改，因此可以編成dll檔案，供所有的測試指令碼使用。
使用語法可以這樣：
『------------------------------------
set object=createobject(「」)
call object.funciton 「」
『------------------------------------
high level——各專案專用的測試用例，是為專門的測試專案而設定的，但是這些services function不能單獨作測試，必須配合更高一級的test level才能使用。
test level——test level可以這樣理解：是對某乙個使用者來說，為了完成某項工作和業務，時間從頭至尾相對連續的一組操作。
test level並不是測試用例，但是它的顆粒大小卻決定了其復用程度，因此需要仔細分析每個testcase的業務邏輯，將相同的test level services function 總結出來。
test level的組成：
function
step 『測試所要進行的操作
validation 『驗證測試的結果
return result 『返回測試的結果，validation的驗證結果也應該通過這一部分的函式寫入到result report中
end function
1.2 test case 和test suite
test case和test suite的意義：
1、大量的case，肯定是分模組存放的。否則就難以查詢和維護、修改。
2、test case和test level /high level service function的互相呼叫關係可以通過insight sources這個工具來查詢。
3、suite相當於乙個case模組，裡面包含很多個case；比如測試使用者管理的，都放在乙個suite裡，測試裝置管理的，放在另乙個suite裡。
1.3testcase的分類原則
1.4測試用例和services function命名規則
型別 名稱
test case 專案名_tc_name
test level services function 專案名_tl_name
high level services function 專案名_hl_name
common level services function cl_name(不應包括專案名，因為此類函式是公用的)
2工作方式
並非所有的測試用例都可以用自動化來完成，因此需要對用例進行挑選，選擇合適的用例作為自動化測試用例。記住！自動化測試的成本是巨大的，一般來說，乙個指令碼執行6~7次才算收回成本，因此不可寄予自動化測試過高期望。
2.1選擇自動化測試用例
2.1.1不適合自動化測試用例的情況
2.1.2適合自動化測試的情況
自動化測試之所以能在很多大公司實施起來，就是有它適合自動化測試的特點和高的投資回報率。
2.2編寫test case和test level
分析test case的業務，將test level services function 的顆粒從test case中識別出來，盡量做到用少的service function來實現測試業務。
2.3搭建測試框架
依據測試框架，在下一節中提到。依次填入測試框架的內容。
2.4執行測試並記錄bug
這時就可以開始執行測試。測試結果應該自動被記錄在測試報告中，而不應該一遇到bug就停止——除非必須停止。這裡注意以下幾點
2.5維護測試指令碼
3測試框架的構想
3.1test driver
測試框架的核心叫test driver，它具有以下一些東西
4團隊開展自動化測試要點
單人自動化測試與團隊開展自動化測試有很大不同，因為不同的物件名、不同的函式會造成每個人的測試指令碼不同，並難以合併成乙個完整、統一的指令碼。為了解決這個問題，應該注意以下幾點：
5測試配置
測試配置應該盡量自動完成，減少工作量。
測試配置包括如下內容：
6測試初始設定
一些測試用例相互依賴，本應該把它們合成乙個測試用例；但是如果單個測試用例顆粒很大，那麼在回歸測試或再現缺陷時就會使人發瘋，並且浪費了大量的測試時 間。最好最可靠的解決辦法看來只有一種，那就是將顆粒大的測試用例分離出來，同時為這個測試用例預備測試初始設定——將客戶端所需要的資料庫結構和資料庫 備份，並且作為測試初始設定儲存管理。
這裡的測試初始設定並非只針對自動化測試，手工測試也被包括進來。
6.1測試初始設定的命名辦法
te+測試用例編號
如測試用例為tc1.2，則te為te1.2
6.2測試初始設定的儲存
測試初始設定應儲存在單獨的資料夾內，初始設定的路徑被鏈結到test driver上。
自動化測試框架
可設計為五層 一 測試用例層 主要存放用例的指令碼，分為主指令碼和子指令碼。主指令碼用來控制各個子指令碼，實現指令碼間的資料傳遞。子指令碼是實現各個功能點的指令碼，同時也會提取出一些共用的方法，一般放在提取層中。主指令碼中可使用資料驅動來控制指令碼實現各種場景的流程，如silktest的test s...
自動化測試框架 自動化測試呼喚開發
週末參加了testage 測試時代 組織的乙個專家討論會。主要討論測試自動化。說是專家討論會，我參加實在是慚愧，我對測試的理解實在是太淺薄了。只是因為在部落格上發表了一些謬論才收到邀請。想著可以幫助公司去接受一些新的思想，而自己也可以結識一些朋友，便去了。對於測試時代的會議組織，我以為定位和思路還是...
UFT自動化測試框架
使用vbs的function代替指令碼中的action。uft工具自帶call action的方法進行指令碼復用，但本框架使用function的方法代替call action，每個function執行乙個測試步驟，通過組合多個function可完成乙個測試用例。資料檔案統一維護。所有需要用到的測試資...