所謂響應時間的“2-5-8原則”，簡單說，就是
- 當用戶能夠在2秒以內得到響應時，會感覺系統的響應很快；
- 當用戶在2-5秒之間得到響應時，會感覺系統的響應速度還可以；
- 當用戶在5-8秒以內得到響應時，會感覺系統的響應速度很慢，但是還可以接受；
- 而當用戶在超過8秒後仍然無法得到響應時，會感覺系統糟透了，或者認爲系統已經失去響應，而選擇離開這個Web站點，或者發起第二次請求。
軟件測試理論中，常提到2-8原則
所謂2-8原則，即80%的bug多發生在軟件的20%的模塊。所以，在迴歸測試的時候，這20%的高發地帶是關注的重點！
二八原則還指：80%的業務量在20%的時間裏完成。
如何理解，下面我們來個例子吧
用戶登錄場景：早高峯時段，8：50---9：10，5000坐席上線登陸。
業務量：5000個
時間：20x60=1200秒
吞吐量=80%x業務量/(20%*時間)=4000/240=16.7/秒
而並非5000/1200=4.1/秒
實際上，登錄請求數分佈是一個正態分佈，最高峯時肯定比4.1/秒更高，高峯段實際上完成了80%的業務量，卻只花了20%的時間。
溫馨提示：
1.二八原則計算的結果並非在線併發用戶數，是系統要達到的處理能力（吞吐量），初學者容易被誤導，那這這個數據就去設置併發數，這是錯誤滴。
2.如果你的系統性能要求更高，也可以選擇一九原則或更嚴格的算法，二八原則比較通用，一般系統性能比較接近這個算法而已，大家應該活用。
二八原則還指：
1、80%的錯誤是由20%的模塊引起的
-----> 站在用戶角度，並非研發實現的角度，正確地選擇重要模塊作爲測試重點，從而不偏離方向。
2、80%的測試成本花在20%的軟件模塊中
-----> 設計用例時需要將時間花傾斜在複雜的20%核心模塊上，從而設計更高效的測試用例。
3、80%的測試時間花在20%的軟件模塊中
------> 軟件測試執行過程中需要將時間傾斜在重要模塊的測試用例中，從而使測試更加有效，發現bug。