• 如何有效地报告Bug?
    时间:2012-10-12   作者:崔康   出处:infoq.com

    自由软件开发者Simon Tatham针对如何有效地报告Bug发表了自己的看法,他列举了一系列拙劣Bug报告的例子,并提出了改正建议。

    Simon首先列举了一系列拙劣Bug报告的例子,包括:

    ■在报告中说“不好用”;
    ■所报告内容毫无意义;
    ■在报告中用户没有提供足够的信息;
    ■在报告中提供了错误信息;
    ■所报告的问题是由于用户的过失而产生的;
    ■所报告的问题是由于其他程序的错误而产生的;
    ■所报告的问题是由于网络错误而产生的;

    接着,他点出了报告Bug的目的:

    简单地说,报告bug的目的是为了让程序员看到程序的错误。您可以亲自示范,也可以给出能导致程序出错的、详尽的操作步骤。如果程序出错了,程序员会收集额外的信息直到找到错误的原因;如果程序没有出错,那么他们会请您继续关注这个问题,收集相关的信息。

    在bug报告里,要设法搞清什么是事实(例如:“我在电脑旁”和“XX出现了”)什么是推测(例如:“我想问题可能是出在……”)。如果愿意的话,您可以省去推测,但是千万别省略事实。

    然后,Simon针对Bug报告的不同问题分别提出了自己的见解:

    “程序不好用”

    程序员不是弱智:如果程序一点都不好用,他们不可能不知道。他们不知道一定是因为程序在他们看来工作得很正常。所以,或者是您作过一些与他们不同的操作,或者是您的环境与他们不同。他们需要信息,报告bug也是为了提供信息。信息总是越多越好。

    许多程序,特别是自由软件,会公布一个“已知bug列表”。如果您找到的bug在列表里已经有了,那就不必再报告了,但是如果您认为自己掌握的信息比列表中的丰富,那无论如何也要与程序员联系。您提供的信息可能会使他们更简单地修复bug。

    “演示给我看”

    报告bug的最好的方法之一是“演示”给程序员看。让程序员站在电脑前,运行他们的程序,指出程序的错误。让他们看着您启动电脑、运行程序、如何进行操作以及程序对您的输入有何反应。

    他们对自己写的软件了如指掌,他们知道哪些地方不会出问题,而哪些地方最可能出问题。他们本能地知道应该注意什么。在程序真的出错之前,他们可能已经注意到某些地方不对劲,这些都会给他们一些线索。他们会观察程序测试中的每一个细节,并且选出他们认为有用的信息。

    这些可能还不够。也许他们觉得还需要更多的信息,会请您重复刚才的操作。他们可能在这期间需要与您交流一下,以便在他们需要的时候让bug重新出现。他们可能会改变一些操作,看看这个错误的产生是个别问题还是相关的一类问题。如果您不走运,他们可能需要坐下来,拿出一堆开发工具,花上几个小时来好好地研究一下。但是最重要的是在程序出错的时候让程序员在电脑旁。一旦他们看到了问题,他们通常会找到原因并开始试着修改。

    “哪儿出错了?在我看来一切正常哦!”

    如果您给了程序员一长串输入和指令,他们执行以后没有出现错误,那是因为您没有给他们足够的信息,可能错误不是在每台计算机上都出现,您的系统可能和他们的在某些地方不一样。有时候程序的行为可能和您预想的不一样,这也许是误会,但是您会认为程序出错了,程序员却认为这是对的。

    同样也要描述发生了什么。精确的描述您看到了什么。告诉他们为什么您觉得自己所看到的是错误的,最好再告诉他们,您认为自己应该看到什么。如果您只是说:“程序出错了”,那您很可能漏掉了非常重要的信息。

    如果您看到了错误消息,一定要仔细、准确的告诉程序员,这确实很重要。在这种情况下,程序员只要修正错误,而不用去找错误。他们需要知道是什么出问题了,系统所报的错误消息正好帮助了他们。如果您没有更好的方法记住这些消息,就把它们写下来。只报告“程序出了一个错”是毫无意义的,除非您把错误消息一块报上来。

    特殊情况下,如果有错误消息号,一定要把这些号码告诉程序员。不要以为您看不出任何意义,它就没有意义。错误消息号包含了能被程序员读懂的各种信息,并且很有可能包含重要的线索。给错误消息编号是因为用语言描述计算机错误常常令人费解。用这种方式告诉您错误的所在是一个最好的办法。

    在这种情形下,程序员的排错工作会十分高效。他们不知道发生了什么,也不可能到现场去观察,所以他们一直在搜寻有价值的线索。错误消息、错误消息号以及一些莫名其妙的延迟,都是很重要的线索,就像办案时的指纹一样重要,保存好。

    如果您使用UNIX系统,程序可能会产生一个内核输出(coredump)。内核输出是特别有用的线索来源,别扔了它们。另一方面,大多数程序员不喜欢收到含有大量内核输出文件的EMAIL,所以在发邮件之前最好先问一下。还有一点要注意:内核输出文件记录了完整的程序状态,也就是说任何秘密(可能当时程序正在处理一些私人信息或秘密数据)都可能包含在内核输出文件里。

    除此之外,Simon还举了其他一些例子,他最后总结到:

    ■bug报告的首要目的是让程序员亲眼看到错误。如果您不能亲自做给他们看,给他们能使程序出错的详细的操作步骤。
    ■如果首要目的不能达成,程序员不能看到程序出错。这就需要bug报告的第二个目的来描述程序的什么地方出毛病了。详细的描述每一件事情:您看到了什么,您想看到什么,把■错误消息记下来,尤其是“错误消息号”。
    ■当您的计算机做了什么您料想不到的事,不要动!在您平静下来之前什么都别做。不要做您认为不安全的事。
    ■尽量试着自己“诊断”程序出错的原因(如果您认为自己可以的话)。即使做出了“诊断”,您仍然应该报告“症状”。
    ■如果程序员需要,请准备好额外的信息。如果他们不需要,就不会问您要。他们不会故意为难自己。您手头上一定要有程序的版本号,它很可能是必需品。
    ■表述清楚,确保您的意思不能被曲解。
    ■总的来说,最重要的是要做到精确。程序员喜欢精确。

    网友留言/评论

    我要留言/评论

    相关文章

    项目相关的10点感悟:作过也参与过一些项目,有成功的,有失败的,以下是在我眼里,认为比较重要的一些点,分享出来,也帮自已理理思路!
    社交网络心得50条:金鹏远,1968书吧老板,社交网络实践者
    Fab CEO:我在创办4家公司中学到的90件事:本文来自创意闪购网站Fab的CEO Jason,发表于他的个人博客Betashop。本文中他谈了在创办4家(科技)公司的过程中学到的一些事情,特别总结了Fab从一个同性恋网站转型到现在创意闪购网站过程中学到的一些经验。这些经验对于创业者、投资人、行业从业者都具有很大参考价值。
    主动消费和被动消费:由于工作原因,以下我所说的话只能停留在“道”的层面上,没有具体的做法和实际案例,内容较“虚”。如果您想看到具体的实在的操作层面内容,请止步。
    淘宝校招鸡蛋篮子算法题标准答案:又到一年校招时,阿里集团虽然今年休养生息,缩紧招聘,但是现在继续开放校招,不过只招a类学生,也就是重点学校的最优学生(面试官认为),以往多半是研究生居多,本科生录用比率减少,但是编程逻辑思维好的学生仍然是不多的,这是去年出的一道原创题和它的标准答案,做对的人非常少。
    铁道部新客票系统设计(三):最近只是一时兴起,觉得无聊,正好要到买票的时候,写了这个一系列文章,首先是对自己这些年来的工作经验的总结,其次是把分布式事务性系统的设计思想进行分析和整理,最后也就是和想集大家的智慧,讨论系统的设计。我不是铁道部的工程师,我只是一家互联网金融类公司的屌丝工程师,级别不高,能力也一般,就是喜欢技术而已。
    铁道部新客票系统设计(二):在上一篇文章中《铁道部信客票系统设计(一)》里面,探讨了关于数据库层面的功能性需求以及非功能性的需求,在非功能性需求里面,一博主 提出了没有考虑到峰值的情况,这一点的确漏掉了,因为我们铁道部的特殊需求,在春运期间负载很大,平时可能一般,如果用考虑最大的情况,则回存在浪费的情况,如果考虑不足,就像网络订票一样,苦逼。就好比 铁道部春运的时候,发车量大,但是如果制造大量列车,平时就空闲了,也就很亏。机器的折旧很是块的。春运期间可以考虑紧急扩容来实现,所以从设计上可以保持这种扩展性。 扩容是一项工程,整体来说比较复杂。
    优秀的用户体验设计师应该做好的五件事:一大早又梦到了南开中学。一如既往的回到那里见了老朋友,然后一起去后街淘打口磁带和杂志。梦境中的情节没有让当时的自己感到哪怕一点点的时空穿越,只觉得一切都很真实而正常,反倒是醒来之后感到眼前这一切有些突兀,空白了几秒才想起自己正躺在哪里。
    陈一舟荐文:顶级优秀的产品经理如何从TOP 10%跻身TOP 1%:每个备受推崇的产品背后,是顶级优秀产品人的创新精神和执行力。今天,人人网CEO陈一舟回复了人人网一位员工同学的邮件——关于创新和专业学习,并推荐 Quora 上的一篇文章《顶级优秀的产品经理如何从TOP 10%跻身TOP 1%》。
    铁道部新客票系统设计(一):这几天正好看到一条新闻 铁道部:新客票系统2015年建成 ,正好最近想整理和总结一下这几年的工作中的收获,正好可以借这个机会,尝试设计一下铁路客票系统,把自己所学全部用到这个系统中去,顺便也希望各位猿们拍砖,一起探讨一下设计,技术吗,讨论讨论总是有点收获的,总比一个人在那里看书好。