讓QTP走下神壇--SilkTest 捲土重來

業內但凡玩過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 這個目錄裡面，這種規劃思路很不好，過度分離的結果是你維護的時候不得不關注一大堆地方。

而SilkTest呢，就是單一的指令碼檔案，我即使不開工具也可以直接修改。簡單即美，難道不是麼？

（五）異常捕獲、場景恢復

　　QTP的場景設計也很複雜，又是獨立於指令碼（指令碼里看不到），在指令碼外進行配置（類似resource），需要開發者思路很清晰的規劃它可能在什麼地方出現什麼錯誤、怎麼處理，最糟糕的是可讀性極差，假如你在場景裡面還有FunctionCall還得再配一個外部qfl或vbs檔案，而如果引發了迭代還要在另一個Settings中做迭代設定，否則你場景恢復的時候可能莫名其妙的調起了好幾遍自己的應用。一句話，真的很坑爹，不是一般的高手搞不定它。

　　而SilkTest呢，自己程式設計實現，開箱即用，真正的7*24小時支援。

　　（六）外掛支援（Add-ins）

　　QTP每個程式語言都需要一個外掛，通過外掛來識別物件。而有時候這種外掛載入顯得很不靈活，比如你勾選外掛進去以後居然沒法再新增，這什麼易用性啊？

　　而SilkTest呢，不需要安裝這個那個外掛。一句話：哪兒那麼多麻煩啊。

　　（七）Web2.0支援

　　QTP對於Web2.0的支援，我連寫的慾望都沒有，因為實在太差了！什麼Ajax/DHTML，什麼Flex，全部都不認（或者乾脆整個視窗認為ActiveX），……你真的想用是吧，好，啟用object，通過nativeobject呼叫HTMLDOM物件。那麼這樣一來就很強大了嗎？NO，NO，NO，穿上了鋼鐵俠盔甲的QTP頂多跟SeleniumRC（也就是Selenium1.0）打個平手，因為原理都是通過JavaScript注入HTMLDOM來實現的（一樣的可以採用innerHTML賦值，可以RunScript），跟WebDriver（Selenium2.0）就沒法比了。

　　可以說，QTP曾幾何時打敗WinRunner的關鍵就是Web1.0的支援超強，可如今死在了自己的最強絕學上。這也是為什麼後來給了Selenium以可趁之機的地方！

　　但是Selenium的強項在於純HTML/JS應用，對於Flex基本無能為力。

　　而反觀SilkTest，全面支援Ajax/DHTML，Flex/AdobeAir，全面支援.Net4.0，即使Adobe公司自己也是選擇SilkTest作為它的自動化測試工具哦！

　　（八）引數化、資料驅動

　　QTP號稱自己採用Keyword-Driven，一種在Data-Driven基礎上派生的更高階的擴充套件驅動理念，而事實上是QTP直接把資料驅動的框架內嵌在自己的DataTable上，以DataTableObject的核心結合Action迭代驅動指令碼執行。這意味著號稱自己是共產主義社會，但其實在封建主義社會。這麼說已經很客氣了，事實上DataTable並不好用，在實際專案中應用不多，一般往往採用外部檔案（文字、csv/excel格式、資料庫、XML）做配置，擴充套件性比DataTable好多了。

　　而且坑爹的是，我還要爆料一下，QTP從誕生到現在，DataTable物件的SetNextRow一直都有指標重置的Bug，我一般都推薦用SetCurrentRow。

　　而SilkTest呢，有自己的DataDriven嚮導，直接操作、快速完成，還支援直接從資料庫裡面查詢測試資料。是不是很霸氣側漏呢？！

　　（九）平臺支援

　　QTP只能執行在Windows上，而且對於不同Windows的相容也有問題，比如我幾年前提及的OCR識別驗證碼技術，現在已經沒落了。

　　而SilkTest呢，通過SilkBean支援Java的應用，可以在Linux平臺上回放哦！

　　（十）分散式、雲端計算

　　QTP本身帶有RemoteAgent，可以遠端排程，但是它的商業意圖過度明顯，因為這個遠端呼叫是通過QualityCenter/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吃一輩子飯的。自動化測試做到後面已經不僅僅只是工具了，還有流程、模式、管理等等一系列的配合。

有要拍磚的儘管來，但是別搞人身攻擊！呵呵呵

本文轉載自51testing軟體測試網，檢視更多：http://www.51testing.com/

[@more@]

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11323760/viewspace-1060712/，如需轉載，請註明出處，否則將追究法律責任。