处理BUG就这3个步骤

2018-06-26   出处: 鲁德  作/译者:鲁德  

 回想之前在大厂工作的6年里,基本有一半的时间在处理bug,久而久之形成了处理bug的一套实用的步骤。贯彻这套步骤,即使在解决难度很高的问题,也没有失去方向。

  步骤1,重现问题

  步骤2,寻找问题根源

  步骤3,思考解决方案

  重现问题

  这个步骤里,主要是安照测试人员提交的bug里的描述,在自己的设备上重现问题。一个好的测试人员,不但会描述问题现象,还会描述测试步骤,和测试的前提条件。也有不负责任的测试人员,仅仅留下简单的问题现象的描述。无论是哪种情况,你都要找到重现问题的步骤,如果能在自己的设备上重现那就是最好结果。

  1,要仔细看测试人员的描述,特别是重现步骤;以及她观察到了什么结果,认为是不符合预期的。有的时候可能是测试人员对需求的理解和开发人员不一致,而提出了bug。这个时候需要找产品经理来确认,究竟该是什么样。

  2,问题的前提条件和重现步骤非常关键,只有这样你才能通过调试手段,不断缩小有问题代码的范围。

  3,不要完全相信测试人员的描述。对于测试人员来说,系统就是个黑盒,她做出的一些主观判断可能并不精确,这就需要开发人员批判的看待bug单中的信息,分离出有价值的信息。

  寻找问题根源

  重现问题后,就可以通过调试手段来定位问题所在。不同的问题有不同的调试手段

  1,打断点:这可能是最方便的调试手段了。

  2,打日志

  3,抓取网络包。。。

  不够什么样的调试手段,一定是通过可以观察的现象,给提示信息。以前我做嵌入式的时候,会通过外接LED亮暗灯来提供信息。

  思考解决方案

  问题重现了,通过调试手段也寻找到了问题根源,下面就是考虑如何解决问题了。这里就考察你的老本行,开发的能力了。

  1,因为你改的是老系统,一定要了解清楚之前的运作原理,才能设计方案。

  2,对于设计方案来说,如果影响面特别大,必须告知相关测试。

  3,修改完毕,比较自己设计测试用例,进行严谨的测试。

  特别注意的一点就是,任何一个bug的解决,一定会经历以上3步。常见的误区就是没照这3步来走,失去了做事的条理性。

  老大:昨天分配给你的bug解决的这么样?

  小H:这个部分的代码很复杂。

  老大:那么你知道这是个什么问题吗?

  小H:Bug的描述里说了呀,但是这块的业务代码很复杂,我还在理解。

  老大:那你定位到是那部分代码有问题吗?

  小H:还没有,我还在理解这块业务的代码。

  这种情况就是,以直觉来判断问题点,在尚未确定问题点的情况下,就开始展开针对性的准备工作。

  另外要注意的一点就是,平和的心态对的bug。有人会觉得测试人员没事找茬,开bug就是对自己的人身攻击。承认自己的不完美,争取下次避免同样的问题,才是正确的态度。

  为了让大家能按照步骤来思考,我定了条规矩:解决完一个bug后,必须在bug里按以下板式进行回复

  问题原因:

  解决方案:

  总结(如何避免这样的问题):

  如何确定问题已经解决:

  有没有类似问题:

  影响页面:

  这辈子做好两件事:1,编程;2,理财;


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

登录 后发表评论
最新文章