日志
　　在bug report里附上日志或日志的摘录片断。这将帮助开发人员轻松地分析且调试系统。多数情况下，如果不附上日志而且在开发人员那边又很难重现问题的话，他们将会把bug report打回给你并要求附带日志文件。
　　如果日志文件不太大的话，举个例子，大约20到25行，你可以把它贴在bug report里。但是如果它比较大的话，把它做为附件贴在bug report里，否则你的bug report会看上去象个日志。
　　其他信息
　　◆　如果你的bug是随机出现的，只需在你的bug report中说一下可以了。但是不要忘记归档它。你总是能够在你发现它们之后的任何时间里增加准确的步骤。这也将在其他人提交这个问题时解救你，特别是当那个问题比较严重时。
　　◆　在bug report中写下错误信息，特别是当错误信息有编号的时候。例如，来自数据库中的错误信息。
　　◆　在bug report中写下版本编号和内部小版本编号
　　◆　写下问题可以被重现的平台。准确的说明问题不可重现的平台。同样也要理解问题在特定平台上不可重现和没有在某个平台上测试之间的分别。这个可能会造成混淆。
　　◆　如果你遇到几个问题却有一样的结果，只需写一个bug report。问题的修复可能只是一个。同样，如果你在不同的地方遇到相似的问题，且要求同一种修复方法，但是在不同的地方，那么要为每一个问题书写单独的bug report。每个bug report对应一个修复。
　　◆　如果可以重现bug的测试环境是开发人员可以访问的，写下访问这种设置的详情。这将帮助他们节约安装环境的时间以重现你提交的bug。
　　◆　你决不能坚持关于bug的任何信息。在bug被修复之前由于低效的提交bug而引起的开发人员和测试人员之间不必要的交互只是浪费时间。