軟體缺陷的概念

軟體缺陷（Defect），常常又被叫做Bug。所謂軟體缺陷，即為計算機軟體或程式中存在的某種破壞正常運作能力的問題、錯誤，或者隐藏的功能缺陷。缺陷的存在會導緻軟體産品在某種程度上不能滿足使用者的需要。IEEE729-1983對缺陷有一個标準的定義：從産品内部看，缺陷是軟體産品開發或維護過程中存在的錯誤、毛病等各種問題；從産品外部看，缺陷是系統所需要實作的某種功能的失效或違背。

軟體缺陷的類别

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

　　以電腦開發為例。電腦的産品規格說明

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

　　産品規格說明書還可能規定電腦不會當機，或者停止反應。如果随意敲鍵盤導緻電腦停止接受輸入，這就是第二種類型的缺陷。

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

　　在測試電腦時若發現電池沒電會導緻計算不正确，而産品說明書是假定電池一直都有電的，進而發現第四種類型的錯誤。

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

軟體缺陷(software defect)分類标準

缺陷屬性

　　屬性名稱 描述 缺陷辨別(Identifier) 缺陷辨別是标記某個缺陷的一組符号。每個缺陷必須有一個唯一的辨別 缺陷類型 (Type) 缺陷類型是根據缺陷的自然屬性劃分的缺陷種類。 缺陷嚴重程度 (Severity) 缺陷嚴重程度是指因缺陷引起的故障對軟體産品的影響程度。 缺陷優先級(Priority) 缺陷的優先級指缺陷必須被修複的緊急程度。 缺陷狀态(Status) 缺陷狀态指缺陷通過一個跟蹤修複過程的進展情況。 缺陷起源(Origin) 缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段。 缺陷來源(Source) 缺陷來源指引起缺陷的起因。 缺陷根源(Root Cause) 缺陷根源指發生錯誤的根本因素。

缺陷類型（Type）

　　缺陷類型編号 缺陷類型 描述 10 F- Function 影響了重要的特性、使用者界面、産品接口、硬體結構接口和全局資料結構。并且設計文檔需要正式的變更。如邏輯，指針，循環，遞歸，功能等缺陷。 20 A- Assignment 需要修改少量代碼，如初始化或控制塊。如聲明、重複命名，範圍、限定等缺陷。 30 I- Interface 與其他元件、子產品或裝置驅動程式、調用參數、控制塊或參數清單互相影響的缺陷。 40 C- Checking 提示的錯誤資訊，不适當的資料驗證等缺陷。 50 B Build/package/merge 由于配置庫、變更管理或版本控制引起的錯誤。 60 D- Documentation 影響釋出和維護，包括注釋。 70 G- Algorithm 算法錯誤。 80 U-User Interface 人機互動特性：螢幕格式，确認使用者輸入，功能有效性，頁面排版等方面的缺陷。 90 P-Performance 不滿足系統可測量的屬性值，如：執行時間，事務處理速率等。 100 N-Norms 不符合各種标準的要求，如編碼标準、設計符号等。

缺陷嚴重程度（Severity）

　　1.3.1 軟體測試錯誤嚴重程度

　　# 缺陷嚴重等級 描述 1 Critical 不能執行正常工作功能或重要功能。或者危及人身安全。 2 Major 嚴重地影響系統要求或基本功能的實作，且沒有辦法更正。（重新安裝或重新啟動該軟體不屬于更正辦法） 3 Minor 嚴重地影響系統要求或基本功能的實作，但存在合理的更正辦法。（重新安裝或重新啟動該軟體不屬于更正辦法） 4 Cosmetic 使操作者不友善或遇到麻煩，但它不影響執行工作功能或重要功能。 5 Other 其它錯誤。

　　1.3.2 同行評審錯誤嚴重程度

　　# 缺陷嚴重等級 描述 Major 主要的，較大的缺陷 Minor 次要的，小的缺陷

缺陷優先級（Priority）

　　# 缺陷優先級 描述 1 Resolve Immediately 缺陷必須被立即解決。 2 Normal Queue 缺陷需要正常排隊等待修複或列入軟體釋出清單。 3 Not Urgent 缺陷可以在友善時被糾正。

缺陷狀态（Status）

　　缺陷狀态 描述 Submitted 已送出的缺陷 Open 确認“送出的缺陷”，等待處理 Rejected 拒絕“送出的缺陷”，不需要修複或不是缺陷 Resolved 缺陷被修複 Closed 确認被修複的缺陷，将其關閉

缺陷起源（Origin）

　　缺陷起源 描述 Requirement 在需求階段發現的缺陷 Architecture 在構架階段發現的缺陷 Design 在設計階段發現的缺陷 Code 在編碼階段發現的缺陷 Test 在測試階段發現的缺陷

缺陷來源（Source）

　　缺陷來源 描述 Requirement 由于需求的問題引起的缺陷 Architecture 由于構架的問題引起的缺陷 Design 由于設計的問題引起的缺陷 Code 由于編碼的問題引起的缺陷 Test 由于測試的問題引起的缺陷 Integration 由于內建的問題引起的缺陷

軟體缺陷的級别

　　一旦發現軟體缺陷，就要設法找到引起這個缺陷的原因，分析對産品品質的影響，然後确定軟體缺陷的嚴重性和處理這個缺陷的優先級。各種缺陷所造成的後果是不一樣的，有的僅僅是不友善，有的可能是災難性的。一般問題越嚴重，其處理優先級就越高，可以概括為以下四種級别：

　　（1）微小的（Minor）。一些小問題如有個别錯别字、文字排版不整齊等，對功能幾乎沒有影響，軟體産品仍可使用。

　　（2）一般的（Major）。不太嚴重的錯誤，如次要功能子產品喪失、提示資訊不夠準确、使用者界面差和操作時間長等。

　　（3）嚴重的（Critical）。嚴重錯誤，指功能子產品或特性沒有實作，主要功能部分喪失，次要功能全部喪失，或緻命的錯誤聲明。

　　（4）緻命的（Fatal）。緻命的錯誤，造成系統崩潰、當機，或造成資料丢失、主要功能完全喪失等。

　　除了嚴重性之外，還存在反映軟體缺陷處于一種什麼樣的狀态，以便于及時跟蹤和管理，下面是不同的缺陷狀态。

　　·激活狀态（Open）：問題沒有解決，測試人員新報告的缺陷或者驗證後缺陷仍舊存在。

　　·已修正狀态（Fixed）：開發人員針對缺陷，修正軟體後已解決問題或通過單元測試。

　　·關閉狀态（Close）：測試人員經過驗證後，确認缺陷不存在之後的狀态。

　　以上是三種基本的狀态，還有一些是需要相應的狀态描述，如“保留”，“不一緻”狀态等。

軟體缺陷産生的原因

　　在軟體開發的過程中，軟體缺陷的産生是不可避免的。那麼造成軟體缺陷的主要原因有哪些？從軟體本身、團隊工作和技術問題等角度分析，就可以了解造成軟體缺陷的主要因素。

　　軟體缺陷的産生主要是由軟體産品的特點和開發過程決定的。

軟體本身

　　①需求不清晰，導緻設計目标偏離客戶的需求，進而引起功能或産品特征上的缺陷。

　　②系統結構非常複雜，而又無法設計成一個很好的層次結構或元件結構，結果導緻意想不到的問題或系統維護、擴充上的困難；即使設計成良好的面向對象的系統，由于對象、類太多，很難完成對各種對象、類互相作用的組合測試，而隐藏着一些參數傳遞、方法調用、對象狀态變化等方面問題。

　　③對程式邏輯路徑或資料範圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。

　　④對一些實時應用，要進行精心設計和技術處理，保證精确的時間同步，否則容易引起時間上不協調，不一緻性帶來的問題。

　　⑤沒有考慮系統崩潰後的自我恢複或資料的異地備份、災難性恢複等問題，進而存在系統安全性、可靠性的隐患。

　　⑥系統運作環境的複雜，不僅使用者使用的計算機環境千變萬化，包括使用者的各種操作方式或各種不同的輸入資料，容易引起一些特定使用者環境下的問題；在系統實際應用中，資料量很大。進而會引起強度或負載問題。

　　⑦由于通信端口多、存取和加密手段的沖突性等，會造成系統的安全性或适用性等問題。

　　⑧新技術的采用，可能涉及技術或系統相容的問題，事先沒有考慮到。

團隊工作

　　☆系統需求分析時對客戶的需求了解不清楚，或者和使用者的溝通存在一些困難。

　　☆不同階段的開發人員互相了解不一緻。例如，軟體設計人員對需求分析的了解有偏差，程式設計人員對系統設計規格說明書某些内容重視不夠，或存在誤解。

　　☆對于設計或程式設計上的一些假定或依賴性，相關人員沒有充分溝通。

　　☆項目組成員技術水準參差不齊，新員工較多，或教育訓練不夠等原因也容易引起問題。

技術問題

　　○算法錯誤：在給定條件下沒能給出正确或準确的結果。

　　○文法錯誤：對于編譯性語言程式，編譯器可以發現這類問題；但對于解釋性語言程式，隻能在測試運作時發現。

　　○計算和精度問題：計算的結果沒有滿足所需要的精度。

　　○系統結構不合理、算法選擇不科學，造成系統性能低下。

　　○接口參數傳遞不比對，導緻子產品內建出現問題。

項目管理的問題

　　· 缺乏品質文化，不重視品質計劃，對品質、資源、任務、成本等的平衡性把握不好，容易擠掉需求分析、評審、測試、等時間，遺留的缺陷會比較多。

　　· 系統分析時對客戶的需求不是十厘清楚，或者和使用者的溝通存在一些困難。

　　· 開發周期短，需求分析、設計、程式設計、測試等各項工作不能完全按照定義好的流程來進行，工作不夠充分，結果也就不完整、不準确，錯誤較多；周期短，還給各類開發人員造成太大的壓力，引起一些人為的錯誤。

　　· 開發流程不夠完善，存在太多的随機性和缺乏嚴謹的内審或評審機制，容易産生問題。

　　· 文檔不完善，風險估計不足等。

軟體缺陷的構成

　　從軟體測試觀點出發，軟體缺陷有以下五大類：

功能缺陷

　　（1）規格說明書缺陷：規格說明書可能不完全，有二義性或自身沖突。另外，在設計過程中可能修改功能，如果不能緊跟這種變化并及時修改規格說明書，則産生規格說明書錯誤。

　　

功 規格說明書 404

能 功能 147

缺 測試 7

陷 總計 558 27%

　（2）功能缺陷：程式實作的功能與使用者要求的不一緻。

軟體缺陷

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

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

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

系統缺陷

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

　　

内部接口    29               

系 硬體 63

統 作業系統 2

缺 軟體結構 193

陷 控制與順序 43

資源    8    
總計    338    16%           

　◆内部接口缺陷：内部接口是指程式内部子系統或子產品之間的聯系。它所發生的缺陷與外部接口相同，隻是與程式内實作的細節有關，如設計協定錯、輸入/輸出格式錯、資料保護不可靠、子程式通路錯等。

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

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

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

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

　　◆資源管理缺陷：由于不正确地使用資源而産生的缺陷。如使用未經獲準的資源；使用後未釋放資源；資源死鎖；把資源連結到錯誤的隊列中等。

加工缺陷

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

算術    114               

加 初始化 15

工 控制與次序 271

缺 靜态邏輯 13

陷 其他 120

總計    533    26%           

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

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

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

資料缺陷

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

類型    36               

數 結構 34

據 初始值 51

錯 其他 120

誤 總計 241 12%

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

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

代碼缺陷

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

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

程式編寫錯誤 78 4%

文檔和其他錯誤 322 16%

　◆使用者一般是非軟體開發專業人員，軟體開發人員和使用者的溝通存在較大困難，對要開發的産品功能了解不一緻。

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

　　◆使用者的需求總是不斷變化，這些變化如果沒有在産品規格說明書中得到正确的描述，容易引起前後文、上下文的沖突。

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

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

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

修複軟體缺陷的代價

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

　　平均而言，如果在需求階段修正一個錯誤的代價是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可以分标表示低優先級、一般、較高優先級和最高優先級。

如何确定缺陷的嚴重性和優先級

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

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

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

　　1 – 非常嚴重的缺陷，例如，軟體的意外退出甚至作業系統崩潰，造成資料丢失。 2 – 較嚴重的缺陷，例如，軟體的某個菜單不起作用或者産生錯誤的結果； 3 - 軟體一般缺陷，例如，本地化軟體的某些字元沒有翻譯或者翻譯不準确； 4 - 軟體界面的細微缺陷，例如，某個控件沒有對齊，某個标點符号丢失等；

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

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

其他注意事項

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

　　在測試項目進行過程中和項目接收後，充分利用統計功能統計缺陷的嚴重性，确定軟體子產品的開發品質，評估軟體項目實施進度。統計優先級的分布情況，控制開發進度，使開發按照項目盡快進行，有效處理缺陷，降低風險和成本。

　　為了保證報告缺陷的嚴重性和優先級的一緻性，品質保證人員需要經常檢查測試和開發人員對于這兩個名額的配置設定和處理情況，發現問題，及時回報給項目負責人，及時解決。

　　對于測試人員而言，通常經驗豐富的人員可以正确的表示缺陷的嚴重性和優先級，為缺陷的及時處理提供準确的資訊。對于開發人員來說，開發經驗豐富的人員嚴重缺陷的錯誤較少，但是不要将缺陷的嚴重性作為衡量其開發水準高低的主要判斷名額，因為軟體的子產品的開發難度不同，各個子產品的品質要求也有所差異。

軟體缺陷(software defect)管理指南

1、如何收集缺陷

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

　　1．1 缺陷類型

　　缺陷類 型編号 缺陷類型 描述 10 F-功能 如邏輯,指針,循環,遞歸,功能等缺陷 20 G-文法 拼寫、标點符号、打字 30 A-指派 如聲明、重複命名，作用域 40 I-接口 與其他元件、子產品或裝置驅動程式、調用參數、控制塊或參數清單互相影響的缺陷 50 B-聯編打包 由于配置庫、變更管理或版本控制引起的錯誤 60 D-文檔 需求、設計類文檔 70 U-使用者接口 人機互動特性：螢幕格式，确認使用者輸入，功能有效性 80 P-性能 不滿足系統可測量的屬性值，如：執行時間，事務處理速率等 90 N-标準 不符合各種标準的要求，如編碼标準、設計符号等 100 E-環境 設計、編譯、其他支援系統問題

　　1．2 了解缺陷

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

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

　　◆ 對每個缺陷要記錄足夠詳細的資訊，以便以後能更好地了解這個缺陷

　　◆ 分析這些資料以找出主要哪些缺陷類型引起大部分的問題

　　◆ 設計出發現和修複這些缺陷的方法（缺陷排除）

　　通常為了收集缺陷資料，可以采用缺陷記錄日志來登記所發現的每一個缺陷

　　日期 編号 狀态 類型 缺陷來源 排除階段 修改時間 修複缺陷 描述： 描述： 描述：

　　對于缺陷記錄日志中的描述應該足夠清楚，以便今後可以看出該缺陷的起因。修複缺陷一欄說明此缺陷是由于修複其他缺陷而引入的。引入階級表示該缺陷的來源，缺陷的來源可以分為以下幾類：

　　排除階級表示發現和修複這個缺陷的階級，通常分為如下：

　　排除階段 描述 Requirement 在需求階段發現的缺陷 Architecture 在構架階段發現的缺陷 Design 在設計階段發現的缺陷 Code 在編碼階段發現的缺陷 Test 在測試階段bsp;

2、如何分析和統計缺陷

　　為了更好地分析缺陷，需要對缺陷在嚴重程度、優先級以及狀态上加以區分。

　　2．1 缺陷嚴重程度

　　# 缺陷嚴重等級 描述 1 嚴重缺陷（Critical） 不能執行正常工作功能或重要功能。或者危及人身安全 2 較大缺陷（Major） 嚴重地影響系統要求或基本功能的實作，且沒有辦法更正。 （重新安裝或重新啟動該軟體不屬于更正辦法） 3 較小缺陷（Minor） 嚴重地影響系統要求或基本功能的實作，但存在合理的更正辦法。（重新安裝或重新啟動該軟體不屬于更正辦法） 4 輕微缺陷（Cosmetic） 使操作者不友善或遇到麻煩，但它不影響執行工作功能或重要功能。 5 其他缺陷（Other） 其它錯誤

　　2．2 解決優先級（Priority）

　　# 解決優先級 描述 1 立即解決 （Resolve Immediately） 缺陷必須被立即解決。 2 正常排隊 （Normal Queue） 缺陷需要正常排隊等待修複或列入軟體釋出清單。 3 不緊急 （Not Urgent） 缺陷可以在友善時被糾正。

　　, 讓這些創意得到展現。現在我們都有Bug管理系統，這時我們的測試人員将需求Bug不是送出給程式員，而是送出給需求分析人員，由他們進行處理，不過這裡我想強調的是對需求Bug的定位，如果這個Bug在軟體需求說明書中明确提到了，這時就不可能定位它為需求Bug，它是必需讓程式, , , , 員實作的，稱為軟體功能缺陷，送出由程式員進行處理。但如果需求說明書沒有明确提到的，我們則可以定位為需求Bug，處理的流程如圖。 這樣處理有以下好處，首先需求Bug再不象以前，沒有人進行确認，需求的處理人員本來就是需求人員，由他們确認與跟蹤是最好不過的，因為他們對需求有絕對的權威。同時測試人員其實就是最早的使用者，他們的需求就是使用者的需求，這種方法加強了需求人員與測試人員的溝通，使需求得到有效的補充，進而讓産品更加完善。還有測試人員從本質上來說與程式員還是對立的，這裡如果為了這樣一個不是軟體本身問題的問題形成與開發人員的對立，則會出現赢得戰役而丢失整個戰争的情況，測試人員協調好與開發人員的關系，讓他們更有效的對軟體本身的缺陷形成有效的關注是最好的。還有最為關鍵的一點，測試人員的激情是最重要的，如果他們的想法沒有得到展現，這時會漸漸的失去對測試的興趣，進而軟體的品質則會無法得到保證，通過這種方法可以讓他們看到自己的建議可以通過對需求人員的反映得到實作，讓他們時時覺得自己的想法是可以通過這種方法來有效的推行，這樣工作的積極性才會有保障。

　　不過從實施的角度來說，還是有一定的困難的，首先要讓大家改變以前那種凡是Bug就是由開發人員負責的觀念，其次需求人員的工作量要加大，不過廣泛的了解需求是他們的本份工作，想來不會很困難，還有必需要有有效的Bug管理工具，比如BugManage等等，不要出現那種對需求人員說了，可過兩天就忘的情況出現，這時需求Bug的生命周期會出現跨越兩個軟體開發周期??要延長對這些需求Bug的管理，不過我想這些需求是他們提出的，會有興趣對這些Bug進行管理的。