如何记录一个大家认为好的，尤其是开发人员认为好的Bug呢？撰写缺陷报告的一个基本原则是：客观地陈述所有相关事实。
一个合格的Bug报告应该包括完整的内容，至少应该包含五个方面：发现问题、预期行为的描述、问题重视步骤、问题出现的环境、错误行为的描述。报告发现问题的版本，开发人员需要知道问题出现的版本，才能获取一个相同的版本来进行问题的重视。版本的标识有助于分析和总结问题出现的集中程度，需要注意的是，有些Bug可能会在不同的版本中出现，例如，某个BUG在版本1.1中出现了，测试人员录入了Bug，ID为101，开发人员也进行了修改，经验证关闭了。但是，改Bug到了版本1.4时又出现了，这时，有些测试人员回头把Bug101的状态改成Reopen，这时错误的，因为这个Bug是在新的版本中出现的，即使是同一种现象，甚至是同一个原因造成的，也不应该Reopen，而是新加一个，因为这代表了一个质量回归问题。这个缺陷确实又出现了，因为这个缺陷造成了损失，测试人员需要重新测试、验证并进行报告，开发人员需要再次修改程序并编译，如果Reopen,则可能造成质量统计时漏算了一个缺陷。
正确的做法是，录入之前再多做几次尝试，尽量把操作步骤缩减到必须要执行才能重现错误的几个步骤。
