第 4 章 · 预计阅读 15 分钟
系统测试与用户验收
技术测试全部通过，为什么客户仍可能在 UAT 说不能上线？
技术团队验证系统是否按设计工作，业务用户验证它是否支持真实任务和控制要求。
先放回整门生意
先知道这一章为什么存在
先把“系统测试与用户验收”理解成一段有触发、有负责人、有记录、也有完成标准的业务，而不是一组部门名词。
上一章“架构、开发与系统集成”应先形成：端到端业务依赖数据、权限、接口和多个组件在同一版本中协同。
本章把“技术团队验证系统是否按设计工作，业务用户验证它是否支持真实任务和控制要求。”从一句目标变成可执行、可交接、可核验的工作。
结果将交给下一章“生产切换、验收与运维”：上线需要冻结、迁移、验证、回退和支持安排，验收则需要完整证据和遗留项边界。
- 收入怎么受影响
- 陆桥数智通过定制开发项目费、系统集成费、需求变更工时费和上线后运维费收费。本章形成的“UAT 结论”要和“测试报告与缺陷清单”和“UAT 签署单”一起核对，才能继续判断验收、结算或后续经营；现金时点按以下规则判断：签约收 20%，需求基线、上线试运行和终验分别收 30%、30% 和 20%；已批准变更随下一里程碑结算。
- 风险在哪里出现
- 全程要警惕“范围蔓延、估算偏差、交付延期与关键人员依赖”。本章至少要用“测试报告与缺陷清单”和“UAT 签署单”留下可追溯证据。
读完这一章，你应该能自己解释
- 能用自己的话解释“技术测试全部通过，为什么客户仍可能在 UAT 说不能上线？”，并说出它为什么会影响客户价值或经营结果。
- 能按依赖顺序还原2个业务步骤，并指出每一步的负责人、记录和交接物。
- 能区分业务流、钱流、信息流和责任流，不把“做过动作”误当成“完成交付”。
- 遇到相似情境时，能用“产出是否形成、证据能否核对、风险是否受控”作出判断。
先建立业务直觉
通过测试要对应不同问题
单元和系统测试发现技术缺陷，UAT 检查业务规则、权限、数据和操作结果；二者互补，不能相互替代。
把它放进陆桥数智的经营现场：本章只聚焦“系统测试与用户验收”这一环，追踪它怎样承接已有输入，并把“技术团队验证系统是否按设计工作，业务用户验证它是否支持真实任务和控制要求”变成可以执行和复核的工作。
本章从“完成系统级验证”开始，依次经过“完成系统级验证”和“组织业务 UAT”，最后得到“UAT 结论”。判断是否完成，要把动作、产出、业务记录和下一位接手者放在一起核对。
至少同时满足三件事：产出“UAT 结论”；关键记录“测试报告与缺陷清单”和“UAT 签署单”可以相互核对；相关负责人清楚下一步由谁接手。
完整案例推演
跟着陆桥数智，把“系统测试与用户验收”完整跑一遍
现在把镜头放到陆桥数智的“系统测试与用户验收”：技术测试全部通过，为什么客户仍可能在 UAT 说不能上线？ 先读下面的经营底账，后续每一步都会复用这些数字与约束。
贯穿全课的虚构案例
陆桥数智
一家 32 人的软件交付公司，为汽配厂建设生产计划、仓储和质量追溯系统；合同已经签署，但客户新增扫码和设备联网需求，项目经理必须先判断它属于原范围还是变更。
- 项目合同额
- ¥860,000合同总价对应已确认的范围和验收条件，并不自动覆盖后续提出的所有需求。
- 交付周期
- 6 个月、4 个付款里程碑需求确认、联调、试运行和终验分别产生交付证据与回款条件。
- 系统接口
- 12 个，已联通 8 个开发完成的页面不等于系统可用，上下游接口状态会直接阻塞完整业务测试。
- 验收状态
- 132 条用例通过 109 条、阻塞 8 条通过率要连同阻塞原因和责任方解释，不能用一个百分比代替问题清单。
客户为什么付钱
定制开发项目费、系统集成费、需求变更工时费、上线后运维费
钱在什么时候进来
签约收 20%，需求基线、上线试运行和终验分别收 30%、30% 和 20%；已批准变更随下一里程碑结算。
利润最容易被什么吃掉
研发和项目管理工时、外部接口与软硬件采购、驻场差旅、返工与延期占用
这笔业务怎样一步一步形成可交付结果
- 01完成系统级验证满足 UAT 准入的版本
- 02组织业务 UATUAT 结论
完成系统级验证
在陆桥数智，团队先面对一条共同事实：“项目合同额”为¥860,000。合同总价对应已确认的范围和验收条件，并不自动覆盖后续提出的所有需求。
按需求和风险执行功能、接口、性能、安全与回归测试，分级管理缺陷。
这一步真正要判断：拆解计划和管理产能
如果本步没有形成“满足 UAT 准入的版本”，下一步“组织业务 UAT”就没有可靠输入。
- 谁在参与
- 交付负责人
- 关键记录
- 测试报告与缺陷清单
- 形成产出
- 满足 UAT 准入的版本
- 交给下一步
- 把“满足 UAT 准入的版本”交给实施经理和客户业务负责人，继续处理“组织业务 UAT”。
如果没做好：如果交付负责人没有拆解计划和管理产能，或者没有留下“测试报告与缺陷清单”，即使动作已经做过，下一步也无法确认“满足 UAT 准入的版本”是否可靠。
组织业务 UAT
上一步已经形成“满足 UAT 准入的版本”。与此同时，案例里的“交付周期”为6 个月、4 个付款里程碑，需求确认、联调、试运行和终验分别产生交付证据与回款条件。
由授权业务用户用代表性数据执行端到端场景，记录通过、缺陷和范围外建议。
这一步真正要判断：准备 UAT 和上线计划；提供决策和业务资源
这是本章最后一项可核验产出，用来判断团队是否真的完成了“系统测试与用户验收”。
- 谁在参与
- 实施经理、客户业务负责人
- 关键记录
- UAT 签署单
- 形成产出
- UAT 结论
- 交给下一步
- 把“UAT 结论”作为本章完成证据，交给下一章节继续使用。
如果没做好：如果实施经理没有准备 UAT 和上线计划，或者没有留下“UAT 签署单”，即使动作已经做过，下一步也无法确认“UAT 结论”是否可靠。
案例结束时，不是因为所有人都完成了自己的动作就算成功，而是因为“UAT 结论”已经形成、证据可以追溯，并且实施经理和客户业务负责人能够解释结果怎样产生、风险怎样被控制。技术团队验证系统是否按设计工作，业务用户验证它是否支持真实任务和控制要求。
换一个视角再看
同一笔业务，同时跑着四条线
业务流说明事情怎样发生，钱流解释收入、成本与现金，信息流留下共同事实，责任流决定谁执行、谁确认、谁承担后果。点击切换，观察同一章节怎样变化。
围绕“技术测试全部通过，为什么客户仍可能在 UAT 说不能上线？”，业务必须按依赖关系推进，不能把一串并行任务误当成已经交付。
- 01
完成系统级验证 → 满足 UAT 准入的版本
- 02
组织业务 UAT → UAT 结论
出现这个信号要警惕：如果交付负责人没有拆解计划和管理产能，或者没有留下“测试报告与缺陷清单”，即使动作已经做过，下一步也无法确认“满足 UAT 准入的版本”是否可靠。
岗位、记录与业务语言
一家公司靠什么把多人协作变成同一个结果
岗位不是孤立的名称，记录也不是多余的表格。前者分配判断与责任，后者让不同人能够核对同一件事是否真的发生。
谁负责什么，结果交给谁
| 角色 | 本章负责 | 最关心 | 交给谁 |
|---|---|---|---|
| 业务职能设计、开发与质量交付 | 提供本章所需的约束、输入或审批 | 按基线构建系统、集成接口并证明它满足要求；重点关注：完成架构、开发、集成和测试 | 下一章节或业务结果的接收方 |
| 业务职能上线、验收与运维 | 提供本章所需的约束、输入或审批 | 把系统安全切换到生产环境并获得正式业务确认；重点关注：组织 UAT、上线和数据迁移 | 下一章节或业务结果的接收方 |
| 外部参与者客户业务负责人 | 组织业务 UAT | 代表客户确定优先级、业务规则和验收结论；重点关注：提供决策和业务资源 | 下一章节或业务结果的接收方 |
| 代表岗位交付负责人 | 完成系统级验证 | 协调开发、测试和依赖方，持续交付可验证版本；重点关注：拆解计划和管理产能 | 实施经理、客户业务负责人 |
| 代表岗位实施经理 | 组织业务 UAT | 连接客户现场、生产切换与项目收尾；重点关注：准备 UAT 和上线计划 | 下一章节或业务结果的接收方 |
哪些记录能证明业务真的发生了
| 业务记录 | 在哪产生 | 谁形成 | 证明什么 | 下一步怎么用 |
|---|---|---|---|---|
| 测试报告与缺陷清单 | 完成系统级验证 | 交付负责人 | 满足 UAT 准入的版本 | 组织业务 UAT |
| UAT 签署单 | 组织业务 UAT | 实施经理和客户业务负责人 | UAT 结论 | 判断本章是否完成并进入下一章节 |
本章术语：先用白话理解，再回到正式定义
- UAT用户验收测试 UAT
- 白话：真正使用的人按工作场景确认能不能用。
- 正式定义：由业务用户在接近真实场景下验证系统是否支持约定业务的测试。
- 放进业务里：财务人员用测试订单完成开票、冲红和对账。
- 业务术语缺陷严重度
- 白话：问题有多严重，是否会挡住上线。
- 正式定义：按缺陷对核心功能、数据、安全和上线的影响进行的等级划分。
- 放进业务里：无法保存订单被定为阻断级，按钮颜色错误为低级。
- 业务术语里程碑
- 白话：不是到了某一天，而是到那天必须拿出什么结果。
- 正式定义：项目中具有明确成果和确认条件的重要节点。
- 放进业务里：完成接口联调并通过测试后触发里程碑付款。
新手最容易误解的地方
通过用例多，所以金额错误不重要
为什么不对：缺陷等级取决于后果，不取决于出现次数或通过用例比例。
应该继续追问：如果改成“按资金和业务影响提高严重度，修复验证后再决定”，需要谁确认、留下什么证据？
“完成系统级验证”只要动作做完，就可以直接进入下一步。
为什么不对：如果交付负责人没有拆解计划和管理产能，或者没有留下“测试报告与缺陷清单”，即使动作已经做过，下一步也无法确认“满足 UAT 准入的版本”是否可靠。
应该继续追问：是否已经形成“满足 UAT 准入的版本”，并留下“测试报告与缺陷清单”供下一步核对？
“组织业务 UAT”只要动作做完，就可以直接进入下一步。
为什么不对：如果实施经理没有准备 UAT 和上线计划，或者没有留下“UAT 签署单”，即使动作已经做过，下一步也无法确认“UAT 结论”是否可靠。
应该继续追问：是否已经形成“UAT 结论”，并留下“UAT 签署单”供下一步核对？
先复盘，再做判断
现在，试着不用页面原话把这一章讲出来
- 为什么本章必须先做“完成系统级验证”，如果跳过会影响哪一步？
- 在“组织业务 UAT”中，谁执行、谁提供约束，应该留下什么记录？
- 本章怎样影响定制开发项目费、系统集成费、需求变更工时费和上线后运维费？结合“签约收 20%，需求基线、上线试运行和终验分别收 30%、30% 和 20%；已批准变更随下一里程碑结算。”判断它何时才会形成收入或现金。
- 如果只看到“UAT 结论”的口头结论，你还会要求核对哪些业务记录？
UAT 中发现付款金额偶发计算错误，但大部分场景通过，可以按低级缺陷上线吗？
项目已接近里程碑日期。