先说结论：UI 过了，功能没过，照样是半成品

UI 验收那篇讲了"好不好用"的四层，但即便视觉和交互都过了，还有一个常被跳过、却最要命的环节——功能验收（UAT）。界面漂亮、流程顺，不代表每个按钮背后算得对、每个异常兜得住。这一篇是它的姊妹篇，专讲功能怎么验。

UI 验收过了，为什么还要功能验收？

  • 视觉对 ≠ 逻辑对：页面好看，但提交订单算错金额、库存没扣，用户照样炸；
  • 理想路径 ≠ 真实路径：设计只画了"正常情况"，用户会走错、会乱点、会断网；
  • 前端显示 ≠ 后端落库：前端说"成功"，数据库未必记下了，这种问题只测界面发现不了。

UI 验收保的是"看起来对"，功能验收保的是"实际上对"。两道都过，才叫交付。

核心流程要测哪些用例？

把用户最常走的几条主路径，逐条写成用例：

  • 注册 / 登录：正常登录、验证码、第三方授权、退出再进；
  • 核心动作：如下单、支付、预约、发布——每一步前置条件、操作、预期结果写清楚；
  • 数据与状态：操作后数据库/订单状态是否按预期变化，不只是前端提示"成功"。

每条用例的结构固定为：前置条件 → 操作步骤 → 预期结果。口头"测一下"最不可靠，落到纸上才查得出漏。

边界和异常，怎么测才不漏？

正常流程人人会测，真正翻车的都在边界：

  • 空与零：空输入、数量为 0、金额为 0，系统怎么反应；
  • 超限：超库存下单、超长文本、超大额支付；
  • 中断：支付中途退出、网络断开、杀掉进程后数据是否一致；
  • 重复：重复提交、重复支付，会不会扣两次。

这些"非理想状态"在 UI 验收里提过要设计，而功能验收要把它们真刀真枪跑一遍，确认兜得住而不是崩给你看。

多角色和多端，怎么覆盖？

  • 多角色：普通用户、管理员、审核员各自能看什么、能做什么，权限边界要逐条验；
  • 多端：iOS / Android / 不同机型、暗黑模式、刘海屏，真机过一遍（UI 验收也强调过真机）；
  • 多版本：老用户数据在新版本下是否兼容，升级后不丢不乱。

只在一个角色、一台机器上点一遍就签字，上线后必被真实多样性打脸。

验收不通过，怎么留痕和追责？

  • 用例即证据：每条不通过，截图+步骤+环境记录下来，别口头说"有点问题"；
  • 分级：阻断级（不能用）必须修，体验级（能忍）排期修，双方签字确认；
  • 回归：修完要重跑相关用例，确认没引入新问题。

留痕不是为了甩锅，是为了把"交付标准"钉死——这和我们在合同里强调的"验收节点"是同一套逻辑：没验清楚，后面扯皮的成本远高于现在多花的两天。

最后

功能验收的主动权在你手里。把上面这套用例清单当成签收前的硬门槛，比"感觉差不多了"有用得多。我们做项目时，UAT 本来就是交付的一部分；如果你想在方案阶段就把验收标准定清楚、避免上线后返工扯皮，把业务说给我们，方案评估免费——验收标准越早定，后面越省心。