標籤: 暫無標籤

軟體缺陷(software defect)是對軟體產品預期屬性的偏離現象。它包括檢測缺陷和殘留缺陷。每一個軟體組織都知道必須妥善處理軟體中的缺陷。這是關係到軟體組織生存、發展的質量根本。

中科永聯高級技術培訓中心(www.itisedu.com     

      軟體缺陷(software defect)是對軟體產品預期屬性的偏離現象。它包括檢測缺陷和殘留缺陷。每一個軟體組織都知道必須妥善處理軟體中的缺陷。這是關係到軟體組織生存、發展的質量根本。

一、軟體缺陷(software defect)分類標準

      1.1 缺陷屬性

屬性名稱

描述

缺陷標識(Identifier)

缺陷標識是標記某個缺陷的一組符號。每個缺陷必須有一個唯一的標識

缺陷類型(Type)

缺陷類型是根據缺陷的自然屬性劃分的缺陷種類。

缺陷嚴重程度(Severity)

缺陷嚴重程度是指因缺陷引起的故障對軟體產品的影響程度。

缺陷優先順序(Priority)

缺陷的優先順序指缺陷必須被修復的緊急程度。

缺陷狀態(Status)

缺陷狀態指缺陷通過一個跟蹤修復過程的進展情況。

缺陷起源(Origin)

缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段。

缺陷來源(Source)

缺陷來源指引起缺陷的起因。

缺陷根源(Root Cause)

缺陷根源指發生錯誤的根本因素。


      1.2 缺陷類型(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

不符合各種標準的要求,如編碼標準、設計符號等。

      1.3 缺陷嚴重程度(Severity)

      1.3.1 軟體測試錯誤嚴重程度

#

缺陷嚴重等級

描述

1

Critical

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

2

Major

嚴重地影響系統要求或基本功能的實現,且沒有辦法更正。(重新安裝或重新啟動該軟體不屬於更正辦法)

3

Minor

嚴重地影響系統要求或基本功能的實現,但存在合理的更正辦法。(重新安裝或重新啟動該軟體不屬於更正辦法)

4

Cosmetic

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

5

Other

其它錯誤。

      1.3.2 同行評審錯誤嚴重程度

#

缺陷嚴重等級

描述

Major

主要的,較大的缺陷

Minor

次要的,小的缺陷


      1.4 缺陷優先順序(Priority)

#

缺陷優先順序

描述

1

Resolve Immediately

缺陷必須被立即解決。

2

Normal Queue

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

3

Not Urgent

缺陷可以在方便時被糾正。


      1.5 缺陷狀態(Status)

缺陷狀態

描述

Submitted

已提交的缺陷

Open

確認「提交的缺陷」,等待處理

Rejected

拒絕「提交的缺陷」,不需要修復或不是缺陷

resolved

缺陷被修復

Closed

確認被修復的缺陷,將其關閉


      1.6 缺陷起源(Origin)

缺陷起源

描述

Requirement

在需求階段發現的缺陷

Architecture

在構架階段發現的缺陷

Design

在設計階段發現的缺陷

Code

在編碼階段發現的缺陷

Test

在測試階段發現的缺陷


      1.7 缺陷來源(Source)

缺陷來源

描述

Requirement

由於需求的問題引起的缺陷

Architecture

由於構架的問題引起的缺陷

Design

由於設計的問題引起的缺陷

Code

由於編碼的問題引起的缺陷

Test

由於測試的問題引起的缺陷

Integration

由於集成的問題引起的缺陷

      1.8 缺陷根源(Root Cause)

 

二、軟體缺陷(software defect)的嚴重性和優先順序

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  正確處理缺陷的嚴重性和優先順序不是件非常容易的事情,對於經驗不很豐富??情形:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  其他注意事項

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

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

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

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

      通常大家發現軟體缺陷時會對軟體缺陷進行分類,可分類的方式只有一種,就是嚴重極別,難道沒有其它的分法嗎。比如我們碰到下面這種情況,測試人員發現有一種功能是必需加入進去的,這時他與程序員說,程序員說沒有時間或是不必要,這時這種情況則會形成兩者的扯皮,最終的結果也就不了了知了,這樣會戳傷了測試人員的積極性,下次他們再也不會盡心的考慮產品的問題,只要可以運行就可以了。其實這種情況是可以解決的,下面我會提到一個新的軟體缺陷分類概念,從而有效的解決這個問題。

  在軟體缺陷中不僅僅只是嚴重極別,更多的則是功能沒有做到。說到這裡也許大家都理解了,就是需求沒有考慮到,可需求不會一次就很完美的,需要大家的共同努力,來不斷的完善。那麼怎樣才能讓測試人員提出的好的建議得到有效的執行?這就是我下面想說的。在軟體缺陷中還有一種分法,跟據缺陷內容來分, , ,主要分為需求Bug與程序Bug,對於這種分法的好處就是明確了Bug處理的責任人。對於程序Bug我們都知道是由相關開發人員進行處理。下面主要討論一下需求Bug,需求Bug從名稱上來就知道是要交由需求人員進行處理,可怎麼處理,怎樣在處理的過程中有效的, 讓這些創意得到體現。現在我們都有Bug管理系統,這時我們的測試人員將需求Bug不是提交給程序員,而是提交給需求分析人員,由他們進行處理,不過這裡我想強調的是對需求Bug的定位,如果這個Bug在軟體需求說明書中明確提到了,這時就不可能定位它為需求Bug,它是必需讓程序, , , , 員實現的,稱為軟體功能缺陷,提交由程序員進行處理。但如果需求說明書沒有明確提到的,我們則可以定位為需求Bug,處理的流程如圖。

軟體缺陷

  這樣處理有以下好處,首先需求Bug再不象以前,沒有人進行確認,需求的處理人員本來就是需求人員,由他們確認與跟蹤是最好不過的,因為他們對需求有絕對的權威。同時測試人員其實就是最早的用戶,他們的需求就是用戶的需求,這種方法加強了需求人員與測試人員的溝通,使需求得到有效的補充,從而讓產品更加完善。還有測試人員從本質上來說與程序員還是對立的,這裡如果為了這樣一個不是軟體本身問題的問題形成與開發人員的對立,則會出現贏得戰役而丟失整個戰爭的情況,測試人員協調好與開發人員的關係,讓他們更有效的對軟體本身的缺陷形成有效的關注是最好的。還有最為關鍵的一點,測試人員的激情是最重要的,如果他們的想法沒有得到體現,這時會漸漸的失去對測試的興趣,從而軟體的質量則會無法得到保證,通過這種方法可以讓他們看到自己的建議可以通過對需求人員的反映得到實現,讓他們時時覺得自己的想法是可以通過這種方法來有效的推行,這樣工作的積極性才會有保障。

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

四、軟體缺陷(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
由於測試的問題引起的缺陷
Integration
由於集成的問題引起的缺陷

      排除階級表示發現和修復這個缺陷的階級,通常分為如下:

排除階段
描述
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進行管理的。

四、軟體缺陷(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
由於測試的問題引起的缺陷
Integration
由於集成的問題引起的缺陷

      排除階級表示發現和修復這個缺陷的階級,通常分為如下:

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

      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)
缺陷可以在方便時被糾正。

上一篇[軟體風險管理]    下一篇 [膀胱陰道瘺]

相關評論

同義詞:暫無同義詞