在实际工作中我们会看到这样2个现象：
1、同样的bug，不同的测试描述出来，解决的结果不同。
2、一些无法被解决的偶现Bug在好几个版本过后又得到了解决 。
解决后跟开发的沟通中了解到，是因为当时没有找到毕现的规律所以无法解决。
通过这两个现象告诉我一个道理，那就是：让Bug百分百毕现很有必要。
今天我们就来讨论下如何找到能让Bug 100%毕现的规律。这种能力是我们测试所需要的。
Bug毕现的重要性：
Bug毕现的步骤可以提交开发效率，从而提高生产产品的效率，更好的保证质量。虽然我们不知道代码是如何设计的，但是我们可以帮助开发找到触发Bug的条件。
我们都知道，目前在工作中，Bug是以100%毕现和非毕现（经常复现和偶尔复现）两种状态存在的。但我始终坚信：没有非毕现的Bug，只是我们没有找到能够让他100%毕现的规律。
Bug毕现的三种方法：
一、逆向推理法
首先要做的就是逆向推理，从时间最近的一次开始逆推，回想这段时间发生的事情（自己的操作，以及在操作期间其他程序或功能对其的影响），而不仅仅只是自己的操作。尽量在最短的时间将现场还原（这就需要在测试的过程中要“用心”，）
可能有人问了，回想的“这段时间”是多久？
1、容易复现的Bug，一般从本条用例开始操作到Bug出现就可以找到毕现的规律。
2、较难复现的Bug，一般就需要追溯到上一条用例执行的操作或者结果。
除了回想自己的操作，为什么还要留意一些别的事情？
根据经验而言，一般不容易复现的Bug就是因为在复现Bug的同时忽略掉了其他程序对其本身操作的影响。
注：要想在最短的时间将现场还原，一定要注意细节，不要放过任何一个可能的细节。
二、反复尝试法
在经历了逆向推理之后，我们要做的就是“不断尝试”。
为什么要不断的尝试呢？根据逆向推理尝试一两次不行吗？我想说的是：如果你能保证操作过程中的任何一个细节都考虑到了，并且都尝试了，那么就不用不断尝试了。
1、不断的尝试是对现场还原的一种帮助，有的时候我们记忆的时候对细节记忆的不是很清晰，只有不断的尝试，不断的找感觉，才能真正的做到现场还原。
2、避免被表面现象所迷惑，发现一个Bug之后不要立即就提交Bug，可以反复多试几次，看看按照自己的操作是否可以100%毕现，如果可以毕现，说明我们找到了此Bug毕现的规律。（反复尝试可以帮助我们抓住Bug产生的本质性原因）
原则是：提交的Bug尽量让其100%毕现
三、判断猜测法
判断猜测法需要建立在对产品的深度理解的基础上。我们需要根据对产品的深度理解，再结合相关测试经验进行“关联猜测”，然后根据猜测的操作进行实践。
猜测点：模块交互部分（一级模块之间的交互、子模块与一级模块之间的交互均需考虑）、状态改变部分、用户角色转换部分等
总之：只要是有变化的部分，就要考虑其变化对程序带来的影响。
文章来源：51testing