但是在寫了這篇文章后，因為工作原因沒有用實踐去驗證文章里的思想，直到今天才有時間來溫習以前的教訓。今天來按實際來做時，發現了一個問題——用什么方式來劃分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.anti-gravitydesign.com/