平台：告诉我们软件运行在什么平台。尤其是操作系统的名字及版本和游览器名称版本。特别是web应用，这些信息对我们很重要。

　　差：“Windows”

　　好：“Windows7，IE9”

　　是否能重现：有些恼火的Bug是间歇性的出现，我们想预先知道，如果我们正在处理一个灵异事件或者正逢Bug出现时。

　　差：留空白

　　好：“每次”，“偶然”，“不重现”

　　描述：这部分是很多人拿不定的地方，不知道怎么描述问题，在描述中做到包括下面的内容：

　　● 总结：用简洁的语言概括出Bug出现时你正在做的事情。从上下文开始，在操作应用的哪个部分。聚焦在你做的时候软件做了什么？

　　差：“系统不能用了”

　　好：在“honor report”页面单击“打印按钮”，但是报表是空的。

　　● 发生了什么：一步一步描述你做的事情当bug出现时，为什么你认为是错误的。事无巨细，打印出菜单的名称，页面标题，点击时的按钮或者链接的名称。做相同的操作是不是出现一样的错误。

　　差：“空白报表”

　　好：“点击 ‘File/Save as…’，’Save‘对话空弹出，然后点击‘OK’按钮，但是文件没有保存”

　　● 错误时什么：如果错误消息出现时，拷贝粘贴整个信息，这样更有利于我们跟踪错误。

　　差：“有个错误，点击它始终读不出”

　　好：“Error 403：访问拒绝”

　　● 复现的步骤：如果你可以让bug重现，那太好了，这能提供很大的帮助。一步步描述如何重现次bug。

　　差：“打印没法使用”

　　好：“从‘Honors Report’页面，点击‘打印按钮’”

　　● 预期结果：描述你预期发生的结果当bug发生时，这部分特别有用如果程序没有按照你期待的结果发生时，因为它很诡异。

　　差：“我期待能正常工作”

　　好：“我期待能看到‘Honors Reports’的PDF文件”

　　真实结果：当bug发生时是怎么发生的，什么错误，为什么有错，或者如果错误抛出，抛出什么错。

　　差：“没法用”

　　好：“我收到是空的PDF文件，或者’403错误，访问拒绝’”

　　● 附件：如果你知道怎么截屏，做吧，附上一个简短的错误，截屏可以是错误之前或者发生错误之后，我们的开发者能够看到究竟发生了什么。如果应用有崩溃的日志，同样附上它。

　　● 联系方式：附上你的名字和email，我们可以让你提交的报告及时的得到答复，在我们不理解问题的描述时还能够询问你，如果你忘记附联系方式了，我们也就没法联系到你，也没法修复bug。