如何有效地报告 Bug

如何写一个好的bug报告：（为了方便描述把服务器以及客户端都简称为程序）
简单地说，报告bug的目的是为了让策划以及程序员看到程序的错误。您可以亲自示范，也可以给出能导致程序出错的、详尽的操作步骤。如果程序出错了，程序员会收集额外的信息直到找到错误的原因；如果程序没有出错，那么他们会请您继续关注这个问题，收集相关的信息。
在bug报告里，要设法搞清什么是事实（例如：“我点击了XX”和“XX出现了”）什么是推测（例如：“我想问题可能是出在……”）。如果愿意的话，您可以省去推测，但是千万别省略事实。
当您报告bug的时候（既然您已经这么做了），一定是希望bug得到及时修正。所以此时针对策划以及程序员的任何过激或亵渎的言语（甚至谩骂）都是与事无补的——因为这可能是他们的错误，也有可能是您的错误，也许您有权对他们发火，但是如果您能多提供一些有用的信息（而不是激愤之词）或许bug会被更快的修正。
“程序不好用，设计不完美！”
策划、程序员不是弱智：如果程序一点都不好用，他们不可能不知道。他们不知道一定是因为程序在他们看来工作得很正常。所以，或者是您作过一些与他们不同的操作，或者是您的环境与他们不同。他们需要信息，报告bug也是为了提供信息。信息总是越多越好。
在我们公司，任何一个已经开发了，或者正在开发的项目都会公布一个“已知bug列表”。如果您找到的bug在列表里已经有了，那就不必再报告了，但是如果您认为自己掌握的信息比列表中的丰富，那无论如何也要与策划联系。您提供的信息可能会使程序员更简单地修复bug。
上面说的，没有哪一条是必须恪守的准则。不同的策划，程序员会喜欢不同形式的bug报告。如果策划或者程序附带了一套报告bug的准则，一定要读。如果它与本文中提到的规则相抵触，那么请以它为准。
“演示给程序，策划看”
报告bug的最好的方法之一是“演示”给程序员或者策划看。让他们站在电脑前，运行游戏，指出游戏里的错误。让他们看着您启动电脑、运行游戏、如何进行操作以及游戏对您的操作有何反应。
 
策划对自己写的案子也相当熟悉。程序对自己写的程序了如指掌，他们知道哪些地方不会出问题，而哪些地方最可能出问题。他们本能地知道应该注意什么。在程序真的出错之前，他们可能已经注意到某些地方不对劲，这些都会给他们一些线索。他们会观察程序测试中的每一个细节，并且选出他们认为有用的信息。
这些可能还不够。也许他们觉得还需要更多的信息，会请您重复刚才的操作。他们可能在这期间需要与您交流一下，以便在他们需要的时候让bug重新出现。他们可能会改变一些操作，看看这个错误的产生是个别问题还是相关的一类问题。
“告诉程序和策划怎么出现此BUG”
如果您必须报告bug，而此时程序员又不在您身边，那么您就要想办法让bug重现在他们面前。当他们亲眼看到错误时，就能够进行处理了。
确切地告诉他们您做了些什么。比如告诉他们您按了哪个按钮，依照什么顺序按的。或者说是测试聊天功能，精确的告诉他们您键入了什么。您应该尽可能详细地提供您所键入的内容和程序的反应。把您能想到的所有的输入方式都告诉程序员。如果客户端下产生了LOG文件，那么提交BUG的时候也一定要附上LOG文件。
“哪儿出错了？在程序或者策划看来一切正常哦！”
如果您给了程序员BUG报告，他们按照步骤执行以后没有出现错误，那是因为您没有给他们足够的信息，可能错误不是在每台计算机上都出现，您的系统可能和他们的在某些地方不一样。有时候程序的行为可能和您预想的不一样，这也许是误会，但是您会认为程序出错了，程序员却认为这是对的。这时候，一切都要以策划案为准。
同样也要描述发生了什么。精确的描述您看到了什么。告诉他们为什么您觉得自己所看到的是错误的（和策划案中不符合的地方），最好再告诉他们，您认为自己应该看到什么（策划案中描述的正确表现）。如果您只是说：“客户端崩溃了”，或者“资源出错”，那您很可能漏掉了非常重要的信息。
如果您看到了错误消息，一定要仔细、准确的告诉策划以及程序员，这很重要。在这种情况下，他们只要修正错误，而不用去找错误。他们需要知道是什么出问题了，系统所报的错误消息正好帮助了他们。如果您没有更好的方法记住这些消息，就把它们写下来。只报告“客户端或者服务器出了一个错”是毫无意义的，除非您把错误消息一块报上来。
特殊情况下，如果有弹出错误消息框，一定要把这些信息框内容告诉程序员。不要以为您看不出任何意义，它就没有意义。这些内容包含了能被程序员读懂的各种信息，并且很有可能包含重要的线索。
在这种情形下，程序员的排错工作会十分高效。他们不知道发生了什么，也不可能到现场去观察，所以他们一直在搜寻有价值的线索。错误消息、错误消息号以及一些莫名其妙的延迟，都是很重要的线索，就像办案时的指纹一样重要，请保存好（可以以截图的方式保存！）。
“出了问题之后，该怎么做……” 
当一个错误或bug发生的时候，您可能会做许多事情。但是大多数人会使事情变的更糟。当程序出毛病的时候，立刻停止正在做的任何操作。不要按任何健。仔细地看一下屏幕，注意那些不正常的地方，记住它或者写下来。然后慎重地点击“确定” 或“取消”，选择一个最安全的。学着养成一种条件反射——一旦电脑出了问题，先不要动。要想摆脱这个问题，关掉受影响的程序或者重新启动计算机都不好，一个解决问题的好办法是让问题再次产生。程序员们喜欢可以被重现的问题，这样可以更快而且更有效率的帮助程序员修复bug。
“真是奇怪，刚才还不好用，怎么现在又好了？”
“间歇性错误”着实让程序员发愁。相比之下，进行一系列简单的操作便能导致错误发生的问题是简单的。程序员可以在一个便于观察的条件下重复那些操作，观察每一个细节。太多的问题在这种情况下不能解决，例如：游戏中偶然出一次错，或者在程序员面前从不出错（程序员一离开就出错。）。
大多数“间歇性错误”并不是真正的“间歇”。其中的大多数错误与某些地方是有联系的。有一些错误可能是内存泄漏产生的，有一些可能是别的程序在不恰当的时候修改某个重要文件造成的。
同样，如果您能使bug重现，而程序员不能，那很有可能是他们的计算机和您的计算机在某些地方是不同的，这种不同引起了问题。或者说我们使用的服务器或者客户端（资源，配置文件等等）和他们使用的不一样而存在这样的问题！
程序员想要了解任何与您发现的问题相关的事情。有可能的话您到另一台机器上试试，多试几次，两次，三次，看看问题是不是经常发生。如果问题出现在您进行了一系列操作之后，不是您想让它出现它就会出现，这就有可能是长时间的运行游戏或者进行了某些特定的操作所导致的错误。客户端崩溃的时候，您要尽可能的记住您都做了些什么，并且如果您看到了什么东西,也别忘了提一下。您提供的任何事情都是有帮助的。即使只是概括性的描述，这虽然不能提供导致问题的直接线索，但是可能帮助程序员重现问题。
最重要的是：程序员想要确定他们正在处理的是一个真正的“间歇性错误”呢，还是一个在另一类特定的计算机上才出现的错误。他们想知道有关您计算机的许多细节，以便了解您的机器与他们的有什么不同。有一件东西您一定要提供——版本号。服务器客户端的版本、操作系统的版本以及与问题有关的所有资源或者配置文件的日期。
“表意清晰”
表意清楚在一份bug报告里是最基本的要求。如果程序员不知道您说的是什么意思，那您就跟没说一样。
精确。如果做相同的事情有多种方法，请说明您用的是哪一种。例如：“我选择了‘交易’”，可能意味着“你提出了交易”或“或者是你接受了对方提出的交易请求”，说清楚您用了哪种方法，有时候这也有关系。 
详细。信息宁多毋少！如果您说了很多，程序员或者策划可以略去一部分，可是如果您说的太少，他们就不得不回过头再去问您一些问题。
慎用代词。诸如“它”，“按钮”这些词，当它们指代不清晰的时候不要用。来看看这句话：“我运行了征服，它弹出一个警告窗口，我试着关掉它，它就崩溃了。”这种表述并不清晰，你究竟关掉了哪个窗口？是警告窗口还是整个征服？您可以这样说，“我运行征服时弹出一个警告窗口，我试着关闭警告窗口，征服整个客户端崩溃了。”这样虽然罗嗦点，但是很清晰不容易产生误解。 
检查。重新读一遍您写的bug报告，您觉得它是否清晰？如果您列出了一系列能导致出错的操作，那么照着做一遍，看看您是不是漏写了一步。 
小结：
bug报告的首要目的是让策划以及程序员亲眼看到错误。如果您不能亲自做给他们看，给他们能使程序出错的详细的操作步骤。 
如果首要目的不能达成，策划和程序员不能看到程序出错。这就需要bug报告的第二个目的来描述程序的什么地方出毛病了。详细的描述每一件事情：您看到了什么，您想看到什么，把错误消息记下来。 
当您的计算机做了什么您料想不到的事，不要动！在您平静下来之前什么都别做。不要做您认为不安全的事。 
尽量试着自己“诊断”程序出错的原因（如果您认为自己可以的话）。即使做出了“诊断”，您仍然应该报告“症状”。 
如果策划以及程序员需要，请准备好额外的信息。如果他们不需要，就不会问您要。他们不会故意为难自己。您手头上一定要有服务器以及客户端的版本号，它很可能是必需品。 
表述清楚，确保您的意思不能被曲解。 
总的来说，最重要的是要做到精确。策划、程序员以及一切修改BUG的人都喜欢精确。