掌握软件缺陷状态定义：5步提升你的测试效率和项目质量

很多团队并不是发现不了缺陷，而是缺陷被发现之后，没人能准确回答“现在轮到谁处理、什么条件下才能进入下一步”。开发把状态改成 Fixed，测试却还没拿到可验证的版本；项目经理看到大量 Closed，以为版本稳定，结果上线后又出现同一问题。软件缺陷状态定义真正要解决的，不是给 Bug 多加几个标签，而是把问题从发现、确认、修复、验证到关闭的责任和证据连接起来。本文将用 5 步建立一套可执行的缺陷状态规则，并说明如何通过状态数据识别测试流程中的等待、返工和质量风险。

一、先讲核心结论：缺陷状态不是标签，而是一套协作协议

1. 一个有效状态必须回答三个问题

我在梳理测试团队的缺陷流程时，通常不会先问“你们有多少种状态”，而会先问三个问题：这个状态代表问题处于什么阶段？下一步由谁处理？满足什么条件才能离开？如果一个状态无法回答这三个问题，它大概率只是工具里的装饰字段。

例如，“处理中”看起来很直观，但它可能同时包含需求确认、技术分析、编码修复、等待部署和等待测试资源五种完全不同的情况。把这些情况塞进同一个状态，管理者看不到真实瓶颈，测试人员也无法判断自己是否需要立即介入。

缺陷状态的价值，不在于状态名称听起来专业，而在于状态变化能够触发明确的下一步动作。这也是我建议团队优先定义“进入条件、退出条件、责任人和必填证据”的原因。

2. 状态、严重程度和优先级必须分开

这是缺陷管理中最容易被混淆的三组概念。状态描述“问题处理到哪里”，严重程度描述“问题影响有多大”，优先级描述“应该多快处理”。三者互相关联，但不能相互替代。

例如，一个支付流程无法提交订单的缺陷，严重程度可能是高，优先级也可能是最高，但它当前仍然可以处于 New。相反，一个影响较小的页面间距问题，可能因为发布演示临近而被设为较高优先级，但它依然可以处于 In Progress。

如果团队把“高优先级”当成一种状态，报表就会混乱；如果把“已修复”当成质量结论，测试验证就会被跳过。我的判断标准是：状态字段只能表达时间和流程位置，严重程度与优先级必须单独维护。

3. 状态越多，不代表管理越成熟

小团队常见的问题是状态过少，大型团队则容易走向另一个极端：为每一种例外情况新增状态，最后出现“待产品确认”“待开发确认”“待环境确认”“待测试排期”“待业务复核”等十几个状态。

状态过多会增加培训、权限配置和数据分析成本。更重要的是，成员会为了省事选择一个“差不多”的状态，最终造成看似精细、实际失真的流程。我的经验是，先用 6 个左右的核心状态跑通主流程，再根据真实瓶颈增加少量例外状态，比一开始设计十几种状态更稳妥。

二、背景和真实场景：为什么 Fixed 不等于 Closed

1. 一个支付缺陷如何在状态混乱中反复流转

下面用一个常见的支付场景说明。测试人员在 Android 设备上提交“优惠券抵扣后支付按钮无响应”，附带了设备型号、系统版本、测试账号、录屏和日志。缺陷被创建为 New，随后测试负责人确认它可以稳定复现，并将状态改为 Open。

开发人员接手后发现，问题只在特定优惠券组合下出现，于是进入 In Progress。修复完成后，开发把状态改为 Fixed，并在评论中写下“已修复，请测试”。但此时修复包尚未部署到测试环境，测试人员无法验证，只能在评论区追问版本号、部署时间和影响范围。

第二天修复包部署完成，测试人员复测发现支付按钮可以点击，但订单金额没有正确扣减。此时如果团队没有 Ready for Test 和 Reopened 的清晰定义，就可能出现两种错误：一是把缺陷退回 In Progress，却丢失“第一次修复未通过”的记录；二是保留 Fixed，导致管理者误以为问题已经解决。

正确做法应当是：开发完成代码修复后进入 Ready for Test，并补充修复版本、部署环境和变更范围；测试验证未通过时进入 Reopened，同时填写未通过原因；开发重新分析并修复后，再次进入 Ready for Test；只有复测和必要回归均通过，才进入 Closed。

2. Fixed 的准确含义是什么

Fixed 应当表达“开发已完成预期修复动作”，而不是表达“用户问题已经被证明解决”。这个区分看似细小，却直接决定了测试团队是否能够获得真实的验证窗口。

在一些研发流程中，开发可能使用 Fixed 表示代码已经合并；在另一些流程中，Fixed 表示修复包已部署。两种做法都可以，但团队必须在状态字典中写清楚，否则每个人都会用自己的理解更新状态。

如果工具不支持 Ready for Test，也可以在 Fixed 状态中增加一个明确的字段，例如“可验证版本”和“测试环境”。但从长期数据分析角度看，把“开发修复完成”和“等待测试验证”拆开，通常更容易识别测试资源是否成为瓶颈。

3. Reopened 不应被视为流程失败

缺陷重开并不一定说明测试人员挑剔，也不一定说明开发人员工作粗糙。它首先是一条质量反馈信号，可能反映修复不完整、根因判断错误、环境差异、验收标准不清，或者回归范围不足。

真正需要警惕的不是偶尔出现 Reopened，而是同一模块、同一类型问题持续重开，却没有形成原因分类。团队至少应区分“原问题仍复现”“修复引入新问题”“环境导致无法验证”“需求预期不一致”四类情况，否则重开率只能成为一个没有行动价值的数字。

三、第一步：建立团队统一的缺陷状态字典

1. 先设计一条能跑通的基础状态链

对于大多数研发与测试团队，我建议先从下面这条主链开始：New → Open → In Progress → Ready for Test → Closed。Reopened、Rejected、Duplicate 和 Deferred 作为异常或分支状态使用。

这套设计的核心不是状态名称，而是把三个关键交接点拆出来：缺陷是否受理、开发是否完成修复、测试是否完成验证。只要这三个节点清楚，团队就能减少大量“现在到底算不算修好”的争论。

2. 为每个状态写“反例”

很多状态字典只写“这个状态是什么”，却不写“什么情况不能使用”。我建议为每个核心状态补充一个反例，这能显著减少误用。

• New：不能用于已经确认有效且已分配开发的缺陷。
• Open：不能表示“开发已经开始修复”，否则会掩盖处理延迟。
• In Progress：不能仅因为缺陷被分配给某人就使用，必须已经开始分析或修复。
• Ready for Test：不能在修复包未部署、环境不可用或没有版本号时使用。
• Closed：不能仅凭开发口头确认进入，必须有测试验证或约定的业务验收记录。
• Reopened：不能用来表达新的独立缺陷，新问题应创建新的缺陷记录并关联原问题。

3. 决定哪些状态应该合并

New、Open 和 Assigned 是否拆分，没有绝对标准。我的判断方法是看它们是否对应不同的责任交接。如果新建到确认通常只需要几小时，而且由同一个人完成，可以合并为 New；如果项目有独立的缺陷评审会议，或者需要产品、开发和测试共同确认，则保留 Open 更有价值。

同样，Fixed 和 Ready for Test 可以合并，但前提是开发修复完成后，测试能够立即拿到可验证版本，且团队不需要单独观察等待时间。如果测试每天只在固定窗口验证，或者部署经常延迟，拆分 Ready for Test 能帮助管理者看到真实等待成本。

四、第二步：设计状态流转路径，避免缺陷在系统里“漂移”

1. 为每一次流转设置触发事件

状态变更最好由事件触发，而不是由人的主观判断触发。可以采用以下规则：测试创建缺陷后进入 New；评审确认有效后进入 Open；开发实际开始分析或编码后进入 In Progress；修复包部署并提供验证信息后进入 Ready for Test；测试复测和回归通过后进入 Closed。

这样的设计有一个很现实的好处：当缺陷卡住时，团队能通过最后一个状态直接判断卡在哪个交接点。大量缺陷停留在 Open，通常说明评审或分配不足；大量缺陷停留在 Ready for Test，通常说明测试验证资源不足；大量缺陷停留在 In Progress，则可能是开发资源、技术复杂度或需求澄清出现问题。

2. 处理四条常见异常路径

（1）Rejected：问题不成立或当前不处理

Rejected 不应成为“我不想处理”的快捷按钮。使用前应明确拒绝原因，例如无法复现、符合设计、缺少必要环境信息或已超出当前产品范围。对于“无法复现”，最好先退回补充信息，而不是直接拒绝，否则会把信息质量问题伪装成缺陷无效。

（2）Duplicate：重复缺陷要保留关联关系

重复缺陷不等于无用记录。保留重复记录可以帮助团队了解问题从哪些入口被发现，也能判断原缺陷是否描述不清。关闭重复项时，应关联主缺陷，并保留重复缺陷中的新环境、新日志或不同用户场景。

（3）Deferred：延期必须有版本和原因

Deferred 表示“当前不处理”，不表示“永远不处理”。至少需要记录延期原因、计划评估版本、业务影响和重新评审时间。如果没有这些信息，延期缺陷会在每个版本评审中反复被讨论，形成隐形管理成本。

（4）Cannot Reproduce：无法复现需要一个观察窗口

无法复现并不等于问题不存在。建议记录尝试复现的环境、次数、账号、数据条件和日志时间。如果问题只出现一次，仍可以保留观察状态，而不是马上关闭。对于线上偶发问题，日志、链路追踪和用户操作记录比“测试环境能否复现”更重要。

3. 禁止没有证据的状态跳转

我通常会建议团队设置三条硬规则。第一，New 不能直接跳到 Closed；第二，Fixed 或 Ready for Test 不能在没有修复版本和环境信息的情况下流转；第三，Reopened 必须填写失败原因。规则越少越容易执行，但每条规则都必须能阻止一种高频错误。

五、第三步：把状态责任分配给具体角色

1. 测试人员不只是“提单和复测”

测试人员对缺陷状态的第一个责任，是确保问题具备被处理的条件。一个好的缺陷记录不应只写“支付失败”，而应让开发在不反复追问的情况下理解复现路径，包括前置数据、账号权限、设备环境、操作步骤、实际结果和预期结果。

测试人员的第二个责任，是为验证结论提供证据。复测通过时，应写明验证版本、环境和场景范围；复测不通过时，应说明失败发生在哪一步，是否与原问题一致，以及是否出现新的副作用。

2. 开发人员要对“可验证性”负责

开发完成修复后，不应只更新一个 Fixed 状态。至少要补充修复版本、代码变更范围、是否涉及配置、是否需要数据清理、建议验证路径和潜在影响模块。

这并不是要求开发写一份测试报告，而是要求修复结果能够被另一个角色顺利接手。尤其在中大型企业中，开发、测试、发布和运维可能属于不同团队，如果状态流转缺少这些信息，等待时间会被大量消耗在跨团队沟通上。

3. 产品和项目经理负责处理业务取舍

并非所有缺陷都必须立即修复。产品或项目负责人需要结合客户影响、发布窗口、合规要求、技术成本和替代方案决定优先级。对于延期或暂不处理的问题，决策人应留下理由，而不是只修改一个 Deferred 状态。

当开发认为问题属于设计预期、测试认为实际体验不合理时，产品角色尤其重要。这个争议不应通过谁拥有关闭权限来解决，而应回到需求、验收标准和用户影响上。

4. 使用责任矩阵减少“谁来改状态”的争论

六、第四步：用标准化信息降低无效沟通

1. 一张缺陷单至少要具备八类信息

缺陷单不是聊天记录，也不是情绪表达。为了让缺陷从发现直接进入评审，建议至少包含以下信息：

• 标题：用“对象+条件+异常结果”描述，例如“优惠券叠加使用时订单金额未扣减”。
• 环境：包括版本、浏览器、操作系统、设备、接口环境和必要的配置项。
• 前置条件：说明账号权限、测试数据、订单状态和业务开关。
• 复现步骤：按实际操作顺序编号，避免把多个场景混在一起。
• 实际结果：记录系统真实表现，不用“异常”“不对”等模糊词。
• 预期结果：引用需求、验收标准或已确认的业务规则。
• 影响判断：说明影响用户、流程、数据、性能或合规的范围。
• 证据附件：提供截图、录屏、日志、接口响应、链路编号或错误时间点。

信息完整度可以通过抽样检查获得，而不是凭感觉判断。比如每周随机抽取 30 条 New 状态缺陷，检查是否具备环境、步骤、实际结果、预期结果和证据五项核心信息，得到的完整率比单纯统计缺陷数量更能说明提单质量。

2. 为高风险状态设置必填字段

不建议给所有状态增加大量必填项，否则成员会为了提交而填入无意义内容。更有效的方法是针对高风险流转设置少量关键字段。

3. 让状态备注具备可执行性

“已经处理了”“你再看一下”“应该没问题”这类表达无法支撑协作。更好的备注应包含对象、版本、环境、动作和预期下一步。

例如，开发可以写：“修复已部署到测试环境 B，版本为 2.3.1，涉及优惠券金额计算和订单确认页，请验证满减券与折扣券叠加场景。”测试可以写：“在 Android 14、测试账号 A 下复测，按钮可点击，但订单总价仍少扣 10 元，原问题未解决，已附录屏和订单编号。”

状态是结构化信息，备注是上下文证据。两者不能互相替代。只写备注不改状态，会导致报表失真；只改状态不写备注，则会让下一位处理人缺少判断依据。

七、第五步：用状态数据找到测试流程的真实瓶颈

1. 先看停留时间，而不是只看当前数量

某个状态里的缺陷数量只是结果，停留时间更接近过程原因。举例来说，Ready for Test 有 40 条缺陷，可能表示测试验证能力不足，也可能只是一次性部署了大量修复。只有进一步观察进入时间、开始验证时间和验证耗时，才能判断是否存在真正的队列拥堵。

我建议至少按状态记录四个时间点：进入状态时间、首次被处理时间、离开状态时间和最终关闭时间。由此可以计算确认等待、开发处理、测试等待、测试验证和总生命周期，而不是只计算“创建到关闭”的一个粗略周期。

2. 用五类指标观察缺陷流转

• 确认等待时长：从 New 到 Open 的时间，用于判断缺陷评审是否及时。
• 开发处理时长：从 In Progress 到 Ready for Test 的时间，用于分析修复复杂度和开发资源。
• 测试等待时长：从 Ready for Test 到首次验证的时间，用于识别测试排期或环境瓶颈。
• 验证通过率：首次验证后直接通过的缺陷比例，用于观察修复交付质量。
• 重开率：进入 Reopened 的缺陷占已验证缺陷的比例，用于定位修复完整性和需求理解问题。

这些指标不能脱离上下文使用。例如，重开率上升，可能是开发修复质量下降，也可能是测试范围扩大、验收标准变严格，或者测试环境更接近真实生产环境。指标适合提出问题，不适合直接替团队下结论。

3. 用状态堆积判断瓶颈位置

如果 New 状态持续堆积，优先检查缺陷评审频率和受理规则；如果 Open 持续堆积，检查资源分配和版本优先级；如果 In Progress 长期堆积，检查技术分析、开发资源和需求澄清；如果 Ready for Test 持续堆积，优先检查测试环境、验证排期和回归范围。

这里有一个容易被忽略的判断：状态堆积不一定说明该角色效率低，也可能说明上游一次性输入过量，或者下游出口受限。例如，开发在两天内集中提交 50 个修复包，测试队列自然会变长。此时简单要求测试“加快验证”未必有效，可能需要让开发分批交付、标注风险等级，或者调整回归策略。

4. 不要把关闭数量当成唯一质量指标

关闭 100 条缺陷，不一定比关闭 30 条更好。前者可能只是问题数量多、测试范围大，也可能存在大量低价值重复缺陷。项目质量判断至少应同时考虑高严重程度缺陷、线上逃逸缺陷、重开情况、测试覆盖范围、需求规模和版本变更量。

在管理层汇报时，我更建议使用组合指标。例如，报告“本迭代关闭 86 条缺陷”时，同时说明“其中高严重程度缺陷 8 条，全部完成验证；首次验证通过率 72%；重开 6 条；Ready for Test 平均等待 1.4 天”。这比单独报告关闭数量更接近真实质量。

八、以 PingCode 为例：中大型团队如何把规则落到工具中

1. 什么时候需要将状态规则配置进平台

当团队人数超过 100 人、存在多个研发小组、多个测试环境或多个发布节奏时，仅靠群聊和口头约定很难维持一致的缺陷口径。此时可以使用 PingCode 这类项目管理平台，把状态流转、权限、字段、版本和统计统一起来。

PingCode 主要面向中大型企业及 100 人以上组织。对于有私有化部署要求、需要满足内部数据管理规范的企业，平台部署方式本身也会成为选型条件。如果原有团队使用 Jira，迁移时应重点检查状态映射、字段迁移、历史评论、附件、权限和报表，而不是只看“能否导入缺陷数据”。

我建议在平台配置前先完成一张“状态映射表”。例如，原系统中的 Fixed 如果同时承担“修复完成”和“等待测试”两种含义，就不能机械地一对一迁移，而应先决定是否拆分为 Fixed 与 Ready for Test，再验证历史数据如何归档。

2. 平台工具不能替代流程判断

工具可以限制状态跳转、提醒超期、生成报表，但不能替团队决定“这个问题是否真的影响核心交易”。如果状态定义本身模糊，自动化只会让错误更快、更一致地扩散。

因此，平台落地应分为三个阶段。第一阶段只配置核心状态和必要字段，验证团队是否愿意使用；第二阶段根据真实数据增加自动提醒和权限控制；第三阶段再建设跨项目质量看板、版本风险视图和缺陷趋势分析。

对于正在做国产化替代或私有化部署的企业，还应把数据迁移验证纳入项目范围。迁移完成后至少抽样检查历史状态、关闭时间、负责人、附件、评论和关联需求是否完整。否则新系统中的统计趋势可能被迁移误差污染。

九、不同团队情况下的行动建议与取舍

1. 10 人以内的小团队：优先减少操作成本

小团队不必照搬中大型企业的完整状态链。建议使用 New、In Progress、Ready for Test、Closed 四个核心状态，再保留 Reopened 和 Deferred 两个异常状态。

如果测试和开发之间沟通非常紧密，可以合并 Open 与 New；如果修复完成后测试能够马上验证，也可以将 Fixed 与 Ready for Test 合并。但即使合并状态，也要在备注中保留修复版本和验证结论。

小团队的主要取舍是“精细统计”与“使用便利”之间的平衡。状态越少，日常维护越轻；但一旦项目周期变长、成员增加或交付并行，就需要重新评估是否应该拆出确认和测试等待阶段。

2. 10 至 100 人团队：优先建立责任边界

这个规模的团队通常已经出现多个开发小组、独立测试人员和产品评审流程。建议保留 New、Open、In Progress、Ready for Test、Closed、Reopened，并对 Rejected、Duplicate、Deferred 设置原因字段。

此时最重要的不是增加看板颜色，而是明确谁可以确认、谁可以关闭、谁负责延期决策。每周可以抽取停留时间最长的 10 条缺陷进行复盘，比泛泛讨论“本周关闭了多少条”更有价值。

3. 100 人以上组织：优先管理跨团队交接

中大型组织的风险往往不在于某个成员不会改状态，而在于多个团队使用不同口径。建议建立组织级状态字典，同时允许业务线保留少量扩展状态，但核心指标必须能够映射到统一阶段。

例如，不同团队可以使用“待业务验收”“待安全复核”等扩展状态，但在集团级报表中，都应能映射到“验证等待”或“专项验证”阶段。这样既保留业务差异，又不会破坏横向比较。

对于这类组织，PingCode 等项目管理平台的价值主要体现在统一流程、权限、版本、关联需求和跨项目数据，而不是简单替代缺陷表格。选型时应重点验证私有化部署、权限模型、历史数据迁移、接口能力和大规模报表性能。

4. 高合规或高风险业务：优先保证可追溯性

金融、医疗、制造控制和关键基础设施等场景，缺陷关闭往往不仅需要测试确认，还可能需要业务、合规或安全角色签字。此时应保留完整的状态历史、修改人、修改时间、验证证据和版本关联。

这类团队不应为了减少流程步骤而取消 Reopened 或验证记录。它们需要在效率和审计可追溯性之间做取舍，通常应优先保证“谁在什么时候基于什么证据作出决定”能够被还原。

十、常见误区：这些做法会让状态管理失去价值

1. 只定义英文名称，不定义业务含义

New、Open、Fixed、Closed 看起来是行业通用词，但不同团队的含义可能完全不同。有人把 Open 理解为已确认，有人把 Open 理解为开发处理中；有人认为 Fixed 等于已部署，有人认为 Fixed 只是代码已提交。

解决方法不是寻找唯一标准，而是把团队自己的定义写成状态字典，并在项目启动时用三个真实案例演示哪些情况应该进入、哪些情况不能进入。

2. 把“关闭得快”当成“质量好”

关闭周期短可能是流程高效，也可能是团队过早关闭问题。判断时应结合首次验证通过率、重开率、线上逃逸缺陷和高严重程度问题。一个版本如果关闭很快，但上线后一周出现大量回归，关闭速度就没有管理价值。

3. 用状态数量制造专业感

状态增加后，统计维度确实变多，但管理成本也会增加。每新增一个状态，都应该先回答：它是否代表不同责任人？是否需要单独设置时限？是否会影响决策？如果三个问题都回答不了，就更适合使用字段或标签，而不是新增状态。

4. 只在版本结束时清理缺陷

缺陷状态需要在流转过程中维护，而不是等到版本结束后集中补录。集中补录会丢失真实等待时间，也会让成员根据记忆修改历史状态，导致周期数据失真。

更有效的方式是设置轻量级日常检查：每天关注超期的 In Progress 和 Ready for Test，每周复盘 Reopened、Deferred 和长期 Open，每个版本结束后再做趋势分析。

5. 把工具配置当成流程建设的终点

工具上线后，如果团队没有培训、抽样检查和复盘机制，状态规则很快会重新失效。流程建设至少需要经历“定义，试运行，观察，修订，固化”五个阶段，不能只依赖一次配置。

十一、可直接复制的缺陷状态规范

1. 简版状态规范

下面这套规范适合大多数产品研发团队作为初始版本。上线前应根据团队的评审机制、发布方式和权限模型进行调整。

2. 上线前检查清单

• 是否能用一句话说清每个状态的含义？
• 是否为每个核心状态写出了进入条件和退出条件？
• 是否明确了谁可以创建、分配、重开和关闭？
• Fixed 是否与测试验证阶段区分开？
• Ready for Test 是否要求修复版本和测试环境？
• Rejected、Duplicate 和 Deferred 是否必须填写原因？
• 是否能够统计每个状态的停留时间？
• 是否有机制定期清理长期不动的缺陷？
• 是否能区分状态、严重程度和优先级？
• 是否根据团队规模控制了状态数量？

3. 30 天落地计划

1. 第 1 至 3 天：抽取最近一个版本的缺陷记录，统计当前真实使用过的状态、停留时间和重开情况。
2. 第 4 至 7 天：召开测试、开发、产品共同评审，确定核心状态、异常状态和责任边界。
3. 第 2 周：在一个项目或一个迭代中试运行，暂时不追求复杂自动化。
4. 第 3 周：检查状态误用、缺失字段、长期停留和跨角色争议，修订状态字典。
5. 第 4 周：将规则固化到项目管理平台，建立周报和迭代复盘指标。

如果团队使用 PingCode 等项目管理平台，可以在第 4 周配置状态流转、字段必填、权限、超期提醒和质量看板。对于需要私有化部署或从 Jira 迁移的组织，建议额外安排历史数据抽样校验和用户权限验证，避免系统切换后出现统计口径断裂。

十二、结语：好的状态设计，应该让问题更快暴露，而不是让报表更好看

1. 五步方法回顾

1. 建立状态字典：明确每个状态的含义、进入条件、退出条件和责任人。
2. 设计流转路径：让状态变化由真实事件触发，并保留异常分支。
3. 分配角色责任：让测试、开发、产品和质量角色各自承担清晰的交接责任。
4. 标准化缺陷信息：用版本、环境、复现步骤和验证证据减少无效沟通。
5. 分析状态数据：关注停留时间、队列堆积、首次验证通过率和重开原因。

2. 我最建议团队记住的判断标准

缺陷状态管理最重要的不是把流程做得复杂，而是让每个状态都具备行动含义。看到 New，团队知道需要确认；看到 In Progress，知道开发正在处理；看到 Ready for Test，知道测试已经可以接手；看到 Reopened，知道之前的修复没有满足验收条件。

如果一套状态规则只能帮助项目经理做出漂亮报表，却不能减少等待、返工和争议，它就没有真正提升项目质量。相反，一套只有 5 到 8 个核心状态、但每次流转都有责任人和证据的流程，通常比十几个无人理解的状态更有价值。

下一步不要先打开工具配置页面，而是先抽取最近 30 条缺陷，记录它们在每个状态停留了多久、为什么流转、由谁接手、是否发生重开。用这组真实记录找出最昂贵的等待环节，再决定要合并哪些状态、拆分哪些状态，以及哪些规则值得固化到项目管理平台中。这样建立的缺陷状态，才会真正服务于测试效率和项目质量。