现在的位置: 首页 > 综合 > 正文

bug状态开发人员必知必会

2012年12月05日 ⁄ 综合 ⁄ 共 800字 ⁄ 字号 评论关闭
         在项目开发过程中,我发觉很多人在解决测试人员提出的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状态开人员必知必会续

抱歉!评论已关闭.