這是我以前寫的一篇文章，用于整理自己對自動化測試的理解。當時寫這個文章的目的，是因為剛剛掌握QTP，又使用自動化測試參與公司一個大項目的測試，結果發現原來掌握QTP距離自動化測試還有很遙遠的路要走，原來一直以為掌握了QTP的腳本編寫、可以寫出所有的測試方法腳本則自動化測試就可以大功告成了。但是現實是殘酷的，實際和自己所想的相差太遠了——實際的情況是需求變化快，甚至有段時間開發還沒有需求變化快，自動化測試腳本的維護工作量就可想而知了。 因此我當時就咨詢了一下其他的測試同行，他們都認為測試代碼復用是很重要的問題，要搭建一個好的測試框架，這就是我當時寫這篇文章的目的。
但是在寫了這篇文章后，因為工作原因沒有用實踐去驗證文章里的思想，直到今天才有時間來溫習以前的教訓。今天來按實際來做時，發現了一個問題——用什么方式來劃分test level service function 的顆粒呢？打個比方來說，我要寫一個測試函數，實現以下功能：我要測試的是登錄一個系統，打開一個頁面，然后新建一條記錄。因為還有其他的測試函數，肯定與這個函數有相同的代碼部分，比如登錄就是顯而易見，但是還有一些代碼肯定也是重復，而且是隱藏的，那么用什么方法把它們挖掘出來，細分的原則是什么？我實在想不清楚，需要大家的指點．文章里的一些內容取自別人的帖子或與同行的交流，所以只能算是半原創．
自動化測試框架指南
以下只是測試框架的一點設想，需要以后修改；
這套方案的最終結果是實現測試自動化，但是因為目前人力、實力有限，只能逐步完善設想中的功能；最終的目的是要實現define the driver——定義驅動測試。
本文的自動化測試以MI公司的QuickTest professional 為例
1定義：
Services function :業務函數
TestCase(測試用例)：是能夠從頭至尾獨立執行的最小測試單元
測試框架的設想
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: 是一個相同工作性質的工作部門人員，為了完成某項工作和業務，時間從頭至尾相對連續的一組操作。
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的分類原則
一般復雜Case，要牽扯到好多個模塊的功能的，但是要看它的主要測試點是什么，然后按這個測試點所屬模塊，來確定這個Case歸屬哪個模塊的。
有依賴關系的Case，是合并成一個Case，還是保留獨立？運行起來有依賴關系,傾向于合并成一個Case，合并的好處是運行方便，但是出錯時要再區分是那個小Case的錯誤;分開的話，就相反，運行不方便，但出錯時比較明確哪個錯了。
如果A是建10萬個用戶，要花1小時的時間，那你還會放在一塊嘛，肯定是傾向分開成小Case，不然B出錯了，你還得再重頭跑ABCD，測試人員會氣死的！所以運行麻煩、容易出錯、時間較長的小case，還是保持獨立，只要跟測試人員寫好說明文檔，讓他們知道正確的運行方法，就可以了。
如果合成一個case，我應該把它放到哪個suite里呢 因為它橫跨了幾個頁面，都是測試點，不好劃分啊。放在那個Suite里啊，那都可以啊，或者你想獨立一個suite也可以啊，無所謂的，只要你運行結果有正確記錄，不會漏掉丟失就可以了。
測試環境可以通過重新導入數據來恢復，這樣就可以將一部分運行時間長、但是又有依賴關系的Test case分離出來，避免總是要從開頭進行測試。
一個Test suite里的用到的lib和OR都是相同的。
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次才算收回成本，因此不可寄予自動化測試過高期望。
文章來源于領測軟件測試網 http://www.k11sc111.com/
