Bug的复现机率

　　这个是特别是值得注意的，首先Bug描述上面写的复现机率只是测试人员在当时的现场Bug出现的机率，另外这个也是比较主观的，比如试了三次出一次，有的人认为是必现的，也有的人认为是有一半机率（Above 50%）。

　　但是经过这几年解Bug总结的经验发现，真正的随机出现的Bug只有与线程时序有关的逻辑才会有。其他的随机Bug并不是随机，只可能是测试不太清楚操作步骤和所有的数据或当时的环境现场。

　　如何解决Bug

　　1、弄清楚Bug究竟是什么样的问题

　　拿到Bug后，不要着急去复现，首先要弄明白Bug究竟涉及到哪些行为，哪些操作，当时的现场和环境是什么样的，用了什么样的数据，操作到哪一步出现了问题等等。因为测试人员对Bug的描述是很主观的，可能不太清楚，所以就要与测试人员进行沟通，弄明白这些问题：

　　当时的配置，环境，现场是什么样子的？

　　涉及到哪些行为？

　　进行了什么样的操作？

　　操作到哪一步出现了问题？

　　出现了什么问题？

　　如果说是功能失常，或差劲的用户体验或未实现的行为，那么测试所期待的行为又是什么样子的？

　　测试人员有没有附上日志，截屏或其他调试信息。

　　2、如果Bug是崩溃或异常

　　先不要忙着去复现，因为对于崩溃和异常，日志当中肯定会有崩溃和异常的直接相关信息，通常这就能定位出问题，比如对于Java语言来说如果出现未Handle的异常，那么日志中肯定会有异常相关的信息调用栈等。所以通过日志文件就可以定位出问题出现的源代码。这样就多了一个线索，因为你可以通过源代码来推测是什么导致了这个异常，可能做了什么操作，环境现场发生了什么变化等，通常来讲这比测试人员提供的信息更有参考性。

　　3、如果是差劲的用户体验或是未实现的功能

　　这个要与测试人员进行沟通，甚至是与管理层和设计者进行沟通，如何修改行为或如何实现行为，并且什么时候进行修改等，通常这个开发人员是没有决定权的。

　　4、尝试复现Bug

　　这个步骤也是很有必要的，因为即使你修复了Bug，也是需要复现Bug来进行验证以保证你真正的修复了。所以，如果无法复现Bug那么就说不清是因为一直都没有复现还是被你修复了。

　　如前所述，如果你完全掌握了Bug所发生的条件，相关的操作步骤，那么复现Bug应该很容易，相关的操作步骤应该Bug描述都会有，但是Bug的相关条件（环境，配置，上下文和数据）这些东西可能要去挖掘才能知道，因为测试可能没有注意，也可能忘记添加到Bug描述中去，所以为什么第一步是弄清楚问题。

　　如果是真正的随机问题，那肯定是与线程时序相关的，对于这类问题，发生的原因通常是线程应用不当，产生的Bug也相当的隐蔽。对于这类问题的复现方法是，找到相关的代码逻辑和线程，进行人为的干预，以加大问题出现的机率，比如可以用Thread.sleep（）来阻塞线程，以让其以某种特定的时序来运行，以加大Bug复现的机率。

　　另外，如果难以完全复制Bug出现的条件，比如特定数据或特定的条件等，也可以通过修改代码来实现，比如某一逻辑只有当对象为空的时候才会进，但是99%的情况下它都不为空，且没有合数据让它为空，那么就在代码中直接用空的对象，以复现Bug。