本文轉自：https://www.cnblogs.com/Chilam007/p/6445165.html

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性能測試、流程、監控、調優全程實戰剖析》（黃文高、何月順編著）一書，我是新手，參照此教程做了下實踐，順便將學到的東西寫下來。

?? ? ? ? ? ??

? ? 分析器就是對測試結果數據進行分析的組件，它是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性能測試、流程、監控、調優全程實戰剖析》（黃文高、何月順編著）一書，我是新手，參照此教程做了下實踐，順便將學到的東西寫下來。

分類:?LoadRunner性能測試 好文要頂?關注我?收藏該文?? 一加一
關注 - 5
粉絲 - 74 +加關注 3 0 ??上一篇：loadrunner入門篇 - Controller控制器
??下一篇：loadrunner提高篇 - 插入檢查點與關聯函數 posted @?2017-03-12 16:56?一加一?閱讀(3773) 評論(2)?編輯?收藏
評論 回復引用 #1樓?2017-11-01 09:29?|?Taowd? 在學習中，學習了相當詳細，博主能推薦幾本LR的書嗎？多謝！ 支持(0)反對(0) 回復引用 #2樓[樓主]?2017-11-04 14:42?|?一加一? @?Taowd
推薦《深入性能測試--LoadRunner性能測試、流程、監控、調優全程實戰剖析》（黃文高、何月順編著）

我也是正在學習LR，看了好幾本LR的書，比較傾向于這本，講的比較詳細，有一個從淺到深的過程，看完后會對LR的整體操作有個比較深的了解，剩下的就要靠自己運用書本知識去項目上實踐了。 支持(0)反對(0) 刷新評論刷新頁面返回頂部 發表評論

昵稱：

評論內容： ?????

?退出?訂閱評論

[Ctrl+Enter快捷鍵提交]

【推薦】超50萬VC++源碼: 大型組態工控、電力仿真CAD與GIS源碼庫！
【活動】2050 大會 - 年青人因科技而團聚（5.26-5.27 杭州·云棲小鎮）
【推薦】0元免費體驗華為云服務
【活動】騰訊云云服務器新購特惠，5折上云 最新IT新聞:
·?騰訊微視：一條自我銜尾的蛇
·?微軟CEO納德拉對話麥肯錫：微軟的責任究竟是什么？
·?魏武揮：誰該為馬化騰表態這個烏龍尷尬？
·?美國紀錄片里的制造業衰落
·?全民公敵攜程危險逼近：以利潤驅動 用資本做防線
??更多新聞... 最新知識庫文章:
·?如何成為優秀的程序員？
·?菜鳥工程師的超神之路 -- 從校園到職場
·?如何識別人的技術能力和水平？
·?寫給自學者的入門指南
·?和程序員談戀愛 ??更多知識庫文章... 昵稱：一加一
園齡：3年3個月
粉絲：74
關注：5 +加關注

?

轉載于:https://www.cnblogs.com/wxinyu/p/9002777.html

總結

以上是生活随笔為你收集整理的loadrunne-- Analysis 分析器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。