在跑場景時,會碰到這樣一種情況,使用LoadRunner測試出來的響應時間比實際使用瀏覽器感受到的時間要長,例如,實際使用瀏覽器打開一個系統時只需要1~2秒，而使用LoadRunner跑一個用戶所得出的結果可能是遠遠超過實際操作的響應時間.
針對上述問題進行分析總結,有3種情況:
1、在運行LR場景時沒有忽略Think Time（思考時間）和記錄log的時間.
2、施壓機或服務器的機器配置不高,比如低配置的機器在運行場景工具時系統資源已滿,則造成響應時間過長.
3、實際IE感受的時間不等同於LR錄製的響應時間.
前兩中情況可以通過LR設置及提高硬件配置解決.
第三種情況,因爲LR在錄製過程中,事物的響應時間包括:DNS Resolution/Connection/First Buffer time/Receive Time/Client Time時間等,比如當我們在使用IE打開頁面時,系統首先會進行域名解析,並與服務器建立連接、下載數據，到這時在IE中已可以顯示頁面,但實際響應時間並沒有結束,瀏覽器仍有可能在與服務器進行數據交互，或者客戶端IE由於忙碌未及時將請求發出,出現了客戶端延時情況(客戶端IE會執行一些 javascript腳本或其他頁面初始化動作),直到這些動作全部完成後纔是一個完整的響應時間,LoadRunner也是記錄的這個響應時間.
所以我們通常使用IE所感受到的時間是比用性能工具錄製時記錄的響應時間要少.因此,系統頁面的響應時間應以工具記錄時間爲準,並在分析報告中查看平均事物響應時間.
還有關鍵一點,IE還要清除緩存.即在runtime setting中設置“clear cache on each iteration".
對時間的解釋：
1、DNS Resolution:瀏覽訪問一個網站的時候,一般用的是域名,需要DNS服務器把域名解析爲IP地址,這個過程就是域名解析時間.
2、Connection:解析出Web Server的IP地址後,瀏覽器請求被髮送到了一個Web Server,然後瀏覽器和Web Server 之間需要建立一個初始化的HTTP連接,服務器端需要做兩件事:一個是接收請求,二是分配進程.建立該連接的過程就是Connection.
3、First Buffer:建立連接後,從Web Server發出第一個數據包,進過網絡傳輸到客戶端,瀏覽器成功接收第一個字節的時間就是First Buffer.
4、Receive:從瀏覽器接收第一個字節起,直到成功收到最後一個字節,下載完成爲止.
5、Client Time:請求在客戶端瀏覽器延遲的時間.