bug状态开发人员必知必会

         在项目开发过程中，我发觉很多人在解决测试人员提出的bug之后，应该将这个bug修改成什么状态不太了解，导致了最后统计bug解决数量，以及遗留bug等等数据不准确。作为开发人员，我觉得了解bug的解决状态是一门基础课程。这里我将开发人员用到的bug解决状态列举出来，希望对大家有所帮助（这些都是开发人员在解决相应bug时应该在测试库中修改的状态）：
   

•  FIXED（已解决）：bug已经被解决,并且通过经过测试。

•  INVALID(不是bug)：被描述的问题不是一个bug（测试人员提出这个bug,但是开发人员认为不是bug）。

•  WONTFIX(不修改bug,NeedlessFix)：被描述的问题是一个bug,但是不准备进行修改。

•  LATER(下一版本再修改)：被描述的问题是一个bug,但是不在当前版本中进行修改。（已经确定在下一版本修改）

•  REMIND(可能到下一个版本再修改)：被描述的问题是一个bug,但是很可能不在目前版本中进行修改（注意是可能，注意later）

•  DUPLICATE(bug重复)：提出的问题和当前已经存在的某个bug重复。

•  WORKSFORME(bug不能重现)：不能重现这个bug,查看源代码也不知道为什么会出现这样的bug 现象,如果以后有更多的关 于这个bug的线索,将重新接受这个bug。（这个是对于那些知道有bug，但是却不能重现bug的情况）

  可见，bug状态并不是随便指定的，是要根据具体情况具体处理，我见有的开发人员是这样处理bug的：测试人员提出bug，开发人员不管这个是不是bug，或者是重复bug，或者留待LATER修改的bug,一律设置为FIXED。这时很不负责的表现，殊不知，就有可能因为你随便设置bug状态这么一个小动作，就把bug留在了产品中，最终可能导致严重后果。切记！！！！

  测试人员bug状态见 《bug状态开人员必知必会续》