這是我以前寫的一篇文章，用于整理自己對自動化測試的理解。當時寫這個文章的目的，是因為剛剛掌握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次才算收回成本，因此不可寄予自動化測試過高期望。
2.1選擇自動化測試用例
2.1.1不適合自動化測試用例的情況
定制型項目（一次性的）。為客戶定制的項目，維護期由客戶方承擔的，甚至采用的開發語言、運行環境也是客戶特別要求的，即公司在這方面的測試積累就少，這樣的項目不適合作自動化測試。
項目周期很短的項目。項目周期很短，測試周期很短，就不值得花精力去投資自動化測試，好不容易建立起的測試腳本，不能得到重復的利用是不現實的。
業務規則復雜的對象。業務規則復雜的對象，有很多的邏輯關系、運算關系，工具就很難測試。
美觀、聲音、易用性測試。人的感觀方面的：界面的美觀、聲音的體驗、易用性的測試，也只有人來測試。
測試很少運行。測試很少運行，對自動化測試就是一種浪費。自動化測試就是讓它不厭其煩的、反反復復的運行才有效率。
軟件不穩定。軟件不穩定，則會由于這些不穩定因素導致自動化測試失敗。只有當軟件達到相對的穩定，沒有界面性嚴重錯誤和中斷錯誤才能開始自動化測試。
涉及物理交互。工具很難完成與物理設備的交互，比如刷卡的測試等。
2.1.2適合自動化測試的情況
自動化測試之所以能在很多大公司實施起來，就是有它適合自動化測試的特點和高的投資回報率。
產品型項目。產品型的項目，每個項目只改進少量的功能，但每個項目必須反反復復的測試那些沒有改動過的功能。這部分測試完全可以讓自動化測試來承擔， 同時可以把新加入的功能的測試也慢慢地加入到自動化測試當中。
增量式開發、持續集成項目。由于這種開發模式是頻繁的發布新版本進行測試，也就需要頻繁的自動化測試，以便把人從中解脫出來測試新的功能。
能夠自動編譯、自動發布的系統。要能夠完全實現自動化測試，必須具有能夠自動化編譯，自動化發布系統進行測試的功能。 當然，不能達到這個要求也可以在手工干預的情況下進行自動化測試。
回歸測試�；貧w測試是自動化測試的強項，它能夠很好的驗證你是否引入了新的缺陷，老的缺陷是否修改過來了。在某種程度上可以把自動化測試工具叫做回歸測試工具。
多次重復、機械性動作，將煩瑣的任務轉化為自動化測試。自動化測試最適用于多次重復、機械性動作，這樣的測試對它來說從不會失敗。比如要向系統輸入大量的相似數據來測試壓力和報表。
需要頻繁運行測試。在一個項目中需要頻繁的運行測試，測試周期按天算，就能最大限度的利用測試腳本，提高工作效率。
2.2編寫Test case和Test level
分析Test Case的業務，將Test Level services function 的顆粒從Test Case中識別出來，盡量做到用少的Service function來實現測試業務。
2.3搭建測試框架
依據測試框架，在下一節中提到。依次填入測試框架的內容。
2.4執行測試并記錄bug
這時就可以開始執行測試。測試結果應該自動被記錄在測試報告中，而不應該一遇到BUG就停止——除非必須停止。這里注意以下幾點
測試報告功能應該在Common level中實現，這樣所有的測試都可以共用。
測試框架應該具有一定的判斷功能，一旦某個測試失敗。測試框架可以決定停止測試，或者轉入不受影響的新測試用例，Test suite分類也應該注意這一點，因為同一個Test suite一般來說是互相影響的。
測試框架可以具有某種還原測試環境的功能——即測試結束清理的功能，這樣就可以自動恢復到不受影響的測試環境中。
2.5維護測試腳本
這是一項工作量很大的工作。維護腳本的難度很大程度上與團隊活動有關，相關信息參考第4節。
3測試框架的構想
3.1Test Driver
測試框架的核心叫Test driver，它具有以下一些東西
全局參數。
所要測試的用例集，也許叫Test suite集更合適；包括測試所要用到的參數。
對于用例的描述。
lib and tsr。
能夠判斷測試結果，并且決定是否調用其它的測試用例，或者停止測試。
自動生成測試報告。以及需要輸出的路徑。
每個測試腳本的初始設置路徑
4團隊開展自動化測試要點
單人自動化測試與團隊開展自動化測試有很大不同，因為不同的對象名、不同的函數會造成每個人的測試腳本不同，并難以合并成一個完整、統一的腳本。為了解決這個問題，應該注意以下幾點：
團隊成員在編寫腳本時應該多使用對象庫，盡量少使用描述性編程。
統一對象名稱，規定網頁元素對象命名的統一規定，這樣才可能在合并對象庫時統一。
統一函數命名規定。
統一函數書寫格式。
統一對同一類型操作的處理方式——應該定期舉行會議，溝通各種操作的處理方法，共同提高對系統的認識水平。
5測試配置
測試配置應該盡量自動完成，減少工作量。
測試配置包括如下內容：
測試工具的配置
測試環境，如數據、數據庫結構
6測試初始設置
一些測試用例相互依賴，本應該把它們合成一個測試用例；但是如果單個測試用例顆粒很大，那么在回歸測試或再現缺陷時就會使人發瘋，并且浪費了大量的測試時間。最好最可靠的解決辦法看來只有一種，那就是將顆粒大的測試用例分離出來，同時為這個測試用例預備測試初始設置——將客戶端所需要的數據庫結構和數據庫備份，并且作為測試初始設置保存管理。
這里的測試初始設置并非只針對自動化測試，手工測試也被包括進來。
6.1測試初始設置的命名辦法
TE+測試用例編號
如測試用例為TC1.2，則TE為TE1.2
6.2測試初始設置的保存
測試初始設置應保存在單獨的文件夾內，初始設置的路徑被鏈接到Test driver上。
因此我當時就咨詢了一下其他的測試同行，他們都認為測試代碼復用是很重要的問題，要搭建一個好的測試框架，這就是我當時寫這篇文章的目的。
但是在寫了這篇文章后，因為工作原因沒有用實踐去驗證文章里的思想，直到今天才有時間來溫習以前的教訓。今天來按實際來做時，發現了一個問題——用什么方式來劃分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次才算收回成本，因此不可寄予自動化測試過高期望。
2.1選擇自動化測試用例
2.1.1不適合自動化測試用例的情況
定制型項目（一次性的）。為客戶定制的項目，維護期由客戶方承擔的，甚至采用的開發語言、運行環境也是客戶特別要求的，即公司在這方面的測試積累就少，這樣的項目不適合作自動化測試。
項目周期很短的項目。項目周期很短，測試周期很短，就不值得花精力去投資自動化測試，好不容易建立起的測試腳本，不能得到重復的利用是不現實的。
業務規則復雜的對象。業務規則復雜的對象，有很多的邏輯關系、運算關系，工具就很難測試。
美觀、聲音、易用性測試。人的感觀方面的：界面的美觀、聲音的體驗、易用性的測試，也只有人來測試。
測試很少運行。測試很少運行，對自動化測試就是一種浪費。自動化測試就是讓它不厭其煩的、反反復復的運行才有效率。
軟件不穩定。軟件不穩定，則會由于這些不穩定因素導致自動化測試失敗。只有當軟件達到相對的穩定，沒有界面性嚴重錯誤和中斷錯誤才能開始自動化測試。
涉及物理交互。工具很難完成與物理設備的交互，比如刷卡的測試等。
2.1.2適合自動化測試的情況
自動化測試之所以能在很多大公司實施起來，就是有它適合自動化測試的特點和高的投資回報率。
產品型項目。產品型的項目，每個項目只改進少量的功能，但每個項目必須反反復復的測試那些沒有改動過的功能。這部分測試完全可以讓自動化測試來承擔， 同時可以把新加入的功能的測試也慢慢地加入到自動化測試當中。
增量式開發、持續集成項目。由于這種開發模式是頻繁的發布新版本進行測試，也就需要頻繁的自動化測試，以便把人從中解脫出來測試新的功能。
能夠自動編譯、自動發布的系統。要能夠完全實現自動化測試，必須具有能夠自動化編譯，自動化發布系統進行測試的功能。 當然，不能達到這個要求也可以在手工干預的情況下進行自動化測試。
回歸測試�；貧w測試是自動化測試的強項，它能夠很好的驗證你是否引入了新的缺陷，老的缺陷是否修改過來了。在某種程度上可以把自動化測試工具叫做回歸測試工具。
多次重復、機械性動作，將煩瑣的任務轉化為自動化測試。自動化測試最適用于多次重復、機械性動作，這樣的測試對它來說從不會失敗。比如要向系統輸入大量的相似數據來測試壓力和報表。
需要頻繁運行測試。在一個項目中需要頻繁的運行測試，測試周期按天算，就能最大限度的利用測試腳本，提高工作效率。
2.2編寫Test case和Test level
分析Test Case的業務，將Test Level services function 的顆粒從Test Case中識別出來，盡量做到用少的Service function來實現測試業務。
2.3搭建測試框架
依據測試框架，在下一節中提到。依次填入測試框架的內容。
2.4執行測試并記錄bug
這時就可以開始執行測試。測試結果應該自動被記錄在測試報告中，而不應該一遇到BUG就停止——除非必須停止。這里注意以下幾點
測試報告功能應該在Common level中實現，這樣所有的測試都可以共用。
測試框架應該具有一定的判斷功能，一旦某個測試失敗。測試框架可以決定停止測試，或者轉入不受影響的新測試用例，Test suite分類也應該注意這一點，因為同一個Test suite一般來說是互相影響的。
測試框架可以具有某種還原測試環境的功能——即測試結束清理的功能，這樣就可以自動恢復到不受影響的測試環境中。
2.5維護測試腳本
這是一項工作量很大的工作。維護腳本的難度很大程度上與團隊活動有關，相關信息參考第4節。
3測試框架的構想
3.1Test Driver
測試框架的核心叫Test driver，它具有以下一些東西
全局參數。
所要測試的用例集，也許叫Test suite集更合適；包括測試所要用到的參數。
對于用例的描述。
lib and tsr。
能夠判斷測試結果，并且決定是否調用其它的測試用例，或者停止測試。
自動生成測試報告。以及需要輸出的路徑。
每個測試腳本的初始設置路徑
4團隊開展自動化測試要點
單人自動化測試與團隊開展自動化測試有很大不同，因為不同的對象名、不同的函數會造成每個人的測試腳本不同，并難以合并成一個完整、統一的腳本。為了解決這個問題，應該注意以下幾點：
團隊成員在編寫腳本時應該多使用對象庫，盡量少使用描述性編程。
統一對象名稱，規定網頁元素對象命名的統一規定，這樣才可能在合并對象庫時統一。
統一函數命名規定。
統一函數書寫格式。
統一對同一類型操作的處理方式——應該定期舉行會議，溝通各種操作的處理方法，共同提高對系統的認識水平。
5測試配置
測試配置應該盡量自動完成，減少工作量。
測試配置包括如下內容：
測試工具的配置
測試環境，如數據、數據庫結構
6測試初始設置
一些測試用例相互依賴，本應該把它們合成一個測試用例；但是如果單個測試用例顆粒很大，那么在回歸測試或再現缺陷時就會使人發瘋，并且浪費了大量的測試時間。最好最可靠的解決辦法看來只有一種，那就是將顆粒大的測試用例分離出來，同時為這個測試用例預備測試初始設置——將客戶端所需要的數據庫結構和數據庫備份，并且作為測試初始設置保存管理。
這里的測試初始設置并非只針對自動化測試，手工測試也被包括進來。
6.1測試初始設置的命名辦法
TE+測試用例編號
如測試用例為TC1.2，則TE為TE1.2
6.2測試初始設置的保存
測試初始設置應保存在單獨的文件夾內，初始設置的路徑被鏈接到Test driver上。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
