下面的是IBM RATIONAL ROBOT與UT ROBOT的特性比較
ibm RATIONAL ROBOT UT ROBOT
CASE生成 全部CASE需要腳本支持 無需腳本支持
后臺應用 不支持 主要支持
開放性 較好 較好
數據驅動 支持，不太方便 采用強大的模板解析引擎，數據驅動輕而易舉
可讀性 不同的腳本編寫人員有不同的編碼風格 全部基于數據表達，清晰易懂
自然語言 不支持 支持，設計CASE的自然語言可以通過解析器識別，所見即所得
擴展性 比較困難，因為是商用產品 比較好，可根據不同的需求進行擴展
檢查點設置 優于傳統，但不太靈活 CASE產生與檢查點相分離，極低的耦合度，檢查點強大無比，維護成本低
BOSS是指為電信運營商提供的營帳支撐系統，因為移動電信的業務的特點是業務非常復雜，有成千上萬的價格計劃套餐，計費也比較復雜，后臺的支持網元有上百個，我們現在整套BOSS系統能支撐軟交換，GSM，IPTV等等多業務，現在的BOSS相關網元已經超過300個，所以接口是非常多的，因為這種特點，所以接口協議和后臺數據的測試就是主要方面
UT ROBOT的主要成績體現在我們通過ROBOT回歸的部分網元，在現場實施之后幾乎沒有再報回歸方面的遺漏問題。BUG下降了85%，因為有了這個數據說話，所以堅定了我們在這個架構上的信心
UT Robot強調的是框架，也就是可以適用在多個應用，多業務的測試中，即使不是我們公司的產品也可以應用
自動化測試需要考慮以下方面：
1.CASE執行前的環境準備：這是為了保證批量測試的時候不影響其它CASE的執行
2.CASE執行后的環境清理：這也是為了保證批量測試的時候不影響其它CASE的執行
3.結果檢查點：非常重要，這是測試準確性的根本
4.參數的組合關系：只有可以自由組合CASE，才能覆蓋各種場景 軟件測試
5.核心思想：CASE的生成，執行，結果記錄，以及回歸要分離
6.協議無關：具體完成協議發送的功能與框架想分離
7.業務無關
現在Robot已經應用到我們BOSS的部分網元的測試中，并且做到了與協議和業務無關，我們現在的效率是，一周之內就可以支持新的簡單網元的自動化測試。
舉例：對于WebService的SOAP接口測試，通過CASE的生成，執行，結果記錄，以及回歸要分離，可以實現數據庫基本的所有字段的測試�？梢栽诙虝r間內完成40個接口，超過5000個CASE的生成，生成的CASE中包括：枚舉值、邊界值、異常值、各種自定義組合的CASE，這個測試效果非常好，不僅發現了大量的功能問題，同時也發現了大量的版本變更過程中回歸業務的問題。因為ROBOT在實現功能測試的同時也要支持自動化回歸測試，當然，這是要求測試人員按照規范來寫的。
因為采用的是模板定制測試數據的方式，測試人員不需要編寫任何代碼，只需要關注業務層面，即使webservice發生了變化，也只需要進行數據的變更就可以了，同時數據的版本管理可以很好的適應不同版本的變化情況。
為了更好的說明，我把測試環境中的數據拿出來說明一下，下面是SOAPSERVER幾個CASE的返回結果，如第1個case，caseid=InsertAddress_2 從WEBSERVICE返回的值是1，可能有些人認為這個CASE就算PASS了，實際，這還遠遠不夠，我們需要關注的是數據級別的變化，因此，我們需要另外的手段去記錄所有數據庫變化的情況，一個CASE，所涉及到的結果檢查點就達到幾十甚至上百個。
說到這里，大家應該明白了，UT ROBOT的特點是將結果檢查點與CASE的回歸執行時相分離的，否則在一個CASE中同時包含了上百個結果檢查點的檢查，得寫多少腳本才能完成，維護代價得多大?
文章來源于領測軟件測試網 http://www.kjueaiud.com/
