web項目性能測試方案

《web項目性能測試方案》由會員分享，可在線閱讀，更多相關(guān)《web項目性能測試方案（16頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、web項目性能測試方案 任務(wù)： 測試JBOS郵境下UBSS項目的性能 目標：測試繳費部分（前臺繳費，IC卡充值）在并發(fā)數(shù)從 50-100遞增的性能指標，不要求 對結(jié)果進行分析 步驟： 1?搭建測試環(huán)境，要求與真實環(huán)境大概一致（關(guān)注在現(xiàn)有 license情況下，UBSS系統(tǒng)支持的 最大并發(fā)數(shù)） 2?準備數(shù)據(jù)腳本（SQL和存儲過程） 3. 準備測試腳本（Vuser scr i pts,scer）ario 4?進行性能測試 測試范圍 針對UBSS項目，抽取對系統(tǒng)影響最大、最為典型的業(yè)務(wù)交易，構(gòu)建場景，以此評判系統(tǒng)的 整體性能和實際性能表現(xiàn) a. 用戶前臺繳費 b. 標準用戶

2、IC卡充值 測試內(nèi)容 1. 基準測試 概念：檢查每個業(yè)務(wù)的基準響應(yīng)時間（系統(tǒng)整體空閑，無額外進程運行并占用系統(tǒng)資源） 方法：單用戶運行業(yè)務(wù)多次，獲取該業(yè)務(wù)的平均響應(yīng)時間 序號 功能名稱 并發(fā)用戶數(shù) 循環(huán)次數(shù) 操作間隔 循環(huán)間隔 1-1 前臺繳費 1 100 3 3 1-2 IC 卡充值 1 100 3 3 2. 單個交易負載測試 概念：設(shè)定負載序列，并發(fā)用戶數(shù)為 X{ 20,30,50,....},收集系統(tǒng)單個交易在不同負載級別 的性能表現(xiàn) 方法：設(shè)置并發(fā)用戶數(shù)等于 X,關(guān)鍵步驟處設(shè)置并發(fā)點，每個用戶運行 N個iteration，獲 取平均響應(yīng)時間和吞吐量 用戶登陸方

3、式： 每 2秒登陸2個 序號 功能名稱 并發(fā)用戶數(shù) 循環(huán)次數(shù) 操作間隔循環(huán)間隔 2-1 前臺繳費 5 50 3 3 2-2 前臺繳費 10 50 3 3 2-3 前臺繳費 15 50 3 3 注：響應(yīng)時間超過 30S 2-4 前臺繳費 20 50 3 3 注：阻塞，不進行測試 2-5 IC卡充值 5 50 3 3 2-6 IC卡充值 10 50 3 3 2-7 IC卡充值 15 50 3 3 2-8 IC卡充值 20 50 3 3 3. 組合交易負載測試

4、 概念：多個交易組合在一起，設(shè)定負載序列，并發(fā)數(shù)為 X {20,30,50,....}，收集系統(tǒng)在不同 負載級別的性能表現(xiàn) 方法：設(shè)置并發(fā)總數(shù)，各用戶數(shù)按比例分配，每個用戶運行 N分鐘，獲取平均響應(yīng)時間和 吞吐量 序號 功能名稱 并發(fā)用戶總數(shù) 比例 持續(xù)時間 操作間隔 循環(huán)間隔 3-1 前臺繳費， IC卡充值 5 2： 3 20m 3 3 3-2 前臺繳費， IC卡充值 10 2： 3 20m 3 3 3-3 前臺繳費， IC卡充值 15 2： 3 20m 3 3 3-4 前臺繳費， IC卡充值 20 2： 3 20m 3

5、 3 性能指標 1. 主機系統(tǒng)性能指標 CPU 使用率 內(nèi)存占用率 磁盤讀寫 2. 數(shù)據(jù)庫性能指標（略），可直接看應(yīng)用系統(tǒng)所在主機情況 3. 中間件指標（略），可直接看應(yīng)用系統(tǒng)所在主機情況 4. 業(yè)務(wù)指標 平均響應(yīng)時間 最長響應(yīng)時間 吞吐率 衩測系統(tǒng)環(huán)境描述 1. 系統(tǒng)架構(gòu) J2EE架構(gòu)，多層結(jié)構(gòu)，即展示層、應(yīng)用服務(wù)層、數(shù)據(jù)服務(wù)層 2. 主機環(huán)境 主機名 型號主機IP CPU數(shù)內(nèi)存磁盤用途 數(shù)據(jù)庫主機 192.168.1.8 應(yīng)用主機 192.168.1.33 1 2G 3. 軟件環(huán)境 項目 信息 備注 操作系統(tǒng) window xp 應(yīng)用主機 linux

6、數(shù)據(jù)庫主機 數(shù)據(jù)庫 oracle10G 中間件 EOS5.3 for JBOSS 測試工具 LoadRunner8.1 破解 4. 數(shù)據(jù)庫環(huán)境 數(shù)據(jù)庫實例 orcl 數(shù)據(jù)規(guī)模 用戶數(shù)量： 837,060 客戶數(shù)量： 857,043 帳戶數(shù)量： 832,727 未繳費帳單： 403,839 IC 卡用戶信息： 404,607 發(fā)票數(shù)量： 1,169,600 用戶表具信息： 846,999 計費策略： 845,771 已繳費帳單： 5,593,951 5，測試客戶機 序號 IP 操作系統(tǒng) 配置 用途 1 192.168.1.30 window xp pentium4 3.2GHz

7、 memory 1G generator+controoler 測試報告 由anilys自動生成 系統(tǒng)性能測試方案 1引言 1.1 編寫目的 編寫本方案的目的是用于指導 XXXX系統(tǒng)的性能測試,主要從測試環(huán)境、測試工具、測試 策略、測試具體執(zhí)行方法、任務(wù)與進度表等事先計劃和設(shè)計。 1.2 適用范圍 XXXX系統(tǒng)性能測試組 XXXX系統(tǒng)開發(fā)組 XXXX系統(tǒng)性能優(yōu)化組 1.3 參考資料 縮寫、術(shù)語 解釋 性能測試(performanee testing) 運行這些測試通常要確定程序運行有多 快，以便確定是否需要優(yōu)化 負載測試(Load testing) 通過在面臨

8、很多資源要求的系統(tǒng)上運行， 攻擊被測程序或系統(tǒng) 可靠性測試(reliability testing) 持續(xù)進行的性能測試，目標是發(fā)現(xiàn)短序列 程序測試遺漏的情況 系統(tǒng)性能測試指南 1.4 術(shù)語和縮寫詞 2 系統(tǒng)介紹 3 測試環(huán)境 3.1 網(wǎng)絡(luò)拓撲圖 3.2 硬件環(huán)境 3.3 軟件環(huán)境 4 測試范圍與主要內(nèi)容 測試范圍： 女口： XXXX系統(tǒng)各項性能指標，反應(yīng)時間的性能測試、 CPU Memory的性能測試、負載的 性能測試(壓力測試)、可靠性測試 主要檢測內(nèi)容： 如： 1. 典型應(yīng)用的反應(yīng)時間 2. 客戶端、服務(wù)器的 CPU Me

9、mory使用情況 3. 服務(wù)器的響應(yīng)速度 4. 系統(tǒng)支持的最優(yōu)負載數(shù)量 5. 網(wǎng)絡(luò)指標 6. 系統(tǒng)可靠性測試 5 測試工具和測試方法 5.1 測試工具 Ml ( Mercury In teractive User Gen erator MI ( Mercury In teractive Con troller MI ( Mercury In teractive ）公司的LoadRu nn er7.5.1創(chuàng)建虛擬用戶腳本工具 Virtual ）公司的LoadRunner7.5.1 創(chuàng)建、運行實際 場景工具 ）公司的LoadRunner7.5.1 分析測試結(jié)果工具 A

10、nalysis 性能監(jiān)視器（Microsoft Win2000 自帶） 5.2 測試方法 5.2.1 反應(yīng)時間的性能測試 處理點或事件 期望的反應(yīng)時間 實際反映時間平均 值（至少3次） 上次或上版本實際反映 時間平均值（至少 3次） 測試結(jié)果分析： 5.2.2CPU、Memory的性能測試 條件： 1. 客戶端情況 2. 應(yīng)用服務(wù)器情況 3. 數(shù)據(jù)庫服務(wù)器情況 測試結(jié)果分析： 5.2.3 負載的性能測試（壓力測試） 輸入/動作 輸出/響應(yīng) 能否正常運行 5個用戶操作 1

11、0個用戶操作 20個用戶操作 30個用戶操作 50個用戶操作 測試結(jié)果分析: 5.2.4 可靠性測試 任務(wù)描述 連續(xù)運行時間 故障發(fā)生的時刻 故障描述 統(tǒng)計分析 任務(wù)A無故障運行的平均時間間隔 （CPU小時） 測試結(jié)果分析： 5.2.5 網(wǎng)絡(luò)性能測試 對網(wǎng)絡(luò)性能的測試，如網(wǎng)絡(luò)流量、每秒采樣數(shù)、網(wǎng)絡(luò)延遲等。 6 測試完成準則 系統(tǒng)滿足各項性能要求、能滿足實際使用情況并提供測試報告 7 任務(wù)與進度表 8 提交的文檔和報告 XXXX 系統(tǒng)性能測試方案

12、XXXX 系統(tǒng)性能測試報告 XXXX 系統(tǒng)性能測試腳本 軟件系統(tǒng)性能測試方案 1 引言 1.1 編寫目的 編寫本方案的目的是用于指導 XXXX系統(tǒng)的性能測試,主要從測試環(huán)境、測試工具、測試策略、 測試具體執(zhí)行方法、任務(wù)與進度表等事先計劃和設(shè)計。 1.2 適用范圍 XXXX系統(tǒng)性能測試組 XXXX系統(tǒng)開發(fā)組 XXXX系統(tǒng)性能優(yōu)化組 1.3 參考資料 系統(tǒng)性能測試指南 1.4 術(shù)語和縮寫詞 縮寫、術(shù)語 解釋 性能測試 ( performance testing ) 運行這些測試通常要確定程序運行有多快，以便確定是否需要優(yōu)化 負載測試 (load testing

13、) 通過在面臨很多資源要求的系統(tǒng)上運行，攻擊被測程序或系統(tǒng) 可靠性測試 (reliability testing) 持續(xù)進行的性能測試，目標是發(fā)現(xiàn)短序列程序測試遺漏的情況 2 系統(tǒng)介紹 3 測試環(huán)境 3.1 網(wǎng)絡(luò)拓撲圖 3.2 硬件環(huán)境 3.3 軟件環(huán)境 4 測試范圍與主要內(nèi)容 測試范圍： 如：XXXX系統(tǒng)各項性能指標，反應(yīng)時間的性能測試、 CPU Memory的性能測試、負載的性 能測試(壓力測試)、可靠性測試 主要檢測內(nèi)容： 如： 1. 典型應(yīng)用的反應(yīng)時間 2. 客戶端、服務(wù)器的 CPU、 Memory 使用情況 3. 服務(wù)器的響應(yīng)速度 4. 系統(tǒng)支持的最

14、優(yōu)負載數(shù)量 5. 網(wǎng)絡(luò)指標 6. 系統(tǒng)可靠性測試 5 測試工具和測試方法 5.1 測試工具 MI （ Mercury Interactive ）公司的 LoadRunner7.5.1 創(chuàng)建虛擬用戶腳本工具 Virtual User Generator MI （ Mercury Interactive ）公司的 LoadRunner7.5.1 創(chuàng)建、運行實際場景工具 Controller MI （ Mercury Interactive ）公司的 LoadRunner7.5.1 分析測試結(jié)果工具 Analysis 性能監(jiān)視器（ MicroSoft Win2000 自帶） 5.2

15、測試方法 5.2.1 反應(yīng)時間的性能測試 處理點或事件 期望的反應(yīng)時間 實際反映時間平均值（至少 3 次） 上次或上版本實際反映時間平均值（至少 3 次） 測試結(jié)果分析： 5.2.2CPU、 Memory 的性能測試 條件： 1. 客戶端情況 2. 應(yīng)用服務(wù)器情況 3. 數(shù)據(jù)庫服務(wù)器情況 測試結(jié)果分析： 5.2.3 負載的性能測試（壓力測試 輸入 / 動作 輸出 /響應(yīng) 能否正常運行 10 個用戶操作 20 個用戶操作 30 個用戶操作 50 個用戶操作 100個用戶操作 測試結(jié)果分析： 524可靠性測試 任務(wù)描述 連續(xù)運行時間 建議72小時 故

16、障發(fā)生的時刻 故障描述 ??…統(tǒng)計分析 任務(wù)A無故障運行的平均時間間隔 （CPU小時） 任務(wù)A無故障運行的最小時間間隔 （CPU小時） 任務(wù)A無故障運行的最大時間間隔 （CPU小時） 測試結(jié)果分析： 5.2.5網(wǎng)絡(luò)性能測試 對網(wǎng)絡(luò)性能的測試，如網(wǎng)絡(luò)流量、每秒采樣數(shù)、網(wǎng)絡(luò)延遲等。 6測試完成準則 系統(tǒng)滿足各項性能要求、能滿足實際使用情況并提供測試報告 7任務(wù)與進度表 8提交的文檔和報告 XXXX系統(tǒng)性能測試方案 XXXX系統(tǒng)性能測試報告 XXXX系統(tǒng)性能測試腳本 成功的 Web應(yīng)用系統(tǒng)性能測試 性能測試是 Web應(yīng)用系統(tǒng)的一項重要質(zhì)量保證措施。 在現(xiàn)實中，

17、很多 Web性能測試項目 由于性能測試 需求定義不合理或不明確， 導致性能測試項目不能達到預期目標或進度超期。 本文針對 Web 應(yīng)用系統(tǒng)的 技術(shù)架構(gòu)和系統(tǒng)使用特點，探討如何有效實施性能測試過程，并重點介紹如何分析獲得合理 的性能測試 需求，最終對 Web應(yīng)用系統(tǒng)性能進行科學、準確的評估。 1引言 基于Web服務(wù)器的應(yīng)用系統(tǒng)由于提供瀏覽器界面而無須安裝，大大降低了系統(tǒng)部署和升 級成本，得以普遍應(yīng)用。目前，很多企業(yè)的核心業(yè)務(wù)系統(tǒng)均是 Web應(yīng)用，但當 Web應(yīng)用的 數(shù)據(jù)量和訪問用戶量日益增加，系統(tǒng)不得不面臨 性能和可靠性方面的挑戰(zhàn)。因此，無論是 Web應(yīng)用系統(tǒng)的開發(fā)商或最終用戶

18、，都要求在上線前對系統(tǒng)進行 性能，室驗實TI國中科學 評價系統(tǒng)的性能，從而降低系統(tǒng)上線后的 性能風險。 在很多性能測試項目中，由于不能合理定義系統(tǒng)的 性能測試需求，不能建立和真實環(huán)境相 符的負載模型，不能科學分析 性能測試結(jié)果，導致性能測試項目持續(xù)時間很長或不能真正評 價系統(tǒng)性能并提出性能改進措施。 本文在總結(jié)許多 Web應(yīng)用系統(tǒng) 性能測試實踐經(jīng)驗和教訓的基礎(chǔ)上，從與 性能測試工具無 關(guān)的角度介紹 Web應(yīng)用系統(tǒng)性能測試的方法和實施過程，以及如何定義合理的 性能測試需 求。 1.1術(shù)語定義 性能測試：通過模擬大量瀏覽器客戶端同時訪問 Web服務(wù)器，獲得系統(tǒng)的 性能數(shù)據(jù)。 虛擬用戶：

19、模擬瀏覽器向 Web服務(wù)器發(fā)送請求并接收響應(yīng)的一個進程或線程。 響應(yīng)時間：瀏覽器向 Web服務(wù)器提交一個請求到收到響應(yīng)之間的間隔時間。 思考時間：瀏覽器在收到響應(yīng)后到提交下一個請求之間的間隔時間。 請求成功率：Web服務(wù)器正確處理的請求數(shù)量和接收到的請求數(shù)量的比。 吞吐量：單位時間內(nèi) Web服務(wù)器成功處理的 HTTP頁面或HTTP請求數(shù)量。 在線用戶：用戶通過瀏覽器訪問登錄 Web應(yīng)用系統(tǒng)后，并不退出該應(yīng)用系統(tǒng)。通常一個 Web應(yīng)用服務(wù)器的在線用戶對應(yīng) Web應(yīng)用服務(wù)器的一個 Session 并發(fā)用戶數(shù)：Web服務(wù)器在一段時間內(nèi)為處理瀏覽器請求而建立的 HTTP連接數(shù)或生成的

20、處理線程數(shù)。當所有在線用戶發(fā)送 HTTP請求的思考時間為零時， Web服務(wù)器的并發(fā)用戶數(shù) 等于在線用戶數(shù)。 性能分析名詞解釋 LoadRunner Transactions （用戶事務(wù)分析） 用戶事務(wù)分析是站在用戶角度進行的基礎(chǔ)性能分析。 1、 Transation Sunmmary （事務(wù)綜述） 對事務(wù)進行綜合分析是性能分析的第一步，通過分析測試時間內(nèi)用戶事務(wù)的成功與失敗情 況，可以直接判斷出系統(tǒng)是否運行正常。 2、 Average Transaciton Response Time （事務(wù)平均響應(yīng)時間） 事務(wù)平均響應(yīng)時間”顯示的是測試場景運行期間的每一秒內(nèi)事務(wù)執(zhí)行所用的平均

21、時間， 通過 它可以分析測試場景運行期間應(yīng)用系統(tǒng)的性能走向。 例：隨著測試時間的變化， 系統(tǒng)處理事務(wù)的速度開始逐漸變慢， 這說明應(yīng)用系統(tǒng)隨著投產(chǎn)時 間的變化，整體性能將會有下降的趨勢。 3、 Transactions per Second （每秒通過事務(wù)數(shù) /TPS） 每秒通過事務(wù)數(shù)/TPS顯示在場景運行的每一秒鐘，每個事務(wù)通過、失敗以及停止的數(shù)量， 使考查系統(tǒng)性能的一個重要參數(shù)。 通過它可以確定系統(tǒng)在任何給定時刻的時間事務(wù)負載。 分 析TPS主要是看曲線的性能走向。 將它與平均事務(wù)響應(yīng)時間進行對比，可以分析事務(wù)數(shù)目對執(zhí)行時間的影響。 例：當壓力加大時，點擊率 /TPS曲線如果

22、變化緩慢或者有平坦的趨勢，很有可能是服務(wù)器 開始出現(xiàn)瓶頸。 4、 Total Transactions per Second （每秒通過事務(wù)總數(shù)） 每秒通過事務(wù)總數(shù)”顯示在場景運行時，在每一秒內(nèi)通過的事務(wù)總數(shù)、失敗的事務(wù)總署以及 停止的事務(wù)總數(shù)。 5、 Transaction Performance Sunmmary （事務(wù)性能摘要） “事務(wù)性能摘要 ”顯示方案中所有事務(wù)的最小、 最大和平均執(zhí)行時間， 可以直接判斷響應(yīng)時間 是否符合用戶的要求。 重點關(guān)注事務(wù)的平均和最大執(zhí)行時間， 如果其范圍不在用戶可以接受的時間范圍內(nèi)， 需要進 行原因分析。 6、 Transaction Resp

23、onse Time Under Load （事務(wù)響應(yīng)時間與負載） “事務(wù)響應(yīng)時間與負載 ”是“正在運行的虛擬用戶 ”圖和 “平均響應(yīng)事務(wù)時間 ”圖的組合，通過它 可以看出在任一時間點事務(wù)響應(yīng)時間與用戶數(shù)目的關(guān)系， 從而掌握系統(tǒng)在用戶并發(fā)方面的性 能數(shù)據(jù)， 為擴展用戶系統(tǒng)提供參考。 此圖可以查看虛擬用戶負載對執(zhí)行時間的總體影響， 對 分析具有漸變負載的測試場景比較有用。 7、 Transaction Response Time（Percentile） （事務(wù)響應(yīng)時間 （百分比 ）） “事務(wù)響應(yīng)時間 （百分比 ） ”是根據(jù)測試結(jié)果進行分析而得到的綜合分析圖，也就是工具通過一 些統(tǒng)計分析方法間

24、接得到的圖表。 通過它可以分析在給定事務(wù)響應(yīng)時間范圍內(nèi)能執(zhí)行的事務(wù) 百分比。 8、 Transaction Response Time（Distribution） （事務(wù)響應(yīng)時間 （分布 ）） “事務(wù)響應(yīng)時間 （分布） ”顯示在場景運行過程中，事務(wù)執(zhí)行所用時間的分布，通過它可以了解 測試過程中不同響應(yīng)時間的事務(wù)數(shù)量。 如果系統(tǒng)預先定義了相關(guān)事務(wù)可以接受的最小和最大 事務(wù)響應(yīng)時間，則可以使用此圖確定服務(wù)器性能是否在可以接受的范圍內(nèi)。 Web Resources（ Web 資源分析） Web 資源分析是從服務(wù)器入手對 Web 服務(wù)器的性能分析。 1、 Hits per Seco nd （

25、每秒點擊次數(shù)） 每秒點擊次數(shù)”，即使運行場景過程中虛擬用戶每秒向 Web服務(wù)器提交的HTTP請求數(shù)。 通過它可以評估虛擬用戶產(chǎn)生的負載量， 如將其和 “平均事務(wù)響應(yīng)時間 ”圖比較， 可以查看點 擊次數(shù)對事務(wù)性能產(chǎn)生的影響。通過對查看 “每秒點擊次數(shù) ”，可以判斷系統(tǒng)是否穩(wěn)定。系統(tǒng) 點擊率下降通常表明服務(wù)器的響應(yīng)速度在變慢，需進一步分析，發(fā)現(xiàn)系統(tǒng)瓶頸所在。 2、 Throughput （吞吐率） “吞吐率 ”顯示的是場景運行過程中服務(wù)器的每秒的吞吐量。 其度量單位是字節(jié)， 表示虛擬用 在任何給定的每一秒從服務(wù)器獲得的數(shù)據(jù)量。 可以依據(jù)服務(wù)器的吞吐量來評估虛擬用戶產(chǎn)生的負載量， 以及看出

26、服務(wù)器在流量方面的處理 能力以及是否存在瓶頸。 “吞吐率”圖和“點擊率 ”圖的區(qū)別： 吞吐率”圖，是每秒服務(wù)器處理的 HTTP申請數(shù)。 “點擊率 ”圖，是客戶端每秒從服務(wù)器獲得的總數(shù)據(jù)量。 3、 HTTP Status Code Summary（ HTTP狀態(tài)代碼概要） “ HTT狀態(tài)代碼概要”顯示場景或會話步驟過程中從 Web服務(wù)器返回的 HTTP狀態(tài)代碼數(shù)， 該圖按照代碼分組。HTTP狀態(tài)代碼表示HTTP請求的狀態(tài)。 4、 HTTP Responses per Second （每秒 HTTP 響應(yīng)數(shù)） 每秒HTTP響應(yīng)數(shù)”是顯示運行場景過程中每秒從 Web服務(wù)器返回的不同

27、HTTP狀態(tài)代碼的 數(shù)量， 還能返回其它各類狀態(tài)碼的信息， 通過分析狀態(tài)碼， 可以判斷服務(wù)器在壓力下的運行 情況，也可以通過對圖中顯示的結(jié)果進行分組，進而定位生成錯誤的代碼腳本。 5、 Pages Downloader per Second （每秒下載頁面數(shù)） “每秒下載頁面數(shù) ”顯示場景或會話步驟運行的每一秒內(nèi)從服務(wù)器下載的網(wǎng)頁數(shù)。 使用此圖可 依據(jù)下載的頁數(shù)來計算 Vuser 生成的負載量。 和吞吐量圖一樣，每秒下載頁面數(shù)圖標是 Vuser 在給定的任一秒內(nèi)從服務(wù)器接收到的數(shù)據(jù) 量。但是吞吐量考慮的各個資源極其大小（例，每個 GIF文件的大小、每個網(wǎng)頁的大?。? 而每秒下載頁面

28、數(shù)只考慮頁面數(shù)。 注：要查看每秒下載頁數(shù)圖，必須在 R-T-S那里設(shè)置每秒頁面數(shù)（僅HTML模式）” 6、 Retries per Second （每秒重試次數(shù)） “每秒重試次數(shù)”顯示場景或會話步驟運行的每一秒內(nèi)服務(wù)器嘗試的連接次數(shù)。 在下列情況將重試服務(wù)器連接： A、 初始連接未經(jīng)授權(quán) B、 要求代理服務(wù)器身份驗證 C、 服務(wù)器關(guān)閉了初始連接 D、 初始連接無法連接到服務(wù)器 E、 服務(wù)器最初無法解析負載生成器的 IP地址 7、 Retries Summary （重試次數(shù)概要） “重試次數(shù)概要”顯示場景或會話步驟運行過程中服務(wù)器嘗試的連接次數(shù)， 它按照重試原因分 組。將此圖與

29、每秒重試次數(shù)圖一起使用可以確定場景或會話步驟運行過程中服務(wù)器在哪個時 間點進行了重試。 8、 Connections （連接數(shù)） 連接數(shù)”顯示場景或會話步驟運行過程中每個時間點打開的 TCP/IP連接數(shù)。 借助此圖，可以知道何時需要添加其他連接。 例：當連接數(shù)到達穩(wěn)定狀態(tài)而事務(wù)響應(yīng)時間迅速增大時， 添加連接可以使性能得到極大提高 （事務(wù)響應(yīng)時間將降低）。 9、 Connections Per Second （每秒連接數(shù)） 每秒連接數(shù)”顯示方案在運行過程中每秒建立的 TCP/IP連接數(shù)。 理想情況下，很多 HTTP請求都應(yīng)該使用同一連接，而不是每個請求都新打開一個連接。通 過每秒連

30、接數(shù)圖可以看出服務(wù)器的處理情況，就表明服務(wù)器的性能在逐漸下降。 10、 SSLs Per Seco nd（每秒 SSL連接數(shù)） 每秒SSL連接數(shù)”顯示場景或會話步驟運行的每一秒內(nèi)打開的新的以及重新使用的 SSL連接 數(shù)。當對安全服務(wù)器打開 TCP/IP連接后，瀏覽器將打開 SSL連接。 Web Page Breakdown （網(wǎng)頁元素細分） “網(wǎng)頁元素細分”主要用來評估頁面內(nèi)容是否影響事務(wù)的響應(yīng)時間， 通過它可以深入地分析網(wǎng) 站上那些下載很慢的圖形或中斷的連接等有問題的 1、Web Page Breakdown （頁面分解總圖） “頁面分解”顯示某一具體事務(wù)在測試過程的響應(yīng)情況，進

31、而分析相關(guān)的事務(wù)運行是否正常。 “頁面分解”圖可以按下面四種方式進行進一步細分： 1） 、 Download Time Breaddown （下載時間細分） “下載時間細分”圖顯示網(wǎng)頁中不同元素的下載時間，同時還可按照下載過程把時間進行分 解，用不同的顏色來顯示 DNS解析時間、建立連接時間、第一次緩沖時間等各自所占比例。 2） 、Component Breakdown（Over Time） （組件細分 （隨時間變化 ）） “組件細分”圖顯示選定網(wǎng)頁的頁面組件隨時間變化的細分圖。 通過該圖可以很容易的看出哪 些元素在測試過程中下載時間不穩(wěn)定。該圖特別適用于需要在客戶端下載控件較多的頁

32、面， 通過分析控件的響應(yīng)時間，很容易就能發(fā)現(xiàn)那些控件不穩(wěn)定或者比較耗時。 3） 、 Download Time Breakdown（Over Time） （下載時間細分 （隨時間變化 ）） 下載時間細分（隨時間變化）”圖顯示選定網(wǎng)頁的頁面元素下載時間細分 （隨時間變化）情況, 它非常清晰地顯示了頁面各個元素在壓力測試過程中的下載情況。 下載時間細分”圖顯示的是整個測試過程頁面元素響應(yīng)的時間統(tǒng)計分析結(jié)果， 下載時間細 分（隨時間變化）"顯示的事場景運行過程中每一秒內(nèi)頁面元素響應(yīng)時間的統(tǒng)計結(jié)果， 兩者分別 從宏觀和微觀角度來分析頁面元素的下載時間。 4）、Time to First B

33、uffer Breakdown（Over Time）（第一次緩沖時間細分 （隨時間變化）） 第一次緩沖時間細分（隨時間變化）圖顯示成功收到從 Web服務(wù)器返回的第一次緩沖之前 的這段時間，場景或會話步驟運行的每一秒中每個網(wǎng)頁組件的服務(wù)器時間和網(wǎng)絡(luò)時間 （以秒 為單位）。可以使用該圖確定場景或會話步驟運行期間服務(wù)器或網(wǎng)絡(luò)出現(xiàn)問題的時間。 First Buffer Time :是指客戶端與服務(wù)器端建立連接后， 從服務(wù)器發(fā)送第一個數(shù)據(jù)包開始計時， 數(shù)據(jù)經(jīng)過網(wǎng)絡(luò)傳送到客戶端，到瀏覽器接收到第一個緩沖所用的時間。 2、 Page Component Breakdown （頁面組件細分） 頁

34、面組件細分”圖顯示每個網(wǎng)頁及其組件的平均下載時間（以秒為單位）?？梢愿鶕?jù)下載組 件所用的平均秒數(shù)對圖列進行排序，通過它有助于隔離有問題的組件。 3、 Page Component Breakdown（Over Time）（頁面組件分解（隨時間變化）） 頁面組件分解（隨時間變化）圖顯示在方案運行期間的每一秒內(nèi)每個網(wǎng)頁及其組件的平均響 應(yīng)時間（以秒為單位）。 4、 Page Download Time Breakdown （頁面下載時間細分） 頁面下載時間細分”圖顯示每個頁面組件下載時間的細分， 可以根據(jù)它確定在網(wǎng)頁下載期間 事務(wù)響應(yīng)時間緩慢是由網(wǎng)絡(luò)錯誤引起還是由服務(wù)器錯誤引起。 頁面

35、下載時間細分”圖根據(jù)DNS解析時間、連接時間、第一次緩沖時間、 SSL握手時間、接 收時間、FTP驗證時間、客戶端時間和錯誤時間來對每個組件的下載過程進行細分。 5、 Page Download Time Breakdown（Over Time）（頁面下載時間細分 （隨時間變化）） 頁面下載時間細分（隨時間變化）圖顯示方案運行期間，每一秒內(nèi)每個頁面組件下載時間的 細分。使用此圖可以確定網(wǎng)絡(luò)或服務(wù)器在方案執(zhí)行期間哪一時間點發(fā)生了問題。 頁面組件細分（隨時間變化）圖和 頁面下載時間細分（隨時間變化）圖通常結(jié)合起來進行分 析：首先確定有問題的組件，然后分析它們的下載過程，進而定位原因在哪里。

36、 6、 Time to First Buffer Breakdown （第一次緩沖時間細分） 第一次緩沖時間細分”圖顯示成功收到從 Web服務(wù)器返回的第一次緩沖之前的這一段時間 內(nèi)的每個頁面組件的相關(guān)服務(wù)器 /網(wǎng)路時間。如果組件的下載時間很長，則可以使用此圖確 定產(chǎn)生的問題與服務(wù)器有關(guān)還是與網(wǎng)絡(luò)有關(guān)。 網(wǎng)絡(luò)時間：定義為第一個 HTTP請求那一刻開始，直到確認為止所經(jīng)過的平均時間。 服務(wù)器時間：定義為從收到初始 HTTP請求確認開始，直到成功收到來自 Web服務(wù)器的一次 緩沖為止所經(jīng)過的平均時間。 7、 Time to First Buffer Breakdown（Over Time

37、）（第一次緩沖時間細分 （隨時間變化）） 第一次緩沖時間細分（隨時間變化）圖顯示成功收到從 Web服務(wù)器返回的第一個緩沖之前 的這段時間內(nèi)，場景運行的每一秒中每個網(wǎng)頁組件的服務(wù)器時間和網(wǎng)絡(luò)時間。 可以使用此圖 確定場景運行期間服務(wù)器或網(wǎng)絡(luò)出現(xiàn)問題的時間點。 & Downloader Component Size（KB）（已下載組件大小） 已下載組件大小”圖顯示每個已經(jīng)下載的網(wǎng)頁組建的大小。 通過它可以直接看出哪些組件比 較大并需要進一步進行優(yōu)化以提高性能。 性能測試（并發(fā)負載壓力）測試分析-簡要篇 在論壇混了多日，發(fā)現(xiàn)越來越多的 性能測試 工程師基本上都能夠掌握利用測試工具來作

38、負載 壓力測試，但多數(shù)人對怎樣去分析工具收集到的測試結(jié)果感到無從下手， 下面我就把個人工作中的體會和收集到的有關(guān)資料整理出來，希望能對大家分析測試結(jié)果有所幫助。 分析原則： ? 具體問題具體分析（這是由于不同的應(yīng)用系統(tǒng)，不同的測試目的，不同的性能關(guān)注點） ? 查找瓶頸時按以下順序，由易到難。 服務(wù)器硬件瓶頸 -〉網(wǎng)絡(luò)瓶頸（對局域網(wǎng)，可以不考慮） -〉服務(wù)器操作系統(tǒng)瓶頸（參數(shù) 配置） -〉中間件瓶頸（參數(shù)配置，數(shù)據(jù)庫， web 服務(wù)器等） -〉應(yīng)用瓶頸（ SQL 語句、數(shù)據(jù) 庫設(shè)計、業(yè)務(wù)邏輯、算法等） 注：以上過程并不是每個分析中都需要的，要根據(jù)測試目的和要求來確定分析的深度。 對

39、一些要求低的，我們分析到應(yīng)用系統(tǒng)在將來大的負載壓力（并發(fā)用戶數(shù)、數(shù)據(jù)量）下，系 統(tǒng)的硬件瓶頸在哪兒就夠了。 ? 分段排除法 很有效 分析的信息來源： ?1 根據(jù)場景運行過程中的錯誤提示信息 ?2 根據(jù)測試結(jié)果收集到的監(jiān)控指標數(shù)據(jù) 一．錯誤提示分析 分析實例： 1 ?Error: Failed to connect to server “ 10.10 [10.3008 0C8o0nnection ?Error: timed out Error: Server w10hafts1Sh80dow n the connection prematurely 分析：

40、 ?A、應(yīng)用服務(wù)死掉。 （小用戶時：程序上的問題。程序上處理數(shù)據(jù)庫的問題） ?B、應(yīng)用服務(wù)沒有死 （應(yīng)用服務(wù)參數(shù)設(shè)置問題） 例：在許多客戶端連接 Weblogic 應(yīng)用服務(wù)器被拒絕，而在服務(wù)器端沒有錯誤顯示，則有 可能是 Weblogic 中的 server 元素的 AcceptBacklog 屬性值設(shè)得過低。如果連接時收到 conn ection refused消息，說明應(yīng)提高該值，每次增加 25% ?C、數(shù)據(jù)庫的連接 （1、在應(yīng)用服務(wù)的性能參數(shù)可能太小了 2、數(shù)據(jù)庫啟動的最大連接數(shù) （跟硬件的內(nèi)存有關(guān)）） 2 Error: Page dow nl oad timeout

41、（120 sec on ds） has expired 分析：可能是以下原因造成 ?A、應(yīng)用服務(wù)參數(shù)設(shè)置太大導致服務(wù)器的瓶頸 ?B、頁面中圖片太多 ?C 、在程序處理表的時候檢查字段太大多 二?監(jiān)控指標數(shù)據(jù)分析 1 ?最大并發(fā)用戶數(shù)： 應(yīng)用系統(tǒng)在當前環(huán)境（硬件環(huán)境、網(wǎng)絡(luò)環(huán)境、軟件環(huán)境（參數(shù)配置））下能承受的最大并發(fā) 用戶數(shù)。 在方案運行中，如果出現(xiàn)了大于 3個用戶的業(yè)務(wù)操作失敗，或出現(xiàn)了服務(wù)器 shutdown 的情況，則說明在當前環(huán)境下， 系統(tǒng)承受不了當前并發(fā)用戶的負載壓力， 那么最大并發(fā)用戶 數(shù)就是前一個沒有出現(xiàn)這種現(xiàn)象的并發(fā)用戶數(shù)。 如果測得的最大并發(fā)用戶數(shù)到達了性

42、能要求，且各服務(wù)器資源情況良好，業(yè)務(wù)操作響應(yīng) 時間也達到了用戶要求，那么 OK。否則，再根據(jù)各服務(wù)器的資源情況和業(yè)務(wù)操作響應(yīng)時間 進一步分析原因所在。 2 .業(yè)務(wù)操作響應(yīng)時間： ?分析方案運行情況應(yīng)從平均事務(wù)響應(yīng)時間圖和事務(wù)性能摘要圖開始。 使用事務(wù)性能摘 要”圖，可以確定在方案執(zhí)行期間響應(yīng)時間過長的事務(wù)。 ?細分事務(wù)并分析每個頁面組件的性能。查看過長的事務(wù)響應(yīng)時間是由哪些頁面組件引起 的？問題是否與網(wǎng)絡(luò)或服務(wù)器有關(guān)？ ?如果服務(wù)器耗時過長，請使用相應(yīng)的服務(wù)器圖確定有問題的服務(wù)器度量并查明服務(wù)器性能 下降的原因。如果網(wǎng)絡(luò)耗時過長，請使用 網(wǎng)絡(luò)監(jiān)視器”圖確定導致性能瓶頸的網(wǎng)絡(luò)問題

43、性能測試之場景設(shè)計思想 前段時間有幸收到珠海 X公司性能題目，呵呵，以下是對公司產(chǎn)品性能測試的總結(jié)。個人認 為有關(guān)性能測試場景問題，其實更佳著重于對性能測試目的考究。 驗證測試是用于驗證在特定的場景、 時間、壓力、環(huán)境和操作方式下系統(tǒng)能夠正常的運 行，服務(wù)器、應(yīng)用系統(tǒng)和網(wǎng)絡(luò)環(huán)境等軟硬件設(shè)施還能否良好的支撐這些情況下用戶的使用。 驗證性測試主要針對有明確的壓力目標和預期結(jié)果， 驗證系統(tǒng)在這種壓力下的各方面反映能 夠達到預期結(jié)果。 主要分以下幾種： 壓力測試：已知系統(tǒng)高峰期使用人數(shù)，驗證各事務(wù)在最大并發(fā)數(shù)（通過高峰期人數(shù)換算） 下事務(wù)響應(yīng)時間能夠達到客戶要求。系統(tǒng)各性能指標在這種壓力下

44、是否還在正常數(shù)值之內(nèi)。 系統(tǒng)是否會因這樣的壓力導致不良反應(yīng)（如：宕機、應(yīng)用異常中止等）。 Ramp Up增量設(shè)計：如并發(fā)用戶為 75人，系統(tǒng)注冊用戶為 1500人，以5%— 7%作為 并發(fā)用戶參考值。一般以每15s加載5人的方式進行增壓設(shè)計， 該數(shù)值主要參考測試加壓機 性能，建議Run幾次。以事務(wù)通過率與錯誤率衡量實際加載方式。 Ramp Up增量設(shè)計目標： 尋找已增量方式加壓系統(tǒng)性能瓶頸位置，抓住出現(xiàn)的性能拐 點時機，一般常用參考 Hits點擊率與吞吐量、CPU內(nèi)存使用情況綜合判斷。模擬高峰期使 用人數(shù)，如早晨的登錄，下班后的退出，工資發(fā)送時的消息系統(tǒng)等。 另一種極限模擬方式，可視為

45、在峰值壓力情況下同時點擊事務(wù)操作的系統(tǒng)極限操作指 標。加壓方式不變，在各腳本事務(wù)點中設(shè)置同集合點名稱（如： lr_ren dzvous（"same";） 在場景設(shè)計中，使用事務(wù)點集合策略。 以同時達到集合點百分率為標準， 同時釋放所有正在 Run 的 Vuser。 穩(wěn)定性測試：已知系統(tǒng)高峰期使用人數(shù)、 各事務(wù)操作頻率等。設(shè)計綜合測試場景，測試 時將每個場景按照一定人數(shù)比率一起運行， 模擬用戶使用數(shù)年的情況。并監(jiān)控在測試中，系 統(tǒng)各性能指標在這種壓力下是否能保持正常數(shù)值。 事務(wù)響應(yīng)時間是否會出現(xiàn)波動或隨測試時 間增漲而增加。系統(tǒng)是否會在測試期間內(nèi)發(fā)生如宕機、應(yīng)用中止等異常情況。 根

46、據(jù)上述測試中，各事務(wù)條件下出現(xiàn)性能拐點的位置， 已確定穩(wěn)定性測試并發(fā)用戶人數(shù)。 仍然根據(jù)實際測試服務(wù)器（加壓機、應(yīng)用服務(wù)器、數(shù)據(jù)服務(wù)器三方性能），估算最終并發(fā)用 戶人數(shù)。 場景設(shè)計思想：從穩(wěn)定性測試場景的設(shè)計意義，應(yīng)分多種情況考慮： 針對同一個場景為例，以下以公文附件上傳為例簡要分析場景設(shè)計思想： 1） 場景一：已壓力測試環(huán)境下性能拐點的并發(fā)用戶為設(shè)計測試場景，目的驗證極限壓 力情況下測試服務(wù)器各性能指標。 2） 場景二：根據(jù)壓力測試環(huán)境中 CPU內(nèi)存等指標選取服務(wù)器所能承受最大壓力的 50% 來確定并發(fā)用戶數(shù)。 測試方法：采用 1)Ramp Up-Load all Vusers

47、simultaneously 2）Duration-Run Indefinitely 3）在 Sechedule-勾選 Initalize all Vusers before Run 容錯性測試：通過模擬一些非正常情況（如：服務(wù)器突然斷電、網(wǎng)絡(luò)時斷時續(xù)、服務(wù)器 硬盤空間不足等） ，驗證系統(tǒng)在發(fā)生這些情況時是否能夠有自動處理機制以保障系統(tǒng)的正常 運行或恢復運行措施。如有 HA （自動容災系統(tǒng)），還可以專門針對這些自動保護系統(tǒng)進行 另外的測試。驗證其能否有效觸發(fā)保護措施。 問題排除性測試： 通過原有案例或經(jīng)驗判斷， 針對系統(tǒng)中曾經(jīng)發(fā)生問題或懷疑存在隱患 的模塊進行驗證測試。 驗證這些模塊

48、是否還會發(fā)生同樣的性能問題。 如： 上傳附件模塊的內(nèi) 存泄露問題、地址本模塊優(yōu)化、開啟 Tivoli性能監(jiān)控對0A系統(tǒng)性能的影響等等。 測評測試是用于獲取系統(tǒng)的關(guān)鍵性能指標點， 而進行的相關(guān)測試。 主要是針對預先沒有 明確的預期測試結(jié)果， 而是要通過測試獲取在特定壓力場景下的性能指標 （如：事務(wù)響應(yīng)時 間、最大并發(fā)用戶數(shù)等）。 評測事務(wù)交易時間： 為獲取某事務(wù)在特定壓力下的響應(yīng)時間而進行的測試活動。 通過模 擬已知客戶高峰期的各壓力值或預期所能承受的壓力值，獲取事務(wù)在這種壓力下的響應(yīng)時 間。 評測事務(wù)最大并發(fā)用戶數(shù)： 為獲取某事務(wù)在特定系統(tǒng)環(huán)境下所能承受的最大并發(fā)用戶數(shù) 而進行的測試活

49、動。 通過模擬真實環(huán)境或直接采用真實環(huán)境， 評測在這種環(huán)境下事務(wù)所能承 受的最大并發(fā)用戶數(shù)。判定標準閾值需預先定義（如響應(yīng)時間， CPU占用率，內(nèi)存占用率， 已出現(xiàn)點擊率峰值，已出現(xiàn)吞吐量峰值等）。 評測系統(tǒng)最大并發(fā)用戶數(shù)： 為獲取整個系統(tǒng)所能夠承受的最大并發(fā)用戶數(shù)而進行的的測 試活動。 通過預先分析項目各主要模塊的使用比率和頻率， 定義各事務(wù)在綜合場景中所占的 比率， 以比率方式分配各事務(wù)并發(fā)用戶數(shù)。 模擬真實環(huán)境或直接采用真實環(huán)境， 評測在這種 環(huán)境下系統(tǒng)所能承受的最大并發(fā)用戶數(shù)。 判定標準閥值預先定義 （如響應(yīng)時間，CPU占用率, 內(nèi)存占用率，已出現(xiàn)點擊率峰值，已出現(xiàn)吞吐量峰值等）

50、。取值標準以木桶法則為準（并發(fā) 數(shù)最小的事務(wù)為整個系統(tǒng)的并發(fā)數(shù)）。 評測不同數(shù)據(jù)庫數(shù)據(jù)量對性能的影響： 針對不同數(shù)據(jù)庫數(shù)據(jù)量的測試， 將測試結(jié)果進行 對比，分析發(fā)現(xiàn)數(shù)據(jù)庫中各表的數(shù)據(jù)量對事務(wù)性能的影響。 得以預先判斷系統(tǒng)長時間運行后， 或某些模塊客戶要求數(shù)據(jù)量較大時可能存在的隱患。 問題定位測試在通過以上測試或用戶實際操作已經(jīng)發(fā)現(xiàn)系統(tǒng)中的性能問題或懷疑已存 在性能問題。 需通過響應(yīng)的測試場景重現(xiàn)問題或定義問題。 如有可能， 可以直接找出引起性 能問題所在的代碼或模塊。 該類測試主要還是通過測試出問題的腳本場景， 并可以增加發(fā)現(xiàn)和檢測的工具， 如開啟 Tivoli 性能監(jiān)控、開啟 HeapDump 輸出、 Linux 資源監(jiān)控命令等。并在場景運行過程中輔以手 工測試。