所謂響應時間的“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

轉載 

滇東北小漢