如何录入一个大家认为好的，尤其是开发认为好的BUG呢。撰写缺陷报告的一个基本原则就是客观陈述所有的相关事实。
第一点 报告发现问题的版本
开发人员需要指导问题出现在那个版本中，才能获取一个相同的版本进行问题的重现，并且版本的标识有助于分析和总结问题的集中程度。
需要注意的是，有些bug在1.1版本出现，测试人员录入了bugID为101 ，开发人员修改了并且验证关闭了，但是到了1.4的时候又出现，这时候测试人员把101的状态改为reopen，这是错误的，因为这个是在新得版本中出现的，即使是同一个现象，甚至原因一样，但是也不应该reopen，而是新加一个。因为这个代表了质量回归问题，这个缺陷的确又出现了，改为reopen可能导致质量统计时漏算了一个缺陷。测试人员需要重新登记、测试、验证、报告，开发人员需要重新修改和编译。
第二点 报告问题出现的环境
问题出现的环境包括操作系统环境、软件配置环境、有时候还包括系统资源使用情况，因为有些错误是在资源不足时才出现。
由于开发环境和测试环境还有客户真实使用环境存在较大的差异，所以应当考虑问题出现时是否受到了软硬件环境或者配置的影响。例如有的第三方需要注册的插件导致报表如法打开。
第三点 报告问题重现的操作步骤
应该描述重现问题所必须执行的最少的一组操作步骤。
有些测试人员往往一发现问题就把重现的步骤写上去，报告bug，而实际上可能仅仅时其中的某些个关键步骤的组合才会出现这样的错误，所以正确的做法是，录入之前再多做几次尝试，尽量把操作步骤缩减到必要执行才能重现错误的几个步骤。
第四点 描述预期的行为
要让开发人员知道什么才是正确的，尤其要从客户的角度出发来描述程序的行为应该是怎样的。明确的说明程序的预期行为才能更好的表达需求。表述不要模棱两可，要让开发明确的知晓想要得到什么。
第五点 描述观察到的错误行为
描述问题的现象，客观的陈述和反映事实，不要夸大 更不要讽刺。
第六点 录完提交前自检
文章内容中不要出现错别字，表述模棱两可不清晰的情况，不要把几个bug同时录入到一个ID的上报中，录完一个bug后自己读一遍。
除了上面说到的bug的版本、出现的环境、重现的步骤、预期的行为、错误的行为之外，还可以登记bug的缺陷等级、bug对应的模块及位置定位、缺陷的类型、发现日期、用户上报日期等。必要的异常信息文件、日志文件、输入的数据和输出的数据、前端截图等都可以作为附件加到bug报告中，方便开发人员定位。