2. 交付验收基础：概念、流程、标准与规范
交付验收是网关API项目从开发阶段转入生产运营的关键质量闸门。本章围绕“什么是交付验收”、“验收如何执行”、“依据什么标准”三个核心问题，建立统一的验收认知框架。
2.1 交付验收的概念
交付验收（Delivery Acceptance）是指：在API网关系统开发完成并部署至预发布或生产环境后，由验收方（通常为质量保障团队、运维团队或客户代表）依据预先约定的验收标准，对系统功能、性能、安全、稳定性及文档进行全面验证，并正式签署通过的过程。
| 维度 | 说明 | 验收关注点 |
|---|---|---|
| 功能验收 | 验证网关路由、限流、鉴权、日志等核心功能是否按需求实现 | 用例通过率 ≥ 100%，边界场景覆盖完整 |
| 性能验收 | 验证网关在高并发下的吞吐量、延迟、资源消耗是否达标 | QPS、P99延迟、CPU/内存水位 |
| 安全验收 | 验证网关是否存在常见安全漏洞，鉴权与加密机制是否有效 | OWASP Top 10 扫描、渗透测试结果 |
| 稳定性验收 | 验证网关在异常场景（断网、后端宕机、流量突增）下的行为 | 故障恢复时间、熔断降级正确性 |
| 文档验收 | 验证交付物是否包含完整的部署手册、运维手册、API文档 | 文档覆盖率、可操作性、版本一致性 |
关键认知：交付验收 ≠ 功能测试。功能测试是“做对了没有”，交付验收是“做完了且符合合同/需求约定的全部条件”。验收通过意味着项目正式移交，后续进入运维保障阶段。
2.2 验收流程
标准化的验收流程分为五个阶段，每个阶段都有明确的输入、活动和输出。以下流程图展示了完整的验收流转路径。
- 提交验收申请：开发团队完成内部测试后，向验收方提交正式验收申请，附带自测报告、部署说明、版本发布记录。
- 资料与文档审查：验收方检查交付物完整性，包括需求文档、设计文档、API文档、部署手册、运维手册、测试报告。资料不齐则退回补充。
- 现场/远程验收测试：验收方按照验收用例逐项执行测试，记录测试结果与缺陷。测试环境应与生产环境配置一致或等效。
- 签署验收报告：测试通过后，双方共同签署《网关API交付验收报告》，明确验收范围、测试结论、遗留问题及处理计划。
- 正式移交运维：将网关系统移交至运维团队，同步配置数据、监控告警规则、应急预案、运维联系人等信息。
2.3 验收标准与规范
验收标准是衡量交付物是否合格的标尺。标准应具备可量化、可验证、无歧义三个特征。以下表格列出网关API交付验收的核心标准维度与典型指标。
| 标准类别 | 验收项 | 合格标准 | 验证方法 |
|---|---|---|---|
| 功能标准 | 路由转发 | 所有已配置路由规则100%正确转发 | 自动化用例 + 人工抽测 |
| 限流熔断 | 超过阈值时正确触发限流/熔断，恢复后自动解除 | 压测工具模拟流量 | |
| 鉴权认证 | 非法请求100%拦截，合法请求正常通过 | 安全测试用例 | |
| 性能标准 | 吞吐量 | 单节点QPS ≥ 需求值（如5000 QPS） | JMeter/Locust 压测 |
| 延迟 | P99延迟 ≤ 50ms（不含后端业务耗时） | 压测 + 链路追踪 | |
| 安全标准 | 漏洞扫描 | 无高危漏洞，中低危漏洞已修复或已确认风险 | OWASP ZAP / Nessus |
| 数据加密 | 敏感字段传输使用TLS 1.2+，密钥管理符合规范 | 抓包验证 + 配置审计 | |
| 稳定性标准 | 故障恢复 | 网关进程崩溃后自动重启时间 ≤ 10秒 | 混沌工程实验 |
| 优雅降级 | 后端服务不可用时，网关返回自定义错误码而非超时 | 模拟后端宕机 | |
| 文档标准 | 交付物完整性 | 部署手册、运维手册、API文档、测试报告、版本清单齐全 | 文档清单核对 |
规范引用参考：网关API交付验收应参照以下行业规范进行裁剪适配：
- GB/T 25000.51-2016 系统与软件工程 系统与软件质量要求和评价（SQuaRE）
- ISO/IEC 25010:2011 软件产品质量模型
- OWASP API Security Top 10（API安全验收参考）
- 企业内部《API网关技术规范》与《交付验收管理办法》
2.4 验收过程中的常见误区
根据多个网关项目的交付验收经验，以下误区最容易导致验收反复或交付延期，需提前规避。
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 标准模糊 | 验收标准写“性能良好”“安全可靠”等定性描述 | 全部改为可量化的数字指标 |
| 环境不一致 | 验收环境与生产环境配置差异过大 | 验收环境硬件、网络、中间件版本与生产对齐 |
| 遗漏非功能项 | 只测功能，不测性能、安全、稳定性 | 验收用例必须覆盖功能+非功能全维度 |
| 文档滞后 | 验收时文档还在编写中或版本不匹配 | 文档与代码同步交付，验收前完成文档冻结 |
| 缺乏缺陷分级 | 所有缺陷一视同仁，导致验收卡死 | 按P0~P3分级，P0/P1必须修复，P2/P3可协商 |
交付验收红线：以下情况直接判定验收不通过，不得签署验收报告：
① 存在未修复的高危安全漏洞；
② 核心功能（路由、鉴权、限流）存在阻断性缺陷；
③ 性能指标低于需求值的80%；
④ 缺少运维手册或部署手册，导致无法独立运维。
① 存在未修复的高危安全漏洞；
② 核心功能（路由、鉴权、限流）存在阻断性缺陷；
③ 性能指标低于需求值的80%；
④ 缺少运维手册或部署手册，导致无法独立运维。
2.5 验收交付物清单
验收通过前，开发团队必须提交完整的交付物包。以下清单可作为验收资料检查的基线模板。
- 代码与制品：网关源码（或编译后镜像）、配置文件模板、数据库初始化脚本、版本标签。
- 技术文档：部署手册（含环境要求、部署步骤、回滚方案）、运维手册（含监控指标、日志采集、告警配置、应急预案）、API接口文档（OpenAPI 3.0格式）。
- 测试报告：功能测试报告、性能压测报告、安全扫描报告、稳定性测试报告（含混沌工程结果）。
- 管理文档：需求跟踪矩阵（RTM）、验收用例清单、缺陷清单及修复记录、版本发布说明。
- 运维工具：监控大盘模板（Grafana JSON）、告警规则配置、日志采集配置、健康检查脚本。
交付物清单应在项目启动阶段与验收方共同确认，避免验收时因资料缺失导致流程阻塞。