軟件缺陷可以分類方法(軟件缺陷的分類標準)
1.軟件缺陷的分類標準
1.缺陷標識（Identifier）： 缺陷標識是標記某個缺陷的一組符號。每個缺陷必須有一個唯一的標識。
2.缺陷類型 （Type）： 缺陷類型是根據缺陷的自然屬性劃分的缺陷種類。
3.缺陷嚴重程度 （Severity） ：缺陷嚴重程度是指因缺陷引起的故障對軟件產品的影響程度。
4.缺陷優(yōu)先級（Priority）： 缺陷的優(yōu)先級指缺陷必須被修復的緊急程度。
5.缺陷狀態(tài)（Status） ：缺陷狀態(tài)指缺陷通過一個跟蹤修復過程的進展情況。
6.缺陷起源（Origin） ：缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段。
7.缺陷來源（Source）： 缺陷來源指引起缺陷的起因。
8.缺陷根源（Root Cause）： 缺陷根源指發(fā)生錯誤的根本因素。 F- Function ：影響了重要的特性、用戶界面、產品接口、硬件結構接口和全局數據結構。并且設計文檔需要正式的變更。如邏輯，指針，循環(huán)，遞歸，功能等缺陷。
A- Assignment： 需要修改少量代碼，如初始化或控制塊。如聲明、重復命名，范圍、限定等缺陷。
I- Interface： 與其他組件、模塊或設備驅動程序、調用參數、控制塊或參數列表相互影響的缺陷。
C- Checking： 提示的錯誤信息，不適當的數據驗證等缺陷。
B Build/package/merge ：由于配置庫、變更管理或版本控制引起的錯誤。
D- Documentation： 影響發(fā)布和維護，包括注釋。
G- Algorithm ：算法錯誤。
U-User Interface：人機交互特性：屏幕格式，確認用戶輸入，功能有效性，頁面排版等方面的缺陷。
P-Performance：不滿足系統可測量的屬性值，如：執(zhí)行時間，事務處理速率等。
N-Norms：不符合各種標準的要求，如編碼標準、設計符號等。 軟件測試錯誤嚴重程度
1.Critical：不能執(zhí)行正常工作功能或重要功能?；蛘呶＜叭松戆踩?/p>
2.Major：嚴重地影響系統要求或基本功能的實現，且沒有辦法更正。（重新安裝或重新啟動該軟件不屬于更正辦法）
3.Minor：嚴重地影響系統要求或基本功能的實現，但存在合理的更正辦法。（重新安裝或重新啟動該軟件不屬于更正辦法）
4.Cosmetic：使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作功能或重要功能。
5.Other：其它錯誤。
同行評審錯誤嚴重程度
1.Major：主要的，較大的缺陷
2.Minor：次要的，小的缺陷 1.Resolve Immediately：缺陷必須被立即解決。
2.Normal Queue：缺陷需要正常排隊等待修復或列入軟件發(fā)布清單。
3.Not Urgent：缺陷可以在方便時被糾正。 1.Submitted： 已提交的缺陷
2.Open ：確認“提交的缺陷”，等待處理
3.Rejected： 拒絕“提交的缺陷”，不需要修復或不是缺陷
4.Resolved ：缺陷被修復
5.Closed ：確認被修復的缺陷，將其關閉 1.Requirement：在需求階段發(fā)現的缺陷
2.Architecture：在構架階段發(fā)現的缺陷
3.Design：在設計階段發(fā)現的缺陷
4.Code：在編碼階段發(fā)現的缺陷
5.Test：在測試階段發(fā)現的缺陷 1.Requirement： 由于需求的問題引起的缺陷
2.Architecture： 由于構架的問題引起的缺陷
3.Design： 由于設計的問題引起的缺陷
4.Code： 由于編碼的問題引起的缺陷
5.Test： 由于測試的問題引起的缺陷
6.Integration： 由于集成的問題引起的缺陷
2.軟件缺陷包括哪些內容
一般我們都認為測出一個問題就是一個bug，其實這是不對的，假設測試10個問題就10個bug，而修改一出就全解決了，程序員肯定認為冤枉自己。
所有軟件是文檔，代碼等組成的，最初的錯誤是來自于這些軟件錯誤（software error），如代碼中加法寫成減法。軟件錯誤導致軟件缺陷（software defect），如設計缺陷，代碼缺陷等，可用靜態(tài)測試，如走查，靜態(tài)檢查，測試床（軍事軟件用的技術）等，軟件的缺陷導致一個或多個軟件故障 （software fault），故障有內部故障，外部故障，也就是我們所說的bug，軟件故障導致了軟件在功能操作等方面的失效（software failure）。
我們平時測的bug實際上是軟件故障于失效的體現。一旦軟件錯誤得到修改，相應的故障與失效也就解除了。這樣分有助于我們定位問題，找到問題。
3.缺陷分析方法具體有哪幾種
1、ODC缺陷分析：由IBM 的waston中心推出。
Phontol.com將一個缺陷在生命周期的各環(huán)節(jié)的屬性組織起來，從單維度、多維度來對缺陷進行分析，從不同角度得到各類缺陷的缺陷密度和缺陷比率，從而積累得到各類缺陷的基線值，用于評估測試活動、指導測試改進和整個研發(fā)流程的改進；同時根據各階段缺陷分布得到缺陷去除過程特征模型，用于對測試活動進行評估和預測。Phontol.com上面回答中涉及到的缺陷分布、缺陷趨勢等都屬于這個方法中的一個角度而已。
2、Gompertz分析：根據測試的累積投入時間和累積缺陷增長情況，擬合得到符合自己過程能力的缺陷增長Gompertz曲線，用來評估軟件測試的充分性、預測軟件極限缺陷數和退出測試所需時間、作為測試退出的判斷依據、指導測試計劃和策略的調整； 3、Rayleigh分析：通過生命周期各階段缺陷發(fā)現情況得到缺陷Rayleigh曲線，用于評估軟件質量、預測軟件現場質量； 4、四象限分析：根據軟件內部各模塊、子系統、特性測試所累積時間和缺陷去除情況，和累積時間和缺陷去除情況的基線進行比較，得到各個模塊、子系統、特性測試分別所位于的區(qū)間，從而判斷哪些部分測試可以退出、哪些測試還需加強，用于指導測試計劃和策略的調整； 5、根本原因分析：利用魚骨圖、柏拉圖等分析缺陷產生的根本原因，根據這些根本原因采取措施，改進開發(fā)和測試過程； 6、缺陷注入分析：對被測軟件注入一些缺陷，通過已有用例進行測試，根據這些刻意注入缺陷的發(fā)現情況，判斷測試的有效性、充分性，預測軟件殘留缺陷數。 7、DRE/DRM分析：通過已有項目歷史數據，得到軟件生命周期各階段缺陷注入和排除的模型，用于設定各階段質量目標，評估測試活動。
4.軟件缺陷的五種特征
簡單說下軟件缺陷的最明顯的特征吧知
集結（二八定理）
缺陷往往喜歡扎堆，一個模塊已經發(fā)現的缺陷比別的模塊多，
通常不是代表這個模塊已經把缺陷暴露完了，而是意味著這
個模塊還存在有同樣多的缺陷尚未被道發(fā)現。這就是著名的二
八定理：80%的缺陷出現在 20%的模塊。
缺陷抗藥性
測試進行得越多，新缺陷就越難被發(fā)現
1. 因為之前一直使用同樣的測試思內路，同樣的一套測試用
例，沒有新的突破。
2. 某些缺陷天然地只有在很特殊或者很極端的情況下才會
被觸發(fā)
并非所有缺陷都要修改
p有一些原因，使得有容些缺陷我們不修復
1. 修復的風險太大
2. 沒有足夠的時間
3. 下一版本修復
p 所有未修復的bug都處于“掛起”狀態(tài)
5.軟件缺陷包括哪些內容
一般我們都認為測出一個問題就是一個bug，其實這是不對的，假設測試10個問題就10個bug，而修改一出就全解決了，程序員肯定認為冤枉自己。
所有軟件是文檔，代碼等組成的，最初的錯誤是來自于這些軟件錯誤（software error），如代碼中加法寫成減法。軟件錯誤導致軟件缺陷（software defect），如設計缺陷，代碼缺陷等，可用靜態(tài)測試，如走查，靜態(tài)檢查，測試床（軍事軟件用的技術）等，軟件的缺陷導致一個或多個軟件故障 （software fault），故障有內部故障，外部故障，也就是我們所說的bug，軟件故障導致了軟件在功能操作等方面的失效（software failure）。
我們平時測的bug實際上是軟件故障于失效的體現。一旦軟件錯誤得到修改，相應的故障與失效也就解除了。
這樣分有助于我們定位問題，找到問題。
