多款自動化工具的橫向比較 (UFT、RFT和CukeTest)
自動化測試作為非常專業的市場，不光對自動化測試的工程師技術要求很高，而且在工具選擇也非常關鍵。很多公司的軟體在以手動測試為主轉換到更多應用自動化測試的過程中，一大困惑是如何選擇自動化測試產品。工具產品的選擇不僅決定著今後測試質量和自動化測試的開發效率。而且影響到技術人員的招聘，運營成本等多種因素。
僅從成本角度考慮，開源軟體沒有工具軟體的購置成本，但是開源工具的整合和測試框架的搭建需要耗費大量人力。另外，疑難問題如果沒有廠商支援，會影響專案進度，也會導致大量的支出。如果從總擁有成本角度考慮(TCO)，未必是最優的。
為幫助各位根據自己的實際情況選擇合適的工具，本文選取了自動化測試的幾款典型的工具，從工具軟體的各個方面進行比較。方便各位在選擇工具的時候做有效的決策。UFT，RFT是老牌的自動化測試工具、生態相對封閉。CukeTest是開源軟體Cucumber演變而來的軟體，在開源社群被廣泛的採用。
| 特性 | 惠普 Unified Function Testing | IBM Rational Functional Tester | 聆播科技CukeTest |
| 指令碼管理 | 指令碼檔案的方式管理指令碼，後期維護困難，複用率很低。目前不少廠商開發了UFT的指令碼管理工具，但無法脫離指令碼檔案的基礎，很難有質的改變。 | 分散管理指令碼，使用者在使用時需到相應使用者處查詢指令碼，查詢到指令碼後才能夠呼叫，無形增加了工作量。分散管理模式不能實現指令碼實時更新，不能實現實時共享，導致指令碼的複用率較低。 | 指令碼管理採用先進的行為驅動(BDD)方式，基於測試場景管理測試用例。測試步驟與程式碼相關聯。指令碼易於維護。因為基於自然語言編寫測試場景，有很強的可讀性，非測試開發也可審閱和貢獻測試用例。 |
| 易用性 |
工具的圖形化操作功能比較簡單；指令碼編寫比較簡單；可以通過簡單的描述性程式設計實現手動識別物件。 |
工具的圖形化操作功能比較簡單；指令碼編寫比較難；通過find方法實現手動識別物件，使用難席比較大點。 |
用例開發部分採用視覺化模式和文字模式兩種方式，根據需要切換。程式碼部分使用流行的指令碼編輯器。可從用例跳轉到程式碼，或從程式碼轉到用例文字。 |
| 使用配置 | 需要安裝一系列工具，並配置licence。 | RFT安裝複雜，配置步驟多。 | 多平臺開發支援，包括MacOS、Windows等，開發的指令碼還可在Linux上執行。從免費版開始，一定用量需安裝License。 |
| 指令碼語言 | VBS | Java、VB.NET | JavaScript，Node.js |
|
支援應用 |
預設支援windows控制元件，VB，和ActiveX；可以加外掛來支援其他常用的應用程式。不過外掛都是要單買的，價格很高。 |
預設支援大部分常用的應用程式。其他應用程式可以通過載入相應的識別Jar包進行識別，可惜，這些Jar包沒有現成的。 |
支援各類應用包括Windows、移動端、Web、API等。移動端、Web、API等開發時需引入免費的開源庫，無需額外成本。Windows應用測試可跟本公司另一產品LeanRunner結合使用。 |
| 錄製指令碼 |
支援圖形化的操作錄製指令碼；支援圖形化的操作新增驗證點；支援圖形化的操作應用正則表示式。 |
支援圖形化的操作錄製指令碼；支援圖形化的操作新增驗證點；支援圖形化的操作應用正則表示式。 |
不提供錄製，Web採用開源方案的物件識別，有豐富的公開文件，簡單培訓即可瞭解。Windows支援物件識別，新增到物件管理庫後再自動生成物件呼叫程式碼。 |
| 引數化 |
支援圖形化的資料表格式資料操作；使用的是Excel檔案來作為測試資料儲存介質；可以直接開啟Excel資料檔案修改資料； |
支援指引數化資料；支援圖形化的資料表格式資料操作；使用的是Xml格式檔案來儲存測試資料；Xml測試資料只支援在RFT軟體中使用格式化方式顯示和修改；Xml測試資料使用標準的資料格式，通用性更好。 |
支援引數化。內建了行為驅動引數化功能。支援資料驅動，資料表可從外部匯入，或將測試用例中已有的資料匯出到Excel。 |
|
測試資料 載入 |
測試資料載入簡單，使用內建函式能方便實現。 | 可以用封裝的方法來動態載入資料，不過比較複雜，而且還得修改指令碼中引數化的地方。 | 提供載入資料表的API。 |
|
物件識別 能力 |
有內建識別的比較標準的控制元件識別強；組合的控制元件識別較弱；預設支援dom，可以直接操作。 |
有內建識別的比較標準的控制元件識別強；自定義的控制元件識別較弱；可以自定義非標準控制元件的識別；當然，通過Jar包的載入，理論上可以操作任何想操作的物件 |
物件識別使用了開源庫Selenium的功能。是廣泛使用的成熟方案，支援多種識別方式，包括Id，css, linkText, name, className, xPath等多種方式。 |
|
手動新增 物件 |
提供樹形的物件選取方式，可以選擇當前節點，也可以選擇父節點或子節點，使用挺方便。 |
提供節點直接選擇和物件遍歷選擇，不大實用。首先，節點直接選擇不能選擇父節點或子節點，很多情況是直接選擇不到要選的節點的；其次，遍歷節點更是不可能，因為頁面經常一遍歷就有好幾百個物件，很是不好找。 |
手動新增物件是基於流行的Selenium的物件新增，市場上有眾多的技術人員瞭解這些新增物件的方式，也有非常多的免費培訓講解。 |
| 指令碼編輯 |
提供步驟編輯介面，方便不會不會程式設計的人員使用；指令碼編輯器的功能比較弱。 |
只有指令碼編輯器，沒有步驟編輯器；指令碼編輯器的功能比較強，跟操作Eclipse差不太多。 |
整合流行的vscode引擎，類似vscode的指令碼編輯器，提供智慧提示 |
| 指令碼除錯 |
HP為QTP加入了VBS除錯功能；除錯功能比較弱。 |
直接使用Eclipse除錯Java的強大功能。 | JavaScript的除錯方式，無需編譯。另有多種按照場景的除錯方式。因為是JavaScript語言，前端工程師也可參與開發除錯。 |
| 回放速度 | 速度比較快。 | 速度一般。 | 採用Node.js引擎，和成熟的Selenium庫，速度較快。 |
| 結果報告 |
樹形顯示各個步驟的執行情況。可以在程式碼中向報告寫內容。 |
提供多種形式的結果顯示。可以在程式碼中向報告寫內容。 |
提供多種型別的html報告，其中有按照場景的彙總資料，以及每個場景步驟的詳細資料。每個場景詳細內容可以新增截圖或自定製資料。可以匯出到PDF，另提供json報表資料，方便自定製。執行時可以自動錄製視訊。 |
| 擴充套件性 | 外掛擴充套件，外掛都由UFT廠商提供 | 有Jar包，幾乎就可以擴充套件。 | 能夠與多種開源的自動化庫相結合使用，擴充套件自動化功能。因為基於流行的Node.js技術，Github上有眾多數量的JavaScript庫擴充套件功能。 |
| 整合性 |
提供了與其他程式結合的介面，對C#、VB和VBS結合性比較好。可以通過C#、VB和VBS等編寫程式方便的呼叫和操作UFT。 |
提供了編寫用例指令碼的API，但產品本身功能不易擴充套件 | 提供多種型別html報表，json報表資料，方便自定製報表，有Jenkins外掛支援，可在Jenkins中輕鬆實現持續整合 |
| 安全性 | 架構較封閉，不支援提供原始碼，安全性無法評估 | 架構較封閉，不支援提供原始碼，安全性無法評估 | 基於開源實現，提供執行引擎及自動化庫原始碼，便於自主可控 |
| 價格 | 昂貴 | 較貴 | 一般 |
| 總結 | 功能全面，價格昂貴，自動化測試指令碼生成較快，但對需求的頻繁變化自適應能力差，重新錄製的風險較大，指令碼維護困難，迴歸持續100%通過率較低。在國內的市場佔有率有逐年下降的趨勢。 | RFT 的驗證結構的功能比較強大，通過對 TestObject 的獲取和使用，可以對 Eclipse 中的很多的 SWT/JFace 圖形物件提供支援，而且也可以支援很多的驗證種類；其次，它直觀、易於理解。但RFT驗證 API 的使用繁瑣、可重用性低；也沒有區分各個具體物件型別的差異，造成驗證形式比較單一，從而不利於使用者進行擴充套件操作；用例執行失敗定位不方便，自動生成的指令碼維護較困難。 | 價效比較高，可擴充套件性強。產品支援Web、介面、Android、IOS、Windows、Qt等。行為驅動讓指令碼維護更為方便。開發的指令碼基於開源引擎執行，避免了供應商繫結。靈活開放能引入眾多的開源庫和解決方案，易擴充套件。 |
各軟體在支援的語言、指令碼開發、自動化技術、可擴充套件性、報告方面各有強項。相信大家在進行綜合的比較後。對這幾款工具有了初步的瞭解。在開源軟體盛行的今天，由單一廠商提供大而全且價格昂貴的產品已不再是潮流，反之，支援開源、開放、提升價值是軟體產品的新的趨勢。
因為篇幅關係，本文只比較了幾款主流工具，如果要參考其它工具，也可填寫類似的表格做詳細的比較分析。