定义BUG状态
谈到BUG的状态,不得不提一下测试的工作模式,较为常见有以下两种:第一种工作模式为交互式,也就是说由测试工程师提交BUG到管理工具,通知软件工程师进行修改,软件工程师根据BUG状态做出反应或修改,然后将问题状态更新,提交测试版本后,由软件工程师确认并再次更新问题的状态,这种工作模式是较为理想化的,因为中间需要多次沟通协调,所以转换周期会长一些,比较适用于大型软件项目;那么单方触发的工作模式,以测试工程师为主导,发现问题并督促软件工作师修改,跟踪修改结果,这种工作模式较为灵活,测试工程师与软件工程师之间是一对一或一对二的关系,问题发现后能够及时修改,修复的周期较短,这种工作模式适用于中小型软件开发项目。在这里,我主要说明一下在第二种工作模式下,BUG的状态定义。
1.任务:适用出因为增加合理化要求而提出的问题,在开发工程师解决问题时,此类问题的优先级较低。

2.待改:功能性缺陷,主要体现在功能缺失、程序运行异常、没有产生正确的运行结果等,需要软件工程师优先解决的问题。

3.关闭:表明该问题经测试工程师验证后已经解决,并且没有带来新错误的BUG。

4.需求未定:在《软件需求说明书》未描述,程序也未实现,但因为该业务不完整导致程序不能正常执行的问题,需要项目经理等管理人员参与讨论确定的功能特性。

5.遗留:对软件影响较小,此次项目周期不做修改的问题。

6.重新开启:在前面的版本经测试工程师验证通过,在当前版本中重复出现的问题,建议在记录这类问题时,增加“重复次数”字段,用以说明问题的重现概率。

7.非错:由于测试工程师对软件需求的理解错误,所提交的问题。

8.关闭的需求:在第4项中说明的问题,经过讨论后加以确定,并在提交的软件版本中得以实现,经过测试工作师验证后与确定需求一致并且功能无缺陷的问题。
以上八种状态并非适应于所有的软件项目,测试工程师可以对其中的状态进行合并或是拆分,根据测试工程师对程序的理解及测试的不同要求,还可以制定其他的问题状态,定义BUG的状态主要目的是明确问题的种类,为评价程序缺陷修复质量提供依据。