缺陷状态是缺陷在处置流程中所处的阶段标记，用来表示这条缺陷当前由谁负责、下一步该做什么。它通常由一组有限的状态值和允许的流转规则组成，例如新建、已确认、处理中、待验证、已关闭，并配合重新打开、拒绝、延期等分支。缺陷状态描述的是流程位置，不描述修复进度细节，也不等于缺陷严重程度或优先级。
要点总览（TL;DR）
- 缺陷状态是缺陷在处置流程中所处的阶段标记，由有限的状态值和允许的流转规则组成，用来表示当前由谁负责、下一步做什么。
- 理解缺陷状态要抓住三个要素：状态值集合、流转规则与责任人、状态与工作项记录的关系。
- 状态与严重程度、优先级、修复进度是不同维度：状态描述流程位置，严重程度描述后果，优先级描述排期，修复进度描述工作量。
- 典型正向路径为新建→已确认→处理中→待验证→已关闭，并通过重新打开、拒绝、延期等分支处理例外情况。
- 状态变化应伴随处理人变更和必要记录，状态集合与流转规则需与团队实际修复流程保持一致。
缺陷状态指什么：一句话定义与核心要素
缺陷状态是缺陷在处置流程中所处的阶段标记，用来表示这条缺陷当前由谁负责、下一步该做什么。它通常由一组有限的状态值和允许的流转规则组成，例如新建、已确认、处理中、待验证、已关闭，并配合重新打开、拒绝、延期等分支。缺陷状态描述的是流程位置，不描述修复进度细节，也不等于缺陷严重程度或优先级。
理解缺陷状态，可以抓住三个核心要素：状态值集合、流转规则与责任人、以及状态与工作项记录的关系。
状态值集合
状态值集合是一个团队为缺陷定义的全部阶段名称。常见的取值包括新建、已确认、处理中、待验证、已关闭，有些团队还会加入已拒绝、已延期、重新打开等分支状态。状态值应当数量有限、含义清晰、彼此不重叠，让每个看到状态的人都能判断这条缺陷处在流程的哪一步。状态值过多会让流转路径变得复杂，过少则难以区分关键阶段，团队需要根据缺陷处理的实际环节来取舍。
流转规则与责任人
流转规则规定哪些状态之间允许转换、由谁执行转换、转换时需要补充什么信息。例如，只有确认缺陷可复现的人才能把“新建”改为“已确认”，只有修复完成并提交代码的人才能把“处理中”改为“待验证”，只有验证通过的人才能把“待验证”改为“已关闭”。流转规则把状态变化与具体角色绑定，使状态成为责任交接的凭据，而不只是一个标签。
状态与工作项记录的关系
缺陷状态依附于缺陷这条工作项记录存在。一条缺陷记录通常包含标题、描述、复现步骤、环境、提交人、当前处理人、状态、严重程度、优先级等字段，状态只是其中一个字段。状态变化往往伴随操作记录、评论、附件和关联提交，这些内容共同构成缺陷的处置轨迹。状态本身回答“现在到哪一步”，记录中的其他信息回答“这条缺陷是什么、有多严重、由谁在什么时候做了什么”。
缺陷状态包括哪些，不包括哪些
缺陷状态只描述流程位置，它的边界需要与几个相邻概念区分清楚。下面用表格对照状态与严重程度、优先级、修复进度和流程配置的差别。
| 概念 | 回答的问题 | 典型取值 | 与缺陷状态的关系 |
|---|---|---|---|
| 缺陷状态 | 这条缺陷现在处在流程的哪一步、由谁负责 | 新建、已确认、处理中、待验证、已关闭 | 本文主题，描述流程位置 |
| 严重程度 | 缺陷造成的后果有多重 | 致命、严重、一般、轻微 | 独立属性，不随状态变化而改变 |
| 优先级 | 团队打算多快处理它 | 高、中、低或P0至P3 | 独立属性，可与状态组合使用 |
| 修复进度 | 修复工作完成了多少 | 百分比、剩余工时、具体改动说明 | 状态之外的细节，不写进状态值 |
| 流程系统配置 | 状态和流转规则如何被平台定义 | 工作流配置、字段配置、权限设置 | 承载状态的系统设置，归其他主题 |
状态与严重程度、优先级的区别
严重程度衡量缺陷造成的后果，优先级衡量团队打算多快处理它，两者都是缺陷的独立属性。一条严重程度为“致命”的缺陷，状态可能仍是“新建”；一条优先级为“低”的缺陷，状态也可能已经进入“处理中”。状态回答流程位置，严重程度和优先级回答影响与排期，三者组合起来才能支撑缺陷的分诊和排序。
状态与单个修复进度的区别
状态是离散的阶段标记，修复进度是连续的工作量描述。“处理中”这个状态可以覆盖从刚定位问题到即将提交修复的整个过程，具体改了什么、还剩多少工作，需要写在评论、提交记录或工时字段里。把“修复了百分之六十”这类信息塞进状态值，会让状态集合膨胀，也会让流转规则失去意义。
状态与流程系统配置的区别
状态值和流转规则是管理概念，流程系统配置是平台层面的实现方式，包括工作流定义、字段配置、权限设置和自动化规则。本文讨论状态的含义、边界和流转机制；研发平台中如何配置工作流、如何设置字段权限，属于流程系统配置与治理的范畴，不在本文展开。
缺陷状态如何流转：典型阶段与规则
缺陷状态的流转机制由典型阶段、正向路径和分支处理三部分组成。团队可以按下面的阶段划分建立自己的状态集合，再根据实际环节增减。
典型状态阶段划分
- 新建：缺陷被提交，尚未经过确认，等待分诊。
- 已确认：缺陷被确认可复现、描述完整，进入待处理队列。
- 处理中：责任人正在定位或修复问题。
- 待验证：修复已提交，等待测试或提交人验证。
- 已关闭：验证通过，缺陷处置完成。
正向流转路径
最常见的正向路径是新建→已确认→处理中→待验证→已关闭。每一步转换都对应一次责任交接：提交人把缺陷交给分诊人，分诊人交给修复责任人，修复责任人交给验证人，验证人确认后关闭。路径清晰的状态集合能让每个参与者知道自己接手时该做什么、交付时该交给谁。
重新打开、拒绝、延期等分支
正向路径之外，缺陷处理还需要分支状态来处理例外情况。验证不通过时，缺陷从待验证回到处理中或重新打开；确认后发现描述不清、无法复现或属于重复提交时，缺陷可以进入已拒绝；因排期或依赖原因暂时不处理时，缺陷可以进入已延期。分支状态让例外情况有明确的落点，避免缺陷在正向路径上被反复推回却无人负责。
流转规则如何约束操作
流转规则通过三件事约束操作：限定允许的状态转换，例如禁止从新建直接跳到已关闭；限定执行转换的角色，例如只有验证人能把待验证改为已关闭；限定转换时的必填信息，例如关闭时必须填写验证结论，拒绝时必须说明理由。规则的作用是让状态变化可追溯、可审计，减少“状态被随手改掉”的情况。规则过严会增加操作负担，过松则失去约束意义，团队需要按缺陷量和协作方式调整。
在工具层面，状态需要承载责任交接和处置记录。ONES Project 支持缺陷跟踪管理，可统计缺陷状态分布，沉淀问题和经验；也支持一键提交 Bug 至对应的项目或迭代中，记录和跟踪缺陷修复情况。团队可以把状态字段与处理人、评论和关联记录结合使用，让每次状态变化都对应一次可查的交接动作。具体状态取值和流转规则需要按团队流程在平台中配置。
缺陷状态与缺陷生命周期、缺陷修复流程的区别
缺陷状态、缺陷生命周期和缺陷修复流程三个概念经常被混用，它们描述的是不同层次的对象。下面的对照说明各自的侧重点。
| 概念 | 描述对象 | 回答的问题 | 与状态的关系 |
|---|---|---|---|
| 缺陷状态 | 单条缺陷在某一时刻的流程位置 | 现在到哪一步、由谁负责 | 生命周期中的节点标记 |
| 缺陷生命周期 | 一条缺陷从提交到关闭的完整过程 | 这条缺陷经历了哪些阶段、如何结束 | 由状态序列和分支路径构成 |
| 缺陷修复流程 | 团队处理缺陷的工作方法与协作约定 | 谁在什么条件下做什么、如何验证 | 状态和流转规则是流程的显性表达 |
缺陷生命周期与状态的关系
缺陷生命周期指一条缺陷从提交、确认、修复、验证到关闭的完整过程，状态是这个过程上的节点标记。生命周期关注整体路径和结束条件，状态关注当前所处的位置。一条缺陷的生命周期可能包含多次重新打开，因此它的状态序列不是简单的一条直线，而是带有回环的路径。理解生命周期有助于设计状态集合，理解状态有助于跟踪单条缺陷的进展。
缺陷修复流程与状态的关系
缺陷修复流程是团队处理缺陷的工作方法与协作约定，包括分诊规则、责任分配、修复标准、验证要求和关闭条件。状态和流转规则是流程的显性表达：流程中约定的交接点，通常对应一个状态转换；流程中约定的角色职责，通常对应流转规则中的执行权限。流程调整时，状态集合和流转规则也应同步调整，否则状态会与团队实际做法脱节。
状态管理与流程治理的边界
状态管理关注状态值是否清晰、流转是否顺畅、责任是否明确；流程治理关注流程是否合理、角色是否匹配、度量是否有效。两者相互关联但层次不同。本文讨论状态的含义、边界和流转机制；流程治理涉及组织分工、度量体系和工作流配置，属于更上层的管理议题，不在本文展开。
一个例子看懂缺陷状态流转与常见误解
下面用一条缺陷的完整处置过程演示状态变化，再澄清几个常见误解。
一条缺陷从提交到关闭的状态变化示例
假设测试人员在回归测试中发现登录页面在弱网环境下偶发超时。这条缺陷的处置过程可以这样展开：
- 测试人员提交缺陷，填写复现步骤、环境和日志，状态为新建，处理人为测试负责人。
- 测试负责人分诊，确认可复现且描述完整，把状态改为已确认，处理人改为后端开发人员。
- 后端开发人员接手，把状态改为处理中，在评论中记录定位到的超时配置问题，并关联修复提交。
- 修复提交后，开发人员把状态改为待验证，处理人改回测试人员。
- 测试人员在弱网环境复测，第一次仍出现超时，把状态改为重新打开并附上新的日志。
- 开发人员再次处理，补充超时重试逻辑，状态回到待验证。
- 测试人员复测通过，填写验证结论，把状态改为已关闭。
这个例子中，状态变化始终伴随处理人变更和记录补充，每次转换都能回答“谁在什么时候把缺陷交给了谁”。严重程度和优先级在这条缺陷上保持独立：严重程度可能定为“一般”，优先级可能因影响登录而调高，它们不随状态变化而改写。
常见误解及纠正
- 误解一：状态越细越好。状态值过多会让流转路径复杂、维护成本上升。状态应覆盖关键交接点，细节放在评论和记录里。
- 误解二：状态等于进度。状态是阶段标记，“处理中”不说明修复完成了多少，进度需要另外记录。
- 误解三：状态可以随意改。状态变化应遵循流转规则并留下记录，否则责任交接和后续追溯都会失去依据。
- 误解四：关闭就是终点。验证不通过时缺陷可以重新打开，关闭表示本次处置完成，不代表问题永远不会再出现。
- 误解五：状态和严重程度是一回事。状态描述流程位置，严重程度描述后果，两者独立取值、组合使用。
状态使用中的注意事项
使用缺陷状态时，团队需要约定状态值的含义和流转规则，并让规则与实际的修复流程保持一致。状态变化应尽量伴随处理人变更和必要记录，使交接可追溯。定期查看状态分布，可以发现长期停留在某一阶段的缺陷，及时调整分诊和排期。状态集合和流转规则属于团队约定，不同团队可以根据缺陷量、协作方式和验证要求做不同设计，没有统一的标准答案。
常见问题
缺陷状态设置多少个比较合适？
数量取决于团队需要区分的关键交接点，没有统一标准。常见做法是覆盖新建、已确认、处理中、待验证、已关闭这几个阶段，再按需要补充重新打开、已拒绝、已延期等分支。判断标准是：每个状态是否对应一次明确的责任交接，以及是否有人能据此判断下一步动作。状态过多会让流转路径和维护成本上升，过少则难以区分关键阶段，可以先用最小集合运行一段时间，再根据实际卡点增减。
缺陷被拒绝后还能重新处理吗？
可以，但需要团队事先约定规则。已拒绝通常用于描述不清、无法复现或重复提交等情况，如果后续补充了复现信息或确认并非重复，缺陷可以从已拒绝回到新建或已确认重新进入流程。关键在于拒绝时必须写明理由，重新打开时说明新增信息，让状态变化有据可查。若团队希望已拒绝作为终态，也应在流程约定中明确，避免同一类情况出现两种处理方式。
缺陷状态和缺陷生命周期是一回事吗？
两者相关但层次不同。缺陷生命周期指一条缺陷从提交到关闭的完整过程，关注整体路径和结束条件；缺陷状态是这个过程上的节点标记，关注当前所处的位置。一条缺陷的生命周期可能包含多次重新打开，因此状态序列不是一条直线，而是带有回环的路径。设计状态集合时参考生命周期有助于覆盖关键阶段，跟踪单条缺陷进展时则看当前状态和流转记录。
状态流转规则定得很严，会不会影响处理效率？
规则过严确实会增加操作负担，例如每次转换都要求填写大量必填项、限定过细的角色权限。比较务实的做法是只在关键交接点设约束：关闭时要求填写验证结论，拒绝时要求说明理由，其余转换保留必要的操作记录即可。规则强度可以随缺陷量和协作方式调整，缺陷量大、参与角色多的团队更需要明确约束，小团队可以适当简化。定期回看状态停留时间和返工情况，能帮助判断规则是否合适。
团队用工具管理缺陷状态时要注意什么？
工具层面的重点是让状态变化可追溯。以 ONES Project 为例，它支持缺陷跟踪管理，可统计缺陷状态分布，沉淀问题和经验，也支持一键提交 Bug 至对应的项目或迭代中，记录和跟踪缺陷修复情况。团队在配置时，应把状态字段与处理人、评论和关联记录结合使用，使每次状态变化对应一次可查的交接动作；具体状态取值和流转规则需要按团队流程在平台中配置，并与实际修复流程保持同步。
