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的流程或步骤：
　　1) 获取当前测试的版本信息；让测试人员通过版本检测工具读取当前测试的版本信息，然后截图。此举，可立即确定是否由于版本不正确导致的问题；
　　2) 读取设备的运行日志；让测试人员读取设备的操作日志和运行日志，交由开发人员解析；
　　3) 通过设备运行监控工具，获取设备当前的运行状态，然后截图；
　　4) 通过抓包工具，抓包并且将结果交由开发人员解析；（可选，只针对网络相关的问题）
　　5) 将获得的所有信息，放到一个文件夹中，以bug现象和测试人员姓名命名该文件夹；
　　这样的步骤或流程一个大的好处是，不会遗漏可用的信息。因此，除非是那种一眼能定位原因的bug以外，对于所有bug我基本上都会按照上述去做的，其实其目的也很简单，在还不清楚问题具体情况的状况下，先尽可能地获得系统的可以获得的所有信息，这些信息会为后续分析提供了可参考的信息。这样做只是麻烦一些，但是没有坏处。曾经有几个很难复现的bug，是由于缺少对应的日志信息，给我们分析问题原因带来了极大的麻烦。当时，对于没有及时获取更多的信息，非常之懊悔。
　　将所有信息都放到一个文件夹中，是一个非常好的习惯，这样所有与之相关的信息非常好找，更不会出现混乱。另外，上述步骤中，我通常都会要截图，一方面是自己不太相信测试人员的口述，另外一方面留下足够的证据，因为有的时候真是口说无凭啊。
　　3. 针对不同类型的bug，适当区别对待
　　开发人员有时候可能同时在分析好几个bug，这要对这些bug分轻重缓急了。我通常将bug按照复现难度分优先级。越容易复现的bug优先级越低，即使该bug的严重等级很高。因为能复现的bug，只要花时间总能够分析出原因的，但是很难复现的bug难说了。其实，bug分析和解决有50%取决于该bug能否复现。因此，每当测试人员告诉一个新bug时，我收集了所有信息，并且分析以后有个初步结论以后，我才会让测试人员破坏环境，让他复现一下（复现bug可能会导致现象消失，但是不去复现也没什么可做的了，毕竟所有的信息都收集完了）。如果这个bug很难复现的话，那么我会先推掉其他事情，专心分析这个bug，否则拖得时间越久，越难找到原因。
　　生命不息，bug不止。面对bug，我们须保持良好的心态，因为它们毕竟已经成为我们工作生活的一部分了，以积极良好的心态面对它们的时候，我们也许能找到比较好的方法解决它们了，^_^
　　【后记】
　　对于模块很多，功能比较复杂的产品，一旦发生bug，一般很难确定bug的原因。这个时候除了尽可能地收集现场信息以外，还一个分析方法。这个方法很简单：首先列出会产生这个bug的所有原因，无论列出的原因听起来，多么不可能，也要列出来，然后逐个去验证和排除，可以先从可能性大或者容易验证（或排除）的入手。这个方法背后的逻辑是：
　　1) 面对一个很复杂的bug的时候，我们实际上面对的是一团漆黑，面对的是巨大的不确定性；
　　2) 人在面对不确定性的时候，会本能地焦虑和慌张；
　　3) “列出会产生bug的所有原因”，实际上是给我们提供了一个“落脚点”，让我们在面对不确定性的时候，觉得有事情可做，觉得有“可以入手”的地方，这样我们在心理上不会那么焦虑和慌张了；
　　4) “无论列出的原因听起来，多么不可能，也要列出来”，目的是不去限制大家的思维，让大家可以自由地思考和分析；
　　5) “逐个去验证和排除每个原因”，目的是尽可能地缩小问题原因的范围；
　　6) “先从可能性大或者容易验证或排除的入手”，这一点符合人类的行为习惯——先易后难。
　　这个方法不能百分之百地保证能够找到bug的原因，但是它给分析bug提供了一个方向，指引我们的思维和行为，为解决bug提供了一个“落脚点”。本人用这个方法帮助公司解决很多棘手的bug，却发现了一个有趣的现象：产生bug的终原因通常不是开始列出来的那些，^_^。
　　这个方法的灵感来自于美剧《豪斯医生》。豪斯医生在面对每一个疑难杂症的时候，都会集合助手，一一列出任何可能的病因，然后逐个验证和排除。而且我发现的那个现象，这个美剧中也有，是终的病因通常不是他们开始列出来的，这也许是编剧故意制造的戏剧化效果吧，哈哈。