分类：
2008-10-15 16:44:19
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的抽象化層次更高，到達了「業務流程」的層次。
[1]
