二八原則始于Pareto原則，Pareto原則中文翻譯為帕累托原則，由意大利經濟學家Villefredo Pareto提出，他研究發(fā)現：社會財富的80%是掌握在20%的人手中，而余下的80%的人只占有20%的財富。延伸一下，就是“至關重要的少數，微不足道的多數”。二八原則告訴我們，做事要抓重點。在軟件測試中，懂得二八原則可以幫助我們節(jié)省很多精力!
  1.80%的錯誤是由20%的模塊引起的
  簡單、容易的模塊或功能是很少引入過多Bug的，而對于存在復雜邏輯的一些關鍵模塊往往會引起系統(tǒng)80%的錯誤。只有關鍵模塊穩(wěn)定了，整個系統(tǒng)才可能真正的健壯和穩(wěn)定。
  這個原則對于測試來說就是站在用戶角度(而不是研發(fā)實現的角度)，正確地選擇重要功能模塊作為測試的重點，不偏離方向。
  2.80%的測試成本花在20%的軟件模塊中
  設計測試用例時，常會用日產多少條用例來衡量工程師的。用例的多少與需求量有關，而影響軟件架構設計的需求描述往往是比較少的。在這種情況下，設計測試用例時特別需要結合軟件的概要設計、詳細設計一起考慮。如果用例設計人員為了達到用例的數量，通過大量復制用例，修改個別字眼，而沒有真正去設計高效的測試用例，那么用如此低效甚至更多的用例數量來對待復雜的20%的核心模塊，在測試執(zhí)行過程中必將導致一部分關鍵Bug找不出來。
  3.80%的測試時間花在20%的軟件模塊中
  對于復雜的模塊，前期的測試設計和思考可能會耗費大量時間，而產出的用例量可能并不大。對于復雜的系統(tǒng)，特別是對于全新系統(tǒng)，必須舍得投入充足的時間來優(yōu)先考慮設計，前期方案、用例設計的時間越短，后期的風險越大。
  在項目進展到一定階段后，增加人力并不一定能解決縮短時間的問題。例如，如果復雜且核心模塊在項目的后期才開始執(zhí)行測試，由于Bug較多，而項目又需要短時間把版本穩(wěn)定下來，通常的做法是加人。然而加入的新兵需要一段時間的熟悉期，必要時還需要老兵來帶，這本身又會影響到老兵的。另外一些性能測試、自動化測試也只有等版本穩(wěn)定后才會有更好的效果。