analysis簡介

分析器就是對測試結果數據進行分析的組件，它是LR三大組件之一，保存著大量用來分析性能測試結果的數據圖，但並不一定要對每個視圖進行分析，可以根據實際情況選擇相關的數據視圖進行分析，分析結果可以生成一些不同格式的測試報告。

一、設置選項

analysis中的數據是怎麽得到的呢？其實在場景運行的時候，默認情況下，所有的vuser信息都保存在該vusr的負載機上。只有當場景運行結束後，這些數據才會自動進行整理或合並，這時負載機上所有vuser的信息和數據都將被傳輸到結果目錄中。默認情況下，在controller控制器中，results->auto collate results是被選中的，也就是說默認情況下，當場景運行結束後，這些數據會被自動整理或合並。但當沒有選中這項時，場景運行結束後，可以在controller控制器中選擇results->collate results 進行手動整理。

在進行數據視圖分析前，有必要將分析圖中涉及的一些選項加以設置，過濾掉不需要的數據，方便對數據進行分析。

下面介紹一些常用的設置選項：

1、結果目錄設置

在controller控制器中選擇results->results setting，如圖1所示：

a.每執行一次場景都生成一份結果文件，結果文件的命名方式為res後接一個序號（如res0），每執行一次序號依次加1；

b.每執行一次場景，將執行後的結果覆蓋以前的結果。（為了防止意外發生，一般會選擇第一種結果保存方式）。

圖1（結果目錄設置）

2、result collection設置

在LR處理這些數據時，可以查看這些數據的摘要，具體怎樣查看摘要數據，需要在result collection選項中進行設置，如圖2所示：

圖2

data source：

a.表示僅查看摘要數據。如果選中該選項，那麽analysis還會處理數據以用於篩選和分組等高級用途。且data aggregation項是不可以設置的。

b.表示僅查看經過處理的完整數據，但是不顯示摘要數據。

c.表示在處理完整數據時，查看摘要數據。

data aggregation：

a.表示使用內置數據聚合公式聚合數據，以優化性能

b.表示使用內置數據聚合公式僅僅聚合與web相關的數據

c.表示用戶自定義來設置聚合數據，如圖3所示：

aggregate data (available only for complete data)：用於設置聚合數據的類型，這裏只適用於完整數據，可以選擇需要聚合數據的圖的類型，這樣可以減小數據庫的容量。

select the graph properties to aggregate：指定要聚合的圖屬性。

web data aggregation only：表示僅聚合web的數據，在這裏可以設置聚合的粒度。

圖3

3、configure measurements 設置

在分析圖時，發現分析圖的Y軸幅值過小時，就可以在這裏進行設置，對Y軸進行適當的放大或縮小操作，如圖4所示：

a.手動設置一個比例值；b.使用優化的自動比例來顯示圖中每個度量；c.將圖中所有度量比例都設置為1；d.查看所有度量的趨勢。

默認值 為1，即按原始比例進行顯示，有時波形顯示的幅值太小，那麽就需要適當地調整放大比例。

圖4

4、設置篩選條件

如圖5所示：在錄制測試腳本過程中，如果執行腳本時沒有忽略think time時間，那麽analysis分析器在統計分析結果時會把think time包含進去，這樣當think time存在於用戶事務的開始與結束之間時，相關事務統計情況會受到影響。因此，很多時候需要過濾用戶的思考時間，在下拉框中刪除include think time選項即可，分析結果中就會自動濾掉思考時間。

圖5

二、analysis圖

analysis分析器中提供了豐富的分析圖，如圖6所示：

常見的有8類：

1）vuses圖：在方案執行過程中，vuser在執行事務時生成數據。使用vusers圖可以確定方案執行期間vuser的整體行為。它顯示vuser狀態和完成腳本的vuser的數量。主要包括正在運行的vuser圖和vuser摘要圖

2）錯誤圖：主要統計方案執行時的錯誤信息。主要包括error statistics(by description)、error per second(by description)、error statistics和error per second四種圖。

3）事務圖：描述了整個腳本執行過程中的事務性能和狀態。主要包括平均事務響應時間圖、每秒事務數圖、每秒事務總數、事務摘要圖、事務性能摘要圖、事務響應時間（負載下）圖、事務響應時間（百分比）圖和事務響應時間（分布）圖。

4）web資源圖：主要提供有關web服務器性能的一些信息。使用web資源圖可以分析方案運行期間每秒點擊次數、服務器的吞吐量、從服務器返回的HTTP狀態代碼、每秒HTTP響應數、每秒頁面下載數、每秒服務器重試次數、服務器重試摘要、連接數和每秒連接數。

5）網頁細分圖：主要提供一些信息來評估頁面是否影響事務響應時間。包括網頁細分、頁面組件細分、頁面組件細分（隨時間變化）、頁面下載時間細分、頁面下載時間細分（隨時間變化）和已下載組件圖

6）系統資源圖：主要監控場景運行期間系統資源使用率的情況。可以監控windows資源、UNIX資源、SNMP資源、Antara Flame Thrower資源和SiteScope資源

7）web服務器資源圖：主要用來捕捉場景運行時web服務器的信息。主要用來分析microsoft IIS服務器、apache服務器、iplanet/netscape服務器和iplanet(SNMP)服務器。

8）數據庫服務器資源圖：主要顯示數據庫服務器的統計信息。目前支持DB2、oracle、sql server和sybase數據庫。

圖6

摘要報告

一、概要部分

二、統計部分

三、事務統計部分

第一行統計場景運行時所有事務通過、失敗、停止的數量。而表格裏則是顯示了所有事務執行時的詳細信息：

1）transaction name（事務名）；2）minimum（事務運行的最短時間）；3）average（事務運行的平均時間）；4）maximum（事務運行的最長時間）；

5）std.deviation（標準方差）：方差描述一組數據偏離其平均值的情況，方差值越大，說明這組數據就越離散，波動性也就越強；反之，則說明這組數據就越聚合，波動性也就越小；

6）90 percent：在controller運行場景時，並不會顯示這個值，因為它是對整個一系列數據統計的結果。表示一個事務在執行過程中的90%所花費的時間，比如，一個事務執行了100次，對這100次事務響應時間進行升序排序，第90%即90次事務運行時間；

7）pass（通過的事務個數）；8）fail（失敗的事務個數）；9）stop（停止的事務個數）：在執行場景時，若用戶手工停止場景的執行，事務沒有自己的狀態，那麽就是停止狀態。

註：事務的通過率一定要大於95%，也即失敗率應該小於5%，因為如果事務失敗率過高，就說明客戶在使用系統時很容易出現錯誤，這樣無論事務響應時間多麽短也是不符合要求的，因為客戶最基本的需求都沒有被滿足，功能都不能正確的處理，那麽更無法談性能了。

四、SLA

SLA（service level agreement，服務水平協議）可在性能測試過程中，定義性能測試的目標和度量性能，在性能測試過程中LR會收集和保存性能的相關數據，在分析運行結果時，分析器分將收集的數據與SLA中定義的度量數據進行比較，並將分析結果顯示在分析器中，SLA三種狀態分別是：

a.pass：表示SLA獲得該項測試數據，並且該數據達到目標要求；b.fail：表示SLA獲得該項測試數據，但是測試結果未達到目標要求；c.no data：表示SLA未獲得該項測試數據，所以無法確定是通過還是失敗。

SLA配置步驟如下：

1、在摘要視圖中單擊如圖7所示的按鈕：

圖7

2、單擊new，定義SLA目標，如圖8所示：

圖8

3、設置待度量的目標。這裏以事務響應時間為例，如圖9所示。

關於事務響應時間的目標有兩種方式，一種是按百分比來度量（即設置百分之多少的事務響應時間不能超過目標時間）；另一種是按平均事務響應時間來度量。等下依次介紹這2種方式。

圖9

4、選擇事務。（註：在腳本中一定要插入事務，否則在該步選擇事務時，無法選擇待度量的事務），如圖10所示：

圖10

5、設置百分比閾值。如果是以百分比模式來度量事務響應時間時，如圖11所示：

圖11

該步驟需要設置好百分比和事務響應時間閾值，設置的百分比為90%，事務響應時間為2s，即是只要90%的事務響應時間不超過2s，那麽SLA的報告結果即為PASS，否則結果為FAIL。如圖12所示。

圖12

百分比模式，可以在analyze transaction按鈕進入分析事務界面，查看詳細的分析信息，如圖13所示：

圖13

下面講一下按平均事務響應時間來度量：

1、設置負載標準。如果選擇按平均事務響應時間來度量，則如圖14所示：

選擇負載標準，即通過什麽指標來衡量事務響應的變化情況，以運行的虛擬用戶數為例，需要設置在不同運行虛擬用戶數下事務的響應時間。

圖14

2、設置閾值。

選擇好負載標準後，需要設置在不同的負載標準情況下，事務響應時間情況，這裏即需要設置在不同運行虛擬用戶下事務的響應時間情況，如圖15所示。

設置為當虛擬用戶數少於10個時，事務響應時間應該不超過1s，當虛擬用戶數大於10個時，事務響應時間不超過1.5s。

圖15

設置到這裏就已經全部完成了，可以看出 SLA從本質上來說它是一種目標，是一種度量測試結果是否達到目標的一種手段，與目標場景的設置很相似，原理幾乎一致。

完成SLA設置後，在分析器中會顯示出每個度量事務在不同時間域中的結果表現，如圖16所示：

圖16

在此可以選擇不同事務、不同時間域進行詳細的分析，以查看機票信息為例進行分析，單擊analyze transaction按鈕分析器會顯示出該事務的詳細信息，詳細分析信息主要包括事務摘要信息、事務相關、錯誤信息和快照視圖。

1）事務摘要信息

2）事務相關聯信息（主要包括顯示分析事務時可能需要關聯的相關信息：腳本運行時的一些錯誤信息、系統資源消耗情況、web資源消耗情況和數據庫資源消耗情況。）

註：我的報告中只顯示了web資源消耗情況，其實還有上面所提到的其他幾種信息的。

3）錯誤信息（主要顯示整個場景運行過程中出現的錯誤信息，這在與場景運行過程中產生的錯誤輸出信息類似。詳細地記錄了錯誤的類型、錯誤代碼、事務名稱、腳本、錯誤代碼行數、運行過程中哪個虛擬用戶出錯 等一些相關的信息）。

註：因我的腳本運行過程中沒有錯誤，所以在報告中就沒有顯示錯誤信息，可自己去操作看一下。

4）快照視圖（主要是描述分析的時間域中事務響應時間的情況），如圖17所示。

橫坐標表示場景執行的時間，縱坐標表示事務響應時間，圖中有3條曲線，紅色的表示場景運行時的虛擬用戶數，綠色為場景運行時事務的響應時間，黑色表示SLA定義的閾值。如果綠色的線超過了黑色線則說明該點的SLA失敗，那麽SLA的狀態將會置為失敗。反之則成功，SLA的狀態將置為通過。

圖17

註：按百分比模式與按平均模式的結果顯示會有點不同，具體可自行操作分析。

五、HTTP響應統計

HTTP是一種通信協議，它允許將超文本標記語言（HTML）文檔從web服務器傳送到web瀏覽器。HTML是一種用於創建文檔的標記語言，這些文檔包含到相關信息的鏈接。可以單擊一個鏈接來訪問其他文檔、圖像或多媒體對象，並獲得關於鏈接項的附加信息。（關於HTTP請求響應機制與HTTP響應狀態碼的含義，可自行百度，這裏就不說了。）

analysis常見圖分析

在LR分析器中對資源使用的情況分析得很少，因為通常在性能測試過程中很少使用LR來監控系統資源的使用，特別是UNIX、LINUX和ALX操作系統，幾乎不使用LR來監控，更多的是借助第三方工具來監控，當然如果服務器是windows操作系統，那麽使用LR進行監控比較簡單。

一、vuser圖

它顯示vuser狀態和完成腳本的vuser的數量。將這些圖與事務圖結合使用可以確定vuser的數量對事務響應時間產生的影響。

X軸表示從方案開始運行以來已用的時間，Y軸表示方案中的vuser數，vuser圖顯示在測試期間的每一秒內執行vuser腳本的vuser數量及其狀態。可以幫助確定任何給定環境中服務器上的vuser負載。默認情況下，此圖僅顯示為running的vuser。

二、點擊率圖

顯示在方案運行過程中vuser每秒鐘向web服務器提交的HTTP請求數。借助此圖可以依據點擊次數來評估vuser產生和負載量。一般會將此圖與平均事務響應時間圖放在一起進行查看，觀察點擊數對事務性能產生的影響。X軸表示方案從開始運行以來所用的時間，Y軸表示服務器上的點擊數。

註意：點擊率並不能衡量服務器的真實處理能力，也不能僅僅通過點擊率來衡量服務器的處理能力，因為服務器即使出現 了瓶頸也還會影響到這個值的變化，因為LR其實也是一個代理錄制的工具，將錄制過程中提交的請求錄制成腳本，在回放時模擬用戶重新提交這些請求，那麽在提交的時間LR可以對HTTP請求進行統計，進而生成點擊率視圖。但是這並不代表LR畫出來的點擊率視圖一定正確，假如客戶端實際提交的HTTP請求為2000個/s，但點擊率視圖畫出來的值為1000個/s，這說明客戶端提交的請求根本就沒有完全發送到服務器，那麽這種情況最有可能是在網關處請求出現超時，因為每個網關端口都有一個允許其訪問的最大值，當這個值過大時，網關也會出現排隊現象，如果隊列過長就會導致一些請求出現超時現象，最後導致統計出來的點擊率的值不正確。

三、平均事務響應時間圖

顯示方案在運行期間執行事務所用的平均時間。X軸表示從方案開始運行以來已用的時間，Y軸表示執行每個事務所用的平均時間（s）。平均事務響應時間最直接地反映了事務的性能情況，一般會將平均事務響應時間圖與vuser圖對照著看，來觀察vuser運行對事務性能的影響。可以右鍵選擇show transaction breakdown tree查看子事務或者所有的事務每個頁面所花費的時間。

平均事務響應時間圖直接反映系統的性能情況，這也是客戶眼中的性能，在需要時必須明確地定義好業務的響應時間，在分析時一般先分析的響應時間，當平均事務響應時間符合定義時，也僅僅說明響應時間能達到要求，但是此時並不代表系統達到客戶要求，因為LR統計出來的事務響應時間不一定正確，所以當事務響應時間達到要求後，也一定要分析一些其他的數據，需要確定的是業務是否都做成功了，如果業務都做成功了，並且事務響應時間達到要求，這樣才能說明事務響應時間達到客戶的要求；如果平均事務響應時間達不到要求，就需要進一步分析，是哪些原因導致事務響應時間過長，這樣才能進一步優化系統的性能。

四、吞吐量圖

顯示方案運行過程中服務器上每秒的吞吐量。吞吐量的單位為字節，表示 vuser在一秒時間內從服務器獲得的數據量。借助此圖可以依據服務器吞吐量來評估vuser產生的負載量，可以和平均事務各應時間圖對照觀察，以查看吞吐量對事務性能產生的影響。

X軸表示 方案從開始運行以來已用的時間，Y軸表示服務器的吞吐量（以字節為單位）。吞吐量直接反映了服務器的處理能力，如果服務器處理的吞吐量的值越大，說明服務器處理業務的能力越強，但是在測試過程中不可能一次就測試出服務器吞吐量的值，必須經過多次測試才能找到吞吐量的值，即測試過程中一定要找到吞吐量的拐點，這樣才能找到服務器處理業務時的最大吞吐量，亦即服務器處理的最大能力。

analysis報告

一、HTML報告

二、SLA報告

三、自定義報告

四、使用報告模板定義報告

備註：文字講解來自《深入性能測試--LoadRunner性能測試、流程、監控、調優全程實戰剖析》（黃文高、何月順編著）一書，我是新手，參照此教程做了下實踐，順便將學到的東西寫下來。

轉自：http://www.cnblogs.com/Chilam007/p/6445165.html

性能測試工具Loadrunner使用之三（Analysis ）