論性能測試中的“響應時間” 性能測試工具
昔日收到一個讀者的來信，對于我在書中提到的“響應時間”有一些疑問，以下是他的郵件中提到的問題：
1，“系統響應時間”如何定義?是指“客戶端排匯到響應所消耗的時間”還是“排匯到最后一個字節數據所消耗的時間。。。�！�?
2，書中提到“可以應用技巧在數據尚未排匯完成時進行顯現來增添用戶感想到的響應時間”，這一句話是什么意思?
先回覆第一個問題，我在書中找到了原文：
而“系統響應時間”指應用系統從請求發出起頭到客戶端排匯到數據所消耗的時間。這里確實有不清楚的中心，更確實的說法應該是：而“系統響應時間”指應用系統從請求發出起頭到客戶端排匯到所有數據所消耗的時間。
這樣，“系統響應時間”加上“顯現時間”，才是完整的用戶感想到的響應時間。
對于第二個問題，倒是有些可以討論的內容：
我們在定義響應時間的時候，是從應用的應用者÷客戶的角度出發的。從這個角度出發，響應時間被定義成“對請求做出響應所需要的時間”。我們以一個web應用為例，如果web應用有一個“提交用戶留言”的功能，考察這個功能的響應時間，就應該是“從用戶填寫完留言，點擊提交按鈕起頭，到頁面刷新完成，用戶看到完整的返回頁面為止”所消耗的所有時間——這個定義非常完整，但若從用戶的實際感想來看的話，這里還是有一點模糊的中心。
我們可以把上文提到的交互過程細化一下：
用戶點擊“提交”按鈕-》請求被發送到服務器-》服務器處理-》服務器返回頁面-》瀏覽器排匯服務器的返回并render頁面
模糊之處在于最后一個環節：“瀏覽器排匯服務器的返回并render頁面”，如果我們堅定的認為“只有當頁面完整的顯示完成，才是響應時間的結束”，這不會是一個問題。但實際上，對大多數用戶來說，看到頁面上起頭顯示數據或是圖片，用戶就會認為“我已經得到了響應”，從這個角度來說，用戶感想到的響應時間實際上是“從請求發出起頭，到用戶看到頁面起頭顯現出的內容結束”所需要的時間。
那為什么我們不采用“從請求發出起頭，到用戶看到頁面起頭顯現出的內容結束”這樣一個定義方式呢?關鍵在于這里涉及到用戶的認知行為，帶有主觀色彩，不完整是客觀的標準，因此不適合作為一個需要被度量的性能指標。另一方面，不同的瀏覽器有不同的行為(例如parse的方式和render的方式)，如果需要把這些瀏覽器本身的行為都推敲到性能測試中的話，我們很難為所有的系統建立統一的測試模型——實際上，現在的主流性能測試工具(例如JMeter，LoadRunner，Webload等)都完整不推敲客戶端的顯現過程。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
