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

轉自:http://www.uml.org.cn/Test/201405212.asp?artid=1686

  衆所周知，自動化測試工具曾幾什麼時候三足鼎立，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 這個目錄裏面，這種規劃思路很很差，過分分離的結果是你維護的時候不得不關注一大堆地方。

而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），……你真的想用是吧，好，激活object，經過 native object調用HTML DOM對象。那麼這樣一來就很強大了嗎？NO，NO，NO，穿上了鋼鐵俠盔甲的QTP頂多跟 Selenium RC（也就是Selenium 1.0）打個平手，由於原理都是經過 JavaScript注入HTML DOM來實現的（同樣的能夠採用innerHTML賦值，能夠RunScript），跟WebDriver（Selenium 2.0）就無法比了。

能夠說，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了），用它搶搶票、灌灌水仍是能夠的，但是，你既然都要花那麼多時間學一個工具，爲何不順便在學自動化工具 的同時把編程學會了，一箭雙鵰，順便還拿到了高薪，對不？

好了，說了這麼多，你們以爲要不要讓QTP走下神壇呢？

固然，我並非讓你們停下本身手中的QTP項目，特別是大家團隊若是已經作的比較成熟，這時候就暫時沒有必要更換其餘工具。可是，要作到心中有數，你不可能靠QTP吃一生飯的。自動化測試作到後面已經不只僅只是工具了，還有流程、模式、管理等等一系列的配合。