Rational Performance Tester 還能夠使您執行根本原因的分析。這在兩個方面獲得便利：資源使用（正如前面所提到的）以及代碼執行統計表。此處，您從性能報告中能夠得到一個響應時間分解報告。這允許您在預定的測試期間從頁面元素中分析統計表，或者從外部工具中分析任何導入的歷史數據。響應時間分解為您所測試的系統顯示了諸如每一項元素的周期等細節。每一個頁面元素都被同統計表中的一個入口關聯起來。在獲得響應時間分解之前，您必須選中 Response Time Breakdown 選項：
- 選擇包括測試腳本的調度，然后選擇 Schedule Element Details > Response Time Breakdown。
- 在 Quick Links 下，勾選 Enable collection of response time data 復選框。
- 最后，為適當的錄制選擇復選框。
圖 32. 啟動響應時間分解
- 確保 DCI 正在運行，并且已經準備好被監控。
- 要啟動監控，進入 Start > All Programs > IBM Software Development Platform > IBM Rational Data Collection Infrastructure > Start Monitoring。
Response Time Breakdown 報告提供了與代碼執行相關的統計表，它包括根本組件：JDBC、RMI/IIOP (Remote Method Invocation over Internet InterORB Protocol)、網絡服務器、EJBs，等等。圖33中顯示了一個 Response Time Breakdown 報告的例子。（您也能夠通過查看 Response Time Breakdown Statistics 獲得更多細節，盡管該選項并沒有被顯示在這里。）
圖 33. 響應時間分解
通常來講，響應時間分解是在開發環境中被捕獲的。在它被啟用和配置用來收集數據的量（低、中、高）之后，并且數據收集器基礎構造被安裝和運行之時，您能夠通過以下幾種方式收集數據：
- 從一個標準的Web 應用程序性能測試中得到；
- 從這些性能監控工具中：IBM® Tivoli® Monitoring for Transaction Performance、IBM® Tivoli® Composite Application Manager for Response Time Tracking、或者 IBM® Tivoli® Composite Application Manager for WebSphere 得到；
- 從 Java™ 2 Platform、Enterprise Edition (J2EE) 應用程序服務器和 Application Response Measurement (ARM) 中得到。它所支持的應用程序服務器包括 IBM® WebSphere® Application Server 版本5和版本6，以及 BEA WebLogic 版本8；
- 從網絡服務中得到；
- 從一個配置 ARM 的應用程序中得到。這一模式支持一個不支持 J2EE 的應用程序服務器。數據能夠通過手動插入 ARM API 調用而被收集。ARM 工具將通過挖掘工具下面的應用程序提供一個事物序列圖表；
- 從應用程序、網絡服務器、數據庫服務器所生成的應用程序日志中得到。這些能夠被導入、分析和關聯。
請注意：
每一個應用程序服務器都需要被配置和被用于數據收集基礎構造。
啟動 Data Collection Infrastructure (DCI) 監控器的唯一目的就是收集分析數據。正如前面所提到的，為了確保數據被收集，DCI 需要為每一臺運行應用程序的主機啟用（安裝和運行）。失敗的操作將導致如圖34中所示的錯誤。
圖 34. Profiling Agent 錯誤
Rational Performance Tester 同 IBM® Rational® ClearCase® LT 被打包在一起，使得源版本控制能夠更好的鼓勵開發環境中的協作。ClearCase LT 配置一個單一的服務器模型以及少量的管理需求。盡管自然地適合于一個比較小型的環境，例如25-30位開發人員和測試人員，但是您也能夠將 ClearCase 或者 IBM® Rational® ClearCase MultiSite® 編輯器用于更加大型的環境中，并且為兩者都提供了移植路徑。
資產，例如項目、調度、測試、定制代碼、數據池、位置、以及結果等，能夠被放到源代碼控制之下。通過 IBM Rational ClearCase LT 源控制，可以提供以下特性：
- 檢入和檢出：檢入資產，使得他人能夠在其上面工作。而檢出則允許您在您的本地工作臺中在其上面工作。
- 透視圖支持：CVS Repository Exploring （如圖35中所示）和 Team Synchronizing 透視圖。
圖 35. 與 CVS 相關的透視圖
- 多個視圖：CVS Console、CVS History 和 CVS Repository。
- 同步與融合：
- 同步是一種通過知識庫檢查本地工作臺之間差異性的一種方式。它允許您在您的本地工作臺中更新資源，并且將資源從本地工作臺提交到一個知識庫中。
- 融合使您能夠在資源沖突時找到折中的方案。
同 Rational ClearCase LT 的集成引入了在工作臺中共享工作資產的功能，或者資產的并行開發功能。任何人都能夠通過檢入和檢出工作區域共享測試文件，任何團隊成員都能夠在任何時間對其進行更新。通常來說，個體將本地工作于團隊項目的一部分，他們通過同步工作臺中發生的任何變化來核對其他人的工作。簡而言之，所有的工作都是由一個本地個體所完成的，只有在這個人將它們通過提交到知識庫中發布之后，它們才能夠被共享。當您已經將變化提交到分部時，變化將會從您的本地工作臺被拷貝到分部中。
基于功能性的需求，有許多不同的分部，例如并行運行的每一個項目都有一個分部。同樣的道理也適用于處理不同的分部。您將通過首先同步您的工作臺，檢查其他人的工作。為了進行同步操作，IBM Rational Performance Tester 配備了一個 Team Synchronizing 透視圖，以便更加容易的進行定位和管理。有以下四種與同步相關的模式：
- 流入：顯示 CVS 知識庫中與本地工作臺不同的資源（只是流入改變）；
- 流出：顯示本地工作臺中將被修改的資源（只是流出改變）；
- 流入/流出：顯示流入和流出改變的結合；
- 沖突：顯示沖突的資源。當知識庫中具有比您正在工作的資源更加新近的副本時，資源就會發生沖突。資源沖突的問題可以通過融合技術解決。丟棄您的工作或者其他人的工作也許并不是一個好的選項。
IBM Rational Performance Tester 首先是一個交互式的 GUI 測試器，它使初學者也能夠輕松的執行加載測試。然而，有時侯也需要添加定制代碼，從而實現更高級的測試方法。
定制代碼選項以綠色字符 C 作為圖標。您可以在測試腳本中的任何位置插入定制代碼。圖36中顯示了兩段即將被插入的定制代碼的片段。當您第一次插入定制代碼的時候，將自動生成一個類名稱。不過，如果您愿意的話，可以將其重新命名為有意義的字符串。
圖 36. 插入定制代碼
當定制代碼被插入之后，您就能夠立即通過轉換到 Java 源代碼視圖來輸入代碼邏輯（點擊 View Code）。此外，您還能夠將透視圖改變為 Java Browsing。另外，內聯的 Java IDE 允許您調試您的代碼。
圖 37. 生成定制代碼
系統提供兩個接口：CustomCode2 和 ITestExecutionServices，用于擴展測試執行（提供一個完整的 Javadoc）。下面的場景就是擴展測試執行的典型用例：
- 控制循環行為；
- 運行一個已經存在的調用外部程序；
- 找到一組用戶或者一個用戶的 IP 地址；
- 設置和清除用戶的訪問消息
- 從用戶數據區域中獲得信息；
- 將一個頁面同另一個頁面關聯起來。
跨越地理邊界為每一個遠程分布的測試迭代動態地測試用戶負載并不是一種通常的做法。典型的測試方法，即每一項測試都被限定在一個位置上，也許對地理分散的開發團隊來說并不具有靈活性。除此之外，跨邊界共享測試資產的能力，Rational Performance Tester 使您能夠通過一個廣域網（WAN）跨越不同的地理位置來執行負載測試。由于服務器可能是地理上分散的，所以遠程執行的能力與較低的硬件要求的結合，使得您能夠使用 IBM® AIX®、Linux、Microsoft® Windows® 和 z/OS 等操作系統配置遠程服務器。
例如，您可能擁有五個低端的服務器，它們從新加坡仿真5000位用戶，另外有三臺服務器從香港仿真3000位用戶，等等。這種測試方法不僅產生更加逼真的測試效果，而且降低了測試的成本，這是因為測試結果可以由團隊共享和分析，而且空閑的服務器能夠被更好的加以利用。
最低需求，例如每個虛擬用戶擁有一個 CPU 和 1MB 的內存（通常來說）首先依賴于測試頁面的復雜性。有些因素能夠增加每位虛擬用戶的內存容量。您能夠通過仿真實際的場景獲得更高的縮放比例，例如為每位用戶使用思考時間和延遲時間。通常來說，將額外的負載放到管理員服務器上并不是一種很好的做法，這是因為與工作臺相關的活動需要服務器中的資源。
在您捕獲測試腳本之后，擴大虛擬用戶的范圍就是添加更多的用戶組。Rational Performance Tester 通過允許您添加更多的用戶組以及指派用戶的絕對值數量或者百分點數量，從而無縫的掌控縮放比例。只要測試實例依舊完整的話，我們就無需重新捕獲測試腳本。
中央管理部門允許一個集中的視圖和管理，只需少量的管理成本就能夠管理遠程測試系統。管理本地測試服務器和遠程測試服務器所花費的精力實際上是一樣的，這是因為遠程服務器并不必掌控本地服務器復雜。圖38中顯示了將遠程服務器納入測試服務器是多么的容易實現。
圖 38. 遠程測試服務器——管理員
在本系列四篇文章的第 1 部分中，我們查看了由 IBM Rational Performance Tester 所提供的各種各樣的功能。包括易于使用的 GUI 管理、報告特性、以及可量測性。盡管這些內容僅僅是被簡要的概述，但是本文為您提供了一幅功能的鳥瞰圖。您能夠使用從這一簡要介紹中所獲得的知識加深對 IBM Rational 軟件交付開發平臺中的軟件選項的負載測試工具的理解。
在第 2 部分和第 3 部分中，您將學習一個完整的負載測試周期。在第四部分中，您將詳細看到包括在 Rational Performance Tester 中的許多報告及其變種，并且學習如何根據您的特定需要對它們進行定制。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
