一、80% 的軟件缺陷，聚集在軟件 20% 的模塊中
優秀的測試人員會根據這個原則，非常快速的找出較多的缺陷（這個原則可以解釋一個你的苦惱：為何你苦苦測了幾天，都沒發現有啥缺陷；你老大慢悠悠的走了過來，隨便點點，新鮮出爐3個Bug）。
普通的測試人員，非常焦慮 & 忙碌的加班加點，漫無目的地到處搜尋，一個Bug都沒發現。
此處，俗稱：探索性測試；
在測試時間有限 / 測試人員有限的情況下，非常適用。
此原則：
對於軟件測試人員提高測試效率及缺陷發現率有着重大的意義
二、軟件測試工作盡早介入
在需求階段、系統分析、系統設計、系統實現階段的復審，能夠發現和避免 80% 的軟件缺陷 。
作者一直認為，測試的價值，不是測試出多少個Bug ，而應該去思考，如何減少缺陷流出到線上生產系統；
三、反映在軟件測試的自動化方面
經過大量企業的實踐證明，80% 的軟件缺陷可借助人工測試發現， 20% 的軟件缺陷可以借助自動化測試收到發現和避免。
二者間具有交叉的部分，尚有 5% 左右的軟件缺陷需要通過其他方式進行發現和修正。
比如，測試右移的，線上監控、灰度測試 、日志分析 等等 ；
四、80%的缺陷，集中在某20%的開發工程師代碼中
在質量部門的過程中，讓每位測試同學詳細分析各團隊的開發人員，分析每位開發同學的過程缺陷數據；把有限的時間，集中在某幾位同學提交的代碼中；能夠發現80%的Bug ；
注：還有很多企業落地實戰，在踐行 80 / 20原則 ；這篇文章，先寫這四個維度 ；
另，關於軟件測試的一些觀念澄清：
一、缺陷是解決不完的
質量 & 效率的平衡 ，需把控一個適當的“度”
一味追求Bug 解決 100% ，期望一個缺陷不留，只會導致版本上線遙遙無期；對於99%的系統，這不是科學的玩法（特別是快速發展、迭代的電商等系統） 。
對於每位測試從業者，都需要去思考的一個事：“當發版時間臨近，還存在一些Bug沒解決完時，如何處理 ？”
作者的建議是：拉上相關人（業務、IT老大、測試老大、項目經理），梳理Bug優先級，確定發版前必須要解決的Bug，可暫緩的，遺留到下個版本解決 ；
二、是不可能發現100%缺陷的
所以考核指標，才存在“線上漏測率”這個指標 。
軟件測試能做到的是：盡可能多的發現軟件的缺陷 ；
沒人能夠保證100%發現所有缺陷 ；這就是為何現在各企業在落地實戰「測試右移」；
雖然不能發現100%的缺陷，但我們可以做到實時監控，以及在用戶發現缺陷之前，把缺陷給“偷偷的”解決了（這就是之前說的：軟件測試從業者終極目標，線上零BUG如何實現 ？ ）；
三、缺陷是相對的
除了明顯的功能不可用、Error報錯等；不符合預期結果，也可以稱為“Bug” ；
如果連預期結果都沒有，或者產品經理，根本就沒有告訴你，這個點，應該是怎么樣的 ；
這個時候，就得跟產品經理，好好勾兌，懟需求了；
這就是為何IT團隊，經常跟產品經理，討論如此火熱的原因（每個人對預期結果的想法是不一樣的）；
但，這里有一個點：作為一名軟件測試工程師，你是可以通過接觸足夠多的行業軟件 / 行業系統 ，去引導產品經理、開發工程師，按你的想法，達成你期望的結果 ；
這就是所謂的“用戶體驗測試”