对于用户而言，一个产品的好坏不仅仅决定于其产品的功能，而更加在于产品的可靠性及稳定性。小概率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风险。