如何对待测试中不能重现的BUG

作者：谢金花

在测试过程中，我们总会遇到一些偶然发生的、不能重现的BUG，或者在测试人员那里可以重现，但是在开发人员处却不能重现的BUG。而且偶然发生的“无法重现”的BUG多半是“计划外”的。无论站在开发人员还是测试人员的角度，都不愿意遇到不能重现的BUG，因为这意味着要花更多的时间去查找原因和修改BUG，甚至短期内无法修复，需等待以后再次出现或许才能解决。

一、一般情况下，BUG不能重现的原因主要有以下几点：

（1）环境不一致

这是BUG不能重现的主要原因之一。在开发人员认为这是无效的BUG里面，估计至少有80%的BUG是因为环境不一致的原因造成的。这既包括开发环境和测试环境的不一致，也包括开发环境和系统的实际运行环境不一致。

BUG产生是有一定原因的，它的重现也需要一定的环境。如果没有相应的环境，那么你可能很难重现这个BUG。

从广义上来说，保证或影响系软件的任何因素都是环境。例如，硬件的配置、软件的设置、网络的带宽、网速等。通常，环境中的软件因素有：系统的Build、 Application Server的类型和Version、Operation System 的语言和Version、浏览器的语言和Version等。

就拿我们某一项目来说：在V1.0.5版本的系统测试中，发现某一模块功能出现问题，将这个问题提交到开发人员处，结果开发人员无法重现这个问题，且在开发人员处，该模块功能正常，查找了原因很久，发现可能是版本升级导致，于是将版本回滚到之前的版本，功能恢复正常。

诸如此类由于环境不一致的原因导致的不能重现的BUG，大部分是在开发人员那不能重现，小部分是在测试人员处偶然出现，找不到规律。所以，这就要求我们测试与开发的环境要分开，测试要有自己的独立环境，且测试环境要保持干净、无毒。

（2）浏览器的不当设置

对于Web测试来说，浏览器的设置又是对重现BUG起着重要的作用。下面的几个图片说明了浏览器的几个关键设置：

说明：在“高级”选项中，对测试起重要作用的是“禁止脚步调试”（不选择，即前面不要有勾）和“显示每个脚本错误的通知”（选择它，即前面要出现勾）。

这些设置对重现有关脚本错误的BUG起着重要的作用。根据这些脚本错误的通知，开发人员可以快速发现代码中的错误，并及时修复它。

下面讲解某一项目中由于浏览器设置引起的bug不能重现的例子：

有次版本发布之后，从领导那边反馈回来一个bug。根据以往流程，我们首先对这个BUG进行验证，可是无论如何都重现不了该BUG，于是找到项目经理，让他重现下该BUG，仍旧不能重现。最后项目经理找到领导，了解其操作过程，才发现其浏览器字体设置为“微软雅黑”，而我们的浏览器字体为默认字体。最后将字体修改为“微软雅黑”后该BUG才重现。

（3）内存泄露

某些系统长期运行后出现运行速度慢、反应迟钝等现象，其中一个主要的原因就是内存泄露。有的开发人员没有养成及时回收内存的习惯，结果系统在不断地申请内存空间，却没有一点内存释放。这类错误在短期内不会出现，但当系统长期运行时就会出现，并且由此会引发一系列的问题。此类问题只有经过长时间的运行测试， 才可能会被发现。

这个问题在我们某一项目中也存在过，由于该项目是采用Java语言开发的，Java可以自动回收内存，这就导致了开发人员对及时回收内存问题的忽略，使用时出现内存泄露。

（4）函数接口类型不匹配

此类错误难以重现，并且难以发现它的真正原因，一般只有在查看源代码后才能发现。某些类型的数据会被系统自动转换，一般也不会出现错误；但有些数据被截断或被强制转换成另外一种数据类型时，会出现一些潜在的错误。在集成测试时此类错误最有可能发生。

二、出现不可重现的BUG时，我们应当本着以下原则，实现BUG的重现工作：

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

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

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

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

三、遇到无法重现的BUG时，我们应该做到如下几点：

（1）一定要提交

把不可重现的BUG记录下来，以后再遇到的时候可能就会了解发生的原因。同时尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。而且程序员对程序比测试人员熟悉的多，因为测试人员看到的只是程序的外部，无法深入程序内部，也许你提交了，即使无法重新，程序员也会了解问题所在。无法重现的问题再次出现后，也可以直接叫程序员来看看问题。

但是针对一些比较严重的、随机发生无法重现的bug，测试人员提交上去后，有可能会出现以下三个情形：a．开发人员试图重现，重现不出，Reject回来；b．开发人员找不到规律，所以不去解决，问题一直处于Open状态；c．开发人员因为问题难以解决，所以直接Resolved回来，觉得反正是偶发的，先改成解决状态再说。

（2）尽量详细的描述缺陷

尽可能的详细记录BUG产生的相关信息；如重现频率，发生情况并有截图，操作步骤，软件的版本，发生错误时的各种变量、内存、存储器等存储的数据内容，软件出错时的软硬件环境等。

（3）由开发人员进行人工代码走查和工具静态检查

无法重现的代码找对系统最熟悉的开发人员重新Review代码，最好是多人一起查。查代码还找不出来，就要检查操作系统、应用服务器及其环境是否有问题，是否有兼容性问题。或者采用静态检查工具（如pclint,splint等工具）检查代码，消除所有的error与warning。

（4）查看是否正确设置浏览器的选项

对于浏览器设置不正确引起的BUG，设置好浏览器选项，就能使BUG重现。

总之，在遇到某些严重的、却又无法重现的Bug，应积极回忆BUG的症状和所有的环境因素，一丝一毫的细节都不要错过。并与开发人员、DBA、系统设计人员、项目经理等一起分析那些环境因素，根据以往的经验分析影响此Bug重现的重要因素，并在相同的环境上安装同样的系统进行测试，以验证所做的猜测。而对于某些无法重现、但严重程度不是很高的Bug，可以暂时只作记录、而不必花费大量的人力和物力去分析。如果下次又出现了，那么根据发生的频率再去分析是否需要跟踪此Bug。如果需要跟踪它，那么在它又出现后一定要立刻对当时的环境进行截图，如错误信息、界面、日志等。这样也利于开发人员定位、分析它，从而准确、快速地修复它。如果条件允许，测试人员应立即保护现有环境，并邀请相关的开发人员和系统分析人员一起研讨产生此问题的原因和解决方法。