性能測(cè)試報(bào)告(模板).doc

《性能測(cè)試報(bào)告(模板).doc》由會(huì)員分享，可在線閱讀，更多相關(guān)《性能測(cè)試報(bào)告(模板).doc（21頁珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、xxxxxxxxxx性能測(cè)試報(bào)告2018年12月23日目 錄1 前言11第一章XXXXXXXX核心業(yè)務(wù)系統(tǒng)性能測(cè)試概述11.1 被測(cè)系統(tǒng)定義11.1.1 功能簡(jiǎn)介11.1.2 性能測(cè)試指標(biāo)21.2 系統(tǒng)結(jié)構(gòu)及流程21.2.1 系統(tǒng)總體結(jié)構(gòu)21.2.2 功能模塊描述31.2.3 業(yè)務(wù)流程41.2.4 系統(tǒng)的關(guān)鍵點(diǎn)描述（KP）51.3 性能測(cè)試環(huán)境51.3.1 硬件及網(wǎng)絡(luò)環(huán)境51.3.2 系統(tǒng)裝配描述61.3.3 系統(tǒng)啟動(dòng)和管理62 第二章 性能測(cè)試62.1 壓力測(cè)試62.1.1 壓力測(cè)試概述72.1.2 測(cè)試目的72.1.3 測(cè)試方法及測(cè)試用例72.1.4 測(cè)試指標(biāo)及期望92.1.5 測(cè)試數(shù)據(jù)準(zhǔn)

2、備102.1.6 運(yùn)行狀況記錄113第三章 測(cè)試計(jì)劃及方案112.2 測(cè)試步驟122.2.1 被測(cè)系統(tǒng)調(diào)研122.2.2 測(cè)試環(huán)境的部署132.2.3 腳本的錄制和調(diào)試132.2.4 準(zhǔn)備測(cè)試場(chǎng)景142.2.5 準(zhǔn)備測(cè)試數(shù)據(jù)142.2.6 執(zhí)行性能測(cè)試142.2.7 生成測(cè)試報(bào)告152.3 測(cè)試時(shí)間進(jìn)度及人員安排152.3.1 人員安排153 第四章 測(cè)試報(bào)告16第 0 頁 共 21 頁1 前言目前，XXXX的XXXXXXXX核心業(yè)務(wù)系統(tǒng)（以下簡(jiǎn)稱新業(yè)務(wù)系統(tǒng)）已先后在XXXX、成功上線，從而公司的XXXX信息管理逐步走上了集中管控的道路。后續(xù)，xxx等34家分公司的XXXX信息也將分布進(jìn)入業(yè)務(wù)

3、系統(tǒng)，從而將會(huì)勢(shì)必出現(xiàn)新業(yè)務(wù)系統(tǒng)中信息大量增長(zhǎng)的態(tài)勢(shì)。隨著新業(yè)務(wù)系統(tǒng)在生產(chǎn)狀態(tài)下日趨穩(wěn)定、成熟，系統(tǒng)的性能問題也逐步成為了我們關(guān)注的焦點(diǎn)：XXXX大數(shù)據(jù)量的“沖擊”，在XXXX信息進(jìn)入時(shí)，系統(tǒng)能穩(wěn)定在什么樣的性能水平，面臨公司業(yè)務(wù)沖刺時(shí)，系統(tǒng)能否經(jīng)受住“考驗(yàn)”，這些問題需要通過一個(gè)完整的性能測(cè)試來給出答案。本性能測(cè)試規(guī)劃書即是基于上述考慮，參考科學(xué)的性能測(cè)試方法而撰寫的，用以指導(dǎo)即將進(jìn)行的XXXXXXXX核心業(yè)務(wù)系統(tǒng)的性能測(cè)試。1第一章xxxx系統(tǒng)性能測(cè)試概述1.1 被測(cè)系統(tǒng)定義xxxx業(yè)務(wù)系統(tǒng)作為本次測(cè)試的被測(cè)系統(tǒng)（注：以下所有針對(duì)被測(cè)系統(tǒng)地描述均為針對(duì)XXXXXXXX核心業(yè)務(wù)系統(tǒng)進(jìn)行的），

4、該業(yè)務(wù)系統(tǒng)的主要功能包括：xxxxx在本次測(cè)試中，將針對(duì)上述的功能進(jìn)行壓力測(cè)試，檢查并評(píng)估在模擬環(huán)境中，系統(tǒng)對(duì)負(fù)載的承受能力，在不同的用戶連接情況下，系統(tǒng)地吞吐能力和響應(yīng)能力，以及在預(yù)計(jì)的數(shù)據(jù)容量中，系統(tǒng)能夠容忍的最大用戶數(shù)，1.1.1 功能簡(jiǎn)介xxxxxx主要功能如下： xxx xxxxx1.1.2 性能測(cè)試指標(biāo)本次測(cè)試是針對(duì)XXXXXXXX核心業(yè)務(wù)系統(tǒng)的性能特征和系統(tǒng)的性能調(diào)優(yōu)而進(jìn)行的，主要需要獲得如下的測(cè)試指標(biāo)。1、系統(tǒng)的響應(yīng)能力：即在各種負(fù)載壓力情況下，系統(tǒng)的響應(yīng)時(shí)間，也就是從客戶端交易發(fā)起，到服務(wù)器端交易應(yīng)答返回所需要的時(shí)間，包括網(wǎng)絡(luò)傳輸時(shí)間和服務(wù)器處理時(shí)間。2、應(yīng)用系統(tǒng)的吞吐率：即

5、應(yīng)用系統(tǒng)在單位時(shí)間內(nèi)完成的交易量，也就是在單位時(shí)間內(nèi)，應(yīng)用系統(tǒng)針對(duì)不同的負(fù)載壓力，所能完成的交易數(shù)量。3、應(yīng)用系統(tǒng)的負(fù)載能力：即系統(tǒng)所能容忍的最大用戶數(shù)量，也就是在正常的響應(yīng)時(shí)間中，系統(tǒng)能夠支持的最多的客戶端的數(shù)量。1.2 系統(tǒng)結(jié)構(gòu)及流程xxxx業(yè)務(wù)系統(tǒng)在實(shí)際生產(chǎn)中的體系結(jié)構(gòu)跟本次性能測(cè)試所采用的體系結(jié)構(gòu)是一樣的，交易流程也完全一致的。不過，由于硬件條件的限制，本次性能測(cè)試的硬件平臺(tái)跟實(shí)際生產(chǎn)環(huán)境略有不同。1.2.1 系統(tǒng)總體結(jié)構(gòu)描述本系統(tǒng)的總體結(jié)構(gòu)，包括：硬件組織體系結(jié)構(gòu)、網(wǎng)絡(luò)組織體系結(jié)構(gòu)、軟件組織體系結(jié)構(gòu)和功能模塊的組織體系結(jié)構(gòu)。 1.2.2 功能模塊本次性能測(cè)試中各類交易都是由若干功能模

6、塊組成的，每個(gè)交易都根據(jù)其執(zhí)行特點(diǎn)分成了若干操作步驟，每個(gè)步驟就是一個(gè)功能點(diǎn)（即功能模塊），在xxx業(yè)務(wù)系統(tǒng)中，各種交易及其包含的功能模塊關(guān)系如下：1 xxx2 xxxx3 xxxx本次壓力測(cè)試主要設(shè)計(jì)的功能模塊以及所屬的路徑如下表名稱所屬交易路徑1.2.3 業(yè)務(wù)流程本次性能測(cè)試中，選擇的各類交易的業(yè)務(wù)流程如下：1xxxxxx2xxxxxxx3xxxxxx：4xxx：5xxxxx6xxxx查詢交易的業(yè)務(wù)流程只是單一步驟的，即：輸入查詢條件后獲取查詢結(jié)果，因此在本次性能測(cè)試中只作為一個(gè)事物處理，交易流程圖略。1.2.4 關(guān)鍵點(diǎn)描述（KP）本次性能測(cè)試的關(guān)鍵點(diǎn)，就是查看xxxx業(yè)務(wù)系統(tǒng)在并發(fā)壓力下

7、的表現(xiàn)，即：支持的并發(fā)用戶數(shù)目和并發(fā)用戶發(fā)送頻率，以及在較大壓力下，系統(tǒng)的交易處理能力，并找出各類交易的性能瓶頸。1.3 性能測(cè)試環(huán)境本次性能測(cè)試環(huán)境與真實(shí)運(yùn)行環(huán)境基本一致，都運(yùn)行在同樣的硬件和網(wǎng)絡(luò)環(huán)境中，數(shù)據(jù)庫是真實(shí)環(huán)境數(shù)據(jù)庫的一個(gè)復(fù)制（或縮?。?，本系統(tǒng)采用標(biāo)準(zhǔn)的CS結(jié)構(gòu)，客戶端都是通過瀏覽器訪問應(yīng)用系統(tǒng)。 其中具體的硬件和網(wǎng)絡(luò)環(huán)境如下： 服務(wù)器設(shè)備：IBM 570（DBserver）， IBM 690（APserver） 操作系統(tǒng)： AIX 網(wǎng)絡(luò)環(huán)境： LAN（10M） 數(shù)據(jù)庫：Oracle 客戶端： PC （Windows ）網(wǎng)絡(luò)拓?fù)浜徒Y(jié)構(gòu)圖如下：2 第二章 性能測(cè)試從廣泛意義上講性能測(cè)

8、試包括：壓力測(cè)試、穩(wěn)定性測(cè)試、負(fù)載能力測(cè)試和可擴(kuò)展性測(cè)試等。在不同應(yīng)用系統(tǒng)的性能測(cè)試中，需要根據(jù)應(yīng)用系統(tǒng)的特點(diǎn)和測(cè)試目的的不同來選擇具體的測(cè)試方案，本次XXXXXXXX核心業(yè)務(wù)系統(tǒng)的性能測(cè)試主要是采用通常的壓力測(cè)試模式來執(zhí)行的，即：逐步增加壓力，查看應(yīng)用系統(tǒng)在各種壓力狀況小的性能表現(xiàn)。在本次性能測(cè)試中，也將使用美科利的新產(chǎn)品性能測(cè)試診斷工具（Diagnostic）對(duì)測(cè)試應(yīng)用的各層進(jìn)行監(jiān)控，判斷J2EE各層次的各類方法和類的調(diào)用使用時(shí)間和效率，并幫助開發(fā)人員分析J2EE應(yīng)用的各類交易的性能瓶頸點(diǎn)。2.1 壓力測(cè)試在性能測(cè)試中，壓力測(cè)試主要是為了獲取系統(tǒng)在較大壓力狀況下的性能表現(xiàn)而設(shè)計(jì)并實(shí)現(xiàn)的，壓

9、力測(cè)試主要是獲取系統(tǒng)的性能瓶頸和系統(tǒng)的最大吞吐率。2.1.1 壓力測(cè)試概述本次壓力測(cè)試是指針對(duì)現(xiàn)行的xxx核心業(yè)務(wù)系統(tǒng)的聯(lián)機(jī)交易處理能力的測(cè)試，檢驗(yàn)系統(tǒng)的吞吐率。本系統(tǒng)的壓力測(cè)試主要是針對(duì)xxxxx，檢查在日間交易高峰時(shí)期，并發(fā)用戶數(shù)較多的時(shí)候的處理能力等等。2.1.2 測(cè)試目的壓力測(cè)試的目的就是檢驗(yàn)系統(tǒng)的最大吞吐量，檢驗(yàn)現(xiàn)行的xxxx業(yè)務(wù)系統(tǒng)在各種壓力交易量下的運(yùn)行狀況，檢驗(yàn)系統(tǒng)地運(yùn)行瓶頸，獲取系統(tǒng)的處理能力等等。本次針對(duì)xxxx核心業(yè)務(wù)系統(tǒng)所進(jìn)行的壓力測(cè)試的測(cè)試目的為： 給出xxxx系統(tǒng)當(dāng)前的性能狀況 定位新業(yè)務(wù)系統(tǒng)性能瓶頸或潛在性能瓶頸 總結(jié)一套合理的、可操作的、適合公司現(xiàn)實(shí)情況的性能測(cè)

10、試方案，為后續(xù)的性能測(cè)試工作提供基本思路。2.1.3 測(cè)試方法及測(cè)試用例使用美科利公司（Mercury）的性能測(cè)試軟件LoadRunner，對(duì)現(xiàn)行的xxxx業(yè)務(wù)系統(tǒng)進(jìn)行腳本錄制、測(cè)試回放、逐步加壓和跟蹤記錄。測(cè)試過程中，由LoadRunner的管理平臺(tái)調(diào)用各臺(tái)測(cè)試前臺(tái)，發(fā)起各種組合的交易請(qǐng)求，并跟蹤記錄服務(wù)器端的運(yùn)行情況和返回給客戶端的運(yùn)行結(jié)果。使用的測(cè)試用例包括：聯(lián)機(jī)處理交易和查詢交易，其中聯(lián)機(jī)交易測(cè)試試用的交易包括：xxxx查詢類交易包括：xxxx測(cè)試用例列表包括：交易種類案例一案例二案例三案例四30%40%25%10%10%10%25%0%20%10%15%0%20%20%15%10%3

11、0%20%20%80%本次測(cè)試將依照如下場(chǎng)景進(jìn)行測(cè)試： 用戶數(shù)功能模塊業(yè)務(wù)操作交易配比（%)200400700100000000241017245102136527132747675112137535102137527142951725101934481122457811214285698140612244159511223855613264564204080141201針對(duì)每個(gè)測(cè)試案例，都將采用逐步加壓和瞬間加壓兩種客戶端連接方式進(jìn)行，查看服務(wù)器端在客戶端的連接數(shù)量變化過程中對(duì)應(yīng)的處理能力，測(cè)試運(yùn)行安排如下： 每隔2秒增加1個(gè)用戶連接，最多增加到200個(gè)用戶，查看并記錄運(yùn)行情況 每隔2秒增加

12、2個(gè)用戶連接，最多增加到200個(gè)用戶，查看并記錄運(yùn)行情況 一次性連接10個(gè)用戶，查看記錄運(yùn)行情況 一次性連接100個(gè)用戶，查看記錄運(yùn)行情況2.1.4 測(cè)試指標(biāo)及期望在本次性能測(cè)試中，各類測(cè)試指標(biāo)包括測(cè)試中應(yīng)該達(dá)到的某些性能指標(biāo)，這些性能指標(biāo)均是來自應(yīng)用系統(tǒng)設(shè)計(jì)開發(fā)時(shí)遵循的業(yè)務(wù)需求，當(dāng)某個(gè)測(cè)試的某一類指標(biāo)已經(jīng)超出了業(yè)務(wù)需求的要求范圍，則測(cè)試已經(jīng)達(dá)到目的，即可終止壓力測(cè)試。2.1.4.1 應(yīng)用軟件級(jí)別的測(cè)試指標(biāo)：1) 聯(lián)機(jī)交易類的執(zhí)行情況 交易的平均響應(yīng)時(shí)間（期望值：15s） 交易的最大響應(yīng)時(shí)間（期望值：95%） 不同并發(fā)用戶數(shù)的狀況下的上述記錄值2）測(cè)試結(jié)果分析情況 單筆記錄的處理時(shí)間（期望值：

13、10個(gè)） 某個(gè)時(shí)間段內(nèi)的交易處理數(shù)量 單筆能處理的最大數(shù)據(jù)量 在每個(gè)交易處理中最大（最耗時(shí)）的模塊 在不同數(shù)量的測(cè)試數(shù)據(jù)基礎(chǔ)上的上述記錄值2.1.4.2 網(wǎng)絡(luò)級(jí)別的測(cè)試指標(biāo)： 吞吐量：?jiǎn)挝粫r(shí)間內(nèi)網(wǎng)絡(luò)傳輸數(shù)據(jù)量 沖突率：在以太網(wǎng)上監(jiān)測(cè)到的每秒沖突數(shù)2.1.4.3 操作系統(tǒng)級(jí)別的測(cè)試指標(biāo)： 進(jìn)程/線程交換率：進(jìn)程和線程之間每秒交換次數(shù) CPU利用率：即CPU占用率（） 系統(tǒng)CPU利用率：系統(tǒng)的CPU占用率（） 用戶CPU利用率：用戶模式下的CPU占用率（） 磁盤交換率：磁盤交換速率 中斷速率：CPU每秒處理的中斷數(shù) 讀入內(nèi)存頁速率：物理內(nèi)存中每秒讀入內(nèi)存頁的數(shù)目 寫出內(nèi)存頁速率：每秒從物理內(nèi)存中寫

14、到頁文件中的內(nèi)存頁數(shù)目或者從物理內(nèi)存中刪掉的內(nèi)存頁數(shù)目 內(nèi)存頁交換速率：每秒寫入內(nèi)存頁和從物理內(nèi)存中讀出頁的個(gè)數(shù) 進(jìn)程入交換率：交換區(qū)輸入的進(jìn)程數(shù)目 進(jìn)程出交換率：交換區(qū)輸出的進(jìn)程數(shù)目 2.1.4.4 數(shù)據(jù)庫級(jí)別的測(cè)試指標(biāo)： 數(shù)據(jù)庫的并發(fā)連接數(shù)：客戶端的最大連接數(shù) 數(shù)據(jù)庫鎖資源的使用數(shù)量2.1.5 測(cè)試數(shù)據(jù)準(zhǔn)備2.1.5.1 案例數(shù)據(jù)：滿負(fù)荷壓力根據(jù)測(cè)試系統(tǒng)的硬件條件，選擇滿負(fù)荷的壓力，在系統(tǒng)的資源使用基本維持在90%左右的狀況下，測(cè)試xxx核心業(yè)務(wù)系統(tǒng)的處理能力。數(shù)據(jù)準(zhǔn)備工作包括：1 xxxxx2.1.6 運(yùn)行狀況記錄記錄可擴(kuò)展性測(cè)試中的測(cè)試結(jié)果及其系統(tǒng)的運(yùn)行狀況。除了記錄測(cè)試指標(biāo)以外，應(yīng)該

15、結(jié)合測(cè)試實(shí)時(shí)記錄系統(tǒng)各個(gè)層次的資源和參數(shù)。主要包括： 硬件環(huán)境資源 服務(wù)器操作系統(tǒng)參數(shù) 網(wǎng)絡(luò)相關(guān)參數(shù) 數(shù)據(jù)庫相關(guān)參數(shù)：具體數(shù)據(jù)庫參數(shù)有所不同，結(jié)合各個(gè)數(shù)據(jù)庫獨(dú)有的特點(diǎn)記錄3 第三章 測(cè)試過程及結(jié)果描述 xxxx務(wù)系統(tǒng)的性能測(cè)試共計(jì)執(zhí)行了2次，兩次執(zhí)行的腳本流程作了調(diào)整，其他的環(huán)境和數(shù)據(jù)都一樣。在測(cè)試數(shù)據(jù)準(zhǔn)備完備以后，第一次測(cè)試中，操作流程為每次交易都執(zhí)行用戶登錄操作，第二次測(cè)試中，操作流程為先進(jìn)行用戶登錄，然后每次交易都不再執(zhí)行用戶登錄。3.1 測(cè)試描述兩次測(cè)試都是在12月22日凌晨進(jìn)行的。第一次測(cè)試執(zhí)行了30分鐘左右，執(zhí)行腳本都是采用每次交易都執(zhí)行登錄操作，測(cè)試過程中，交易的執(zhí)行速度隨著測(cè)試

16、的進(jìn)行，越來越慢，交易的響應(yīng)時(shí)間越來越長(zhǎng)，交易出錯(cuò)（超時(shí)）情況也越來越嚴(yán)重，交易在執(zhí)行到30分鐘左右，用戶登錄交易開始大量失?。ǔ瑫r(shí)）并導(dǎo)致后續(xù)的交易都無法完成，于是終止本次測(cè)試。第二次測(cè)試執(zhí)行了50分鐘左右，在第一次測(cè)試的基礎(chǔ)上，調(diào)整交易流程，讓每次交易都只登錄一次，然后順序執(zhí)行交易邏輯。測(cè)試開始初期，交易的響應(yīng)時(shí)間隨著交易并發(fā)量的增加而快速增加，在測(cè)試執(zhí)行了10分鐘左右，所有的用戶登錄操作都基本完成，此后交易響應(yīng)時(shí)間開始減少，并比較平穩(wěn)的執(zhí)行，絕大部分交易執(zhí)行比較平穩(wěn)成功率也很高，除了兩個(gè)交易：xxx(Audit_Transaction)和 xxx(ClaimRegister_Transa

17、ction)，這兩個(gè)交易的執(zhí)行速度特別慢，交易相應(yīng)時(shí)間一直都維持在190秒左右和160秒左右，這兩個(gè)交易超時(shí)現(xiàn)象嚴(yán)重，交易成功率很低，很多交易都因?yàn)槌瑫r(shí)而失敗。3.2 測(cè)試場(chǎng)景測(cè)試中，使用逐步加壓的模式，采用：每隔2秒啟動(dòng)1個(gè)并發(fā)用戶（Vuser）的方式，即：每隔1秒，啟動(dòng)1個(gè)Vuser，在7分鐘左右啟動(dòng)所有的Vuser（200個(gè)），執(zhí)行登錄，并根據(jù)設(shè)置的時(shí)間間隔發(fā)起交易。這次測(cè)試都部署在如下的場(chǎng)景中。運(yùn)行的腳本部署在3臺(tái)PC機(jī)，主要目的就是檢查在較大壓力的情況下，xxxxx心業(yè)務(wù)系統(tǒng)的性能表現(xiàn)。 選擇了2臺(tái)PC，每臺(tái)PC機(jī)部署了70個(gè)左右并發(fā)用戶， 選擇1臺(tái)PC，部署60個(gè)左右的并發(fā)用戶，并

18、運(yùn)行LoadRunner的控制器（Controller）3.3 測(cè)試結(jié)果兩次測(cè)試AP服務(wù)器主機(jī)上的CPU利用率如下：可以看出在兩次測(cè)試執(zhí)行中第一次（1:52 2:20）測(cè)試過程中CPU的利用率都幾乎達(dá)到了100%，第二次測(cè)試中（2:45- 4:00）CPU的利用率也達(dá)到了95%以上。兩次測(cè)試在數(shù)據(jù)庫（Oracle）服務(wù)器上主機(jī)上的CPU利用率如下：可以看出兩次測(cè)試執(zhí)行中第一次（1:52 2:20）測(cè)試過程中CPU的利用率很低，第二次測(cè)試中（2:45- 4:00）CPU的利用率較高也達(dá)到了75%以上，但兩次測(cè)試的CPU的IO等待時(shí)間卻都比較高，IO和CPU利用率對(duì)照表如下：可以看出兩次測(cè)試執(zhí)行中

19、第一次（1:52 2:20）測(cè)試過程中CPU的IO等待率較低，因?yàn)榇蠖鄶?shù)的交易都是用戶登錄，都?jí)涸贏P服務(wù)器上了，第二次測(cè)試中（2:45- 4:00）CPU的IO等待率較高，都達(dá)到了80%以上。兩次測(cè)試的網(wǎng)絡(luò)壓力并不大，網(wǎng)絡(luò)流量如下：AP服務(wù)器監(jiān)控的網(wǎng)絡(luò)流量DB服務(wù)器上監(jiān)控的網(wǎng)絡(luò)流量從圖中可以看出，在10M的局域網(wǎng)中，網(wǎng)絡(luò)流量并不大。3.3.1 第一次測(cè)試第一次測(cè)試使用了200個(gè)并發(fā)用戶，并發(fā)用戶的啟動(dòng)信息如下：各類交易的交易相應(yīng)時(shí)間 （秒）ColorScale交易名稱最小平均最大1AutoUW_Transaction0.023.73387.8711Confirm_Transaction210

20、.203210.203210.2031CTDetail_Transaction105.878151.032199.4771EdorNoscanAppInput_Transaction60.704153.425259.2341GeneralQuery_Transaction0.06713.62339.0941IndividualQuery_Transaction0.78128.04264.9841Issue_Transaction5.14530.660.221Login_Transaction4.265115.433246.7361ManualUW_Transaction77.09477.094

21、77.0941NBQuery_Transaction0.33422.34849.6251PayIn_Transaction1.50359.944112.6391PayOut_Transaction5.25629.17860.2791PayOutQuery_Transaction0.0781.2916.8721PEdorTypeAC_Transaction111.253160.054213.5441PosNoScanApp_Transaction9.254158.276271.3811POSQuery_Transaction29.602122.815212.931PrtNoInput_Trans

22、action1.722146.879263.0941Relogin_Transaction30.1670.939105.241ReportInput_Transaction1.155101.387184.7831Review_Transaction5.091112.682387.0871RiskInput_Transaction2.821113.049211.4271vuser_end_Transaction0.00.00.01vuser_init_Transaction0.00.1582.41712.084112.373267.65910.2786.31215.39413.7513.5625

23、.92510.226.24315.93918.531109.639210.74611.2818.55315.47410.09319.46959.271各類交易的平均響應(yīng)時(shí)間圖：可以看出隨著測(cè)試的進(jìn)行，交易相應(yīng)時(shí)間逐漸增大，最終導(dǎo)致交易超時(shí)而失敗。測(cè)試中，每秒的點(diǎn)擊率如下：測(cè)試中每秒頁面的下載速度如下：根據(jù)上面兩組數(shù)據(jù)，即：每秒的點(diǎn)擊率和每秒下載頁面的速度，可以看出，在測(cè)試執(zhí)行開始4分鐘以后，核心業(yè)務(wù)系統(tǒng)用戶登錄的并發(fā)數(shù)量不斷在增加，但是用戶登錄后的數(shù)據(jù)下載量卻變化不大，這樣將最終導(dǎo)致大量的用戶登錄因?yàn)榻灰滋幚沓瑫r(shí)而失敗。3.3.2 第二次測(cè)試第二次測(cè)試調(diào)整了交易處理邏輯，大大減少了用戶登錄的操

24、作數(shù)目，每個(gè)用戶只執(zhí)行一次用戶登錄，然后執(zhí)行對(duì)應(yīng)的交易處理，交易過程中不再執(zhí)行用戶登錄操作。運(yùn)行的并發(fā)用戶數(shù)目如下圖：在用戶登錄過程中，交易的平均響應(yīng)時(shí)間如下圖：從圖中可以看出，隨著并發(fā)用戶數(shù)量的不斷增加，所有的交易的平均響應(yīng)時(shí)間都在加大，直到并發(fā)用戶數(shù)不再增加，這時(shí)候所有的交易相應(yīng)時(shí)間下降到一定的數(shù)值，并一直穩(wěn)定在這個(gè)數(shù)值左右。在第二次測(cè)試中，各類交易的平均響應(yīng)時(shí)間如下表：（單位：秒）ColorScale交易最小平均最大1Audit_Transaction19.481162.12207.6271AutoUW_Transaction0.013.00149.4941ClaimRegister_T

25、ransaction75.599143.641163.9781Confirm_Transaction1.13151.42794.5851CTDetail_Transaction37.25765.967148.3341EdorNoscanAppInput_Transaction16.50479.919169.2391EndCase_Transaction11.8846.54685.6581GeneralQuery_Transaction0.15211.01735.3211IndividualQuery_Transaction0.87514.45540.5781Issue_Transaction4

26、.26914.32630.4961Login_Transaction8.36390.998151.3441ManualUW_Transaction3.26281.311171.2841NBQuery_Transaction0.42212.08236.2971PayIn_Transaction0.55932.01274.4621PayOut_Transaction2.20411.12132.3971PayOutQuery_Transaction0.0791.2555.3281PEdorTypeAC_Transaction37.38466.606137.3821PosNoScanApp_Trans

27、action15.89285.482164.1561POSQuery_Transaction10.19357.825132.6771PrtNoInput_Transaction5.16277.07164.4581Relogin_Transaction16.10361.11674.8961ReportInput_Transaction4.8866.869138.3721Review_Transaction8.6761.846302.1311RiskInput_Transaction9.31749.871123.7881vuser_end_Transaction0.00.00.0161vuser_

28、init_Transaction0.00.00.00817.79254.317183.40910.6942.4198.55311.4817.26724.72510.7772.5326.63818.97172.21145.92311.3843.97711.53910.2967.43328.666交易相應(yīng)時(shí)間時(shí)序圖如?。簣D中最上方的兩條曲線（即交易相應(yīng)時(shí)間最慢的）分別是：xxx (Audit_Transaction) 和 xxx(ClaimRegister_Transaction)，除了這兩類交易，其他各類交易都是在測(cè)試初期執(zhí)行較慢，隨著用戶登錄完成以后，各類交易的平均響應(yīng)時(shí)間都穩(wěn)定在對(duì)應(yīng)的數(shù)值上，并都保持在90秒以內(nèi)。測(cè)試中每秒的點(diǎn)擊率如下：途中，從20分鐘開始到35分鐘，點(diǎn)擊率下降的原因是部分查詢交易循環(huán)600次已經(jīng)成功結(jié)束，在35分鐘左右重新啟動(dòng)，所有出現(xiàn)了途中點(diǎn)擊率下滑的現(xiàn)象。下面的幾幅圖中，數(shù)據(jù)線下滑的原因相同。交易的吞吐率（每秒處理數(shù)據(jù)量）如下圖：其中數(shù)據(jù)線下滑的原因同上。4第四章 測(cè)試報(bào)告在xxxxx核心業(yè)務(wù)系統(tǒng)的性能測(cè)試過程中，將分別撰寫測(cè)試計(jì)劃和性能測(cè)試報(bào)告，其中測(cè)試計(jì)劃將在測(cè)試開始之前完成，用以指導(dǎo)測(cè)試、并做好各個(gè)階段的計(jì)劃和任務(wù)分配工作，在測(cè)試結(jié)束之后，根據(jù)測(cè)試結(jié)果，將生成測(cè)試報(bào)告。兩份對(duì)應(yīng)的文檔名稱如下： 性能測(cè)試計(jì)劃書 性能測(cè)試報(bào)告第 19 頁 共 21 頁