如何写一篇好的bug报告
作者:网络转载 发布时间:[ 2013/7/25 14:55:59 ] 推荐标签:bug
在这里我会尽力阐明如何写一个好的bug报告。我非常希望每一个人在报告bug之前都读一下这篇短文,当然我也希望用户在给我报告bug之前已经读过这篇文章。
在bug报告里,要设法搞清什么是事实(例如:“我在电脑旁”和“XX出现了”)什么是推测(例如:“我想问题可能是出在……”)。如果愿意的话,您可以省去推测,但是千万别省略事实。
“程序不好用”
程序员不是弱智:如果程序一点都不好用,他们不可能不知道。他们不知道一定是因为程序在他们看来工作得很正常。所以,或者是您作过一些与他们不同的操作,或者是您的环境与他们不同。他们需要信息,报告bug也是为了提供信息。信息总是越多越好。
本文中提到的都是一些指导方针,没有哪一条是必须恪守的准则。不同的程序员会喜欢不同形式的bug报告。如果程序附带了一套报告bug的准则,一定要读。如果它与本文中提到的规则相抵触,那么请以它为准。
“演示给我看”
报告bug的好的方法之一是“演示”给程序员看。让程序员站在电脑前,运行他们的程序,指出程序的错误。让他们看着您启动电脑、运行程序、如何进行操作以及程序对您的输入有何反应。
这些可能还不够。也许他们觉得还需要更多的信息,会请您重复刚才的操作。他们可能在这期间需要与您交流一下,以便在他们需要的时候让bug重新出现。他们可能会改变一些操作,看看这个错误的产生是个别问题还是相关的一类问题。如果您不走运,他们可能需要坐下来,拿出一堆开发工具,花上几个小时来好好地研究一下。但是重要的是在程序出错的时候让程序员在电脑旁。一旦他们看到了问题,他们通常会找到原因并开始试着修改。
“告诉我该怎么做”
如果您必须报告bug,而此时程序员又不在您身边,那么您要想办法让bug重现在他们面前。当他们亲眼看到错误时,能够进行处理了。
把您能想到的所有的输入方式都告诉程序员,如果程序要读取一个文件,您可能需要发一个文件的拷贝给他们。如果程序需要通过网络与另一台电脑通讯,您或许不能把那台电脑复制过去,但至少可以说一下电脑的类型和安装了哪些软件(如果可以的话)。
“哪儿出错了?在我看来一切正常哦!”
同样也要描述发生了什么。精确的描述您看到了什么。告诉他们为什么您觉得自己所看到的是错误的,好再告诉他们,您认为自己应该看到什么。如果您只是说:“程序出错了”,那您很可能漏掉了非常重要的信息。
特殊情况下,如果有错误消息号,一定要把这些号码告诉程序员。不要以为您看不出任何意义,它没有意义。错误消息号包含了能被程序员读懂的各种信息,并且很有可能包含重要的线索。给错误消息编号是因为用语言描述计算机错误常常令人费解。用这种方式告诉您错误的所在是一个好的办法。
如果您使用UNIX系统,程序可能会产生一个内核输出(coredump)。内核输出是特别有用的线索来源,别扔了它们。另一方面,大多数程序员不喜欢收到含有大量内核输出文件的EMAIL,所以在发邮件之前好先问一下。还有一点要注意:内核输出文件记录了完整的程序状态,也是说任何秘密(可能当时程序正在处理一些私人信息或秘密数据)都可能包含在内核输出文件里。
“出了问题之后,我做了……”
这种用户仿佛一只被逼到墙角的鼬(黄鼠狼、紫貂一类的动物——译者注):背靠墙壁,面对死亡的降临奋起反扑,疯狂攻击。他们认为做点什么总比什么都不做强。然而这些在处理计算机软件问题时并不适用。
当程序出毛病的时候,立刻停止正在做的任何操作。不要按任何健。仔细地看一下屏幕,注意那些不正常的地方,记住它或者写下来。然后慎重地点击“确定” 或“取消”,选择一个安全的。学着养成一种条件反射——一旦电脑出了问题,先不要动。要想摆脱这个问题,关掉受影响的程序或者重新启动计算机都不好,一个解决问题的好办法是让问题再次产生。程序员们喜欢可以被重现的问题,快乐的程序员可以更快而且更有效率的修复bug。
“我想粒子的跃迁与错误的极化有关”
有一次我与另一个程序员一起工作,他一直在找代码中的bug,他常常遇到一个bug,但是不会解决,于是叫我帮忙。“出什么毛病了?”我问。而他的回答却总是一些关于bug的意见。如果他的观点正确,那的确是一件好事。这意味着他已经完成了工作的一半,并且我们可以一起完成另一半工作。这是有效率并有用的。
做程序员也是一样。即便您自己的“诊断”有时真的有帮助,也要只说“症状”。“诊断”是可说可不说的,但是“症状”一定要说。同样,在bug报告里面附上一份针对bug而做出修改的源代码是有用处的,但它并不能替代bug报告本身。
用户多动动脑筋对程序员的工作是有帮助的。即使您的推断是错误的,程序员也应该感谢您,至少您想去帮助他们,使他们的工作变的更简单。不过千万别忘了报告“症状”,否则只会使事情变得更糟。
“真是奇怪,刚才还不好用,怎么现在又好了?”
大多数“间歇性错误”并不是真正的“间歇”。其中的大多数错误与某些地方是有联系的。有一些错误可能是内存泄漏产生的,有一些可能是别的程序在不恰当的时候修改某个重要文件造成的,还有一些可能发生在每一个小时的前半个小时中(我确实遇到过这种事情)。
程序员想要了解任何与您发现的问题相关的事情。有可能的话您到另一台机器上试试,多试几次,两次,三次,看看问题是不是经常发生。如果问题出现在您进行了一系列操作之后,不是您想让它出现它会出现,这有可能是长时间的运行或处理大文件所导致的错误。程序崩溃的时候,您要尽可能的记住您都做了些什么,并且如果您看到任何图形,也别忘了提一下。您提供的任何事情都是有帮助的。即使只是概括性的描述(例如:当后台有EMACS运行时,程序常常出错),这虽然不能提供导致问题的直接线索,但是可能帮助程序员重现问题。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11