什么是軟件缺陷？
軟件缺陷（Defect），常常又被叫做Bug。
所謂軟件缺陷，即為計算機軟件或程序中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。
缺陷的存在會導致軟件產品在某種程度上不能滿足用戶的需要。
IEEE729-1983對缺陷有一個標准的定義：
從產品內部看，缺陷是軟件產品開發或維護過程中存在的錯誤、毛病等各種問題；
從產品外部看，缺陷是系統所需要實現的某種功能的失效或違背。
缺陷屬性
缺陷標識(Identifier)： 缺陷標識是標記某個缺陷的一組符號。每個缺陷必須有一個唯一的標識。
缺陷類型 (Type)： 缺陷類型是根據缺陷的自然屬性划分的缺陷種類。
缺陷嚴重程度 (Severity) ：缺陷嚴重程度是指因缺陷引起的故障對軟件產品的影響程度。
缺陷優先級(Priority)： 缺陷的優先級指缺陷必須被修復的緊急程度。
缺陷狀態(Status) ：缺陷狀態指缺陷通過一個跟蹤修復過程的進展情況。
缺陷起源(Origin) ：缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段。
缺陷來源(Source)： 缺陷來源指引起缺陷的起因。
缺陷根源(Root Cause)： 缺陷根源指發生錯誤的根本因素。
缺陷類型（Type）
F- Function ：影響了重要的特性、用戶界面、產品接口、硬件結構接口和全局數據結構。並且設計文檔需要正式的變更。如邏輯，指針，循環，遞歸，功能等缺陷。
A- Assignment： 需要修改少量代碼，如初始化或控制塊。如聲明、重復命名，范圍、限定等缺陷。
I- Interface： 與其他組件、模塊或設備驅動程序、調用參數、控制塊或參數列表相互影響的缺陷。
C- Checking： 提示的錯誤信息，不適當的數據驗證等缺陷。
B Build/package/merge ：由於配置庫、變更管理或版本控制引起的錯誤。
D- Documentation： 影響發布和維護，包括注釋。
G- Algorithm ：算法錯誤。
U-User Interface：人機交互特性：屏幕格式，確認用戶輸入，功能有效性，頁面排版等方面的缺陷。
P-Performance：不滿足系統可測量的屬性值，如：執行時間，事務處理速率等。
N-Norms：不符合各種標准的要求，如編碼標准、設計符號等。
缺陷嚴重程度（Severity）
軟件測試錯誤嚴重程度
Critical：不能執行正常工作功能或重要功能。或者危及人身安全。
Major：嚴重地影響系統要求或基本功能的實現，且沒有辦法更正。（重新安裝或重新啟動該軟件不屬於更正辦法）
Minor：嚴重地影響系統要求或基本功能的實現，但存在合理的更正辦法。（重新安裝或重新啟動該軟件不屬於更正辦法）
Cosmetic：使操作者不方便或遇到麻煩，但它不影響執行工作功能或重要功能。
Other：其它錯誤。
同行評審錯誤嚴重程度
Major：主要的，較大的缺陷
Minor：次要的，小的缺陷
缺陷優先級（Priority）
Resolve Immediately：缺陷必須被立即解決。
Normal Queue：缺陷需要正常排隊等待修復或列入軟件發布清單。
Not Urgent：缺陷可以在方便時被糾正。
缺陷狀態（Status）
Submitted: 已提交的缺陷
Open :確認“提交的缺陷”，等待處理
Rejected: 拒絕“提交的缺陷”，不需要修復或不是缺陷
Resolved :缺陷被修復
Closed :確認被修復的缺陷，將其關閉
這里根據不同公司需求的不同，其實還有幾個細節狀態：
Verified :已驗證修復的缺陷，等待上線。
Hang : 掛起，暫時不予處理的缺陷
缺陷起源（Origin）
Requirement：在需求階段發現的缺陷
Architecture：在構架階段發現的缺陷
Design：在設計階段發現的缺陷
Code：在編碼階段發現的缺陷
Test：在測試階段發現的缺陷
缺陷來源（Source）
Requirement： 由於需求的問題引起的缺陷
Architecture： 由於構架的問題引起的缺陷
Design： 由於設計的問題引起的缺陷
Code： 由於編碼的問題引起的缺陷
Test： 由於測試的問題引起的缺陷
Integration： 由於集成的問題引起的缺陷
生命周期
在很多公司的流程里，其實是這樣的一個流程。
缺陷提交 -> 確認缺陷 -> 已拒絕 -> 關閉或重新打開
缺陷提交 -> 確認缺陷 -> 缺陷修復 -> 缺陷已驗證 -> 關閉（缺陷已上線）
而這個流程，通常被稱為缺陷的生命周期。
提交（打開）缺陷
在提交一個缺陷的缺陷，首先盡量描述這個缺陷的屬性。Bug重現環境，bug類型，bug等級，bug的優先級以及詳細的重現步驟，結果與期望等。
當然，我們在提交一個問題之前首先應該保證，這個缺陷是沒有被提過的，以免造成重復缺陷單。
如果是回歸不通過的缺陷，其狀態又會變為打開狀態。
分配（轉交）缺陷
這一步不是必須的，跟項目模式有關，有些公司測試部門與開發部門獨立，那么測試人員就不確定自己測試的模塊是由哪位開發人員負責的，在這種情況下，測試人員統一把問題指派給項目組長或經理，由項目組長（或經理）對問題進行確認后再次分配給相應的開發人員。
有些測試人員是穿插到不同研發團隊中的，所以對不同的開人發員負責的開發模塊非常清楚，這個時候就可以將問題直接指派給相應的開發人員。
也有一種情況，本來此問題應該由A開發人員負責，但由於A開發人員的調離或辭職，些問題為轉交給其它人員處理。“分配”強調是上級對下級；“轉交”強調的是平級之間。
確認缺陷
當開發人員接到一個缺陷時，首先是對其進行分析與重現，如果對其進行分析發現不是缺陷（可能由於測試人員不了解需求）或無法對此問題進行重現，那么就需要將此問題反回給測試人員，並注明原因。如果確認為缺陷則需要對其進行處理。
掛起
在處理問題之后，還需要進行一次判斷，是否需要推遲處理，有些需求已經確認了是問題，由於其可能在極端情況下才會出現，或需要對系統架構進行改動，或其優先級非常低，所以暫時不需要對此問題進行處理（或到下個版本進再進行修復）。
修復缺陷
開發人員在確認完一個問題需要處理時，那么就對其進行處理工作。（例如，redmine 是支持處理人時時更新問題處理進度的，如 已處理30% ，已處理80% 等，當然，對於短時間內可以修復的問題就沒必要時時的去更新處理進度。）
回歸缺陷
回歸缺陷對於測試人員來說是非常重要的工作，其有三個入口兩個出口。
確認非缺陷問題：對於提交的一個缺陷，開人員處理為非問題或無法重現，然后直接轉交給測試人員回歸。測試人員再次確認，如果真如開發人員所說，則將問題關閉。如果非開發人員所說，是由於問題描述模糊或其它原因喂重現問題，則再次注明原因轉給開發人員。
確認修復問題：對開發人員修復的問題再次進行確認，確認能過，則關閉問題。確認不通過，將問題再次打開並轉給開發人員。
確認固定問題：有計划的對固定問題進行確認，有些固定問題隨着時間的推移，版本的更新或已經不存在了，對這類問題應該及時關閉。有些固定問題依然存在且變得緊急，對於這類問題應該及時打開交給開發人員處理。
關閉缺陷
對於已經修復的缺陷進行關閉，這也是一個缺陷的最后一個狀態