软件测试工程师如何有效的提交缺陷报告(2)

发表于:2011-12-26来源:sam作者:sam点击数: 标签:
如果您看到了错误消息,一定要仔细、准确的告诉程序员,这确实很重要。在这种情况下,程序员只要修正错误,而不用去找错误。他们需要知道是什么出

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

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

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

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

  “出了问题之后,我做了……”

  当一个错误或bug发生的时候,您可能会做许多事情。但是大多数人会使事情变的更糟。我的一个朋友在学校里误删了她所有的Word文件,在找人帮忙之前她重装了Word,又运行了一遍碎片整理程序,这些操作对于恢复文件是毫无益处的,因为这些操作搞乱了磁盘的文件区块。恐怕在这个世界上没有一种反删除软件能恢复她的文件了。如果她不做任何操作,或许还有一线希望。

  这种用户仿佛一只被逼到墙角的鼬(黄鼠狼、紫貂一类的动物——译者注):背靠墙壁,面对死亡的降临奋起反扑,疯狂攻击。他们认为做点什么总比什么都不做强。然而这些在处理计算机软件问题时并不适用。

  不要做鼬,做一只羚羊。当一只羚羊面对料想不到的情况或受到惊吓时,它会一动不动,是为了不吸引任何注意,与此同时也在思考解决问题的最好办法(如果羚羊有一条技术支持热线,此时占线。)。然后,一旦它找到了最安全的行动方案,它便去做。

  当程序出毛病的时候,立刻停止正在做的任何操作。不要按任何健。仔细地看一下屏幕,注意那些不正常的地方,记住它或者写下来。然后慎重地点击“确定” 或“取消”,选择一个最安全的。学着养成一种条件反射——一旦电脑出了问题,先不要动。要想摆脱这个问题,关掉受影响的程序或者重新启动计算机都不好,一个解决问题的好办法是让问题再次产生。程序员们喜欢可以被重现的问题,快乐的程序员可以更快而且更有效率的修复bug。

  “我想粒子的跃迁与错误的极化有关”

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

  有一次我与另一个程序员一起工作,他一直在找代码中的bug,他常常遇到一个bug,但是不会解决,于是就叫我帮忙。“出什么毛病了?”我问。而他的回答却总是一些关于bug的意见。如果他的观点正确,那的确是一件好事。这意味着他已经完成了工作的一半,并且我们可以一起完成另一半工作。这是有效率并有用的。

  但事实上他常常是错的。这就会使我们花上半个小时在原本正确的代码里来回寻找错误,而实际上问题出在别的地方。我敢肯定他不会对医生这么做。“大夫,我得了Hydroyoyodyne(真是怪病——译者),给我开个方子”,人们知道不该对一位医生说这些。您描述一下症状,哪个地方不舒服,哪里疼、起皮疹、发烧……让医生诊断您得了什么病,应该怎样治疗。否则医生会把您当做疑心病或精神病患者打发了,这似乎没什么不对。

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

  如果程序员向您询问额外的信息,千万别应付。曾经有一个人向我报告bug,我让他试一个命令,我知道这个命令不好用,但我是要看看程序会返回一个什么错误(这是很重要的线索)。但是这位老兄根本就没试,他在回复中说“那肯定不好用”,于是我又花了好些时间才说服他试了一下那个命令。

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

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

  “间歇性错误”着实让程序员发愁。相比之下,进行一系列简单的操作便能导致错误发生的问题是简单的。程序员可以在一个便于观察的条件下重复那些操作,观察每一个细节。太多的问题在这种情况下不能解决,例如:程序每星期出一次错,或者偶然出一次错,或者在程序员面前从不出错(程序员一离开就出错。——译者)。当然还有就是程序的截止日期到了,那肯定要出错。

  大多数“间歇性错误”并不是真正的“间歇”。其中的大多数错误与某些地方是有联系的。有一些错误可能是内存泄漏产生的,有一些可能是别的程序在不恰当的时候修改某个重要文件造成的,还有一些可能发生在每一个小时的前半个小时中(我确实遇到过这种事情)。

  同样,如果您能使bug重现,而程序员不能,那很有可能是他们的计算机和您的计算机在某些地方是不同的,这种不同引起了问题。我曾写过一个程序,它的窗口可以蜷缩成一个小球呆在屏幕的左上角,它在别的计算机上只能在 800×600 的解析度工作,但是在我的机器上却可以在 1024×768 下工作。

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