軟體缺陷

缺陷的表現形式不僅體現在功能的失效方面，還體現在其他方面。主要類型有：軟體沒有實現產品規格說明所要求的功能模塊；軟體中出現了產品規格說明指明不應該出現的錯誤；軟體實現了產品規格說明沒有提到的功能模塊；軟體沒有實現雖然產品規格說明沒有明確提及但應該實現的目標；軟體難以理解，不容易使用，運行緩慢，或從測試員的角度看，最終用戶會認為不好。

以計算器開發為例。計算器的產品規格說明

定應能準確無誤地進行加、減、乘、除運算。如果按下加法鍵，沒什麼反應，就是第一種類型的缺陷；若計算結果出錯，也是第一種類型的缺陷。

產品規格說明書還可能規定計算器不會死機，或者停止反應。如果隨意敲鍵盤導致計算器停止接受輸入，這就是第二種類型的缺陷。

如果使用計算器進行測試，發現除了加、減、乘、除之外還可以求平方根，但是產品規格說明沒有提及這一功能模塊。這是第三種類型的缺陷——軟體實現了產品規格說明書中未提及到的功能模塊。

在測試計算器時若發現電池沒電會導致計算不正確，而產品說明書是假定電池一直都有電的，從而發現第四種類型的錯誤。

軟體測試員如果發現某些地方不對，比如測試員覺得按鍵太小、“=”鍵布置的位置不好按、在亮光下看不清顯示屏等，無論什麼原因，都要認定為缺陷。而這正是第五種類型的缺陷。

根據以上五種缺陷類型，在軟體測試中可以區分不同類型的問題。

1.缺陷標識(Identifier)：缺陷標識是標記某個缺陷的一組符號。每個缺陷必須有一個唯一的標識。

2.缺陷類型(Type)：缺陷類型是根據缺陷的自然屬性劃分的缺陷種類。

3.缺陷嚴重程度(Severity)：缺陷嚴重程度是指因缺陷引起的故障對軟體產品的影響程度。

4.缺陷優先順序(Priority)：缺陷的優先順序指缺陷必須被修復的緊急程度。

5.缺陷狀態(Status)：缺陷狀態指缺陷通過一個跟蹤修復過程的進展情況。

6.缺陷起源(Origin)：缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段。

7.缺陷來源(Source)：缺陷來源指引起缺陷的起因。

8.缺陷根源(RootCause)：缺陷根源指發生錯誤的根本因素。

F-Function：影響了重要的特性、用戶界面、產品介面、硬體結構介面和全局數據結構。並且設計文檔需要正式的變更。如邏輯，指針，循環，遞歸，功能等缺陷。

A-Assignment：需要修改少量代碼，如初始化或控制塊。如聲明、重複命名，範圍、限定等缺陷。

I-Interface：與其他組件、模塊或設備驅動程序、調用參數、控制塊或參數列表相互影響的缺陷。

C-Checking：提示的錯誤信息，不適當的數據驗證等缺陷。

BBuild/package/merge：由於配置庫、變更管理或版本控制引起的錯誤。

D-Documentation：影響發布和維護，包括註釋。

G-Algorithm：演演算法錯誤。

U-UserInterface：人機交互特性：屏幕格式，確認用戶輸入，功能有效性，頁面排版等方面的缺陷。

P-Performance：不滿足系統可測量的屬性值，如：執行時間，事務處理速率等。

N-Norms：不符合各種標準的要求，如編碼標準、設計符號等。

軟體測試錯誤嚴重程度

1.Critical：不能執行正常工作功能或重要功能。或者危及人身安全。

2.Major：嚴重地影響系統要求或基本功能的實現，且沒有辦法更正。（重新安裝或重新啟動該軟體不屬於更正辦法）

3.Minor：嚴重地影響系統要求或基本功能的實現，但存在合理的更正辦法。（重新安裝或重新啟動該軟體不屬於更正辦法）

4.Cosmetic：使操作者不方便或遇到麻煩，但它不影響執行工作功能或重要功能。

5.Other：其它錯誤。

同行評審錯誤嚴重程度

1.Major：主要的，較大的缺陷

2.Minor：次要的，小的缺陷

1.ResolveImmediately：缺陷必須被立即解決。

2.NormalQueue：缺陷需要正常排隊等待修復或列入軟體發布清單。

3.NotUrgent：缺陷可以在方便時被糾正。

1.Submitted:已提交的缺陷

2.Open:確認“提交的缺陷”，等待處理

3.Rejected:拒絕“提交的缺陷”，不需要修復或不是缺陷

4.Resolved:缺陷被修復

5.Closed:確認被修復的缺陷，將其關閉

1.Requirement：在需求階段發現的缺陷

2.Architecture：在構架階段發現的缺陷

3.Design：在設計階段發現的缺陷

4.Code：在編碼階段發現的缺陷

5.Test：在測試階段發現的缺陷

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）規格說明書缺陷：規格說明書可能不完全，有二義性或自身矛盾。另外，在設計過程中可能修改功能，如果不能緊跟這種變化並及時修改規格說明書，則產生規格說明書錯誤。

（2）功能缺陷：程序實現的功能與用戶要求的不一致。

這常常是由於規格說明書包含錯誤的功能、多餘的功能或遺漏的功能所致。在發現和改正這些缺陷的過程中又可能引入新的缺陷。

（3）測試缺陷：軟體測試的設計與實施發生錯誤。特別是系統級的功能測試，要求複雜的測試環境和資料庫支持，還需要對測試進行腳本編寫。因此軟體測試自身也可能發生錯誤。另外，如果測試人員對系統缺乏了解，或對規格說明書做了錯誤的解釋，也會發生許多錯誤。

（4）測試標準引起的缺陷：對軟體測試的標準要選擇適當，若測試標準太複雜，則導致測試過程出錯的可能就大。

◆外部介面缺陷：外部介面是指如終端、印表機、通信線路等系統與外部環境通訊的手段。所有外部介面之間、人與機器之間的通訊都使用形式的或非形式的專門協議。如果協議有錯，或太複雜，難以理解，致使在使用中出錯。此外，還包括對輸入/輸出格式錯誤理解，對輸入數據不合理的容錯等。

◆內部介面缺陷：內部介面是指程序內部子系統或模塊之間的聯繫。它所發生的缺陷與外部介面相同，只是與程序內實現的細節有關，如設計協議錯、輸入/輸出格式錯、數據保護不可靠、子程序訪問錯等。

◆硬體結構缺陷：與硬體結構有關的軟體缺陷在於不能正確的理解硬體如何工作。如忽視或錯誤地理解分頁機構、地址生成、通道容量、I/O指令、中斷處理、設備初始化和啟動等而導致的出錯。

◆操作系統缺陷：與操作系統有關的軟體缺陷在於不了解操作系統的工作機制而導致出錯。當然，操作系統本身也有缺陷，但是一般用戶很難發現這種缺陷。

◆軟體結構缺陷：由於軟體結構不合理而產生的缺陷。這種缺陷通常與系統的負載有關，而且往往在系統滿載時才出現。如錯誤地設置局部參數或全局參數；錯誤地假定寄存器與存儲器單元初始化了；錯誤地假定被調用子程序常駐內存或非常駐內存等，都將導致軟體出錯。

◆控制與順序缺陷：如忽視了時間因素而破壞了事件的順序；等待一個不可能發生的條件；漏掉先決條件；規定錯誤的優先順序或程序狀態；漏掉處理步驟；存在不正確的處理步驟或多餘的處理步驟等。

◆資源管理缺陷：由於不正確地使用資源而產生的缺陷。如使用未經獲準的資源；使用后未釋放資源；資源死鎖；把資源鏈接到錯誤的隊列中等。

◇演演算法與操作缺陷：是指在算術運算、函數求值和一般操作過程中發生的缺陷。如數據類型轉換錯；除法溢出；不正確地使用關係運算符；不正確地使用整數與浮點數做比較等。

◇初始化缺陷：如忘記初始化工作區，忘記初始化寄存器和數據區；錯誤地對循環控制變數賦初值；用不正確的格式、數據或類類型進行初始化等。

◇控制和次序缺陷：與系統級同名缺陷相比，它是局部缺陷。如遺漏路徑；不可達到的代碼；不符合語法的循環嵌套；循環返回和終止的條件不正確；漏掉處理步驟或處理步驟有錯等。

◇靜態邏輯缺陷：如不正確地使用switch語句；在表達式中使用不正確的否定（例如用“>”代替“<”的否定）；對情況不適當地分解與組合；混淆“或”與“異或”等。

△動態數據缺陷：動態數據是在程序執行過程中暫時存在的數據，它的生存期非常短。各種不同類型的動態數據在執行期間將共享一個共同的存儲區域，若程序啟動時對這個區域未初始化，救護導致數據出錯。

△靜態數據缺陷：靜態數據在內容和格式上都是固定的。它們直接或間接的出現在程序或資料庫中，有編譯程序或其他專門對他們做預處理，但預處理也會出錯。

△數據內容、結構和屬性缺陷：數據內容是指存儲於存儲單元或數據結構中的位串、字元串或數字。數據內容缺陷就是由於內容被破壞或被錯誤地解釋而造成的缺陷。數據結構是指數據元素的大小和組織形式。在同一存儲區域中可以定義不同的數據結構。數據結構缺陷包括結構說明錯誤及數據結構誤用的錯誤。數據屬性是指數據內容的含義或語義。數據屬性缺陷包括對數據屬性不正確地解釋，如錯把整數當實數，允許不同類型數據混合運算而導致的錯誤等。

包括數據說明錯、數據使用錯、計算錯、比較錯、控制流錯、界面錯、輸入\輸出錯，及其他的錯誤。

規格說明書是軟體缺陷出現最多的地方，其原因是：

◆用戶一般是非軟體開發專業人員，軟體開發人員和用戶的溝通存在較大困難，對要開發的產品功能理解不一致。

◆由於在開發初期，軟體產品還沒有設計和編程，完全靠想象去描述系統的實現結果，所以有些需求特性不夠完整、清晰。

◆用戶的需求總是不斷變化，這些變化如果沒有在產品規格說明書中得到正確的描述，容易引起前後文、上下文的矛盾。

◆對規格說明書不夠重視，在規格說明書的設計和寫作上投入的人力、時間不足。

◆沒有在整個開發隊伍中進行充分溝通，有時只有設計師或項目經理得到比較多的信息。

排在產品規格說明書之後的是設計，編程排在第三位。許多人印象中，軟體測試主要是找程序代碼中的錯誤，這是一個認識的誤區。

在討論軟體測試原則時，一開始就強調測試人員要在軟體開發的早期，如需求分析階段就應介入，問題發現的越早越好。發現缺陷后，要儘快修復缺陷。其原因在於錯誤並不只是在編程階段產生，需求和設計階段同樣會產生錯誤。也許一開始，只是一個很小範圍內的錯誤，但隨著產品開發工作的進行，小錯誤會擴散成大錯誤，為了修改後期的錯誤所做的工作要大得多，即越到後來往前返工也越遠。如果錯誤不能及早發現，那隻可能造成越來越嚴重的後果。缺陷發現或解決的越遲，成本就越高。

平均而言，如果在需求階段修正一個錯誤的代價是1，那麼，在設計階段就是它的3～6倍，在編程階段是它的10倍，在內部測試階段是它的20～40倍，在外部測試階段是它的30～70倍，而到了產品發布出去時，這個數字就是40～1000倍，修正錯誤的代價不是隨時間線性增長，而幾乎是呈指數增長的。

軟體未達到產品說明書表明的功能。

軟體出現了產品說明書指名不會出現的錯誤。

軟體功能超出產品說明書指名範圍。

軟體未達到產品說明書雖未指出但應達到的目標。

軟體測試人員認為軟體難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好。

一般我們都認為測出一個問題就是一個bug，其實這是不對的，假設測試10個問題就10個bug，而修改一出就全解決了，程序員肯定認為冤枉自己。

所有軟體是文檔，代碼等組成的，最初的錯誤是來自於這些軟體錯誤(softwareerror)，如代碼中加法寫成減法。軟體錯誤導致軟體缺陷(softwaredefect)，如設計缺陷，代碼缺陷等，可用靜態測試，如走查，靜態檢查，測試床（軍事軟體用的技術）等，軟體的缺陷導致一個或多個軟體故障(softwarefault)，故障有內部故障，外部故障，也就是我們所說的bug，軟體故障導致了軟體在功能操作等方面的失效(softwarefailure)。

我們平時測的bug實際上是軟體故障於失效的體現。一旦軟體錯誤得到修改，相應的故障與失效也就解除了。這樣分有助於我們定位問題，找到問題。

詳見《軟體可靠性工程》

嚴重性和優先順序是表徵軟體測試缺陷的兩個重要因素，它影響軟體缺陷的統計結果和修正缺陷的優先順序，特別在軟體測試的後期，將影響軟體是否能夠按期發布與否。

對於軟體測試初學者而言，或者沒有軟體開發經驗的測試工程師，對於這兩個概念的理解，對於它們的作用和處理方式往往理解的不徹底，實際測試工作中不能正確表示缺陷的嚴重性和優先順序。這將影響軟體缺陷報告的質量，不利於儘早處理嚴重的軟體缺陷，可能影響軟體缺陷的處理時機。

什麼是缺陷的嚴重性和優先順序

嚴重性(Severity)顧名思義就是軟體缺陷對軟體質量的破壞程度，即此軟體缺陷的存在將對軟體的功能和性能產生怎樣的影響。

在軟體測試中，軟體缺陷的嚴重性的判斷應該從軟體最終用戶的觀點做出判斷，即判斷缺陷的嚴重性要為用戶考慮，考慮缺陷對用戶使用造成的惡劣後果的嚴重性。

優先順序是表示處理和修正軟體缺陷的先後順序的指標，即哪些缺陷需要優先修正，哪些缺陷可以稍後修正。

確定軟體缺陷優先順序，更多的是站在軟體開發工程師的角度考慮問題，因為缺陷的修正順序是個複雜的過程，有些不是純粹技術問題，而且開發人員更熟悉軟體代碼，能夠比測試工程師更清楚修正缺陷的難度和風險。

缺陷的嚴重性和優先順序的關係

缺陷的嚴重性和優先順序是含義不同但相互聯繫密切的兩個概念。它們都從不同的側面描述了軟體缺陷對軟體質量和最終用戶的影響程度和處理方式。

一般地，嚴重性程度高的軟體缺陷具有較高的優先順序。嚴重性高說明缺陷對軟體造成的質量危害性大，需要優先處理，而嚴重性低的缺陷可能只是軟體不太盡善盡美，可以稍後處理。

但是，嚴重性和優先順序並不總是一一對應。有時候嚴重性高的軟體缺陷，優先順序不一定高，甚至不需要處理，而一些嚴重性低的缺陷卻需要及時處理，具有較高的優先順序。

修正軟體缺陷不是一件純技術問題，有時需要綜合考慮市場發布和質量風險等問題。例如，如果某個嚴重的軟體缺陷只在非常極端的條件下產生，則沒有必要馬上解決。另外，如果修正一個軟體缺陷，需要重新修改軟體的整體架構，可能會產生更多潛在的缺陷，而且軟體由於市場的壓力必須儘快發布，此時即使缺陷的嚴重性很高，是否需要修正，需要全盤考慮。

另一方面，如果軟體缺陷的嚴重性很低，例如，界面單詞拼寫錯誤，但是如果是軟體名稱或公司名稱的拼寫錯誤，則必須儘快修正，因為這關係到軟體和公司的市場形象。

處理缺陷的嚴重性和優先順序的常見錯誤

正確處理缺陷的嚴重性和優先順序不是件非常容易的事情，對於經驗不是很豐富的測試和開發人員而言，經常犯的錯誤有以下幾種情形：

第一，將比較輕微的缺陷報告成較高級別的缺陷和高優先順序，誇大缺陷的嚴重程度，經常給人“狼來了”的錯覺，將影響軟體質量的正確評估，也耗費開發人員辨別和處理缺陷的時間。

第二，將很嚴重的缺陷報告成輕微缺陷和低優先順序，這樣可能掩蓋了很多嚴重的缺陷。如果在項目發布前，發現還有很多由於不正確分配優先順序造成的嚴重缺陷，將需要投入很多人力和時間進行修正，影響軟體的正常發布。或者這些嚴重的缺陷成了“漏網之魚”，隨軟體一起發布出去，影響軟體的質量和用戶的使用信心。

因此，正確處理和區分缺陷的嚴重性和優先順序，是軟體測試人員和開發人員，以及全體項目組人員的一件大事。處理嚴重性和優先順序，既是一種經驗技術，也是保證軟體質量的重要環節，應該引起足夠的重視。

如何表示缺陷的嚴重性和優先順序

缺陷的嚴重性和優先順序通常按照級別劃分，各個公司和不同項目的具體表示方式有所不同。

為了盡量準確的表示缺陷信息，通常將缺陷的嚴重性和優先順序分成4級。如果分級超過4級，則造成分類和判斷尺度的複雜程度，而少於4級，精確性有時不能保證。

具體的表示方法機可以使用數字錶示，也可以使用文字表示，還可以數字和文字綜合表示。使用數字錶示通常按照從高到底或從低到高的順序，需要軟體測試前達成一致。例如，使用數字1，2，3，4分別表示輕微、一般、較嚴重和非常嚴重的嚴重性。對於優先順序而言，1，2，3，4可以分標表示低優先順序、一般、較高優先順序和最高優先順序。

如何確定缺陷的嚴重性和優先順序

通常由軟體測試人員確定缺陷的嚴重性，由軟體開發人員確定優先順序較為適當。但是，實際測試中，通常都是由軟體測試人員在缺陷報告中同時確定嚴重性和優先順序。

確定缺陷的嚴重性和優先順序要全面了解和深刻體會缺陷的特徵，從用戶和開發人員以及市場的因素綜合考慮。通常功能性的缺陷較為嚴重，具有較高的優先順序，而軟體界面類缺陷的嚴重性一般較低，優先順序也較低。

對於缺陷的嚴重性，如果分為4級，則可以參考下面的方法確定：

1–非常嚴重的缺陷，例如，軟體的意外退出甚至操作系統崩潰，造成數據丟失。2–較嚴重的缺陷，例如，軟體的某個菜單不起作用或者產生錯誤的結果；3-軟體一般缺陷，例如，本地化軟體的某些字元沒有翻譯或者翻譯不準確；4-軟體界面的細微缺陷，例如，某個控制項沒有對齊，某個標點符號丟失等；

對於缺陷的優先性，如果分為4級，則可以參考下面的方法確定：

1–最高優先順序，例如，軟體的主要功能錯誤或者造成軟體崩潰，數據丟失的缺陷。2–較高優先順序，例如，影響軟體功能和性能的一般缺陷；3-一般優先順序，例如，本地化軟體的某些字元沒有翻譯或者翻譯不準確的缺陷；4–低優先順序，例如，對軟體的質量影響非常輕微或出現幾率很低的缺陷；

其他注意事項

比較規範的軟體測試，使用軟體缺陷管理資料庫進行缺陷報告和處理，需要在測試項目開始前對全體測試人員和開發人員進行培訓，對缺陷嚴重性和優先順序的表示和劃分方法統一規定和遵守。

在測試項目進行過程中和項目接收后，充分利用統計功能統計缺陷的嚴重性，確定軟體模塊的開發質量，評估軟體項目實施進度。統計優先順序的分佈情況，控制開發進度，使開發按照項目儘快進行，有效處理缺陷，降低風險和成本。

為了保證報告缺陷的嚴重性和優先順序的一致性，質量保證人員需要經常檢查測試和開發人員對於這兩個指標的分配和處理情況，發現問題，及時反饋給項目負責人，及時解決。

對於測試人員而言，通常經驗豐富的人員可以正確的表示缺陷的嚴重性和優先順序，為缺陷的及時處理提供準確的信息。對於開發人員來說，開發經驗豐富的人員嚴重缺陷的錯誤較少，但是不要將缺陷的嚴重性作為衡量其開發水平高低的主要判斷指標，因為軟體的模塊的開發難度不同，各個模塊的質量要求也有所差異。

缺陷既指程序中存在的錯誤，例如語法錯誤、拼寫錯誤或者是一個正確的程序語句，缺陷也指可能出現在設計中，甚至在需求、規格說明或其他的文檔中的種種錯誤。為了對缺陷進行管理，首先應對缺陷進行分類，通過對缺陷進行分類，可以迅速找出哪一類缺陷的問題最大，然後集中精力預防和排除這一類缺陷。而這正是缺陷管理的關鍵，一旦這幾類缺陷得到控制，再進一步找到新的容易引起問題的幾類缺陷上。

缺陷管理的第一步是了解缺陷，為此，必須首先收集缺陷數據，然後才能了解這些缺陷，並且找出如何預防它們，同時也能領會到如何更好地發現，修復甚至預防仍在引入的缺陷。可以按照以下步驟收集關於缺陷的數據：

1.為測試和同行評審中發現的每一個缺陷做一個記錄

2.對每個缺陷要記錄足夠詳細的信息，以便以後能更好地了解這個缺陷

3.分析這些數據以找出主要哪些缺陷類型引起大部分的問題

4.設計出發現和修復這些缺陷的方法（缺陷排除）

通常為了收集缺陷數據，可以採用缺陷記錄日誌來登記所發現的每一個缺陷。

對於缺陷記錄日誌中的描述應該足夠清楚，以便今後可以看出該缺陷的起因。修復缺陷一欄說明此缺陷是由於修復其他缺陷而引入的。引入階級表示該缺陷的來源。

為了有效地再現軟體缺陷，除了按照軟體缺陷的有效描述規則來描述軟體缺陷，還要遵循軟體缺陷分離和再現的方法，雖然有時少數幾個缺陷很難再現、或者根本無法再現.

1.確保所有的步驟都被記錄。記錄下所做的每一件事、每一個步驟、每一個停頓。無意間丟失一個步驟或者增加一個多餘步驟，可能導致無法再現軟體缺陷。在嘗試運行測試用例時，可以利用錄製工具確切地記錄執行步驟。所有的目標是確保導致軟體缺陷所需的全部細節是可見的。

2.特定條件和時間。軟體缺陷僅在特定時刻出現嗎？軟體缺陷在特定條件下產生嗎？產生軟體缺陷是網路忙嗎？在較差和較好的硬體設備上運行測試用例會有不同的結果嗎？

3.壓力和負荷、內存和數據溢出相關的邊界條件。執行某個測試町能導致產生缺陷的數據被復蓋，而只有在試圖使用浚數據時才會再現。在重啟計算機后軟體缺陷消失，當執行其他測試之後又出現這類軟體缺陷，需要注意某些軟體缺陷可能是在無意中產生的。

4.考慮資源依賴性包括內存、嘲絡和硬體共享的相互作用等。軟體缺陷是否僅在運行其他軟體並與其他硬體通信的“繁忙”系統上出現？軟體缺陷可能最終證實跟硬體資源、網路資源有相互的作用，審視這些影響有利於分離和再現軟體缺陷。

5.不能忽視硬體。與軟體不同，硬體Hi按預定方式工作。板卡鬆動、內存條損壞或者cPU過熱都可能導致像是軟體缺陷的失敗。設法在不同硬體卜再現軟體缺陷。在執行配置或者兼容性測試時特別重要。判定軟體缺陷是在一個系統上還是在多個系統l產生。

開發人員有時可以根據相對簡單的錯誤信息就能找出問題所在。因為開發人員熟悉代碼，因此看到癥狀、測試用例步驟和分離問題的過程時。可能得到查找軟體缺陷的線索。一個軟體缺陷的分離和再現有時需要小組的共同努力。如果軟體測試人員盡最大努力分離軟體缺陷，也無法表達準確的再現步驟，那麼仍然需要記錄和報告軟體缺陷。