一般常用的缺陷預防有幾個階段，需求階段，設計階段，編碼階段。
第一，在需求階段，最重要的事情是需求驗證。一般驗證的幾個大項是，功能是否完整，是否考慮效能，有沒有模糊需求，有沒有考慮安全性，有沒有冗餘和錯誤的需求，需求是不是過於苛刻，需求是不是矛盾等方面。一般常用的方法是列出需求檢查表，並進一步執行需求
/測試矩陣。
第二，設計階段，這個階段主要通過技術評審測試邏輯設計。常用比較規範的作法是建立過程
/資料矩陣，也就是
crud
矩陣，把過程影射到實體，把整個程式的資料的生命週期（建立，更新，讀取，刪除）反映出來。
第三，編碼階段，這個階段預防措施主要有統一編碼規範，**評審，單元測試。統一**規範一般是開發經理統一要求，**評審則是互相評審或者開發
leader
進行評審，最後最重要的則是單元測試，就是一般說的白盒測試。
缺陷分析，很多高深的分析技術也不很實用，現介紹一點常用的分析方法。 1
、模組的缺陷分布。一般用柱狀圖或餅狀圖。就是每乙個功能模組發現
bug的比例，發現
bug最多的模組證明在發布以後需要更多的維護。
另外，歷史資料可以參照，譬如上乙個版本在哪個模組發現的
bug比例對這個版本就是乙個參考。如果，某個模組發現
bug的比例比上個版本大幅下降，則很可能說明該模組還需要更多測試。 2
、缺陷的起因分布。一般用柱狀圖或餅狀圖。一般可分為架構缺陷、功能缺陷、易用性缺陷、效能缺陷、安全性缺陷、介面文字缺陷。一般如果架構缺陷佔的比例較大，則說明設計有很大問題。 3
、按照不同發現人員的缺陷分布，一般用柱狀圖或餅狀圖，一般分為測試人員發現，開發人員發現，
beta
測試發現，外部客戶發現。如果測試人員發現的
bug低於某個比例，證明質量保證測試不足。 4
、按照不同方式的缺陷分布，一般有需求審查，設計測試，**走查，
jad，手工測試，自動化測試，白盒測試。一般來說，如果通過需求審查，設計測試，**走查，
jad（
聯合應用開發）發現的
bug
比重很低則說明測試前期重視不夠，另外，在手工測試和自動化測試之間的比例也能說明自動化測試的貢獻度。 5
、缺陷差額分析
.就是已經發現的和已經解決的曲線關係，以時間為橫軸，兩者越接近說明產品質量越高 6
、時間段的缺陷分布。一般用時間為橫軸的曲線圖表示。主要說明在哪個階段發現的
bug最多，對測試總結有指導意義 7
、rayleigh
分析，即俗稱的零缺陷追蹤法。一般截至某個時間點發現的缺陷總數和時間有乙個函式關係（乙個複雜的數學函式），一般用這個函式來推測經過多少天測試之後軟體中大概還有多少個
bug，以及交付到使用者手中之後大概還能出現多少個
bug。
如何有效地描述軟體缺陷 Defect ？
作為軟體測試人員，最基本的一項技能就是如何把所發現的缺陷 defect 準確無歧義的表達出來，尤其還是全英文表達的時候。其實從缺陷的描述也可以看出乙個軟體測試人員的基本功，甚至可以看出測試人員在做一些自由測試的時候的投入程度。本文主要以缺陷出現的頻率來說明測試人員在遇到不同頻率的缺陷的時候如何做?缺...
如何有效地描述軟體缺陷 Defect ？
最近乙個月偷懶了，剛看到一篇博文很不錯。最近也是碰到一樣的問題，由於我記錄bug的描述不夠清晰。導致開發看不懂我描述的bug，還有一些配置資訊沒記錄好。出現一問三不知的情況，還被領導訓。下面的博文是來自的。作為軟體測試人員，最基本的一項技能就是如何把所發現的缺陷 defect 準確無歧義的表達出來，...
如何寫乙個好的缺陷（Defect）報告
編寫缺陷報告是測試人員的日常工作，好的缺陷報告能夠讓開發人員更容易理解，更快速的定位問題 不好的缺陷報告可能會誤導調查方向，增加溝通成本。那麼乙個好的缺陷報告應該包括哪些方面呢？請看我的mindmap 1.首先要做乙個 標題黨 此標題黨非彼標題黨 標題一定要清晰簡潔易理解，不應該臃長 2.盡量字首要...