认识达内从这里开始

我们在进行软件测试结果汇报的时候，为了能够提高办事效率，很多时候都是口头表达一些问题，方便解决，但是如果时间不足的话，通过书面形式进行汇报也是可以的。

今天，我们就一起来了解和学习一下，在进行书面汇报软件测试结果反馈的时候，应该有哪些内容是需要汇报的，下面我们就一起来了解一下具体内容。

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重现，而程序员不能，那很可能程序运行的各自环境(如计算机配置、已安装的软件等)是不同的，这种不同引起了问题。

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

作/译者：SimonTatham

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!