软件测试中如何有效地写Bug报告
 

2009-09-18 来源:网络

 

引言

为公众写过软件的人,大概都收到过很拙劣的bug(计算机程序代码中的错误或程序运行时的瑕疵——译者注)报告,例如:

在报告中说“不好用”;

所报告内容毫无意义;

在报告中用户没有提供足够的信息;

在报告中提供了错误信息;

所报告的问题是由于用户的过失而产生的;

所报告的问题是由于其他程序的错误而产生的;

所报告的问题是由于网络错误而产生的;

这便是为什么“技术支持”被认为是一件可怕的工作,因为有拙劣的bug报告需要处理。然而并不是所有的bug报告都令人生厌:我在业余时间维护自由软件,有时我会收到非常清晰、有帮助并且“有内容”的bug报告。

在这里我会尽力阐明如何写一个好的bug报告。我非常希望每一个人在报告bug之前都读一下这篇短文,当然我也希望用户在给我报告bug之前已经读过这篇文章。

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

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

当您报告bug的时候(既然您已经这么做了),一定是希望bug得到及时修正。所以此时针对程序员的任何过激或亵渎的言语(甚至谩骂)都是与事无补的——因为这可能是程序员的错误,也有可能是您的错误,也许您有权对他们发火,但是如果您能多提供一些有用的信息(而不是激愤之词)或许bug会被更快的修正。除此以外,请记住:如果是免费软件,作者提供给我们已经是出于好心,所以要是太多的人对他们无礼,他们可能就要“收起”这份好心了。

“程序不好用”

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

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

本文中提到的都是一些指导方针,没有哪一条是必须恪守的准则。不同的程序员会喜欢不同形式的bug报告。如果程序附带了一套报告bug的准则,一定要读。如果它与本文中提到的规则相抵触,那么请以它为准。

如果您不是报告bug,而是寻求帮助,您应该说明您曾经到哪里找过答案,(例如:我看了第四章和第五章的第二节,但我找不到解决的办法。)这会使程序员了解用户喜欢到哪里去找答案,从而使程序员把帮助文档做得更容易使用。

“演示给我看”

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

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

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

“告诉我该怎么做”

如今是网络时代,是信息交流的时代。我可以点一下鼠标把自己的程序送到俄罗斯的某个朋友那里,当然他也可以用同样简单的方法给我一些建议。但是如果我的程序出了什么问题,我不可能在他旁边。“演示”是很好的办法,但是常常做不到。

如果您必须报告bug,而此时程序员又不在您身边,那么您就要想办法让bug重现在他们面前。当他们亲眼看到错误时,就能够进行处理了。

确切地告诉程序员您做了些什么。如果是一个图形界面程序,告诉他们您按了哪个按钮,依照什么顺序按的。如果是一个命令行程序,精确的告诉他们您键入了什么命令。您应该尽可能详细地提供您所键入的命令和程序的反应。

把您能想到的所有的输入方式都告诉程序员,如果程序要读取一个文件,您可能需要发一个文件的拷贝给他们。如果程序需要通过网络与另一台电脑通讯,您或许不能把那台电脑复制过去,但至少可以说一下电脑的类型和安装了哪些软件(如果可以的话)。

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

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

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

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

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

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

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

火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织