（本文基於網路資料，由「趙亮-碧海情天」重新進行組織和個別修正，使之更符合邏輯理解的順序和更加嚴謹。）
缺陷是指程式中存在的錯誤或不理想的設計。
即使有經驗的程式設計師，一般開發10行左右源程式就會引入乙個缺陷。通常在編譯和測試階段能發現和糾正大部分缺陷，但仍有許多缺陷留在最終產品中。
為防止缺陷的引入，需要精通所用的程式語言，深入理解開發支援環境，掌握要開發的應用系統的型別，並具有豐富的設計經驗等。
一般的軟體組織要用一半以上的時間和精力來查詢和修復缺陷。由於測試時間難以預計，產品缺陷常常是產生超支和延期的主要原因。
當軟體工程師對你說程式中僅剩幾個bug時，你可能感到一陣輕鬆。但若告訴你，程式經過全部測試，僅留幾個定時炸彈時，你的感覺又會如何？
編寫程式的軟體工程師本人最適合查詢和修復程式中的缺陷，因此軟體工程師應該承擔所生產的軟體的質量責任。
若你不朝著設計無缺陷程式的方向努力，你永遠也不可能做到這一點。
把缺陷進行分類，把精力集中到最容易引起問題的幾類缺陷上，這是缺陷管理的關鍵。
逃過你所有的缺陷預防和檢測手段的漏網者，對於了解你自己的個體軟體過程的弱點是非常重要的，對它們的了解將成為你個體過程改善的主要資料**。
目前，我們可以把精力集中在編譯或測試階段來發現缺陷。隨著收集缺陷的增多和習慣，逐漸關注和尋找在設計和編碼階段出現的錯誤，因為大多數的缺陷還是在設計和編碼階段引入的。
編譯器是現有速度最快的缺陷檢測工具，但它只能查出大約90%的語法錯誤和很少的邏輯錯誤。它並不能真正辨認你整體的意圖.
編譯器檢查不出來的大部分是設計錯誤，也有一些是語法錯誤。c++的缺陷資料表明，大約有9.4%的語法錯誤會通過編譯。
通過使用者發現和反饋找出缺陷
這是一種常見的方法，事實證明，這也是花費最大的策略，如ibm每年花費大約2.5億美元用於修復1.3萬個客戶反饋的缺陷和重新安裝修復後的版本，每個缺陷花費約2000美元。
單元測試是最有效的測試階段，但它只能發現大約50%的缺陷。
系統測試一般僅能找到進入系統測試時產品中缺陷的大約30~40%
測試可以驗證程式幾乎所有的功能，但它只能給出缺陷的徵兆，需要你去找出問題的根源，然後開始修復。
**複查就是個人複查源程式清單。這是最快和最有效的發現和修復缺陷的方法。
**複查有效率的原因是：在**複查時看到的是缺陷本身而不是徵兆。
同行檢查，或叫同行評審，是讓幾個工程師彼此複查程式。同行檢查組織得好，一般會發現程式中50~70%的缺陷。
**複查也有缺點：一是非常耗時，二是很難恰當地進行。
在psp（個體軟體過程）中主要的缺陷排除方法就是個人**複查：先列印程式清單，然後逐行進行複查。
最有效的方法是找出以前的程式中，在編譯和測試階段引起最大問題的那些缺陷型別。
在第一次編譯前仔細地複查**，能減少大約10%的編譯時間，並且可節省更多的測試時間。
（趙亮注：看上去這不一定合算，但不要忘了，bug總是會有的，**遲早要檢查的，既然早晚要走這麼一趟，何不先行一步呢？況且，保持在測試人員與上司心目中的光輝形象也是很重要的哦，倒不只是虛榮心，將來公升職加薪也都是要參考你的工作表現的。）
軟體工程之軟體專案管理（估算缺陷的數量）
林肯指數依賴於假設 測試者發現任何缺陷的機會相等 假定兩位測試者發現乙個bug的概率分別為p1和p2，在應用程式中總共有b個缺陷，則他們可能分別找到e1 p1 b，e2 p2 b個缺陷 某個特殊的缺陷被同時發現的概率是p1 p2 因此，預計他們能同時發現s p1 p2 b個缺陷 所以，總共的缺陷數量...
個體軟體過程 PSP 學習筆記 未完
軟體開發中的問題 什麼是過程？過程要素詳解 psp框架說明 你還可以 psp提供了 計畫過程是從規模估算開始的，由此必須做規模估算 依據規模估算，我們可以估計出完成產品開發所需要的時間 怎麼算？在此之前，我們必須有乙個度量規模的方法 過程度量原則 度量過程並不會改進它，為了達到持久改進，必須改變過程...
軟體缺陷管理流程
軟體缺陷 bug 能夠引起軟體執行時產生的一種不希望或不可接受的外部行為結果，而 軟體測試缺陷管理流程。一 缺陷產生的原因 通常開發及測試人員所講述的軟體錯誤和軟體缺陷是兩個不同的概念，簡單的來講軟體錯誤是指在軟體宣告週期內不希望或不可見接受的人為錯誤，其結果是導致軟體缺陷的產生。在軟體動態執行過程...