一、80% 的軟件缺陷，聚集在軟件 20% 的模塊中

優秀的測試人員會根據這個原則，非常快速的找出較多的缺陷(這個原則可以解釋一個你的苦惱：為何你苦苦測了幾天，都沒發現有啥缺陷；你老大慢悠悠的走了過來，隨便點點，新鮮出爐3個Bug)。

普通的測試人員，非常焦慮 & 忙碌的加班加點，漫無目的地到處搜尋，一個Bug都沒發現 。

此處，俗稱：探索性測試；

在測試時間有限 / 測試人員有限的情況下，非常適用 。

此原則：對于軟件測試人員提高測試效率及缺陷發現率有著重大的意義

二、軟件測試工作盡早介入

在需求階段、系統分析、系統設計、系統實現階段的復審，能夠發現和避免 80% 的軟件缺陷 。老徐一直認為，測試的價值，不是測試出多少個Bug ，而應該去思考，如何減少缺陷流出到線上生產系統 ；

三、反映在軟件測試的自動化方面

經過大量企業的實踐證明，80% 的軟件缺陷可借助人工測試發現， 20% 的軟件缺陷可以借助自動化測試收到發現和避免。二者間具有交叉的部分，尚有 5% 左右的軟件缺陷需要通過其他方式進行發現和修正。

比如，測試右移的，線上監控、灰度測試 、日志分析? 等等 ；

四、80%的缺陷，集中在某20%的開發工程師代碼中 ；

IDO老徐

在帶質量部門的過程中，讓每位測試同學詳細分析各團隊的開發人員，分析每位開發同學的過程缺陷數據；把有限的時間，集中在某幾位同學提交的代碼中；能夠發現80%的Bug ；

注：還有很多企業落地實戰，在踐行 80 / 20原則 ；這篇文章，先寫這四個維度 ；，

另，關于軟件測試的一些觀念澄清：

一、缺陷是解決不完的

質量 & 效率的平衡 ，需把控一個適當的“度”

一味追求Bug 解決 100% ，期望一個缺陷不留，只會導致版本上線遙遙無期；對于99%的系統，這不是科學的玩法(特別是快速發展、迭代的電商等系統) 。

對于每位測試從業者，都需要去思考的一個事：“當發版時間臨近，還存在一些Bug沒解決完時，如何處理 ？”

老徐的建議是：拉上相關人(業務、IT老大、測試老大、項目經理)，梳理Bug優先級，確定發版前必須要解決的Bug，可暫緩的，遺留到下個版本解決 ；

二、是不可能發現100%缺陷的

所以考核指標，才存在“線上漏測率”這個指標 。

軟件測試能做到的是：盡可能多的發現軟件的缺陷 ；

沒人能夠保證100%發現所有缺陷 ；這就是為何現在各企業在落地實戰「測試右移」；

雖然不能發現100%的缺陷，但我們可以做到實時監控，以及在用戶發現缺陷之前，把缺陷給“偷偷的”解決了(這就是老徐之前說的：軟件測試從業者終極目標，線上零BUG如何實現 ？) ；

三、缺陷是相對的

除了明顯的功能不可用、Error報錯等；不符合預期結果，也可以稱為“Bug” ；

如果連預期結果都沒有，或者產品經理，根本就沒有告訴你，這個點，應該是怎么樣的 ；

這個時候，就得跟產品經理，好好勾兌，懟需求了；

這就是為何IT團隊，經常跟產品經理，討論如此火熱的原因(每個人對預期結果的想法是不一樣的)；

但，這里有一個點：作為一名軟件測試工程師，你是可以通過接觸足夠多的行業軟件 / 行業系統 ，去引導產品經理、開發工程師，按你的想法，達成你期望的結果 ；

這就是所謂的“用戶體驗測試” ；

總結

以上是生活随笔為你收集整理的软件测试的8.20原则,四个维度，拆解「软件测试中的80 / 20原则」的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。