今天有一個同學問：“一個小的系統，使用者併發數為20個，那事務平均響應時間大概在什麼範圍內？” 怕麻煩直接告訴他2/5/8原則，鑽牛角尖的話，需要進一步確認什麼樣的小系統？提供的什麼型別的業務？使用者行為是什麼樣的？使用者對系統的使用頻率？就算同響應時時間一樣，前端通過不同展現方法，使用者的感知可能完全不一樣。下面就真對這個問題延伸討論一下從使用者感知的角度看軟體效能測試。

2/5/8原則 

　　2/5/8原則是上個世紀80年代某公司真對自己公司的應用做的一個調查，調查的結果

　　到90年代的時候英國真對零售業的網站又做了一次調查， 它的調查結果是一個使用者真對一個頁面的響應的最長忍耐時間是4s，超過4s 大量的使用者會選擇放棄頁面的響應。

　　我在《效能測試知多少---響應時間》中已經對使用者的響應時間做過分析；就是從使用者按下鍵盤或滑鼠按鍵到整個頁面在瀏覽器中的展示的過程分程可以分三個部分：

呈現時間：瀏覽器接收到資料，解析渲染的時間。

資料傳輸時間：傳送與接收的資料在網路中傳輸的時間。

系統處理時間：系統真對請求的處理並返回的時間。

　　我們在通過測試工具做效能測試的時候，第一個時間直接去掉，第二個時間進行閹割（因為一般的效能測試在區域網中進行，所以，資料傳輸時間基本可忽略），唯一保留的就是系統的處理時間。

你能用2/5/8原則麼？你用效能測試工具得到的2秒，真實的使用者感知恐怕要遠遠大於這個時間吧！？

不同業務的不同使用者感知

　　真對不同業務型別的軟體，使用者的容忍度也是不一樣的。百度和淘寶網都有搜尋功能，而且都具有海量的資料，淘寶的搜尋速度要慢於百度，不考慮技術層面，百度的搜尋結果是純文字資訊；而淘寶搜尋的商品會有大量圖片，所以使用者對淘寶的響應速度要“

　　從使用者的心理分析，在使用百度的時候，對結果的顯示顯然更迫切；而我們平時在使用淘寶時叫“逛”淘寶，所以對結果的迫切性不強。

　　當然，如果是相同的業務，拿百度和到谷歌比，百度搜索結果1秒，谷歌需要10秒，相信谷歌再也不會被愛了。

不同使用頻率的使用者感知

　　裝作業系統絕對是個耗時的事兒，少則也需要10分鐘以上，但不少使用者一年半載才裝一次系統，所以，使用者也基本可以接受這個事兒的耗時。如果是你每天早上開機需要10分鐘以上，估計大多使用者就要叫苦了。

　　所以，在一個系統中，使用者頻繁使用的功能上響應很慢的話，使用者將很難忍受；相反，如果使用頻率很低的功能，響應很慢使用者也可接受。

減少使用者等待感

　　最早是Robert B miller 在1968 年的《resopnse time in man-computer conversational transactions》報告中描述了3個層次的響應時間，

0.1～0.2s：使用者認為得到的是即時響應。

1～5s ：使用者感覺到基本資訊的互動是基本流暢的。使用者明顯注意到了延遲，感受到計算機的“工作”過程。

8s 以上：使用者會關注對話方塊。需要提示資訊或進度條來確認系統仍然是處於處理過程的。

　　Peter Bickford 在調查使用者反應時發現：在連續27次的連續反饋後，第28次操作時，計算機讓使用者等待2分鐘，結果半數人每8.5秒左右就離開或按下重啟鍵，使用滑鼠指標的漏斗提示的介面會把使用者的等待時間延長到20秒左右，使用動畫的滑鼠指標漏斗提示介面則會讓使用者的等待時間超過1分鐘，而進度條可以讓使用者等待到最後。

Peter Bickford 的調查結果被廣泛用到web軟體系統的性有需求的響應時間定義中。

從上面的結果發現，增加使用者感知遠比效能的提升更能延長使用者等待，這個非常有意思。也就是說在同樣的響應時間下，使用者感知將非常重要。

無loading：如果響應非常短暫，最好不要用loading ,使用者無法看清loading ，反而影響體驗

Loading：如果響應時間大於1s 的話可以加loading 效果，增加使用者感知。

進度條：如果需要更長時度測需要使用進度條來增加使用者感知。

時度條+倒計時：在一些需要長時間等待的處理過程中，時度條+倒計時是個不錯的選擇，倒計時可以讓使用者預計完成時間，以便用這個空閒去處理其它業。

最快給使用者看到

有時候增加loading 可以增加使用者等待，但他不是最好使用者體驗，還記得一張很大的圖片是怎麼顯示的麼？

自頂向下顯示，自頂向下逐行的來顯示，直到整個完整的圖片

切成若干小圖，得到一個小圖展示一個小圖，終使使用者看到完整的圖片。

由模糊到清晰，一張圖片有規律的先抽取上面一部分畫素顯示，使一張圖片由模糊到清晰。

分頁顯示：

當用戶請求一批資料時，只給使用者最先看到的一頁的資料，翻頁時再來載入展示第二頁的資料。

邊展示邊載入：

你一定訪問過花瓣網咖！滾動條永遠也拖不到底部，因為螢幕的大小總是有限的，所以有可以採用邊顯示邊處理載入。

　　效能測試分前端效能與後端效能，一般的效能測試更關心後端，但不管什麼樣的產品最終是要給使用者用的。以使用者感知為導向的效能測試才更有意義。