您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 缺陷管理 > 正文

关注缺陷报告的有效性

发表于:2018-06-20 作者:Simon Tatham 来源:网络转载

写过软件的人,大概都收到过很糟糕的缺陷( bug)报告,特别来自用户的报告,而不是专职的测试人员的报告,例如:

●在报告中说“不好用;

●所报告内容毫无意义;

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

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

●所报告的问题是由于错误的操作而产生的;

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

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

这便是为什么“技术支持” 被认为是一件可怕的工作,因为有拙劣的 bug 报告需要处理。我非常希望每一个人在报告 bug之前都读一下这篇短文,当然我也希望用户在给我报告 bug 之前已经读过这篇文章。

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

在 bug 报告里,要设法搞清什么是事实、什么是推测。如果愿意的话,可以省去推测,但是千万别省略事实。

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

1. 程序不好用

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

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

2. 演示给我看

报告 bug 的最好的方法之一是「演示」给程序员看。让程序员站在电脑前,运行他们的程序,指出程序的错误。

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

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

3. 准确地告诉程序员,你做了什么

“演示”是很好的办法,但是常常做不到。如果您必须报告 bug,而此时程序员又不在您身边,那么您就要想办法确切地告诉程序员您做了些什么,让他们能够自己再现 bug。当他们亲眼看到错误时,就能够进行处理了。

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

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

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

同样也要描述发生了什么。精确的描述您看到了什么。告诉他们为什么您觉得自己所看到的是错误的,最好再告诉他们,您认为自己应该看到什么。如果您只是说:「程序出错了」,那等于没说。

如果有错误消息代码,一定要把这些告诉程序员。不要以为您看不出任何意义,它就没有意义。对普通人用语言描述计算机错误,往往不容易,用这种方式告诉您错误的所在是一个最好的办法。有了错误代码,程序员知道什么地方出错了,了解到重要的线索,排错工作会十分高效。。他们不知道发生了什么,也不可能到现场去观察,所以他们一直在搜寻有价值的线索。

5. 出了问题之后,我做了……

当一个错误或 bug 发生的时候,您可能会做许多事情。但是大多数人会使事情变得更糟糕。有人误删了所有的 Word 文件,在找人帮忙之前他重装了 Word,又运行了一遍碎片整理程序,这些操作对于恢复文件制造了巨大的麻烦,因为这些操作搞乱了磁盘的文件区块。如果她不做任何操作,或许还有一线希望。

当程序出毛病的时候,立刻停止正在做的任何操作,仔细地看一下屏幕,注意那些不正常的地方,记住它或者写下来。学着养成一种条件反射——一旦电脑出了问题,先不要动。关掉受影响的程序或者重新启动计算机都不好,最好是能保护“出错”的现场。

6. 我想粒子的跃迁与错误的极化有关

并不只是非专业的用户才会写出拙劣的 bug 报告,我见过一些非常差的 bug 报告出自程序员之手,有些还是非常优秀的程序员。

有一次我与另一个程序员一起工作,他一直在找代码中的 bug,他常常遇到一个 bug,但是不会解决,于是就叫我帮忙。「出什么毛病了?」我问。而他的回答却总是一些关于 bug 的意见。如果他的观点正确,那的确是一件好事。但事实上他常常是错的。这就会使我们花上半个小时在原本正确的代码里来回寻找错误,而实际上问题出在别的地方。

我敢肯定他不会对医生这么做。「大夫,我得了 Hydroyoyodyne 病,给我开个方子」,人们知道不该对一位医生说这些。您描述一下症状,哪个地方不舒服,哪里疼、起皮疹、发烧……让医生诊断您得了什么病,应该怎样治疗。否则医生会把您当做疑心病或精神病患者打发了。

做程序员也是一样。即便您自己的「诊断」有时真的有帮助,也要只说「症状」。「诊断」是可说可不说的,但是「症状」一定要说。同样,在 bug 报告里面附上一份针对 bug 而做出修改的源代码是有用处的,但它并不能替代 bug 报告本身。

测试人员多动动脑筋对程序员的工作是有帮助的。即使您的推断是错误的,程序员也应该感谢您,至少您想去帮助他们,使他们的工作变得更简单。不过千万别忘了报告「症状」,否则只会使事情变得更糟。

7. 真是奇怪,刚才还不好用,怎么现在又好了?

间歇性错误」着实让程序员发愁,也就是我们经常说的,缺陷发生频率不是100%。但大多数「间歇性错误」并不是真正的「间歇」,其中的大多数错误与某些地方是有联系的,只是不知道这些地方(引起bug的错误代码)。有些错误可能是内存泄漏产生的,有些可能是空指针造成的,有些是在特定条件下产生的。

同样,如果您能使 bug 重现,而程序员不能,那很可能程序运行的各自环境(如计算机配置、已安装的软件等)是不同的,这种不同引起了问题。

程序员想要了解任何与您发现的问题相关的事情。有可能的话,到另一台机器上试试,多试几次,两次,三次,看看问题是不是经常发生。如果问题出现在一系列操作之后,不是想让它出现它就会出现,这就有可能是长时间的运行或处理大文件所导致的错误。程序崩溃的时候,要尽可能的记住都做了些什么。

最重要的是:程序员想要确定他们正在处理的是一个真正的「间歇性错误」呢,还是一个在另一类特定的计算机上才出现的错误。他们想知道有关您计算机的许多细节,如程序的版本、操作系统的版本......

小结:

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

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

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

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

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

●详细。信息宁多毋少!如果您说了很多,程序员可以略去一部分,可是如果您说的太少,他们就不得不回过头再去问您一些问题。

●慎用代词。诸如「它」,「窗体」这些词,当它们指代不清晰的时候不要用。

●检查。重新读一遍您写的bug报告,您觉得它是否清晰?如果您列出了一系列能导致程序出错的操作,那么照着做一遍,看看您是不是漏写了一步。

●总的来说,最重要的是要做到精确、表述清楚,确保您的意思不能被曲解。如果做相同的事情有两种方法,请说明您用的是哪一种。