分类：
2008-10-15 16:45:28
数据
尽力编写普通的bug report，开发人员可能没有权限访问你的数据。如果bug是和一组特定的测试数据相关，在你的bug report上附带上它。
截屏
截屏是bug report中一个十分必要的部分。一个图片胜过一千句话。但是不要把在每个bug report里附带没有必要的截屏变成一个习惯。理想的来说，你的bug report应该是足够有效的使开发人员重现问题。截屏应该只是验证的一种方法。
◆ 如果你要在bug report里附带截屏，要确保那些图片不是太大的，使用jpg或gif的格式，而不是bmp格式
◆ 在截屏上写上注释以指出问题所在。这将帮助开发人员一眼就可以马上定位问题。
严重程序/优先级别
◆ 在设置bug report的严重程序之前应该全面的分析缺陷的影响程序。如果你认为你的bug具有很高的优先级应该被修复，在bug report中证明这点。应该在bug report的描述部分指出这个理由。
◆ 如果bug是来自上个内部小版本或版本回归的结果，那么发出警报。象这种bug的严重程序可能是低的，但是优先级别应该是高。
日志
在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而引起的开发人员和测试人员之间不必要的交互只是浪费时间。
