軟體
缺陷（defect），常常又被叫做bug。所謂
軟體缺陷
，即為計算機軟體或程式中存在的某種破壞正常執行能力的問題、錯誤，或者隱藏的功能缺陷。
缺陷的存在會導致
軟體產品在某種程度上不能滿足使用者的需要。ieee729-1983對
缺陷有乙個標準的定義：從產品內部看，缺陷是
軟體產品開發或維護過程中存在的錯誤、毛病等各種問題；從產品外部看，缺陷是系統所需要實現的某種功能的失效或違背。在軟體開發生命週期的後期，修復檢測到的
軟體錯誤
的成本較高。
缺陷的優先順序：
1.resolve immediately：缺陷必須被立即解決。
2.normal queue：
缺陷需要正常排隊等待修復或列入
軟體發布清單。
3.not urgent：
缺陷可以在方便時被糾正。
缺陷的嚴重性：
軟體測試
錯誤嚴重程度
.critical：不能執行正常工作功能或重要功能。或者危及人身安全。
2.major：嚴重地影響系統要求或基本功能的實現，且沒有辦法更正。（重新安裝或重新啟動該
軟體不屬於更正辦法）
3.minor：嚴重地影響系統要求或基本功能的實現，但存在合理的更正辦法。（重新安裝或重新啟動該
軟體不屬於更正辦法）
4.cosmetic：使操作者不方便或遇到麻煩，但它不影響執行工作功能或重要功能。
5.other：其它錯誤。
同行評審錯誤嚴重程度
1.major：主要的，較大的
缺陷 2.minor：次要的，小的缺陷
級別：
嚴重性和優先順序是表徵
軟體測試
缺陷的兩個重要因素，它影響軟體缺陷的統計結果和修正缺陷的優先順序，特別在
軟體測試的後期，將影響軟體是否能夠按期發布與否。
對於 軟體測試初學者而言，或者沒有軟體開發經驗的
測試工程師，對於這兩個概念的理解，對於它們的作用和處理方式往往理解的不徹底，實際測試工作中不能正確表示
缺陷的嚴重性和優先順序。這將影響軟體
缺陷報告的質量，不利於盡早處理嚴重的軟體缺陷，可能影響軟體缺陷的處理時機。
什麼是缺陷的嚴重性和優先順序
嚴重性(
severity)顧名思義就是
軟體缺陷對
軟體質量的破壞程度，即此
軟體缺陷的存在將對
軟體的功能和效能產生怎樣的影響。
在 軟體測試中，軟體
缺陷的嚴重性的判斷應該從軟體終端使用者的觀點做出判斷，即判斷缺陷的嚴重性要為使用者考慮，考慮缺陷對使用者使用造成的惡劣後果的嚴重性。
優先順序是表示處理和修正軟體
缺陷的先後順序的指標，即哪些缺陷需要優先修正，哪些缺陷可以稍後修正。
確定軟體
缺陷優先順序，更多的是站在
軟體開發工程師的角度考慮問題，因為缺陷的修正順序是個複雜的過程，有些不是純粹技術問題，而且開發人員更熟悉
軟體**，能夠比
測試工程師更清楚修正缺陷的難度和風險。
缺陷的嚴重性和優先順序的關係
缺陷的嚴重性和優先順序是含義不同但相互聯絡密切的兩個概念。它們都從不同的側面描述了
軟體缺陷對
軟體質量和終端使用者的影響程度和處理方式。
一般地，嚴重性程度高的
軟體缺陷具有較高的優先順序。嚴重性高說明
缺陷對軟體造成的質量危害性大，需要優先處理，而嚴重性低的缺陷可能只是
軟體不太盡善盡美，可以稍後處理。
但是，嚴重性和優先順序並不總是一一對應。有時候嚴重性高的
軟體缺陷，優先順序不一定高，甚至不需要處理，而一些嚴重性低的缺陷卻需要及時處理，具有較高的優先順序。
修正 軟體
缺陷不是一件純技術問題，有時需要綜合考慮市場發布和質量風險等問題。例如，如果某個嚴重的
軟體缺陷只在非常極端的條件下產生，則沒有必要馬上解決。另外，如果修正乙個
軟體缺陷，需要重新修改軟體的整體架構，可能會產生更多潛在的缺陷，而且軟體由於市場的壓力必須盡快發布，此時即使缺陷的嚴重性很高，是否需要修正，需要全盤考慮。
另一方面，如果軟體
缺陷的嚴重性很低，例如，介面單詞拼寫錯誤，但是如果是軟體名稱或公司名稱的拼寫錯誤，則必須盡快修正，因為這關係到軟體和公司的市場形象。
處理缺陷的嚴重性和優先順序的常見錯誤
正確處理
缺陷的嚴重性和優先順序不是件非常容易的事情，對於經驗不是很豐富的測試和開發人員而言，經常犯的錯誤有以下幾種情形：
第一，將比較輕微的
缺陷報告成較高階別的缺陷和高優先順序，誇大缺陷的嚴重程度，經常給人「狼來了」的錯覺，將影響
軟體質量的正確評估，也耗費開發人員辨別和處理缺陷的時間。
第二，將很嚴重的
缺陷報告成輕微缺陷和低優先順序，這樣可能掩蓋了很多嚴重的缺陷。如果在專案發布前，發現還有很多由於不正確分配優先順序造成的嚴重
缺陷，將需要投入很多人力和時間進行修正，影響
軟體的正常發布。或者這些嚴重的
缺陷成了「漏網之魚」，隨
軟體一起發布出去，影響軟體的質量和使用者的使用信心。
因此，正確處理和區分
缺陷的嚴重性和優先順序，是
軟體測試人員和開發人員，以及全體專案組人員的一件大事。處理嚴重性和優先順序，既是一種經驗技術，也是保證
軟體質量的重要環節，應該引起足夠的重視。
如何表示缺陷的嚴重性和優先順序
缺陷的嚴重性和優先順序通常按照級別劃分，各個公司和不同專案的具體表示方式有所不同。
為了盡量準確的表示
缺陷資訊，通常將缺陷的嚴重性和優先順序分成4級。如果分級超過4級，則造成分類和判斷尺度的複雜程度，而少於4級，精確性有時不能保證。
具體的表示方法機可以使用數字表示，也可以使用文字表示，還可以數字和文字綜合表示。使用數字表示通常按照從高到底或從低到高的順序，需要
軟體測試前達成一致。例如，使用數字1，2，3，4分別表示輕微、一般、較嚴重和非常嚴重的嚴重性。對於優先順序而言，1，2，3，4可以分標表示低優先順序、一般、較高優先順序和最高優先順序。
如何確定缺陷的嚴重性和優先順序
通常由 軟體測試人員確定
缺陷的嚴重性，由軟體開發人員確定優先順序較為適當。但是，實際測試中，通常都是由
軟體測試人員在
缺陷報告中同時確定嚴重性和優先順序。
確定 缺陷的嚴重性和優先順序要全面了解和深刻體會缺陷的特徵，從使用者和開發人員以及市場的因素綜合考慮。通常功能性的
缺陷較為嚴重，具有較高的優先順序，而
軟體介面類缺陷的嚴重性一般較低，優先順序也較低。
對於 缺陷的嚴重性，如果分為4級，則可以參考下面的方法確定：
1 – 非常嚴重的
缺陷，例如，
軟體的意外退出甚至操作
系統崩潰，造成資料丟失。 2 – 較嚴重的
缺陷，例如，
軟體的某個選單不起作用或者產生錯誤的結果； 3 - 軟體一般缺陷，例如，本地化軟體的某些字元沒有翻譯或者翻譯不準確； 4 -
軟體介面的細微缺陷，例如，某個控制項沒有對齊，某個標點符號丟失等；
對於 缺陷的優先性，如果分為4級，則可以參考下面的方法確定：
1 –最高優先順序，例如，
軟體的主要功能錯誤或者造成軟體崩潰，資料丟失的
缺陷。 2 – 較高優先順序，例如，影響
軟體功能和效能的一般
缺陷； 3 -一般優先順序，例如，本地化軟體的某些字元沒有翻譯或者翻譯不準確的缺陷； 4 – 低優先順序，例如，對軟體的質量影響非常輕微或出現機率很低的缺陷；
其他注意事項
比較規範的
軟體測試，使用軟體缺陷管理資料庫進行缺陷報告和處理，需要在測試專案開始前對全體測試人員和開發人員進行培訓，對缺陷嚴重性和優先順序的表示和劃分方法統一規定和遵守。
在測試專案進行過程中和專案接收後，充分利用統計功能統計
缺陷的嚴重性，確定
軟體模組的開發質量，評估軟體專案實施進度。統計優先順序的分布情況，控制開發進度，使開發按照專案盡快進行，有效處理
缺陷，降低風險和成本。
為了保證報告
缺陷的嚴重性和優先順序的一致性，質量保證人員需要經常檢查測試和開發人員對於這兩個指標的分配和處理情況，發現問題，及時反饋給專案負責人，及時解決。
對於測試人員而言，通常經驗豐富的人員可以正確的表示
缺陷的嚴重性和優先順序，為缺陷的及時處理提供準確的資訊。對於開發人員來說，開發經驗豐富的人員嚴重
缺陷的錯誤較少，但是不要將缺陷的嚴重性作為衡量其開發水平高低的主要判斷指標，因為
軟體的模組的開發難度不同，各個模組的質量要求也有所差異。
軟體缺陷的嚴重性和優先順序
嚴重性和優先順序是表徵軟體測試缺陷的兩個重要因素，它影響軟體缺陷的統計結果和修正缺陷的優先順序，特別在軟體測試的後期，將影響軟體是否能夠按期發布與否。對於軟體測試初學者而言，或者沒有軟體開發經驗的測試工程師，對於這兩個概念的理解，對於它們的作用和處理方式往往理解的不徹底，實際測試工作中不能正確表示缺...
軟體缺陷級別和優先順序
缺陷嚴重程度是指因缺陷引起的故障對軟體產品的影響程度。致命 嚴重 一般 輕微 舉例 系統任何乙個主要功能完全失效，使用者資料受到破壞，系統崩潰 懸掛 司機或者危機人身安全 示例 系統的主要功能部分失效，資料不能儲存，系統的次要功能完全喪失，系統所提供的功能或服務受到明顯影響 示例 系統的次要功能沒有...
Bug嚴重級和優先順序
嚴重程度 優先順序嚴重 主要功能完全喪失 阻礙流程 系統崩潰導致重大任務不能正常進行的缺陷 1.由於程式所引起的宕機,非法退出 2.死迴圈 3.資料庫發生死鎖 4.錯誤操作導致的程式中斷 5.嚴重的計算錯誤 6.與資料庫連線錯誤 7.資料通訊錯誤等 8.系統崩潰,記憶體洩漏 9.嚴重的數值計算錯誤 ...