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

　　1.任务：适用出因为增加合理化要求而提出的问题，在开发工程师解决问题时，此类问题的优先级较低。

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

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

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

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

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

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

　　8.关闭的需求：在第4项中说明的问题，经过讨论后加以确定，并在提交的软件版本中得以实现，经过测试工作师验证后与确定需求一致并且功能无缺陷的问题。

　　以上八种状态并非适应于所有的软件项目，测试工程师可以对其中的状态进行合并或是拆分，根据测试工程师对程序的理解及测试的不同要求，还可以制定其他的问题状态，定义BUG的状态主要目的是明确问题的种类，为评价程序缺陷修复质量提供依据。