1、實現自動化測試框架做功能自動化測試都會不約而同的遇到一個比較棘手的問題測試框架的搭建。這也是直接影響功能自動化測試成功與否的關鍵。框架做的好可以使測試事半功倍，反之輕則很難看到工作的成果重則會使整個測試失敗。目前網上有很多關于測試框架的討論，其中也有成型的測試框架，其中有很多好的思想在里邊，很值得借鑒。但今天要討論的不是網上已有的，而是HP已經為我們設計好的一個測試體系，業務組件測試。他是利用QTP與QC的完美結合組成的一個體系架構。它可以輕易實現目前比較流行的三層測試架構：腳本層，業務層，數據層相分離，為開展功能自動化測試提供一個高效、穩定、容易的測試實現。   

2、;     一概述        11業務組件（Bussiness Process Testing）簡介        業務組件是組成流程測試的基本單元，組合不同的業務組件可以實現不同的業務流程測試。如將fligt系統的登錄最為一個組件，選擇航班最為一個組件等。這樣可以實現組件的復用，提高開發效率。         12 Bussines

3、s Process Testing的優點        1）   相關業務人員可以在沒有腳本的環境下組合業務組件，實現業務流程。        2）   對業務人員的編程能力沒有要求，業務人員只需了解系統的業務流程，不用關心具體的腳本實現。這一點也實現了業務層和腳本層的分離。        3）   一旦某個

4、組件開發完畢，即可在不同的流程中使用該組件，實現高可復用性，從而加快業務流程測試的速度。        4）   明確的角色分工，業務人員負責流程的開發、組織；QTP工程師負責腳本的開發、維護以及相應函數庫的開發、維護。        5）   因為實現了腳本的復用，提高了自動化開發的效率，無形中就降低了測試過程中維護的時間和成本。     

5、60;  13 Bussiness Process Testing的簡易流程        如圖所示，整個過程分為2條線：第一個是由業務測試人員劃分組件并組合不同的組件實現不同的流程測試；其次QTP專家負責組件的腳本具體實現并負責調試成功，上傳到QC供業務測試人員調用。        注：測試數據的組織后邊介紹，以便實現三層的測試架構；此過程需要QC有Bussiness Process Testing組件許可的支持，也就是需要單獨向HP購買。&#

6、160;       下邊以QTP自帶的示例程序演示整個流程的開發過程        21劃分組件        本次將系統劃分為：登錄；選擇航班并插入；打開訂單；更新訂單；刪除訂單；注銷。這樣劃分僅為演示之用，不用在實際的測試之中。        22組織業務測試流程     

7、   本次只是用于演示，所以流程不會100覆蓋，在實際的測試過程中要達到100的流程覆蓋。本次測試流程如下：        流程1：登錄選擇航班并插入注銷        流程2：登錄選擇航班并插入更新訂單注銷        流程3：登錄選擇航班并插入更新訂單刪除訂單注銷        流程4：登錄打

8、開訂單更新訂單刪除訂單注銷        下邊需要根據劃分的組件來實現組件腳本的實現。        23創建應用程序區域        在開發腳本之前首先要做的是要創建一個應用程序區域。應用程序區域提供創建業務組件所需的所有資源和設置，每個業務組建都居于一個應用程序區域，并從這些應用程序區域集成這些資源和設置。在此創建一個名為“訂票系統流程測試”的區域，如圖所示。  

9、;      創建過程:依次選擇:fileNewFunction library。保存后自動上傳至QC默認目錄。        在此也可以加載自己的函數庫，對象庫，恢復場景等，這樣以后創建的組建都可以共享該應用程序區域的資源。同時也方便維護，這也是一個優點所在，例如一旦函數庫改變在此從新加載新的函數庫即可，不用在腳本理修改?？傊@個應用程序區域很重要，以后所有的腳本均是基于這個區域。應用程序路徑一定要加載正確，否則錄制時不能生成腳本。   

10、60;    24創建腳本        在創建腳本之前最好在QC中組織好目錄樹，方便保存及調用。關于腳本的開發過程，每個人、每個公司都有自己的方法。在此源代碼也沒法一一貼出。所以在此只列出輸入參數和輸出參數，方便后邊的參數化以及數據組織。本次也采用最通用的方式即對象庫解決對象識別問題。腳本的開發規范以及參數命名也以我自己慣用方式。  注：“”為無相應參數。        在QTP中創建組件腳本有2中模式：Bussi

11、ness Component和Scripted Component。區別：Bussiness Component只能見關鍵字視圖，QC中亦可見關鍵字視圖；Scripted Component可以看見專家視圖，在QC中腳本代碼不可見。一般創建后者，本次也是采用后者，方便編輯腳本，控制腳本結構。        注意：參數一定要合理設置并對代碼中的輸入項做參數化與參數關聯，否則測試數據傳不到腳本，導致腳本運行失敗。參數可以在QTP中創建，也可以在QC中創建，效果等同。     &#

12、160;  腳本開發完保存至QC，如圖:         至此腳本開發完畢。也實現了腳本和業務層、數據層的脫離，現在單個組件腳本實現業務流程中的某一個功能且腳本中不會涉及具體的測試數據，從而為實現三層結構打下基礎。接下來的工作就是在QC中組織需要測試的業務流程以及需要的測試數據。        這里有一個需要注意的地方，就是在QTP創建腳本如果選擇Bussiness Component類型，在“設計步驟”選項卡可以看到QTP中的關鍵字視圖，相關人

13、員可以像在QTP操作一樣，但是看不到代碼。這也是為何上邊為何創建腳本組件的原因。        25業務流程的組織        業務流程的組織主要是在“測試計劃”模塊中實現。這的主要工作是由業務測試人員完成。規劃好目錄結構以后，根據需要測試的業務流程拖拽需要的組件即可。這一步和在“測試計劃”中拖拽測試用例很相似，區別就是這個是組合業務流程，而且可以自動執行。組織好后的效果如圖：      

14、60; 需要注意的是，創建用例是請選擇“BUSINESS-PROCESS”測試類型，否則組件腳本拖拽不過來。拖拽腳本是在“測試腳本”選項卡中進行，如上圖。限于篇幅，在此創建目錄和拖拽等動作不再詳述，請參見QC的用戶手冊。另外，根據實際的系統，可以把組件分組，以組的形式控制流程。例如，選擇如圖的2到4的組件，然后選擇工具欄叉號旁邊的圖標，即可把組件分成一組。這樣可以更好的控制流程。至此，所有的業務流程均以實現?？梢栽赒C中選擇運行（綠色箭頭），進行相關的調試。        這里實現的是三層結構中的業務層。這里進行的業務流程組

15、織和腳本沒有任何關系，相關人員不用關心腳本如何實現，只要保證所有的流程均已覆蓋即可。        接下來就是要實現數據層的工作了，從而實現三層的測試架構。        26測試數據的組織        測試數據的組織也是在“測試計劃”模塊中實現。選擇某一個流程，在“測試腳本”選項卡中右擊要設計數據的組件，在彈出窗口中選擇“迭代”，彈出組件迭代設置窗口，如圖：  &

16、#160;     在此可以根據測試需求設置組件要迭代的次數，以及每次迭代的參數值。如上圖，設置了3次迭代每次迭代輸入的訂單信息均不相同。同時可以設置輸入參數選擇上一個組件的輸出參數（在復選框中打勾，按提示操作即可），如下圖。是流程4中的“打開訂單”組件，orderNo參數使用的是“選擇航班并插入”組件的輸出參數。注意，此流程的“選擇航班并插入”設置了三次迭代，所以“打開訂單”也要對應三次迭代，否則會提示錯誤。         在組織數據時，可以在單個組件中設置每次迭代的數據

17、，由于組件的重用次數很多，所以這樣做還是有些麻煩。解決方法就是在外部組織好數據后，批量導入。QC默認是txt文本文件，格式可以把現有參數導出，參照它給的格式設計自己數據即可。        至此，數據層的設計也已完畢。同時也實現了測試數據和具體的業務流程相分離。        其實，這里的數據和業務層的分離并不是很徹底，不能根據自己的想法去設計，所以還有很大的改進空間，還需要進一步研究。      

18、;  通過以上幾個步驟，開發工作基本結束。以后就是需要相關的維護即可。當然，最后還是要執行測試。27執行測試        測試的執行是在“測試實驗室”中進行的。這里和操作QC執行用例很相似。也是組織目錄，拖拽相應的測試流程即可，這里也不在累述?？蓞⒁娪脩羰謨詧绦袦y試用例部分。當然執行測試可以選擇本機執行，也可以選擇在遠程機器上執行測試，但要注意要安裝相應組件和設置主機。執行效果如下圖：        QC會記錄每次執行的結果，包括流程中每個組件的執行狀態，執行時間等信息。這也是QC的強大之處，它會給出一個很人性化的結果，方便我們后續的分