bug分析在整个测试阶段是非常容易被忽视的一个点，而就这样的一个被忽视的点真正利用起来之后发现“前辈再也不用担心我掉坑了”

学会分析bug，获取更大破解bug的信息，从质量走向卓越

1. 建立一套分析bug用的工具箱

       正所谓，“工欲善其事，必先利其器”，分析bug有一套得心应手的工具很重要。我的工具箱里就有：网络抓包工具（用来分析网络相关问题的），读取、解析日志的工具、获取设备运行状态的工具，另外，还配有解压工具、UltraEditor等等小程序的安装程序。工具多了，自然分析各种各样的问题起来也就得心应手了

2. 建立一套分析bug的流程或步骤

        bug产生后，测试人员告诉开发人员的一般都是现象，而开发人员要根据测试人员的现象描述去推测。

       而好的测试人员要对bug负责，查bug就像是在“查案”，一层一层抽丝剥茧地在分析“案情”，不能放过任何蛛丝马迹。分析bug有的时候就好比在黑暗中行走一样，常常觉得完全无从下手。而当得到这样的结论之后，再发给开发，此时相信我，站在你面前的开发同学一定泪眼婆娑的看着你，超级感动。

      言归正传，经过几次痛苦经历后，我逐渐建立一套分析bug的流程或步骤：

　　1) 获取当前测试的版本信息；让测试同学通过版本检测工具读取当前测试的版本信息，然后截图。此举，可立即确定是否由于版本不正确导致的问题；

　　2) 读取设备的运行日志；读取设备的操作日志和运行日志，解析后分析结果；

　　3) 通过设备运行监控工具，获取设备当前的运行状态，然后截图；

　　4) 通过抓包工具，抓包并且将结果解析；（可选，只针对网络相关的问题）

　　这样的步骤或流程一个最大的好处就是，不会遗漏可用的信息。因此，除非是那种一眼就能定位原因的bug以外，对于所有bug我基本上都会按照上述去做的，其实其目的也很简单，在还不清楚问题具体情况的状况下，先尽可能地获得系统的可以获得的所有信息，这些信息会为后续分析提供了可参考的信息。这样做只是麻烦一些，但是绝对没有坏处。曾经就有几个很难复现的bug，就是由于缺少对应的日志信息，给我们分析问题原因带来了极大的麻烦。当时，对于没有及时获取更多的信息，非常之懊悔。

　　将所有信息都放到一个文件夹中，是一个非常好的习惯，这样所有与之相关的信息就非常好找，更不会出现混乱。另外，上述步骤中，我通常都会要截图，一方面是自己不太相信测试人员的口述，另外一方面留下足够的证据，因为有的时候真是口说无凭啊。

3.针对不同类型的bug，适当区别对待

       开发人员有时候可能同时在分析好几个bug，这就要对这些bug分轻重缓急了。我通常将bug按照复现难度分优先级。越容易复现的bug优先级越低，即使该bug的严重等级很高。因为能复现的bug，只要花时间总能够分析出原因的，但是很难复现的bug就难说了。其实，bug分析和解决有50%取决于该bug能否复现。因此，每当发现一个新bug时，收集了所有信息，并且分析以后有个初步结论以后，才会破坏环境，

　　生命不息，bug不止。面对bug，我们须保持良好的心态，因为它们毕竟已经成为我们工作生活的一部分了，以积极良好的心态面对它们的时候，我们也许就能找到比较好的方法解决它们了，^_^