测试工程师如何有效地报告缺陷(Bug)

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

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

　　在报告中说“不好用”;

　　所报告内容毫无意义;

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

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

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

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

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

　　接着，他点出了报告Bug的目的：

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

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

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

　　“程序不好用”

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

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

　　“演示给我看”

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

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

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

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

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

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

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

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

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

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

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

　　bug报告的首要目的是让程序员亲眼看到错误。如果您不能亲自做给他们看，给他们能使程序出错的详细的操作步骤。

　　如果首要目的不能达成，程序员不能看到程序出错。这就需要bug报告的第二个目的来描述程序的什么地方出毛病了。详细的描述每一件事情：您看到了什么，您想看到什么，把错误消息记下来，尤其是“错误消息号”。

　　当您的计算机做了什么您料想不到的事，不要动!在您平静下来之前什么都别做。不要做您认为不安全的事。

　　尽量试着自己“诊断”程序出错的原因(如果您认为自己可以的话)。即使做出了“诊断”，您仍然应该报告“症状”。

　　如果程序员需要，请准备好额外的信息。如果他们不需要，就不会问您要。他们不会故意为难自己。您手头上一定要有程序的版本号，它很可能是必需品。

　　表述清楚，确保您的意思不能被曲解。

原文转自：http://www.ltesting.net