軟體缺陷等級如何劃分

❶ 缺陷等級應如何劃分

不同的公司對缺陷等級的劃分界限還是有區別的，但是一般的都遵循以下的原則：極高：在測試的過程中出現死機，系統崩潰、數據丟失，功能沒有實現等此類缺陷的級別；高：此類缺陷導致系統功能不穩定，或功能實現錯誤，流程錯誤等。中：校驗錯誤、罕見故障、錯別字等不會影響系統功能，但會影響用戶易用性等的錯誤。低：對系統沒影響的一些小問題。

❷ 軟體缺陷的優先順序

嚴重性和優先順序是表徵軟體測試缺陷的兩個重要因素，它影響軟體缺陷的統計結果和修正缺陷的優先順序，特別在軟體測試的後期，將影響軟體是否能夠按期發布與否。
對於軟體測試初學者而言，或者沒有軟體開發經驗的測試工程師，對於這兩個概念的理解，對於它們的作用和處理方式往往理解的不徹底，實際測試工作中不能正確表示缺陷的嚴重性和優先順序。這將影響軟體缺陷報告的質量，不利於盡早處理嚴重的軟體缺陷，可能影響軟體缺陷的處理時機。
什麼是缺陷的嚴重性和優先順序
嚴重性(Severity)顧名思義就是軟體缺陷對軟體質量的破壞程度，即此軟體缺陷的存在將對軟體的功能和性能產生怎樣的影響。
在軟體測試中，軟體缺陷的嚴重性的判斷應該從軟體最終用戶的觀點做出判斷，即判斷缺陷的嚴重性要為用戶考慮，考慮缺陷對用戶使用造成的惡劣後果的嚴重性。
優先順序是表示處理和修正軟體缺陷的先後順序的指標，即哪些缺陷需要優先修正，哪些缺陷可以稍後修正。
確定軟體缺陷優先順序，更多的是站在軟體開發工程師的角度考慮問題，因為缺陷的修正順序是個復雜的過程，有些不是純粹技術問題，而且開發人員更熟悉軟體代碼，能夠比測試工程師更清楚修正缺陷的難度和風險。
缺陷的嚴重性和優先順序的關系
缺陷的嚴重性和優先順序是含義不同但相互聯系密切的兩個概念。它們都從不同的側面描述了軟體缺陷對軟體質量和最終用戶的影響程度和處理方式。
一般地，嚴重性程度高的軟體缺陷具有較高的優先順序。嚴重性高說明缺陷對軟體造成的質量危害性大，需要優先處理，而嚴重性低的缺陷可能只是軟體不太盡善盡美，可以稍後處理。
但是，嚴重性和優先順序並不總是一一對應。有時候嚴重性高的軟體缺陷，優先順序不一定高，甚至不需要處理，而一些嚴重性低的缺陷卻需要及時處理，具有較高的優先順序。
修正軟體缺陷不是一件純技術問題，有時需要綜合考慮市場發布和質量風險等問題。例如，如果某個嚴重的軟體缺陷只在非常極端的條件下產生，則沒有必要馬上解決。另外，如果修正一個軟體缺陷，需要重新修改軟體的整體架構，可能會產生更多潛在的缺陷，而且軟體由於市場的壓力必須盡快發布，此時即使缺陷的嚴重性很高，是否需要修正，需要全盤考慮。
另一方面，如果軟體缺陷的嚴重性很低，例如，界面單詞拼寫錯誤，但是如果是軟體名稱或公司名稱的拼寫錯誤，則必須盡快修正，因為這關繫到軟體和公司的市場形象。
處理缺陷的嚴重性和優先順序的常見錯誤
正確處理缺陷的嚴重性和優先順序不是件非常容易的事情，對於經驗不是很豐富的測試和開發人員而言，經常犯的錯誤有以下幾種情形：
第一，將比較輕微的缺陷報告成較高級別的缺陷和高優先順序，誇大缺陷的嚴重程度，經常給人「狼來了」的錯覺，將影響軟體質量的正確評估，也耗費開發人員辨別和處理缺陷的時間。
第二，將很嚴重的缺陷報告成輕微缺陷和低優先順序，這樣可能掩蓋了很多嚴重的缺陷。如果在項目發布前，發現還有很多由於不正確分配優先順序造成的嚴重缺陷，將需要投入很多人力和時間進行修正，影響軟體的正常發布。或者這些嚴重的缺陷成了「漏網之魚」，隨軟體一起發布出去，影響軟體的質量和用戶的使用信心。
因此，正確處理和區分缺陷的嚴重性和優先順序，是軟體測試人員和開發人員，以及全體項目組人員的一件大事。處理嚴重性和優先順序，既是一種經驗技術，也是保證軟體質量的重要環節，應該引起足夠的重視。
如何表示缺陷的嚴重性和優先順序
缺陷的嚴重性和優先順序通常按照級別劃分，各個公司和不同項目的具體表示方式有所不同。
為了盡量准確的表示缺陷信息，通常將缺陷的嚴重性和優先順序分成4級。如果分級超過4級，則造成分類和判斷尺度的復雜程度，而少於4級，精確性有時不能保證。
具體的表示方法機可以使用數字表示，也可以使用文字表示，還可以數字和文字綜合表示。使用數字表示通常按照從高到底或從低到高的順序，需要軟體測試前達成一致。例如，使用數字1，2，3，4分別表示輕微、一般、較嚴重和非常嚴重的嚴重性。對於優先順序而言，1，2，3，4可以分標表示低優先順序、一般、較高優先順序和最高優先順序。
如何確定缺陷的嚴重性和優先順序
通常由軟體測試人員確定缺陷的嚴重性，由軟體開發人員確定優先順序較為適當。但是，實際測試中，通常都是由軟體測試人員在缺陷報告中同時確定嚴重性和優先順序。
確定缺陷的嚴重性和優先順序要全面了解和深刻體會缺陷的特徵，從用戶和開發人員以及市場的因素綜合考慮。通常功能性的缺陷較為嚴重，具有較高的優先順序，而軟體界面類缺陷的嚴重性一般較低，優先順序也較低。
對於缺陷的嚴重性，如果分為4級，則可以參考下面的方法確定：
1 – 非常嚴重的缺陷，例如，軟體的意外退出甚至操作系統崩潰，造成數據丟失。 2 – 較嚴重的缺陷，例如，軟體的某個菜單不起作用或者產生錯誤的結果； 3 - 軟體一般缺陷，例如，本地化軟體的某些字元沒有翻譯或者翻譯不準確； 4 -軟體界面的細微缺陷，例如，某個控制項沒有對齊，某個標點符號丟失等；
對於缺陷的優先性，如果分為4級，則可以參考下面的方法確定：
1 –最高優先順序，例如，軟體的主要功能錯誤或者造成軟體崩潰，數據丟失的缺陷。 2 – 較高優先順序，例如，影響軟體功能和性能的一般缺陷； 3 -一般優先順序，例如，本地化軟體的某些字元沒有翻譯或者翻譯不準確的缺陷； 4 – 低優先順序，例如，對軟體的質量影響非常輕微或出現幾率很低的缺陷；
其他注意事項
比較規范的軟體測試，使用軟體缺陷管理資料庫進行缺陷報告和處理，需要在測試項目開始前對全體測試人員和開發人員進行培訓，對缺陷嚴重性和優先順序的表示和劃分方法統一規定和遵守。
在測試項目進行過程中和項目接收後，充分利用統計功能統計缺陷的嚴重性，確定軟體模塊的開發質量，評估軟體項目實施進度。統計優先順序的分布情況，控制開發進度，使開發按照項目盡快進行，有效處理缺陷，降低風險和成本。
為了保證報告缺陷的嚴重性和優先順序的一致性，質量保證人員需要經常檢查測試和開發人員對於這兩個指標的分配和處理情況，發現問題，及時反饋給項目負責人，及時解決。
對於測試人員而言，通常經驗豐富的人員可以正確的表示缺陷的嚴重性和優先順序，為缺陷的及時處理提供准確的信息。對於開發人員來說，開發經驗豐富的人員嚴重缺陷的錯誤較少，但是不要將缺陷的嚴重性作為衡量其開發水平高低的主要判斷指標，因為軟體的模塊的開發難度不同，各個模塊的質量要求也有所差異。

❸ 如何劃分缺陷【類型】【等級】【原因】

1. 缺陷等級、類型、原因的劃分會因公司或項目管理需求的不同、業務類型的不同而不同，公司EPG在參考其它公司分類情況的基礎上，關鍵任務是要根據自身的需求和業務情況總結出適合自己的分類情況。

2. 個人認為缺陷等級的劃分要看公司或項目組關心哪個緯度的數據，比如關心缺陷的嚴重程度，那等級可能可以分為致命、嚴重、中等、一般等幾個級別；如果比較關心缺陷影響范圍，那等級可能可以分為很大、大、中、小等級別；如果比較關心缺陷的處理的緊急程度，那等級可能可以分為緊急、高、中、低等級別……。當然，緯度還有很多種，關鍵是看你關心什麼數據，而且這些緯度也可以結合在一起，以加強對問題的管理。等級的劃分雖說很多是定性的，但最好也能夠有個比較清晰的定義，以方便推廣和選擇，減少歧議。再有就是上面提到的「為了建立各項目工作產品質量的比較，是不是得有一個統一的缺陷基準？如1致命缺陷=2嚴重缺陷=4一般缺陷=？？？」這樣做的目的是為了做項目績效考核嗎？一般很少有公司會這樣做吧，個人認為等級劃分是為了更好地對問題進行管理和分析，而不適合用定量的方法去轉換各不同級別缺陷的數量。

❹ 軟體缺陷的等級劃分是如何劃分的

軟體缺陷的等級劃分是如何劃分的？我認為每個軟體都是有缺陷的，只是說有的缺陷比較小，有的缺陷比較大，就根據你軟體的運行的計算大不大來計算吧？

❺ 軟體缺陷的分類標准

1.缺陷標識(Identifier)： 缺陷標識是標記某個缺陷的一組符號。每個缺陷必須有一個唯一的標識。
2.缺陷類型 (Type)： 缺陷類型是根據缺陷的自然屬性劃分的缺陷種類。
3.缺陷嚴重程度 (Severity) ：缺陷嚴重程度是指因缺陷引起的故障對軟體產品的影響程度。
4.缺陷優先順序(Priority)： 缺陷的優先順序指缺陷必須被修復的緊急程度。
5.缺陷狀態(Status) ：缺陷狀態指缺陷通過一個跟蹤修復過程的進展情況。
6.缺陷起源(Origin) ：缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段。
7.缺陷來源(Source)： 缺陷來源指引起缺陷的起因。
8.缺陷根源(Root Cause)： 缺陷根源指發生錯誤的根本因素。 F- Function ：影響了重要的特性、用戶界面、產品介面、硬體結構介面和全局數據結構。並且設計文檔需要正式的變更。如邏輯，指針，循環，遞歸，功能等缺陷。
A- Assignment： 需要修改少量代碼，如初始化或控制塊。如聲明、重復命名，范圍、限定等缺陷。
I- Interface： 與其他組件、模塊或設備驅動程序、調用參數、控制塊或參數列表相互影響的缺陷。
C- Checking： 提示的錯誤信息，不適當的數據驗證等缺陷。
B Build/package/merge ：由於配置庫、變更管理或版本控制引起的錯誤。
D- Documentation： 影響發布和維護，包括注釋。
G- Algorithm ：演算法錯誤。
U-User Interface：人機交互特性：屏幕格式，確認用戶輸入，功能有效性，頁面排版等方面的缺陷。
P-Performance：不滿足系統可測量的屬性值，如：執行時間，事務處理速率等。
N-Norms：不符合各種標準的要求，如編碼標准、設計符號等。 軟體測試錯誤嚴重程度
1.Critical：不能執行正常工作功能或重要功能。或者危及人身安全。
2.Major：嚴重地影響系統要求或基本功能的實現，且沒有辦法更正。（重新安裝或重新啟動該軟體不屬於更正辦法）
3.Minor：嚴重地影響系統要求或基本功能的實現，但存在合理的更正辦法。（重新安裝或重新啟動該軟體不屬於更正辦法）
4.Cosmetic：使操作者不方便或遇到麻煩，但它不影響執行工作功能或重要功能。
5.Other：其它錯誤。
同行評審錯誤嚴重程度
1.Major：主要的，較大的缺陷
2.Minor：次要的，小的缺陷 1.Resolve Immediately：缺陷必須被立即解決。
2.Normal Queue：缺陷需要正常排隊等待修復或列入軟體發布清單。
3.Not Urgent：缺陷可以在方便時被糾正。 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： 由於集成的問題引起的缺陷

❻ 軟體測試中的軟體的缺陷等級如何劃分

可以劃分為 重大錯誤--嚴重錯誤--一般錯誤--輕微錯誤
也可以按照 S--A--B--C 來劃分，這個東西不是死，並沒有什麼規定，只要你喜歡，你可以用自己詞語去劃分，只要詞語描述清晰即可

❼ 簡述軟體缺陷的定義和劃分

IEEE 1983 of IEEE Standard 729中對軟體缺陷作了一個標準的定義：
從產品內部看，軟體缺陷是軟體產品開發或維護過程中所存在的錯誤、毛病等各種問題；從外部看，軟體缺陷是系統所需要實現的某種功能的失效或違背。
因此軟體缺陷就是軟體產品中所存在的問題，最終表現為用戶所需要的功能沒有完全實現，沒有滿足用戶的需求。
以前看黑馬程序員公開課時候就講過。

❽ 舉例說下軟體缺陷等級

缺陷嚴重級別定義:
o 最高級--導致運行中斷(應用程序崩潰),預期的功能沒有得到實現,測試工作無法繼續進行等.
o 緊急---事件非常重要,並且需要馬上給予關注.
o 高級---事件是重要的,並且應該在緊急的事件處理之後盡快得到解決.
o 中級---事件是重要的,但是由於解決問題需要花費一定的時間,所以可以用較長的時間解決.
o 低級---事件不重要,可以在時間和資源允許的情況下再解決.
o 建議性缺陷.

更為詳細的劃分如下:

A類——嚴重錯誤，包括：
o 由於程序所引起的死機,非法退出
o 死循環
o 導致資料庫發生死鎖
o 數據通訊錯誤
o 嚴重的數值計算錯誤

B類——較嚴重錯誤，包括：
o 功能不符
o 數據流錯誤
o 程序介面錯誤
o 輕微的數值計算錯誤

C類——一般性錯誤，包括：
o 界面錯誤(詳細文檔)
o 列印內容、格式錯誤
o 簡單的輸入限制未放在前台進行控制
o 刪除操作未給出提示

D類——較小錯誤，包括：
o 輔助說明描述不清楚
o 顯示格式不規范
o 長時間操作未給用戶進度提示
o 提示窗口文字未採用行業術語
o 可輸入區域和只讀區域沒有明顯的區分標志
o 系統處理未優化

E類——測試建議（非缺陷）

❾ 軟體缺陷分類的標准

軟體缺陷(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： 由於集成的問題引起的缺陷