第1頁共14頁第0頁共14頁xxx系統性能測試報告姓名：班級：學號：目錄1前言 32被測系統定義 32.1功能簡介 32.2性能測試指標 43系統結構及流程 43.1系統總體結構 43.2功能模塊 43.3業務流程 53.4關鍵點描述 63.5性能測試環境 64性能測試 64.1性能測試概述 74.2測試目的 74.3測試方法及測試用例 74.4測試指標及期望 84.5測試數據準備 104.6運行狀況記錄 105測試過程及結果描述 105.1測試描述 115.2測試場景 115.3測試結果 116測試分析和結論 16第11頁共14頁前言目前，隨著WebTours訂票系統在生產狀態下日趨穩定、成熟，系統的性能問題也逐步成為了我們關注的焦點：隨著訂票過程中大數據量的“沖擊”，在客戶信息信息進入時，系統能穩定在什么樣的性能水平，面臨公司業務沖刺時，系統能否經受住“考驗”，這些問題需要通過一個完整的性能測試來給出答案。本報告前部分即是基于上述考慮，參考科學的性能測試方法而撰寫的，用以指導即將進行的WebTours訂票系統的性能測試。HPWebTours系統定義HPWebTours訂票系統作為本次測試的被測系統，該業務系統的主要功能包括：搜索航班，預訂機票并查看航班路線。在本次測試中，將針對上述的功能進行壓力測試，檢查并評估在模擬環境中，系統對負載的承受能力，在不同的用戶連接情況下，系統地吞吐能力和響應能力，以及在預計的數據容量中，系統能夠容忍的最大用戶數。功能簡介HPWebTours主要功能如下：用戶注冊登錄查詢航班性能測試指標本次測試是針對HPWebTours訂票系統的性能特征和系統的性能調優而進行的，主要需要獲得如下的測試指標。1、系統的響應能力：即在各種負載壓力情況下，系統的響應時間，也就是從客戶端交易發起，到服務器端交易應答返回所需要的時間，包括網絡傳輸時間和服務器處理時間。2、應用系統的吞吐率：即應用系統在單位時間內完成的交易量，也就是在單位時間內，應用系統針對不同的負載壓力，所能完成的交易數量。3、應用系統的負載能力：即系統所能容忍的最大用戶數量，也就是在正常的響應時間中，系統能夠支持的最多的客戶端的數量。系統結構及流程HPWebTours訂票系統在實際生產中的體系結構跟本次性能測試所采用的體系結構是一樣的，交易流程也完全一致的。不過，由于硬件條件的限制，本次性能測試的硬件平臺跟實際生產環境略有不同。系統總體結構HPWebTours訂票系統系統由用戶注冊、登錄、查詢航班等這些功能構成。功能模塊本次性能測試中各類交易都是由若干功能模塊組成的，每個交易都根據其執行特點分成了若干操作步驟，每個步驟就是一個功能點（即功能模塊），在HPWebTours訂票系統中，各種交易及其包含的功能模塊關系如下：注冊登錄查詢航班本次壓力測試主要設計的功能模塊以及所屬的路徑如下表名稱所屬交易路徑業務流程本次性能測試中，選擇的各類交易的業務流程如下：注冊登錄查詢航班查詢交易的業務流程只是單一步驟的，即：輸入查詢條件后獲取查詢結果，因此在本次性能測試中只作為一個事務處理，交易流程圖略。關鍵點描述本次性能測試的關鍵點，就是查看HPWebTours訂票系統在并發壓力下的表現，即：支持的并發用戶數目和并發用戶發送頻率，以及在較大壓力下，系統的交易處理能力，并找出各類交易的性能瓶頸。性能測試環境本次性能測試環境與真實運行環境基本一致，都運行在同樣的硬件和網絡環境中，數據庫是真實環境數據庫的一個復制（或縮?。鞠到y采用標準的CS結構，客戶端都是通過瀏覽器訪問應用系統。其中具體的硬件和網絡環境如下：服務器設備：IBM570（DBserver），IBM690（APserver）操作系統：Windows2003網絡環境：LAN（10M）數據庫：MYSQL客戶端：PC（Windows）網絡拓撲和結構圖如下：性能測試從廣泛意義上講性能測試包括：壓力測試、穩定性測試、負載能力測試和可擴展性測試等。在不同應用系統的性能測試中，需要根據應用系統的特點和測試目的的不同來選擇具體的測試方案，本次HPWebTours訂票系統的性能測試主要是采用通常的壓力測試模式來執行的，即：逐步增加壓力，查看應用系統在各種壓力狀況小的性能表現。在性能測試中，壓力測試主要是為了獲取系統在較大壓力狀況下的性能表現而設計并實現的，壓力測試主要是獲取系統的性能瓶頸和系統的最大吞吐率。性能測試概述本次壓力測試是指針對現行的HPWebTours訂票業務系統的聯機交易處理能力的測試，檢驗系統的吞吐率。本系統的壓力測試主要是針對HPWebTours訂票系統，檢查在日間交易高峰時期，并發用戶數較多的時候的處理能力等等。測試目的壓力測試的目的就是檢驗系統的最大吞吐量，檢驗現行的HPWebTours訂票系統在各種壓力交易量下的運行狀況，檢驗系統地運行瓶頸，獲取系統的處理能力等等。本次針對HPWebTours訂票業務系統所進行的壓力測試的測試目的為：給出HPWebTours訂票系統當前的性能狀況定位新業務系統性能瓶頸或潛在性能瓶頸總結一套合理的、可操作的、適合公司現實情況的性能測試方案，為后續的性能測試工作提供基本思路。測試方法及測試用例使用性能測試軟件LoadRunner，對現行的HPWebTours訂票系統進行腳本錄制、測試回放、逐步加壓和跟蹤記錄。測試過程中，由LoadRunner的管理平臺調用各臺測試前臺，發起各種組合的交易請求，并跟蹤記錄服務器端的運行情況和返回給客戶端的運行結果。本次測試將依照如下場景進行測試：用戶數功能模塊業務操作2004007001000注冊注冊登錄登錄業務查詢航班針對每個測試案例，都將采用逐步加壓和瞬間加壓兩種客戶端連接方式進行，查看服務器端在客戶端的連接數量變化過程中對應的處理能力，測試運行安排如下：每隔2秒增加1個用戶連接，最多增加到200個用戶，查看并記錄運行情況每隔2秒增加2個用戶連接，最多增加到200個用戶，查看并記錄運行情況一次性連接10個用戶，查看記錄運行情況一次性連接100個用戶，查看記錄運行情況測試指標及期望在本次性能測試中，各類測試指標包括測試中應該達到的某些性能指標，這些性能指標均是來自應用系統設計開發時遵循的業務需求，當某個測試的某一類指標已經超出了業務需求的要求范圍，則測試已經達到目的，即可終止壓力測試。應用軟件級別的測試指標：1)聯機交易類的執行情況交易的平均響應時間（期望值：<15s）交易的最大響應時間（期望值：<30s）平均每秒處理交易數量（分別記錄單位時間內成功、失敗和停止的交易數量）交易成功率（期望值：>95%）不同并發用戶數的狀況下的上述記錄值2）測試結果分析情況單筆記錄的處理時間（期望值：<15s）單位時間內的處理交易筆數（期望值：>10個）某個時間段內的交易處理數量單筆能處理的最大數據量在每個交易處理中最大（最耗時）的模塊在不同數量的測試數據基礎上的上述記錄值網絡級別的測試指標：吞吐量：單位時間內網絡傳輸數據量沖突率：在以太網上監測到的每秒沖突數操作系統級別的測試指標：進程/線程交換率：進程和線程之間每秒交換次數CPU利用率：即CPU占用率（％）系統CPU利用率：系統的CPU占用率（％）用戶CPU利用率：用戶模式下的CPU占用率（％）磁盤交換率：磁盤交換速率中斷速率：CPU每秒處理的中斷數讀入內存頁速率：物理內存中每秒讀入內存頁的數目寫出內存頁速率：每秒從物理內存中寫到頁文件中的內存頁數目或者從物理內存中刪掉的內存頁數目內存頁交換速率：每秒寫入內存頁和從物理內存中讀出頁的個數進程入交換率：交換區輸入的進程數目進程出交換率：交換區輸出的進程數目數據庫級別的測試指標：數據庫的并發連接數：客戶端的最大連接數數據庫鎖資源的使用數量測試數據準備前期準備工作包括：錄制好一段完整的腳本,包括(注冊，登錄，查詢航班)進行相關的設置運行狀況記錄記錄可擴展性測試中的測試結果及其系統的運行狀況。除了記錄測試指標以外，應該結合測試實時記錄系統各個層次的資源和參數。主要包括：硬件環境資源服務器操作系統參數網絡相關參數數據庫相關參數：具體數據庫參數有所不同，結合各個數據庫獨有的特點記錄測試過程及結果描述HPWebTours訂票系統的性能測試共計執行了2次，兩次執行的腳本流程作了調整，其他的環境和數據都一樣。在測試數據準備完備以后，第一次測試中，操作流程為每次交易都執行用戶登錄操作，第二次測試中，操作流程為先進行用戶登錄，然后每次交易都不再執行用戶登錄。測試描述兩次測試都是在12月22日凌晨進行的。第一次測試執行了30分鐘左右，執行腳本都是采用每次交易都執行登錄操作，測試過程中，交易的執行速度隨著測試的進行，越來越慢，交易的響應時間越來越長，交易出錯（超時）情況也越來越嚴重，交易在執行到30分鐘左右，用戶登錄交易開始大量失?。ǔ瑫r）并導致后續的交易都無法完成，于是終止本次測試。第二次測試執行了50分鐘左右，在第一次測試的基礎上，調整交易流程，讓每次交易都只登錄一次，然后順序執行交易邏輯。測試開始初期，交易的響應時間隨著交易并發量的增加而快速增加，在測試執行了10分鐘左右，所有的用戶登錄操作都基本完成，此后交易響應時間開始減少，并比較平穩的執行，絕大部分交易執行比較平穩成功率也很高，除了兩個交易：xxx(Audit_Transaction)和xxx(ClaimRegister_Transaction)，這兩個交易的執行速度特別慢，交易相應時間一直都維持在190秒左右和160秒左右，這兩個交易超時現象嚴重，交易成功率很低，很多交易都因為超時而失敗。測試場景測試中，使用逐步加壓的模式，采用：每隔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的利用率都幾乎達到了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第一次測試第一次測試使用了200個并發用戶，并發用戶的啟動信息如下：各類交易的交易相應時間（秒）ColorScale交易名稱最小平均最大1AutoUW_Transaction0.023.73387.8711Confirm_Transaction210.203210.203210.2031CTDetail_Transaction105.878151.032199.4771EdorNoscanAppInput_Transaction60.704153.425259.2341GeneralQuery_Transaction0.06713.62339.0941IndividualQuery_Transaction0.78128.04264.9841Issue_Transaction5.14530.660.2218.531109.639210.74611.2818.55315.47410.09319.46959.271各類交易的平均響應時間圖：可以看出隨著測試的進行，交易相應時間逐漸增大，最終導致交易超時而失敗。第二次測試第二次測試調整了交易處理邏輯，大大減少了用戶登錄的操作數目，每個用戶只執行一次用戶登錄，然后執行對應的交易處理，交易過程中不再執行用戶登錄操作。運行的并發用戶數目如下圖：在用戶登錄過程中，交易的平均響應時間如下圖：從圖中可以看出，隨著并發用戶數量的不斷增加，所有的交易的平均響應時間都在加大，直到并發用戶數不再增加，這時候所有的交易相應時間下降到一定的數值，并一直穩定在這個數值左右。在第二次測試中，各類交易的平均響應時間如下