性能測試方法及分析報告方法

標準文案標準文案大全大全性能測試方法及分析方法一、性能測試簡介什么是軟件性能性能是軟件產(chǎn)品的一種特性，可以用時間來進展度量。性能的準時性用響應時間或者吞吐量來衡量。響應時間是對懇求作出響應所需要的時間。OK按鈕后2應時間?！瞁eb述系統(tǒng)的性能，而對非交互式應用〔嵌入式系統(tǒng)或是銀行等的業(yè)務處理系統(tǒng)〕而言，響應時間是指系統(tǒng)對大事產(chǎn)生響應所需要的時間。品的開發(fā)人員也關注軟件性能，下面將從3用戶視角的軟件性能Web開頭到應用系統(tǒng)把本次操作的結果以用戶能覺察的方式呈現(xiàn)出來1.1以一個Web發(fā)出懇求 懇求應用效勞器 DB效勞器用戶用戶感受到響應

應用界面呈現(xiàn)

返回數(shù)據(jù)呈現(xiàn)時間 系統(tǒng)響應時間1.1Web必需要說明的是，用戶所體會到的“響應時間”既有客觀的成分，也有主觀的成分。例〔順便說一下，這種技巧是在C/S。1.2.1節(jié)對“響應時間”的解釋。治理員視角的軟件性能外，他還會關心和系統(tǒng)狀態(tài)相關的信息。例如，治理員已經(jīng)知道，在并發(fā)用戶數(shù)為100時，A8CPU了最大值？是否還有可用的內存？應用效勞器的狀態(tài)如何？我們設置的JVM可用內存是否足夠？數(shù)據(jù)庫的狀況如何？是否還需要進展一些調整？這些問題一般的用戶并不關心不在他們的體驗范圍之內；但對治理員來說，要保證系統(tǒng)的穩(wěn)定運行和持續(xù)的良好性能，就必需關心這些問題。況制定治理措施，在系統(tǒng)消滅打算之外的用戶增長等緊急狀況的時候能夠馬上制定相應措施，進展快速的處理；此外，治理員可能還會關心系統(tǒng)在長時間的運行中是否足夠穩(wěn)定，是否能夠不連續(xù)地供給業(yè)務效勞等。題。1-1治理員關心的問題軟件性能描述效勞器的資源使用狀況合理嗎治理員關心的問題軟件性能描述效勞器的資源使用狀況合理嗎資源利用率應用效勞器和數(shù)據(jù)庫的資源使用狀況合理嗎資源利用率系統(tǒng)是否能夠實現(xiàn)擴展系統(tǒng)可擴展性系統(tǒng)最多能支持多少用戶的訪問？系統(tǒng)最大的業(yè)務處理系統(tǒng)容量量是多少系統(tǒng)性能可能的瓶頸在哪里系統(tǒng)可擴展性更換哪些設備能夠提高系統(tǒng)性能系統(tǒng)可擴展性7×24系統(tǒng)穩(wěn)定性開發(fā)視角的軟件性能等治理員關心的內容，由于這些也是產(chǎn)品需要面對的用戶〔特別的用戶。但對開發(fā)人員來的性能表現(xiàn)到底是由于系統(tǒng)架構選擇的不合理還是由于代碼實現(xiàn)的問題引起？由于數(shù)據(jù)庫設計的問題引起？抑或是由于系統(tǒng)的運行環(huán)境引發(fā)？是否存在由于內存處理等問題引起的系統(tǒng)故障？因此，對開發(fā)人員來說，單純獲知系統(tǒng)性能“好”或者“不好”的評價并沒有太大的意1-21-2開發(fā)人員關注的性能問題開發(fā)人員關心的問題開發(fā)人員關心的問題問題所屬層次架構設計是否合理系統(tǒng)架構數(shù)據(jù)庫設計是否存在問題數(shù)據(jù)庫設計代碼是否存在性能方面的問題代碼系統(tǒng)中是否有不合理的內存使用方式代碼系統(tǒng)中是否存在不合理的線程同步方式設計與代碼系統(tǒng)中是否存在不合理的資源競爭設計與代碼總結以上我們描述了3用戶對性能的理解屬于“用戶視角〔包括設計人員〕自然就是從“開發(fā)視角”來關注軟件性能了。用戶的角度來說，表現(xiàn)為軟件系統(tǒng)對用戶操作的響應時間；在系統(tǒng)或是治理員的關注層面，和引起性能問題的關鍵緣由。軟件性能的幾個術語性能計數(shù)器，在使用性能測試工具進展測試時，還會接觸到“思考時間ThinkTim”的概念，那么，這些術語的精準含義到底是什么呢？本節(jié)重點介紹以上的各個術語。響應時間1.11.1.1圖1.1〔響應時間Web性能測試中，我們并不關注“呈現(xiàn)時間表現(xiàn)，例如，一臺內存缺乏的客戶端機器在處理簡潔頁面的時候，其呈現(xiàn)時間可能就很長，應時間”和“響應時間1.2描述了一個Web中可以看到，頁面的響應時間可被分解為“網(wǎng)絡傳輸時間〔N1+N2+N3+N〕A1+A2+A，而“應用延遲時間”又可以分解為“數(shù)據(jù)庫延遲時間〔A〕和“應用效勞A1+A。之所以要對響應時間進展這些分解，主要目的是為了能更好定位能問題的定位。1.2Web用戶主觀顏色，也就是說，響應時間的“長”和“短”沒有確定的區(qū)分。例如，對一個電子商務網(wǎng)站來說，在美國和歐洲，一個普遍被承受的響應時間標準為2/5/10秒，也就是說，在2秒之內給客戶響應被用戶認為是“格外有吸引力的5內響應客戶被認為是“比較不錯的10秒是客戶能承受的響應的上限。2小時以上進行數(shù)據(jù)的錄入，當用戶單擊“提交”按鈕后，即使系統(tǒng)在20分鐘后才給出“處理成功”的操作來說，20因此，在進展性能測試時試人員自己的設想來打算。并發(fā)用戶數(shù)在闡述這個術語之前，先來看看為什么在性能測試中需要關注這個“并發(fā)用戶數(shù)弄清楚會有多少用戶會在同一個時間段內訪問被測試的系統(tǒng)就是我們說的并發(fā)用戶數(shù)的一個概念，這種并發(fā)的概念通常在性能測試〔PerformanceTesting〕C/S或是B/S應用來說，系統(tǒng)的性能表現(xiàn)毫無疑問地主要由“效勞端”打算。在什么時候“效勞端”會承受最大的壓力，或者說，在什么時候“效勞端”表現(xiàn)為最差的性能呢？毫無疑問，確定是在大量用戶同時對這個系統(tǒng)進展訪問的時候。為了說明這個“同時1.。1.3用排球擊打墻面圖1.3用“排球擊打墻面”說明這種“同時描述的是同時向客戶端發(fā)出懇求的客戶，該概念一般結合并發(fā)測試〔ConcurrencyTesting〕使用，表達的是效勞端承受的最大并發(fā)訪問數(shù)。下面我們用一個更接近實際的例子來說明這兩個并發(fā)概念之間的不同。1.4應用界面效勞器VU應用界面效勞器VUVU2

VUG1.4實際應用系統(tǒng)用戶的懇求執(zhí)行某些操作，然后將結果返回給用戶。從用戶的角度來看，在一個相當長的時間段內〔例如1天念就是前面爭論的業(yè)務并發(fā)用戶數(shù)。的運行過程中，把整個運行過程劃分為離散的時間點，在每個點上，都有一個“同時向效勞壓力最大，資源承受的壓力也最大，在這種狀態(tài)下，可以考慮通過并發(fā)測試〔ConcurrencyTesting〕覺察系統(tǒng)中存在的并發(fā)引起的資源爭用等問題。在實際的性能測試中，常常接觸到的與并發(fā)用戶數(shù)相關的概念還包括“并發(fā)用戶數(shù)”、“系統(tǒng)用戶數(shù)”和“同時在線用戶人數(shù)假設有一個OA2023OA用戶總數(shù)是2023名，這個概念就是“系統(tǒng)用戶數(shù)〔用一個全局變量計數(shù)全部已登錄的用戶，從在線統(tǒng)計功能中可以得到，最頂峰時有500人在線〔這個500就是一般所說的“同時在線人數(shù)，那么，系統(tǒng)的并發(fā)用戶數(shù)是多少呢？依據(jù)我們對業(yè)務并發(fā)用戶數(shù)的定義，這500就是整個系統(tǒng)使用時最大的業(yè)務并發(fā)用戶數(shù)。固然，500500器承受的壓力。由于效勞器承受的壓力還與具體的用戶訪問模式相關。例如，在這500個“同時使用系統(tǒng)”的用戶中，考察某一個時間點，在這個時間上，假設其中40%的用戶在饒有興致地看系統(tǒng)公告〔，20〔對用戶填寫的表格來說，只有在“提交”的時刻才會向效勞端發(fā)送懇求，填寫過程是不對效勞端構成壓力的，20〔也就是什么也沒有做，剩下的20%用戶在不停地從一個頁面跳轉到另一個頁面——在這種場景下，可以說，只有20%不只取決于業(yè)務并發(fā)用戶數(shù)，還取決于用戶的業(yè)務場景。業(yè)務場景，一般可以通過對效勞器日志的分析得到。并發(fā)用戶數(shù)進展爭論，而且，為了便利，直接將業(yè)務并發(fā)用戶數(shù)稱為并發(fā)用戶數(shù)。那么，到底應當如何獲得測試人員關心的并發(fā)用戶數(shù)的具體數(shù)值呢？下面給出了一些用于估算并發(fā)用戶數(shù)的公式。nLCT 〔1〕CC3C

〔2〕loginsession的平均長度；TOA應用，考察的時間段長度應當8公式2〕則給出了并發(fā)用戶數(shù)峰值的計算方式，其中，?C就是公式〔1〕中得到的平均的并發(fā)用戶數(shù)。該公式的得出是假設用戶的loginsession符合泊松分布而估算得到的。下面依據(jù)上述給出的方法進展實例計算。OA30004004小時，在8則依據(jù)公式〕和公式2，可以得到：C=400×4/8=200200200+3×200

=242loginsession算這兩個值并不簡潔。另外，考慮到用戶的業(yè)務操作存在確定的時間集中〔也就是說，用戶對系統(tǒng)業(yè)務的訪問往往不是平均分布在整個考察時間段內時間段內，承受公式〕和公式〕進展計算照舊存在確定的偏差。我們給出對該公式使用的一些建議1個小時為考察時間的粒度，對一個OA8在的時間集中性的問題。301日前夕會有大量用戶的訪問……因此多考慮一些可能發(fā)生的場景，基于這些場景進展估算。Web〔固然精度更差〕閱歷公式是：Cn10 〔3〕rC 〔4〕也就是說，用每天訪問系統(tǒng)用戶數(shù)的10%作為平均的并發(fā)用戶數(shù)，并發(fā)用戶數(shù)的最大值由并發(fā)用戶數(shù)乘上一個調整因子r得到，r2～3。公式〔3〕和公式〔4〕可以在要求不太嚴格的性能測試，或是只有很少數(shù)據(jù)支持分析的性能測試中使用。在本節(jié)的前面局部提到了“日志分析”方法。所謂“日志分析”方法是指通過對應用效勞并發(fā)用戶訪問數(shù)”數(shù)據(jù)。這種方式得到的數(shù)據(jù)準確度和可信度都比較高，對于Internet用等無法估量用戶數(shù)量和用戶行為模式的應用，這種方式最為可信。吞吐量吞吐量是指“單位時間內系統(tǒng)處理的客戶懇求的數(shù)量/秒或是頁面數(shù)/秒來衡量，從業(yè)務的角度，吞吐量也可以用訪問人數(shù)/天或是處理的業(yè)務數(shù)/節(jié)數(shù)/天來考察網(wǎng)絡流量。例如，對一個Web應用系統(tǒng)來說，從系統(tǒng)的處理力氣考慮，可以以頁面數(shù)/秒作為吞吐量的標準；對一個銀行的業(yè)務前臺系統(tǒng)來說，可以以其處理的業(yè)務數(shù)/小時作為吞吐量的標準。在本章的開頭局部，已經(jīng)爭論過，對于交互式應用，用戶直接的體驗是“響應時間吐量”來描述我們對系統(tǒng)性能的期望可能更加合理。對于交互式應用來說，吞吐量指標反映的是效勞器承受的壓力。在容量規(guī)劃的測試中，過程中，吞吐量指標也有重要的價值，例如，Empirix80%是由于吞吐量的限制導致的。在對Web系統(tǒng)的性能測試過程中，吞吐量主要以懇求數(shù)〔單擊數(shù)/字節(jié)數(shù)/秒來表達，吞吐量指標可以在兩個方面發(fā)揮作用：用于幫助設計性能測試場景，以及衡量性能測試場景是否到達了預期的設計目標：在設計性能測試場景時，吞吐量可被用于幫助設計性能測試場景，依據(jù)估算的吞吐量數(shù)據(jù)，吞吐量可以衡量測試是否到達了預期的目標。用于幫助分析性能瓶頸：吞吐量的限制是性能瓶頸的一種重要表現(xiàn)形式，因此，有針對性地對吞吐量設計測試，可以幫助盡快定位到性能瓶頸所在位置。例如，RBI〔RapidBottleneckIdentify〕方法就主要通過吞吐量測試覺察性能瓶頸。以不同方式表達的吞吐量可以說明不同層次的問題。例如，以字節(jié)數(shù)/秒方式表示的吞吐量主要受網(wǎng)絡根底設施、效勞器架構、應用效勞器制約；以單擊數(shù)/秒方式表示的吞吐量主要受應用效勞器和應用代碼的制約。到性能瓶頸的時候，吞吐量可以承受如下公式計算：FN其中，F(xiàn)表示吞吐量；N

R 〔5〕vuTvuVU〔VirtuaeUser，虛擬用戶〕的個數(shù)；RVUvu發(fā)出的懇求〔單擊〕數(shù)量；T表示性能測試所用的時間。但假設遇到了性能瓶頸，此時吞吐VU〔5〕給出的關系。常用于分析吞吐量的圖形是“吞吐量——VU1.5給出了兩個“吞吐量——VU從圖中可以看到，吞吐量在VU數(shù)量增長到確定程度的時候產(chǎn)生了性能瓶頸。本文給出了一個例如。1.5“吞吐量——VU對同一個應用進展兩次不同的性能測試，測試A100個并發(fā)，每個VU1出一個懇求；測試B1000VU10A，測試〔頁/秒100×1/1=100B〔頁/秒1000×1/10=100，100。但從測試結果來看，執(zhí)行測試A50/秒消滅性能瓶頸，而測試B25/秒消滅性能瓶頸。性能計數(shù)器〔Counte是描述效勞器或操作系統(tǒng)性能的一些數(shù)據(jù)指標系統(tǒng)來說，使用內存數(shù)MemoryInUsag，進程時間TotalProcessTim〕的計數(shù)器。器只能表達系統(tǒng)性能的某一個方面，對性能測試結果的分析必需基于多個不同的計數(shù)器。與性能計數(shù)器相關的另一個術語是“資源利用率/總的資源可用量”形成資源利用率的數(shù)據(jù)，用以進展各種資源使用的比較。10000Web效勞器的CPU占用率為68%，平均的內存占用率為556855在性能測試中常用資源利用率進展橫向的比照，例如，在進展測試時會覺察，資源A的使用率到達了接近100%的數(shù)值，而其他的資源利用率都處于比較低的水平，則可以很清楚A要結合響應時間變化曲線、系統(tǒng)負載曲線等各種指標進展分析。性能計數(shù)器是性能測試分析的主要參考值，本書的第3章對其進展了具體的解釋說明，并說明白如何利用這些計數(shù)器分析系統(tǒng)性能瓶頸。思考時間思考時間ThinkTim，也被稱為“休眠時間等待一段時間，再發(fā)出下一個懇求。各個操作之間等待一段時間，表達在腳本中，具體而言，就是在操作之間放置一個Think的函數(shù)，使得腳本在執(zhí)行兩個操作之間等待一段時間。在測試腳本中思考時間表達為腳本中兩個懇求語句之間的間隔時間不同的測試工具供給了不同的函數(shù)或者方法來實現(xiàn)思考時間，本書附錄A中對思考時間進展了的具體描述，另外，本書實踐篇也有一些使用思考時間的實際 例子。實，思考時間與迭代次數(shù)、并發(fā)用戶數(shù)和吞吐量之間存在確定的關系。公式〔5〕VUN、每個用戶發(fā)出懇求數(shù)RT的函數(shù)，而其中vuR又可以用時間T和用戶的思考時間T來計算：sTR 〔6〕Ts用公式〔5〕和公式〔6〕進展化簡運算可得，吞吐量與N成正比，而與T成反比。vu s步驟：首先計算出系統(tǒng)的并發(fā)用戶數(shù)；統(tǒng)計出系統(tǒng)平均的吞吐量；統(tǒng)計出平均每個用戶發(fā)出的懇求數(shù)量；依據(jù)公式〔6〕計算出思考時間。4計算得出的思考時間為基準，讓實際的思考時間在確定幅度內隨機變動。LoadRunner和SegueSilkPerformer等工具都支持以這種方式設置思考時間。最終要說明的是“00”作為思考時間，以給要求。由于從業(yè)務的角度考慮，思考時間用于更真實地模擬用戶操作，設置思考時間為0，根本上不具有實際的業(yè)務含義。但在非交互式應用的性能測試過程中，有時候確實會將思考時間設置為0，這時候是模擬一種盡可能大的壓力，爭論系統(tǒng)在巨大壓力下的表現(xiàn)。可以說，假設測試的目的是為了“驗證應用系統(tǒng)具有預期的力氣〔也就是所說的“力氣驗證”的應用領域，就應當盡量模擬用戶在使用業(yè)務時的真實思考時間；假設目的是進展更一般的爭論，例如“了解系統(tǒng)在壓力下的性能水平”或是“了解系統(tǒng)承受壓力的力氣”〔也就是所說的“規(guī)劃力氣”的應用領域，則可以承受0思考時間。二、性能測試方法論與方法簡潔成為一種任憑的測試行為，而任憑進展的性能測試很難取得實際的作用和預期的效果，因此本章將簡潔介紹幾種常見的性能測試過程和方法，并著重介紹常用的性能測試方法。性能測試方法論SEISEI負載測試打算過程〔SEILoadTestingPlanningProcess〕是一個關注于負載測試打算的方法，其目標是產(chǎn)生“清楚、易理解、可驗證的負載測試打算SEI負載測試打算過程包括6個關注的區(qū)域AreSEI負載測試打算過程將以上述6個區(qū)域作為負載測試打算需要重點關注和考慮的內容，其重點關注以下幾個方面的內容：產(chǎn)環(huán)境上的實際性能表現(xiàn)，為了躲避這個風險，必需認真設計測試環(huán)境。用戶分析：用戶是對被測應用系統(tǒng)性能表現(xiàn)最關注和受影響最大的對象，因此，必需通過對用戶行為進展分析，依據(jù)用戶行為模型建立用例和場景。用例：用例是用戶使用某種挨次和操作方式對業(yè)務過程進展實現(xiàn)的過程，對負載測現(xiàn)性能問題的風險等。SEISEI打算過程的一些關注內容，而沒有能夠形成實際的可操作的過程。段，但由于性能測試自身的特別性〔例如，需要引入工具，分析階段相對重要，性能測試過程又不能完全套用功能測試過程。SEI完整的測試過程。RBIRBI〔RapidBottleneckIdentify〕方法是Empirix性能瓶頸的方法。該方法基于以下一些事實：覺察的80%系統(tǒng)的性能瓶頸都由吞吐量制約；并發(fā)用戶數(shù)和吞吐量瓶頸之間存在確定的關聯(lián)；承受吞吐量測試可以更快速定位問題。RBI方法首先訪問效勞器上的“小頁面”和“簡潔應用保持根本全都的增長趨勢，通過不斷增加并發(fā)用戶數(shù)和吞吐量，觀看系統(tǒng)的性能表現(xiàn)。在確定具體的性能瓶頸時，RBI將性能瓶頸的定位依據(jù)一種“自上而下”的分析方式進展分析，首先確定是由并發(fā)還是由吞吐量引發(fā)的性能表現(xiàn)限制，然后從網(wǎng)絡、數(shù)據(jù)庫4RBI值得借鑒，但其也不是完整的性能測試過程。性能下降曲線分析法性能下降曲線實際上描述的是性能隨用戶數(shù)增長而消滅下降趨勢的曲線/主要是指響應時間。1.61.6一條典型的響應時間性能下降曲線例如1.6單用戶區(qū)域——對系統(tǒng)的一個單用戶的響應時間域可被用作基線或是benchmark。壓力區(qū)域——應用“略微下降”的地方。典型的、最大的建議用戶負載是壓力區(qū)域第三步第四步第三步第四步的開頭。性能拐點——性能開頭“急劇下降”的點。頸產(chǎn)生的地方。拐點，通過識別不同的區(qū)間和拐點，從而為性能瓶頸識別和性能調優(yōu)供給依據(jù)。LoadRunner第一步打算測試測試設計VU腳本創(chuàng)立測試場景運行測試場景分析結果其次步1.7給出了LoadRunner第一步打算測試測試設計VU腳本創(chuàng)立測試場景運行測試場景分析結果其次步第五步第六步1.7LoadRunner第五步第六步用例的設計；創(chuàng)立VU腳本階段主要依據(jù)設計的用例創(chuàng)立腳本；創(chuàng)立測試場景階段主要進展執(zhí)行，收集相應數(shù)據(jù)；分析結果階段主要進展結果分析和報告工作。LoadRunner供給的這共性能測試過程已經(jīng)涵蓋了性能測試工作的大局部內容，但由于該過程過于嚴密地與LoadRunner工具集成，沒有兼顧使用其他工具，或是用戶自行設計工具的需求，也不能被稱為是一個普適性的測試過程。另外，LoadRunner供給的該性能測試過程并未對打算測試階段、測試設計階段的具體行為、方法和目的進展具體描述，因此該方法最多只能被稱為“使用LoadRunner進展測試Segue圖1.8SegueSilkPerformerPerformanceTestingLifecycletry-checkSilkPerformer供給的性能測試過程從確定性能基線開頭，通過單用戶對應用的訪問獵取性能取值的基線，然后設定可承受的性能目標〔響應時間，用不同的并發(fā)用戶數(shù)等重復進展測試。Segue供給的這種性能測試方法格外適合性能調優(yōu)和性能優(yōu)化，通過不斷重復的try-check過程，可以逐一找到可能導致性能瓶頸的地方并對其進展優(yōu)化。EvaluateEvaluateDevelopTestAssetsDevelopExploratoryRe-BenchBaseLine&BenchmarkTuneSystemAnalyzeResultsTestsValidateReg’sCriteriaMetCompleteProject1.8SegueSilkPerformer但Segue供給的這共性能測試過程模型存在與LoadRunner的性能測試過程同樣的問題，出具體的活動和目標。性能測試的方法此外還存在其他的一些類型的性能測試方法。依據(jù)大范圍的性能測試的概念的界定，性能測試可包括如下幾種方法：性能測試PerformanceTestin；負載測試LoadTestin；壓力測試StressTestin；配置測試ConfigurationTestin；并發(fā)測試ConcurrencyTestin；牢靠性測試ReliabilityTestin；失效恢復測試FailoverTestin；性能測試〔PerformanceTesting〕性能測試〔PerformanceTesting〕方法是通過模擬生產(chǎn)運行的業(yè)務壓力氣和使用場景組合，測試系統(tǒng)的性能是否滿足生產(chǎn)性能要求。PerformanceTesting是一種最常見的測試方法，通俗地說，這種測試方法就是要在特定的運行條件下驗證系統(tǒng)的力氣狀況。這種方法的特點有：這種方法的主要目的是驗證系統(tǒng)是否有系統(tǒng)宣稱具有的力氣。有的力氣。這種方法需要事先了解被測試系統(tǒng)典型場景，并具有確定的性能目標。PerformanceTesting1005這種方法要求在已確定的環(huán)境下運行。PerformanceTesting〔硬件設備、軟件環(huán)境、網(wǎng)絡條件、根底數(shù)據(jù)等〕都已經(jīng)確定。負載測試〔LoadTesting〕負載測試〔LoadTesting〕方法通過在被測系統(tǒng)上不斷增加壓力，直到性能指標，例如“響應時間”超過預定指標或者某種資源使用已經(jīng)到達飽和狀態(tài)。這種測試放大可以找到系統(tǒng)的處理極限，為系統(tǒng)調優(yōu)供給數(shù)據(jù)。在某些狀況下，這種方法有時也被稱為可量性測試ScalabilityTestin。該方法有這樣一些特點：這種性能測試方法的主要目的是找到系統(tǒng)處理力氣的極限。LoadTesting方法通過“檢測-加壓-直到性能指標超過預期”的手段，其主要目的是120個并發(fā)用戶訪問”12100的性能指標”一般會被定義為“響應時間不超過10CPU65%”等指標。這種性能測試方法需要在給定的測試環(huán)境下進展與唯物壓力氣和典型場景，使得測試結果具有業(yè)務上的意義。LoadTesting方法由于涉及到“預定的性能指標”等需要進展比較的數(shù)據(jù)，也必需在給定的測試環(huán)境下進展。另外，LoadTesting方法在“加壓”的時候，必需選擇典型場景，在增加壓力時保證這種壓力具有業(yè)務上的意義。用。

這種性能測試方法是一般用來了解系統(tǒng)的性能容量，或是協(xié)作性能調優(yōu)來使LoadTesting方法可以用來了解系統(tǒng)的性能容量〔系統(tǒng)在保證確定響應時間的狀況下能夠允很多少并發(fā)用戶的訪問差異。壓力測試〔StressTesting〕壓力測試〔StressTesting〕方法測試系統(tǒng)在確定飽和狀態(tài)下，例如CPU、內存等在飽和使用狀況下，系統(tǒng)能夠處理的會話力氣，以及系統(tǒng)是否會消滅錯誤。StressTesting這種性能測試方法的主要目的是檢查系統(tǒng)處于壓力狀況下時，應用的表現(xiàn)。StressTesting方法通過增加訪問壓力〔例如，增加并發(fā)的用戶數(shù)量等有無出錯信息產(chǎn)生，系統(tǒng)對應用的響應時間等。一般狀況下，會把壓力設定為“CPU7570%以上”CPU和內存使用率JVMCPU作為壓力的依據(jù)。這種性能測試方法一般用于測試系統(tǒng)的穩(wěn)定性。用壓力測試的方法考察系統(tǒng)的穩(wěn)定性是出于這樣的考慮題。配置測試〔ConfigurationTesting〕配置測試〔ConfigurationTesting〕方法通過對被測系統(tǒng)的軟/硬件環(huán)境的調整，了解各種不同環(huán)境對系統(tǒng)性能影響的程度，從而找到系統(tǒng)各項資源的最優(yōu)安排原則。這種方法具有以下的特定：這種性能測試方法的主要目的是了解各種不同因素對系統(tǒng)性能影響的程度而推斷出最值得進展的調優(yōu)操作。的主要目的是了解各種因素對系統(tǒng)性能的影響程度，從而推斷出對性能影響最大的因素。這種性能測試方法一般在對系統(tǒng)性能狀況有初步了解后進展。ConfigurationTesting的因素。這種性能測試方法一般用于性能調優(yōu)和規(guī)劃力氣。ConfigurationTesting續(xù)進展。另外，在“規(guī)劃力氣”領域內，該方法也常被用來評估“該如何調整才能實現(xiàn)系統(tǒng)并發(fā)測試〔ConcurrencyTesting〕并發(fā)測試〔ConcurrencyTesting〕方法通過模擬用戶的并發(fā)訪問，測試多用戶并發(fā)訪問同一個應用、同一個模塊或者數(shù)據(jù)記錄時是否存在死鎖或者其他性能問題。該方法具有以下特點：這種性能測試方法的主要目的是覺察系統(tǒng)中可能隱蔽的并發(fā)訪問時的問題。ConcurrencyTesting后，就常常會消滅各種莫名其妙的問題。解決這類問題的方法是進展認真的并發(fā)模擬測試。這種性能測試方法主要關注系統(tǒng)可能存在的并發(fā)問題，例如系統(tǒng)中的內存泄露、線程鎖和資源爭用方面的問題。ConcurrencyTesting2-1出了并發(fā)測試主要關注的問題。2-1并發(fā)測試主要關注的問題問題類別問題類別問題描述是否有內存泄露〔C/C++〕內存問題是否有太多的臨時對象〔java〕是否有太多的超過設計生命周期的對象〔java〕是否有數(shù)據(jù)庫死鎖〔DeadLock〕數(shù)據(jù)庫問題是否常常消滅長事務〔LongTransaction〕線程/進程問題是否消滅線程/進程同步失敗是否消滅資源爭用導致的死鎖其他問題是否沒有正常處理特別〔例如超時等〕導致系統(tǒng)死鎖這種性能測試方法可以在開發(fā)的各個階段使用支持。發(fā)負載的產(chǎn)生外，還需要一些其他工具進展代碼級別的檢查和定位。Compuware公司的DevPartnerdj-technologieJProfileQuestJProbe以在這方面發(fā)揮作用。牢靠性測試〔ReliabilityTesting〕這里說的“牢靠性測試”并不等同于“獲得軟件的牢靠性”，軟件的牢靠性是一個很大的命題，這里指的牢靠性測試是通過給系統(tǒng)加載確定的業(yè)務壓力〔例如：資源在70%~90%的使用率〕，讓應用系統(tǒng)運行一段時間、測試系統(tǒng)是否穩(wěn)定運行。這里有三點需要留意：在使用該測試前需要目的系統(tǒng)的資源使用率已經(jīng)到達70%~90刻環(huán)境下運行該應用系統(tǒng)。90%。比方：該J2EE系統(tǒng)中設置的JDBC數(shù)據(jù)庫連接池定義為30，那么加載業(yè)務壓力使連接到達27。要求MTBF〔平均無故障時間〕到達10000小時、那么我們可以認定該系統(tǒng)的運行時間至少需要到達三年重啟動一次。超過這個數(shù)字我們就可以認為“不行靠”J2EE90%~1003可以認定該MTBF該方法具有以下特點：這種性能測試方法的主要目的是驗證系統(tǒng)是否支持長期穩(wěn)定的運行。ReliabilityTesting方法的目的是驗證系統(tǒng)是否能夠支持長期穩(wěn)定的運行，其原理在行的條件。這種性能測試方法需要在壓力下持續(xù)一段時間的運行。2～3測試過程中需要關注系統(tǒng)的運行狀況。在運行過程中，一般需要關注系統(tǒng)的內存使用狀況，系統(tǒng)的其他資源使用有無明顯的變失效恢復測試〔FailoverTesting〕該方法是針對有HACMP等冗余備份和EdgeServerforLBJ2EE假設這種狀況發(fā)生，用戶將受到多大程度的影響。該方法有以下特點：這種性能測試方法的主要目的是驗證在局部故障狀況下，系統(tǒng)能否連續(xù)使用。有一臺或幾臺效勞器消滅問題，應用系統(tǒng)照舊能夠正常執(zhí)行業(yè)務。FailoverTesting方法可以在測試中模擬一臺或幾臺設備故障，驗證預期的恢復技術是否能夠發(fā)揮作用。這種性能測試方法還需要指出，當問題發(fā)生的時候“能支持多少用戶訪問”當一臺或多臺效勞器消滅問題后，系統(tǒng)確定會受到性甚至是功能上的局部損失。因此，些必要措施？”這種問題的明確答案。測試。的系統(tǒng)。三、性能測試分析方法前一章著重介紹了目前常用的性能測試方法，本章主要簡潔介紹一下常用的各種性能測試分析方法。1、內存分析方法內存分析方法主要是用于推斷系統(tǒng)有無遇到內存瓶頸高系統(tǒng)性能表現(xiàn)。主要計數(shù)器包括MemoryPhysicalDisk內存分析的主要步驟和方法如下：首先查看MemoryAvailableMbytes該值是用于描述系統(tǒng)可用內存的直接指標，在對系統(tǒng)進展操作系統(tǒng)級別的內存分析時，存可用。假設該指標的數(shù)據(jù)比較小，系統(tǒng)可能消滅了內存方面的問題，此時需要進一步分析。留意s/sec、sRead/secFaults/sec操作系統(tǒng)常常會使用磁盤交換的方式來提高系統(tǒng)可用的內存量或是提高內存的使用效率。這三個指標直接反映了操作系統(tǒng)進展磁盤交換的頻度。假設s/sec表示內存有問題，而可能是運行使用內存映射文件的程序所致。Faults/sec說明白每秒發(fā)生頁面失效的次數(shù)，頁面失效次數(shù)越多，說明操作系統(tǒng)向內存中讀取的次數(shù)越多。此時還需要查看sRead/sec計數(shù)器，該計數(shù)器閥值為5，假設超過5，則可以判定存在內存方面的問題。依據(jù)PhysicalDiskPhysicalDisksRead/sec%DiskTimeAverageDiskQueueLengthsRead/sec%DiskTimeAverageDiskQueueLength則可能有磁盤瓶頸。但是假設AverageDiskQueueLengthsRead/sec于內存缺乏。(備注：內存分析方法用到的計數(shù)器指標主要有：MemoryAvailableMbytes、Memorys/secsRead/sec和Faults/secPhysicalDisk%DiskTimeAverageDiskQueueLength)2、處理器分析方法處理器(CPU)也可能是系統(tǒng)的瓶頸，對處理器進展性能分析的步驟如下：首先查看System%TotalProcessorTimeCPU假設該值的數(shù)值持續(xù)超過90%，則說明整個系統(tǒng)面臨這處理器方面的瓶頸，需要增加處理器來提高性能。留意：由于操作系統(tǒng)本身的特性，在某些多CPU系統(tǒng)中，該數(shù)據(jù)本身并不大，但此時CPU其次查看每個CPU的Processor%ProcessorTimeProcessor%UserTimeProcessor%PrivilegedTime。