20170714 针对难以重现bug思考

    今天看了老徐的文章《如何重现难以重现的Bug》，里面讲到实际中，当遇到很难复现的bug时，测试人员的处理方式为：

（1）向开发人员寻求帮助来重现bug；

（2）当做一个issue报给开发人员；

这样的做法存在如下问题：

（1）开发人员责任心不够强，不愿意花太多精力去求证这件事情，常见的回复就是：在我这儿没事儿啊，我也重现不了，bug关了吧。结果随后在生产系统上，bug又开始随机出现了。

（2）就跟测试人员不擅长编码和调试一样，开发人员并不擅长找出bug。经过一番尝试以后，他们也找不出什么问题来，常见的回复同第一条是一样的。bug上线后又出现的宿命也是一样的。

    针对上面两点，自己感触最深的是：

（1）自己还是开发的时候，测试将出现一次的问题提了bug，作为开发，每天bug无数，对于这种出现一次，log无效的bug来说，基本的处理方式就如老徐所说，自己复现几遍，若没有复现则打回给测试，让其跟踪（之前公司是跟踪一个月），若还未复现，则关闭bug。有时候就会出现发布后，用户反馈类似的问题，但测试还是未复现，此时才会从代码入手，进行分析，看看究竟是哪里的问题，最后进行修改。

（2）现在自己也是一名测试，也有遇到过出现一次的bug，但是这种情况自己现在都是先回想之前的操作流程，然后不停的进行测试，如果还是复现不了，便会询问开发的实现逻辑，再次进行复现，如果还是复现不了，会先记录下来，到上线的时候重点测试。不知道这样做是否正确……

    无论自己做测试还是做开发，出现难以重现的bug，存在以下几种情况：

（1）测试环境、资源有问题。做开发时，遇到好多问题，就是测试使用已经废弃的资源进行测试（不知道为什么组内人没有告诉组员），导致了很多问题；做测试时，由于是web测试，开发提交了新的代码，未告知测试，导致前一秒还存在的问题，到下一秒就不存在的（这种情况很让人抓狂）

（2）测试步骤不正确，自己也遇到过这种情况，由于测试步骤不完整，导致复现不了

（3）就是复现不了的bug，只能从代码层面去进行分析，这种情况对于测试来说很不好，如果开发去分析（一般都不会去分析，除非问题很严重），那还好说，如果不分析，很多时候这个bug便会不了了之。曾经自己就遇到过一个bug，测试开发都复现不了，但是用户反馈超过100+，后来就是将那个模块的所有代码分析了一遍，才找到问题之所在。

    自己现在也是一名测试，遇到这种情况时，自己的做法也不尽完善，之后根据老徐文章中提到的进行完善补充，多思考，多观察，注意可能复现的条件，然后反复多测试等。