自動化測試工具QTP和SilkTest橫向PK

　　業內但凡玩過QTP的，多半都知道songfun的名字，多少讀過幾篇我寫的關于QTP的文章。然而今天，作為捧紅它的一員，我決定親自推翻它，讓它從神壇走下。

　　前面博文說了QTP已死，這里要談談最近勢頭正勁的 SilkTest 。

　　眾所周知，自動化測試工具曾幾何時三足鼎立，Mercury QTP/WinRunner系、IBM RobotJ (RFT)系、Borland Segue SilkTest系，但是幾年下來，QTP在國內和國外都將同類工具遠遠甩在身后幾條街。即使后起之秀Web界翹楚Selenium也只能將超越QTP作為自己終身己任，以至于連名字上都要以 Selenium(硒) 克一下它的偶像 Mercury(汞，硒解汞毒)。

　　但是時過境遷，SilkTest 已經不再是當年的那個SilkTest，QTP也不再是當年的QTP。2013年的自動化測試工具因為QTP的裹足不前和SilkTest 的浴火重生變得有了味道。

　　好吧，一定有人要站出來說QTP現在的市場份額在國內的仍然有 60%，SilkTest還遠未成氣候，而Selenium只能進行B/S的自動化，不可能取代之……我只想說，這幾年以來QTP并無太大建樹，除了界面更加華麗，兼容性更差，更耗資源，內核未做更新，就是多了一些華而不實噱頭級別的功能特性和某幾個小功能——真的一直沒有太大變化，按照這樣的趨勢，QTP很有可能成為下一個WinRunner。

　　好吧，最近網站和論壇正在熱捧 WinRunner，好多朋友連這個名字都沒聽過，跑個題，告訴大家 曾經的WinRunner就像今天的QTP一樣統領自動化領域的武林，如果大家去看國外最大的SQAForum就會看到它的歷史回帖數在今天仍然躋進 Top 3，但是如果你去 bbs.51testing.com 的論壇看看它目前的人氣那真是令人嗟嘆，整個季度的回帖數不足10篇!

　　QTP可能會變成下一個WinRunner，作為使用了QTP 十年之久的我從感情上有些舍不得，但是必須面對的要去面對，我們應該擁抱變化。

　　好吧，閑話少說，以下橫向PK兩大商業級自動化測試工具：

　　(一)編程語言：

　　QTP一直以來都使用 VBScript. 作為自己的引擎，這在一定程度上降低了學習的成本，確實吸引了很多初學者來學習和使用QTP。

　　但 VBScript. 不是一個純粹的面向對象編程語言，除了可以封裝Class，是不能繼承和多態的。直接一點說，這樣天生缺陷使得QTP的重用性從骨子里就很差，執行效率還很低!

　　而SilkTest呢，可以支持 .Net， C#， Java， 以及它自身的 4Test，這本身就可以吸引一大批編程基礎扎實的開發人員參與到自動化的實施過程中，而它強大的面向對象基因，強大的重用性，強大的維護性(甚至可以輕而易舉進行版本管理，學過QTP的同學都知道，QTP所謂的簡單只是入門簡單，后期維護是非?？植赖?，極高的開發效率更是遠超QTP。

　　(二)檢查點(Checkpoint)

　　QTP的檢查點一向不倫不類，好像基于對象庫(因為是在對象庫中才能看屬性)，又好像脫離于對象庫(因為不是所有的檢查點都可以進行對象模式的維護管理，而Checkpoints和Test Objects是并列節點不是歸屬關系)，這在開發過程中被很多朋友直接拋棄，改用其他手段做驗證(比如經典的 GetRoProperty)。

　　而SilkTest呢，直接通過代碼秀出自己要檢查的對象的屬性等信息，簡單易懂不說，維護方便很多——畢竟，難道你喜歡一邊在Expert View里編程一邊在對象庫里看對象嗎?累不累啊?

　　(三)“錄制/回放”

　　QTP的錄制分為：標準錄制模式、低級別錄制模式(WinObject對象模式)、模擬錄制模式(模擬鼠標運動軌跡)。在視圖上采用了業務專家(SME)的 Keyword View和編程人員的 Expert View。

　　總體來說還算不錯，除了專家視圖模式下的編程功能太坑爹。

　　而SilkTest呢，有 SilkWorkBench、Silk4J、Silk4Net、SilkClassic等一堆的IDE，支持VB.Net、C#、Java等IDE，真的覺得假如你是團隊化開發自動化測試腳本的話，SilkTest的優勢要比 QTP明顯很多。

　　(四)腳本

　　QTP的腳本我一直不喜歡，因為不是純文本。它在創建工程的時候(QTP中的工程叫Test，而不叫 Project)，會生成一堆的資源文件，比如ObjectRepository.bdb、Resource.mtr，還有截圖目錄SnpaShots目錄，而腳本代碼放在 Script.mts 中，還偏偏在代碼行后附著了 Active Screen關聯的圖片信息。這樣導致的直接結果就是版本管理工具沒法進行代碼的沖突管理，比如merge操作。

　　另外啟動信息非要整在 Action0 這個目錄里面，這種規劃思路很不好，過度分離的結果是你維護的時候不得不關注一大堆地方。

原文轉自：http://www.uml.org.cn/Test/201405212.asp