缺陷生命周期一般包含哪些阶段和状态

缺陷生命周期指一个缺陷从被发现到最终归档所经历的状态序列。多数团队会围绕新建、确认与分派、修复中、待验证、关闭五个核心阶段组织流程，并用无效、重复、暂缓、重新打开等分支状态处理例外情况。本文解释这些阶段和状态的进入条件、流转证据与角色分工，帮助读者建立一套可对照实际团队命名的判断框架。

要点总览（TL;DR）

• 缺陷生命周期是缺陷从被发现到归档的状态序列，主线通常为新建、确认与分派、修复中、待验证、关闭，并用无效、重复、暂缓、重新打开处理分支情况。
• 关闭的前提是复测确认原问题不再出现且相关功能无回归；开发提交修复只代表进入待验证，不构成关闭依据。
• 无效用于缺陷不成立（环境问题、误报、操作错误或与需求预期一致），暂缓用于问题成立但延后处理，两者不能混用。
• 重复以根因或同一现象为准，判定后关联主缺陷并关闭本条；重新打开用于已关闭缺陷再次复现或修复不完整，属于验证机制正常发挥作用。
• 每次状态流转都应有触发人、判定证据和简短记录，状态命名可因团队而异，阶段逻辑保持稳定。

缺陷生命周期包含哪些阶段和状态

缺陷生命周期的核心是一条从“有人发现问题”到“问题有了确定结论”的状态链。五个核心阶段承担主线推进：新建表示缺陷已被记录；确认与分派表示缺陷经过初步判断并被交给处理人；修复中表示开发已受理并着手修改；待验证表示修复已完成、等待测试复测；关闭表示修复经复测通过，缺陷不再需要跟进。分支状态则处理主线之外的判断结果：无效、重复、暂缓、重新打开。

下表按状态列出含义、进入条件、常见责任角色和下一步动作。状态名称在不同团队和工具中可能不同，但每个状态背后的判断条件基本稳定。

状态	含义	进入条件	常见责任角色	下一步
新建	缺陷已被记录，尚未经过确认	提交人发现与预期不符的现象，填写复现步骤、环境、实际结果与预期结果	提交人（测试、用户支持、开发等）	等待确认与分派
确认与分派	缺陷被判断为有效问题，并指定处理人	缺陷负责人能按描述复现，或依据日志、截图等证据判断问题成立	缺陷负责人、测试负责人	进入修复中，或转为无效、重复、暂缓
修复中	开发已受理并正在修改	处理人接受分派，明确问题原因或修复方案	开发人员	提交修复说明，转入待验证
待验证	修复已完成，等待复测	开发提交代码变更并说明修复内容、影响范围	测试人员	复测通过转关闭；不通过退回修复中
关闭	缺陷处理结束	复测确认原问题不再出现，且相关功能未出现回归问题	测试人员或缺陷负责人	归档；若再次复现则重新打开
无效	缺陷不成立	确认属于环境问题、误报、操作错误，或实际行为与需求预期一致	缺陷负责人	说明理由后关闭，不进入修复
重复	与已有缺陷指向同一问题	检索到同一现象、同一根因的已有缺陷	缺陷负责人	关联主缺陷并关闭本条
暂缓	问题成立但暂不处理	受版本计划、依赖条件、影响范围等因素限制，团队决定延后	缺陷负责人、产品负责人	记录暂缓原因与复查条件，条件满足后恢复
重新打开	已关闭缺陷再次需要处理	原问题复现，或复测发现修复不完整	测试人员、提交人	回到修复中，补充新的复现证据

这张表的价值在于把“状态”与“判断依据”绑定。只记录状态名称而不记录进入理由，后续查看缺陷时很难判断当时为什么这样处理。

缺陷生命周期的边界：哪些内容不属于状态定义

缺陷生命周期回答的是“一个缺陷可以处于哪些状态、按什么条件进入下一个状态”。它不等同于单个缺陷的修复进度跟踪。修复进度跟踪关注某个具体缺陷当前由谁处理、改到哪一步、预计何时完成，属于执行层面的跟进；状态定义则是团队共用的规则框架，规定所有缺陷共同遵循的阶段与判定条件。

状态定义也不同于研发平台中的流程配置。流程配置是在工具里设置状态选项、流转权限、必填字段和自动化规则，属于系统落地手段；状态定义先回答业务上需要哪些状态、每个状态意味着什么。配置可以随工具调整，业务判断逻辑需要先明确，否则配置出来的流程只是空壳。

缺陷度量指标同样不属于状态定义。度量关注缺陷数量、分布、修复时长、重开率等统计结果，状态是度量的输入之一，但指标口径、统计周期和评估方法属于另一个主题。把状态定义与度量混在一起，容易出现为了指标好看而随意改状态的情况。

需要说明的是，状态命名可以因团队而异。有的团队用“已提交”“处理中”“已解决”“已关闭”，有的团队用“Open”“In Progress”“Resolved”“Closed”。名称不同不影响阶段逻辑：记录、确认、处理、验证、结束这条主线保持稳定，分支状态也围绕“不成立”“重复”“延后”“复现”四类判断展开。

状态如何流转：触发条件与角色分工

状态流转的关键是每次变化都有触发人、有证据、有记录。缺少其中任何一项，状态就会变成个人口头结论，后续无法追溯。

提交人负责把问题说清楚。新建缺陷时至少应包含复现步骤、发生环境、实际结果、预期结果，以及必要的日志或截图。复现步骤越具体，确认环节越快。提交人也可以在缺陷关闭后发现问题复现，触发重新打开。

缺陷负责人负责确认与分派。确认时依据提交人提供的证据尝试复现，判断问题是否成立、是否与已有缺陷重复、是否需要暂缓。分派时明确处理人和期望处理范围。这个角色通常由测试负责人、模块负责人或轮值人员承担。

开发人员负责修复中状态。受理后应给出修复说明，包括问题原因、修改内容、影响范围以及自测情况。修复说明是进入待验证的依据，也是测试人员设计复测范围的输入。

测试人员负责待验证与关闭。复测时既验证原问题是否消失，也检查相关功能是否出现回归问题。复测结果应记录在缺陷中，通过则关闭，不通过则退回修复中并补充失败现象。

验证不通过时的回流路径是“待验证→修复中”。退回时应写明哪一步复测失败、实际现象是什么，避免开发再次提交后仍然无法判断。暂缓的触发通常来自版本计划调整或依赖未就绪，恢复时需要有明确的复查条件，例如“下个版本重新评估”或“依赖接口上线后恢复”。重新打开的触发来自已关闭缺陷再次复现，打开时应关联新的复现证据，并说明与上次修复的关系。

当团队在工具中管理这些流转时，状态变化和操作记录需要能对应到具体的人和证据。ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代，并记录缺陷修复情况；配合 ONES TestCase 使用时，测试用例与缺陷数据可以互通，便于在复测时找到对应的验证依据。这类工具承载的是状态流转的记录动作，状态规则本身仍需团队先定义清楚。

关闭、无效、重复与重新打开分别在什么条件下发生

这四个状态最容易产生争议，因为它们的判定直接影响缺陷是否还需要投入修复资源。下表给出判定条件、所需证据和常见误判。

状态	判定条件	判定证据	常见误判
关闭	修复经复测通过，原问题不再出现，相关功能无回归问题	复测记录、验证环境、回归检查结果	开发提交修复即关闭，未经过独立复测
无效	确认缺陷不成立：环境问题、误报、操作错误，或实际行为与需求预期一致	复现失败记录、需求文档、环境说明、日志分析	把“暂时修不了”或“优先级低”标为无效
重复	与已有缺陷指向同一问题，通常为同一现象或同一根因	主缺陷编号、现象对比、根因说明	仅因描述相似就判重复，未核对根因
重新打开	已关闭缺陷再次复现，或复测发现修复不完整	新的复现步骤、失败截图、与上次修复的对比说明	把新问题挂到旧缺陷上，导致根因混淆

关闭的条件应包含“复测通过”和“无回归”两个部分。只验证原问题消失，可能遗漏修复引入的新问题；只做回归检查，又可能没有覆盖原始场景。两个部分都完成，关闭才有充分依据。

无效的判定需要区分“问题不成立”和“问题成立但暂不处理”。环境问题、误报、需求预期一致属于前者；受资源或计划限制延后处理属于暂缓。把后者标为无效，会掩盖真实存在的缺陷。

重复的判定应以根因为准。两个现象描述相似但触发条件不同，可能是两个独立缺陷；现象不同但由同一处代码引起，也可能应合并处理。判定重复时保留与主缺陷的关联，方便后续在主缺陷修复后一并验证。

重新打开不是流程失败，而是验证机制在起作用。已关闭缺陷再次复现，说明上次修复不完整或场景覆盖不足。重新打开时应补充新的证据，并说明本次复现与上次修复的关系，帮助处理人快速定位。

相邻概念区别：缺陷状态、缺陷流程与缺陷修复跟踪

缺陷状态、缺陷流程和缺陷修复跟踪经常被混用，三者关注的对象不同。缺陷状态是某个缺陷在某一时刻所处的节点；缺陷流程是状态之间的允许路径和流转规则；缺陷修复跟踪是围绕具体缺陷展开的处理、验证和沟通活动。

概念	回答的问题	典型产物	与本文的关系
缺陷状态	这个缺陷现在处于哪个节点	状态名称、状态说明、进入条件	本文核心内容
缺陷流程	状态之间允许怎样流转，由谁操作	流转规则、权限设置、必填字段	本文说明流转机制，不展开系统配置
缺陷修复跟踪	某个缺陷处理到哪一步、何时完成	处理人、修复说明、复测记录、沟通记录	本文只说明其与状态定义的区别

缺陷生命周期管理与缺陷修复验证跟踪的区别在于范围。生命周期管理定义所有缺陷共用的阶段和判定规则；修复验证跟踪针对单个缺陷，记录谁在什么时候做了什么、结果如何。前者是规则，后者是执行记录。

缺陷生命周期管理与研发平台流程配置的区别在于层次。生命周期管理先确定业务上需要哪些状态、每个状态意味着什么；流程配置把这些规则落到工具中，设置状态选项、流转条件和通知规则。规则不清楚时，配置越细越容易产生无效流转。

具体例子与常见误解

以下是一个演示情景，用来说明状态轨迹，不代表特定团队的真实案例。某版本测试中，测试人员发现“订单列表按时间排序后，第二页出现重复记录”。提交时填写了复现步骤、测试环境、实际结果和预期结果，缺陷进入新建。缺陷负责人按步骤复现成功，确认问题成立并分派给订单模块开发，状态转为确认与分派，随后进入修复中。开发定位到分页参数在排序条件下计算错误，修改后提交修复说明，状态转为待验证。测试人员复测原场景通过，并检查了订单列表的筛选、翻页和导出功能，未发现回归问题，缺陷关闭。两周后，另一名测试人员在相似场景下再次发现重复记录，补充新的复现步骤后重新打开该缺陷，状态回到修复中。这次开发发现上次修改只覆盖了单条件排序，补充修复后再次进入待验证并最终关闭。

这个轨迹说明，状态变化背后是具体的判断动作：确认依赖复现，修复依赖原因定位，关闭依赖复测和回归检查，重新打开依赖新的证据。

常见误解有四个。第一，把关闭等同于修复完成。关闭的前提是复测通过且无回归，修复完成只是进入待验证的条件。第二，把无效等同于不修。无效表示缺陷不成立，暂缓才表示问题成立但延后处理。第三，把重复等同于不重要。重复只说明与已有缺陷指向同一问题，问题本身可能优先级很高，只是统一在主缺陷中处理。第四，把重新打开等同于流程失败。重新打开说明验证环节发现了修复不完整，是质量控制正常发挥作用的表现。

这些误解通常来自状态名称过于简略、进入条件没有写清、流转记录缺少理由。纠正方式是在状态定义中写明每个状态的判定条件和所需证据，并要求每次流转留下简短说明。团队还可以定期查看缺陷状态分布，观察无效、重复、重新打开的比例是否异常，以此检验状态规则是否被正确执行。ONES Project 提供缺陷状态分布统计，可用于这类回顾；具体统计维度和报表形式以实际使用配置为准。

常见问题

缺陷被标为“暂缓”后，什么情况下应该恢复处理，什么情况下应该转为无效？

暂缓表示问题成立，只是受版本计划、依赖条件或影响范围限制而延后处理。恢复的条件应在暂缓时就写清楚，例如“下个版本重新评估”“依赖接口上线后恢复”，条件满足后回到确认与分派或修复中。

转为无效的前提是重新确认后缺陷不成立，比如原现象无法复现且证据指向环境问题、误报或操作错误。暂缓与无效的判断对象不同：前者是“问题真实存在但暂不处理”，后者是“问题本身不成立”。把暂缓的缺陷直接标为无效，会让真实问题从统计中消失。

复测时原问题消失了，但相关功能出现了新问题，这个缺陷应该关闭还是重新打开？

这种情况不宜直接关闭。关闭的条件包含两部分：原问题经复测不再出现，且相关功能未出现回归问题。回归问题属于本次修复引入的新风险，应继续留在处理链路中。

常见做法是退回修复中，在缺陷中补充回归问题的复现步骤和现象，说明它与本次修复的关联；如果回归问题影响范围独立、根因不同，也可以单独提交新缺陷并关联本条。无论哪种方式，都要保留复测记录，避免“原问题已修复”和“新问题待处理”混在同一条记录里无法区分。

两个缺陷现象描述相似，可以直接判为重复吗？

不建议只凭描述相似就判重复。重复的判定应以同一现象或同一根因为准：现象相同、触发条件一致，通常可以合并；现象相似但触发路径不同，可能是两个独立缺陷；现象不同但由同一处代码引起，也可能应合并到主缺陷统一处理。

判定重复时应核对复现步骤和根因说明，保留与主缺陷的关联，并在本条中写明主缺陷编号。这样主缺陷修复后可以一并验证，也方便后续回溯为什么当时判为重复。

团队使用的状态名称和文章里的不一样，是否说明流程有问题？

状态命名可以因团队和工具而异，例如“已提交”“处理中”“已解决”“已关闭”与“新建”“修复中”“待验证”“关闭”表达的是同一类阶段逻辑。判断流程是否清晰，关键看每个状态是否有明确的进入条件、判定证据和责任人，而不是名称是否与通用叫法一致。

如果团队状态名称简略到无法区分“问题不成立”和“问题成立但延后”，或者关闭没有复测依据，才需要调整状态定义。调整时优先补充状态说明和流转记录要求，再考虑改名。

缺陷状态分布统计能用来检验生命周期规则是否被正确执行吗？

可以作为回顾的参考。观察无效、重复、重新打开在缺陷总量中的比例，能发现一些规则执行中的异常信号：无效比例异常偏高，可能说明提交质量或确认环节存在问题；重新打开比例偏高，可能说明复测范围或修复完整性不足。

统计结果只反映分布，不能直接证明某个状态判错了，还需要结合具体缺陷的记录查看进入理由和证据。ONES Project 提供缺陷状态分布统计，可用于这类回顾；具体统计维度和报表形式以实际使用配置为准。