業內但凡玩過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關聯的圖片信息。
另外啟動信息非要整在 Action0 這個目錄里面，這種規劃思路很不好，過度分離的結果是你維護的時候不得不關注一大堆地方。
而SilkTest呢，就是單一的腳本文件，我即使不開工具也可以直接修改。簡單即美，難道不是么？
（五）異常捕獲、場景恢復
QTP的場景設計也很復雜，又是獨立于腳本（腳本里看不到），在腳本外進行配置（類似resource），需要開發者思路很清晰的規劃它可能在什么地方出現什么錯誤、怎么處理，最糟糕的是可讀性極差，假如你在場景里面還有Function Call還得再配一個外部qfl或vbs文件，而如果引發了迭代還要在另一個Settings中做迭代設置，否則你場景恢復的時候可能莫名其妙的調起了好幾遍自己的應用。一句話，真的很坑爹，不是一般的高手搞不定它。
而SilkTest呢，開箱即用，真正的 7*24小時支持。
（六）插件支持（Add-ins）
QTP每個編程語言都需要一個插件，通過插件來識別對象。而有時候這種插件加載顯得很不靈活，比如你勾選插件進去以后居然沒法再添加，這什么易用性啊？
而SilkTest呢，不需要安裝這個那個插件。一句話：哪兒那么多麻煩啊。
（七）Web 2.0支持
QTP對于 Web 2.0 的支持，我連寫的欲望都沒有，因為實在太差了！ 什么Ajax/DHTML，什么Flex，全部都不認（或者干脆整個窗口認為ActiveX），……
可以說，QTP曾幾何時打敗 WinRunner的 關鍵就是Web 1.0 的支持超強，可如今死在了自己的最強絕學上。這也是為什么后來給了 Selenium 以可趁之機的地方！
但是 Selenium 的強項在于純HTML/JS應用，對于 Flex基本無能為力。
而反觀 SilkTest，全面支持 Ajax/DHTML，Flex/Adobe Air，全面支持 .Net 4.0，即使 Adobe公司自己也是選擇SilkTest作為它的自動化測試工具哦！
（八）參數化、數據驅動
QTP號稱自己采用 Keyword-Driven，一種在Data-Driven基礎上派生的更高級的擴展驅動理念，而事實上是QTP 直接把數據驅動的框架內嵌在自己的DataTable上，以 DataTable Object的內核結合Action迭代驅動腳本運行。這意味著號稱自己是共產主義社會，但其實在封建主義社會。這么說已經很客氣了，事實上DataTable并不好用，在實際項目中應用不多，一般往往采用外部文件（文本、csv/excel格式、數據庫、XML）做配置，擴展性比DataTable好多了。
而且坑爹的是，我還要爆料一下，QTP從誕生到現在，DataTable對象的SetNextRow 一直都有指針重置的Bug，我一般都推薦用SetCurrentRow。
而SilkTest呢，有自己的Data Driven向導，直接操作、快速完成，還支持直接從數據庫里面查詢測試數據。是不是很霸氣側漏呢？！
（九）平臺支持
QTP只能運行在 Windows上，而且對于不同Windows的兼容也有問題，比如我幾年前提及的OCR識別驗證碼技術，現在已經沒落了。
而SilkTest呢，通過SilkBean支持 Java的應用，可以在Linux平臺上回放哦！
（十）分布式、云計算
QTP本身帶有Remote Agent，可以遠程調度，但是它的商業意圖過度明顯，因為這個遠程調用是通過Quality Center/ALM來完成的，哥們你知道意味著什么嗎？意味著你要去迪拜旅游得自己買個直升機，我擦。。。
Selenium 有 Grid，而SilkTest原生支持，它通過Runtime&Agent技術實現。都明顯強過QTP！
（十一）對象庫、對象存儲
QTP可以說是成也對象庫，敗也對象庫。QTP用單獨的文件存儲對象庫，本地對象庫放在ObjectRepository.bdb文件里，共享對象庫放在 XXXX.tsr 文件里。管理起來很復雜，有些人看我介紹過高階的對象庫管理，一致都表示很暈。因為對象庫的比較、合并、參數化全部都得額外的對象庫管理器里去實現，而且實現參數化還要做映射，弄完之后滿身的汗。。。
而SilkTest呢，可以直接通過編輯器編輯，是不是灰常的爽？！
（十二）采購成本、ROI
得說“ROI（投資回報率）”的問題了。
QTP以前根據插件收費，后來整合起來銷售，美其名曰打包贈送。等于你就是先買個鐵釘，人家賣你一套家具讓你自己拔出來。
SilkTest不一樣，提供了 RunTime的 License模式，降低了采購成本，什么意思呢，就是你買的時候可以分的，看你是編寫腳本，還是只是運行腳本，等于說你買個套餐，居然還可以單點套餐里的東西——靠，這還叫套餐嗎？沒見過這么好的銷售啊，哈哈。
（十三）自動化框架
QTP的天生劣勢使得它的自動化框架部署非常困難和麻煩，這也是幾年前很多人在網上爭論不休的原因，大家都說不出一個真正被認可的很實用可以大面積推廣的成熟框架。
這點上，跟 Selenium、SilkTest 這種工具本身的設計理念就有很大差異。
試想，你把自己的工具捆綁在QC上、自己的工具上，你怎么擁抱開源？沒有開源，你自己的東西怎么集成別人的東西？沒有集成，你的自動化能叫框架嗎？這不搞笑嗎？撐死了就是個半自動化框架。
（十四）成功案例
QTP名氣相當大，國內外都是！但是真正成功實施的用戶很少，給客戶帶來的收益很低。
為什么？因為它雖然上手非常快，但是管理維護非常麻煩，沒有成熟的 framework 。比如建設銀行2007年就開始使用QTP做自動化，迄今沒有形成成熟成型的自動化測試體系，一直在通過外部程序控制QTP執行還是QC控制QTP之間徘徊。
而SilkTest呢，它的不足在于不支持 VBScript，哈哈，不夠簡單，這直接造成了門檻偏高，等于做測試的人一定、必須精通編程，而不能只是能改改腳本那么初級。但是，只要你邁過了前期這個檻，就會發現它的精妙和強大之處。它內置的設計框架，管理比QTP簡單非常多，后期收益大，試想，連 Adobe/SAP/Oracle這樣的大公司都在擁抱 SilkTest，你覺得它們都是傻瓜嗎？而 國際上有幾個巨頭在使用QTP呢？呵呵，Google用嗎？微軟用嗎？Facebook用嗎？呵呵呵……
所以啊，玩QTP其實就是一場空，你玩QTP頂多只是QTP（因為你會VBScript還是做不了JUnit/TestNG/HTMLUnit/Selenium/JMeter等測試，而你會Java以后就能做所有的測試包括SilkTest和Selenium了），用它搶搶票、灌灌水還是可以的，可是，你既然都要花那么多時間學一個工具，為什么不順便在學自動化工具的同時把編程學會了，一舉兩得，順便還拿到了高薪，對不？
好了，說了這么多，大家應該明白了吧？
有要拍磚的盡管來，但是別搞人身攻擊！呵呵呵
版權聲明：本文出自songfun 的51Testing軟件測試博客：http://www.51testing.com/?songfun
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
版權聲明：本文歡迎轉載，轉載時請務必以超鏈接形式標明文章原始出處、作者信息和本聲明，否則將追究法律責任。