在测试工作中，缺陷管理是我们必不可少的工作内容之一。既然是管理，也就少不了时间、人物和管理内容。本文将分享软件项目中缺陷管理的基本内容以及对缺陷管理的一些思考。
如图 1-1 所示， 缺陷通常包含以下八个状态：打开、重新打开、已修复、未复现、问题重复、不是问题、延期修复和关闭 。其中，研发人员需要关注和处理打开和重新打开这两个状态下的缺陷，测试人员需要关注和处理已修复、未复现、问题重复、不是问题和延期修复这五个状态下的缺陷。当然，不同企业对缺陷状态的设置会存在一定的差异，本文暂时以这些状态为例。
1-1 软件缺陷状态图
当我们新录入一个缺陷后，缺陷即处于初态，也就是处于打开状态，这时缺陷的负责人就流转到了研发工程师身上。如图 1-1 中标记为 1 的状态流向，研发分析缺陷后可以有不同的处理方式，如果确认是 Bug，则在缺陷修复后将缺陷状态流转到已修复，这时候缺陷的负责人就流转到了测试工程师。如果研发人员无法复现问题或者认为不是问题或者发现有重复的缺陷记录了，则备注原因后流转向相应的状态。如果确认了是 Bug 但是在当前版本来不及修复，在与产品经理和测试工程师协商一致后，可将缺陷流转到延期修复状态。
如图 1-1 中标记为 2 的状态流向，这里的状态流向是双向的，即缺陷可以在测试工程师和研发工程师间多次来回流转，只要缺陷没有修复或者是对缺陷的处理结果各方未达成一致，缺陷就不能流转向终态。
如图 1-1 中标记为 3 的状态流向，缺陷流向的下一个状态是关闭，即缺陷的终态。当缺陷由测试工程师验证已修复或者是对缺陷的处理结果各方已达成一致，则可以关闭缺陷。
图 1-2 软件缺陷处理流程图
基于缺陷状态管理，我们再来看下缺陷的人员协作流程，可简化为三个部分，如图 1-2 所示， 首先是发现问题，然后是分析和解决问题，最后是再次验证问题。 对应到缺陷的处理流程里，首先是由测试工程师发现缺陷并记录缺陷，之后由研发工程师对缺陷进行分析和处理，最后由测试工程师对处理结果进行验证，若验证通过则关闭缺陷，若验证未通过则需转回研发人员进行重新分析和处理。
通过上文的介绍，我们了解了测试工程师非常重要的工作内容之一：缺陷管理。当然，本文不仅是为了分享缺陷管理的具体内容，也是为了思考如何做好缺陷管理。 总结来看，就是要明确缺陷的状态、对应的负责人和协作的流程。
图 1-3 软件项目流程图
如图 1-3 所示，从软件项目维度去看，系统测试仅是项目的一个环节，而缺陷管理也仅是系统测试环节中的一部分，那如果我们想做好软件项目的管理工作，或者说我们想做好软件项目的质量保障工作，应该怎么做？
“识别好关键的项目节点，建立合适的协作流程，明确什么时间（节点）应该由什么人做什么事。” 这或许会是一个答案。
作者简介： Chaofan，北交学子，专注思考和分享软件测试与质量保障。
对于缺陷管理的过程这块，我觉得可以再补充补充，比如缺陷关闭后 测试还能做什么？
当然，本文不仅是为了分享缺陷管理的具体内容，也是为了思考如何做好缺陷管理
“识别好关键的项目节点，建立合适的协作流程，明确什么时间（节点）应该由什么人做什么事。” 这或许会是一个答案。
也可以深入讲下这段内容..整篇看完给我一种意犹未尽的感觉，刚看到疑似重点，卡擦一下 结束了
“识别好关键的项目节点，建立合适的协作流程，明确什么时间（节点）应该由什么人做什么事。”
我认为这句话应该给开发同学看看
是的，开发人员也需要有这个认识。不单单是测试人员，开发、产品和设计等团队成员其实都需要对项目流程和协作节点有认识，这样团队才能在各司其职的前提下密切配合，从而让项目高效运转。
