瀑布阶段验收：缺陷门槛与交付物完整性怎么设

瀑布阶段验收要回答两个问题：质量状态是否达到约定水平，阶段成果是否齐备且受控。本文把验收标准拆成缺陷门槛和交付物完整性门槛两条独立判定线，给出可复算的公式、分母口径、核对表和五步评估流程，并用一组示例数据演示结论如何合成。文中阈值均为示例设定，团队需按阶段和项目类型自行约定。

要点总览（TL;DR）

• 阶段验收拆成两条独立门槛：缺陷门槛看质量状态，交付物完整性门槛看成果齐备与受控，两条都通过才判定验收通过。
• 缺陷门槛用分级遗留数量上限加遗留缺陷密度共同判定，密度分母（功能点、用例数或千行代码）须在阶段启动前锁定，中途不更换。
• 交付物完整性用必交项完成率=已提交且通过评审的必交项数÷必交项总数判定，单项需同时满足内容齐全、版本受控、评审记录可查。
• 数据冻结时点定在评审前固定时刻，冻结后新增缺陷单独记录；带条件通过必须登记遗留项、责任人和关闭期限。
• 门槛达标只代表达到约定状态，分母口径漂移、批量关闭缺陷、阈值照搬都会让判定失真，需配合抽样复核。

阶段验收要判定什么：两条门槛与一个结论

阶段验收的判定对象有两类，对应两条门槛。缺陷门槛回答“这个阶段交付的质量状态是否可接受”，判定依据是缺陷的严重度分布和遗留数量；交付物完整性门槛回答“这个阶段该交的成果是否交齐、是否经过评审确认”，判定依据是必交项清单的逐项核对结果。两条门槛的判定对象不同，不能互相替代：缺陷清零不代表文档齐备，文档齐备也不代表质量达标。

合成规则只有一条：两条门槛都通过，阶段验收才判定为通过；任一门槛不通过，则进入挂起或带条件通过。验收结论建议固定为三种取值，每种取值对应明确的后续动作：

结论取值	触发条件	后续动作
通过	缺陷门槛与交付物完整性门槛均达标	签署验收记录，下一阶段按计划启动
带条件通过	一条或两条门槛未完全达标，但遗留项风险可控且已登记	登记遗留项清单，明确责任人和关闭期限，在下一阶段指定节点前关闭并复核
挂起	存在致命或严重缺陷未关闭，或关键必交项缺失且无替代方案	不启动下一阶段，整改后重新提交验收评审

三种取值的边界需要在阶段开始前写进验收规则，避免评审会上临时争论。带条件通过尤其需要约束：它允许项目继续推进，但遗留项必须有登记、有责任人、有期限，否则会演变成事实上的无条件通过。

缺陷门槛怎么量化：分级阈值与分母口径

缺陷门槛建议用两个口径共同判定：一是按严重度分级的遗留数量上限，二是遗留缺陷密度。前者控制“有没有不能带走的缺陷”，后者控制“整体遗留规模是否与阶段体量匹配”。只设数量上限，大阶段和小阶段会用同一把尺子；只设密度，又可能放过个别致命缺陷。两个口径同时使用，判定更稳。

下表给出指标定义与计算口径，阈值列填写的是示例值，需按项目实际情况调整：

指标	公式	分子/分母	单位	时间窗	示例阈值
致命缺陷遗留数	验收时点未关闭的致命缺陷数	分子为未关闭致命缺陷；无分母	个	数据冻结时点	0
严重缺陷遗留数	验收时点未关闭的严重缺陷数	分子为未关闭严重缺陷；无分母	个	数据冻结时点	0 或经批准的例外清单
严重缺陷关闭率	已关闭严重缺陷数 ÷（已关闭严重缺陷数 + 未关闭严重缺陷数）	分母为本阶段全部严重缺陷	百分比	阶段启动至冻结时点	100%；分母为零时记为“不适用”
遗留缺陷密度	验收时点未关闭缺陷数 ÷ 统计基数	分母可选功能点数、用例数或千行代码，阶段开始前约定	个/功能点 或 个/千行	数据冻结时点	按历史基线设定，如不超过上阶段实际值的约定比例
一般与轻微缺陷遗留数	验收时点未关闭的一般、轻微缺陷数	分子为对应严重度未关闭缺陷；无分母	个	数据冻结时点	设上限，允许带入下一阶段并登记

分母口径是这类门槛最容易出问题的地方。遗留缺陷密度的分母必须在阶段开始前确定并写入验收规则，中途更换分母会让前后数据失去可比性。功能点数适合需求边界清晰的阶段，用例数适合测试活动密集的阶段，千行代码适合有稳定代码统计口径的团队。三种分母之间不做换算。

统计时间窗同样需要固定。建议把数据冻结时点定在验收评审会前一个固定时点，例如评审前一个工作日的固定时刻，冻结后新增缺陷单独记录、不计入本次判定。这样可以避免评审过程中数据持续变化导致结论反复。严重缺陷关闭率的分母为零时，按“无严重缺陷即视为达标”处理，并在验收记录中注明分母为零，避免除零错误或被误读为数据缺失。

跨阶段比较要谨慎。不同阶段的统计基数、缺陷登记粒度、测试覆盖范围往往不同，遗留缺陷密度不宜直接横向比较，更适合与本阶段自身的历史基线或约定目标对比。

交付物完整性怎么设门槛：清单、必交项与通过标准

交付物完整性的判定前提是一份阶段交付物清单。清单在阶段启动时确定，按阶段成果逐项列出，并区分必交项与选交项。必交项是缺一项就不能判定通过的成果，例如需求规格说明、设计文档、测试报告、阶段评审记录；选交项可以缺失或延后，但需在清单中注明。清单本身应作为验收规则的附件受版本控制，评审时以冻结版本为准。

完整性门槛用必交项完成率判定：必交项完成率 = 已提交且通过评审的必交项数 ÷ 必交项总数。注意分子要求“已提交且通过评审”两个条件同时满足，只提交未评审的交付物不计入分子。完成率的示例门槛可设为 100%，即所有必交项均通过评审；若团队允许少量非关键必交项延后，可在规则中明确允许延后的项数和条件，并纳入带条件通过的遗留项管理。

单项交付物是否算“通过”，需要统一的判定标准。建议每项必交物同时满足以下三条才算通过：

• 内容齐全：覆盖清单中约定的章节或要素，无占位内容、无待补章节。
• 版本受控：有明确的版本号和状态标识，评审依据的版本可追溯。
• 评审记录可查：有对应的评审结论，评审意见已闭环或有明确处理结论。

证据要求与判定标准配套。每项必交物应能对应到提交记录和评审结论两类证据，验收时逐项核对，而不是凭印象判断“文档差不多都有了”。清单缺失或必交项总数为零时，不能直接判定通过，应先补齐清单再评估；若某阶段确实没有必交项，需在验收规则中说明理由并留档。

评估步骤：从冻结数据到出具验收结论

两条门槛的计算需要按固定顺序执行，确保缺陷数据和交付物状态来自同一时点。建议采用以下五步：

1. 冻结数据。在约定时点冻结缺陷数据与交付物提交状态，导出缺陷清单（含严重度、状态、关闭时间）和必交项核对表。产出：冻结时点的缺陷快照与交付物状态快照。
2. 计算缺陷指标。按分级统计未关闭缺陷数，计算严重缺陷关闭率和遗留缺陷密度，与阈值逐项比对。产出：缺陷门槛判定表，每项指标标注达标或不达标。
3. 核对必交项。逐项检查必交物的内容、版本和评审记录，计算必交项完成率。产出：交付物完整性核对表与完成率。
4. 合成结论。两条门槛均达标则判定通过；任一不达标则根据严重程度选择挂起或带条件通过，并登记遗留项，写明事项、责任人、关闭期限和复核方式。产出：验收结论与遗留项清单。
5. 留档与交接。将验收结论、两项判定表和遗留项清单归档，作为下一阶段启动和后续复核的依据。产出：归档的验收记录。

这套流程中的冻结快照、缺陷状态统计和交付物评审记录需要有稳定的承载位置。在 ONES 中，缺陷可在项目内登记并跟踪修复状态，报表可按自定义数据范围和维度统计缺陷分布；交付物清单可借助项目计划按阶段或交付物维度分解，文档与评审记录可通过 Wiki 关联任务并保留版本。这样冻结时点导出的数据与评审记录能对应到同一套工作项和文档，减少核对时的口径争议。具体报表维度和字段需按团队口径配置，官方资料未提供预设的验收阈值。

一个算例：某阶段验收的门槛判定

以下为演示情景，数据为虚构，仅用于说明计算过程。

某瀑布项目进入系统测试阶段验收。阶段启动时约定：致命、严重缺陷遗留数为 0；严重缺陷关闭率 100%；遗留缺陷密度不超过 0.5 个/功能点；一般与轻微缺陷遗留合计不超过 20 个；必交项完成率 100%。统计基数为本阶段 120 个功能点。

冻结时点的缺陷数据：致命缺陷 0 个；严重缺陷累计 14 个，已关闭 14 个，未关闭 0 个；一般缺陷未关闭 9 个，轻微缺陷未关闭 6 个；全部未关闭缺陷合计 15 个。计算过程：

• 致命缺陷遗留数 0，达标。
• 严重缺陷遗留数 0，达标；严重缺陷关闭率 = 14 ÷ (14 + 0) = 100%，达标。
• 遗留缺陷密度 = 15 ÷ 120 = 0.125 个/功能点，低于 0.5 的阈值，达标。
• 一般与轻微缺陷遗留合计 9 + 6 = 15 个，低于 20 的上限，达标。

交付物方面，本阶段必交项共 8 项，冻结时点已提交且通过评审的为 7 项，1 项测试报告已提交但评审意见尚未闭环。必交项完成率 = 7 ÷ 8 = 87.5%，未达到 100% 的门槛。

合成结论：缺陷门槛全部达标，交付物完整性门槛不达标。由于缺失项为评审未闭环而非成果缺失，且缺陷状态良好，判定为带条件通过。遗留项登记为：测试报告评审意见闭环，责任人为测试负责人，关闭期限为下一阶段启动后 5 个工作日内，复核方式为提交修订版评审记录。若该必交项属于关键成果且无法在期限内闭环，则应改为挂起。

解读与限制：门槛不能当质量保证

门槛达标只表示阶段状态达到了事先约定的水平，不表示产品没有缺陷，也不表示业务上已经可用。验收判定是对“是否允许进入下一阶段”的管理决策，质量保证还需要依靠测试设计、评审和后续验证活动。把门槛达标当作质量结论，会掩盖未覆盖场景和未登记问题。

几类常见误用需要提前防范：

• 分母口径漂移。阶段中途更换统计基数或调整缺陷登记粒度，会让密度指标失去可比性。口径应在阶段启动时锁定，变更需留痕并说明影响。
• 关闭率失真。批量关闭、以“无法复现”直接关闭等操作会抬高关闭率。建议对已关闭的严重缺陷做抽样复核，确认修复有验证记录。
• 阈值照搬。不同阶段、不同项目类型的缺陷分布差异明显，阈值应参考历史基线和阶段特点设定，不存在通用的达标线。
• 清单形式化。必交项清单长期不更新，或评审记录只有结论没有意见，会让完整性判定流于形式。清单应随阶段成果变化维护，评审记录需保留可核查的意见。

门槛与组织级流程制度的边界也要分清。本文给出的是单项目阶段验收的判定方法，组织级的研发流程规范、验收审批权限和制度性要求由相应管理制度规定，项目层面的门槛设定应在制度框架内进行，并与阶段评审、变更控制等流程衔接。

常见问题

阶段验收时缺陷数据还在变化，冻结时点应该怎么定？

建议把冻结时点定在验收评审会前一个固定时刻，例如评审前一个工作日的下班前，并在验收规则中提前写明。冻结后导出的缺陷清单作为本次判定的唯一依据，评审过程中新提交或新关闭的缺陷单独记录，不计入本次门槛计算，留到下一阶段或复核时使用。

冻结时点一旦确定就不要临时调整。如果因为评审延期需要重新冻结，应在验收记录中注明原因和两次快照的差异，避免同一阶段出现两套判定数据。

某个阶段确实没有严重缺陷，严重缺陷关闭率怎么算？

分母为零时按“无严重缺陷即视为达标”处理，并在验收记录中注明分母为零，避免除零错误，也避免被误读为数据缺失。同时保留致命缺陷遗留数为 0 的核对结果，两项一起作为严重度维度的判定依据。

需要注意，分母为零只说明本阶段没有登记严重缺陷，不代表测试覆盖充分。建议在验收记录中附上本阶段的测试范围和执行情况，供评审时参考。

必交项完成率没到 100%，但缺的是评审未闭环，能判通过吗？

不能直接判通过。完成率的分子要求“已提交且通过评审”两个条件同时满足，评审未闭环的交付物不计入分子。此时应根据缺失项的性质选择结论：如果成果本身已提交、只是评审意见待闭环，且缺陷门槛达标，可判带条件通过，登记遗留项并写明责任人、关闭期限和复核方式；如果缺失的是关键成果且期限内无法闭环，应判挂起，整改后重新提交验收评审。

不同阶段的遗留缺陷密度可以直接比较吗？

不建议直接横向比较。不同阶段的统计基数、缺陷登记粒度和测试覆盖范围往往不同，密度数值的可比性有限。更稳妥的做法是与本阶段自身的历史基线或阶段启动时约定的目标对比，跨阶段比较时同时说明分母口径和统计范围，口径发生变化时不做直接对比。

验收数据分散在缺陷列表和文档里，怎么保证核对时口径一致？

关键是让缺陷状态和交付物评审记录对应到同一套工作项与文档结构，并在冻结时点统一导出。在 ONES 中，缺陷可在项目内登记并跟踪修复状态，报表可按自定义数据范围和维度统计缺陷分布；交付物清单可借助项目计划按阶段或交付物维度分解，文档与评审记录可通过 Wiki 关联任务并保留版本。具体报表维度和字段需按团队口径配置，官方资料未提供预设的验收阈值。