📚 课程目录第3章功能完整性验收指标

第3章功能完整性验收指标：需求覆盖率、功能点通过率、边界条件处理

功能完整性验收指标适用于以下典型场景：

执行功能完整性验收前，必须满足以下条件：

注意事项：若需求文档或功能点清单仍在频繁变更，应暂缓验收，待基线稳定后再启动。否则覆盖率数据会频繁失效，导致返工。

按下述流程逐步执行，每一步完成后确认结果再进入下一步。

步骤	操作	详细说明
1	建立需求映射矩阵	从需求规格说明中提取所有功能需求项，为每项分配唯一 ID；在追溯矩阵中建立需求-ID → 测试用例-ID 的映射关系。
2	确认功能点清单	联合 PM、开发、QA 三方评审功能点清单，确保粒度一致、无歧义；以清单为后续通过率计算的基准。
3	设计并执行功能测试用例	针对每个功能点编写正向测试用例，执行后标记通过/失败；失败的用例进入缺陷管理流程。
4	计算需求覆盖率	统计已覆盖需求数（至少有一个通过用例的需求项）与总需求数，按公式计算。
5	计算功能点通过率	统计通过功能点数（所有关联用例均通过）与总功能点数，按公式计算。
6	验证边界条件处理	对每个功能点识别边界值，设计等价类划分和边界值分析用例；执行并记录结果，计算边界条件覆盖度。

指标计算公式：

需求覆盖率 = (已覆盖需求数 / 总需求数) × 100%
功能点通过率 = (通过功能点数 / 总功能点数) × 100%
边界条件覆盖度 = (已测试边界数 / 总边界数) × 100%

最佳实践：推荐在 CI/CD 流水线中嵌入“需求覆盖率”和“功能点通过率”的自动计算脚本，每次代码提交后自动更新指标看板，实现质量门禁的实时反馈。

角色	职责
QA 工程师	建立映射矩阵；设计/执行测试用例；计算并发布三个指标数据；对不合格项发起缺陷流程。
开发工程师	提供需求文档和功能点清单；修复缺陷并配合回归验证；确认边界值识别是否完整。
产品经理	确认需求范围和功能点清单的准确性；评审覆盖率报告中“未覆盖需求”的优先级；签字确认验收结果。
测试经理	审核测试用例质量；监控指标趋势；协调跨团队资源解决卡点问题。

以下记录材料需归档至项目质量管理库，保留至少一个版本周期：

异常场景	处理措施
需求中途变更，覆盖基准变化	更新需求映射矩阵，重新计算覆盖率；变更部分需单独标注并在验收总表中说明影响范围。
功能点定义颗粒度不一致	组织三方评审会议，统一功能点拆解规则（建议使用 user story 或 EPIC 层级对齐）。
测试环境不稳定导致部分用例失败	环境修复后重新执行全部受影响用例；若修复周期长，需在报告中注明“环境依赖型未通过”。
边界值识别存在争议	以需求文档中的显式边界描述为准；无明确描述时，采用行业通用等价类划分标准，并记录决策理由。
覆盖率或通过率低于阈值	触发质量门禁，暂停当前阶段交付；由测试经理牵头制定整改计划，达标后方可继续。

  关键原则：异常处理的核心是“可追溯、可复现、可仲裁”。所有异常场景的处理结果必须在记录材料中留下审计线索，避免后续扯皮。

三个指标必须同时满足以下阈值，方可判定功能完整性验收通过：

指标	验收阈值	特殊说明
需求覆盖率	≥ 95%	核心需求（P0 级别）必须 100% 覆盖；未覆盖的常规需求需在报告中说明原因及补救计划。
功能点通过率	≥ 98%	阻塞级（Blocker/Critical）功能点必须 100% 通过；其余未通过功能点需关联已确认的缺陷单。
边界条件覆盖度	≥ 90%	高风险边界（安全、权限、数据一致性相关）必须 100% 覆盖；一般边界可酌情放宽但需评审确认。

量化示例：假设某 Agent 项目共有 120 项需求、80 个功能点、200 个边界点。验收时需满足：已覆盖需求 ≥ 114 项、通过功能点 ≥ 79 个、已测试边界 ≥ 180 个。任一指标不达标则整体验收不通过，需整改后重新评估。

以上为第3章功能完整性验收指标的完整 SOP。学员应按照操作步骤逐一执行，并依据验收标准判定通过与否。记录材料和异常处理机制是保证过程可审计的关键，切勿省略。

第3章 功能完整性验收指标：需求覆盖率、功能点通过率、边界条件处理