1 性能測試的挑戰
性能測試是為描述測試對象與性能相關的特征，并對其進行評價而實施和執行的一類測試，如描述和評價測試對象的響應時間、吞吐量，以及操作的可靠性和限制等特征。一般可以使用被測系統的動態監測報告、響應時間及吞吐量報告、百分位圖報告和各種性能比較報告，對被測對象進行性能評測。
一般來說，在性能測試員進行系統性能測試的過程中主要面臨以下挑戰：
性能測試腳本的能力：它包括性能測試員構造各種復雜性能測試場景的能力和測試腳本的擴展和維護能力。
測試腳本的參數化能力：性能測試總是要模擬大批量虛擬用戶對被測系統進行各種操作，因此測試腳本的參數化能力和上下文數據的關聯能力，便成了性能測試員進行性能測試時要解決的基本問題。
構建各種負載模型的能力：準確模擬被測系統的真實負載情況，是確保性能測試有效、準確的前提。
被測對象的性能監控能力：它為性能測試員進行各種性能分析、定位問題和解決問題提供保證。
性能測試結果的分析能力：性能測試員需要使用各種報告和報表，對性能測試過程中的各種性能數據進行有效分析，做到正確認識被測系統的各項性能指標。
因此，優秀的性能測試工具，一定要滿足以上各種性能測試能力要求，使得性能測試員在測試工具的幫助下，能夠輕松完成各種性能測試。IBM最新推出的性能測試解決方案：IBM Rational Performance Tester（簡稱RPT），正是很多性能測試員夢寐以求的，能夠為其提供以上各種能力，幫助其輕松完成各種WEB應用系統性能測試的優秀測試工具之一。
2 IBM最新自動化性能測試解決方案：Rational Performance Tester
IBM Rational Performance Tester（簡稱RPT）是IBM基于Eclipse平臺及開源的測試及監控框架Hyades，開發出來的最新性能測試解決方案，總體架構如圖一所示。它可以有效地幫助測試人員和性能工程師驗證系統的性能，識別和解決各種性能問題。它適用于性能測試人員和性能優化人員，用于開發團隊在部署基于HTTP和HTTPs通信協議的Web應用程序前，驗證其可擴展性、性能和可靠性。在為性能測試員和性能優化人員提供了前面所提到的各種性能測試能力以外，它還提供了可視化編輯器，一方面可以使新的測試人員可以在無需培訓和編程的情況下，即可快速上手完成性能測試；另一方面，也為需要高級分析和自定義選項的專家級測試人員，提供了對豐富的測試信息的訪問和定制能力、自定義 Java 代碼插入執行能力、自動檢測和處理可變數據的能力。
圖一、IBM Rational Performance Tester體系架構示意圖
此外，通過和IBM Rational的整個軟件平臺的完美集成，它第一次為基于Eclipse的Web和J2EE應用系統的性能測試人員，提供了和開發人員同樣的操作平臺，真正實現了一個平臺、統一軟件開發團隊和性能測試團隊的能力。
3 使用IBM RPT輕松完成自動化性能測試
3.1 基于與開發人員同樣的平臺進行性能測試腳本錄制
基于開發人員的同一開發平臺（Eclipse），如圖二所示，性能測試人員使用RPT進行軟件性能測試時，只要在開發人員工作的Eclipse環境中建立性能測試項目（其實它也是一種Java項目），就會自動打開測試透視圖，立即擁有專業的自動化性能測試工具所擁有的全部功能。
圖二、IBM Rational Performance Test工作界面
在RPT的測試腳本的實現過程中，使用了基于錄制的腳本生成技術。當完成性能測試的測試計劃和測試設計以后，如圖三所示，性能測試員只要在性能測試工具條上選擇測試腳本錄制按鈕，在彈出的"HTTP代理記錄器"窗口輸入測試腳本名稱，就會自動啟動測試腳本錄制過程。
圖三、進行性能測試腳本錄制
如圖四所示，性能測試工具RPT會自動打開瀏覽器（支持的瀏覽器包括IE,Netscape,Mozilla）。此時，性能測試員應根據提示，首先刪除臨時文件，然后在瀏覽器中輸入被測Web應用的網址，按照測試用例的設計步驟瀏覽Web應用程序，完成測試腳本錄制。
圖四、性能測試腳本錄制的注意事項
腳本錄制和生成架構
如上圖所示，RPT使用位于代理控制器上的記錄器，完成性能測試過程原始協議數據的錄制工作，并將其存在跟蹤記錄文件（.recmodel和.rec文件）中。然后，RPT測試生成器會對跟蹤記錄文件進行分析，生成測試腳本（.testsuite文件）。RPT提供了圖形化的測試腳本編輯器，如圖五所示，性能測試員可以通過圖形界面，顯示測試腳本錄制過程中瀏覽器和Web應用服務器間所有的HTTP/HTTPs協議信息。在可視化的測試腳本編輯器中，性能測試員可以察看具體的消息協議數據，包括請求內容、響應頭和響應內容，幫助測試人員理解測試腳本；也可以對指定的消息進行編輯、修改，添加定制的數據關聯或進行腳本參數化；還可以加入定制的Java腳本，進行動態驗證或控制測試執行邏輯。
圖五、測試腳本顯示窗口
3.2 使用RPT輕松實現性能測試腳本的高級定制能力
RPT提供了靈活的測試腳本編輯能力、數據驅動的性能測試能力和上下文數據智能關聯及定制能力。
3.2.1 測試腳本編輯和定制能力
在性能測試腳本的錄制完成后，如圖六所示，基于測試腳本的圖形化界面，測試員可以輕松完成以下各種定制工作：
選取測試消息，通過更改其詳細的標題，建立更易于理解和重用的測試腳本；
通過在測試腳本中添加自定義的HTTP請求，循環和條件語句，測試員可以隨意控制測試腳本的執行過程。循環語句可以控制指定消息的執行次數，條件語句（IF/ELSE語句塊）可以實現根據上一消息的響應內容，決定測試腳本的執行路徑；
通過在測試腳本中添加自定義的Java代碼，測試員可以實現對消息返回內容的驗證、為后面的消息構造動態消息數據或執行各種特殊任務；
通過將一些消息組織成相應的事務，使得整個測試腳本更加容易理解，同時可以更方便的對測試結果進行分析；
通過啟用頁面標題驗證點、響應代碼驗證點和響應包大小驗證點，RPT會自動完成對測試執行過程中的頁面標題、消息響應代碼和數據包大小的驗證，生成各種測試驗證報告。
圖六、PRT測試腳本的能力
通過以上內容，我們可以充分領略到RPT為性能測試員提供的強大性能測試腳本能力。更難得的是，幾乎所有這些能力都可以通過圖形界面，在輕松的鼠標點擊聲中得以實現。
3.2.2 數據驅動的性能測試能力及測試數據的智能關聯能力
性能測試的主要任務就是模擬一定數量的虛擬用戶，按造指定的負載模型對被測系統進行各種操作，完成測試。因此，性能測試腳本的參數化能力和消息上下文數據的智能關聯能力，就會成為性能測試員工作中的一個重要任務。
RPT在測試腳本錄制和生成過程中，能夠按照最佳實踐經驗，自動完成測試數據在不同消息間的智能關聯（關聯數據用紫色標識）。如圖七所示，為了性能測試員更好的理解測試數據的來源，還可以選擇指定的測試關聯數據，右鍵菜單轉至指定關聯的數據源。此外，測試員還可以通過圖形界面，自己建立數據關聯關系，實現各種動態數據關聯需求。
圖六、PRT測試腳本的能力
圖七、測試腳本中消息上下文中數據的智能關聯 RPT會自動標識可能進行參數化的動態數據（用綠色標識），測試員可以通過右鍵選取指定的數據，如圖八所示，選擇用數據池變量替換，從而實現測試腳本的參數化任務。RPT使用綠的底色標識指定的變量由數據池中讀取。當然，在測試員可以使用數據池之前，如圖九所示，首先必須在性能測試項目中創建所需的數據池，數據池中的數據可以從外部文件中導入，也可以在數據池的數據編輯窗口中進行編輯。
圖八、測試腳本參數化
圖九、數據池的創建過程和數據池內容編輯窗口
通過以上描述，我們可以充分了解到RPT靈活、方便的測試腳本的參數化能力和上下文數據的智能關聯能力，它們將會使性能測試員的性能測試工作變得更加輕松。
3.2.3 自定義Java腳本的使用
在測試腳本中添加自定義的Java代碼，主要是為了實現對消息返回內容的驗證、為其后的消息構造動態消息數據或為了完成如驗證、加解密、日志記錄等的特殊任務。RPT通過內置Java代碼執行引擎，提供在測試腳本中靈活插入客戶化Java代碼的能力。性能測試員可以通過右鍵菜單（如圖六所示），方便地在測試腳本中添加定制Java腳本。
圖十、在測試腳本中加入定制代碼
在加入定制代碼過程中，性能測試員通常要根據需要為添加的Java類命名，然后，點擊"生成代碼"按鈕，RPT可以自動生成測試腳本的框架；通過點擊"查看代碼"按鈕，性能測試員可以對生成的代碼進行編輯，實現所需的定制任務。自動生成的Java代碼框架如下所示：
|
package test; |
從代碼中我們可以看到，性能測試員只要把要實現的邏輯寫入exec()方法即可。定義了定制腳本之后，我們就可以在其后的測試腳本中使用自定義的代碼，完成各種任務了。具體操作過程如圖十一所示，RPT用桔黃色來標識變量的值來自定制的Java腳本。
圖十一、在測試腳本中使用"定制代碼"
3.3 建立性能測試負載模型，執行性能測試
壓力測試的關鍵是能夠通過測試工具準確模擬被測系統在生產環境運行時的真實負載情況。在進行性能測試前，一般會由性能測試員和用戶代表一起，根據性能測試計劃中指定的的測試目標，制定測試用例，完成對應的負載模型分析，以便正確執行和實現性能測試目標。一般情況下，性能測試員使用《負載分析文檔》來確定性能測試負載模型中要使用的各種變量，并定義變量值。通過它們來確定被測系統在生產環境中運行時，涉及的各種負載角色特征、每種角色要執行的最終用戶業務功能（用例及其執行流程與條件）和對應工作量和容量，以便最恰當地模擬最終用戶的負載情況。此外，負載模型中還應確定負載模擬持續的時間間隔、測試期間要改變的任何因素或變量，以及測試結果的評測方法。
進行負載模型分析的關鍵，在于找出被測系統的主要角色，以及主要角色所進行的關鍵任務，從而從總體上了解被測系統是如何被各種不同用戶使用和在怎樣的負載情況下工作的。在進行性能測試前，性能測試員可以通過如下手段獲得系統負載模型中的各種變量：
1) 從最終使用人員獲得操作情況，如經常進行的業務類型、業務操作的頻率；
2) 根據系統日志，可以獲得每日所進行的各種業務類型和業務量；
3) 通過和系統測試人員、操作人員、系統架構師充分溝通和配合，對被測系統作如下分析：
定義系統主要角色,它在UML中被稱作主角(Actor)，確定每個主角的屬性和工作簡檔，確定哪些能夠唯一標識被測系統最終用戶的各種特征的屬性和變量（如打字速度、思考時間以及反復出現的因素）。
確定系統主要角色相關聯的用例（Use Case），及每個用例中的主要操作流程，即用例中的必選流和主要可選流，明確每種角色通過執行用例來履行業務職責時，每種操作流程所用的工作量比例或耗時百分比。
確定評測指標和標準，用于評估既定性能目標是否已達成。評測指標通常包括響應時間限度或吞吐量。
最終形成如下面例子中的系統負載模型：
在IBM Rational Performance Tester工具中，如圖十二所示，可以使用性能調度（Schedule）完成構建負載模型的任務。它主要提供了以下測試控件，幫助測試員實現靈活的負載模型：
1) 用戶組：實現不同角色的模擬。在用戶組中，可以加入各種測試腳本、隨機選擇器、循環、延時等完成與角色關聯的各種典型業務操作流程的模擬。對用戶組可以設置具體業務負載百分比，來模擬不同用戶組對被測系統造成的負載比例；
2) 隨機選擇器：實現用戶組內部各種隨機業務操作（用例及其事件流）所占不同負載比例的模擬�？梢栽陔S機選擇器中加入不同的加權塊，代表不同的業務操作（用例及其事件流），通過對其設置權重完成對其負載比例的模擬。
3) 循環：完成用戶的重復操作的模擬，例如用戶在查詢產品時，可能會對不同產品進行多次查詢，這時性能測試員可以通過對測試腳本進行參數化和指定腳本的循環次數，來完成對應的負載模擬工作。
4) 延時：用來模擬真實環境中，用戶在進行不同業務操作中可能存在的思考和等待時間。
通過RPT中的性能調度（Schedule），性能測試員就可以將上表所述的負載模型準確的模擬出來，如圖十二所示。
圖十二、RPT使用性能調度進行負載模型的模擬
在完成負載模型以后，測試員就可以在"性能調度(Schedule)"的屬性中動態隨需指定想要運行的虛擬用戶數，進行不同數量的虛擬用戶負載情況的性能測試。
圖十三、在RPT中指定不同數量的虛擬用戶執行性能調度（Schedule）
測試員執行指定的性能調度（Schedule）時，如圖十三所示，應該首先選擇"運行"，然后在彈出的運行配置管理窗口中，為Schedule創建新的配置。如圖十四所示，在配置的屬性中，性能測試員可以指定要執行的Scheudle，執行結果的存放項目和目錄，以及是否該配置出現在運行或調試菜單中。
圖十四、性能調度（Schedule）的運行配置
從以上部分我們能夠看到，RPT為性能測試員提供了通過鼠標點擊就可實現的靈活負載模型建立能力，使得負載模型的建立變得更加的簡單。
3.4 輕松完成測試結果分析
測試執行過程中，性能測試員可以通過自動彈出的測試報告窗口，方便的監控整個測試執行過程，并通過不同的報告頁面實時察看測試結果信息。
在進行測試結果分析時，首先性能測試員可以通過總體運行情況報告，如圖十五所示，對整個測試運行過程有個一目了然的了解。
圖十五中上面的滾動條顯示了整個測試執行的狀態：
正在初始化計算機
正在運行
正在進行執行歷史數據傳輸
完成
圖十五、總體運行情況報告
圖十五中四個柱狀條分別顯示：
頁 面狀態碼成功百分比
頁面元素狀態碼成功百分比
通過頁面驗證點（VP）百分比
通過頁面元素驗證點（VP）百分比
當把鼠標移動到某一柱狀條上時，可以看到當前柱狀條所代表的具體數據值。
運行小結報告對整個測試運行過程進行總結，如圖十六所示，給出性能測試員在進行性能測試時最關心的一些性能指標,例如頁面和頁面元素的平均響應時間，驗證點的通過情況以及頁面和頁面元素的命中數和嘗試數。
圖十六、測試運行小結報告
而頁面性能報告、響應時間總結報告和響應時間詳細報告則為性能測試員提供進一步分析性能問題，定位性能問題提供了必要的信息。頁面性能報告顯示每個頁面的平均響應時間，響應時間總結報告（Response vs. Time Summary）顯示所有頁面和頁面元素的平均響應時間在測試運行過程中的變化情況，性能測試員可以通過它們對被測系統性能問題作出初步估計。響應時間詳細報告（Response vs. Time Detail）則詳細顯示每個頁面的響應時間在測試運行過程中的變化情況，為性能測試員提供了進一步的信息。一般情況下，開始時頁面的響應時間要比穩定狀態的響應時間慢。
圖十七、頁面性能報告
圖十八、響應時間總結報告
圖十九、響應時間詳細報告
頁面吞吐量報告則為性能測試員報告了在整個測試運行過程中，虛擬用戶的活動情況（右圖）和頁面的吞吐量信息（頁面的嘗試速率和頁面的點擊率）；
圖十九、頁面吞吐量報告
如圖二十和圖二十一所示，服務器健康狀況總結報告和服務器健康狀況詳細報告可以讓性能測試員從總體上對服務器運行健康狀況一目了然。服務器健康狀況總結報告通過顯示頁面和頁面元素總的嘗試數、命中數和返回狀態碼的成功總數，幫助性能測試員方便了解被測服務器的整體健康狀況。而服務器健康狀況詳細報告則把相關嘗試數、命中數和返回狀態碼的成功總數，進一步細化到每個頁面和頁面元素，幫助性能測試員準確了解被測服務器的整體健康狀況，定位問題所在。
圖二十、服務器健康狀況總結報告
圖二十一、服務器健康狀況詳細報告
除以上預定義的各種測試報告外，RPT還為測試員提供了靈活的測試報告的定制能力。通過管理報告功能，性能測試員既可以建立新的報告，也可以編輯各種已經預定義好的報告，修改報告內容或增加報告頁面。如圖二十二中"我的報告"頁面所示，性能測試員可以根據測試要求，把自己關心的多項指標，顯示在一個報告頁面。
圖二十二、性能測試報告的定制能力
RPT報告定制能力中最有創造性的技術莫過于它把性能測試員和用戶所關心的各種性能指標以計數器（Counter）的形式記錄下來，如圖二十三所示，測試員在生成報告時，可以根據需要從已定義的各種計數器中選取任何關心的計數器生成報告。這大大增強了性能測試員對測試結果的分析能力和報告能力，這些無疑都會大大改善性能測試員的測試過程體驗。
圖二十三、基于各種性能指標計數器生成測試報告
3.5 系統資源監控
為了更好的進行性能問題分析，找出被測系統的性能問題，性能測試員還需要了解在性能測試的運行過程中，被測系統運行的服務器上的各種系統資源消耗情況。RPT通過其強大的概要分析（Prifiling）能力，可以在系統性能測試運行的同時，完成服務器各種系統資源的監控。具體作法如下
1) 切換到概要分析和日志記錄透視圖（Profiling and Logging Perspective）;
2) 在運行菜單，選擇"概要分析"，如圖二十四所示。
圖二十四、在RPT中通過概要分析實現對服務器各種系統資源的監控
3) 在彈出的"概要分析"窗口選擇"Perfmon數據收集代理程序"，選擇"新建"按鈕，建立新的概要分析配置，如圖二十五所示，并給出要監視的主機和存放監控記錄文件的項目或目錄。最后，點擊"概要分析"按鈕，開始概要分析過程。
圖二十五、建立概要分析配置
4) 在"概要文件監視器"視圖中選擇新出現的、正在運行的概要分析結點，如圖二十六所示，右鍵菜單中選擇"配置Perfmon計數器"，列出所有可以監控的計數器；
圖二十六、開始配置要監控的性能計數器
5) 在"配置Perfmon計數器"選擇想要監控的計數器（例如內存、處理器和網絡等），右鍵選擇"獲取子計數器"，如圖二十七所示，直至找到要監控的計數器，右鍵選擇"開始跟蹤此計數器"。性能測試員可以選擇多個計數器同時監控；
圖二十七、選擇要監控的性能計數器
6) 然后在"概要文件監視器"中選擇正在運行的概要分析，右鍵菜單中選擇"打開方式"－>"統計數據視圖"（Statistical View）。這時，性能測試員就可以在"統計數據視圖"中，看到前面選定的計數器的變化情況，如圖二十八所示。
圖二十八、監控性能計數器
在"測試透視圖"中，性能測試員執行測試時，可以通過選擇"Window -> Show View -> Other … -> Profiling and Logging -> Statistical Data"顯示"統計數據視圖"，實現在性能測試執行的同時，實時監控所關心的各種服務器性能計數器的變化情況。通過將前面分析的各種結果跟被測服務器系統資源消耗情況相關聯，性能測試員能夠判斷是否由系統資源引起了性能問題，從而排除硬件和網絡因素對被測系統性能的影響。
3.6 與其它生命周期管理軟件的完美集成
IBM Rational的自動化性能測試工具基于Eclipse平臺，提供了和需求管理工具（RequisitePro）、建模工具、代碼級測試工具和變更及配置管理工具（ClearQuest和ClearCase）的完美集成，這使得系統測試人員能夠和整個軟件開發團隊在同一個軟件平臺上，實現系統性能測試的同時，完成測試腳本的配置管理和缺陷追蹤任務，這大大提高了性能測試員對整個測試過程的管理和維護能力。
4 IBM Performance Optimization Toolkit幫您完成性能調優
現在，假設您開發的應用程序正顯示出性能問題的征兆，用戶可能會發現該應用程序變得出乎意料得慢。它可能在一段時間之后變為不響應�；蛘咚赡軟]有警告就發生故障，結果導致丟失客戶數據。性能問題的原因主要有兩類：
1) 編碼問題，問題出在應用程序本身的邏輯中。編寫較差的應用程序代碼可能導致應用程序執行多余的或者不必要的工作。例如，算法效率低或者伸縮性不好、不必要地頻繁調用遠程調用、SQL 查詢效率低等，都會導致應用系統性能問題。
2) 配置問題，問題與應用程序無關，而是由外部因素引起的。這些因素包括硬件問題（如內存不足或者處理能力不足）、網絡問題（如等待時間長、吞吐量低和連接問題）以及其它相關軟件問題（如數據庫調整不當）。
IBM Rational的性能測試解決方案除了RPT提供的各種性能測試功能以外，還包括了最新發布的免費性能優化工具包（IBM Performance Optimization Tookits，簡稱IPOT），它能夠幫助您在您的分布式應用程序中找出并修正與編碼相關的性能問題，和性能測試工具RPT配合使用，幫助性能測試員準確定位基于J2EE的Web應用系統性能問題，分析問題根源，解決問題。
4.1 性能優化工具包的體系架構
性能優化工具包主要由以下兩部分組成：數據收集代理和基于 Eclipse 的開發人員工具。
4.1.1 數據收集體系結構
數據收集體系結構收集整個分布式環境中的運行時應用程序性能數據。對于每臺運行應用程序的主機，如果您想要從該主機收集數據，那么它必須安裝并運行數據收集體系結構。
數據收集體系結構由以下組件構成：
代理控制器，它管理數據收集代理，并與工作臺進行安全通信 ；
應用程序響應測量（ARM）引擎，它從應用程序收集 ARM 數據 ；
ARM代理和JVMPI代理，它們能夠連接到應用程序來收集數據 ；
服務器配置實用程序，它配置服務器將數據發送給代理 ；
數據收集代理，用于從生產或開發環境捕獲跟蹤、監視、收集應用程序性能數據以及日志數據，而應用程序性能數據由應 用程序響應測量（ARM）完成。應用程序響應測量（ARM）標準幫助測量應用程序的端到端的事務性能、服務級別以及響應時間。ARM API 是一個開放式標準�？梢栽趆ttp://www.opengroup.org/management/arm.htm下載相關標準文檔和示例。運行在受支持的 J2EE 應用程序服務器上的應用程序會自動被 ARM API 調用檢測。這意味著它們自動產生數據收集代理收集并分析的數據。其它您想在開發環境中分析的應用程序則必須手動用 ARM API 調用檢測。
4.1.2 基于 Eclipse 的開發人員工具
基于 Eclipse 的開發人員工具，提供視圖和工具以用于查看和分析代碼和運行時數據，它把性能測試員數據收集體系結構收集到的各種應用性能數據，和整個應用運行過程進行直觀關聯，從而有效幫助性能分析人員定位性能問題，并找出性能問題的原因、解決問題。
4.2 使用性能優化工具包（IPOT）輕松進行應用系統的性能分析
利用性能優化工具包(IPOT)可以從生產或開發環境中運行的應用程序中，收集應用性能數據。幫助性能測試員解決以下多種不同類型的性能問題：
性能問題 － 執行操作的時間比預期的長
內存泄漏 － 應用程序在內存使用方面處理不當，導致正常操作期間發生內存不足的錯誤。
應用程序故障 － 應用程序發生故障，表現為或有警告或無警告地突然終止（崩潰），或者進入不響應狀態（掛起）。
下面以解決應用程序性能問題為例，解釋使用工具進行基于J2EE的Web應用程序的性能優化過程。
在使用應用程序性能分析工具時，分析問題的第一步是找出什么引發了該問題。這可能是一個用戶操作，也可能是在整個應用程序中出現的更普遍的問題。如圖所示，在下面的例子中，性能測試員可以通過RPT的頁面性能報告，看到藍色部分顯示的歡迎頁面是最慢的，所以，下面通過RPT和性能優化工具包結合使用，對其性能進行分析。
圖二十九、定位性能問題
明確了存在問題的頁面以后，性能測試員首先要在對應測試腳本中指定頁面的消息屬性中選擇"啟動ARM監控"，如圖三十所示，同時也要在將要執行的"性能調度(Schedule)"的屬性中選擇"啟動ARM監控"。
圖三十、啟動頁面的ARM監控
然后，性能測試員就可以選擇將要執行的"性能調度(Schedule)",右鍵選擇"概要分析"（Profile），啟動'概要分析"配置窗口。
圖三十一、啟動"概要分析"
在概要分析配置窗口中，選擇"J2EE Application with Performance Schedule"配置項，選擇新建配置，如圖三十二所示，給出配置名稱，在Schdule頁面選擇要執行的"性能調度(Schedule)"；在Execution Results頁面選擇用于存放測試概要分析結果的項目；在Profiling頁面選擇"J2EE Performance Analysis"。最后選擇"概要分析"（Profile）按鈕，開始概要分析過程。
圖三十二、 "概要分析"配置窗口
在自動啟動的監視器窗口，如圖三十三所示，性能測試員可以選擇當前運行的監視器節點，右鍵菜單中選擇合適的性能分析視圖，進行被測系統的性能分析。
圖三十三、 打開各種性能分析視圖
一般情況下，性能測試員會首先打開"UML2 Class Interaction"類交互圖，觀察被測應用的總體運行情況。如圖三十四所示，性能測試員可以點擊不關心的類，在右鍵菜單中將其從圖中過濾掉，從而更好地關注性能相關的部分。
圖三十四、性能分析視圖－類交互圖
在"UML2 Class Interaction"類交互圖中，性能測試員可以通過圖中最左邊紅色部分，快速定位性能問題所在。
圖三十五、在性能分析視圖－類交互圖中定位性能問題
在了解被測應用的總體運行情況和大致問題所在以后，性能測試員可以打開"method Statistics" 方法統計視圖，通過排序功能快速、準確的定位耗時最多的方法。
圖三十六、在性能分析視圖－方法統計視圖中定位性能問題
為了進一步了解方法執行過程，在方法統計視圖中還可以右鍵單擊指定方法，選擇"Show Method Invocation",了解方法中具體的邏輯調用過程。具體信息如圖所示。
圖三十七、性能分析視圖－方法執行動態視圖
為了進一步定位被測應用系統的性能瓶頸，性能測試員還可以打開"Performance Call Graph"視圖，找出在整個應用執行過程中最大路徑所在。如圖三十八所示，它可以幫助性能測試員一目了然的定位整個被測應用系統的最大執行路徑，從而時性能分析人員能夠更有效的進行性能分析。如果調用樹過于復雜，性能測試員還可以通過右鍵菜單中的Subtree->Focus on Subtree縮小調用樹的顯示范圍。
圖三十八、性能分析視圖－性能調用圖（Performance Call Graph）
在調用樹上，如圖三十九所示，只要將鼠標置于某一方法之上，性能測試員還可以方便的了解指定方法的具體性能信息。
圖三十九、性能分析視圖－在性能調用圖上顯示方法詳細信息
在性能調用"Call Graph"視圖中，左鍵雙擊性能有問題的方法，就會彈出方法詳細信息窗口，這里性能測試員可以看到有關方法的詳細信息，包括該方法運行所花費時間、被調用次數等，所有調用過它的方法和被它調用的方法的統計信息。
圖四十、性能分析視圖－方法詳細信息視圖
同時，性能測試員可以通過右鍵菜單，直接進入指定方法的源代碼，在代碼級分析代碼性能問題，進行代碼優化工作。
通過以上信息，我們可以看到IBM性能測試解決方案不但為性能測試員提供了簡單易用的性能測試能力，同時也為性能分析員提供了方便的性能問題診斷、定位和輔助解決信息，使得使用者不但可以通過它快速了解被測系統性能狀況，還可以準確定位、診斷及解決性能問題。
5 小結
技術的進步總是在不斷地改造測試員的工作和生活環境。IBM最新推出的性能測試解決方案：Rational Performance Tester不但在在工具的易用性、功能和工具集成度方面有了很大改進，幫助系統性能測試員更加輕松的完成性能測試；而且，通過和IBM免費工具包：IBM Performance Optimization Toolkit的結合使用，為性能測試員提供了強大的性能數據收集、問題定位和分析能力，使得解決應用系統性能問題的過程變得更加輕松。
文章來源于領測軟件測試網 http://www.kjueaiud.com/