為了實現全面自動化測試的目標，IBM 推出了Rational Test Workbench（簡稱 RTW）統一測試工具集，包 括自動化功能測試，性能測試，接口集成測試，手機移動 App 自動化測試以及服務虛擬化等模塊，滿足客戶 多種類型的自動化測試需求。我們將通過系列文章，結合具體的應用，和大家一起分析如何使用 RTW 完成手 機自動化測試，接口集成測試，以及通過服務虛擬化實現測試環境的仿真，從而展示 RTW 全面的自動化測試 能力，方便大家了解 RTW 並在您的實際工作中應用 RTW。
前言
隨著軟件技術的發展和軟件不 斷應用 , 我們的生活 , 日常工作也無時不刻被軟件所影響和改變。
出門打車，有"嘀嘀打車 "來叫車，上車後手機可以收發郵件處理工作，間或看看 Weibo，用微信給朋友發個消息。哦，接到老板 電話，要出差了 ? 好的，打開手機上的國航 App, 預訂機票，信用卡支付，然後預占位置。
這些軟件 系統帶給用戶方便，而為了保證這些系統的功能穩定，高效運行，眾多的 IT 信息中心和軟件研發企業也面臨 著更大的挑戰。
一個大的企業，往往有多個軟件系統，這些系統協同工作才可以保證企業的日常工作 和運行；而系統之間的關聯性，耦合性越來越強；很多時候，一個貌似簡單的業務應用，後面往往貫穿了多個 不同的軟件系統，如手機預訂機票，會訪問機票預訂系統，銀行卡 / 信用卡支付系統，航空公司常旅客管理 系統等。
傳統的軟件測試，更多集中在 GUI 界面的功能測試和性能測試，往往是"重測試，輕定 位"。在測試這類分布式復雜應用系統時，如果按照傳統基於圖形用戶界面的方式來測試，往往難以找出 系統問題的根本原因。這類系統"簡單"的用戶操作界面下面往往是復雜的子系統、業務模塊的調用 ，任何一個環節（接口通信）出現了問題都會導致測試失敗。
圖 1. GUI 界面只是冰山一角，業務由 多個系統共同實現
如上圖，"冰山"上的 GUI 界面的一個輸入請求的輸出出現了錯誤，這個錯誤是"冰山"下多個服務交互的反應，這些服務 可能來自於不同的子系統，我們必須對這些服務的接口進行測試，才能定位出問題的根源。
這就需要 超越界面測試，更深入到後台的接口測試，把不同接口測試的測試用例整合在一起，並和傳統的功能測試，性 能測試結合，共同實現全面的自動化回歸測試。同時，由於越來越多的應用是基於手機客戶端的，我們的測試 工作也必須把針對手機 App 的自動化測試納入重點。
也正是為了實現全面自動化測試的目標， IBM 推出了 Rational Test Workbench （簡稱 RTW) 統一測試工具集，包括自動化功能測試，性能測試，接口集 成測試，手機移動 App 自動化測試以及服務虛擬化等模塊，滿足客戶多種類型的自動化測試需求。我們將通 過系列文章，結合具體的應用，和大家一起分析如何使用 RTW 完成手機自動化測試，接口集成測試，以及通 過服務虛擬化實現測試環境的仿真，從而展示 RTW 全面的自動化測試能力，方便大家了解 RTW 並在您的實際 工作中應用 RTW。
企業應用體系架構發展趨勢
計算機技術發展到今天，越來越多的客戶開始采 用基於 SOA 的分布式體系架構來構建關鍵企業應用，無論是對舊有信息系統的改造，還是對企業新 IT 架構 的設計，分布式、面向服務的體系結構都往往成為了首選的方案。
這種流行的趨勢其實是若干因素共 同促進的結果。一方面，歷經多年軟件工程發展所積累的經驗、方法和各種架構模式，比如 OO/MDD/MDA，需 要新的想法來促進更加快捷的工程組織模式，以應對飛速發展變化的商業模式；另一方面，互聯網的多年發展 帶來了前所未有的分布式系統的交互能力，這成為了實施進一步標准化需求的基礎。
圖 2. 復雜的 SOA 系統
SOA 架構提高了企業對系統的復用 程度，以一種松耦合的方式將不同的系統聯系到一起，用戶會以 PC 聯入系統，也可能以移動設備（如智能手 機或 Pad）聯入系統，這類系統的特性在於：
系統間基於"消息"進行通信。消息格式復雜多樣，包括 HTTP、XML、SOAP、File、JSON、REST 、二進制、JMS、Base64 等。針對特定的行業還會有 HL7、FIX、SWIFT 等。
體系結構復雜，采用多種技術。如 Web Service、FTP、SCA、SDO、BPEL、ESB、BPM、消息中間件等。
系統間依賴關系復雜，接口眾多，難以關聯和調試。
傳統意義上，測試人員通常會基於開發好的 PC 用戶界面做功能測試和性能測試，並使用自動化測試工具 進行相應的自動化測試。但是許多項目組發現，針對 SOA 開發使他們比較頭疼的是集成測試，因為在集成測 試時候會出現大量缺陷。為什麼會有這種情況？我們來看一下 SOA 系統集成測試帶來的新問題。
集成 測試的困惑
集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求組 裝成子系統或系統，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但並不能保證連接起來也能正 常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現。而針對 SOA 和 分布式復雜應用系統的集成測試，往往會碰到如下的一些困惑：
無圖形用戶界面
與傳統的基於 GUI 的測試方式不同，SOA 類系統的測試主要是圍繞著系統底層各個組件和模塊之間的接口來進行的，通過消 息的 Schema 來判定接口之間的通信是否正確。這些接口通常沒有圖形用戶界面，無法采用傳統的基於圖形用 戶界面的錄制方式來進行測試。
消息格式復雜，缺乏統一的測試手段
如圖一所述，分布式復雜 應用系統的各個模塊之間通信和消息格式復雜多樣，常見的包括 HTTP、XML、SOAP、File、JSON、REST、二進 制、JMS、Base64 等。這就要求測試人員必須要熟悉系統中每一種消息的格式和測試方法，必須針對每一種消 息構建獨立的測試腳本。這將導致測試工作復雜，難以以統一的方式有效的執行和管理。
單元測試和 集成測試的“鴻溝”
我們前面提到，項目組在集成測試時感到頭疼，在做分布式復雜應用系統的測試 過程中，往往會碰到這樣的問題：各個子系統和模塊在獨立開發和單元測試階段都進行的十分順利，軟件的質 量也不錯。一旦進行到集成測試階段，由於各個模塊和組件之間的消息契約十分復雜，依賴關系眾多，系統與 系統之間在做聯調測試的時候容易出現各種各樣的問題，導致集成之後的軟件系統質量底下，運行期間持續暴 露各種各樣的缺陷。
圖 3. 到了集成測試階段，質量突然下降
圖三中，我們看到軟件質量在 "Big Bang"後有個下降期，這是因為在單元測試階段沒有考慮集成測試的問題。舉個例子，組件 A 依賴組件 B 和 C，組件 ABC 分別由不同的小組開發，每個小組都會進行單位測試，保證自己小組開發的組件 沒有問題。但當某一時刻，組件 ABC 都開發好後一集成，問題就出來了。這是我們所說的單元測試和集成測 試的"鴻溝"，如果將集成測試介入到單元測試中，出現問題的幾率就會大大降低。
測試環 境構建費時費力，難以平衡質量和進度
分布式復雜應用系統采用技術種類眾多，包含各種類型的操作 系統、中間件、數據庫、通信協議等等。為了測試一個端到端的業務場景，往往需要耗費大量的人力、物力和 時間來重復搭建測試環境（如應用服務器配置、測試數據准備、消息隊列初始化等），並且十分容易出錯。據 統計，測試環境搭建平均耗費掉測試周期 30% 到 50% 的時間。
另外，有時需要定制和額外的軟件支 撐來滿足種種約束（例如，第三方軟件可用性，安全，等等），可能仍然不足以反映目標運行環境 , 或者針 對特定條件的測試 ( 第三方組件新的版本等等 )。為滿足業務目標，系統所需要的開發和測試頻率，由於測 試環節低下的生產率和覆蓋率而被大大地限制了。更長的測試周期增加了應用交付的風險，系統的質量也難易 得到保證。
後台性能瓶頸難捕獲
對傳統的應用系統做性能測試時，通常的做法是采用性能測試 工具通過錄制用戶界面操作生成測試腳本的方式來進行。但分布式復雜系統的性能瓶頸往往不在 Web 前端界 面，界面上一個簡單的操作往往對應著後台大量的子系統、模塊接口的消息調用，任何一個接口的消息處理性 能瓶頸都會影響到整體系統的性能。此外，通過傳統基於界面操作錄制的方式也無法靈活地模擬多個接口直接 的串聯和並發調用的場景。而且，傳統的性能測試工具，如 Load runner, RPT 等，錄制的是第一層客戶端（ 經常是浏覽器）發送給第一個服務器（經常是 web 服務器 ) 的請求，而服務器發送給後台的請求是捕獲不到 的，而後台的服務器設置往往是性能優化的關鍵。
移動終端應用為測試帶來的挑戰
從目前軟件 開發來看，越來越多的企業認識到其業務應用的用戶已開始從個人計算機 ( 如台式機和筆記本電腦 ) 轉向移 動設備 ( 如智能手機和平板電腦 ) 來訪問 Internet 並獲取所需的信息。用戶使用移動設備作為訪問 Internet 獲取信息和請求服務的主要途徑，因為無論去哪裡人們都能隨身攜帶移動設備，並且移動設備更加 直觀易用。這種用戶行為的重大轉變促使企業為現有的應用開發移動版本，隨著移動應用市場的成熟，相應的 移動軟件開發測試問題呈現到人們的視野之中。
移動應用開發面臨巨大挑戰的一個領域是測試。移 動應用測試在復雜度和成本方面比傳統應用有了重大的飛躍。與傳統 PC 和 Web 應用不同，支持移動設備和 版本級別的范圍可能非常龐大。移動項目測試動辄包含數百種設備，移動操作系統、網絡運營商、區域設置和 設備方向組合的情況相當普遍。連接不同的運營商網絡時，同一型號的設備功能可能也會略有不同。此外，網 絡連接的質量對於移動應用的表現也會產生深遠的影響。
絕大部分移動應用具有多層的架構，設備處 於"前端"，對中間層和"後端"數據進行訪問。有效的移動應用測試涉及到各應用層，而 不只是測試移動設備上的程序。中間層和後端服務有可能會為移動應用測試帶來極高的成本和復雜性挑戰。
許多移動項目會使用手工測試方式，這是一種快速開始測試的有效方式。但團隊必須購買應用支持的 各種移動設備，測試人員按照已編寫好的腳本說明執行測試。這種手工測試代價大，效率低。但是在應用可用 性的信息反饋方面，手工測試確實能發揮很大作用。
除了依靠實際的移動設備，還可以使用移動設備 模擬器和仿真器來執行測試。借助這種方法，在桌面工作站上運行的軟件程序能夠代替實際的設備來完成測試 。運用模擬器和仿真器開展移動應用測試對於開發人員單元測試等任務十分有效。因此，無論是手工測試還是 自動測試，在實際的移動設備上執行某種形式的測試往往十分必要。
有些移動應用測試解決方案依賴 於在設備上運行代理程序，可用自動執行的方式與測試腳本進行交互，這種方法能夠靈活地運用實際物理設備 或仿真器開展測試，並可通過自動化技術提高效率。
Rational 測試工作台解決方案
針對傳統 應用的測試和新型系統類型的測試，IBM 提供了 Rational 測試工作台解決方案。該方案作為 Rational 軟件 質量保證的核心組成部分，為企業分布式復雜應用系統和移動應用系統等提供了強有力的測試支持。
圖 4. Rational Test Workbench 架構圖
Rational Test Workbench
圖四中，黑色方框內是 Rational Test Workbench(Rational 測試工作台 )，該測試工作台提供了廣泛的測試 能力，包含 GUI 的功能測試、消息接口的功能測試、GUI 性能測試腳本的編寫、消息接口的性能測試腳本的 編寫、消息接口的樁的腳本的編寫和移動應用的測試等，具體包括以下四個組件：
Rational Integration Tester( 簡稱 RIT)
Rational Functional Tester( 簡稱 RFT)
Rational Performance Tester( 簡稱 RPT)
RTW Mobile Client
並且 RTW 其可以和性能測試服務器 (Rational Performance Test Server)/ 服務虛擬化服務器 (Rational Test Virtualization Server) 協同工作 , 共同完成大規模 , 多團隊的服務測試 , 性能測試 , 服務虛擬化仿真等 .
集成測試組件 RIT
Rational Integration Tester（以下簡稱 RIT）定位 是用於測試分布式復雜應用系統的自動化測試工具，優勢是支持復雜系統的多種類型的接口的自動化測試，可 以把不同類型的接口測試組合起來，按照業務流程形成一個完整的測試過程。
其可以應用於傳統的系 統（例如文件， FTP，中間件）和新建應用（SOA, XML, JMS, ESB, BPM, CEP, Cloud 等）。通常這類系統沒 有用戶界面，RIT 提供了基於 UI 的測試能力，也能夠被集成到客戶現有的產品中。 RIT 為復雜環境的客戶 提供了完整的集成測試能力。具體特性包括：
無需編碼的測試
傳統的自動化測試工具需要用戶編寫測試腳本。RIT 使用一系列可配置的測試步驟來構建測試腳本模型並 且使其與測試者的活動更緊密。例如，"發送消息"、"與預期的消息比較"、"查詢 數據庫"、"在日志文件中查找錯誤"、"檢查文件的一致性"等等，都無需測試人員 手動編寫測試腳本。由於無需手動編寫測試腳本，測試人員將關注於與工具向導的交互，例如通過 Schema 和 消息交換模式來生成測試、修復損壞的測試等。通過消除手工的、重復的、耗時的操作，RIT 可以讓測試人員 的精力關注在更有價值的活動上。
產品架構
RIT 提供了圖形用戶界面來管理測試資產，用於交互執行和優化測試用例。測試用例也可以通過命令行、 ANT、Maven、或者其它測試管理工具執行。RIT 是一種基於 OSGI 的應用，使用了 Eclipse 框架的元素。
報告功能
測試結果被寫入可定制的報告，可以通過 Web 浏覽器或者產品本身來查看。報告可以被導出為 PDF 或者 HTML，也可以導入到 Word 或者打包通過郵件自動發送。
豐富的可擴展性
RIT 提供了豐富的可擴展性，例如定制數據轉化、驗證、數據傳輸和接收、數據格式化等。
持續測試和驗證
RIT 能夠很好的與持續構建服務器集成在一起，以調度的方式執行測試並報告結果。RIT 還可用於持續的 驗證服務，包含語義檢查，響應時間違規報告。
測試和缺陷管理
RIT 具有和測試管理和缺陷跟蹤系統集成的能力，例如 IBM Rational Quality Manager。允許從測試管理 工具中執行測試並收集結果。支持集成 JIRA 和 IBM Rational Team Concert 作為缺陷跟蹤系統。並且，能 夠在缺陷中包含上下文信息，以幫助開發人員快速修復。
多協議支持
RIT 提供了大量的協議支持能力，並且還在不斷更新。涵蓋了常見廠商的產品和技術，並且還提供了強大 了行業特定協議的支持，例如醫療、金融、交通等。如圖五所示：
圖 5. RIT 支持的協議
GUI 功 能測試組件 RFT
試想，一個網上在線商場系統，需要考慮用戶的不同使用習慣，主流的用戶可能使用 Windows2003，,WindowsXP,Windows 7 等不同操作系統，使用 IE,FireFox 等不同浏覽器；那麼在線商場系統 是否在不同操作系統 / 不同浏覽器的組合情況下，，都可以正常工作呢？這就需要針對這不同測試環境分別 進行測試，即針對測試環境的覆蓋率測試。而自動化回歸測試工具的"一次錄制，多次（不同環境）運行 "就可以完全滿足這種需求，提高測試覆蓋率。
功能測試工具的技術特點是"一次錄制，多 次運行", 測試人員在第一次測試時候錄制標准答案，以後在應用發生了修改以後，或者需要覆蓋更多測 試環境情況下，調出第一次錄制的腳本，讓自動化功能測試工具自動運行，得出測試結果。
圖 6. 自 動化回歸測試測試環境覆蓋率
自動化功能測試主要圍繞界面進行 測試 , 通過自動錄制形成測試腳本實現自動化的功能 / 回歸測試。Rational Functional Tester（以下簡稱 RFT）就定位幫助測試人員完成 PC 應用自動化功能測試。RFT 支持對浏覽器、Java Application 應用、SAP 、Siebel 應用以及 .Net 界面應用的功能測試自動化，其測試腳本語言采用 Java 或 Microsoft VB .NET， 並可和 Eclipse 或 Microsoft Visual Studio .NET 集成。由於采用標准的測試腳本語言，測試人員無須學 習特定語言的語法和 API，同時通過和開發環境集成，大大降低了工具學習成本，甚至開發人員也可以迅速掌 握該工具，積極參與到自動化測試腳本的開發過程中。
RFT 提供了標准的腳本錄制功能，並在無需編 程的情況下，快速實現測試數據的參數化，提高測試腳本的開發效率。
此外，在測試腳本的開發方式 上，測試人員使用 RFT 可從最初的基於錄制和數據驅動技術，逐步過渡到基於測試框架的腳本開發技術。
RFT 具體特性包括：
支持多種 IDE: 為 Java、Web、SAP 和 Siebel 和 Microsoft Visual Studio.Net 程序
定制生成 Java 或 Visual Basic.Net 語言的測試腳本
為高級測試人員提供原汁原味的 Java 和 VB.NET 編輯器和調試器
通過 ScriptAssure 技術，支持"按照屬性的優先級"來設置對象識別，從而靈活的應對頻繁的 用戶界面變更，如測試多語言系統時候，把語言相關的屬性設置低優先級，從而使測試環境做到和系統語言無 關。
多點驗證，支持正則表達式的模式匹配自動化的數據關聯和數據驅動測試，消除手工編碼的需要
先進的對象映射維護能力
可用於測試 3270/5250/VT100 終端應用程序
GUI 性能測試組件 RPT
一個大型的應用系統，在多個人訪問的情況下是否還可以穩定，高效的運行 ，如火車票購買網站，是否支持在春運的時候，多個人同時訪問，進行正常的火車票查詢和預定？這就需要通 過性能測試來檢驗。
性能測試是為描述測試對象與性能相關的特征，並對其進行評價而實施和執行的 一類測試，如描述和評價測試對象的響應時間、吞吐量，以及操作的可靠性和限制等特征。一般可以使用被測 系統的動態監測報告、響應時間及吞吐量報告、百分位圖報告和各種性能比較報告，對被測對象進行性能評測 。
性能測試可以有效地幫助測試人員和性能工程師驗證系統的性能，識別和解決各種性能問題。它適 用於性能測試人員和性能優化人員，用於開發團隊在部署大型應用程序前，驗證其可擴展性、性能和可靠性。
性能測試方案的系統架構如圖所示，性能測試工具安裝在 Master 主機上，控制腳本運行和整個負載 加載過程。根據負載模型的要求，首先將測試腳本下載到 Agent 機器，然後在 Agent 機器運行腳本，模擬多 個虛擬用戶，分別加載到服務器。同時在整個測試過程自動收集測試數據，由測試主機統一處理，生成測試報 告及各種報表。
圖 7. 性能測試工具工作圖
Rational Performance Tester( 以 下簡稱 RPT): RPT 能支持 HTTP/ HTTPS、SAP、Siebel、Citrix 和 TCP Socket 協議，同時客戶可利用 RPT 提供的協議開發工具包 (Protocol SDK)，自主開發特殊協議的適配器，從而實現對其它協議的支持。RPT 基 於 Eclipse 平台，並基於 Java 腳本語言，能快速開發性能測試腳本、建立性能測試負載模型、靈活運行性 能測試並生成各種性能測試報告，具有易用性和開放性等特點。此外，RPT 能實現對服務器資源的實時監控， 並建立資源使用狀況和服務器響應狀況的關聯，從而幫助快速定位在操作系統層面的性能問題。對 J2EE 應用 ，RPT 還能進行性能深層次分析，更准確定位應用代碼中的性能問題。在執行性能測試時，支持配合 Rational Performance Test Server 使用。
RPT 具體特性包括：
Web、SAP、Siebel 和 Citrix 應用程序的性能測試
可視化編輯器同時提供測試的高層視圖和詳細視圖
不同用戶群的靈活建模與仿真
運行時的報告能夠立即識別性能問題
自動識別和支持動態服務器響應
測試中用戶負載動態變化
服務器資源數據的收集與可視化展現
采用浏覽器樣式顯示測試中的每一張網頁
能對服務器資源進行監控
能對 J2EE 應用性能問題進行深層分析
移動應用測試組件 RTW Mobile Client
"移動改變生活"，如今，如果你使用的不是智能 手機，那麼真的有可能是 Outman/out woman 了，我們出門打車，察看天氣，移動交流，微博微信，這些都已 經滲透在我們的生活中。眾所周知，移動應用已經在我們的工作生活中廣泛使用，電影票，機票，打車，銀行 轉帳，購物都可以通過 App 來解決；而移動 App 的開發測試也面臨著很多的挑戰，重要的是作為移動終端， 類型多樣化，技術多樣化。如 Android 操作系統的版本眾多（Android 2.2 到目前最新的 4.2），這些都會 讓移動 App 的開發者面臨著這樣的疑問：我們開發的 App 是否可以支持這些名目繁多的手機 / 系統 / 版本 ? 如何測試呢，針對沒有手機終端或者模擬終端進行手工安裝，跑功能測試 ?
這就是自動化的移動測 試要解決的問題。
RTW Mobile Client 是 Rational 測試工作台在 V8.5 以後新增的功能，主要針對 移動應用系統提供相應的測試解決方案。其采用錄制 - 回放 - 檢查結果的過程，完成手機應用的自動化測試 。
具體特性包括：
提供簡潔的 IDE 和終端程序來修改測試腳本、執行測試案例和生產測試報告
自然語言描述操作步驟及可視化的編輯測試腳本
支持運行在 Android 和 iOS 上 native 和 hybrid 類型的應用
融合了移動和 Selenium 的多流程的 Web 界面測試
集成 RQM(Rational Quality Manager) 增強測試計劃和圖形展示能力
集成 IBM 移動開發平台
圖 8. 移動自動化測試過程
我們後續會在《使用 IBM Rational Test Workbench 測試 Android App 應用》中詳細介紹使用 RTW 來測試移動應用程序。
Rational Performance Test Server
通常我們希望在系統上線之前就可以找到 SOA 應用或者基於"消息 "的系統的性能瓶頸，與傳統的獨立應用系統性能測試不同，這類應用的性能往往涉及到很多層面：多端 點、多主機、極限消息傳輸率、極限消息大小、消息延遲等等。作為 Rational Integration Tester 的擴展 ，Rational Performance Test Server( 以下簡稱 RPTS) 為分布式復雜環境和 SOA 的性能測試帶來了便利。 這允許用戶重用任何消息接口的功能測試腳本（RIT 腳本）作為性能測試的基礎，混合不同類型的交互來測試 應用對服務器實際負載的影響。有點類似傳統的性能測試工具中的混合測試？對，的確是的，但請注意的，在 這裡混合的協議很多是後台服務器要使用到的協議，而不僅僅是第一層客戶端發送給後台的協議數據包。
作為 RIT 的性能測試擴展，用戶通過 RIT Performance Controller 定義性能測試的場景，測試負載 通過 RPTS 可以在多台服務器上通過代理（Agent）生成。通過采用探針的方式，操作系統和特定消息數據可 以被捕獲並返回結果，同時用戶能夠通過圖形化的界面（RIT Client）來進行分析而無需進行編程。此外，還 能夠通過並行執行多個消息端口的測試來充分模擬實際的業務場景。
在性能測試過程中，僅僅收集簡 單的 CPU 和內存的信息是遠遠不能夠滿足分布式復雜系統和 SOA 應用的需求的。RPTS 通過探針（Probe）技 術來助力挖掘出性能測試期間各分布式組件的底層詳細信息。RPTS 涉足分布式復雜系統監控領域已經超過 10 年，知道哪些性能指標是最重要的並且能夠輕易獲取。通過一個簡單的配置接口就能夠訪問數百種關於 TIBCO ，Sonic，IBM，BEA 等中間件的性能度量指標。
圖 9. RPTS 性能測試架構圖
只有獲取了詳細的性 能監控指標運行結果的性能測試才是一個有效的測試，RIT 的性能監控圖表引擎可以在測試執行階段或者結束 階段，從海量的性能指標數據中提取我們最需要的信息。並且能夠導出成各種形式的報告，以各種我們希望的 圖表形式體現。我們可以：
通過單擊，實現跨多台機器的消息匯總分析；
定義與多台測試機相關的性能指標；
通過探針捕獲測試執行期間的性能測試指標；
捕獲受測試影響的基礎架構的性能指標；
通過靈活的圖表，在測試執行期間或者結束後進行性能指標分析；
通過回歸測試比較不同的測試結果；
與團隊成員共享測試結果；
通過模版，快速進行通用負載測試場景分析；
通過 RIT 報告性能測試問題
Rational Test Virtualization Server
介紹
Rational Test Virtualization Server （以 下簡稱 RTVS）。RTVS 能夠在多種場景下使用，進行服務的虛擬，不僅僅局限於在測試環境供 RIT 執行。作 為能夠獨立運行的模塊，RTVS 同樣能夠在各種測試場景或開發環境中為手工測試人員和開發人員帶來便利。 並能夠與 RIT 無縫集成 :
測試人員往被測系統發送一條消息，被測系統將執行業務操作並調用相關虛擬服務。
虛擬服務接到被測系統發送過來的請求，並驗證消息的正確性。
虛擬服務決定如何響應消息（例如，錯誤處理、查詢請求、超時等）。
響應通過虛擬服務發送回被測系統，RIT 將驗證響應是否正確。
圖 10. 服務虛擬化解決方案
方案的價值
Rational 測試工作台解決方案能夠為客戶帶來如下的價值：
構建強大的測試團隊
虛擬服務通過中央存儲區進行集中存儲，方便團隊開發和測試成員進行訪問。團隊成員隨時查看虛擬集成 環境的配置，並在浏覽器中根據不同的測試場景快速簡潔地進行修改。RTVS 的虛擬服務能力，包括：
預制的：用戶使用任意的輸入，始終返回預制的響應，並且是可控的。
參數化：虛擬服務使用一個數據集，通過表單、數據庫或文件返回大量不同類型的數據。同時還支持將數 據反持久化到響應的數據源中。
帶狀態的：基於早期數據返回響應，例如，在一次會話中。
模型驅動：RTVS 提供了豐富的應用行為庫，比如持久化、數據供給、B2B、甚至是交易環境等。
RTVS 提供了功能強大的向導工具以通過記錄的方式創建虛擬服務、數據庫、 SWIFT、HL7、IATA、JMS、 Web Services、SOAP、REST、TCP/IP 等。
完美的敏捷開發支持
RTVS 為敏捷團隊進行持續測試提供了良好的支持。由於應用是虛擬的，團隊無需在開發環境和測試環境中 切換配置，並且任何人對虛擬環境的修改都不會影響到實際的系統環境。開發人員和測試人員將采用完全相同 的測試環境，以更好支持並行開發 / 測試。
更快、更低成本的測試
項目團隊可以通過在不同場景下使用 RTVS 而獲取價值：
通過模擬外部系統，使得集成測試環境相對獨立，避免了潛在的風險。
虛擬服務提供的通用響應能力能夠將當前測試與即將進行的測試繼續比較，以更好地復用測試。
通過可重復、可復用、非人工的方式加速 BPM 應用的測試。
簡言之，服務虛擬化可以幫助我們：
通過虛擬化來加速軟件交付質量，提升開發和測試速率。
跨團隊的測試環境共享，實現並行開發。
跨組織團隊實現追蹤和基於上下文的協作。
虛擬化系統的服務，提供 24x7 的測試能力。
降低搭建傳統測試環境基礎架構的支出。
跨越對軟硬件，雲環境的依賴，交付更快的，端到端的持續集成測試。
我們後續將會在《使用 RTW 對 Web service 進行接口測試和虛擬化仿真》，《擴充虛擬化，實現靈活的 服務虛擬化》等文章進一步展開服務虛擬化，結合具體的案例，和大家一起學習討論。
小結
通 過本文，希望讀者能對 Rational 測試工作台有一個初步的了解，在後續的文章中，我們會對 Rational 測試 工作台的各個組件進行專題的介紹，使 Rational 測試工作台可以應用到讀者的生產和工作之中。
