4/4性能測試報告案例(DOC)

具對測試過程中系統各點進行監控，每一次測試結束后工具自動采集測試結果并生成原始報告供分析使用。

Web1.Controller2.數據庫服務器

服務器

4.測試結果被搜集及保存起來供分析控制器

起到調度壓力測試并管理監控器

模擬大量的真實用戶生成壓力.

3.監控器實時捕獲系統的性能狀態

性能監控器

應用服務器虛擬用戶生成器

5.產生性能分析報告

被測系統

2）壓力測試實施基本流程：測試環境準備

系統性能壓力測試環境要求與生產系統的軟、硬件環境保持一致，并具有相同規模的業務數據，并保證軟件版本與生產環境保持一致。

壓力模型定義：

此次性能測試的用例選擇，按照海泰方圓提供的業務數據進行分析抽取，用例選取是性能測試壓力模型設計的首要任務。用例選取的原則是：

1)典型的交易和業務流程2)用戶操作使用頻繁3)對系統性能影響較大

4)性能測試壓力符合業務系統實際的實際交易發生比例

實際執行場景的設置盡量模擬實際業務進行，運行時長，操作間隔（思考時間），循環間隔，并發間隔，用戶加載和減壓時間根據系統基準測試結果進行判斷和設置。

測試數據準備：

測試數據要求盡量模擬真實業務數據，而且具有一定可重用性。能貫穿各相關系統，保

證業務流程的順暢正確。具體的數據類型和數據量需要根據選擇的交易類別或性能測試場景設置而定。

此外性能測試會產生大量的虛擬用戶，需要消耗大量的測試數據。其數量直接關乎測試結果。測試中所需的基本數據類型為：

系統用戶數據：登陸系統使用的用戶名-口令等，數量與虛擬用戶數一致。

業務數據：每個虛擬用戶模擬真實用戶進行操作時使用到的數據。

輔助數據：為保證業務操作的正常進行而設置的基本信息資料。

測試程序開發：

利用在歷史數據收集步驟中所獲得的典型用戶的系統訪問模式，做為測試程序開發的依據。該測試程序應該覆蓋典型用戶的系統訪問模式所涉及的操作。腳本的開發是利用

LoadRunnerVugen進行腳本錄制，開發，參數化，調試的過程。

測試執行：

測試準備階段完畢后，確保測試環境、測試程序、測試過程、測試數據，且均已驗證通過后，然后在指定的時間內可對系統施實性能測試，性能測試執行分為兩個階段：

1、性能基準測試：系統在輕負載環境下，模擬各業務的單用戶交易，評估當前系統的

性能表現，并作為后續壓力測試的性能比較基準；

2、單交易負載測試：

3、負載壓力測試：仿真現實，模擬大批量并發業務交易，評估系統在高負載情況下系

統的性能表現。

測試結果分析報告：

壓力測試結果經過確認有效后，將匯總壓力測試結果，形成最終的性能測試分析報告。3測試環境

3.1被測系統

3.1.1硬件環境

系統IP地址所在主機配置備注

應用服務器CPU：XeonMPX4600Win2003Server

幫助下，用戶可以以模擬上千萬用戶實施并發負載及實時性能監測的方式來確認和查找問題。LoadRunner能夠對整個企業架構進行測試，它通過模擬實際用戶的操作行為和實行實時性能監測，來幫助用戶更快的查找和發現問題。此外，LoadRunner能支持廣泛的協議和技術，可以為用戶的特殊環境提供特殊的解決方案。

本次測試采用的LoadRunner版本為。

4測試設計

4.1模擬用戶數

依據系統目前的業務量以及未來業務量增長，對當前系統分別按3000、4500、6000用戶進行壓力測試，以評估系統在不同壓力梯度情況下的性能表現。

4.2測試模型建立

此次性能測試的業務選擇，應覆蓋各性能關鍵業務，并通過海泰方圓、北京行所志雙方協商選取被測業務。根據協商選定如下業務進行性能測試：

開具發票

以此基礎上定義測試執行壓力模型：

在混合業務場景壓力梯度測試過程中，分別按3000、4500、6000用戶進行壓力測試，在各個壓力測試過程中保持測試場景和調度測試的完全一致，使結果具有很好的可比性。

壓力測試執行場景描述如下：

1、模擬用戶數：3000、4500、6000

2、Pacing：120秒；

3、當所有用戶加載完畢后連續運行15分鐘；

4、用戶調度策略：每1秒啟動30個虛擬用戶。

業務場景一

序號交易業務

配比

執行

時間

操作

間隔

1開具發票100%15分鐘120秒業務場景二

序號交易業務

配比

執行

時間

操作

間隔

1開具發票（無合同）85%

15分鐘120秒2開具發票（有合同）15%

說明：

按照以上場景設置，可估算出模擬用戶數與每小時業務量的對應關系如下：

模擬用戶數300045006000

每小時業務量90000135000180000

5測試結果分析

說明：術語解釋

（事務）－LoadRunner中定義，為一個流程中某個環節的稱謂，一個流程可稱為

一個大的事務，在這個大的交易中包含許多的小的事務。

響應時間－LoadRunner中衡量流程中各個事務性能的最佳手段，計算的是端到端

的時間，說的通俗一點，從點擊應用中的某個控件，到從數據庫返回數據到客戶端，整個過程都被計算在事務的響應時間內。

場景－LoadRunner中專門術語。它是所有測試資源包括測試腳本、運行設置、運

行用戶數等的集合。在這個場景中，可以定義并發用戶的數目，定義要運行的腳本，

或者說運行的流程類型。在一個場景中，可以是單個流程，也可以是多個流程的混

合。

虛擬用戶－LoadRunner中特定術語，為模擬現實中的實際用戶，測試軟件使用虛

擬用戶代替真實的用戶。

5.1業務場景一（無基礎數據）梯度壓力測試分析

5.1.1平均響應時間梯度對比

下圖是不同用戶數下各事務的平均響應時間隨用戶數變化的曲線：

5.3系統穩定性測試

在系統測試過程中，我們發現WebLogic的JVM可用內存逐漸減少，下圖是在WebLogic監控臺所監控到的情況：

為了驗證確認此現象，進行了4500用戶6個小時的測試，當測試執行到1小時左右，WebLogicJVM基本已無內存可用，如下圖所示：

被占用內存無法釋放，導致被測系統在長時間運行后響應時間明顯上升，處理能力明顯下降，如下圖所示：

分析：

用戶在登錄時，系統會自動生成一個session，并占用部分內存，而這個session的過期時間設置為2小時，按照用戶習慣分析，當用戶使用直接關閉IE窗口退出系統的方式退出，這個session是不釋放的，并繼續占用內存。測試過程中沒有做退出操作，導致大量用戶session不釋放。根據上圖顯示，40分鐘時性能開始下降，此時在線用戶數約為*60*40=90000。

解決方法：

開發人員修改程序，點擊重新登錄時清除session，并在測試過程中，完成開具發票操作后就點擊重新登錄。重新執行測試后，此現象消失。

5.4有、無合同場景對比測試

在測試過程中，用戶提出部分用戶需要在開具發票是選擇合同，因此設計以下場