0.軟件缺陷的產生
軟件缺陷 - Software Defect - Bug；缺陷的存在會導致軟件產品在某種程度上不能滿足用戶的需要。IEEE729-1983對缺陷的標準定義：從產品內部看，缺陷是軟件產品開發或維護過程中存在的錯誤、毛病等各種問題；從產品外部看，缺陷是系統所需要實現的某種功能的失效或違背。
在軟件的開發測試過程中項目組會特別關注軟件缺陷的狀況，這是因爲一方面軟件缺陷狀況是項目質量和狀態的重要指示數據，另一方面越到軟件生命週期的後期修復軟件缺陷的成本越高。
1.常見的缺陷
功能沒有實現或與需求規格說明不一致；界面、消息、提示、幫助不夠準確或誤導用戶；屏幕顯示、打印結果不正確；軟件無故退出或沒有反應;邊界條件未做處理，輸入錯誤數據沒有提示和說明；運行速度慢或佔用資源過多；與常用的交互軟件不兼容；有時把尚未完成的小功能也歸屬於軟件缺陷
2.產生原因
在軟件開發的過程中，軟件缺陷的產生是不可避免的，”零缺陷”是軟件產品很難達到一個狀態。導致軟件缺陷產生的原因也是多種多樣的，軟件工程過程中的人、過程、工具都有可能導致產生軟件缺陷，過程中的每一個環節都有可能產生缺陷，概括來說這些原因可以歸結爲四大類。
軟件本身的複雜性和抽象性：在產品真正完成之前，每個人對軟件的理解都不完全相同，這種複雜和抽象使得軟件容易出現缺陷
軟件技術在某些領域應用不成熟，使得某些功能或性能無法達到應用要求，也會導致軟件缺陷的產生
如果軟件開發流程不完善，存在太多的隨機性，缺乏嚴謹的評審機制，則容易產生軟件缺陷。目前軟件行業對項目管理和軟件過程的研究實踐已經有很多成果，比如全流程質量管理、CMMI模型等軟件工程方法。
軟件團隊的成員能力水平不足也會引起軟件缺陷的產生。比如編碼人員能力不足，會產生很多算法錯誤和語法錯誤導致軟件不能正常工作或者性能低下。
3.缺陷屬性
爲了方便引用、理解、解決、測試、迴歸，跟蹤、分析軟件缺陷，軟件缺陷有很多屬性，比如編號ID，解決人，測試人、狀態、所屬功能模塊、嚴重程度等等。這些屬性並不是在缺陷錄入的時候就全部指定的，而是隨着軟件缺陷的流轉根據需要不斷完善的。一個完整的缺陷報告應該清楚的描述BUG的症狀和其他基本信息。不同的團隊根據缺陷管理的需要使用的缺陷屬性不同。
優先級是處理和修正軟件缺陷的先後順序的指標，即哪些缺陷需要優先修正，哪些缺陷可以稍後修正。
理論上來說，確定軟件缺陷優先級，更多的是站在軟件開發工程師的角度考慮問題，因爲缺陷的修復是個複雜的過程，有些不是純粹技術問題，而且開發人員更熟悉軟件代碼，能夠比測試工程師更清楚修復缺陷的難度和風險。
但是實際上，企業在確定缺陷優先級並不只站在開發工程師角度，而是對解決的難度、缺陷對產品銷售的影響、客戶的重要性等方面綜合考慮確定的。
嚴重性(Severity)是軟件缺陷對軟件質量的破壞程度，即此軟件缺陷的存在將對軟件的功能和性能產生怎樣的影響。在軟件測試中，軟件缺陷的嚴重性的判斷應該從軟件最終用戶的觀點做出判斷，即判斷缺陷的嚴重性要爲用戶考慮，考慮缺陷對用戶造成的後果的嚴重性。
團隊在開展測試工作時會根據團隊管理和產品的實際需要定義缺陷的字段，少則六七個字段，多則可達十幾二十個。
4.統計度量
軟件缺陷作爲軟件質量的重要指標變量，對其進行統計分析以明確項目質量情況，幫助管理者進一步做決策意義重大。
缺陷密度Dd：Dd=缺陷數量/代碼行或功能點的數量，其單位爲每千行代碼的缺陷數(Defects/KLOC)。
遺留缺陷密度：遺留缺陷數/代碼行或功能點數
缺陷探測率DDP：發佈前發現的缺陷數/缺陷總數
缺陷趨勢分析統計
缺陷分佈分析統計
缺陷根源分析統計
5.管理工具
軟件缺陷管理指南、軟件缺陷報告錄入模板和指南、軟件缺陷管理系統、
（0）分類
軟件缺陷管理系統分類：1.自主開發、購買、開源 2.單獨的缺陷管理工具、集成在研發管理系統中
典型的軟件缺陷管理系統：1.Bugzilla：https://www.bugzilla.org/ 2.禪道項目管理軟件中的缺陷管理子系統 3.JIRA：https://www.atlassian.com/software/jira 4.ALM中的缺陷管理子系統
（1）功能
工具是理論的載體，理解了理論才能靈活運用工具，一般的缺陷管理系統有如下功能:字段配置、缺陷跟蹤、添加缺陷、修改缺陷、關聯缺陷和測試用例、統計分析功能