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的最终原因通常不是最开始列出来的那些,^_^。

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

【参考文献】:

1. 美剧《豪斯医生》

本站以现代、古代情诗为主,情诗网创办于2013年,以原创爱情诗歌、经典情诗、现代情诗、古代情诗、英文情诗、情诗绝句为主并收集古诗、古诗词、诗歌大全、诗词名句的文学门户。方便您下次继续阅读;可以放在浏览器的收藏夹中(快捷键Ctrl+D);或者看到喜欢或者有趣的诗词可以通过分享按钮给你的好友分享;情诗网是目前最全情诗大全网站之一。并欢迎广大诗歌爱好者阅览投稿!喜欢本站的话请大家把本站告诉给你朋友哦!地址是 www.qingshiwang.com !