再次解讀Web Page Diagnosti…

web page diagnostics 不錯

原文地址：再次解讀Web Page Diagnostics網頁細分圖作者：深藍

Web Page Diagnostics （以下簡稱WPD），這是LR Analysis中非常重要的一塊，搞清楚這部分的內容會讓你少走很多彎路，很多環境問題都可以通過它來定位，比如客戶端，網絡。通過它可以你可以比較好的來定位是環境的問題還是應用本身的問題，當然更重要的是Web頁面本身的問題。

Web Page Diagnostics：頁面診斷圖，也叫頁面分解總圖

“頁面分解”顯示某一具體事務在測試過程的響應情況，進而分析相關的事務運行是否正常。

此視圖下面的文件結構大體上與scripts中actions/transaction/web_url(or submit_form_request)等一系列客戶端請求 這三層體系結構類似。

Transactions是組成Web Page Diagnostics視圖最基本的單元。用戶可以通過右鍵選中Transaction，然後進入Web Page Diagnostics for Transaction界面，對此事務下面的頁面進行分析。在這裏有二點需要說明：

1） 如果Transaction結構多於一個層次，比如Action/Load_home_page,則用戶只允許進入到子級目錄Load_home_page，即使用戶選中Action系統也會自動跳轉到下級目錄。

2） 對於事務下面的頁面請求，LR提供的操作是Break down, 也可以進行View page in Browser.

因爲web_url作用是Loads the specified Web page (GET request)，所以會存在着一次請求多次返回的情況，從服務器端返回的內容包括但不侷限於hmtl、圖片、腳本文件、以及生成的二次請求鏈接等。

比如，打開Web Tours主頁的請求：

 web_url("WebTours", "URL=http://127.0.0.1:8080/WebTours/", "Resource=0", "RecContentType=text/html", "Referer=", "Snapshot=t2.inf", "Mode=HTML", LAST);

從服務端獲得的response就有:

http://127.0.0.1:8080/WebTours/

http://127.0.0.1:8080/WebTours/welcome.pl?signOff=true

http://127.0.0.1:8080/WebTours/images/hp_logo.png

http://127.0.0.1:8080/WebTours/home.html

...

而提交登陸帳戶 web_submit_form("login111.pl", 

"Snapshot=t3.inf", 

ITEMDATA, 

"Name=username", "Value=zhutao", ENDITEM, 

"Name=password", "Value=zhutao", ENDITEM, 

"Name=login.x", "Value=55", ENDITEM, 

"Name=login.y", "Value=3", ENDITEM, 

LAST);

雖然此處沒有明確指定請求的url地址，但也相當於向服務端發送一個請求（登陸請求），所以同樣也可以從server獲得response:

http://127.0.0.1:8080/WebTours/login.pl --注，用來處理客戶請求的腳本庫，pl代表Perl.如果網站使用的是javascript，則需要下載後綴爲.js的腳本文件。

http://127.0.0.1:8080/WebTours/login.pl?intro=true

http://127.0.0.1:8080/WebTours/images/flights.gif

http://127.0.0.1:8080/WebTours/images/signoff.gif

...

Web Page Diagnostics視圖可以按下面四種方式進行進一步細分：

Download Time Breaddown（下載時間細分）

Component Breakdown(Over Time)（組件細分(隨時間變化)）

Download Time Breakdown(Over Time)（下載時間細分(隨時間變化)）

Time to First Buffer Breakdown(Over Time)（第一次緩衝時間細分(隨時間變化)）

Web Page Diagnostics總圖以transaction分析爲主，兼顧頁面的初步分析。

下面七個圖表是對Web Page Diagnostics視圖的更進一步細化，從名字上可以看出，它們主要分析對象是事務的下一級--頁面。

• Page Component Breakdown： 

  頁面中每個元素的平均響應時間佔整個頁面響應時間的百分比

• Page Component Breakdown(Over Time)：在

  整個測試過程中，任意一秒內頁面中每個元素的響應時間（例如在runtime中設置了browser cache，頁面中的資源文件就只會在第一次下載，後面的頁面響應時間也就不包括這些元素的時間，這在Page Component Breakdown中是看不出來的，因爲Page Component Breakdown是整個測試期間內的平均時間。當然，是否啓用了cache，通過over time圖就能看出來）

• Page Download Time Breakdown：頁面中每個元素的響應時間分割圖，響應時間被分割爲以下幾個部分：DNS Resolution,Connection,First Buffer,SSL Handshaking,Receive,FTP Authentication,Client,Error
• Page Download Time Breakdown(Over Time)：在整個測試過程中，任意一秒內頁面中每個元素的響應時間分割圖
• Time to First Buffer Breakdown：First Buffer Time時間分割爲Network Time和Server Time，客戶端http請求發送到接收到服務器端的應答包（ACK）爲Network Time，從接收到ACK到完成First Buffer接受爲Server Time
• Time to First Buffer Breakdown(Over Time)：基本同上，任意一秒內的
• Downloaded Component Size(KB)：頁面中每個元素的大小（KB）

 

介紹了這麼多，具體如何分析呢？

首先打開Web Page Diagnostics圖，來看看下面一個例子Download Time圖：

上圖存在兩個問題：

1、receive時間很長

這個一般是網絡問題，當然如果你確認網絡不存在問題，那麼你就要看看是不是客戶端的問題（客戶端也可能會造成Receive過長，這個千萬要注意）

2、頁面問題

頁面上包括了非常多的圖片，而且圖片似乎都沒有優化，最大的竟然有163K，記下來，這可是罪證哦 ；）

很多時候，你可以根據DNS,Connection,Receive來看出是否存在網絡問題，根據Client來判斷是否存在客戶端問題。

看看，挺簡單的吧！ ^_^

換個圖看看，Page Component Breakdown(Over Time)

很清楚吧，頁面元素都被cache了，說明場景啓用了browser cache，頁面的響應時間只包括紅線和藍線。

Time to First Buffer Breakdown(Over Time)  ，圖就不貼了，這個圖非常重要，也最複雜，這裏的值不絕對，當網絡狀況不好的時候，server time很可能包括網絡時間，因爲很多頁面元素比較小（小於4k的樣子），在First Buffer就完成傳輸，所以一定要注意分析。