1、UDMS性能壓力測試方案UDMS性能壓力測試方案錯誤！未指定書簽。版本控制版本日期作者備注v1.02011-9-9初稿第12頁目錄一、概述41.1 項目背景和測試目的41.2 被測系統介紹41.3 測試可接收條件4二、測試需求5三、測試方法53.1 測試方法53.2 測試案例63.3 測試流程63.4 數據文彳準備6四、測試環境74.1 網絡拓撲圖74.2 環境配置7五、測試實施85.1試資源與進度8附錄：測試工具原理 91.1 項目背景和測試目的為保障UDMS后續示范應用項目能夠順利實施，UDMS項目組希望在示范 應用項目正式實施前了目前的 UDMS性能是否可行，即了解示范應用項目技術 的可

2、行性。另外，通過測試，還希望了解使用不同技術之間實現的差異。1.2 被測系統介紹本次被測系統是目前已完成的 UDMS1.1系統，系統邏輯結構如下圖：示范應用UDMS系統統一存儲統一分析u統一索引j統一查詢接匚 接口 U 接口 U 接口工具數據建模數據導入交互抽取分析插件索引插件基礎設施（存儲+計算）系統邏輯結構圖本次測試主要測試數據的索引性能及并發數據搜索性能。1.3 測試可接收條件1、數據索引性能每次測試均需成功;2、數據并發搜索性能根據并發用戶量決定，見后續描述；每次測試，以上條件必須同時滿足，方視為本次測試通過。二、測試需求本次測試的需求包括：項目計劃文檔性能需求規格說明書系統架構設計文

3、檔:、測試方法3.1 測試方法測試過程采用自動測試工具進行。使用 HP公司的測試產品：LoadRunnen 對數據索引性能測試不使用上述工具。1 .測試UDMS系統數據索引性能：對UDMS系統進行數據導入測試，分別導入 1萬、10萬，100萬，1000萬 條文本及多媒體數據，之后記錄每次導入的時間。2 .整個系統能夠支持多少用戶同時訪問模擬多個虛擬用戶，同時向 UDMS發送搜索請求，之后記錄每個虛擬用戶 的響應時間。3、不同技術間實現的差異如有條件，可測試示范應用系統使用不同數據庫平臺之間的性能差異。該部分測試視實際情況決定是否需要測試。3.2 測試案例測試目的虛擬用戶Case No.并發用戶

4、數數據量測試數據索引Non-GUIVuser00111萬002110萬0031100萬00411000 萬整個系統能夠支 持多少用戶同時 訪問Non-GUIVuser0051100萬00610100萬007100100萬0081000100萬Non-GUIVuser00811000 萬010101000 萬0111001000 萬01210001000 萬3.3 測試流程正式測試過程如下：確認被測環境正常; 確認測試環境設置; 開始測試；存儲測試結果；系統調試；應用調試； 環境維護；3.4 數據文件準備數據文件名稱包含內容說明數據量文本數據標注完后的文本GBK格式純文本1000 萬多媒體數據帶

5、標注文本及媒體文 件包括聲音、圖像及視 頻1000 萬四、測試環境4.1 網絡拓撲圖Load Generator測試網絡拓撲圖4.2 環境配置配置軟件被測系統服務器DELL POWEREDGE210CPU:INTEL XEON E31220 3.1GHZDISK:2TMEMORY:8G測試系統測試機器 及控制臺CPU:INTEL CORE I5-2410M 2.30HZMEMORY:2G網絡交換機千兆網絡五、測試實施5.1 試資源與進度項目 階段任務分解任務內容完成標準責任人資源與 時間項目 啟動設立項目項目定義，規劃項目運作模式， 編制項目計劃，組建項目班子與 實施隊伍輸出項目計劃測試經理0

6、.5人天測試 計劃 和測 試設 計測試需求 調研明確測試需求、測試目標、界定 測試范圍、任務和具體內容雙方就測試需求達 成共識測試人員0.5人天制定測試力殺細化測試方案，定義測試范 圍，并定義各項測試活動和步 驟，具體安排測試實施過程及測 試進度輸出測試力不» （初稿）測試經理2人天測試執行預測試證明測試腳本可用，證明測試流程可用證明測試環境配置合理證明測試數據準備充分按照預期可接收條 件開發及測試人 員1天系統調優使系統運行在最佳狀態運行500或1000并發用戶場景，測試 經理和項目經理直 到認為測試停止項目負責人/開 發人員/測試人 員/測試經理2天性能測試根據測試案例測試按照預

7、期可接收條 件測試人員1天壓力測試測試系統究竟能夠承受的業務 量按照預期可接收條 件，系統已經不能 承受測試人員1天測試 評估 總結總結輸出項目報告、相關文檔歸檔， 安排后續工作輸出項目報告測試人員2天測試組織結構圖附錄：測試工具原理Mercury Interactive公司的客戶機/服務器系統的壓力測試工具 LoadRunner,其工作原理為：通過一個中心控制點，在一個或幾個主機上同時 模擬成百上千的實際用戶的操作， 從而生成一致的、可測量的及可重復的系統負 載，并記錄特定交易操作的響應時間。概要地說：首先錄制應用程序的操作過程， 測試工具會自動生成可執行的腳本，該腳本運行起來，從服務器端看

8、，就如同一個實際的用戶在進行操作，我們稱為虛擬用戶。然后，通過中心控制點(Controller)設置測試場景，控制許多個虛擬用戶在多臺 Agent機器上同時運行， 監控運行狀態，收集響應時間等性能數據。使用虛擬用戶(Vuser)替代實際用戶每個模擬的用戶即為一個虛擬用戶，其實就是一個運行的測試腳本。LoadRunner在PC上主要有兩種Vuser：非圖形用戶界面的虛擬用戶(Non-GUI Vuser)和圖形用戶界面虛擬用戶(GUI Vuser)。Non-GUI Vuser是直接通過API調用和 Web/Application/DB服務器進行交互 的,一它的腳本是直接向服務器提交請求的類C語言程

9、序。多個Non-GUI Vuser可運行于一臺主機上。 Vuser可通過Virtual User Generator來錄制生成，在錄制 腳本中可以標明某一活動(transaction)的開始和結束點，用于具體度量這一活 動的響應時間及性能，還可以在某一操作之前定義集結點(rendezvous,用于測試這一操作的多用戶并發。GUI Vuser模擬實際用戶運行應用程序進行操作的情況，它的腳本記錄了客 戶機上所有的界面操作。GUI Vuser可通過Mercury Interactive公司的功能測試 工具WinRunner來錄制生成。由于本次壓力測試的目的是檢驗服務器對壓力的承載能力，因此建議通過在

10、一臺主機上運行多個Non-GUI Vuser來模擬多用戶的活動進行壓力測試。測試腳本的參數化測試腳本反映的是錄制時輸入的數據的情況。 但由于錄制操作可能引起原輸 入數據狀態的變化，因此要修改測試腳本中的輸入數據及與其相關的數據；而且為了更準確地模擬真實系統的運作，輸入的數據及與其相關的數據就必須參數 化，并且為該參數建立一個包含所有數據的參數文件。這樣當模擬多用戶進行壓 力測試時，就可控制每個虛擬用戶使用參數文件中的不同數據。通過中心控制點(Controller)管理虛擬用戶在中心控制點，定制測試場景，即將要在測試會話中發生的事件。定制包括 模擬的用戶個數、模擬用戶所在的主機、模擬用戶的動作等

11、。在中心控制點控制場景的運行，管理所有虛擬用戶的活動，監控虛擬用戶的 狀態，也可以無人照料地運行。場景執行完后，可通過Controller的性能分析圖形和報表對結果數據進行分析代理程序必須安裝在參與測試的每一臺主機上，當場景開始運行，代理程序 負責Controller與主機之間的通訊。Client使用自動生成的圖表和報表分析測試結果在每個測試場景運行完后，Controller自動收集服務器、網絡及客戶端的性 能數據，并以圖形和報表的形式顯示。其中包括服務器響應Vuser以及transaction 提交的請求和任務的時間；在運行期間的基于活動Vuser數目的transaction性能時間；服務器

12、磁盤I/O、CPU使用情況，網絡延遲等數據。測試方法及步驟1、建立虛擬用戶（生成測試腳本）在LoadRunner的Virtual User Generator中錄制測試腳本，建立虛擬用戶, 般一個業務操作錄制成一個測試腳本，步驟如下：1）根據應用軟件的體系結構、中間件、數據庫或客戶端與服務器之間的協 議，選擇對應的虛擬用戶類型，如： WEB、Oracle、Tuxedo、WinSocket 等等；2）指定要錄制的可執行程序，開始錄制；3）在Vuser init section中記錄登錄應用系統的過程；4） 在 Actions sections己錄功能操作過程，適當加入事務（transaction

13、）的開始與結束點（事務也可在腳本生成后，直接在腳本中加入）。當需要 記錄壓力測試過程中某一操作的響應時間時，則在執行這一操作前定義 事務的開始點，并給這一事務命名，在操作結束后定義該事務的結束點；5） 在Vuser end sections己錄退出系統的過程；6）回放測試腳本，檢驗測試腳本執行的正確性（有可能要恢復錄制以前的 數據狀態，或進行必要的參數化）。1、試腳本的參數化測試腳本反映的是錄制時輸入的數據的情況，但為了更準確地模擬真實系統 的運作，如模擬不同用戶的登錄，不同用戶查詢，有些輸入的數據必須參數化， 并且為該參數建立一個包含所有可能的數據的參數文件。這樣當模擬多用戶進行 壓力測試時

14、，就可控制每個虛擬用戶使用參數文件中的不同數據。參數的選擇、參數文件的定制具體根據應用軟件的實際情況而定，但要保證 錄制的腳本能夠順利地執行回放，且完成相應的業務功能。2、定制壓力測試場景在LoadRunner的Controller中，定制壓力測試場景，也就是模擬一個多用戶 并發的情況，包括：運行虛擬用戶的測試主機、在測試機上運行的虛擬用戶數、 虛擬用戶運行的測試腳本、每個虛擬用戶的循環次數等等。1）虛擬用戶并發數：定義執行某一測試腳本的虛擬用戶并發數，則虛擬用 戶并發總數為各腳本虛擬用戶并發數之和；由于在運行測試腳本時，忽 略了 Think Time,因此一個虛擬用戶的操作是非常連貫的，具強

15、度遠遠 大于一個實際用戶的操作強度；另外，為了測試引起系統性能急劇下降 的拐點和引起系統崩潰的崩潰點，并發的虛擬用戶數需逐漸增加，每次 增加的數量可視測試的具體情況而定。2）測試主機：選擇運行某一測試腳本的測試主機。3）虛擬用戶執行的腳本：選擇虛擬用戶執行的測試腳本，即完成某一業務 功能的測試腳本。4） Iteration Count:虛擬用戶運行測試腳本 Actions section分的循環次 數，增加循環次數是為了保證在某一稍長的時間段內有一個穩定的負載， 這樣統計的結果才比較準確。需要注意的是，每臺測試機上所支持的虛擬用戶數，與測試機的配置和錄制 的應用程序的大小有關。每臺測試機上運行

16、的虛擬用戶數不能太多，因為如果太 多的話，性能瓶頸將會出現在客戶端，那么測出的結果將毫無意義。3、運行壓力測試場景在LoadRunner的Controller中，運行壓力測試場景，就可以控制測試機上的 所有虛擬用戶并發進行相應的操作。步驟為：1）啟動測試機的 Remote Command Launcher;2）在Controller中使測試機處于“連接”狀態；3）在Controller中，對所有虛擬用戶發出初始化（initialize ）命令，測試主 機的RCL啟動Agent,并將虛擬用戶初始化，執行測試腳本中Vuser init section分，使之登錄系統；4）在Controller中，

17、對所有虛擬用戶發出運行（run）命令，通過測試主機的Agent運行各虛擬用戶，執行測試腳本中的 Actions section分，在 Controller端監控虛擬用戶的狀態及執行結果；5）每個虛擬用戶按指定的循環次數執行測試腳本中的Actions section部分，然后執行Vuser end section?分，退出應用系統；6）當每一個虛擬用戶運行完成后，整個測試場景運行結束。在壓力測試場 景執行過程中，Controller會自動收集服務器、網絡及客戶端的性能數據， 以及各事務的響應時間等。4、監控系統性能在測試場景運行過程中，我們需要監控：1）監控運行虛擬用戶的客戶端的資源使用情況，使

18、用Windows的性能監視 器監控客戶端的CPU、Memory等資源使用情況，以防止性能瓶頸出現 在客戶端；另外，可以在進行壓力測試的同時，在另外的客戶端上運行 應用程序，也就是在系統負載較大時從最終客戶的角度再進行相應功能 的確認，并測試端到端的響應時間，也可將該響應時間與壓力測試的響 應時間進行比較，若結果差別不大，也可驗證壓力測試結果的可信性。2）監控數據庫服務器、WEB服務器資源的使用情況，可以使用QuestSoftware 的 I/Watch,或 CA UniCenter 和 IBM Tivoli 等專門的系統監控 工具，來監控服務器端的 CPU、Memory、Disk、Process Network