量变到质变

2017-06-05   出处:搜狗测试  作/译者:搜狗测试  

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,我们须保持良好的心态,因为它们毕竟已经成为我们工作生活的一部分了,以积极良好的心态面对它们的时候,我们也许就能找到比较好的方法解决它们了,^_^


欢迎给测试窝投稿或参与内容翻译工作,请邮件至editors@testwo.com。也欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,并与我们的编辑和其他窝友交流。
141°|1395 人阅读|2 条评论

原来游去  2017-06-05

哈哈。对的 平时测试过程中遇到一些和网络相关的问题。因为早期测试的时候,开发甩锅给网络环境 测试久了以后,每次遇到新问题,如果我自己判断可能和网络有关,我会抓个网络包,再ping个网络数据。然后把现场画面录下来。并且log抓好。。。这样也避免了开发甩锅,也更好的分析问题


蕾蕾  2017-06-08

我是一个新手测试,想知道如何判断这个bug是属于网络类的问题


登录 后发表评论