摘 要：本文简要分析了无法重现的Bug的可能产生原因，包括环境不一致、缺少最准确的描述和浏览器的不当设置。针对这些原因，本文给出了相应的对策。通过这些措施，可以重现许多以前认为不可重现的Bug。
关键词：重现；Bug；环境
在测试人员提交bug后，最不希望看到的结果是它们被标记为INVALID，尽管你坚信这一定是Bug。开发人员查看了bug的Description后，最不希望的结果是你无法重现它们，尽管他使用了所有可能的方法去重现它。一旦出现这样的情况，测试人员会很伤心，开发人员也会对测试人员有意见。这就使得关系本来就不怎么融洽的测试人员和开发人员之间的关系更加紧张。这对于关系紧张的测试人员和开发人员来说，无异于是火上浇油。
为了减少这种情况的出现，非常有必要分析一下Bug不能重现的原因。根据我的测试经验，Bug不能重现的原因有：
一、 环境不一致
这是bug不能重新的最主要的原因。在开发人员认为这是无效的bug 里面，估计至少有80%的Bug是因为环境不一致的原因造成的。这既包括开发环境和测试环境的不一致，也包括开发环境和系统的实际运行环境不一致。
Bug产生是有一定原因的，它的重现也需要一定的环境。如果没有相应的环境，那么你可能很难这个Bug。
从广义上来说，保证或影响系软件的任何因素都是环境。例如，硬件的配置、软件的设置、网络的带宽、网速等。通常，环境中的软件因素有：系统的Build、Application Server的类型和Version、Operation System 的语言和Version、浏览器的语言和Version等。
下面是我的一些有趣的经历：某个Bug 只出现在WebSphere 6.0.2.15上，按照开发人员的要求，把WebSphere升级到6.0.2.17 后，此Bug就自动消失了。因此，此Bug是因为WebSphere的版本不一致引起地。
几个图片在某个Build上莫名其妙地消失了，刚开始怀疑是开发人员修改别的Bug而引起的错误。后来经过仔细认真地测试才发现，原来是操作系统的语言搞的“鬼”：测试人员使用的机器的操作系统语言是简体中文，开发人员使用的是繁体中文。
Bug的Description里面缺少重现bug 的最准确的操作,下图是测试系统在增加一个Role时的页面：
图1：增加Role的页面
测试人员在输入某些数据、然后点击Save后，“一不小心”就出现了java.lang.NullPointerException的错误。说一不小心，是因为这是测试人员在无意中发现了，并且出现这个错误后，你再也无法增加任何Role了（当然也无法重现此Bug了）。最糟糕的是，别的与Role有关的许多功能点也无法验证。尽管不知道为什么发生了这个错误，也无法重现此Bug，但考虑到此Bug的严重性，测试人员还是把此Bug提交到Bug库里去了（事后证明这是非常明智的举动）。
在测试下一个Build的时候，我要求测试人员重点关注此Bug。后来在DBA的帮助下找到了产生此Bug的真正原因：输入Role Code后，如果Role Name为空，页面没有进行检查（前台没有检查）；但点击Save后，数据需要保存到数据库时，Role所在的Table要求Role Code和Role Name都不能为空。因此就出现了java.lang.NullPointerException这个错误信息。
找到此Bug发生的原因后，我建议开发人员把Role Code当作Role Name，如果用户输入Role Code而没有输入Role Name。经过测试，此Bug就再也不会出现了
二、 浏览器的不当设置
对于Web测试来说，IE的设置又是对重现Bug起着重要的作用。下面的几个图片说明了浏览器的几个关键设置：
图2：Internet临时文件的设置
下页链接
图3：“高级”选项的设置
说明：在“高级”选项中，对测试起重要作用的是“禁止脚步调试”（不选择，即前面不要有勾）和“显示每个脚本错误的通知”（选择它，即前面要出现勾）。
这些设置对重现有关脚本错误的Bug起着重要的作用。根据这些脚本错误的通知，开发人员可以快速发现代码中的错误，并及时修复它。
三、 内存泄露
某些系统长期运行后出现运行速度慢、反应迟钝等现象，其中一个主要的原因就是内存泄露。有的开发人员没有养成及时回收内存的习惯，结果系统在不断地申请内存空间，却没有一点内存释放。这类错误在短期内不会出现，但当系统长期运行时就会出现，并且由此会引发一系列的问题。此类问题只有经过长时间的运行测试，才可能会被发现。
四、 函数接口类型不匹配
此类错误难以重现，并且难以发现它的真正原因，一般只有在查看源代码后才能发现。某些类型的数据会被系统自动转换，一般也不会出现错误；但有些数据被截断或被强制转换成另外一种数据类型时，会出现一些潜在的错误。在集成测试时此类错误最有可能发生。
既然分析出了这些Bug不能重现的原因，我们就可以对症下药了：
1. 测试人员要有重视测试环境的意思，并在Bug Report里面增加对测试环境的准确描述，特别是影响重现此Bug的那些环境因素。
2. Bug的Step要准确说明操作步骤。为了重现一个Bug，测试人员可能需要对几个Build进行连续跟踪、测试和定位产生这个Bug的最根本原因。
3. 正确设置浏览器的选项。
4. 对性能有要求的软件或系统一定要进行长期负荷测试(Loading Testing )，以发现内存泄露等需要长期运行才能出现的问题。根据微软的测试经验，如果软件能通过72小时的强力测试，则该软件72小时后出现问题的可能几率微乎其微。因此只需对软件进行72小时的强力测试即可。
5. 集成测试时一定要注意函数接口类型是否匹配。
6. 测试人员要与开发人员、DBA等保持良好的关系。遇到问题要及时、主动与他们沟通，听取他们的意见。在他们的帮助下，你可以更容易地找到问题的关键所在之处。
根据上面的这些建议，我相信大多数不能重现的Bug都可以重现了。当然由于测试的系统的开发语言、开发平台等因素的不同，恕笔者不能一一列举出无法重现的Bug发生所有原因。如果还是遇到某些严重的、却又无法重现的Bug，那么也不必惊慌，你可以按照下面的操作去查找产生Bug的原因：
1. 积极回忆Bug的症状和所有的环境因素，一丝一毫的细节都不要错过。
2. 与开发人员、DBA、系统设计人员、项目经理等一起分析那些环境因素，根据以往的经验分析影响此Bug重现的重要因素，并在相同的环境上安装同样的系统进行测试，以验证所做的猜测。
另外，对于某些无法重现、但严重程度不是很高的Bug，可以暂时只作记录、而不必花费大量的人力和物力去分析。如果下次又出现了，那么根据发生的频率再去分析是否需要跟踪此Bug。如果需要跟踪它，那么在它又出现后一定要立刻对当时的环境进行截图，如错误信息、界面、日志等。这样也利于开发人员定位、分析它，从而准确、快速地修复它。如果条件允许，测试人员应立即保护现有环境，并邀请相关的开发人员和系统分析人员一起研讨产生此问题的原因和解决方法。
