如何记录一个合格的bug

    首先，撰写缺陷报告的一个基本原则是：客观地陈述所有相关事实。

    接着，一个合格的bug报告应该包括完整的内容，至少应该含有以下几个方面：

    * 发现问题的版本

    * 问题出现的环境

    * 问题重现的步骤

    * 预期行为的描述

    * 错误行为的描述

    下面，对以上各项详细的讲解一下。

    1.发现问题的版本

    开发人员需要知道问题出现的版本，才能获取一个相同的版本来进行问题的重现。版本的标识有助于分析和总结问题出现的集中程度。

    需要注意的是，有些bug可能会在不同的版本中出现，例如，某个bug在版本1.1中出现了，测试人员录入了bug，ID为01，开发人员也进行了修改，经验证关闭了。但是，该bug到了版本1.4又出现了，这是，有些测试人员回过头来把bug01的状态改成了reopen，这是错误的，因为这个bug是在新的版本中出现的，即使是同一种现象，甚至是同一个原因造成了，也不应该reopen，而是新加一个，因为这代表了一个质量回归的问题。这个缺陷确实又出现了，因为这个缺陷造成了损失，测试人员需要重新测试、验证并进行报告，开发人员需要再次修改程序并编译；如果reopen，则可能造成质量统计时漏算了一个缺陷。

    2.问题出现的环境

    问题出现的环境包括操作系统环境，软件配置环境，有时候还需要包括系统资源的情况，因为这些错误只有在资源不足时才出现。

    由于开发环境和测试环境存在差异，往往会导致有些问题只在测试环境下才出现，这时候，测试人员应该把这些差异记录清楚，以便开发人员在重新问题和进入调试之前把环境设置好。

    3.问题重现的步骤

    应该描述重现问题所必须执行的最少的一组操作步骤。

    有些测试人员往往一发现问题就把重新步骤记录下来，并报告bug。这些重新步骤可能是非常冗长的一个操作，而实际上则可以仅仅是其中的一两个关键步骤的组合才会出现这样的错误。让开发人员重新执行这些多余的步骤其实是在浪费开发人员的宝贵时间，因为调试周期会因此加长。

   正确的做法是，录入之前再多做几次尝试，尽量把操作步骤缩减到必须要执行才能重新错误的几个步骤。   

   4.预期行为的描述

   要让开发人员知道什么才是正确的，尤其要从用户的角度来描述程序的行为应该是怎样的。

   明确地说明程序的预期行为才能更好地表达需求。

   5.错误行为的描述

   描述问题的现象，例如“程序抛出异常信息如下:......”。

   记住，在描述这些错误行为时要客观地反映事实，不要人为地夸大。

   除了以上提到的必须记录的缺陷信息外，还有一些事需要及时登记的，以备将来统计和报告使用的信息。例如，缺陷的严重程度、出现的功能模块、缺陷的类型、发现的日期等信息。