说说分析bug的一些心得

bug已经成为程序员工作中的一部分，作为从事嵌入式软件开发已有三年的我，经手的bug也不少了。先说说自己对于bug的心态变化吧，刚开始工作的时候，自己还是很喜欢bug的。那时，自己是负责维护别人的代码，如果发现了bug，说明自己工作有成绩；后来，自己开始码代码，这个时候测试人员告诉我有bug，自己就有些心烦，尤其是当领导知道了这个bug以后，就会感到很大压力；再后来，经手的bug变多了，也变得淡定多了，而且还逐渐建立自己分析bug的工具箱和分析流程；现在，经过几年的工作，积累了一些经验，开始在设计和编码阶段，就尽量考虑周全，以减少bug的产生。
下面就说说自己分析bug的一些心得：
1. 建立一套分析bug用的工具箱 正所谓，“工欲善其事，必先利其器”，分析bug有一套得心应手的工具很重要。我的工具箱里就有：网络抓包工具（用来分析网络相关问题的），读取、解析日志的工具、获取设备运行状态的工具，另外，还配有解压工具、UltraEditor等等小程序的安装程序（因为有些测试用的电脑上没有安装这些软件）。我将这些工具放到一个文件中，并将其放在U盘中，一旦测试人员告知有bug存在，我就揣着U盘过去。这个“窍门”的来历缘于自己一段痛苦的经历，自己有段时间膝盖疼，特别讨厌爬楼梯，但是当时测试人员在开发人员的楼下，因此，常因为测试人员的电脑上没有自己想要的工具，自己不得已只能爬上爬下地用U盘拷贝工具。痛苦之下，就想出了上面的那个办法，呵呵。
2. 建立一套分析bug的流程或步骤 bug产生后，测试人员告诉开发人员的都是现象，而开发人员要根据测试人员的现象描述去推测。我同事说，查bug就像是在“查案”，一层一层抽丝剥茧地在分析“案情”，不能放过任何蛛丝马迹。分析bug有的时候就好比在黑暗中行走一样，常常觉得完全无从下手。经过几次痛苦经历后，我逐渐建立一套分析bug的流程或步骤：
获取当前测试的版本信息；让测试人员通过版本检测工具读取当前测试的版本信息，然后截图。此举，可立即确定是否由于版本不正确导致的问题；
读取设备的运行日志；让测试人员读取设备的操作日志和运行日志，交由开发人员解析；
通过设备运行监控工具，获取设备当前的运行状态，然后截图；
通过抓包工具，抓包并且将结果交由开发人员解析；（可选，只针对网络相关的问题）
将获得的所有信息，放到一个文件夹中，以bug现象和测试人员姓名命名该文件夹；
这样的步骤或流程一个最大的好处就是，不会遗漏可用的信息。因此，除非是那种一眼就能定位原因的bug以外，对于所有bug我基本上都会按照上述去做的，其实其目的也很简单，在还不清楚问题具体情况的状况下，先尽可能地获得系统的可以获得的所有信息，这些信息会为后续分析提供了可参考的信息。这样做只是麻烦一些，但是绝对没有坏处。曾经就有几个很难复现的bug，就是由于缺少对应的日志信息，给我们分析问题原因带来了极大的麻烦。当时，对于没有及时获取更多的信息，非常之懊悔。
将所有信息都放到一个文件夹中，是一个非常好的习惯，这样所有与之相关的信息就非常好找，更不会出现混乱。另外，上述步骤中，我通常都会要截图，一方面是自己不太相信测试人员的口述，另外一方面留下足够的证据，因为有的时候真是口说无凭啊。
3. 针对不同类型的bug，适当区别对待 开发人员有时候可能同时在分析好几个bug，这就要对这些bug分轻重缓急了。我通常将bug按照复现难度分优先级。越容易复现的bug优先级越低，即使该bug的严重等级很高。因为能复现的bug，只要花时间总能够分析出原因的，但是很难复现的bug就难说了。其实，bug分析和解决有50%取决于该bug能否复现。因此，每当测试人员告诉一个新bug时，我收集了所有信息，并且分析以后有个初步结论以后，我才会让测试人员破坏环境，让他复现一下（复现bug可能会导致现象消失，但是不去复现也没什么可做的了，毕竟所有的信息都收集完了）。如果这个bug很难复现的话，那么我会先推掉其他事情，专心分析这个bug，否则拖得时间越久，越难找到原因。
生命不息，bug不止。面对bug，我们须保持良好的心态，因为它们毕竟已经成为我们工作生活的一部分了，以积极良好的心态面对它们的时候，我们也许就能找到比较好的方法解决它们了，^_^