Bug的優先級是bug管理過程中必須考慮的問題。對于優先級的劃分，不同的軟件公司有自身的一套制度，因此筆者介紹的也僅僅是自己比較喜歡的一種方式。
為了便于bug的提交和管理，也為了方便于與開發人員進行交流，筆者傾向于在項目中將bug劃分為三個等級，而不是網絡上流傳的五等級版本甚至七等級版本（在成熟的軟件組織中，使用更細的bug等級劃分有利于bug分類，質量評審等工作的順利進行）。這三個優先級分別即優先級1（嚴重的），優先級2（比較嚴重的）和優先級3（一般的）。
筆者劃分bug等級的指導思想很簡單，嚴重影響測試執行的bug是最嚴重的，即優先級1 的bug，除此之外所有導致應用程序崩潰掉的bug也列入到優先級1中；其他功能性bug列入比較嚴重的bug的隊伍，即優先級2；界面上的bug列為一般的，即優先級3。
作者在實踐過程中推行的就是這種bug分級制度。這種分級制度看起來過于主觀，而不像網絡上流傳的各個bug優先級劃分的版本中，將每個優先級的bug的表現都一五一十列出來，如下是筆者以前使用到一個bug優先級劃分文檔中列出的優先級1的bug特征：
a）應用程序某個模塊功能未實現（包括整個模塊不能運行）
b）用戶的信息被破壞或者丟失
c）可重現的不可避免的崩潰，死鎖
d）功能和性能急劇衰退
e）嚴重的內存泄漏
f）導致功能無法正常使用的UI設計（UI響應遲緩）
g）其他
的確，這些bug優先級劃分很明確，讓人一目了然并且覺得很有道理，可是拿到實際中一用，麻煩開始來了。因為某些描述仍然不夠詳細，含混不清的描述諸如“功能和性能急劇衰退”，碰到這種描述，不同的人會有不同的理解，而不同的理解必然會帶來各種各樣的問題。因此，筆者在實踐中逐漸摒棄了這種做法（當然，筆者并不排除將來可能還是會回到一些比較正規的管理方法上來，但是目前這種“標準”方法并不適合筆者所在的公司~），并開始逐步推廣筆者自己剛才提到的粗放式bug優先級劃分方法。
對于該劃分方法，筆者還需要進一步的說明。筆者剛才提到的“嚴重影響測試執行的bug”其實也是指系統的基本功能或者核心功能，比如新建編輯刪除功能中，對于同樣是信息為保存到數據庫——即新建后記錄未添加到數據庫，編輯后記錄未更新，刪除后數據仍然存在于數據庫中——這時候筆者僅僅將新建功能的該bug置于優先級1中，編輯刪除bug則置于優先級2中。這種方法與很多正統的方法很不一致，因為在很多劃分方法中“信息未保存”都是優先級1的bug。但是筆者自認為這樣做是有理由的：當新建功能發生該類型bug而編輯刪除功能正常時，編輯刪除功能仍然無法測試或者實現（因為沒有數據?。@在客戶的江渡看來會直接視為新建編輯刪除功能均未實現。新建功能正常而編輯或者刪除功能失效，則不會影響到其他功能的使用（當僅編輯功能失效的時候，新建和刪除功能并不會受到影響），測試人員仍然進行新建刪除功能的功能測試，客戶依然可以使用新建和刪除功能。
當然，筆者使用上面的劃分方式還有其他的原因——基于bug管理和測試開發工作的順利推進。讀者可能會注意到，使用上面的bug劃分方式會減少優先級1的bug的數量，筆者這樣做是因為筆者在bug管理中推介的方式是優先級1的bug不允許推遲到下一個工作日修改。試想，如果優先級1的bug的數量如果過多自然會導致這種管理方式推行的極大阻力——沒有哪個開發人員會喜歡讓自己一整天的時間花費在修復bug上。當我們提交的優先級1的bug都是非常緊急的，會影響到開發或者測試的進度的話，開發人員就自知理虧不得不去修復這些bug了，這就保證了即使到了項目很急迫的時間，我們項目的主體功能還是穩定可用的，并有效遏制了嚴重bug的生存期。
對于優先級2與優先級3 的劃分點，只是筆者個人看法，因為筆者目前所經歷的項目都是功能性為主，因此對于UI相關的要求相對較低，因此筆者采取了這種粗放的方式（將UI相關bug歸納為優先級3，其他的非UI的非優先級1的bug全部塞到優先級2 的集裝箱中~）。
PS：感謝下面一位同仁的回復，優先級1類的bug還應該包括功能嚴重不符合產品說明書這種類型的bug。
以上為個人意見，如有意見建議，歡迎一起交流。