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的终原因通常不是开始列出来的那些,^_^。
  这个方法的灵感来自于美剧《豪斯医生》。豪斯医生在面对每一个疑难杂症的时候,都会集合助手,一一列出任何可能的病因,然后逐个验证和排除。而且我发现的那个现象,这个美剧中也有,是终的病因通常不是他们开始列出来的,这也许是编剧故意制造的戏剧化效果吧,哈哈。