你有没有因为bug无法复现，就悄悄的放过？你有没有因为一些低概率性的bug，对提与不提之间犹豫再三？你可能对低概率性的bug提了，但有没有试图去寻找bug出现的规律并深层次的分析出现的原因？如果低概率bug，测试、开发人员都定位不了原因，无法做修复，那应该怎么处理呢？
不可复现的bug，笔者称之为幽灵bug。可能就是一闪而逝，后面就再也复现不了了。这时我们是不是该放过这个bug，猜测用户可能也只能是如自己这样偶然性的碰到它？
幽灵bug也一定要提。可能我们测试人员限于角度和有限的程序知识而不能定位问题，但把出现bug时的情况尽可能详尽的描述出来（包括当时的测试环境情况，测试机的配置信息，测试数据，出现问题时的前几步操作等），有截图把当时的截图附上，开发人员可能就蛛丝马迹找到问题的根因。
哪怕开发人员不能定位问题原因，那我们也应该后续的测试过程中有意识的关注这个bug是否会再次冒出。如果再次冒出这个问题，尽可能维持当时出问题的状态，如有可能，把相关的开发人员拉过来现场定位问题。
如果在测试整个过程都分析不出原因，那我们也应在最后的测试报告中如实说明情况。相信我，这样的幽灵问题，往往可能会是严重缺陷的表现。忽视它，后面可能会导致自己工作的重大失误，并为此付出沉重代价。这是无数“英勇”的“先驱”们血的经验和教训。
对于低概率的bug，可能大家经常都会在提与不提之间犹豫再三。笔者曾经也这样犹豫过，不过人胆小，最后还是把碰到这样的问题都详尽的提上去了。对于提这种低概率性的bug，笔者也有些傻傻的心得。那就是不停的根据出现的步骤去尝试复现这个bug，然后试图找出出现的规律或出现的概率。这时笔者有了惊奇的发现！
往往低概率的bug有两种情况：
一是确实就是低概率的出现，通过黑盒测试无法定位出问题。这时我们只需要把bug尽可能的描述清楚，同时把出现的概率标明，然后提交给开发进行分析修复。方便时，也可以把开发拉过来，一起来定位问题。
还有种情况，也是大多数的情况，一些低概率性bug是有规律可循的，并且能定位出问题原因的。比如，是不是输入值含有某个特定的字符时出现，是不是输入值超过一个特定长度时出现，是不是在一个特定的时间操作时出现，等等，这些都有可能。而且，当我们确定了出现的规律，往往能定位出问题的原因。如输入的字符串中含有","符号，而程序在做字符串处理时赋予了这个字符特殊的作用，如果没有对输入值做特殊处理，可能就会导致前端应用出现问题。
最后，当测试、开发都不能定位到问题，那bug该怎么处理呢？
笔者通常都会叫团队成员把bug留在那里，在项目测试收尾时，叫上项目经理，开发经理，测试相关人员，开发相关人员对所有这样和其它遗留的bug做一次扫荡（说明bug情况，对bug处理做决定）。
如果有时间，协助开发团队对遗留下的bug做一次集中分析处理，不局限于当时负责的开发和测试人员。如果最终也没修复bug，那应该把这些bug反馈进测试报告中并说明情况，让大家一起权衡是否结束处理这些bug，或暂缓处理这些bug。