在网上看过好几次关于紧急而不严重、严重而不紧急的缺陷举例，对网上的例子并不满意，就此发表一下自己的看法。
该问题是讨论紧急和严重程度的理解，但在面试的时候我们很容易直观想到紧急程度跟时间有关系，严重程度跟功能重要性有关系。这个不能说错，但这个理解未免太过于表面进而得分不高。
有人说：紧急不严重的会挑一些在临近上线的时候突然冒出一个文字错误、体验不佳的BUG，因为时机不巧所以紧急。
有人说：严重不紧急的会挑一些某功能很少有人使用即出现了BUG，因为其特性所以不紧急了。
对于这类答案，我有一个明显的疑问：难道在测试的初期我们就没有了紧急而不严重的BUG了，难道在常用功能里面我们就没有严重而不紧急的问题了？如果突破了这两个前提条件而符合要求的BUG，我认为才是一个高质量的BUG。这是我发表该问题看法的前置条件。
我更倾向于如下答案（用户登陆为例）：
紧急而不严重：
因为登陆验证码无法显示，导致用户无法登陆进而影响所有人登入系统进行测试。
解析：就该问题而言，解决该问题的迫切程度远高于讨论问题的严重程度且验证码的问题算不上严重。对于开发来说，可能只需要动几处代码就行。对于需求方来说就算阉割该功能也没事。
严重而不紧急：
输入任何密码均能登陆系统
解析：该缺陷属于登陆的核心功能异常，登陆等于被废。毫无疑问为严重，但对测试影响并不大，仍然可以登陆系统进行系统功能测试。
登陆功能毕竟属于最常用来举例的程序同时又是极少出问题的模块，若举非软件测试经典案例效果将会更好。再另举一例（通用型）
紧急而不严重：
某流程因其中一个节点使用无法通过，不能流转至下一个环节。
解析：该缺陷在所有流程类测试中均可认为是紧急缺陷，严重程序视情况而定即首先咱们迫切希望问题解决、其次再去争论缺陷严重等级。
严重而不紧急：
某流程如手机充值交易，充值完成后发现手机到账金额为充值金额的2倍，即充值100元，实际到账200元。
解析：直接提BUG，但不影响后续测试。
有人也许要反对了，以上的严重问题同样也很紧急。那怎么判断是否紧急呢，假设负责处理该BUG的开发因病休假或者结婚休假了，我们对于严重BUG能够忍受几天，说明并不那么紧急。如果半刻也不能忍受，那必是绝对紧急、相对不严重。
再有一条相对要求：所有严重、紧急的BUG均需在上线前修复完成；能够容忍到上线后的BUG全部为不严重同时不紧急的BUG。