基于 IBM Rational Build Forge 的自動化性能測試

　　概述

　　敏捷開發(Agile development)是一種以人為核心、迭代、循序漸進的開發方法，開發周期一般是兩星期到四星期。性能測試從環境部署、數據準備到測試、分析，是個工作量巨大的工作，如何才能在很短的迭代周期內完成產品的性能測試，盡早盡快的發現和驗證產品的性能問題，是敏捷開發環境中實現質量保證的關鍵。IBM Rational Build Forge(RBF)是業界領先的自動話流程執行軟件，可以集中、自動化并且加速不同軟件開發組織的軟件開發過程。本文將介紹如何使用 RBF 來實現自動化性能測試。

　　回頁首測試環境部署

　　云計算，是當今 IT 業界最炙手可熱的話題。云計算技術的應用使得測試環境的部署自動化成為可能。當測試者需要申請一個資源時，云計算部署平臺會自動創建一個虛機，預裝測試者所選擇的需要的軟件，并對虛機進行管理。我們使用的部署平臺基于 TSAM(Tivoli Service Automation Manager)，它是 IBM 目前實施云計算解決方案的一個成熟的核心平臺。圖 1 描述了如何借助 TSAM 和 RBF 將 CLM3.0.1 部署到虛機的步驟。

　　圖 1. RBF 驅動的云計算平臺測試環境部署

　　登錄 TSAM 的服務請求控制臺，選擇“Create Project with VMWare Servers”，輸入要創建的項目的基本信息，包括名稱、訪問權限、項目描述和項目的起止時間，也就是期望在哪個時間段使用項目中的虛機。

　　圖 2. 在 TSAM 中創建項目

　　選擇需要預裝的操作系統，調整虛機所需要的資源，包括 CPU、內存、硬盤大小等，并選擇需要預裝的軟件，如圖 3，為了方便后續基于 RBF 的性能測試的自動化，此處需要預裝自定義的一個軟件包 Build Forge Integration prep, 其中包括供 RBF 服務器調用的代理。還要預裝軟件安裝程序 IBM Installation Manager (IM). 值得說明的是，需要預裝的操作系統和軟件包并不是 TSAM 的默認功能，需要自行基于 TSAM 開發實現自定義。

　　圖 3. 輸入測試環境的相關參數

　　確認后，TSAM 就會自動生成所需的虛機。系統自動發郵件告知測試員該虛機的用戶認證信息。至此，我們完成了通過 TSAM 實現自動部署虛擬機和預裝軟件包的階段。下個階段就是使用 Build Forge 平臺部署要測試的產品。

　　登錄 RBF 系統，選擇庫 CLM-E2EProductDeploymentWithWASAndDB2，如圖 4，該庫實現 CLM 產品在 DB2 和 WAS 系統上的安裝，測試員只需要輸入剛剛生成的虛機的主機名、密碼，并選擇需要安裝的 CLM 的版本號或者開發階段的 build 號，選擇虛機生成過程中根據主機名在 BF 系統中自動生成的 selector，系統就可以自動開始執行庫中的各個步驟：安裝 DB2, 安裝 WAS，安裝 CLM，并完成安裝后的配置工作，包括 LDAP 配置等。

　　圖 4. 部署待測試產品

　　圖 4 大圖

　　性能測試往往會涉及不同的平臺，只要開發適合測試需求的 RBF 腳本，就會實現測試環境部署的自動化。由于 Agile 開發的測試周期短、產品版本推出快，這個步驟的自動化可以大大節約測試人員用于測試環境部署的時間。

　　回頁首性能測試執行

　　CLM 產品的測試使用測試工具 Rational Performance Tester RPT)，但又不僅僅是 RPT 測試或調度的運行。它包括測試環境準備、測試運行、測試結果搜集和測試結果分析。開始測試前，測試人員要將測試數據恢復到一個符合測試要求的“干凈”的狀態;然后，啟動數據庫服務器、應用服務器，打開性能監視工具，啟動 RPT 中測試的執行，等到執行結束后，要關閉服務器并搜集日志。如果測試環境是個集群系統，這些工作需要登錄到不同的機器上執行，不但耗時而且會容易出錯。而一旦出錯，測試者就不得不解決出現的問題并將待測試的系統恢復到測試前的狀態或者正常的狀態。在性能測試中，一個測試場景通常需要在不同用戶負載和數據負載下執行，以尋找性能瓶頸，或和前一個階段的性能數據進行比較。而每種負載的測試需要執行多遍以保證測試結果的穩定性。所以，性能測試的工作量可見一斑。通過對不同項目的性能測試員的調查發現，測試執行要占整個測試工作量的 50% 以上。如果這個過程能夠實現自動化、標準化、流程化，測試人員會能節約大量的時間以將精力用于性能問題的分析和解決上，減少人為操作的失誤。

　　我們開發了 RBF 項目 Run Performance Test 來自動化一個單次的性能測試執行，步驟 2 到 8 為測試準備階段，其中，第 2～3 步關閉應用以便于后續恢復數據的操作，第 4～5 步恢復并重啟數據庫，第 6～7 步恢復產品在本地文件系統中的信息，第 8 步啟動應用服務器;第 10～11 步為測試執行階段，第 10 步開啟服務器性能監視工具，第 11 步用命令行方式啟動 RPT 中的測試調度;從第 12 步開始測試運行結束，第 12 步關閉性能監視工具，第 13 步關閉應用服務器，第 14 步搜集測試過程中產生的 RPT 性能報告及服務器日志以便于性能分析，見圖 5。

　　圖 5. Run Performance Test 項目

　　如前所述，性能測試經常需要在不同負載下重復某個 RPT 調度的執行或者重復多次同樣的測試運行取得穩定的結果，為此，我們開發了個 Back to Back Runs 項目來組織整個測試的執行。見圖 6，每個步驟代表一個單次的性能測試，需要指定的是要執行哪個 RPT 的調度、要怎樣監控服務器的性能、要加載的用戶數和數據量等。這些每次測試中不同的部分可以作為 RBF 中的環境變量，如圖 7 所示，這樣，在每步中調用項目 Run Performance Test 就可以實現測試調度的連續運行了，圖 7 的例子中，我們調用三次同樣的運行來獲得最穩定的測試結果。至此，性能測試就可以實現不加干涉的自動化執行，即使是在非工作時間。

原文轉自：http://www.kjueaiud.com