对于用户而言，一个产品的好坏不仅仅决定于其产品的功能，而更加在于产品的可靠性及稳定性。小概率BUG则是影响产品可靠性及稳定性的主要因素。而小概率BUG的产生，一般是由于积累操作或多任务并发所引起。哪么在成本及时间等影响产品发布的条件允许的情况下，小概率BUG在产品上遗留的越少，那么产品的质量也更好，用户对产品的体验值可能越高。

　　但实际情况要解决小概率BUG并不乐观。由于小概率BUG发生的概率较小，因此不论是对于开发人员还是测试人员而言，要解决或验证小概率BUG都是一件让人头痛不已的事情。

　　哪么作为测试人员的我们如何把握住这仅有的一次或两次机会，以提供更多的小概率BUG信息给开发人员呢？

　　小概率BUG的多发地带：

　　1． 临界测试

　　2． 中断测试

　　3． 多任务测试

　　4． 积累测试

　　小概率BUG信息的提供：

　　1． 若被测终端提供LOG接口，在测试过程中一定要打开LOG跟踪工具。在BUG发生时提示LOG或图像。

　　2． 若发生小概率BUG，我们应该多做测试或者询问其它同事是否发生类似问题，争取找出其发生的规律。

　　3． 若发生的小概率BUG引发系统崩溃或主要功能无效，应及时通知开发人员。

　　4． 在提交小概率BUG时，一定要详细记录BUG发生的环境，测试步骤及时间点等因素。

　　小概率BUG的验证：

　　1． 小概率BUG的验证应当由发现此BUG的测试人员来进行。

　　2． 若小概率BUG相对轻微，在产品经理确认不必修改时，可以将其关闭或保留。

　　3． 若小概率BUG在验证时再次发生，应及时通知开发人员。

　　4． 小概率BUG连续验证3轮之后没有发生（每轮验证根据BUG的复杂度可分为20-50次），可将其关闭。

　　5． 对于特别严重，而开发人员又束手无策的小概率BUG，在条件允许的情况下，可让开发人员发布T版本来进行测试。

　　6． 对于特别严重的，而开发人员又未确认修改的小概率BUG，可在风险中提出此小概率BUG风险。