去易迅面试，QA主管问，“严重但不紧急，紧急但不严重的BUG能不能举几个例子”

candy_wf · 发表于 2012-8-15 17:25:15

严重但不紧急：用户买了一年vip，有个到期时会导致用户数据清零但没有任何提示的bug，但在一年内都不影响用户的使用。
紧急不严重：错别字。
严重紧急：XSS漏洞

yhz460363746 · 发表于 2012-8-16 09:48:35

学到了。

mainer · 发表于 2012-8-17 19:06:04

太变态了，估计问我也卡壳了。

我每天坐27路 · 发表于 2012-8-20 10:42:45

有没人直接写出几个例子来？有些人喜欢分析问题，但我是菜鸟，还是喜欢从答案上找结果

TesterChen · 发表于 2012-8-31 16:11:51

我举一个实际上碰到的缺陷吧，关于登陆的。
紧急而不严重：登陆窗口的验证码显示不出来，导致无法登陆。
...
千里发表于 2012-8-12 11:27

千里兄，我怎么想都觉得你说的这个登录的两个问题，都属于紧急而严重的问题。。。

buble84 · 发表于 2012-9-7 15:19:29

回复 25# 千里

受教啊.

Jackc · 发表于 2012-9-7 17:59:53

紧急但不严重的类型：如果选择UI bug作为答案，需要额外注意一些其他方面。在某些产品中，UI bugs的严重级别是比较高的。比如新闻系统或App的Title。
简单来说，相同类型的2个bug，如果Bug A易于被用户察觉，或涉及安全/规范等范畴，都可能会被定义为较高严重程度。

故，“紧急但不严重”可选为：客户来源反馈的低严重级别bug，如客户反馈，产品的UI界面过于冷色调

小结：其实国内很多公司在对CMMI进行流程裁剪时，已经将“优先级”&“严重程度”进行一定的整合，使两者可以同时对单个bug进行评估。

duangang312 · 发表于 2012-9-8 16:23:40

回复 47# Jackc

还是得分线上，线下。线上的话，UI bug肯定是紧急bug，至于是不是严重另说，线下你敢算紧急严重的，开发非跟你急不可。

xiaoshi_2011 · 发表于 2012-9-10 15:03:48

其实测试部只是找BUG，更重要的是需要去总结分析，这样才能更好的提高产品质量

enjoyhappylife · 发表于 2012-9-12 15:05:23

前段时间测试过程中碰到一个问题：deadlock，不知道大家碰到过没有，这个问题很难复现，至今也没找出出现的规律性以及原因，但是一旦出现，程序就不会继续运行了，需要重新启动服务。所以我想找个问题应该属于上边的所说的吧。

5itttesting · 发表于 2012-9-18 16:39:38

紧急不重要：不影响功能使用，但是会严重影响验收效果或使用效果的缺陷
重要不紧急：功能使用频率低或者是缺陷出现率低，或该功能短时间不会用到

a349643236 · 发表于 2012-9-24 10:36:32

好帖，以前没想过这个问题

挑战无处不在 · 发表于 2012-10-26 11:19:23

紧急不严重：“中国人民银行”写成“中国人民很行”了，这个要是在中国银行的page上面，应该算是紧急但是不 ...
kenanmao1983 发表于 2012-8-9 16:51

这个例子不错！

alljl · 发表于 2012-11-2 11:14:01

学习了...

千里 · 发表于 2012-11-2 13:16:12

千里兄，我怎么想都觉得你说的这个登录的两个问题，都属于紧急而严重的问题。。。
TesterChen 发表于 2012-8-31 16:11

要考虑一下是在测试阶段，这个时期不是面对用户，是面对开发。

千里 · 发表于 2012-11-2 13:19:31

紧急不重要：不影响功能使用，但是会严重影响验收效果或使用效果的缺陷
重要不紧急：功能使用频率低或者是 ...
5itttesting 发表于 2012-9-18 16:39

我想问一下这个紧急和严重是上线后的BUG，被用户逮到了去定性的还是测试时候被测试人员发现了找开发人员定性的？
整个回帖，我看到的是假设在上线后在试运行阶段被用户逮出来了，用户对这个BUG的一个看法而不是假设测试人员对这个BUG的看法。

wensy · 发表于 2012-12-12 17:33:13

这个命题很好，首先要弄明白两个概念：
1、严不严重，是根据用户而言的，不是产品本身，是对用户造成伤害的大小，更不会是修改i问题工作量的大小。
2、紧不紧级，同样是根据用户而言，这里不能单纯说是时间问题，应该是减少或规避使用者满意度下降的一个指标。紧急处理了，就能减少或规避使用者满意度的影响；处理滞缓了，就会给用户带来满意度的下降。
弄明白了这两个概念，去解释“严重并不紧急”或“紧急并不严重”就会使用适当的优先原则进行处理，使问题处置更简单，而不会是一件脑袋疼的事情。

wensy · 发表于 2012-12-12 17:33:41

这个命题很好，首先要弄明白两个概念：
1、严不严重，是根据用户而言的，不是产品本身，是对用户造成伤害的大小，更不会是修改i问题工作量的大小。
2、紧不紧级，同样是根据用户而言，这里不能单纯说是时间问题，应该是减少或规避使用者满意度下降的一个指标。紧急处理了，就能减少或规避使用者满意度的影响；处理滞缓了，就会给用户带来满意度的下降。
弄明白了这两个概念，去解释“严重并不紧急”或“紧急并不严重”就会使用适当的优先原则进行处理，使问题处置更简单，而不会是一件脑袋疼的事情。

0omiaomiaoo0 · 发表于 2012-12-23 17:21:33

学习中，这要是问到我了，我还真一下答不上来，看来还是要多练习

0omiaomiaoo0 · 发表于 2012-12-23 17:23:35

学习了，这问题说难不难，却也不是一下能想到的，发现平时太死板了点，还是要多学习，多练习

		自动登录	找回密码
密码			(注-册)加入51Testing

[求助] 去易迅面试，QA主管问，“严重但不紧急，紧急但不严重的BUG能不能举几个例子”

站长推荐 /1