今天有乙個同學問：「乙個小的系統，使用者併發數為
20個，那事務平均響應時間大概在什麼範圍內？」 怕麻煩直接告訴他
2/5/8
原則，鑽牛角尖的話，
需要進一步確認什麼樣的小系統？提供的什麼型別的業務？使用者行為是什麼樣的？使用者對系統的使用頻率？就算同響應時時間一樣，前端通過不同展現方法，使用者的感知可能完全不一樣。下面就真對這個問題延伸討論一下從使用者感知的角度看軟體效能測試。
2/5/8原則
2/5/8原則是上個世紀80
年代某公司真對自己公司的應用做的乙個調查，調查的結果就是當使用者能夠在2
秒以內得到響應時，會感覺系統的響應很快；當使用者在
2-5秒之間得到響應時，會感覺系統的響應速度還可以；當使用者在
5-8秒以內得到響應時，會感覺系統的響應速度很慢，但是還可以接受；而當使用者在超過
8秒後仍然無法得到響應時，會感覺系統糟透了，或者認為系統已經失去響應，而選擇離開或者發起第二次請求。
到90年代的時候英國真對零售業的**又做了一次調查， 它的調查結果是乙個使用者真對乙個頁面的響應的最長忍耐時間是4s
，超過4s
大量的使用者會選擇放棄頁面的響應。
我在《效能測試知多少---
響應時間
》中已經對使用者的響應時間做過分析；就是從使用者按下鍵盤或滑鼠按鍵到整個頁面在瀏覽器中的展示的過程分程可以分三個部分：
呈現時間：瀏覽器接收到資料，解析渲染的時間。
資料傳輸時間：傳送與接收的資料在網路中傳輸的時間。
系統處理時間：系統真對請求的處理並返回的時間。
我們在通過測試工具做效能測試的時候，第乙個時間直接去掉，第二個時間進行閹割（因為一般的效能測試在區域網中進行，所以，資料傳輸時間基本可忽略），唯一保留的就是系統的處理時間。
你能用2/5/8原則麼？你用效能測試工具得到的2
秒，真實的使用者感知恐怕要遠遠大於這個時間吧！？
不同業務的不同使用者感知寬容」
些。逛」**，所以對結果的迫切性不強。
秒，谷歌需要
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
可以增加使用者等待，但他不是最好使用者體驗，還記得一張很大的是怎麼顯示的麼？
自頂向下顯示，自頂向下逐行的來顯示，直到整個完整的
切成若干小圖，得到乙個小圖展示乙個小圖，終使使用者看到完整的。
由模糊到清晰，一張有規律的先抽取上面一部分畫素顯示，使一張由模糊到清晰。
分頁顯示：
當使用者請求一批資料時，只給使用者最先看到的一頁的資料，翻頁時再來載入展示第二頁的資料。
邊展示邊載入：
你一定訪問過花瓣網咖！滾動條永遠也拖不到底部，因為螢幕的大小總是有限的，所以有可以採用邊顯示邊處理載入。
效能測試分前端效能與後端效能，一般的效能測試更關心後端，但不管什麼樣的產品最終是要給使用者用的。以使用者感知為導向的效能測試才更有意義。
從使用者感知談軟體效能測試
乙個小系統，使用者數是20個，那事務的平均響應時間大概在什麼範圍內？怕麻煩可以直接告訴他2 5 8原則，鑽牛角尖的話，需要進一步確認是什麼樣的系統？提供的是什麼型別的業務？使用者行為是什麼樣的？使用者對系統的使用頻率？就算同響應時間一樣，前端通過不同展現方式，使用者的感知可能完全不一樣。下面就針對這...
軟體測試談（一）
一 軟體測試概述 軟體測試是軟體開發過程的重要組成部分，是用來確認乙個程式的品質或效能是否符合開發之前所提出的一些要求。軟體測試的目的，第一是確認軟體的質量，其一方面是確認軟體做了你所期望的事情 do the right thing 另一方面是確認軟體以正確的方式來做了這個事件 do it righ...
《效能測試二三談》系列
從16年4月份開始學習效能測試到現在全職做效能測試工作，差不多兩年半時間。期間斷斷續續寫了一些效能測試方法和負載工具以及監控工具相關的部落格。主要會從基礎篇 方法篇 分析篇 監控篇 工具篇這幾部分來統計，具體見下文吧，會不斷更新的。基礎篇 我第一次真正意義上接觸效能測試，應該是從段念老師的 軟體效能...