做功能自動化測試都會不約而同的遇到一個比較棘手的問題－測試框架的搭建。這也是直接影響功能自動化測試成功與否的關鍵。框架做的好可以使測試事半功倍，反之輕則很難看到工作的成果重則會使整個測試失敗。目前網上有很多關於測試框架的討論，其中也有成型的測試框架，其中有很多好的思想在裏邊，很值得借鑑。但今天要討論的不是網上已有的，而是HP已經爲我們設計好的一個測試體系，業務組件測試。他是利用QTP與QC的完美結合組成的一個體系架構。它可以輕易實現目前比較流行的三層測試架構：腳本層，業務層，數據層相分離，爲開展功能自動化測試提供一個高效、穩定、容易的測試實現。
一．概述
1．1業務組件（Bussiness ProcessTesting）簡介
業務組件是組成流程測試的基本單元，組合不同的業務組件可以實現不同的業務流程測試。如將fligt系統的登錄最爲一個組件，選擇航班最爲一個組件等。這樣可以實現組件的複用，提高開發效率。
1．2 Bussiness Process Testing的優點
1） 相關業務人員可以在沒有腳本的環境下組合業務組件，實現業務流程。
2） 對業務人員的編程能力沒有要求，業務人員只需瞭解系統的業務流程，不用關心具體的腳本實現。這一點也實現了業務層和腳本層的分離。
3） 一旦某個組件開發完畢，即可在不同的流程中使用該組件，實現高可複用性，從而加快業務流程測試的速度。
4） 明確的角色分工，業務人員負責流程的開發、組織；QTP工程師負責腳本的開發、維護以及相應函數庫的開發、維護。
5） 因爲實現了腳本的複用，提高了自動化開發的效率，無形中就降低了測試過程中維護的時間和成本。
1．3 Bussiness Process Testing的簡易流程
如圖所示，整個過程分爲2條線：第一個是由業務測試人員劃分組件並組合不同的組件實現不同的流程測試；其次QTP專家負責組件的腳本具體實現並負責調試成功，上傳到QC供業務測試人員調用。
注：測試數據的組織後邊介紹，以便實現三層的測試架構；此過程需要QC有Bussiness Process Testing組件許可的支持，也就是需要單獨向HP購買。
下邊以QTP自帶的示例程序演示整個流程的開發過程
2．1劃分組件
本次將系統劃分爲：登錄；選擇航班並插入；打開訂單；更新訂單；刪除訂單；註銷。這樣劃分僅爲演示之用，不用在實際的測試之中。
2．2組織業務測試流程
本次只是用於演示，所以流程不會100％覆蓋，在實際的測試過程中要達到100％的流程覆蓋。本次測試流程如下：
流程1：登錄－選擇航班並插入－註銷
流程2：登錄－選擇航班並插入－更新訂單－註銷
流程3：登錄－選擇航班並插入－更新訂單－刪除訂單－註銷
流程4：登錄－打開訂單－更新訂單－刪除訂單－註銷
下邊需要根據劃分的組件來實現組件腳本的實現。
2．3創建應用程序區域
在開發腳本之前首先要做的是要創建一個應用程序區域。應用程序區域提供創建業務組件所需的所有資源和設置，每個業務組建都居於一個應用程序區域，並從這些應用程序區域集成這些資源和設置。在此創建一個名爲“訂票系統流程測試”的區域，如圖所示。
創建過程:依次選擇:file－New－Function library。保存後自動上傳至QC默認目錄。
在此也可以加載自己的函數庫，對象庫，恢復場景等，這樣以後創建的組建都可以共享該應用程序區域的資源。同時也方便維護，這也是一個優點所在，例如一旦函數庫改變在此從新加載新的函數庫即可，不用在腳本理修改。總之這個應用程序區域很重要，以後所有的腳本均是基於這個區域。應用程序路徑一定要加載正確，否則錄製時不能生成腳本。
2．4創建腳本
在創建腳本之前最好在QC中組織好目錄樹，方便保存及調用。關於腳本的開發過程，每個人、每個公司都有自己的方法。在此源代碼也沒法一一貼出。所以在此只列出輸入參數和輸出參數，方便後邊的參數化以及數據組織。本次也採用最通用的方式即對象庫解決對象識別問題。腳本的開發規範以及參數命名也以我自己慣用方式。
注：“－”爲無相應參數。
在QTP中創建組件腳本有2中模式：Bussiness Component和Scripted Component。區別：Bussiness Component只能見關鍵字視圖，QC中亦可見關鍵字視圖；Scripted Component可以看見專家視圖，在QC中腳本代碼不可見。一般創建後者，本次也是採用後者，方便編輯腳本，控制腳本結構。
注意：參數一定要合理設置並對代碼中的輸入項做參數化與參數關聯，否則測試數據傳不到腳本，導致腳本運行失敗。參數可以在QTP中創建，也可以在QC中創建，效果等同。
腳本開發完保存至QC，如圖:
至此腳本開發完畢。也實現了腳本和業務層、數據層的脫離，現在單個組件腳本實現業務流程中的某一個功能且腳本中不會涉及具體的測試數據，從而爲實現三層結構打下基礎。接下來的工作就是在QC中組織需要測試的業務流程以及需要的測試數據。
這裏有一個需要注意的地方，就是在QTP創建腳本如果選擇Bussiness Component類型，在“設計步驟”選項卡可以看到QTP中的關鍵字視圖，相關人員可以像在QTP操作一樣，但是看不到代碼。這也是爲何上邊爲何創建腳本組件的原因。
2．5業務流程的組織
業務流程的組織主要是在“測試計劃”模塊中實現。這的主要工作是由業務測試人員完成。規劃好目錄結構以後，根據需要測試的業務流程拖拽需要的組件即可。這一步和在“測試計劃”中拖拽測試用例很相似，區別就是這個是組合業務流程，而且可以自動執行。組織好後的效果如圖：
需要注意的是，創建用例是請選擇“BUSINESS-PROCESS”測試類型，否則組件腳本拖拽不過來。拖拽腳本是在“測試腳本”選項卡中進行，如上圖。限於篇幅，在此創建目錄和拖拽等動作不再詳述，請參見QC的用戶手冊。另外，根據實際的系統，可以把組件分組，以組的形式控制流程。例如，選擇如圖的2到4的組件，然後選擇工具欄叉號旁邊的圖標，即可把組件分成一組。這樣可以更好的控制流程。
至此，所有的業務流程均以實現。可以在QC中選擇運行（綠色箭頭），進行相關的調試。
這裏實現的是三層結構中的業務層。這裏進行的業務流程組織和腳本沒有任何關係，相關人員不用關心腳本如何實現，只要保證所有的流程均已覆蓋即可。
接下來就是要實現數據層的工作了，從而實現三層的測試架構。
2．6測試數據的組織
測試數據的組織也是在“測試計劃”模塊中實現。選擇某一個流程，在“測試腳本”選項卡中右擊要設計數據的組件，在彈出窗口中選擇“迭代”，彈出組件迭代設置窗口，如圖：
在此可以根據測試需求設置組件要迭代的次數，以及每次迭代的參數值。如上圖，設置了3次迭代每次迭代輸入的訂單信息均不相同。同時可以設置輸入參數選擇上一個組件的輸出參數（在複選框中打勾，按提示操作即可），如下圖。是流程4中的“打開訂單”組件，orderNo參數使用的是“選擇航班並插入”組件的輸出參數。注意，此流程的“選擇航班並插入”設置了三次迭代，所以“打開訂單”也要對應三次迭代，否則會提示錯誤。
在組織數據時，可以在單個組件中設置每次迭代的數據，由於組件的重用次數很多，所以這樣做還是有些麻煩。解決方法就是在外部組織好數據後，批量導入。QC默認是txt文本文件，格式可以把現有參數導出，參照它給的格式設計自己數據即可。
至此，數據層的設計也已完畢。同時也實現了測試數據和具體的業務流程相分離。
其實，這裏的數據和業務層的分離並不是很徹底，不能根據自己的想法去設計，所以還有很大的改進空間，還需要進一步研究。
通過以上幾個步驟，開發工作基本結束。以後就是需要相關的維護即可。當然，最後還是要執行測試。
2．7執行測試
測試的執行是在“測試實驗室”中進行的。這裏和操作QC執行用例很相似。也是組織目錄，拖拽相應的測試流程即可，這裏也不在累述。可參見用戶手冊執行測試用例部分。當然執行測試可以選擇本機執行，也可以選擇在遠程機器上執行測試，但要注意要安裝相應組件和設置主機。執行效果如下圖：
QC會記錄每次執行的結果，包括流程中每個組件的執行狀態，執行時間等信息。這也是QC的強大之處，它會給出一個很人性化的結果，方便我們後續的分析工作，以及對系統給出一個量化的指標。這一點QC做的相當完善，從需求開始到最後的缺陷分析以及測試報告，都會有一個圖形的界面供我們參考，這對我們寫測試報告提供了極大的方便，給我們提供了強有力的，可靠的數據支持。
注：以上全部工作在WinXP（sp3）＋QTP9.5＋QC9.0環境下完成。
三．總結
本文只是針對業務組件測試給出了一個簡單敘述，QTP以及QC的強大之處遠不及這些。對於QTP和QC的其他功能本文沒有提及，其他功能在自動化測試中起到的作用，是有些工具不能代替的，也許這也是現在很多公司、很多人都在學習、使用的原因之一吧！前一段時間51的調查文件就是一個很好的證明，HP（Mercury）的所有產品都是遙遙領先其他工具。當然有很多公司也有自己的測試框架，也有自己開發的測試工具。但不可否認QTP確實是一個很好的測試工具，雖然它很貴。
需要提到的是，QTP和QC是一個開放式的架構，HP（也就是以前的MERCURY）爲我們提供了很多接口，我們完全可以利用這些接口開發出自己的框架，實現三層乃至更高的框架結構。這些接口以及函數說明都能在QTP的幫助文檔中找到。
最後希望國內的測試發展越來越好，中國的軟件越做越好。