類别
缺陷的表現形式不僅體現在功能的失效方面，還體現在其他方面。主要類型有：軟件沒有實現産品規格說明所要求的功能模塊；軟件中出現了産品規格說明指明不應該出現的錯誤；軟件實現了産品規格說明沒有提到的功能模塊；軟件沒有實現雖然産品規格說明沒有明确提及但應該實現的目标；軟件難以理解，不容易使用，運行緩慢，或從測試員的角度看，最終用戶會認為不好。
以計算器開發為例。計算器的産品規格說明
定應能準确無誤地進行加、減、乘、除運算。如果按下加法鍵，沒什麼反應，就是第一種類型的缺陷；若計算結果出錯，也是第一種類型的缺陷。
産品規格說明書還可能規定計算器不會死機，或者停止反應。如果随意敲鍵盤導緻計算器停止接受輸入，這就是第二種類型的缺陷。
如果使用計算器進行測試，發現除了加、減、乘、除之外還可以求平方根，但是産品規格說明沒有提及這一功能模塊。這是第三種類型的缺陷——軟件實現了産品規格說明書中未提及到的功能模塊。
在測試計算器時若發現電池沒電會導緻計算不正确，而産品說明書是假定電池一直都有電的，從而發現第四種類型的錯誤。
軟件測試員如果發現某些地方不對，比如測試員覺得按鍵太小、“=”鍵布置的位置不好按、在亮光下看不清顯示屏等，無論什麼原因，都要認定為缺陷。而這正是第五種類型的缺陷。
根據以上五種缺陷類型，在軟件測試中可以區分不同類型的問題。
分類标準
缺陷屬性
1.缺陷标識(Identifier)：缺陷标識是标記某個缺陷的一組符号。每個缺陷必須有一個唯一的标識。
2.缺陷類型(Type)：缺陷類型是根據缺陷的自然屬性劃分的缺陷種類。
3.缺陷嚴重程度(Severity)：缺陷嚴重程度是指因缺陷引起的故障對軟件産品的影響程度。
4.缺陷優先級(Priority)：缺陷的優先級指缺陷必須被修複的緊急程度。
5.缺陷狀态(Status)：缺陷狀态指缺陷通過一個跟蹤修複過程的進展情況。
6.缺陷起源(Origin)：缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段。
7.缺陷來源(Source)：缺陷來源指引起缺陷的起因。
8.缺陷根源(Root Cause)：缺陷根源指發生錯誤的根本因素。
缺陷類型（Type）
F-Function：影響了重要的特性、用戶界面、産品接口、硬件結構接口和全局數據結構。并且設計文檔需要正式的變更。如邏輯，指針，循環，遞歸，功能等缺陷。
A-Assignment：需要修改少量代碼，如初始化或控制塊。如聲明、重複命名，範圍、限定等缺陷。
I-Interface：與其他組件、模塊或設備驅動程序、調用參數、控制塊或參數列表相互影響的缺陷。
C-Checking：提示的錯誤信息，不适當的數據驗證等缺陷。
BBuild/package/merge：由于配置庫、變更管理或版本控制引起的錯誤。
D-Documentation：影響發布和維護，包括注釋。
G-Algorithm：算法錯誤。
U-UserInterface：人機交互特性：屏幕格式，确認用戶輸入，功能有效性，頁面排版等方面的缺陷。
P-Performance：不滿足系統可測量的屬性值，如：執行時間，事務處理速率等。
N-Norms：不符合各種标準的要求，如編碼标準、設計符号等。
缺陷嚴重程度（Severity）
軟件測試錯誤嚴重程度
1.Critical：不能執行正常工作功能或重要功能。或者危及人身安全。
2.Major：嚴重地影響系統要求或基本功能的實現，且沒有辦法更正。（重新安裝或重新啟動該軟件不屬于更正辦法）
3.Minor：嚴重地影響系統要求或基本功能的實現，但存在合理的更正辦法。（重新安裝或重新啟動該軟件不屬于更正辦法）
4.Cosmetic：使操作者不方便或遇到麻煩，但它不影響執行工作功能或重要功能。
5.Other：其它錯誤。
同行評審錯誤嚴重程度
1.Major：主要的，較大的缺陷
2.Minor：次要的，小的缺陷
缺陷優先級（Priority）
1.Resolve Immediately：缺陷必須被立即解決。
2.Normal Queue：缺陷需要正常排隊等待修複或列入軟件發布清單。
3.Not Urgent：缺陷可以在方便時被糾正。
缺陷狀态（Status）
1.Submitted:已提交的缺陷
2.Open:确認“提交的缺陷”，等待處理
3.Rejected:拒絕“提交的缺陷”，不需要修複或不是缺陷
4.Resolved:缺陷被修複
5.Closed:确認被修複的缺陷，将其關閉
缺陷起源（Origin）
1.Requirement：在需求階段發現的缺陷
2.Architecture：在構架階段發現的缺陷
3.Design：在設計階段發現的缺陷
4.Code：在編碼階段發現的缺陷
5.Test：在測試階段發現的缺陷
缺陷來源（Source）
1.Requirement：由于需求的問題引起的缺陷
2.Architecture：由于構架的問題引起的缺陷
3.Design：由于設計的問題引起的缺陷
4.Code：由于編碼的問題引起的缺陷
5.Test：由于測試的問題引起的缺陷
6.Integration：由于集成的問題引起的缺陷
級别
一旦發現軟件缺陷，就要設法找到引起這個缺陷的原因，分析對産品質量的影響，然後确定軟件缺陷的嚴重性和處理這個缺陷的優先級。各種缺陷所造成的後果是不一樣的，有的僅僅是不方便，有的可能是災難性的。一般問題越嚴重，其處理優先級就越高，可以概括為以下四種級别：
（1）微小的（Minor）。一些小問題如有個别錯别字、文字排版不整齊等，對功能幾乎沒有影響，軟件産品仍可使用。
（2）一般的（Major）。不太嚴重的錯誤，如次要功能模塊喪失、提示信息不夠準确、用戶界面差和操作時間長等。
（3）嚴重的（Critical）。嚴重錯誤，指功能模塊或特性沒有實現，主要功能部分喪失，次要功能全部喪失，或緻命的錯誤聲明。
（4）緻命的（Fatal）。緻命的錯誤，造成系統崩潰、死機，或造成數據丢失、主要功能完全喪失等。
除了嚴重性之外，還存在反映軟件缺陷處于一種什麼樣的狀态，以便于及時跟蹤和管理，下面是不同的缺陷狀态。
·激活狀态（Open）：問題沒有解決，測試人員新報告的缺陷或者驗證後缺陷仍舊存在。
·已修正狀态（Fixed）：開發人員針對缺陷，修正軟件後已解決問題或通過單元測試。
·關閉狀态（Close）：測試人員經過驗證後，确認缺陷不存在之後的狀态。
以上是三種基本的狀态，還有一些是需要相應的狀态描述，如“保留”，“不一緻”狀态等。
産生原因
在軟件開發的過程中，軟件缺陷的産生是不可避免的。那麼造成軟件缺陷的主要原因有哪些？從軟件本身、團隊工作和技術問題等角度分析，就可以了解造成軟件缺陷的主要因素。
軟件缺陷的産生主要是由軟件産品的特點和開發過程決定的。
軟件本身
1.需求不清晰，導緻設計目标偏離客戶的需求，從而引起功能或産品特征上的缺陷。
2.系統結構非常複雜，而又無法設計成一個很好的層次結構或組件結構，結果導緻意想不到的問題或系統維護、擴充上的困難；即使設計成良好的面向對象的系統，由于對象、類太多，很難完成對各種對象、類相互作用的組合測試，而隐藏着一些參數傳遞、方法調用、對象狀态變化等方面問題。
3.對程序邏輯路徑或數據範圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。
4.對一些實時應用，要進行精心設計和技術處理，保證精确的時間同步，否則容易引起時間上不協調，不一緻性帶來的問題。
5.沒有考慮系統崩潰後的自我恢複或數據的異地備份、災難性恢複等問題，從而存在系統安全性、可靠性的隐患。
6.系統運行環境的複雜，不僅用戶使用的計算機環境千變萬化，包括用戶的各種操作方式或各種不同的輸入數據，容易引起一些特定用戶環境下的問題；在系統實際應用中，數據量很大。從而會引起強度或負載問題。
7.由于通信端口多、存取和加密手段的矛盾性等，會造成系統的安全性或适用性等問題。
8.新技術的采用，可能涉及技術或系統兼容的問題，事先沒有考慮到。
團隊工作
1.系統需求分析時對客戶的需求理解不清楚，或者和用戶的溝通存在一些困難。
2.不同階段的開發人員相互理解不一緻。例如，軟件設計人員對需求分析的理解有偏差，編程人員對系統設計規格說明書某些内容重視不夠，或存在誤解。
3.對于設計或編程上的一些假定或依賴性，相關人員沒有充分溝通。
4.項目組成員技術水平參差不齊，新員工較多，或培訓不夠等原因也容易引起問題。
技術問題
1.算法錯誤：在給定條件下沒能給出正确或準确的結果。
2.語法錯誤：對于編譯性語言程序，編譯器可以發現這類問題；但對于解釋性語言程序，隻能在測試運行時發現。
3.計算和精度問題：計算的結果沒有滿足所需要的精度。
4.系統結構不合理、算法選擇不科學，造成系統性能低下。
5.接口參數傳遞不匹配，導緻模塊集成出現問題。
項目管理的問題
1.缺乏質量文化，不重視質量計劃，對質量、資源、任務、成本等的平衡性把握不好，容易擠掉需求分析、評審、測試、等時間，遺留的缺陷會比較多。
2.系統分析時對客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難。
3.開發周期短，需求分析、設計、編程、測試等各項工作不能完全按照定義好的流程來進行，工作不夠充分，結果也就不完整、不準确，錯誤較多；周期短，還給各類開發人員造成太大的壓力，引起一些人為的錯誤。
4.開發流程不夠完善，存在太多的随機性和缺乏嚴謹的内審或評審機制，容易産生問題。
5.文檔不完善，風險估計不足等。
修複代價
在讨論軟件測試原則時，一開始就強調測試人員要在軟件開發的早期，如需求分析階段就應介入，問題發現的越早越好。發現缺陷後，要盡快修複缺陷。其原因在于錯誤并不隻是在編程階段産生，需求和設計階段同樣會産生錯誤。也許一開始，隻是一個很小範圍内的錯誤，但随着産品開發工作的進行，小錯誤會擴散成大錯誤，為了修改後期的錯誤所做的工作要大得多，即越到後來往前返工也越遠。如果錯誤不能及早發現，那隻可能造成越來越嚴重的後果。缺陷發現或解決的越遲，成本就越高。
平均而言，如果在需求階段修正一個錯誤的代價是1，那麼，在設計階段就是它的3～6倍，在編程階段是它的10倍，在内部測試階段是它的20～40倍，在外部測試階段是它的30～70倍，而到了産品發布出去時，這個數字就是40～1000倍，修正錯誤的代價不是随時間線性增長，而幾乎是呈指數增長的。
軟件未達到産品說明書表明的功能。
軟件出現了産品說明書指名不會出現的錯誤。
軟件功能超出産品說明書指名範圍。
軟件未達到産品說明書雖未指出但應達到的目标。
軟件測試人員認為軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好。
一般都認為測出一個問題就是一個bug，其實這是不對的，假設測試10個問題就10個bug，而修改一出就全解決了，程序員肯定認為冤枉自己。
所有軟件是文檔，代碼等組成的，最初的錯誤是來自于這些軟件錯誤(software error)，如代碼中加法寫成減法。軟件錯誤導緻軟件缺陷(software defect)，如設計缺陷，代碼缺陷等，可用靜态測試，如走查，靜态檢查，測試床（軍事軟件用的技術）等，軟件的缺陷導緻一個或多個軟件故障 (software fault)，故障有内部故障，外部故障，也就是所說的bug，軟件故障導緻了軟件在功能操作等方面的失效(software failure)。
平時測的bug實際上是軟件故障于失效的體現。一旦軟件錯誤得到修改，相應的故障與失效也就解除了。這樣分有助于定位問題，找到問題。
詳見《軟件可靠性工程》
優先級
嚴重性和優先級是表征軟件測試缺陷的兩個重要因素，它影響軟件缺陷的統計結果和修正缺陷的優先順序，特别在軟件測試的後期，将影響軟件是否能夠按期發布與否。
對于軟件測試初學者而言，或者沒有軟件開發經驗的測試工程師，對于這兩個概念的理解，對于它們的作用和處理方式往往理解的不徹底，實際測試工作中不能正确表示缺陷的嚴重性和優先級。這将影響軟件缺陷報告的質量，不利于盡早處理嚴重的軟件缺陷，可能影響軟件缺陷的處理時機。
什麼是缺陷的嚴重性和優先級
嚴重性(Severity)顧名思義就是軟件缺陷對軟件質量的破壞程度，即此軟件缺陷的存在将對軟件的功能和性能産生怎樣的影響。
在軟件測試中，軟件缺陷的嚴重性的判斷應該從軟件最終用戶的觀點做出判斷，即判斷缺陷的嚴重性要為用戶考慮，考慮缺陷對用戶使用造成的惡劣後果的嚴重性。
優先級是表示處理和修正軟件缺陷的先後順序的指标，即哪些缺陷需要優先修正，哪些缺陷可以稍後修正。
确定軟件缺陷優先級，更多的是站在軟件開發工程師的角度考慮問題，因為缺陷的修正順序是個複雜的過程，有些不是純粹技術問題，而且開發人員更熟悉軟件代碼，能夠比測試工程師更清楚修正缺陷的難度和風險。
缺陷的嚴重性和優先級的關系
缺陷的嚴重性和優先級是含義不同但相互聯系密切的兩個概念。它們都從不同的側面描述了軟件缺陷對軟件質量和最終用戶的影響程度和處理方式。
一般地，嚴重性程度高的軟件缺陷具有較高的優先級。嚴重性高說明缺陷對軟件造成的質量危害性大，需要優先處理，而嚴重性低的缺陷可能隻是軟件不太盡善盡美，可以稍後處理。
但是，嚴重性和優先級并不總是一一對應。有時候嚴重性高的軟件缺陷，優先級不一定高，甚至不需要處理，而一些嚴重性低的缺陷卻需要及時處理，具有較高的優先級。
修正軟件缺陷不是一件純技術問題，有時需要綜合考慮市場發布和質量風險等問題。例如，如果某個嚴重的軟件缺陷隻在非常極端的條件下産生，則沒有必要馬上解決。另外，如果修正一個軟件缺陷，需要重新修改軟件的整體架構，可能會産生更多潛在的缺陷，而且軟件由于市場的壓力必須盡快發布，此時即使缺陷的嚴重性很高，是否需要修正，需要全盤考慮。
另一方面，如果軟件缺陷的嚴重性很低，例如，界面單詞拼寫錯誤，但是如果是軟件名稱或公司名稱的拼寫錯誤，則必須盡快修正，因為這關系到軟件和公司的市場形象。
處理缺陷的嚴重性和優先級的常見錯誤
正确處理缺陷的嚴重性和優先級不是件非常容易的事情，對于經驗不是很豐富的測試和開發人員而言，經常犯的錯誤有以下幾種情形：
第一，将比較輕微的缺陷報告成較高級别的缺陷和高優先級，誇大缺陷的嚴重程度，經常給人“狼來了”的錯覺，将影響軟件質量的正确評估，也耗費開發人員辨别和處理缺陷的時間。
第二，将很嚴重的缺陷報告成輕微缺陷和低優先級，這樣可能掩蓋了很多嚴重的缺陷。如果在項目發布前，發現還有很多由于不正确分配優先級造成的嚴重缺陷，将需要投入很多人力和時間進行修正，影響軟件的正常發布。或者這些嚴重的缺陷成了“漏網之魚”，随軟件一起發布出去，影響軟件的質量和用戶的使用信心。
因此，正确處理和區分缺陷的嚴重性和優先級，是軟件測試人員和開發人員，以及全體項目組人員的一件大事。處理嚴重性和優先級，既是一種經驗技術，也是保證軟件質量的重要環節，應該引起足夠的重視。
如何表示缺陷的嚴重性和優先級
缺陷的嚴重性和優先級通常按照級别劃分，各個公司和不同項目的具體表示方式有所不同。
為了盡量準确的表示缺陷信息，通常将缺陷的嚴重性和優先級分成4級。如果分級超過4級，則造成分類和判斷尺度的複雜程度，而少于4級，精确性有時不能保證。
具體的表示方法機可以使用數字表示，也可以使用文字表示，還可以數字和文字綜合表示。使用數字表示通常按照從高到底或從低到高的順序，需要軟件測試前達成一緻。例如，使用數字1，2，3，4分别表示輕微、一般、較嚴重和非常嚴重的嚴重性。對于優先級而言，1，2，3，4可以分标表示低優先級、一般、較高優先級和最高優先級。
如何确定缺陷的嚴重性和優先級
通常由軟件測試人員确定缺陷的嚴重性，由軟件開發人員确定優先級較為适當。但是，實際測試中，通常都是由軟件測試人員在缺陷報告中同時确定嚴重性和優先級。
确定缺陷的嚴重性和優先級要全面了解和深刻體會缺陷的特征，從用戶和開發人員以及市場的因素綜合考慮。通常功能性的缺陷較為嚴重，具有較高的優先級，而軟件界面類缺陷的嚴重性一般較低，優先級也較低。
其他注意事項
比較規範的軟件測試，使用軟件缺陷管理數據庫進行缺陷報告和處理，需要在測試項目開始前對全體測試人員和開發人員進行培訓，對缺陷嚴重性和優先級的表示和劃分方法統一規定和遵守。
在測試項目進行過程中和項目接收後，充分利用統計功能統計缺陷的嚴重性，确定軟件模塊的開發質量，評估軟件項目實施進度。統計優先級的分布情況，控制開發進度，使開發按照項目盡快進行，有效處理缺陷，降低風險和成本。
為了保證報告缺陷的嚴重性和優先級的一緻性，質量保證人員需要經常檢查測試和開發人員對于這兩個指标的分配和處理情況，發現問題，及時反饋給項目負責人，及時解決。
對于測試人員而言，通常經驗豐富的人員可以正确的表示缺陷的嚴重性和優先級，為缺陷的及時處理提供準确的信息。對于開發人員來說，開發經驗豐富的人員嚴重缺陷的錯誤較少，但是不要将缺陷的嚴重性作為衡量其開發水平高低的主要判斷指标，因為軟件的模塊的開發難度不同，各個模塊的質量要求也有所差異。
管理指南
收集缺陷
缺陷既指程序中存在的錯誤，例如語法錯誤、拼寫錯誤或者是一個正确的程序語句，缺陷也指可能出現在設計中，甚至在需求、規格說明或其他的文檔中的種種錯誤。為了對缺陷進行管理，首先應對缺陷進行分類，通過對缺陷進行分類，可以迅速找出哪一類缺陷的問題最大，然後集中精力預防和排除這一類缺陷。而這正是缺陷管理的關鍵，一旦這幾類缺陷得到控制，再進一步找到新的容易引起問題的幾類缺陷上。
了解缺陷
缺陷管理的第一步是了解缺陷，為此，必須首先收集缺陷數據，然後才能了解這些缺陷，并且找出如何預防它們，同時也能領會到如何更好地發現，修複甚至預防仍在引入的缺陷。可以按照以下步驟收集關于缺陷的數據：
1.為測試和同行評審中發現的每一個缺陷做一個記錄
2.對每個缺陷要記錄足夠詳細的信息，以便以後能更好地了解這個缺陷
3.分析這些數據以找出主要哪些缺陷類型引起大部分的問題
4.設計出發現和修複這些缺陷的方法（缺陷排除）
通常為了收集缺陷數據，可以采用缺陷記錄日志來登記所發現的每一個缺陷。
對于缺陷記錄日志中的描述應該足夠清楚，以便今後可以看出該缺陷的起因。修複缺陷一欄說明此缺陷是由于修複其他缺陷而引入的。引入階級表示該缺陷的來源。
步驟
為了有效地再現軟件缺陷，除了按照軟件缺陷的有效描述規則來描述軟件缺陷，還要遵循軟件缺陷分離和再現的方法，雖然有時少數幾個缺陷很難再現、或者根本無法再現.
1.确保所有的步驟都被記錄。記錄下所做的每一件事、每一個步驟、每一個停頓。無意間丢失一個步驟或者增加一個多餘步驟，可能導緻無法再現軟件缺陷。在嘗試運行測試用例時，可以利用錄制工具确切地記錄執行步驟。所有的目标是确保導緻軟件缺陷所需的全部細節是可見的。
2.特定條件和時間。軟件缺陷僅在特定時刻出現嗎？軟件缺陷在特定條件下産生嗎？産生軟件缺陷是網絡忙嗎？在較差和較好的硬件設備上運行測試用例會有不同的結果嗎？
3.壓力和負荷、内存和數據溢出相關的邊界條件。執行某個測試町能導緻産生缺陷的數據被複蓋，而隻有在試圖使用浚數據時才會再現。在重啟計算機後軟件缺陷消失，當執行其他測試之後又出現這類軟件缺陷，需要注意某些軟件缺陷可能是在無意中産生的。
4.考慮資源依賴性包括内存、嘲絡和硬件共享的相互作用等。軟件缺陷是否僅在運行其他軟件并與其他硬件通信的“繁忙”系統上出現？軟件缺陷可能最終證實跟硬件資源、網絡資源有相互的作用，審視這些影響有利于分離和再現軟件缺陷。
5.不能忽視硬件。與軟件不同，硬件Hi按預定方式工作。闆卡松動、内存條損壞或者cPU過熱都可能導緻像是軟件缺陷的失敗。設法在不同硬件蔔再現軟件缺陷。在執行配置或者兼容性測試時特别重要。判定軟件缺陷是在一個系統上還是在多個系統l産生。
開發人員有時可以根據相對簡單的錯誤信息就能找出問題所在。因為開發人員熟悉代碼，因此看到症狀、測試用例步驟和分離問題的過程時。可能得到查找軟件缺陷的線索。一個軟件缺陷的分離和再現有時需要小組的共同努力。如果軟件測試人員盡最大努力分離軟件缺陷，也無法表達準确的再現步驟，那麼仍然需要記錄和報告軟件缺陷。
