在網上看過好幾次關于緊急而不嚴重、嚴重而不緊急的缺陷舉例，對網上的例子并不滿意，就此發表一下自己的看法。
該問題是討論緊急和嚴重程度的理解，但在面試的時候我們很容易直觀想到緊急程度跟時間有關系，嚴重程度跟功能重要性有關系。這個不能說錯，但這個理解未免太過于表面進而得分不高。
有人說：緊急不嚴重的會挑一些在臨近上線的時候突然冒出一個文字錯誤、體驗不佳的BUG，因為時機不巧所以緊急。
有人說：嚴重不緊急的會挑一些某功能很少有人使用即出現了BUG，因為其特性所以不緊急了。
對于這類答案，我有一個明顯的疑問：難道在測試的初期我們就沒有了緊急而不嚴重的BUG了，難道在常用功能里面我們就沒有嚴重而不緊急的問題了？如果突破了這兩個前提條件而符合要求的BUG，我認為才是一個高質量的BUG。這是我發表該問題看法的前置條件。
我更傾向于如下答案（用戶登陸為例）：
緊急而不嚴重：
因為登陸驗證碼無法顯示，導致用戶無法登陸進而影響所有人登入系統進行測試。
解析：就該問題而言，解決該問題的迫切程度遠高于討論問題的嚴重程度且驗證碼的問題算不上嚴重。對于開發來說，可能只需要動幾處代碼就行。對于需求方來說就算閹割該功能也沒事。
嚴重而不緊急：
輸入任何密碼均能登陸系統
解析：該缺陷屬于登陸的核心功能異常，登陸等于被廢。毫無疑問為嚴重，但對測試影響并不大，仍然可以登陸系統進行系統功能測試。
登陸功能畢竟屬于最常用來舉例的程序同時又是極少出問題的模塊，若舉非軟件測試經典案例效果將會更好。再另舉一例（通用型）
緊急而不嚴重：
某流程因其中一個節點使用無法通過，不能流轉至下一個環節。
解析：該缺陷在所有流程類測試中均可認為是緊急缺陷，嚴重程序視情況而定即首先咱們迫切希望問題解決、其次再去爭論缺陷嚴重等級。
嚴重而不緊急：
某流程如手機充值交易，充值完成后發現手機到賬金額為充值金額的2倍，即充值100元，實際到賬200元。
解析：直接提BUG，但不影響后續測試。
有人也許要反對了，以上的嚴重問題同樣也很緊急。那怎么判斷是否緊急呢，假設負責處理該BUG的開發因病休假或者結婚休假了，我們對于嚴重BUG能夠忍受幾天，說明并不那么緊急。如果半刻也不能忍受，那必是絕對緊急、相對不嚴重。
再有一條相對要求：所有嚴重、緊急的BUG均需在上線前修復完成；能夠容忍到上線后的BUG全部為不嚴重同時不緊急的BUG。