性能測試詳細測試方案 前言

平臺XX項目系統已經成功發布，依據項目的規劃，未來勢必會出現業務系統中信息大量增長的態勢。

隨著業務系統在生產狀態下日趨穩定、成熟，系統的性能問題也逐步成為了我們關注的焦點：每天大數據量的“沖擊”，系統能穩定在什么樣的性能水平，面臨行業公司業務增加時，系統能否經受住“考驗”，這些問題需要通過一個完整的性能測試來給出答案。

1第一章XXX系統性能測試概述

1.1 被測系統定義

XXX系統作為本次測試的被測系統（注：以下所有針對被測系統地描述均為針對XXX系統進行的），XXX系統是由平臺開發的一款物流應用軟件，后臺應用了數據庫，該系統包括主要功能有:XXX等。在該系統中都存在多用戶操作，大數據量操作以及日報、周報、年報的統計，在本次測試中，將針對這些多用戶操作，大數據量的查詢、統計功能進行如預期性能、用戶并發、大數據量、疲勞強度和負載等方面的性能測試，檢查并評估在模擬環境中，系統對負載的承受能力，在不同的用戶連接情況下，系統的吞吐能力和響應能力，以及在預計的數據容量中，系統能夠容忍的最大用戶數。

1.1.1 功能簡介

主要功能上面已提到，由于本文檔主要專注于性能在這里功能不再作為重點講述。

1.1.2 性能測試指標

本次測試是針對XXX系統進行的全面性能測試，主要需要獲得如下的測試指標。

1、應用系統的負載能力：即系統所能容忍的最大用戶數量，也就是在正常的響應時間中，系統能夠支持的最多的客戶端的數量。

2、應用系統的吞吐量：即在一次事務中網絡內完成的數據量的總和，吞吐量指標反映的是服務器承受的壓力。事務是用戶某一步或幾步操作的集合。

3、應用系統的吞吐率：即應用系統在單位時間內完成的數據量，也就是在單位時間內，應用系統針對不同的負載壓力，所能完成的數據量。

4、TPS：每秒鐘系統能夠處理事務或交易的數量，它是衡量系統處理能力的重要指標。

5、點擊率：每秒鐘用戶向服務器提交的HTTP請求數。

5、系統的響應能力：即在各種負載壓力情況下，系統的響應時間，也就是從客戶端請求發起，到服務器端應答返回所需要的時間，包括網絡傳輸時間和服務器處理時間。

6、應用系統的可靠性：即在連續工作時間狀態下，系統能夠正常運行的時間，即在連續工作時間段內沒有出錯信息。

1.2 系統結構與流程

XXX系統在實際生產中的體系結構跟本次性能測試所采用的體系結構是一樣的，交易流程也完全一致的。不過，由于硬件條件的限制，本次性能測試的硬件平臺跟實際生產環境略有不同。

1.2.1 系統總體結構

描述本系統的總體結構，包括：硬件組織體系結構、網絡組織體系結構、軟件組織體系結構和功能模塊的組織體系結構。

1.2.2 功能模塊

本次性能測試中各類操作都是由若干功能模塊組成的，每個功能都根據其執行特點分成了若干操作步驟，每個步驟就是一個功能點（即功能模塊），本次性能測試主要涉及的功能模塊以及所屬操作如下表

步驟

說明

備注：Action、平均響應時間（S）

打開主界面

Action：訪問首頁(FWSY)；5

輸入用戶名密碼（需進行參數化），登錄系統，進入首頁

Action：登陸(DL)；5

點擊“我的通知”標簽，進入通知列表頁面

Action：進入通知列表(JRTZLB)；5

在我的通知上點擊已收通知標題鏈接，查看通知（重要通知）

Action：查看通知(CKTZ)；5

在我的通知上點擊已收通知的“回復”鏈接，進入回復界面

Action：進入回復界面(JRHFJM)；5

在通知回復界面上填寫回復內容并提交

Action：回復通知(HFTZ)；5

1.2.3 關鍵點描述（KP）

本次性能測試的關鍵點，就是查看XXX系統在不同用戶數量（并發）壓力下的表現和大數據量操作時系統的性能狀態，即：支持的并發用戶數目和并發用戶發送頻率，以及在較大壓力下，系統的處理能力以及CPU、數據庫I/O和內存的使用情況，并找出相應的性能瓶頸。

1.3 性能測試環境

本次性能測試環境與真實運行環境硬件和網絡環境有所不同，是真實環境的縮小，數據庫是真實環境數據庫的一個復制（或縮?。鞠到y采用標準的CS結構，客戶端通過前臺安裝訪問應用系統。

其中具體的硬件和網絡環境如下：

中間件服務器：

操作系統：/Linux

網絡環境： LAN（10M）

數據庫：Oracle 11g RAC

客戶端： PC（Windows）

網絡拓撲和結構圖如下：

2第二章 性能測試

從廣泛意義上講性能測試包括：預期性能測試、用戶并發測試、大數據量測試、疲勞強度測試、負載能力測試等。在不同應用系統的性能測試中，需要根據應用系統的特點和測試目的的不同來選擇具體的測試方案，本次XXX系統的性能測試主要是采用通常的壓力測試模式來執行的，即：逐步增加壓力，查看應用系統在各種壓力狀況下的性能表現。

在本次性能測試中，將使用性能測試工具.0對被測試項目的各模塊進行監控，判斷XX系統各模塊的性能表現，并幫助項目人員分析系統各個操作的性能瓶頸點。

2.1 預期性能測試

2.1.1 預期性能概述

通過模擬生產運行的業務壓力量和使用場景組合，測試系統的性能是否滿足生產性能要求。通俗地說，這種方法就是要在特定的運行條件下驗證系統的能力狀態。

2.1.2 測試特點

1、主要目的是驗證系統是否有系統宣稱具有的能力。

2、要事先了解被測試系統經典場景，并具有確定的性能目標。

3、要求在已經確定的環境下運行。

2.2 用戶并發測試

2.2.1 并發測試概述

并發測試方法通過模擬用戶并發訪問，測試多用戶并發訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或其者他性能問題。

2.2.2 測試目的

1、主要目的是發現系統中可能隱藏的并發訪問時的問題。

2、主要關注系統可能存在的并發問題，例如系統中的內存泄漏、線程鎖和資源爭用方面的問題。

3、可以在開發的各個階段使用需要相關的測試工具的配合和支持。

2.3 大數據量測試

2.3.1 大數據量測試概述

測試對象處理大量的數據，以確定是否達到了將使軟件發生故障的極限。大數據量測試還將確定測試對象在給定時間內能夠持續處理的最大負載或工作量。

2.3.2 測試目的

1、主要目的是確定軟件發生故障的極限。

2、確定測試對象在給定時間內能夠持續處理的最大負載或工作量。

3、可以在開發的各個階段使用需要相關的測試工具的配合和支持。

2.4 疲勞強度測試

2.4.1疲勞強度測試概述

即壓力測試，測試系統在一定飽和狀態下，例如cpu、內存在飽和使用情況下，系統能夠處理的會話能力，以及系統是否會出現錯誤。

2.4.1測試目的

1、主要目的是檢查系統處于壓力性能下時，應用的表現。

2、一般通過模擬負載等方法，使得系統的資源使用達到較高的水平。

3、一般用于測試系統的穩定性。

2.5 負載能力測試

2.5.1 負載測試概述

通過在被測系統上不斷加壓，直到性能指標達到極限，例如“響應時間”超過預定指標或都某種資源已經達到飽和狀態。

2.5.2 測試目的

1、主要目的是找到系統處理能力的極限。

2、需要在給定的測試環境下進行，通常也需要考慮被測試系統的業務壓力量和典型場景、使得測試結果具有業務上的意義。

3、一般用來了解系統的性能容量，或是配合性能調優來使用。

2.6 測試方法及測試用例

詳情參見《XX項目測試用例.doc》的“性能測試”章節

2.7 測試指標及期望

在本次性能測試中，各類測試指標包括測試中應該達到的某些性能指標，這些性能指標均是來自應用系統設計開發時遵循的業務需求，當某個測試的某一類指標已經超出了業務需求的要求范圍，則測試已經達到目的，即可終止性能測試。

2.7.1.1 應用軟件級別的測試指標：

üCPU的利用率小于40%

ü內存占用小于80%

ü queue length小于2

ü time小于 1s

ü吞吐量大于90%

ü業務執行的平均響應時間（期望值：

ü不同并發用戶數的狀況下的記錄上述值

2.7.1.2 網絡級別的測試指標：

ü吞吐量：單位時間內網絡傳輸數據量

ü沖突率：在以太網上監測到的每秒沖突數

2.7.1.3 操作系統級別的測試指標：

ü進程/線程交換率：進程和線程之間每秒交換次數

üCPU利用率：即CPU占用率（％）

ü系統CPU利用率：系統的CPU占用率（％）

ü用戶CPU利用率：用戶模式下的CPU占用率（％）

ü磁盤交換率：磁盤交換速率

ü中斷速率：CPU每秒處理的中斷數

2.7.1.4 數據庫級別的測試指標：

ü數據庫I/O的流量大小

ü數據庫鎖資源的使用數量

ü數據庫的并發連接數：客戶端的最大連接數

2.7.2 測試數據準備

2.7.2.1 案例數據：滿負荷壓力

根據測試系統的硬件條件，選擇滿負荷的壓力，在系統的資源使用基本維持在90%左右的狀況下，測試天威寬帶業務管理系統的處理能力。

數據準備工作包括：

測試數據庫需具備與真實環境成一定比例或基本一致的數據

2.7.3 運行狀況記錄

記錄可擴展性測試中的測試結果及其系統的運行狀況。除了記錄測試指標以外，應該結合測試實時記錄系統各個層次的資源和參數。主要包括：

ü硬件環境資源

ü服務器操作系統參數

ü網絡相關參數

ü數據庫相關參數：具體數據庫參數有所不同，結合各個數據庫獨有的特點記錄

3 第三章測試過程及結果描述

3.1 測試描述

在測試數據準備完備以后，測試將進行。記錄每次測試的結果數據，分析測試結果對系統進行全面評估。

3.2 測試場景

示例：

步驟

說明

備注：Action、平均響應時間（S）

打開主界面

Action：訪問首頁(FWSY)；5

輸入用戶名密碼（需進行參數化），登錄系統，進入首頁

Action：登陸(DL)；5

點擊“我的通知”標簽，進入通知列表頁面

Action：進入通知列表(JRTZLB)；5

在我的通知上點擊已收通知標題鏈接，查看通知（重要通知）

Action：查看通知(CKTZ)；5

在我的通知上點擊已收通知的“回復”鏈接，進入回復界面

Action：進入回復界面(JRHFJM)；5

在通知回復界面上填寫回復內容并提交

Action：回復通知(HFTZ)；5

測試中，使用逐步加壓的模式，測試運行場景安排如下：

每隔2秒增加1個用戶連接，最多增加到100個用戶，查看并記錄運行情況

每隔2秒增加2個用戶連接，最多增加到200個用戶，查看并記錄運行情況

每隔2秒增加1個用戶連接，最多增加到300個用戶，查看并記錄運行情況

每隔3秒增加1個用戶連接，最多增加到400個用戶，查看并記錄運行情況

每個場景都包括：用戶登錄-業務操作-業務完成-退出系統，所有用例都按以上場景進行測試，由于pc性能限制，為了更準確模擬現場環境，將運行的所有腳本部署在終端上，主要目的就是檢查在不同的壓力的情況下，業務系統的性能表現。

3.3 測試結果標準

測試結束標準一般依據以下原則：

1.所有計劃的測試已經完成；

2.所有計劃收集的性能數據已經獲得；

3.所有性能瓶頸得到改善并達到設計要求。

執行每個場景時需要記錄以下相應的數據

1.APP服務器主機上的CPU利用率：

2.在數據庫（Oracle）服務器上主機上的CPU利用率：

3.IO和CPU利用率對照表如下：

4.APP服務器監控的網絡流量：

5.DB服務器上監控的網絡流量：

6.運行的并發用戶數目：

7.測試中完成各操作的平均響應時間：（單位：秒）

8.測試中每秒的點擊率如下：

9.交易的吞吐率（每秒處理數據量）：

4第四章 測試報告

在XXX系統的性能測試結束后，根據測試結果，將生成測試報告。

對應的文檔名稱如下：

ü《XX項目性能測試報告》