游戏测试 如何有效地报告 Bug

为群众读过app的人，大约都收到过很荒缪的Bug（电子计算机程序编码里的错误或程序运行中的缺陷——译者注）报告，比如：

在报告上说“不好用”；所报告具体内容毫无价值；在报告中客户没给予充足的信息；在报告中带来了错误信息；所报告的问题就是因为客户的过错而引起的；所报告的问题就是因为别的程序的错误而引起的；所报告的问题就是因为互联网错误而引起的；这正是为何“服务支持”被称之为一件令人害怕的工作中，由于有荒缪的Bug报告需要解决。

但是并非所有的bug报告都令人厌恶：我在业余时间维护保养自由软件，有时候我能接到很清晰、也有帮助而且“有具体内容”的Bug报告。

在这儿我能竭尽全力表明要怎么写一个好的Bug报告。

我十分希望每一个人们在报告bug之前都读一下这篇短文，自然真心希望客户在帮我报告bug之前就已经看过本文。

简单来说，报告bug的目的在于让程序员见到程序的错误。

大家可以亲身示范性，还可以得出能造成程序出错、详细的操作流程。

假如程序出错了，程序员会搜集额外信息直至寻找错误的主要原因；假如程序并没有出差错，那他们会请你持续关注这种情况，搜集有关的信息。

在bug报告里，要想方设法弄清哪些是真（比如：“我在电脑上旁”和“XX出现”）什么叫推断（比如：“我思考问题有可能是存在于……”）。

如果愿意得话，大家可以省掉推断，可是千万不要省去客观事实。

当你报告bug的情况下（那么既然您早已这样做了），一定是期待bug获得立即调整。

因此这时对于程序员的所有偏激或玷污的话语（乃至辱骂）都是和事无补的——因为这个有可能是程序员的错误，也可能是你的错误，或许您有权利对她们发脾气，可是如果你能够多提供一些有益的信息（而非气愤之词）也许bug能被更快地调整。

除此之外，一定要记住：假如是专业软件，创作者发放给己经出于好意，因此如果很多的人对她们失礼，她们可能要“收拢”这一份好意了。

“程序不好用”程序员并不是智障：假如程序一点都不好用，他们并不并不清楚。

根本不知道一定是因为程序在他们眼中工作中的很正常的。

因此，或者您作过一些和他们不一样操作，或是是你的自然环境和他们不一样。

他需要信息，报告bug其实是为了给予信息。

信息一直愈多愈好。

很多程序，尤其是自由软件，会发布一个“已知bug目录”。

如果你寻找的Bug在列表里有了，那么就不用再报告了，可是如果你觉得自己把握的信息比页面上丰富，那无论如何都要和程序员联络。

您所提供的信息可能会让她们更方便地修复bug。

文中中指出的都是一些指导方针，并没有哪一条是一定要遵守的原则。

不同类型的程序员会喜欢不一样方式的Bug报告。

假如程序附加了一套报告bug的规则，一定需读。

它可能与文中中提到标准相排斥，那你就要以它为标准。

如果你并不是报告bug，反而是求助，您应当表明您当初到在哪里过回答，（比如：我看了第四章和第五章的第二节，但找不着解决的方法。

）这时候使程序员掌握客户喜爱到哪去寻找答案，从而使得程序员把帮助文件做的比较容易应用。

“演试让我看”报告bug的最好的办法之一是“演试”给程序员看。

让程序员立在电脑前面，运作他的程序，强调程序的错误。

让她们看见您启动电脑、运作程序、怎样来操作及其程序对你的键入有什么反映。

他们对于自己写的手机软件了然于胸，大家知道什么地方不容易出现问题，而什么地方最有可能出现问题。

她们下意识地了解需要注意什么。

在程序确实出差错以前，她们或许已经留意到一些地方不太对，这样就会给他一些案件线索。

他们也会观查程序检测中的每一个细节，而且挑选出在他们看来有益的信息。

这种很有可能不够。

或许他们会觉得还需要更多信息，会请你反复刚刚操作。

他们也许在此期间必须与你交流一下，确保在她们需要时让bug再次发生。

他可能会更改一些实际操作，看一下这个错误的形成是某些原因还是有关的一类难题。

如果你不走运，她们可能还需要坐下，取出一堆开发环境，用上几小时来好好研究一下。

不过最主要的是在程序出错情况下让程序员在电脑上旁。

一旦她们看见了难题，她们一般会找出原因并迅速尝试改动。

“告诉我该怎么办”如今已是互联网时代，是信息沟通的时期。

我能点一下电脑鼠标将自己的程序送至俄国某个好朋友那边，自然他还可以用一样最简单的方法帮我一些建议。

可是如果我的程序出了什么问题，我不可能在他旁边。

“演试”是非常好的方法，可是经常没法做到。

如果你务必报告bug，而这时程序员又没有在您身旁，那么你就要想办法让bug再现在他们面前。

当她们亲眼看见错误时，就可以进行解决了。

确切地告诉程序员您做了些哪些。

如果是一个用户界面程序，告诉她们您按到哪一个按键，按照什么顺序按的。

如果是一个cmd程序，精准的告诉她们您输入了什么命令。

您应当尽量详细的给予您所输入的指令和程序反应。

把您想得到的每一个输入方式都告诉程序员，假如程序要获取一个文档，您可能还需要发一个文件信息复制给他。

假如程序必须通过网络与另一台电脑通信，您也许不要把那台电脑复制以往，但起码能说一下计算机的种类和装上哪些软件（有机会的话）。

“哪里出错了？

我认为一切正常哦！

”如果你给程序员一长串键入和命令，她们实行之后没有看到错误，这是因为您并没有给他充足的信息，很有可能错误并不是在每件电脑中都出现了，您的软件很有可能和他的在一些地方不一样。

有时程序的举动很有可能和你预期的不一样，这或许是误解，但您会以为程序出错了，程序员却觉得这是正确的。

同时也要叙述发生什么事。

精准的叙述您看到了什么。

告诉他们为什么您觉得自身能看到的是错误的，最好是再告诉她们，您觉得自己该看见什么。

如果你而是说：“程序出错了”，那你很有可能漏掉了至关重要的信息。

如果你看见了错误信息，一定要仔细、精确的告诉程序员，这确实至关重要。

在这样的情况下，程序员只需调整错误，而不必去找错误。

他需要知道是什么出问题了，系统软件已报的错误信息恰好拯救了她们。

如果你没有更好的办法记牢这种信息，把这些记录下来。

只报告“程序出了一个错”是没有意义的，除非是您把错误信息一块报上来。

情况下，若是有错误信息号，一定要把这种号告诉程序员。

别以为您看不出来任何意义，他就毫无意义。

错误信息号包括了会被程序员了解的各类信息，而且极有可能包括极为重要的案件线索。

给错误信息序号是由于用语言描述电子计算机错误经常匪夷所思。

通过这种方式告诉您错误的所属是一个有效的方法。

在这样的情况下，程序员的排错工作十分效率高。

根本不知道发生什么事，也不太可能去现场来观察，因此他们一直在寻找有意义的案件线索。

错误信息、错误信息号以及一些无缘无故的延迟时间，都是非常重要的案件线索，如同审理案件后的指纹识别一样重要，保留好。

如果你应用UNIX系统软件，程序可能产生一个核心导出（coredump）。

核心导出是非常有益的线索来源，别扔掉了他们。

另一方面，大部分程序员不太喜欢接到含有较多的核心输出文件的EMAIL，因此在发送邮件以前一定要先问一下。

还有一点需要注意：核心输出文件展示了完备的程序情况，换句话说一切隐秘（很有可能那时候程序正在处理一些个人信息或隐秘数据信息）都会包含于核心输出文件里。

“出现了问题以后，我做了……”当一个错误或bug发生的时候，您可能做很多事情。

但是大部分人要使事儿变得更糟糕。

我的一个朋友在校园里误删除她每一个Word文件，在找人之前她重新安装了Word，又运作了一遍碎片整理程序，这种操控针对恢复数据是毫无好处的，所以这些实际操作弄乱了硬盘文件区块链。

也许在这个世界没有一种反删除软件可以恢复她文件了。

她要是不做任何实际操作，或许还有一线希望。

这类客户好像一只被逼到墙角的鼬（黄鼬、紫貂一类的小动物——译者注）：靠着墙面，坦然面对的来临奋发反攻，疯狂攻击。

在他们看来做些什么远比什么事都不做强。

但是这些在解决计算机技术问题的时候并不适合。

不能做鼬，做一只羚羊。

当一只羚羊应对料想不到的现象或受惊吓时，他会一动不动，就是为了不吸引住一切留意，此外也开始思考解决问题最好是方法（假如羚羊有一条服务支持热线电话，这时占线。

）。

随后，一旦它找到最安全行动方案，它就去做。

当程序有问题时，马上终止正在进行的所有实际操作。

不必按一切健。

仔细地看一下显示屏，留意这些不正常地区，记牢它或是记录下来。

之后谨慎地点一下“明确” 或“撤销”，选择一个最安全。

试着培养一种条件刺激——一旦计算机出现了问题，先不要动。

若想解决这种情况，关闭受影响的程序或是重启电子计算机都不是很好，一个处理问题的好方法就是让难题再度造成。

程序员们喜爱能够被再现问题，开心快乐的程序员能够迅速并且更加高效的修复bug。

“我觉得颗粒的越迁与错误的电极化相关”并不仅仅是外行的消费者才能写下荒缪的Bug报告，我遇到过一些非常不好的Bug报告源于程序员的手中，有一些或是很优秀的程序员。

有一次我与另一个程序员一起工作，他一直在找编码中的Bug，他经常碰到一个bug，但不会处理，因此就叫我帮助。

“出什么毛病了？

”我询问。

假如他的立场恰当，那确实是一件好事。

这就意味着他已经完成工作中的一半，而且我们能一起进行另一半工作中。

这也是高效率并有益的。

但实际上他经常是错的。