1、xxxxxxxxxx性能測試報告2022年2月8日目 錄1 前言11第一章XXXXXXXX核心業務系統性能測試概述11.1 被測系統定義1 功能簡介1 性能測試指標21.2 系統結構及流程2 系統總體結構2 功能模塊描述3 業務流程4 系統的關鍵點描述（KP）51.3 性能測試環境5 硬件及網絡環境5 系統裝配描述6 系統啟動和管理62 第二章 性能測試62.1 壓力測試6 壓力測試概述7 測試目的72.1.3 測試方法及測試用例7 測試指標及期望9 測試數據準備10 運行狀況記錄113第三章 測試計劃及方案112.2 測試步驟12 被測系統調研12 測試環境的部署13 腳本的錄制和調試13

2、準備測試場景14 準備測試數據14 執行性能測試14 生成測試報告152.3 測試時間進度及人員安排15 人員安排153 第四章 測試報告16前言目前，XXXX的XXXXXXXX核心業務系統（以下簡稱新業務系統）已先后在XXXX、成功上線，從而公司的XXXX信息管理逐步走上了集中管控的道路。后續，xxx等34家分公司的XXXX信息也將分布進入業務系統，從而將會勢必出現新業務系統中信息大量增長的態勢。隨著新業務系統在生產狀態下日趨穩定、成熟，系統的性能問題也逐步成為了我們關注的焦點：XXXX大數據量的“沖擊”，在XXXX信息進入時，系統能穩定在什么樣的性能水平，面臨公司業務沖刺時，系統能否經受住

3、“考驗”，這些問題需要通過一個完整的性能測試來給出答案。本性能測試規劃書即是基于上述考慮，參考科學的性能測試方法而撰寫的，用以指導即將進行的XXXXXXXX核心業務系統的性能測試。1第一章xxxx系統性能測試概述被測系統定義xxxx業務系統作為本次測試的被測系統（注：以下所有針對被測系統地描述均為針對XXXXXXXX核心業務系統進行的），該業務系統的主要功能包括：xxxxx在本次測試中，將針對上述的功能進行壓力測試，檢查并評估在模擬環境中，系統對負載的承受能力，在不同的用戶連接情況下，系統地吞吐能力和響應能力，以及在預計的數據容量中，系統能夠容忍的最大用戶數，功能簡介xxxxxx主要功能如下：

4、Ø xxxØ xxxxx性能測試指標本次測試是針對XXXXXXXX核心業務系統的性能特征和系統的性能調優而進行的，主要需要獲得如下的測試指標。1、系統的響應能力：即在各種負載壓力情況下，系統的響應時間，也就是從客戶端交易發起，到服務器端交易應答返回所需要的時間，包括網絡傳輸時間和服務器處理時間。2、應用系統的吞吐率：即應用系統在單位時間內完成的交易量，也就是在單位時間內，應用系統針對不同的負載壓力，所能完成的交易數量。3、應用系統的負載能力：即系統所能容忍的最大用戶數量，也就是在正常的響應時間中，系統能夠支持的最多的客戶端的數量。系統結構及流程xxxx業務系統在實際生產中的

5、體系結構跟本次性能測試所采用的體系結構是一樣的，交易流程也完全一致的。不過，由于硬件條件的限制，本次性能測試的硬件平臺跟實際生產環境略有不同。系統總體結構描述本系統的總體結構，包括：硬件組織體系結構、網絡組織體系結構、軟件組織體系結構和功能模塊的組織體系結構。 功能模塊本次性能測試中各類交易都是由若干功能模塊組成的，每個交易都根據其執行特點分成了若干操作步驟，每個步驟就是一個功能點（即功能模塊），在xxx業務系統中，各種交易及其包含的功能模塊關系如下：1 xxx2 xxxx3 xxxx本次壓力測試主要設計的功能模塊以及所屬的路徑如下表名稱所屬交易路徑業務流程本次性能測試中，選擇的各類交易的業務

6、流程如下：1xxxxxx2xxxxxxx3xxxxxx：4xxx：5xxxxx6xxxx查詢交易的業務流程只是單一步驟的，即：輸入查詢條件后獲取查詢結果，因此在本次性能測試中只作為一個事物處理，交易流程圖略。關鍵點描述（KP）本次性能測試的關鍵點，就是查看xxxx業務系統在并發壓力下的表現，即：支持的并發用戶數目和并發用戶發送頻率，以及在較大壓力下，系統的交易處理能力，并找出各類交易的性能瓶頸。 性能測試環境本次性能測試環境與真實運行環境基本一致，都運行在同樣的硬件和網絡環境中，數據庫是真實環境數據庫的一個復制（或縮小），本系統采用標準的CS結構，客戶端都是通過瀏覽器訪問應用系統。 其中具體的

7、硬件和網絡環境如下：Ø 服務器設備：IBM 570（DBserver）， IBM 690（APserver）Ø 操作系統： AIXØ 網絡環境： LAN（10M）Ø 數據庫：Oracle Ø 客戶端： PC （Windows ）網絡拓撲和結構圖如下：第二章 性能測試從廣泛意義上講性能測試包括：壓力測試、穩定性測試、負載能力測試和可擴展性測試等。在不同應用系統的性能測試中，需要根據應用系統的特點和測試目的的不同來選擇具體的測試方案，本次XXXXXXXX核心業務系統的性能測試主要是采用通常的壓力測試模式來執行的，即：逐步增加壓力，查看應用系統在各種

8、壓力狀況小的性能表現。在本次性能測試中，也將使用美科利的新產品性能測試診斷工具（Diagnostic）對測試應用的各層進行監控，判斷J2EE各層次的各類方法和類的調用使用時間和效率，并幫助開發人員分析J2EE應用的各類交易的性能瓶頸點。壓力測試在性能測試中，壓力測試主要是為了獲取系統在較大壓力狀況下的性能表現而設計并實現的，壓力測試主要是獲取系統的性能瓶頸和系統的最大吞吐率。壓力測試概述本次壓力測試是指針對現行的xxx核心業務系統的聯機交易處理能力的測試，檢驗系統的吞吐率。本系統的壓力測試主要是針對xxxxx，檢查在日間交易高峰時期，并發用戶數較多的時候的處理能力等等。測試目的壓力測試的目的就

9、是檢驗系統的最大吞吐量，檢驗現行的xxxx業務系統在各種壓力交易量下的運行狀況，檢驗系統地運行瓶頸，獲取系統的處理能力等等。本次針對xxxx核心業務系統所進行的壓力測試的測試目的為：² 給出xxxx系統當前的性能狀況² 定位新業務系統性能瓶頸或潛在性能瓶頸² 總結一套合理的、可操作的、適合公司現實情況的性能測試方案，為后續的性能測試工作提供基本思路。測試方法及測試用例使用美科利公司（Mercury）的性能測試軟件LoadRunner，對現行的xxxx業務系統進行腳本錄制、測試回放、逐步加壓和跟蹤記錄。測試過程中，由LoadRunner的管理平臺調用各臺測試前臺，發

10、起各種組合的交易請求，并跟蹤記錄服務器端的運行情況和返回給客戶端的運行結果。使用的測試用例包括：聯機處理交易和查詢交易，其中聯機交易測試試用的交易包括：xxxx查詢類交易包括：xxxx測試用例列表包括：交易種類案例一案例二案例三案例四30%40%25%10%10%10%25%0%20%10%15%0%20%20%15%10%30%20%20%80%本次測試將依照如下場景進行測試： 用戶數功能模塊業務操作交易配比（%)200400700100000000241017245102136527132747675112137535102137527142951725101934481122457811

11、214285698140612244159511223855613264564204080141201針對每個測試案例，都將采用逐步加壓和瞬間加壓兩種客戶端連接方式進行，查看服務器端在客戶端的連接數量變化過程中對應的處理能力，測試運行安排如下：· 每隔2秒增加1個用戶連接，最多增加到200個用戶，查看并記錄運行情況· 每隔2秒增加2個用戶連接，最多增加到200個用戶，查看并記錄運行情況· 一次性連接10個用戶，查看記錄運行情況· 一次性連接100個用戶，查看記錄運行情況測試指標及期望在本次性能測試中，各類測試指標包括測試中應該達到的某些性能指標，這些性能

12、指標均是來自應用系統設計開發時遵循的業務需求，當某個測試的某一類指標已經超出了業務需求的要求范圍，則測試已經達到目的，即可終止壓力測試。應用軟件級別的測試指標：1) 聯機交易類的執行情況交易的平均響應時間（期望值：<15s）交易的最大響應時間（期望值：<30s）平均每秒處理交易數量（分別記錄單位時間內成功、失敗和停止的交易數量）交易成功率 （期望值：>95%）不同并發用戶數的狀況下的上述記錄值2）測試結果分析情況單筆記錄的處理時間（期望值：<15s）單位時間內的處理交易筆數（期望值：>10個）某個時間段內的交易處理數量 單筆能處理的最大數據量在每個交易處理中最大（

13、最耗時）的模塊在不同數量的測試數據基礎上的上述記錄值網絡級別的測試指標：吞吐量：單位時間內網絡傳輸數據量沖突率：在以太網上監測到的每秒沖突數操作系統級別的測試指標：進程/線程交換率：進程和線程之間每秒交換次數 CPU利用率：即CPU占用率（）系統CPU利用率：系統的CPU占用率（） 用戶CPU利用率：用戶模式下的CPU占用率（） 磁盤交換率：磁盤交換速率 中斷速率：CPU每秒處理的中斷數 讀入內存頁速率：物理內存中每秒讀入內存頁的數目 寫出內存頁速率：每秒從物理內存中寫到頁文件中的內存頁數目或者從物理內存中刪掉的內存頁數目 內存頁交換速率：每秒寫入內存頁和從物理內存中讀出頁的個數 進程入交換率

14、：交換區輸入的進程數目 進程出交換率：交換區輸出的進程數目 數據庫級別的測試指標：數據庫的并發連接數：客戶端的最大連接數數據庫鎖資源的使用數量測試數據準備案例數據：滿負荷壓力根據測試系統的硬件條件，選擇滿負荷的壓力，在系統的資源使用基本維持在90%左右的狀況下，測試xxx核心業務系統的處理能力。數據準備工作包括：1 xxxxx運行狀況記錄記錄可擴展性測試中的測試結果及其系統的運行狀況。除了記錄測試指標以外，應該結合測試實時記錄系統各個層次的資源和參數。主要包括：硬件環境資源服務器操作系統參數網絡相關參數數據庫相關參數：具體數據庫參數有所不同，結合各個數據庫獨有的特點記錄第三章 測試過程及結果描

15、述 xxxx務系統的性能測試共計執行了2次，兩次執行的腳本流程作了調整，其他的環境和數據都一樣。在測試數據準備完備以后，第一次測試中，操作流程為每次交易都執行用戶登錄操作，第二次測試中，操作流程為先進行用戶登錄，然后每次交易都不再執行用戶登錄。測試描述兩次測試都是在12月22日凌晨進行的。第一次測試執行了30分鐘左右，執行腳本都是采用每次交易都執行登錄操作，測試過程中，交易的執行速度隨著測試的進行，越來越慢，交易的響應時間越來越長，交易出錯（超時）情況也越來越嚴重，交易在執行到30分鐘左右，用戶登錄交易開始大量失敗（超時）并導致后續的交易都無法完成，于是終止本次測試。第二次測試執行了50分鐘左

16、右，在第一次測試的基礎上，調整交易流程，讓每次交易都只登錄一次，然后順序執行交易邏輯。測試開始初期，交易的響應時間隨著交易并發量的增加而快速增加，在測試執行了10分鐘左右，所有的用戶登錄操作都基本完成，此后交易響應時間開始減少，并比較平穩的執行，絕大部分交易執行比較平穩成功率也很高，除了兩個交易：xxx(Audit_Transaction)和 xxx(ClaimRegister_Transaction)，這兩個交易的執行速度特別慢，交易相應時間一直都維持在190秒左右和160秒左右，這兩個交易超時現象嚴重，交易成功率很低，很多交易都因為超時而失敗。測試場景測試中，使用逐步加壓的模式，采用：每隔

17、2秒啟動1個并發用戶（Vuser）的方式，即：每隔1秒，啟動1個Vuser，在7分鐘左右啟動所有的Vuser（200個），執行登錄，并根據設置的時間間隔發起交易。這次測試都部署在如下的場景中。運行的腳本部署在3臺PC機，主要目的就是檢查在較大壓力的情況下，xxxxx心業務系統的性能表現。Ø 選擇了2臺PC，每臺PC機部署了70個左右并發用戶，Ø 選擇1臺PC，部署60個左右的并發用戶，并運行LoadRunner的控制器（Controller）測試結果兩次測試AP服務器主機上的CPU利用率如下：可以看出在兩次測試執行中第一次（1:52 2:20）測試過程中CPU的利用率都幾乎

18、達到了100%，第二次測試中（2:45- 4:00）CPU的利用率也達到了95%以上。兩次測試在數據庫（Oracle）服務器上主機上的CPU利用率如下：可以看出兩次測試執行中第一次（1:52 2:20）測試過程中CPU的利用率很低，第二次測試中（2:45- 4:00）CPU的利用率較高也達到了75%以上，但兩次測試的CPU的IO等待時間卻都比較高，IO和CPU利用率對照表如下：可以看出兩次測試執行中第一次（1:52 2:20）測試過程中CPU的IO等待率較低，因為大多數的交易都是用戶登錄，都壓在AP服務器上了，第二次測試中（2:45- 4:00）CPU的IO等待率較高，都達到了80%以上。兩次

19、測試的網絡壓力并不大，網絡流量如下：AP服務器監控的網絡流量DB服務器上監控的網絡流量從圖中可以看出，在10M的局域網中，網絡流量并不大。第一次測試第一次測試使用了200個并發用戶，并發用戶的啟動信息如下：各類交易的交易相應時間 （秒）ColorScale交易名稱最小平均最大1AutoUW_Transaction0.023.73387.8711Confirm_Transaction210.203210.203210.2031CTDetail_Transaction105.878151.032199.4771EdorNoscanAppInput_Transaction60.704153.4252

20、59.2341GeneralQuery_Transaction0.06713.62339.0941IndividualQuery_Transaction0.78128.04264.9841Issue_Transaction5.14530.660.221Login_Transaction4.265115.433246.7361ManualUW_Transaction77.09477.09477.0941NBQuery_Transaction0.33422.34849.6251PayIn_Transaction1.50359.944112.6391PayOut_Transaction5.25629

21、.17860.2791PayOutQuery_Transaction0.0781.2916.8721PEdorTypeAC_Transaction111.253160.054213.5441PosNoScanApp_Transaction9.254158.276271.3811POSQuery_Transaction29.602122.815212.931PrtNoInput_Transaction1.722146.879263.0941Relogin_Transaction30.1670.939105.241ReportInput_Transaction1.155101.387184.783

22、1Review_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.92510.226.24315.93918.531109.639210.74611.2818.55315.47410.09319.46959.271各類交易的平均響應時間圖：可以看出隨著測試的進行，交易相應時

23、間逐漸增大，最終導致交易超時而失敗。測試中，每秒的點擊率如下：測試中每秒頁面的下載速度如下：根據上面兩組數據，即：每秒的點擊率和每秒下載頁面的速度，可以看出，在測試執行開始4分鐘以后，核心業務系統用戶登錄的并發數量不斷在增加，但是用戶登錄后的數據下載量卻變化不大，這樣將最終導致大量的用戶登錄因為交易處理超時而失敗。第二次測試第二次測試調整了交易處理邏輯，大大減少了用戶登錄的操作數目，每個用戶只執行一次用戶登錄，然后執行對應的交易處理，交易過程中不再執行用戶登錄操作。運行的并發用戶數目如下圖：在用戶登錄過程中，交易的平均響應時間如下圖：從圖中可以看出，隨著并發用戶數量的不斷增加，所有的交易的平均

24、響應時間都在加大，直到并發用戶數不再增加，這時候所有的交易相應時間下降到一定的數值，并一直穩定在這個數值左右。在第二次測試中，各類交易的平均響應時間如下表：（單位：秒）ColorScale交易最小平均最大1Audit_Transaction19.481162.12207.6271AutoUW_Transaction0.013.00149.4941ClaimRegister_Transaction75.599143.641163.9781Confirm_Transaction1.13151.42794.5851CTDetail_Transaction37.25765.967148.3341Edo

25、rNoscanAppInput_Transaction16.50479.919169.2391EndCase_Transaction11.8846.54685.6581GeneralQuery_Transaction0.15211.01735.3211IndividualQuery_Transaction0.87514.45540.5781Issue_Transaction4.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_Transaction15.89285.482164.1561P