偶尔出现的缺陷如何处理？（10-04-19）（获奖名单已公布）

默默巫

对于测试来说最怕遇到的就是不可重现的严重级bug，在执行的不经意间出现了一个crash的bug，然后无论如何尝试

都无法重现，当遇到这种问题时作为一个测试应该如何处理？

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	Christina_LL	价值50元的礼品	10#
二等奖	shwonder	300论坛积分	14#
	小小孩子		15#
三等奖	deanaa	100论坛积分	3#
	woodcraft		4#
	晒太阳的耗子		8#

孟胡范b

感谢楼主辛苦发贴。吞噬星空  http://www.kanshu.la/

凤凰山

做好缺陷跟踪记录，及时纠正
通过以前的缺陷记录，找出潜在的缺陷

ATTITODE

学习

wjlMydream

高手太多了，学习了，谢谢

wjlMydream

学习！！！

beyondxiang

不错。

gongx2008

zpzs

学习了不少，都是实用的东东，感谢分享。

b45993e

暂时还没碰见过。

b45993e

原帖由 胡靖 于 2010-4-22 21:22 发表
新手路过，看见很多高手，不敢发表言论，只有顶一下。

ME TOO

测试王国

高手还真多呀，我在这里学习下，都不敢回答。

qicailingbing

大家讨论的热火朝天，我也忍不住说说自个的想法。
    首先，我们应该回到测试的最终目的来考虑这个问题。测试是为了保障产品的质量，发现常见的缺陷，偶尔的缺陷，都是测试人员为了最大限度的保障产品质量。注意这里我用到了咱们常用的一句话“最大限度的保障产品的质量”，作为测试人员，大家都清楚，我们的工作不可能发现所有的缺陷。
    现在回到我们的主题“如何处理偶尔出现的缺陷”。偶尔出现的缺陷，它不容易重现，或是重现的代价高，如何处理成了一个难题。总有一堆堆的理论知识教育我们，作为测试人员不能存在侥幸心理，要尽自己的能力重现缺陷，才能保障产品质量。理论总归是理论，现实中的我们要是把自己框在理论的框架里，测试工作估计也很难做好了。
    我认为一名好的测试人员，应该从产品质量和生产效率两方面综合考虑。准确评估缺陷风险。对于影响较大的偶尔出现缺陷，应尽最大努力去重现。对于多次努力均不能重现的缺陷，我们应该准确记录缺陷的特征，在系统上线之后，密切关注这些方面的问题，跟踪缺陷。在缺陷真正暴露时，可以根据跟踪信息尽早定位问题，早日解决，不给客户带来过多的麻烦。对于那些对项目影响不大，或是出现概率极低的缺陷，我们可以先记录缺陷特征，在上线之后，再跟踪缺陷，及早解决。
    最后，我想声明一点，我的态度不是放任这些缺陷。对于大多数缺陷，作为测试人员我会通过各种方式尽自己的最大努力去重现。我只是强调，我们应该从保障系统质量和生产效率角度来综合考虑如何处理这些缺陷。另外，做好偶发缺陷的跟踪工作，我认为是十分有必要的。
    很高兴和大家交流~~

namisang

学习，期待更多高人。

小小孩子

　　问题场景：

　　有一些比较严重的BUG随机发生，难以查找规律的，测试工程师提交上去后，有可能会出现以下三个情形：

　　1.开发人员试图重现，重现不出，Reject回来;

　　2.开发人员找不到规律，所以不去解决，问题一直处于Open状态;

　　3.开发人员因为问题难以解决，所以直接Resolved回来，觉得反正是偶发的，先改成解决状态再说。

　　对开发人员、项目经理和测试工程师来说，正确的处理方法应该是怎样的?

　　解决方案：

　　1 缺陷的描述：

　　(1)重现频率：在提交Bug时，记录重现的频率(是、否、随机)

　　(2)现象：测试人员尽可能描述发生的情况并有截图。

　　(3)软件的版本：确认发现BUG程序版本和重现的代码是一致的，可通过tag(Clearcase应该叫Label)或者Revision号来标注。

　　(4)数据：发生错误时的各种变量、内存、存储器等存储的数据内容。

　　(5)环境：软件出错时的软硬件环境。

　　对缺陷的描述应该尽可能的详细。

　　2 缺陷的重现：

　　(1)重现的人员： 缺陷的重现工作，最好由测试人员去完成，一方面，测试人员的文字描述其实很难包括所有的现象信息，让开发人员重现的难度很大，另一方面，测试人员的重现更有说服力和更快捷。

　　(2)重现的次数：每个难重现的缺陷，由发现该缺陷的测试人员连续重复测试300次，如果还不能重现，将缺陷状态改为closed;

　　(3)延长测试时间，努力找到规律。如果市场紧急，由公司级领导特批，相当于高层领导评估风险，就可以先发布软件，但测试和整改继续，留待问题解决后下一版本软件升级;

　　(4) 若确实无法重现，转交项目经理做延迟处理，继续跟踪，若保留一个月都无法重现的，可先关闭，以后重现时再Reopen;

　　3 不可重现的缺陷的处理方法：

　　(1)人工代码走查：无法重现的代码找对系统最熟悉的开发人员重新Review代码，最好是多人一起查。查代码还找不出来，就要检查操作系统、应用服务器及其环境是否有问题，是否有兼容性问题。

　　(2)工具静态检查：采用静态检查工具(如pclint,splint等工具)检查代码，消除所有的error与warning。记住：可能出现问题的地方一定出现问题!

　　(3)换人重新开发相关模块：

　　4 缺陷的记录：

　　(1)开发人员Resolve缺陷的时候要写Revision号，写bug的原因。通过Revision号可以追溯到究竟改了什么内容。写bug原因对开发人员也是一种提高，知其然，也知其所以然。

　　(2)根据紧急程度，放入每日/每周跟踪列表，每次开例会时跟踪问题的解决状态。

　　5 行政管理：

　　(1)开发人员未解决直接置为Resolve状态的，必须Reopen，不允许这种假解决状况。

　　(2)对于开发人员，对于这种因为无法重现和定位的缺陷，不应牵涉到他们的绩效考核，以避免作假的出现。

　　(3)加强开发人员的质量意识培养。

这是我转的，西西。

小小孩子

　　问题场景：

　　有一些比较严重的BUG随机发生，难以查找规律的，测试工程师提交上去后，有可能会出现以下三个情形：

　　1.开发人员试图重现，重现不出，Reject回来;

　　2.开发人员找不到规律，所以不去解决，问题一直处于Open状态;

　　3.开发人员因为问题难以解决，所以直接Resolved回来，觉得反正是偶发的，先改成解决状态再说。

　　对开发人员、项目经理和测试工程师来说，正确的处理方法应该是怎样的?

　　解决方案：

　　1 缺陷的描述：

　　(1)重现频率：在提交Bug时，记录重现的频率(是、否、随机)

　　(2)现象：测试人员尽可能描述发生的情况并有截图。

　　(3)软件的版本：确认发现BUG程序版本和重现的代码是一致的，可通过tag(Clearcase应该叫Label)或者Revision号来标注。

　　(4)数据：发生错误时的各种变量、内存、存储器等存储的数据内容。

　　(5)环境：软件出错时的软硬件环境。

　　对缺陷的描述应该尽可能的详细。

　　2 缺陷的重现：

　　(1)重现的人员： 缺陷的重现工作，最好由测试人员去完成，一方面，测试人员的文字描述其实很难包括所有的现象信息，让开发人员重现的难度很大，另一方面，测试人员的重现更有说服力和更快捷。

　　(2)重现的次数：每个难重现的缺陷，由发现该缺陷的测试人员连续重复测试300次，如果还不能重现，将缺陷状态改为closed;

　　(3)延长测试时间，努力找到规律。如果市场紧急，由公司级领导特批，相当于高层领导评估风险，就可以先发布软件，但测试和整改继续，留待问题解决后下一版本软件升级;

　　(4) 若确实无法重现，转交项目经理做延迟处理，继续跟踪，若保留一个月都无法重现的，可先关闭，以后重现时再Reopen;

　　3 不可重现的缺陷的处理方法：

　　(1)人工代码走查：无法重现的代码找对系统最熟悉的开发人员重新Review代码，最好是多人一起查。查代码还找不出来，就要检查操作系统、应用服务器及其环境是否有问题，是否有兼容性问题。

　　(2)工具静态检查：采用静态检查工具(如pclint,splint等工具)检查代码，消除所有的error与warning。记住：可能出现问题的地方一定出现问题!

　　(3)换人重新开发相关模块：

　　4 缺陷的记录：

　　(1)开发人员Resolve缺陷的时候要写Revision号，写bug的原因。通过Revision号可以追溯到究竟改了什么内容。写bug原因对开发人员也是一种提高，知其然，也知其所以然。

　　(2)根据紧急程度，放入每日/每周跟踪列表，每次开例会时跟踪问题的解决状态。

　　5 行政管理：

　　(1)开发人员未解决直接置为Resolve状态的，必须Reopen，不允许这种假解决状况。

　　(2)对于开发人员，对于这种因为无法重现和定位的缺陷，不应牵涉到他们的绩效考核，以避免作假的出现。

　　(3)加强开发人员的质量意识培养。

这是我转的，西西。

shwonder

说这个话题之前，先假设有对缺陷评审的相对完善的机制，缺陷能够被准确的评估。再来说缺陷对处理问题。决定一个缺陷被如何处理，我想主要有两个方面的考虑，一是这个缺陷带来的系统风险的大小，另一个是对这个缺陷的修复成本的高低。在同一坐标轴上，这二者构成了四个象限区，如下图：

    在第四象限，带来的风险越大并且修复成本越低的缺陷最能够引起重视，通常会被最及时处理；相反，在第二象限，带来的风险越小但修复成本越高的缺陷，一般很难被快速处理，我们的情况是这类问题放在最低优先级处理。第三象限的缺陷则较第二象限优先处理。最棘手的是第一象限的问题，对于这类问题我们会通过投入人力或时间来解决。
    最后来说偶尔出现缺陷的问题。一般来说，缺陷若出现过一次，则总够通过某些步骤或构造特定测试环境使其再重现出来。因此测试人员要尽可能的保证所提交的缺陷能够被重现出来。为了避免缺陷“偶尔”出现，测试人员在测试过程需要保持清晰的思路，测试执行的过程要可重现（按照测试用例的描述执行），测试环境也要能够重新构造（包括服务器端环境和客户端环境，对系统运行的环境要有记录）。对于不是根据测试用例发现的缺陷，提交缺陷时还需一并描述该缺陷出现的环境及上下文条件。在这样的情况下，若仍发现了偶尔出现的缺陷，则可以按照前面提到的方法对缺陷进行分析，评估该缺陷所属象限，并据此判断是否需要对该缺陷进行持续跟踪。
    另外，遇到这类缺陷的时候也有必要与开发人员做充分的沟通，与开发人员一起分析缺陷可能产生的条件或原因。
    当然了，一定不能有侥幸心理，无论是对于开发人员还是测试人员，都是这样。偶尔出现的缺陷也一定要记录下来。我曾经遇到过测试人员偷懒或者是幸存侥幸心理不提交偶尔出现的缺陷的情况（因为重现困难，怕在开发人员面前出丑或是怕麻烦）。

liaoxj

其实在测试中无法重现的问题很少，只是测试人员没有认真去查！
测试中我们不要很盲目的点击鼠标和敲键盘，做之前先想一下，我发现很多同仁发现不可再现问题时，让他回想前面操作步骤时，都想不清楚。
想一下前面操作步骤，想想前面跟现在环境有没有变化，有没打补丁，有没有打开什么工具，有没有系统属性包括操作系统属性，一起开的邮件，QQ等

[ 本帖最后由 liaoxj 于 2010-4-23 16:59 编辑 ]

pycctv

我们目前做的项目中也会经常出现crash的事件，刚开始的时候也是无法重现，结果导致开发无法定位问题，也无法修改。不过现在好多了，目前在项目中要是再出现crash的事件的话，就会自动生成一个文件，根据这个文件分析是哪个模块出现了问题，比较好定位，从而得到解决。这个办法实施了有一段时间了，效果良好。

jency_moon

主要看影响的程度，一般crash 的问题不能解决的话是不能发布的。

胡靖

新手路过，看见很多高手，不敢发表言论，只有顶一下。