Mercury 在 Quality Center 8.0 时就推出 Business Process Testing，到现在已经进步到 9.0 的版本了。为什么 Mercury 发展出 Business Process Testing 呢？Business Process Testing 的好处在哪？要如何使用Business Process Testing？我将在以下的文章为大家做个介紹。

 

传动自动化测试的限制

 

軟體的自動化測試在過去一段時間中有長足的進步。每個世代的產品都成功解決了某些重要的挑戰，但是同時也引進了不同的問題等待解決。

 

第一代的自動化測試大概在15年前開始，透過硬體的方式錄製鍵盤的輸入並播放，但缺少檢查點（checkpoint）的功能，而且測試腳本很難維護。

 

第二代的自動化測試則大約在10年前開始的，這時已經由硬體轉變成透過軟體錄製/播放（capture/playback）的方式產生測試腳本（script），並且也增加了檢查點的功能，可以對軟體做驗證，測試的範圍也比硬體方式的自動化方式大了許多。比較大的問題是測試腳本也是一種程式語言，所以測試人員也需要懂程式語言，換句話說就是要會寫程式。而且當軟體有變動時，測試腳本也需要同步更新，這對測試人員來說是一大挑戰，測試人員常常就是整個測試腳本再重新錄製一遍。

 

以下為Mercury WinRunner測試腳本的範例

 

 

在2001年開始了第三代的自動化測試稱為「測試框架（test framework）」，主要是把測試腳本給抽象化（abstraction）（註：如Keyword-Driven Test），讓非技術人員（如系統分析師、使用者等）即使不懂測試腳本，不會寫程式的情況下，也可以使用自動化測試工具建立自動化測試個案。

 

舉個 Mercury QuickTest Professional Keyword-Driven Test的測試腳本為例子，測試人員不管是錄製、編輯或是看到的測試腳本都是以「click the “OK” button」這樣的關鍵字所呈現的。

 

「測試框架」確實是增加了測試團隊的生產力，但是還是有些缺點：

n           以Keyword方式建立的測試腳本還是在測試步驟的層次，當設計一個複雜的商業流程測試個案可能還是需要大量的Keyword。對測試人員而言還是需要耗費大量的時間。

n           「測試框架」對於測試人員而言，只是測試腳本長得不再像是程式原始碼，而像是在Excel中填入Keyword罷了，其實還是在寫測試腳本。

n           支援「測試框架」的自動化測試工具通常與之前的測試工具做法不同，例如不提供錄製的功能，而限制了其彈性。再者，測試人員在使用這類工具時也常常不知其所以然，在不瞭解內部的運作下，很難對Keyword做客製化。

n           「測試框架」即使已經被抽象化了，但是其層次還是停留在「步驟」的層次，尚未提升到「業務流程」的層次，迫使測試人員在建立測試腳本時，還是需要以「程式人員」的思考方式建立測試腳本，而不是以「業務人員」的角度來建立測試腳本。

n           「測試框架」的測試腳本沒有與測試文件建立關聯性，測試人員還是需要花費大量的工時在建立與維護測試文件的工作上。

 

從上面的問題，可以看出「測試框架」這樣的方式，對於具備技術背景的測試人員也許還 OK，但是對沒有技術背景的測試人員如（業務人員或是使用者），還是有其使用上的困難。

 

Mercury Business Process Testing – 是一種轉變而非一種新技術

 

Mercury很快地意識到這些挑戰，並非只有單單改進第三代自動化測試工具就能解決，需要的是一個全新的方式。所以從測試腳本的設計、自動化、維護以及文件化做一個全面且根本的進化，進而發展出第四代的自動化測試工具「Mercury Business Process Testing」 。

 

相較於Keyword-Driven Testing，Business Process Testing的抽象化層次更高，到達了「業務流程」的層次。

 

以下的例子可以看出一個有登入動作的測試個案，使用Keyword-Driven Testing的方式，至少需要4個步驟：開啟應用程式登入視窗、輸入帳號、輸入密碼、按下OK按鈕來完成登入的動作。但是以Business Process Testing的方式，登入的動作就成為一個可以接受以帳號、密碼為參數而且可以重複使用的業務流程元件。

 

 

 

Business Process Testing的優點

 

使用Business Process Testing的自動化測試主要有以下的優點：

n           透過非技術性、元件化、以業務流程層次的方式設計測試個案，讓業務人員以及一般使用者也可以參與自動化測試的工作。

n           業務元件可以被不同的測試個案所使用，加快建立自動化測試腳本的時間，並降低維護的成本。

n           建立或維護測試腳本時也會同時更新測試個案文件，大大縮短維護測試文件的時間。

 

 

如何Mercury Business Process Testing

 

Business Process Testing需要Mercury Quality Center與QuickTest Professional配合才能運作。同時測試團隊中也需要二種角色，一是熟悉QuickTest Professional測試工具的人員（Automation Engineer），負責建立並維護Application Area、物件庫（object repository）、library files、recovery scenarios，另外也需要負責對Business Component進行除錯的工作；另一是非常熟悉業務流程的人員（Subject Matter Expert），透過Quality Center介面，設計Business Component以及Business Process Test並運用Application Area將其自動化。

 

使用Business Process Test的流程如下：

 

 

建立Business Component

 

首先建立一個名為Login的Business Component，並且填入相關資訊，如Summary、Pre-Condition、Post-Condition，讓想要使用此Business Component的人員知道其目的、用途以及使用條件與限制。

 

 

輸入測試步驟

 

點選上方的Design Steps，開始輸入測試步驟，含Step Name、Description、Expected Result。

 

點選New Step將其餘的測試步驟也一併輸入，最後可以看到此Busniess Component的執行步驟如下。

 

 

建立Business Process Test

 

點選Mercury Quality Center的Test Plan，建立一個名為「預定機位」的Business Process Test。

 

輸入此測試個案的描述。

 

將Business Component加入Business Process Test中

 

在Test Script點選Select Component，將剛剛建立的Busniess Component依序以滑鼠拖拉到中間的區塊。此Business Process Test由Login、Create Order、Update Order、Logout 4個Business Component所組成。

 

將Business Component自動化

 

再回到Business Components將其轉成自動化測試腳本，在Design Steps點選QuickTest Keyword-Driven，將此Business Components轉成QuickTest Keyword-Driven類型的測試腳本。Business Components支援三種類型的腳本：QuickTest Keyword-Driven、QuickTest Scripted、WinRunner。

 

轉成QuickTest Keyword-Driven腳本後，點選Automation就可以看到其Keyword-Driven的腳本，目前都還是ManualStep。

 

選擇Application Area。這個Application Area內含測試物件（Test Object）、Keyword steps、函式庫等等。

 

將Keyword-Driven步驟加入Business Component中

 

直接在Keyword View上透過選取Item、Operation、輸入Value的方式建立Keyword-Driven腳本。

第一個步驟為執行Flight Reservation程式，在Item欄位就不是選取Test Object，而是選取Operation，然後在Operation欄位選擇OpenApp表示此步驟是要執行一個程式，同時在Value欄位輸入這個程式的路徑，這樣第一個步驟就完成了。

在Item選取Login Diaglog的Test Object，然後在Operation選取Activate，表示此步驟為開啟登入視窗，Value欄位則不需要輸入任何值。

 

選取AgentName的EditBox，Operation則是Set，表示要在Agent Name這個EditBox輸入資料，至於要輸入什麼資料就直接輸入在Value欄位中。

 

 

在Value欄位輸入mercury。

 

以相同的方式加入其他的步驟，完成後整個Business Component的執行腳本如下。

 

也同步更新了Business Component的Design Steps（可惜不是中文）。

 

連登入視窗的畫面也加進去方便要使用Busniess Component的測試人員更容易瞭解此元件的操作畫面。

 

到此這個Login的Business Component已經完成，而且可以被其他的Business Process Test使用了。

 

Business Component除錯

 

當完成Business Component的自動畫腳本後，通常會試著執行看看此Business Component是否可以順利執行，假如執行有任何問題則可以進行除錯，看看是不是Test Object選錯了還是Value值給錯了。

 

參數化

 

由於Business Component可以被其他的Business Process Test重複使用，所以通常也會將輸入資料設定為參數的方式來輸入。例如Login可以設定其接受帳號與密碼二個參數，而且在使用時，可以輸入多組的帳號密碼，然後當執行不同的Iteration時就會使用不同的帳號密碼作登入的動作。以下畫面在設定Login Component在此Business Process Test所使用的帳號密碼參數值。

 

在Test Script的Input出現了剛剛輸入的參數值。

 

執行Business Process Test

 

最後就可以執行Business Process Test並且檢視測試結果了。

 

以上是Mercury Business Process Testing的使用方法。