我覺得有必要給大家解釋透這兩個概念，這樣不至于在日后的工作中做錯。
以下粉紅色部分是對那篇英文的引用，后面則是我的回答（結合微軟的實際例子給大家說明）。
c) The tester then selects the priority of the defect:
Critical - fatal error
High - require immediate attention
Medium - needs to be resolved as soon as possible but not a showstopper
Low - cosmetic error
從這篇文章來看，這段英文描述是有問題的——不能說不對，至少不合理。
優先級不應該給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分配給相應的開發工程師。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
