缺陷管理的一般流程包括以下步骤：1、发现缺陷：新建；2、开启；3、分配；4、拒绝；5、重复；6、延期；7、等待测试；8、关闭；9、重新开启。缺陷管理是在软件生命周期中识别、管理、沟通任何缺陷的过程，确保缺陷被跟踪管理而不丢失。

1、发现缺陷：新建

一般缺陷问题有测试团队根据用例步骤进行测试，如果不能正常通过用例则转为缺陷问题。但是很多团队并没有专门的测试团队，因此创建问题缺陷的可能来自不同团队或者来自外部用户提交的反馈信息。这些缺陷反馈其缺陷状态应该为“新建”。

2、开启

当QA测试团队或者其他相同职务的团队确认了反馈的缺陷问题后，比如可以复现，则确认反馈是一个缺陷，并等待分配给开发团队。

3、分配

当测试团队确认缺陷后，应该将问题分配给开发团队进行缺陷定位和修复工作。

4、拒绝

如果开发团队认为提交上来的缺陷并不是真正的缺陷，比如由于缓存，网络导致的部分文件加载失败导致的问题等，应将缺陷状态标记为“拒绝”并指派回测试团队。测试团队需要重新测试或者提供更多的缺陷信息。

5、重复

如果开发团队收到的缺陷是重复的，或者与其他正在进行中的缺陷问题相似，应将缺陷状态修改为“重复”

6、延期

部分不紧急的缺陷问题，可能会随着日后的产品迭代中进行修复。对于这类缺陷应当标注为“延期”。在这里要注意，并不是所有缺陷都需要立即进行修复。每个缺陷问题在严重程度，影响范围均有不同，因此优先修复的等级也不同。我会在下一篇文章中单独讲解制定优先级别的方法。

7、等待测试

当开发团队修复缺陷后，应将缺陷状态标记为等待测试并由测试团队进行测试。

8、关闭

在测试通过后，缺陷状态修改为“关闭”或者完成。

9、重新开启

如果缺陷修复后并没有通过测试，应标记为重新开启，并重新启用分配流程。

延伸阅读：

缺陷管理的优点

首先需求Bug再不象以前，没有人进行确认，需求的处理人员本来就是需求人员，由他们确认与跟踪是较好不过的，因为他们对需求有绝对的权威。同时测试人员其实就是较早的用户，他们的需求就是用户的需求，这种方法加强了需求人员与测试人员的沟通，使需求得到有效的补充，从而让产品更加完善。还有测试人员从本质上来说与程序员还是对立的，这里如果为了这样一个不是软件本身问题的问题形成与开发人员的对立，则会出现赢得战役而丢失整个战争的情况，测试人员协调好与开发人员的关系，让他们更有效的对软件本身的缺陷形成有效的关注是较好的。还有最为关键的一点，测试人员的激情是最重要的，如果他们的想法没有得到体现，这时会渐渐的失去对测试的兴趣，从而软件的质量则会无法得到保证，通过这种方法可以让他们看到自己的建议可以通过对需求人员的反映得到实现，让他们时时觉得自己的想法是可以通过这种方法来有效的推行，这样工作的积极性才会有保障。

50万+团队都在用的项目协作工具一个工具满足团队所需：任务、项目、文档、IM、目标、 日历、甘特图、工时、审批以及更多，让工作更简单智能化研发管理工具PingCode 是简单易用的新一代研发管理平台，让研发管理自动化、数据化、智能化，帮助企业提升研发效能