缺陷生命周期指一个缺陷从被发现到关闭所经历的状态序列，典型阶段包括发现与记录、确认与分类、分派与受理、修复与提交、验证与回归、关闭或重新打开、归档与复盘。不同团队会合并或拆分状态，但核心逻辑一致：每个阶段都有明确的责任人、准入条件和退出条件，缺陷才能被稳定推进到关闭。
要点总览（TL;DR）
- 缺陷生命周期指单个缺陷从被发现到关闭所经历的状态序列，典型包括发现与记录、确认与分类、分派与受理、修复与提交、验证与回归、关闭或重新打开、归档与复盘七个阶段。
- 阶段划分因团队流程而异，小型团队常合并确认与分派，流程较重的团队会拆出待评审、待发布验证等中间状态，关键是每个状态都有准入条件、责任人和产出物。
- 生命周期只规定状态流转与处置规则；单个缺陷修得快不快属于修复与验证跟踪，状态机如何配置属于研发平台配置与治理。
- 状态、严重程度、优先级是三个维度：状态表示流程位置，严重程度表示影响大小，优先级表示排期紧迫性，严重程度与优先级不一致是正常现象。
- 关闭是处置终态但并非流程终点，归档与复盘把单个缺陷转化为用例和流程的改进输入；跳过验证直接关闭、把拒绝当作关闭都会让质量统计失真。
缺陷生命周期包括哪些阶段
缺陷生命周期描述的是单个缺陷在流程中的位置变化，以及每个位置上允许做什么处置。它回答的是“这个缺陷现在处于哪一步、下一步该由谁做什么”，而不是“这个缺陷修得快不快”。
按行业通行实践，一个缺陷通常经历以下七个阶段：
- 发现与记录：测试、用户或监控发现异常，形成一条可追踪的缺陷记录。
- 确认与分类：判断这是否是有效缺陷，归入相应模块、版本和类型。
- 分派与受理：指定修复责任人，责任人确认接收并纳入排期。
- 修复与提交：开发定位原因、修改代码或配置，提交修复并附说明。
- 验证与回归：测试在目标版本上复现原场景，并检查相关功能是否受影响。
- 关闭或重新打开：验证通过则关闭；验证失败则重新打开，回到修复环节。
- 归档与复盘：缺陷进入历史记录，必要时纳入质量复盘，沉淀为改进项。
阶段数量因团队流程而异。小型团队常把“确认与分类”和“分派与受理”合并为一个状态，把“归档与复盘”放在关闭之后单独处理；流程较重的团队则可能拆出“待评审”“待发布验证”等中间状态。划分粗细不影响核心逻辑，关键是每个状态都有清晰的进入条件和退出条件。
缺陷生命周期的边界：哪些内容不属于生命周期
缺陷生命周期关注两件事：状态如何流转，以及每个状态下允许哪些处置动作。超出这个范围的问题，通常属于相邻的管理主题，混在一起讨论容易让流程设计失焦。
单个缺陷的修复进度属于修复与验证跟踪范畴。某个缺陷卡在开发环节三天、某位开发手上有多少待修缺陷、修复预计何时完成，这些是进度问题。生命周期只规定“修复中”这个状态存在、由谁负责、什么条件下可以流转到“待验证”，不负责衡量快慢。
流程系统的状态机配置属于研发平台配置与治理范畴。在工具中定义有哪些状态、状态之间允许哪些跳转、谁能执行跳转、跳转时哪些字段必填，这些是平台配置工作。生命周期提供的是业务规则，配置是把规则落到系统里的实现动作。
缺陷与需求、任务的边界也需要分清。需求描述要做什么，任务描述某项工作如何推进，缺陷描述已有交付物与预期之间的偏差。三者可以互相关联，例如缺陷关联到引入它的需求或对应的测试用例，但缺陷的生命周期只描述缺陷自身的状态序列，不描述需求的评审流程或任务的执行流程。
判断一个问题是否属于生命周期范畴，可以用一个简单标准：它是否在描述“缺陷处于哪个状态、依据什么条件进入下一个状态”。符合则属于，不符合则多半属于进度跟踪、平台配置或度量分析。
每个阶段的准入条件、责任人与产出
生命周期能否稳定运转，取决于每个阶段是否有可核验的准入条件、明确的责任角色和可交接的产出物。下表按典型七阶段给出对照，团队可据此检查自己的流程是否缺项。
| 阶段 | 准入条件 | 主要责任角色 | 关键字段与产出 | 常见流转触发 |
|---|---|---|---|---|
| 发现与记录 | 观察到与预期不符的现象 | 报告人（测试、用户、值班人员） | 标题、复现步骤、实际结果与预期结果、环境与版本、截图或日志 | 提交缺陷记录 |
| 确认与分类 | 记录信息足以判断现象可复现 | 测试负责人或缺陷负责人 | 有效性结论、所属模块、缺陷类型、严重程度、优先级 | 确认有效并分类，或判定重复、非缺陷后拒绝 |
| 分派与受理 | 缺陷已确认且归属模块明确 | 缺陷负责人、开发责任人 | 指派人、计划修复版本、受理结论 | 指派后由责任人确认接收；无法处理则退回并说明理由 |
| 修复与提交 | 责任人已受理并完成原因定位 | 开发责任人 | 原因说明、修复说明、影响范围、关联代码提交或版本 | 提交修复，流转至待验证 |
| 验证与回归 | 修复已进入可测试的构建或环境 | 测试人员 | 验证结论、回归范围、验证环境与版本 | 验证通过流转至关闭；验证失败流转至重新打开 |
| 关闭或重新打开 | 验证结论已给出 | 测试人员、缺陷负责人 | 关闭原因、重新打开原因、再次修复的版本 | 关闭为终态；重新打开则回到分派或修复环节 |
| 归档与复盘 | 缺陷已关闭并进入历史记录 | 缺陷负责人、质量负责人 | 归档标记、复盘结论、改进项 | 按版本或周期汇总，形成质量改进输入 |
几个字段需要特别说明。复现步骤是“发现与记录”阶段最关键的产出，信息不足会直接导致确认阶段反复退回。严重程度和优先级通常在确认与分类阶段确定，前者描述影响，后者描述排期，二者不必一致。修复说明是开发向测试交接的核心内容，缺少原因说明会让验证只能靠猜。验证结论必须写明验证的环境和版本，否则关闭依据无法追溯。
状态流转的触发动作应当与角色绑定：报告人只能提交，测试可以确认、验证和关闭，开发可以提交修复，缺陷负责人可以分派和调整优先级。谁在什么条件下能推动状态变化，是流程规则的一部分，也是后续在工具中配置流转权限的依据。
当团队把上述规则落到研发管理工具中时，缺陷通常作为一种工作项承载状态与字段。ONES Project 面向研发团队的缺陷管理等场景，支持一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况，并可统计缺陷状态分布；在采用 ONES ALM 方案的场景中，测试用例、缺陷、版本和发布过程会关联到需求链路，便于在出现问题时定位影响范围。这些能力承载的是状态与字段的管理动作，具体状态集合与流转规则仍需团队按自身流程定义。
缺陷状态与缺陷严重程度、优先级的区别
这三个字段经常被混用，实际描述的是不同维度。状态回答“流程走到哪一步”，严重程度回答“影响有多大”，优先级回答“先修哪一个”。
| 字段 | 回答的问题 | 典型取值 | 谁来设定 | 变化频率 |
|---|---|---|---|---|
| 状态 | 缺陷处于生命周期的哪一步 | 新建、已确认、修复中、待验证、已关闭、重新打开 | 按流转规则由对应角色推进 | 随处置动作变化 |
| 严重程度 | 缺陷对业务或系统的影响程度 | 致命、严重、一般、轻微 | 测试或缺陷负责人在确认阶段判定 | 相对稳定，影响评估变化时调整 |
| 优先级 | 修复排期的紧迫性 | 紧急、高、中、低 | 缺陷负责人结合版本计划确定 | 随排期和资源情况调整 |
严重程度与优先级不一致是正常现象。一个影响面很小的显示错误可能严重程度为轻微，但因为它出现在对外演示页面上，优先级会被临时调高；反过来，一个严重程度为严重的边缘场景缺陷，可能因为触发条件极难出现而排在较低优先级。把两者强行绑定，会让排期失去弹性。
终态与分级字段的关系也需要理清。关闭表示缺陷已完成处置并验证通过；拒绝表示经确认不属于有效缺陷，例如重复提交、预期行为或环境问题；延期表示当前版本不修复，留待后续版本处理。拒绝和延期都不是“关闭”的同义词，它们各自有独立的判定依据和责任人，混用会让质量统计失真。状态记录的是处置结论，分级字段记录的是缺陷本身的属性，二者在报表中应分开统计。
一个缺陷走完生命周期的具体例子
以下为演示情景，用于说明阶段流转，不代表任何具体团队的真实记录。
某版本回归测试中，测试人员发现订单详情页在优惠券叠加场景下金额显示错误。他提交缺陷，填写复现步骤、测试环境、账号与订单号，附上截图，状态为“新建”。
缺陷负责人当天确认该现象可稳定复现，判定为有效缺陷，归入订单模块，严重程度定为严重，优先级定为高，指派给负责订单计算的开发，状态变为“已确认”。开发确认接收，将缺陷纳入当前迭代，状态变为“修复中”。
开发定位到优惠券抵扣顺序的计算逻辑问题，修改后提交修复，在缺陷中写明原因、修改点和影响范围，状态变为“待验证”。测试在包含该修复的构建上按原步骤复现，确认金额正确，同时回归了不使用优惠券、单张优惠券等相关场景，填写验证结论与验证版本，状态变为“已关闭”。
如果验证时发现金额仍然错误，测试会重新打开缺陷，写明失败现象和新的复现信息，状态回到“修复中”，开发再次修复后重新进入验证。重新打开的次数本身是有价值的质量信号，说明首次修复没有覆盖根因或影响范围评估不足。
缺陷关闭后进入归档，按版本汇总时被纳入质量复盘：该问题源于计算逻辑缺少边界用例，团队据此补充了对应的自动化用例。归档与复盘不是流程的装饰环节，它把单个缺陷转化为流程和用例的改进输入。
围绕这个例子，常见的误解有几类：
- 把关闭当作终点。关闭是处置终态，但缺陷仍需归档并在复盘中产生价值；对反复出现的问题，关闭之后还应触发改进项。
- 跳过验证直接关闭。开发提交修复后自行关闭，会让“已修复”与“已验证”混为一谈，回归失败时无法区分是修复无效还是验证缺失。
- 状态与分级混用。用“严重”作为状态名，或用优先级代替状态描述流程位置，会导致流转规则无法定义，统计口径也会混乱。
- 把拒绝当作关闭。拒绝需要写明判定依据并由相应角色确认，否则被拒绝的缺陷会从视野中消失，真实问题可能被掩盖。
- 重新打开不写原因。只改状态不补充失败信息，开发无法判断问题出在修复不完整还是环境差异，容易形成来回推诿。
把这套阶段、条件与角色对照到自己的流程中，检查每个状态是否都有准入条件、责任人和产出物，就能判断缺陷生命周期是否完整。阶段命名可以不同，状态可以合并，但这三项要素缺一项，缺陷的推进就会依赖个人经验而非稳定规则。
常见问题
缺陷状态可以合并或精简吗？合并后要注意什么？
可以合并。小型团队常把“确认与分类”和“分派与受理”合并为一个状态，或把“待验证”并入“修复中”，减少交接次数。合并后需要守住两点：一是合并后的状态仍要写明由谁负责、什么条件下可以离开；二是原本分属两个阶段的字段不能丢，例如确认阶段的严重程度、优先级判定和分派阶段的计划修复版本，仍要在合并状态内填写完整。合并的代价是状态粒度变粗，统计缺陷在各环节停留时长时会不够细，团队需要根据是否要做过程度量来决定合并程度。
缺陷被拒绝或延期后，还需要继续跟踪吗？
需要保留记录并说明依据。拒绝表示经确认不属于有效缺陷，例如重复提交、预期行为或环境问题；延期表示当前版本不修复、留待后续版本处理。两者都不是关闭，应有独立的判定依据和确认人。被拒绝的缺陷如果直接删除或从视野中消失，真实问题可能被掩盖；被延期的缺陷应保留在待处理列表中，随版本计划重新评估。在质量统计中，拒绝、延期与关闭应分开计数，否则缺陷关闭率、遗留缺陷数等口径会失真。
重新打开的缺陷要不要重新走一遍确认与分派？
通常不需要重新确认有效性，但需要补充失败信息并明确责任人。重新打开时应写明验证失败的现象、复现步骤、验证环境和版本，让开发能判断问题出在修复不完整、影响范围评估不足还是环境差异。状态可以直接回到修复环节，指派给原开发或当前模块负责人。如果重新打开时发现原判定有误，例如问题实际属于另一个模块，则按新缺陷处理或重新分类。重新打开的次数是有价值的质量信号，建议在复盘中关注高频重新打开的模块和缺陷类型。
团队刚开始梳理缺陷流程，应该先定状态还是先定字段？
建议先定状态序列和每个状态的准入、退出条件，再定字段。状态决定缺陷在流程中的位置和交接点，字段是支撑判断的信息。顺序上可以先画出从提交到关闭的主干状态，明确每个状态的责任角色和流转触发动作，然后为每个状态列出进入下一状态所必需的字段，例如提交时必须有复现步骤和环境版本，验证通过必须有验证结论和验证版本。字段按“缺了就无法判断能否流转”的标准取舍，避免一次堆砌过多必填项导致提交成本过高。规则确定后，再到研发管理工具中配置状态与流转权限。
缺陷和需求、任务在流程上如何衔接而不互相混淆？
三者各自有独立的状态序列，通过关联关系衔接。需求描述要做什么，任务描述某项工作如何推进，缺陷描述已有交付物与预期之间的偏差。实践中可以让缺陷关联到引入它的需求、对应的测试用例和修复所在的版本，便于定位影响范围；但缺陷的状态只反映缺陷自身的处置进度，不随需求评审或任务执行的状态变化。团队在工具中可以把它们作为不同类型的工作项管理，共享项目、迭代和版本等上下文，同时保持各自的状态机独立。
