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

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

1、xxxxxxxxxx性能測試報(bào)告2018年12月23日目 錄1 前言11第一章XXXXXXXX核心業(yè)務(wù)系統(tǒng)性能測試概述11.1 被測系統(tǒng)定義11.1.1 功能簡介11.1.2 性能測試指標(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 性能測試環(huán)境51.3.1 硬件及網(wǎng)絡(luò)環(huán)境51.3.2 系統(tǒng)裝配描述61.3.3 系統(tǒng)啟動和管理62 第二章 性能測試62.1 壓力測試62.1.1 壓力測試概述72.1.2 測試目的72.1.3 測試方法及測試用例72.1.4 測試指標(biāo)及期望92.1.5 測試數(shù)據(jù)準(zhǔn)

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

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

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

5、應(yīng)用系統(tǒng)在單位時間內(nèi)完成的交易量，也就是在單位時間內(nèi)，應(yīng)用系統(tǒng)針對不同的負(fù)載壓力，所能完成的交易數(shù)量。3、應(yīng)用系統(tǒng)的負(fù)載能力：即系統(tǒng)所能容忍的最大用戶數(shù)量，也就是在正常的響應(yīng)時間中，系統(tǒng)能夠支持的最多的客戶端的數(shù)量。1.2 系統(tǒng)結(jié)構(gòu)及流程xxxx業(yè)務(wù)系統(tǒng)在實(shí)際生產(chǎn)中的體系結(jié)構(gòu)跟本次性能測試所采用的體系結(jié)構(gòu)是一樣的，交易流程也完全一致的。不過，由于硬件條件的限制，本次性能測試的硬件平臺跟實(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 功能模塊本次性能測試中各類交易都是由若干功能模

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

7、的表現(xiàn)，即：支持的并發(fā)用戶數(shù)目和并發(fā)用戶發(fā)送頻率，以及在較大壓力下，系統(tǒng)的交易處理能力，并找出各類交易的性能瓶頸。1.3 性能測試環(huán)境本次性能測試環(huán)境與真實(shí)運(yùn)行環(huán)境基本一致，都運(yùn)行在同樣的硬件和網(wǎng)絡(luò)環(huán)境中，數(shù)據(jù)庫是真實(shí)環(huán)境數(shù)據(jù)庫的一個復(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 第二章 性能測試從廣泛意義上講性能測

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

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

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

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

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

13、10個） 某個時間段內(nèi)的交易處理數(shù)量 單筆能處理的最大數(shù)據(jù)量 在每個交易處理中最大（最耗時）的模塊 在不同數(shù)量的測試數(shù)據(jù)基礎(chǔ)上的上述記錄值2.1.4.2 網(wǎng)絡(luò)級別的測試指標(biāo)： 吞吐量：單位時間內(nèi)網(wǎng)絡(luò)傳輸數(shù)據(jù)量 沖突率：在以太網(wǎng)上監(jiān)測到的每秒沖突數(shù)2.1.4.3 操作系統(tǒng)級別的測試指標(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)存中讀出頁的個數(shù) 進(jìn)程入交換率：交換區(qū)輸入的進(jìn)程數(shù)目 進(jìn)程出交換率：交換區(qū)輸出的進(jìn)程數(shù)目 2.1.4.4 數(shù)據(jù)庫級別的測試指標(biāo)： 數(shù)據(jù)庫的并發(fā)連接數(shù)：客戶端的最大連接數(shù) 數(shù)據(jù)庫鎖資源的使用數(shù)量2.1.5 測試數(shù)據(jù)準(zhǔn)備2.1.5.1 案例數(shù)據(jù)：滿負(fù)荷壓力根據(jù)測試系統(tǒng)的硬件條件，選擇滿負(fù)荷的壓力，在系統(tǒng)的資源使用基本維持在90%左右的狀況下，測試xxx核心業(yè)務(wù)系統(tǒng)的處理能力。數(shù)據(jù)準(zhǔn)備工作包括：1 xxxxx2.1.6 運(yùn)行狀況記錄記錄可擴(kuò)展性測試中的測試結(jié)果及其系統(tǒng)的運(yùn)行狀況。除了記錄測試指標(biāo)以外，應(yīng)該

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

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

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

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

19、第一次（1:52 2:20）測試過程中CPU的IO等待率較低，因?yàn)榇蠖鄶?shù)的交易都是用戶登錄，都壓在AP服務(wù)器上了，第二次測試中（2:45- 4:00）CPU的IO等待率較高，都達(dá)到了80%以上。兩次測試的網(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 第一次測試第一次測試使用了200個并發(fā)用戶，并發(fā)用戶的啟動信息如下：各類交易的交易相應(yīng)時間 （秒）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)時間圖：可以看出隨著測試的進(jìn)行，交易相應(yīng)時間逐漸增大，最終導(dǎo)致交易超時而失敗。測試中，每秒的點(diǎn)擊率如下：測試中每秒頁面的下載速度如下：根據(jù)上面兩組數(shù)據(jù)，即：每秒的點(diǎn)擊率和每秒下載頁面的速度，可以看出，在測試執(zhí)行開始4分鐘以后，核心業(yè)務(wù)系統(tǒng)用戶登錄的并發(fā)數(shù)量不斷在增加，但是用戶登錄后的數(shù)據(jù)下載量卻變化不大，這樣將最終導(dǎo)致大量的用戶登錄因?yàn)榻灰滋幚沓瑫r而失敗。3.3.2 第二次測試第二次測試調(diào)整了交易處理邏輯，大大減少了用戶登錄的操

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