缺陷的定義
軟體沒有達到產品說明書表明的功能
軟體出現了產品說明書中不一致的表現
軟體功能超出產品說明書的範圍
軟體沒有達到使用者期望的目標(雖然產品說明書中沒有要求)
測試員或使用者認為軟體的易用性差
不是所有缺陷都會修改
市場的壓力使得產品最終發行有時間限制
測試員錯誤理解或者不正確操作引出的缺陷(faq)
錯誤的修改影響的模組較多，帶來的風險較大（遺留）
修改價效比太低(faq，遺留）
缺陷報告中提出的問題很難重現
缺陷分析的關注點：
對軟體問題的功能域分布進行分析，找出系統的薄弱環節
要詳細採集每個功能模組或系統構件的bug資料，並按功能、錯誤型別、嚴重程度等分類
比較實際發現的軟體bug是否與預期的問題分布相吻合
二八定理：80%的軟體問題總是發生在大約20%的功能模組（系統構件）中。
、對bug的注入階段的分布進行分析，並與歷史資料相比較。應按不同的開發階段詳細採集bug的資料
要求軟體各開發階段的缺陷密度小於本單位過去的平均值
而且要求需求分析、設計和**複查階段的缺陷排除率之和大於或等於規定值（例如75%）。（同行評審）
應對軟體缺陷型別進行分析，以便針對各自的特點，先修復嚴重缺陷。
軟 件 缺 陷 分 類 標 準
分類範疇
子專案
缺陷等級
備註
系統缺陷
由於程式所引起的宕機，非法退出
待定（建議a類）
不能執行正常工作工那或重要功能，使系統崩潰
程式死迴圈
待定（建議a類）
或資源嚴重不足
程式錯誤
待定（建議a類）
待定（建議a類）
資料缺陷
資料計算錯誤
待定（建議b類）
嚴重地影響系統要求或基本功能地實現，且沒有
資料約束錯誤
待定（建議b類）
辦法更正（重新安裝或重新啟動軟體不屬更正
資料輸入、輸出錯誤
待定（建議b類）
辦法）待定（建議b類）
資料庫缺陷
資料庫發生死鎖
待定（建議b類）
資料庫的表、預設值未加完整性等約束條件
待定（建議b類）
資料庫連線錯誤
待定（建議b類）
資料庫中的表有過多的空欄位
待定（建議b類）
介面缺陷
資料通訊錯誤
待定（建議b類）
程式介面錯誤
待定（建議b類）
硬體介面、通訊錯誤
待定（建議b類）
待定（建議b類）
功能錯誤
程式功能無法實現
待定（建議c類）
嚴重的影響系統要求或基本功能的實現，但存在
程式功能實現錯誤
待定（建議c類）
合理的更正辦法（重新安裝或重新啟動軟體不屬
待定（建議c類）
於更正辦法
介面錯誤
操作介面錯誤
待定（建議d類）
使操作者不方便或遇到麻煩，但不影響執行工作
列印內容、格式錯誤
待定（建議d類）
功能的實現
刪除操作未給出提示
待定（建議d類）
長時操作未給出提示
待定（建議d類）
介面不規範
待定（建議d類）
介面錯誤詳細清單見《介面缺陷分類》
待定（建議d類）
建議類錯誤
功能建議
待定（建議e類）
建議性的改進要求
操作建議
待定（建議e類）
校驗建議
待定（建議e類）
說明建議
待定（建議e類）
說明：以上缺陷分類中的內容構成基本缺陷庫，根據實際工作總結，將不斷擴充、完善。如新增分類，或分類內容均需要經過技術總監與質量主管的認可，備註中的內容為缺陷等級分類說明。
軟體缺陷的分類與管理
軟體缺陷的分類與管理 通常大家發現軟體缺陷時會對軟體缺陷進行分類，可分類的方式只有一種，就是嚴重極別,難道沒有其它的分法嗎。比如我們碰到下面這種情況，測試人員發現有一種功能是必需加入進去的，這時他與程式設計師說，程式設計師說沒有時間或是不必要，這時這種情況則會形成兩者的扯皮，最終的結果也就不了了知了...
軟體缺陷分析
alan 缺陷分析本質上是對缺陷中包含的資訊項進行收集，彙總，分類之後使用統計方法 或者分析模型 得出分析結果。缺陷分析得出的結果可以用來度量軟體開發過程中各階段中工作產品的質量，了解缺陷集中的區域，明晰缺陷發展趨向。對於軟體過程的改進，軟體產品的發布來說具有十分重要的參考價值 在我們提交缺陷報告的...
軟體缺陷分析
我在marvell實習了一年多，期間主要做的軟體缺陷分析的工作，比如軟體缺陷的度量，風險分析等，結果一年多的不斷學習，我覺得這件事是非常的有意義，然後，國內很少有公司會選擇在這一塊投入，主要原因是這個過程需要長期的投入才能見成效，其次，風險也比較大。我主要會做一些軟體缺陷的分類統計，和缺陷累積量的 ...