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

默默巫

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

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

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

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

maxwell12

我是一个游戏黑盒测试
我经常能遇到一些能造成客户端崩溃却又无法复现的严重级别bug
一般造成这种情况的原因是:内存地址错误,变量值错误,复杂事件代码处理流程不佳等.
我处理的方法是与程序负责人沟通,增加客户端崩溃信息log或申请使用debug模式进行测试以便抓住bug.
测试部门内部也会利用键盘鼠标操作记录,屏幕录象等工具记录当时的测试环境和输入.
总之,出现过的问题就是问题.不能因为无法复现而不进行处理.这是一个测试人心中的准则.

[ 本帖最后由 maxwell12 于 2010-4-19 17:17 编辑 ]

deanaa

当我们碰到crash或其他问题的时候，首先根据经验判断一下这个问题是否可以重现。如果认为可以重现，那么简单记录当前错误信息后就进行重现。如果判断问题不能重现的话，一般我会按照以下几个步骤处理。
1. 搜集信息。 搜集的信息应该是一切可能和这个问题相关的。一个是程序本身相关的，比如crash时的core文件，相关的日志信息，前面相关的操作等。另一个是系统和硬件信息比如当前的数据库内容，当前的内存，硬盘的情况，当前的网络情况，操作系统的补丁，当前运行的程序列表，等等。
2. 完成信息搜集后，分析可能的原因。很多时候我们会发现一些一开始无法重现的问题，往往都是因为重现步骤没有走到出问题的代码中导致的。盲目的重现问题，既浪费时间，又很有可能破坏了出问题的环境。分析问题时首先自己或是测试团队一起分析，包括可能引发问题的操作等等。如果内部分析没有办法得出可能的原因或重现步骤的情况下，可以让开发人员参与分析。同时在分析的时候一般也是遵循由内及外的方式。首先分析程序本身，然后数据库，然后外部应用接口，操作系统和相关程序，网络，硬件。
3. 测试经理，项目经理和开发经理应该定期审核这些无法重现的问题，根据问题的严重程度以及分析结果适当的安排资源跟踪这些问题。这里有两点注意的地方，一个是需要在后续的测试过程中加入可能的信息搜集方法，比如说提高某程序的日志等级等。另一方面需要指定相应的人员来检查相关的信息。力争做到每一次测试能够对这些无法重现的问题都有进展。
4. 总结和提高。对于最后重现成功的问题，不能简单的关闭，应该把最后的重现过程定期和开发测试人员分享。通过这种方式来提高大家的分析能力，进而减少无法重现BUG的比例和跟踪解决的时间。

woodcraft

我们团队在这个问题上也困扰了很久........现在我的看法如下。

必须坚持的2个原则：
1、任何BUG都必须重视，有些BUG在我们这是小概率的，但是当产品大面积使用后，BUG的爆发可能是很恐怖的！
2、无法重现的BUG是没有意义的。任何BUG的提出，目的是为了解决它，无法重现，往往意味着无法解决。

所以，在遇到小概率问题时，我们做的就是分析它。
1、从应用上分析，如果BUG造成的影响较小，在产品经理允许的情况下，可以先行关闭。
2、如果是严重级别的BUG，特别是crash这种，往往需要组织专项测试进行分析与测试。
（1）、测试人员的操作分析与压力性测试。以期发现具体概率与BUG规律。
（2）、测试人员、开发人员、顾问的脑力激荡讨论，针对发现BUG的操作与专项测试的结果，在实现层面上进行分析与判断，同时也为专项测试提供思路。

但是，往往有些BUG在做完专项测试后还是没有发现规律。目前我们的做法如下：

通过专项测试基本上确认了此BUG的发现概率（基本上没有解决的都是极小概率发生的），在经过同产品经理的REVIEW后，基本上可以在投产的产品中放过，在新品投放后跟踪一段时间（3个月左右），在市场没有反馈的情况下关闭。

CC114

楼上都是高人，说得很好呢。
个人觉得对于比较难重现的BUG，首先我们需要尽可能的去分析原因，比如寻求开发人员或者是架构人员等，如果测试这里实在无法重现，原则上还是需要记录下来，尤其是crash等严重问题。
可记录包括截屏，程序本身的log，操作系统log，如果可能的话甚至保留环境，比如这是一台虚拟机，可以做snapshot等等。
一旦记录为bug，意味着会有一个流程来处理它，有更多的人来看到它，或许有其他相关人员能分析出问题，但是如果不记录这个BUG，意味着就不再有人会去做这样一件事情，给系统带来隐患，和测试的工作相悖。

sxg_feixue

没经验就没有发言权，学习了

蓝色迷走

尽量重现，都想些测试步骤，尽量回忆出出现此问题之前的操作步骤。实在重现不了，与开发人员商量，如果不是很严重的问题暂缓，以后再处理。
养成经常截图的好习惯吧!

晒太阳的耗子

1.遇到问题时，先把自己做过的相关操作回忆一遍，把问题现象，所做操作记录下来，如果有LOG就把问题LOG导出来，自己对问题进行简单复现，如果无法复现先把BUG写出来继续执行任务，不要因为某个问题而耽误任务进度。
2.把发现的问题记录在无规律问题跟踪表内，方便以后跟踪。
3.发邮件知会组内及项目负责人，可以了解他人无没有遇到类似问题，可以提供一些建议，还可以让大家一起跟踪，同时还可以让项目负责人在第一时间此问题的存在，如果问题特别严重，项目负责人会特意安排时间来针对此问题进行复现或者开始来分析此问题。
4.在之后的测试过程中如果做和此问题模块相关的测试时可以稍微对问题进行跟踪。
5.一般严重无规律问题会进行多个版本的跟踪，如果此问题不再出现，会有测试经理来考虑此问题是否关闭。
注：对于已经抓取了log，开发人员能够通过LOG分析出原因，此问题就可以得以解决，开发人员会提供此问题的测试策略，然后针对此问题扩展测试。

[ 本帖最后由 晒太阳的耗子 于 2010-4-22 15:29 编辑 ]

胡靖

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

jency_moon

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

pycctv

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

liaoxj

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

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

shwonder

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

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

小小孩子

　　问题场景：

　　有一些比较严重的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)加强开发人员的质量意识培养。

这是我转的，西西。

namisang

学习，期待更多高人。

qicailingbing

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

测试王国

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

b45993e

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

ME TOO

b45993e

暂时还没碰见过。