模板
教程
环境
性能
功能
管理
如何编写更佳的bug report[1]
我们是否经常看到开发人员针对我们归档的bug report要求提供更多的信息?我们是否经常需要在bug report归档后花更多的时间去研究那个问题?我们是否经常从开发人员那里听到在他们那边难以重现bug并且需要即刻提供“可重现的步骤”?广义上来说，我们与其花更多的时间在这些问题上还不如投资更多的时间来测试系统。问题出在bug report的质量上。这里介绍一些如何改进并达到完美bug report的建议。
Bug report的目的
当我们发现一个缺陷时，我们需要把它告诉给开发人员。Bug report就是这种沟通的媒介物。Bug report的主要目的是让开发人员亲眼看到这个错误。如果你不能和他一起以在他面前制造出那个失败，那么就需要给他们足够多的指引以便他们能够自己制造出那个失败。Bug report就是解释在期望结果和实际结果之间的差距并且详细的说明如何重现那个场景。
在发现缺陷之后
◆ 只有当你确信你已经发现一个bug的时候开始起草bug report，不要在测试结束或每天结束之后。那样，你可能会遗忘掉一些东西。更糟的情况是，我们可能会忘掉那个bug。
◆ 花一些时间去诊断你正在报告的缺陷。想想可能存在的原因。可能到最后你会发现更多的缺陷。在你的bug report中说说你的发现。开发人员将不仅仅对你使他们的工作变得轻松而感到高兴。
◆ 在开始读你的bug report之前抽出一些时间来。你可能会感觉到象重新编写报告一样。
摘要
Bug report的摘要是你bug report给读者的第一印象。你提交的bug的命运很大程度依赖于你的bug report能否吸引读者。原则就是每个bug应该有一个简单有趣的摘要。它可能会听上去象编写一个优秀的勾起注意的广告活动。但是随后，没有什么意外。一个好的摘要应该不超过50到60个字符。而且一个好的摘要不应该承载任何对bug主观的表达。
语言
◆ 不要在bug report中夸大缺陷。同样，也不要太轻描淡写了。
◆ 不管bug是多么的令人讨厌，别忘了是bug令人讨厌，而不是开发人员。永远不要冒犯开发人员的努力。使用委婉些的说法。“混乱的UI”可以被温和些改为“不正确的UI”。这样开发人员的努力将会得到尊重。
◆ 保持简单诚实。你不是在写散文或文章，因此使用简单的语言
◆ 在编写bug report的时候记住你的目标读者。他们可能是开发人员，其他的测试人员，经理，或者在一些情况下，甚至是客户。Bug report应该可以被所有的人理解。
