功能验收按任务清单
把业务场景拆成一条条可判定的任务，逐条记录通过、失败与降级路径。为什么不能只抽几条演示：抽样掩盖长尾，而长尾正是上线后投诉集中的地方。失败样例要留档，作为后续优化输入。
性能要有基线对照
压测的意义在于与试点基线比较，而不是拿一个绝对数字。怎么测：用同一批请求、同一上下文档位跑分位延迟与完成率，并记录测试时的并发与资源占用，否则第二次复测无法比较。
稳定性靠长时压测
短时压测发现不了显存碎片、连接泄漏与日志膨胀。怎么做：至少跑一个完整业务日的混合负载，观察内存与显存曲线是否单调上升；发现上升要先定位再上线，别指望重启脚本兜底。
故障与安全一起验
怎么验：故障注入覆盖单卡、单机、断电、证书过期与许可失效；安全项覆盖账号权限、镜像扫描与日志留存。两类测试都要有恢复时间记录并写进运维手册，否则验收报告只是一份好看的文件。
适用与不适用
适合谁
- 即将完成私有化交付、准备验收的项目组
- 需要向审计或管理层提交验收依据的团队
- 准备进行二期扩容、需要容量依据的运维团队
不适合谁
- 尚未确定业务场景、还在做可行性验证的项目
- 以演示为目标、不打算长期运营的试点
典型场景
一家三甲医院的信息科在问答系统上线前组织验收：用两百条真实咨询跑任务清单，压测记录分位延迟，连续跑满一个业务日看显存曲线，再断开一台机器验证切换。报告里每条结论都附日志路径，遗留项列了责任人与时限。
可执行步骤
- 编制验收矩阵，把场景、指标、证据与责任人逐行对应，经双方确认
- 准备测试数据与对照基线，固定版本、配置与依赖镜像，并留快照
- 执行功能与性能测试，保存原始日志、曲线与全部失败样例，按场景归档
- 做故障注入与安全扫描，实测恢复时间并写进运维手册，附操作步骤
- 出具报告，列出遗留项、责任人与关闭时限，双方签字确认后归档
常见坑
- 验收只做抽样演示，长尾场景没有覆盖，上线首周问题集中爆发，团队只能被动救火，代价更高。
- 压测环境与生产配置不一致，报告上的数字好看却不可迁移，扩容时完全对不上，还要重测。
- 故障恢复只写结论没计时，报告称可恢复，真实停机时长与操作步骤无人知晓，演练也无从设计。
自检与验收清单
- 验收矩阵覆盖五类测试，每一项都有证据可查
- 测试版本、配置与依赖镜像同生产保持一致
- 失败样例与降级路径全部留档，能追溯到具体请求
- 恢复时间实测过，并写进运维手册与演练计划
- 遗留项有责任人、关闭时限与复验安排，逐条关闭
常见问题
压测要压到什么程度
压到目标峰值的余量线，而不是压到系统崩溃。通常从目标峰值的八成起逐档加压，记录完成率与延迟拐点，再留余量确定承诺容量。压到崩溃只能得到故障点，不能得到可承诺的服务水平。
没有生产数据怎么验收
用脱敏样本加人工构造的边界样例，明确说明测试集来源与局限。验收报告应区分已验证与未覆盖两类结论，避免把有限测试说成全面通过，后续出问题时也有据可查。
验收不合格怎么办
按合同约定进入整改与复验，遗留项要有责任人与时限。不建议以先上线再补的方式处理性能与安全问题，这类问题上线后修复成本更高，也容易演变成责任争议。