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

1、xxxxxxxxxx性能測試報(bào)告MERCURY美科利2013年4月18日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功能模塊描述 21.2.3業(yè)務(wù)流程31.2.4系統(tǒng)的關(guān)鍵點(diǎn)描述（KP） 41.3性能測試環(huán)境41.3.1硬件及網(wǎng)絡(luò)環(huán)境 錯(cuò)誤！未定義書簽。1.3.2系統(tǒng)裝配描述 錯(cuò)誤！未定義書簽。1.3.3系統(tǒng)啟動(dòng)和管理 錯(cuò)誤！未定義書簽。2第二章性能測試52.1壓力測試52.1.1壓力測試概述52.1.2測試目的52.1.3測試方法及測試用例 62.1.4

2、測試指標(biāo)及期望 72.1.5測試數(shù)據(jù)準(zhǔn)備 92.1.6運(yùn)行狀況記錄93第三章 測試計(jì)劃及方案 92.2測試步驟 錯(cuò)誤！未定義書簽。2.2.1被測系統(tǒng)調(diào)研 錯(cuò)誤！未定義書簽。2.2.2測試環(huán)境的部署 錯(cuò)誤！未定義書簽。2.2.3腳本的錄制和調(diào)試 錯(cuò)誤！未定義書簽。2.2.4準(zhǔn)備測試場景 錯(cuò)誤！未定義書簽。2.2.5準(zhǔn)備測試數(shù)據(jù) 錯(cuò)誤！未定義書簽。2.2.6執(zhí)行性能測試 錯(cuò)誤！未定義書簽。2.2.7生成測試報(bào)告 錯(cuò)誤！未定義書簽。2.3測試時(shí)間進(jìn)度及人員安排 錯(cuò)誤！未定義書簽。2.3.1人員安排 錯(cuò)誤！未定義書簽。3第四章測試報(bào)告19美科利公司解決方案第1頁共21頁MERCURY 美輯利丄 、F亠

3、一1刖言目前，XXXX的XXXXXXXX 核心業(yè)務(wù)系統(tǒng)（以下簡稱新業(yè)務(wù)系統(tǒng)）已先后在 XXXX、成功上線，從而公司的XXXX信息管理逐步走上了集中管控的道路。后續(xù)，XXX等34家分公司的XXXX信息也將分布進(jìn)入業(yè)務(wù)系統(tǒng)，從而將會(huì)勢必出現(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)入時(shí)，系統(tǒng)能穩(wěn)定在什么樣 的性能水平，面臨公司業(yè)務(wù)沖刺時(shí)，系統(tǒng)能否經(jīng)受住“考驗(yàn)”，這些問題需要通過一個(gè)完整的性能測試來給出答案。本性能測試規(guī)劃書即是基于上述考慮，參考科學(xué)的性能測試方法而撰寫的，用 以

4、指導(dǎo)即將進(jìn)行的XXXXXXXX核心業(yè)務(wù)系統(tǒng)的性能測試。1第一章XXXX系統(tǒng)性能測試概述1.1被測系統(tǒng)定義XXXX業(yè)務(wù)系統(tǒng)作為本次測試的被測系統(tǒng)（注：以下所有針對(duì)被測系統(tǒng)地描述均為針 對(duì)XXXXXXXX 核心業(yè)務(wù)系統(tǒng)進(jìn)行的），該業(yè)務(wù)系統(tǒng)的主要功能包括：XXXXX在本次測試中，將針對(duì)上述的功能進(jìn)行壓力測試， 檢查并評(píng)估在模擬環(huán)境中， 系統(tǒng) 對(duì)負(fù)載的承受能力，在不同的用戶連接情況下，系統(tǒng)地吞吐能力和響應(yīng)能力，以及在預(yù)計(jì)的數(shù)據(jù)容量中，系統(tǒng)能夠容忍的最大用戶數(shù)，1.1.1功能簡介XXXXXX主要功能如下：XXXXXXXX1.1.2性能測試指標(biāo)本次測試是針對(duì)XXXXXXXX 核心業(yè)務(wù)系統(tǒng)的性能特征和系統(tǒng)的

5、性能調(diào)優(yōu)而進(jìn)行 的，主要需要獲得如下的測試指標(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)的吞吐率：即應(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)跟本次性能測試所采用的體系結(jié)構(gòu)是一樣 的，交易流程也完全一致的。不過，由于硬件條件的限制，本次性

6、能測試的硬件平臺(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功能模塊本次性能測試中各類交易都是由若干功能模塊組成的，每個(gè)交易都根據(jù)其執(zhí)行特點(diǎn)分成了若干操作步驟，每個(gè)步驟就是一個(gè)功能點(diǎn)（即功能模塊），在XXX業(yè)務(wù)系統(tǒng)中，各種交易及其包含的功能模塊關(guān)系如下：1 . XXX2. xxxx3. xxxx本次壓力測試主要設(shè)計(jì)的功能模塊以及所屬的路徑如下表名稱所屬交易路徑1.2.3業(yè)務(wù)流程本次性能測試中，選擇的各類交易的業(yè)務(wù)流程如下:1 . XXXXXX2. xxxxxxx3. xxxx

7、xx :4. xxx :5. xxxxx6. xxxx查詢交易的業(yè)務(wù)流程只是單一步驟的，即：輸入查詢條件后獲取查詢結(jié)果，因此在本次性能測試中只作為一個(gè)事物處理，交易流程圖略。1.2.4關(guān)鍵點(diǎn)描述（KP）本次性能測試的關(guān)鍵點(diǎn)，就是查看xxxx業(yè)務(wù)系統(tǒng)在并發(fā)壓力下的表現(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ù)庫的一個(gè)復(fù)制（或縮小），本系統(tǒng)采用標(biāo)準(zhǔn)的CS結(jié)構(gòu)，客戶端都 是通過瀏覽器訪問應(yīng)用系統(tǒng)。其中具體的硬件和網(wǎng)絡(luò)環(huán)境如下

8、：服務(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第二章性能測試從廣泛意義上講性能測試包括：壓力測試、穩(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)品性能測試診斷工具(D

9、iagnostic)對(duì)測試應(yīng)用的各層進(jìn)行監(jiān)控，判斷 J2EE各層次的各類方法和類的調(diào)用使用時(shí)間和效率，并幫 助開發(fā)人員分析J2EE應(yīng)用的各類交易的性能瓶頸點(diǎn)。2.1壓力測試在性能測試中，壓力測試主要是為了獲取系統(tǒng)在較大壓力狀況下的性能表現(xiàn)而設(shè)計(jì)并實(shí)現(xiàn)的，壓力測試主要是獲取系統(tǒng)的性能瓶頸和系統(tǒng)的最大吞吐率。2.1.1壓力測試概述本次壓力測試是指針對(duì)現(xiàn)行的 XXX核心業(yè)務(wù)系統(tǒng)的聯(lián)機(jī)交易處理能力的測試，檢驗(yàn)系統(tǒng)的吞吐率。本系統(tǒng)的壓力測試主要是針對(duì)XXXXX，檢查在日間交易高峰時(shí)期，并發(fā)用戶數(shù)較多的時(shí)候的處理能力等等。2.1.2測試目的壓力測試的目的就是檢驗(yàn)系統(tǒng)的最大吞吐量，檢驗(yàn)現(xiàn)行的XXXX業(yè)務(wù)系統(tǒng)

10、在各種壓力交易量下的運(yùn)行狀況，檢驗(yàn)系統(tǒng)地運(yùn)行瓶頸，獲取系統(tǒng)的處理能力等等。本次針對(duì)XXXX核心業(yè)務(wù)系統(tǒng)所進(jìn)行的壓力測試的測試目的為：給出XXXX系統(tǒng)當(dāng)前的性能狀況定位新業(yè)務(wù)系統(tǒng)性能瓶頸或潛在性能瓶頸總結(jié)一套合理的、 可操作的、適合公司現(xiàn)實(shí)情況的性能測試方案，為后續(xù)的性能測試工作提供基本思路。2.1.3測試方法及測試用例使用美科利公司（Mercury）的性能測試軟件LoadRunner,對(duì)現(xiàn)行的xxxx業(yè)務(wù)系統(tǒng) 進(jìn)行腳本錄制、測試回放、逐步加壓和跟蹤記錄。測試過程中，由LoadRunner的管理平臺(tái)調(diào)用各臺(tái)測試前臺(tái)，發(fā)起各種組合的交易請(qǐng)求，并跟蹤記錄服務(wù)器端的運(yùn)行情況和 返回給客戶端的運(yùn)行結(jié)果。

11、使用的測試用例包括： 聯(lián)機(jī)處理交易和查詢交易， 其中聯(lián)機(jī)交易測試試用的交易包 括：xxxx 查詢類交易包括： xxxx測試用例列表包括:交易種類案例一案例二案例三案例四30%40%25%10%10%10%25%0%20%10%15%0%20%20%15%10%30%20%20%80%本次測試將依照如下場景進(jìn)行測試:、用戶數(shù) 功能模塊、業(yè)務(wù)操作交易配比（%）2004007001000000002410172451021365271327476751121375351021375271429517251019344811224578112142856981406122441595112238556

12、13264564204080141201針對(duì)每個(gè)測試案例，都將采用逐步加壓和瞬間加壓兩種客戶端連接方式進(jìn)行，查看服務(wù)器端在客戶端的連接數(shù)量變化過程中對(duì)應(yīng)的處理能力，測試運(yùn)行安排如下：*每隔2秒增加1個(gè)用戶連接，最多增加到 200個(gè)用戶，查看并記錄運(yùn)行情況每隔2秒增加2個(gè)用戶連接，最多增加到 200個(gè)用戶，查看并記錄運(yùn)行情況 一次性連接10個(gè)用戶，查看記錄運(yùn)行情況 一次性連接100個(gè)用戶，查看記錄運(yùn)行情況2.1.4測試指標(biāo)及期望在本次性能測試中，各類測試指標(biāo)包括測試中應(yīng)該達(dá)到的某些性能指標(biāo)，這些性能指標(biāo)均是來自應(yīng)用系統(tǒng)設(shè)計(jì)開發(fā)時(shí)遵循的業(yè)務(wù)需求，當(dāng)某個(gè)測試的某一類指標(biāo)已經(jīng)超出了業(yè)務(wù)需求的要求范圍，

13、貝V測試已經(jīng)達(dá)到目的，即可終止壓力測試。2141應(yīng)用軟件級(jí)別的測試指標(biāo)：1）聯(lián)機(jī)交易類的執(zhí)行情況交易的平均響應(yīng)時(shí)間（期望值：<15s）交易的最大響應(yīng)時(shí)間（期望值：<30s）平均每秒處理交易數(shù)量（分別記錄單位時(shí)間內(nèi)成功、失敗和停止的交易數(shù)量）交易成功率 （期望值：>95%）不同并發(fā)用戶數(shù)的狀況下的上述記錄值2）測試結(jié)果分析情況單筆記錄的處理時(shí)間（期望值：<15s）單位時(shí)間內(nèi)的處理交易筆數(shù)（期望值：>10個(gè)）某個(gè)時(shí)間段內(nèi)的交易處理數(shù)量單筆能處理的最大數(shù)據(jù)量在每個(gè)交易處理中最大（最耗時(shí)）的模塊在不同數(shù)量的測試數(shù)據(jù)基礎(chǔ)上的上述記錄值2.1.4.2網(wǎng)絡(luò)級(jí)別的測試指標(biāo)：吞吐量

14、：單位時(shí)間內(nèi)網(wǎng)絡(luò)傳輸數(shù)據(jù)量沖突率：在以太網(wǎng)上監(jiān)測到的每秒沖突數(shù)2.1.4.3操作系統(tǒng)級(jí)別的測試指標(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)存中寫到頁文件中的內(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í)

15、別的測試指標(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)該結(jié)合測試實(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第三章測試過程及結(jié)果描述XXXX務(wù)系統(tǒng)的性能測試

16、共計(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í)行速度隨著測試的進(jìn)行，越來越慢，交易的響應(yīng)時(shí)間越來越長，交易出錯(cuò)（超時(shí)）情況也越來越嚴(yán)重，交易在執(zhí)行到30分鐘左右，用戶登錄交易開始大量失?。ǔ瑫r(shí)）并導(dǎo)致后續(xù)的交易都無法完成，于是終止本次測試。第二次測試執(zhí)行了 50分鐘左右，在第一次測

17、試的基礎(chǔ)上，調(diào)整交易流程，讓每次 交易都只登錄一次，然后順序執(zhí)行交易邏輯。測試開始初期，交易的響應(yīng)時(shí)間隨著交易 并發(fā)量的增加而快速增加，在測試執(zhí)行了10分鐘左右，所有的用戶登錄操作都基本完成，此后交易響應(yīng)時(shí)間開始減少，并比較平穩(wěn)的執(zhí)行，絕大部分交易執(zhí)行比較平穩(wěn)成功 率也很高，除了兩個(gè)交易：xxx（Audit_Transaction）和 xxx（ClaimRegister_Transaction），這 兩個(gè)交易的執(zhí)行速度特別慢，交易相應(yīng)時(shí)間一直都維持在190秒左右和160秒左右，這兩個(gè)交易超時(shí)現(xiàn)象嚴(yán)重，交易成功率很低，很多交易都因?yàn)槌瑫r(shí)而失敗。3.2測試場景測試中，使用逐步加壓的模式，采用：每隔

18、 2秒啟動(dòng)1個(gè)并發(fā)用戶（Vuser）的方 式，即：每隔1秒，啟動(dòng)1個(gè)Vuser，在7分鐘左右啟動(dòng)所有的 Vuser（200 個(gè)），執(zhí)行 登錄，并根據(jù)設(shè)置的時(shí)間間隔發(fā)起交易。這次測試都部署在如下的場景中。運(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ā)用戶，并運(yùn)行 LoadRunner的控制器（Con troller）3.3測試結(jié)果兩次測試AP服務(wù)器主機(jī)上的 CPU利用率如下:美科利公司解決方案第10頁共21頁MERCURY 美輯利CPU Total APP

19、4廠 User% 廠 Sys% Wait%zb- 374 - 3003- 3002- 3001- 390- 39D. 305 - 3HU4 - 303 - 311- 32U- 3100806040200美科利公司解決方案第10頁共21頁MERCURY 美輯利Time of Day可以看出在兩次測試執(zhí)行中第一次(1:52 -2:20)測試過程中CPU的利用率都幾乎達(dá)到了 100%，第二次測試中(2:45- 4:00) CPU的利用率也達(dá)到了 95%以上。兩次測試在數(shù)據(jù)庫(Oracle)服務(wù)器上主機(jī)上的 CPU利用率如下：CPU Total REQDB1廠 User% 廠 Sys% Wait%3D

20、. 300- 32I-340- 314-3H0. 3OI. 391- 392 - 393 - 3oeo- 3Time of Day可以看出兩次測試執(zhí)行中第一次(1:52 -2:20)測試過程中CPU的利用率很低，第二次測試中(2:45-4:00) CPU的利用率較高也達(dá)到了 75%以上，但兩次測試的 CPU的IO等待時(shí)間卻都比較高，IO和CPU利用率對(duì)照表如下：美科利公司解決方案第10頁共21頁MERCURY 美輯利REQDB1O OSLeLX ksb oooTime of DayCPU% IO/secO640O OOO O5O OOO OOO OO O di222034- O美科利公司解決方

21、案第10頁共21頁MERCURY 美輯利可以看出兩次測試執(zhí)行中第一次 (1:52 -2:20)測試過程中CPU的10等待率較低, 因?yàn)榇蠖鄶?shù)的交易都是用戶登錄，都?jí)涸?AP服務(wù)器上了，第二次測試中(2:45- 4:00) CPU的10等待率較高，都達(dá)到了 80%以上。兩次測試的網(wǎng)絡(luò)壓力并不大，網(wǎng)絡(luò)流量如下：oo53oo30oo52o o 202H-3 o oo5匚 Total-Writei Total-Read2- 32U- 3lz-303 - 3or. 3OD. 305. 3001- 37- 3美科利公司解決方案第10頁共21頁MERCURY 美輯利美科利公司解決方案第10頁共21頁MERC

22、URY 美輯利AP服務(wù)器監(jiān)控的網(wǎng)絡(luò)流量005 - 3ow393 - 392 - 391. 3o-3nD. 315- 314-340- 3of-32I-300- 3005- 336 5 4 3 2 1 0匸 Total-Write-Total-Read美科利公司解決方案第10頁共21頁MERCURY 美輯利美科利公司解決方案第10頁共21頁MERCURY 美輯利DB服務(wù)器上監(jiān)控的網(wǎng)絡(luò)流量從圖中可以看出，在 10M的局域網(wǎng)中，網(wǎng)絡(luò)流量并不大美科利公司解決方案第10頁共21頁MERCURY 美輯利美科利公司解決方案第10頁共21頁MERCURY 美輯利3.3.1第一次測試第一次測試使用了 200個(gè)并

23、發(fā)用戶，并發(fā)用戶的啟動(dòng)信息如下:RunningElapsed scenario lime miTi:ssnwqLunN各類交易的交易相應(yīng)時(shí)間（秒）ColorScale交易名稱最小平均最大H1AutoUW_Tra nsactio n0.023.73387.8711Con firm_Tra nsactio n210.203210.203210.20381CTDetail_Tra nsacti on105.878151.032199.477H1EdorNosca nApp In put_Tr an sacti on60.704153.425259.2341Gen eralQuery_Tra nsac

24、t0.06713.62339.094ionB1In dividualQuery_Tra ns actio n0.78128.04264.9841Issue_Tra nsact ion5.14530.660.22B1Logi n_Tran sact ion4.265115.433246.736口1Ma nualUW_Tra nsacti on77.09477.09477.094n1NBQuery Tra nsact ion0.33422.34849.6251Payln_Tran sact ion1.50359.944112.639O1PayOut_Tra nsact ion5.25629.178

25、60.2791PayOutQuery_Tra nsacti0.0781.2916.872on1PEdorTypeAC_Tra nsacti111.253160.054213.544on口1PosNoSca nApp Tra nsact9.254158.276271.381ion1POSQuery_Tra nsacti on29.602122.815212.931PrtNoI nput_Tra nsactio n1.722146.879263.0941Relogin_Tra nsactio n30.1670.939105.24-1Report In put_Tra nsacti on1.1551

26、01.387184.783'-1Review_Tra nsactio n5.091112.682387.0871Risk In put_Tra nsact ion2.821113.049211.427O1vuser_e nd_Tra nsactio n0.00.00.01vuser_i ni t_Tra nsactio n0.00.1582.41712.084112.373267.65910.2786.31215.39413.7513.5625.925H10.226.24315.939H18.531109.639210.746H|11.2818.55315.47410.09319.46

27、959.271各類交易的平均響應(yīng)時(shí)間圖:Number of vussrsTnnsnctionTune 山*討曰 Lend6Gooo2086o o o o26242220*4D(Ep clouwm) -E-H swusdw國tt.美科利公司解決方案第10頁共21頁MERCURY 美輯利美科利公司解決方案第10頁共21頁MERCURY 美輯利可以看出隨著測試的進(jìn)行，交易相應(yīng)時(shí)間逐漸增大，最終導(dǎo)致交易超時(shí)而失敗。美科利公司解決方案第10頁共21頁MERCURY 美輯利測試中，每秒的點(diǎn)擊率如下:pudues出 s；一hHits per Secoiwlri iI I：| ,!； | ! “ ?。?!|丄

28、Id 卩 i i i i I *"01 ：0002：ODU3：0D04:0005:0006:0007:00 DS：O0 09:0010:00T1：0012:00Elaipsed scanario lime mnn:ss美科利公司解決方案第10頁共21頁MERCURY 美輯利美科利公司解決方案第10頁共21頁MERCURY 美輯利測試中每秒頁面的下載速度如下:Pages Downloqded n«i Second050 5 050SO S050877 6 6 55443322pm 8 -lCDdOTIDB 再 d美科利公司解決方案第10頁共21頁MERCURY 美輯利美科利公

29、司解決方案第10頁共21頁MERCURY 美輯利Ii7 、*,01 ：00(J2.0DQ3：0004:0005:0006:0007：OD06:0009:0010:0011 ：0012:0()Elapsed scanario lime mm:ss根據(jù)上面兩組數(shù)據(jù)，即： 每秒的點(diǎn)擊率和每秒下載頁面的速度，可以看出，在測試執(zhí)行開始4分鐘以后，核心業(yè)務(wù)系統(tǒng)用戶登錄的并發(fā)數(shù)量不斷在增加，但是用戶登錄后的數(shù)據(jù)下載量卻變化不大，這樣將最終導(dǎo)致大量的用戶登錄因?yàn)榻灰滋幚沓瑫r(shí)而失敗。3.3.2第二次測試第二次測試調(diào)整了交易處理邏輯，大大減少了用戶登錄的操作數(shù)目，每個(gè)用戶只執(zhí)行一次用戶登錄，然后執(zhí)行對(duì)應(yīng)的交易處理

30、，交易過程中不再執(zhí)行用戶登錄操作。運(yùn)行的并發(fā)用戶數(shù)目如下圖：口2qLLmNRnnnihfj VipersElapsed scenario lim hh:mmQOOOOOOOQDOOOOD4 3 2 4 0 9 8 7 6 .4 3 2 1美科利公司解決方案第10頁共21頁MERCURY 美輯利美科利公司解決方案第10頁共21頁MERCURY 美輯利在用戶登錄過程中，交易的平均響應(yīng)時(shí)間如下圖:2B0 -200iao16014CM120-1100-602002040500100120i140160100200Number of VusersT hwsactjnn Response Time Und

31、ei l "勒I美科利公司解決方案第10頁共21頁MERCURY 美輯利美科利公司解決方案第10頁共21頁MERCURY 美輯利從圖中可以看出，隨著并發(fā)用戶數(shù)量的不斷增加，所有的交易的平均響應(yīng)時(shí)間都在加大，直到并發(fā)用戶數(shù)不再增加，這時(shí)候所有的交易相應(yīng)時(shí)間下降到一定的數(shù)值，并一直穩(wěn)定在這個(gè)數(shù)值左右。在第二次測試中，各類交易的平均響應(yīng)時(shí)間如下表:（單位：秒）ColorScale交易最小平均最大1Audit_Transaction19.481162.12207.6271AutoUW_Transaction0.013.00149.4941ClaimRegister_Transaction75

32、.599143.641163.9781Confirm_Transaction1.13151.42794.5851CTDetail_Transaction37.25765.967148.3341EdorNoscanApplnput_Transa ction16.50479.919169.2391EndCase_Transaction11.8846.54685.6581GeneralQuery_Transaction0.15211.01735.3211IndividualQuery_Transaction0.87514.45540.578ri1Issue_Transaction4.26914.32

33、630.4961Login_Transaction8.36390.998151.3441ManualUW_Transaction3.26281.311171.2841NBQuery_Transaction0.42212.08236.2971PayIn_Transaction0.55932.01274.4621PayOut_Transaction2.20411.12132.3971PayOutQuery_Transaction0.0791.2555.328i1PEdorTypeAC_Transaction37.38466.606137.3821PosNoScanApp_Transaction15.89285.482164.1561POSQuery_Transaction10.19357.825132.6771PrtNoInput_Transaction5.16277.07164.4581Relogin_Tran