5--性能測試報告(模板)

1、迦試時代T e 卜，芒 e lh版權所有測試時代（T北京慧靈科技有限公司XXX系統(tǒng)性能測試報告文檔編號:編 寫:批 準:文檔名稱: 審 核: 批準日期:北京慧靈科技有限公司http:www.testage cn第2頁共16頁迦試時代T e 卜，芒 e lh版權所有測試時代（T北京慧靈科技有限公司第3頁共16頁迦試時代T e 卜，芒 e lh第#頁共16頁迦試時代T e 卜，芒 e lh1前言32被測系統(tǒng)定義 32.1功能簡介32.2性能測試指標43系統(tǒng)結構及流程 43.1系統(tǒng)總體結構 43.2功能模塊43.3業(yè)務流程53.4關鍵點描述63.5性能測試環(huán)境 64性能測試64.1性能測試概述74.

2、2測試目的74.3測試方法及測試用例 74.4測試指標及期望 84.5測試數(shù)據(jù)準備 104.6運行狀況記錄 105測試過程及結果描述 105.1測試描述115.2測試場景115.3測試結果114測試分析和結論 16第#頁共16頁迦試時代版權所有測試時代（T北京慧靈科技有限公司丄 、F亠一1刖言目前，XXXX的XXXXXXXX 核心業(yè)務系統(tǒng)（以下簡稱新業(yè)務系統(tǒng)）已先后在XXXX、成功上線，從而公司的XXXX信息管理逐步走上了集中管控的道路。后續(xù)， xxx等34家分公司的XXXX信息也將分布進入業(yè)務系統(tǒng)，從而將會勢必出現(xiàn)新業(yè)務系統(tǒng)中信 息大量增長的態(tài)勢。隨著新業(yè)務系統(tǒng)在生產(chǎn)狀態(tài)下日趨穩(wěn)定、成熟，系

3、統(tǒng)的性能問題也逐步成為了我們關注的焦點：XXXX大數(shù)據(jù)量的“沖擊”，在XXXX信息進入時，系統(tǒng)能穩(wěn)定在什么樣的性 能水平，面臨公司業(yè)務沖刺時，系統(tǒng)能否經(jīng)受住“考驗”，這些問題需要通過一個完整的性能測試來給出答案。本性能測試規(guī)劃書即是基于上述考慮，參考科學的性能測試方法而撰寫的，用以指導即將進行的 XXXXXXXX 核心業(yè)務系統(tǒng)的性能測試。2被測系統(tǒng)定義xxxx業(yè)務系統(tǒng)作為本次測試的被測系統(tǒng)（注：以下所有針對被測系統(tǒng)地描述均為針對XXXXXXXX 核心業(yè)務系統(tǒng)進行的），該業(yè)務系統(tǒng)的主要功能包括：xxxxx在本次測試中，將針對上述的功能進行壓力測試，檢查并評估在模擬環(huán)境中，系統(tǒng)對 負載的承受能力，

4、在不同的用戶連接情況下，系統(tǒng)地吞吐能力和響應能力，以及在預計的 數(shù)據(jù)容量中，系統(tǒng)能夠容忍的最大用戶數(shù)，2.1功能簡介xxxxxx主要功能如下：xxxxxxxx版權所有測試時代（T北京慧靈科技有限公司2.2性能測試指標本次測試是針對XXXXXXXX 核心業(yè)務系統(tǒng)的性能特征和系統(tǒng)的性能調優(yōu)而進行的， 主要需要獲得如下的測試指標。1、系統(tǒng)的響應能力：即在各種負載壓力情況下，系統(tǒng)的響應時間，也就是從客戶端交 易發(fā)起，到服務器端交易應答返回所需要的時間，包括網(wǎng)絡傳輸時間和服務器處理時間。2、應用系統(tǒng)的吞吐率：即應用系統(tǒng)在單位時間內完成的交易量，也就是在單位時間 內，應用系統(tǒng)針對不同的負載壓力，所能完成的

5、交易數(shù)量。3、應用系統(tǒng)的負載能力：即系統(tǒng)所能容忍的最大用戶數(shù)量，也就是在正常的響應時間中，系統(tǒng)能夠支持的最多的客戶端的數(shù)量。3系統(tǒng)結構及流程xxxx業(yè)務系統(tǒng)在實際生產(chǎn)中的體系結構跟本次性能測試所采用的體系結構是一樣的，交易流程也完全一致的。不過，由于硬件條件的限制，本次性能測試的硬件平臺跟實際生 產(chǎn)環(huán)境略有不同。3.1系統(tǒng)總體結構描述本系統(tǒng)的總體結構，包括：硬件組織體系結構、網(wǎng)絡組織體系結構、軟件組織體系結構和功能模塊的組織體系結構。3.2功能模塊本次性能測試中各類交易都是由若干功能模塊組成的，每個交易都根據(jù)其執(zhí)行特點分成了若干操作步驟，每個步驟就是一個功能點（即功能模塊），在xxx業(yè)務系統(tǒng)中

6、，各種交易及其包含的功能模塊關系如下：1. xxx2. xxxx3. xxxx本次壓力測試主要設計的功能模塊以及所屬的路徑如下表名稱所屬交易路徑版權所有測試時代（T北京慧靈科技有限公司3.3業(yè)務流程本次性能測試中，選擇的各類交易的業(yè)務流程如下:1. xxxxxx2. xxxxxxx3. xxxxxx :4. xxx :5. xxxxx6. xxxx查詢交易的業(yè)務流程只是單一步驟的，即：輸入查詢條件后獲取查詢結果，因此在本 次性能測試中只作為一個事物處理，交易流程圖略。版權所有測試時代（T北京慧靈科技有限公司3.4關鍵點描述本次性能測試的關鍵點，就是查看xxxx業(yè)務系統(tǒng)在并發(fā)壓力下的表現(xiàn)，即：支

7、持的并發(fā)用戶數(shù)目和并發(fā)用戶發(fā)送頻率，以及在較大壓力下，系統(tǒng)的交易處理能力，并找出各類 交易的性能瓶頸。3.5性能測試環(huán)境本次性能測試環(huán)境與真實運行環(huán)境基本一致，都運行在同樣的硬件和網(wǎng)絡環(huán)境中，數(shù) 據(jù)庫是真實環(huán)境數(shù)據(jù)庫的一個復制（或縮?。鞠到y(tǒng)采用標準的 CS結構，客戶端都是通過瀏覽器訪問應用系統(tǒng)。其中具體的硬件和網(wǎng)絡環(huán)境如下：服務器設備：IBM 570 （ DBserver）， IBM 690 （ APserver）操作系統(tǒng)：AIX網(wǎng)絡環(huán)境：LAN （ 10M）數(shù)據(jù)庫：Oracle客戶端：PC （ Windows）網(wǎng)絡拓撲和結構圖如下：4性能測試從廣泛意義上講性能測試包括：壓力測試、穩(wěn)定性測

8、試、負載能力測試和可擴展性測試 等。在不同應用系統(tǒng)的性能測試中，需要根據(jù)應用系統(tǒng)的特點和測試目的的不同來選擇具 體的測試方案，本次 XXXXXXXX 核心業(yè)務系統(tǒng)的性能測試主要是采用通常的壓力測試模 式來執(zhí)行的，即：逐步增加壓力，查看應用系統(tǒng)在各種壓力狀況小的性能表現(xiàn)。在性能測試中，壓力測試主要是為了獲取系統(tǒng)在較大壓力狀況下的性能表現(xiàn)而設計并 實現(xiàn)的，壓力測試主要是獲取系統(tǒng)的性能瓶頸和系統(tǒng)的最大吞吐率。版權所有測試時代（T北京慧靈科技有限公司4.1性能測試概述本次壓力測試是指針對現(xiàn)行的XXX核心業(yè)務系統(tǒng)的聯(lián)機交易處理能力的測試，檢驗系統(tǒng)的吞吐率。本系統(tǒng)的壓力測試主要是針對XXXXX，檢查在日間

9、交易高峰時期，并發(fā)用戶數(shù)較多的時候的處理能力等等。4.2測試目的壓力測試的目的就是檢驗系統(tǒng)的最大吞吐量，檢驗現(xiàn)行的XXXX業(yè)務系統(tǒng)在各種壓力交易量下的運行狀況，檢驗系統(tǒng)地運行瓶頸，獲取系統(tǒng)的處理能力等等。本次針對XXXX核心業(yè)務系統(tǒng)所進行的壓力測試的測試目的為：給出XXXX系統(tǒng)當前的性能狀況定位新業(yè)務系統(tǒng)性能瓶頸或潛在性能瓶頸總結一套合理的、可操作的、適合公司現(xiàn)實情況的性能測試方案，為后續(xù)的性能 測試工作提供基本思路。4.3測試方法及測試用例使用性能測試軟件 LoadRunner,對現(xiàn)行的xxxx業(yè)務系統(tǒng)進行腳本錄制、測試回放、逐步加壓和跟蹤記錄。測試過程中，由LoadRunner的管理平臺調

10、用各臺測試前臺，發(fā)起各種組合的交易請求，并跟蹤記錄服務器端的運行情況和返回給客戶端的運行結果。使用的測試用例包括：聯(lián)機處理交易和查詢交易，其中聯(lián)機交易測試試用的交易包括: XXXX 查詢類交易包括：XXXX測試用例列表包括:交易種類案例一案例二案例三案例四30%40%25%10%10%10%25%0%20%10%15%0%20%20%15%10%30%20%20%80%版權所有測試時代（T北京慧靈科技有限公司本次測試將依照如下場景進行測試：、用戶數(shù) 功能模塊業(yè)務操作交易配比（%）20040070010000255111465620針對每個測試案例，都將采用逐步加壓和瞬間加壓兩種客戶端連接方式進

11、行，查看服 務器端在客戶端的連接數(shù)量變化過程中對應的處理能力，測試運行安排如下：每隔2秒增加1個用戶連接，最多增加到 200個用戶，查看并記錄運行情況每隔2秒增加2個用戶連接，最多增加到 200個用戶，查看并記錄運行情況 一次性連接10個用戶，查看記錄運行情況 一次性連接100個用戶，查看記錄運行情況4.4測試指標及期望在本次性能測試中，各類測試指標包括測試中應該達到的某些性能指標，這些性能指 標均是來自應用系統(tǒng)設計開發(fā)時遵循的業(yè)務需求，當某個測試的某一類指標已經(jīng)超出了業(yè) 務需求的要求范圍，則測試已經(jīng)達到目的，即可終止壓力測試。應用軟件級別的測試指標：1）聯(lián)機交易類的執(zhí)行情況交易的平均響應時間

12、（期望值： <15s）版權所有測試時代（T北京慧靈科技有限公司交易的最大響應時間（期望值：<30s）平均每秒處理交易數(shù)量（分別記錄單位時間內成功、失敗和停止的交易數(shù)量）交易成功率（期望值：>95%）不同并發(fā)用戶數(shù)的狀況下的上述記錄值2）測試結果分析情況單筆記錄的處理時間（期望值：<15s）單位時間內的處理交易筆數(shù)（期望值：>10個）某個時間段內的交易處理數(shù)量單筆能處理的最大數(shù)據(jù)量在每個交易處理中最大（最耗時）的模塊在不同數(shù)量的測試數(shù)據(jù)基礎上的上述記錄值網(wǎng)絡級別的測試指標：吞吐量：單位時間內網(wǎng)絡傳輸數(shù)據(jù)量沖突率：在以太網(wǎng)上監(jiān)測到的每秒沖突數(shù)操作系統(tǒng)級別的測試指標：進

13、程/線程交換率：進程和線程之間每秒交換次數(shù)CPU利用率：即CPU占用率（）系統(tǒng)CPU利用率：系統(tǒng)的 CPU占用率（）用戶CPU利用率：用戶模式下的 CPU占用率（）磁盤交換率：磁盤交換速率中斷速率：CPU每秒處理的中斷數(shù)讀入內存頁速率：物理內存中每秒讀入內存頁的數(shù)目寫出內存頁速率：每秒從物理內存中寫到頁文件中的內存頁數(shù)目或者從物理內存中刪掉的內存頁數(shù)目內存頁交換速率：每秒寫入內存頁和從物理內存中讀出頁的個數(shù)進程入交換率：交換區(qū)輸入的進程數(shù)目進程出交換率：交換區(qū)輸出的進程數(shù)目版權所有測試時代（T北京慧靈科技有限公司數(shù)據(jù)庫級別的測試指標：數(shù)據(jù)庫的并發(fā)連接數(shù)：客戶端的最大連接數(shù)數(shù)據(jù)庫鎖資源的使用數(shù)量

14、4.5測試數(shù)據(jù)準備案例數(shù)據(jù)：滿負荷壓力根據(jù)測試系統(tǒng)的硬件條件，選擇滿負荷的壓力，在系統(tǒng)的資源使用基本維持在90%左右的狀況下，測試 xxx核心業(yè)務系統(tǒng)的處理能力。數(shù)據(jù)準備工作包括：1. xxxxx4.6運行狀況記錄記錄可擴展性測試中的測試結果及其系統(tǒng)的運行狀況。除了記錄測試指標以外，應該 結合測試實時記錄系統(tǒng)各個層次的資源和參數(shù)。主要包括：硬件環(huán)境資源服務器操作系統(tǒng)參數(shù)網(wǎng)絡相關參數(shù)數(shù)據(jù)庫相關參數(shù)：具體數(shù)據(jù)庫參數(shù)有所不同，結合各個數(shù)據(jù)庫獨有的特點記錄5測試過程及結果描述xxxx務系統(tǒng)的性能測試共計執(zhí)行了2次，兩次執(zhí)行的腳本流程作了調整，其他的環(huán)境和數(shù)據(jù)都一樣。在測試數(shù)據(jù)準備完備以后，第一次測試中

15、，操作流程為每次交易都執(zhí)行用戶 登錄操作，第二次測試中，操作流程為先進行用戶登錄，然后每次交易都不再執(zhí)行用戶登 錄。版權所有測試時代（T北京慧靈科技有限公司5.1測試描述兩次測試都是在12月22日凌晨進行的。第一次測試執(zhí)行了 30分鐘左右，執(zhí)行腳本都是采用每次交易都執(zhí)行登錄操作，測試過 程中，交易的執(zhí)行速度隨著測試的進行，越來越慢，交易的響應時間越來越長，交易出錯（超時）情況也越來越嚴重，交易在執(zhí)行到 30分鐘左右，用戶登錄交易開始大量失?。ǔ?時）并導致后續(xù)的交易都無法完成，于是終止本次測試。第二次測試執(zhí)行了 50分鐘左右，在第一次測試的基礎上，調整交易流程，讓每次交易 都只登錄一次，然后順

16、序執(zhí)行交易邏輯。測試開始初期，交易的響應時間隨著交易并發(fā)量 的增加而快速增加，在測試執(zhí)行了10分鐘左右，所有的用戶登錄操作都基本完成，此后交易響應時間開始減少，并比較平穩(wěn)的執(zhí)行，絕大部分交易執(zhí)行比較平穩(wěn)成功率也很高，除 了兩個交易：xxx（Audit_Transaction）和 xxx（ClaimRegister_Transaction），這兩個交易的執(zhí)行 速度特別慢，交易相應時間一直都維持在190秒左右和160秒左右，這兩個交易超時現(xiàn)象嚴重，交易成功率很低，很多交易都因為超時而失敗。5.2測試場景測試中，使用逐步加壓的模式，采用：每隔2秒啟動1個并發(fā)用戶（Vuser）的方式，即：每隔1秒，啟

17、動1個Vuser，在7分鐘左右啟動所有的 Vuser（ 200 個），執(zhí)行登錄，并 根據(jù)設置的時間間隔發(fā)起交易。這次測試都部署在如下的場景中。運行的腳本部署在 3臺PC機，主要目的就是檢查在較大壓力的情況下，xxxxx心業(yè)務系統(tǒng)的性能表現(xiàn)。選擇了 2臺PC,每臺PC機部署了 70個左右并發(fā)用戶，選擇1臺PC，部署60個左右的并發(fā)用戶，并運行LoadRunner的控制器（Controller）5.3測試結果兩次測試AP服務器主機上的 CPU利用率如下：第13頁共16頁版權所有測試時代(T北京慧靈科技有限公司CPU Total APP4100806040200廠 User% 廠 Sys% Wait

18、%2U- 303 - 3or3OD. 305. 390- 30QI- 30Q2- 3003 - 3第14頁共16頁Time of Day可以看出在兩次測試執(zhí)行中第一次(1:52 -2:20)測試過程中 CPU的利用率都幾乎達到了 100%，第二次測試中(2:45- 4:00) CPU的利用率也達到了 95%以上。兩次測試在數(shù)據(jù)庫(Oracle)服務器上主機上的 CPU利用率如下:CPU Total REQDB1廠 User% 廠 Sys% Wait%3D. 300- 32I-340- 314-3H0. 3OI. 391- 392 - 393 - 3oeo- 3Time of Day可以看出兩次

19、測試執(zhí)行中第一次(1:52 -2:20)測試過程中CPU的利用率很低，第二次測試中(2:45-4:00)CPU的利用率較高也達到了75%以上，但兩次測試的 CPU的10等待時間卻都比較高，IO和CPU利用率對照表如下：第#頁共16頁北京慧靈科技有限公司版權所有測試時代(T迦試時代T"芒卜 6，芒 a l i t IhREQDB1SLeLX ksboo o oo o 0 5 0 4 3 3oo o oo o 5 0 5 2 2 1oo oo o15 0CPU% 10/secoeo- 3 ow3 93 - 392 - 391- 3ol. 3no. 3is- 314- 340- 302 -

20、 321- 300- 33U-. 3 nu o o o o o 0 8 6 4 2%SVS.LSU第15頁共16頁Time of Day可以看出兩次測試執(zhí)行中第一次( 1:52 -2:20)測試過程中CPU的10等待率較低，因 為大多數(shù)的交易都是用戶登錄，都壓在 AP服務器上了，第二次測試中(2:45-4:00) CPU 的IO第一次測試第一次測試使用了 200個并發(fā)用戶，并發(fā)用戶的啟動信息如下：各類交易的交易相應時間(秒)Color Scale交易名稱最小平均最大1AutoUW_Tra nsactio n0.023.73387.8711Con firm_Tra nsactio n210.20

21、3210.203210.2031CTDetail_Tra nsacti on105.878151.032199.4771EdorNosca nApp In put_Tr an sacti on60.704153.425259.2341Gen eralQuery_Tra nsact ion0.06713.62339.09431In dividualQuery_Tra ns actio n0.78128.04264.9841Issue_Tra nsact ion5.14530.660.2218.531109.639210.74611.2818.55315.47410.09319.46959.271

22、各類交易的平均響應時間圖:第#頁共16頁測試肘代版權所有 測試時代（T北京慧靈科技有限公司22020018016014012010060eo40240260-Tvnsaction Re&pioim Time Under Lo勒I20401S060 100 120Number of Vusers第16頁共16頁可以看出隨著測試的進行，交易相應時間逐漸增大，最終導致交易超時而失敗。第二次測試第二次測試調整了交易處理邏輯，大大減少了用戶登錄的操作數(shù)目，每個用戶只執(zhí)行一次用戶登錄，然后執(zhí)行對應的交易處理，交易過程中不再執(zhí)行用戶登錄操作。運行的并發(fā)用戶數(shù)目如下圖：在用戶登錄過程中，交易的平均響應

23、時間如下圖：第17頁共16頁第#頁共16頁020406000' 100 120Number of Vusers140ISO100200TMnsctjon Response Tinie Under loail(spuclLJwtf)】 -E-H swuodw血tt第#頁共16頁迦試時代版權所有測試時代（T北京慧靈科技有限公司從圖中可以看出，隨著并發(fā)用戶數(shù)量的不斷增加，所有的交易的平均響應時間都在加大，直到并發(fā)用戶數(shù)不再增加，這時候所有的交易相應時間下降到一定的數(shù)值，并一直穩(wěn)定在這個數(shù)值左右。在第二次測試中，各類交易的平均響應時間如下表：（單位：秒）Response im電20D-19018017Q160140-1301109Q-8070SSl4000:05O0：1O00-15 0tt2O 00:2500.3000:350O.4U00:4500:5000-5501:0001:05Ehpsed scenario limeE-H ®WLI udwWHOL>E®a><Colo