关于那些难以重现的bug，相信每个测试人员都会碰到。它们让我爱恨交加。爱它是因为我相信它是确实存在且有价值的。恨它是因为我无法让别人相信我的描述，或者即使他们相信，也因无法追踪到它而束手无策。眼见为实，一个难以重现的bug是对测试者的考验。
要相信难以重现的bug后必然有一个原因
为什么我不说“不能重现的bug”，而要说“难以重现的bug”呢？因为至少对我而言，我绝对相信有些什么地方是有问题的。我通常都怀着这样的强烈的信念和信心，去逐步排查可能引起问题的因素。有时测试人员和开发人员兵分两路，一个从代码、数据库的角度去分析，一个从界面操作的入口、步骤、数据分析，往往能互相启发，把问题限定在某个范围内，从而更有可能更快地找到原因。你也许记不清楚你刚才每一步的操作步骤，但你可能记得你肯定没有进行的操作。你也许不小心在一个有问题的数据上又做了别的操作，但这个数据应该留有某些特征可以分析。你也许是唯一见证过bug的人，但你的描述和分析可以帮助其他人也相信这样的问题存在的可能性。
难以重现的bug必须记录，而且优先级不能为“低”
“必须记录”这一点大家可能比较容易有共识，但以前我和我所在的项目组有一个认识的误区，认为那些难以重现的bug优先级不高，因为用户可能碰到的概率也不大。现在我改变了这种想法，也在项目组中推广这样一种理念“难以重现的bug的优先级反而是高的”。这是因为通常而言，难以重现的bug搁置得越久，被重现出来的可能性越低。随着时间的推移，当测试版本被更换，测试数据被修改，测试人员已经想不起来当初前前后后都做过些什么操作，一个bug被重现的可能性已经大大降低。所以，当这样一个让人丈二和尚摸不着头脑的bug灵光一现的时候，如果测试人员发现自己重现不了，要做的就是马上找到相关的开发人员来勘探现场，把所有的细节都告诉他，并和他一起来分析和尝试重现。
难以重现的bug根据严重程度决定分配多少资源去尝试重现
难以重现的bug的严重程度各有不同。有些bug不那么重要，也难以重现，我们可以酌情先记录，并花一些时间去重现，若实在没有办法，可以再等一个release用户也没有报，我们也再也没有碰到过后关闭它。而对于一些系统级的bug或者会block用户操作的bug，即使难以重现，也应该群策群力，花力气去尝试重现。
借用一些工具帮助我们重现那些难以重现的bug
测试人员有自己的好帮手。如BB TestAssistant（简单直观）, TestExplorer（能够和Test Director集成，并提供系统级别的如CPU, MEM等信息）, Wink (开源)，或者借用一些更通用的屏幕抓取工具Macromedia Captivate来记录下日常测试的过程，从而在发现可疑问题的时候能够准确回放当时的数据和步骤。
对于底层的bug，我们有一些可爱的developer，总是能找到一些小工具。他们在我报告了一个系统级难以重现的问题后，就会到我的机器上来安装一些这种小工具，期待下一次当我又和这样的问题狭路相逢时，工具能记录下更多细节的线索帮助我们找到问题的方向。这样成功的案例还真不少。
世上无难事，只怕有心人。在所有影响的因素都不变的前提下，世上无不能重现的bug。让我们以饱满的信心、睿智的大脑、亲密的团队合作、合适的辅助工具去把它们揪出来！
版权声明：本文出自zdlzx的51Testing软件测试博客：http://www.51testing.com/?56882
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
