關于缺陷的優先級和嚴重級別(轉)

    我覺得有必要給大家解釋透這兩個概念，這樣不至于在日后的工作中做錯。

    以下粉紅色部分是對那篇英文的引用，后面則是我的回答（結合微軟的實際例子給大家說明）。

    從這篇文章來看，這段英文描述是有問題的——不能說不對，至少不合理。
    優先級不應該給tester指定，這也是很多缺陷流程制定者容易忽略到的地方——很大一部分原因是流程制定者沒有做過項目管理的工作或者學習過項目管理的知識。

為什么這么說呢？
    因為Tester只是項目團隊的成員之一，對缺陷管理、項目進度和項目風險都不可避免的會“盲人摸象”、“管中窺豹”，只“看”到自己“看”到的那個部分。
    一般來說，一個被測系統往往需要多個tester的，而每個tester往往只關注自己發現的bug，不大會去了解其他tester所發現的bug，那么在這種情況下，他如何能夠決定這個bug被修復的優先級別呢？！
這里再次強調一次，大家必須了解“Priority”真正的含義和作用——它是給管理者來據此做項目決策的，也就是說，缺陷優先級將直接導致工作安排的優先順序。PM正是通過參考缺陷優先級來安排開發人員的工作順序（這甚至能在Project里體現），使得項目風險降低、項目成本降低，解決問題更高效。
    其實，這在微軟內部就叫做“基于風險的測試”，也就是指評估測試的優先級，先做高優先級的測試，如果時間或精力不夠，低優先級的測試可以暫時先不做。有如下一個圖，橫軸代表影響，豎軸代表概率，根據一個軟件的特點來確定：如果一個功能出了問題，它對整個產品的影響有多大，這個功能出問題的概率有多大？如果出問題的概率很大，出了問題對整個產品的影響也很大，那么在測試時就一定要覆蓋到。對于一個用戶很少用到的功能，出問題的概率很小，就算出了問題的影響也不是很大，那么如果時間比較緊的話，就可以考慮不測試。

    以下是微軟公司的缺陷流程（不知道現在做微軟外包的公司是否也采用這套流程），給大家參考參考。
Bug跟蹤過程
　 在軟件開發項目中，測試人員的一項最重要使命就是對所有已知Bug進行有效的跟蹤和管理，保證產品中出現的所有問題都可以得到有效的解決。一般地，項目組發現、定位、處理和最終解決一個Bug的過程包括Bug報告、Bug評估和分配、Bug處理、Bug關閉等四個階段：
　 1）測試工程師在測試過程中發現新的Bug后，應向項目組報告該Bug的位置、表現、當前狀態等信息。項目組在Bug數據庫中添加該Bug的記錄。
　 2）開發經理對已發現的Bug進行集中討論，根據Bug對軟件產品的影響來評估Bug的優先級，制定Bug的修正策略。按照Bug的優先級順序和開發人員的工作安排，開發經理將所有需要立即處理的Bug分配給相應的開發工程師。
　 3）開發工程師根據安排對特定的Bug進行處理，找出代碼中的錯誤原因，修改代碼，重新生成產品版本。
　 4）開發工程師處理了Bug之后，測試人員需要對處理后的結果進行驗證，經過驗證確認已正確處理的Bug被標記為關閉（Close）狀態。測試工程師既需要驗證Bug是否已經被修正，也需要確定開發人員有沒有在修改代碼的同時引入新的Bug。

    話說回來，網上有很多自稱專家的人在那里大談特談所謂的優先級標準，什么“系統死機是高級別，界面錯誤是低級別”之類。其實這些指的是缺陷的嚴重級別（Serverity）！
    當然，一般來說缺陷的嚴重級別也不是tester“主觀判斷”決定的，如果公司比較規范的話，會由測試經理、項目經理等組織制訂這么一份相關的標準文檔，文檔是關于對應缺陷嚴重級別的定義。Tester在測試的時候就根據這么一份文檔來決定對應Bug的嚴重級別。
我下面粘貼某公司的一個《缺陷等級標準》的文檔，大家可以看到其中的“E類——測試建議”正是我上課所說的Enhancement。

========================
缺陷嚴重級別定義:
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類——測試建議（非缺陷）


===============================
    好了，關于缺陷優先級和嚴重級別我解釋到這兒，我希望同學們在學習的過程中知其然更要知其所以然。流程的制定不是想當然的，更不是因為看到別的公司都這么做自己就跟著做的。項目管理、缺陷管理都需要有很深的技術管理知識作為支撐，否則是作不好的。