最近我们公司对项目流程做了一次调整，新增了一个重要节点：UAT 验收。
为了更好地理解这个概念，我自己系统学习了一遍，也顺便整理成这篇博客，既是记录，也希望对看到这篇文章的你有所帮助。

🎯 什么是 UAT？

UAT，全称 User Acceptance Testing，中文叫：

  • 用户验收测试
  • 业务验收测试
  • 受理测试
  • 验收测试

它是软件上线前的最后一个测试阶段，由真正的业务使用者或代表来执行，目的只有一个：

确认系统是否能在真实业务场景中正常使用、符合预期，并决定是否上线。

这和我们常说的 QA 测试是完全不同的。

🧩 UAT 到底解决了什么问题？

测试人员会把功能点、逻辑、边界条件等都测得非常完整精准，但有一个问题：
业务团队未必真正看过”做出来的东西”。

比如：

  • 字段名对业务是不是友好？
  • 流程是不是符合真实的工作模式？
  • 是否符合线下/场景/运营流程中的「实际习惯」？
  • 报表数据是不是他们”能用、敢用”的？
  • 多系统链路是否真的跑通业务逻辑？

QA 的职责是验证”按需求实现”，而业务的职责是判断”是否满足我们的实际需求”。

所以 UAT 的价值就在于：在上线前，给业务一次真实把关的机会。

🔎 QA vs UAT：到底有什么区别？

作为测试同学，我们经常被问：”既然 QA 已经测过了，为什么还需要 UAT？”

一句话概括：

QA 测”实现是否正确”，UAT 测”业务是否满意”。

更直观的对比：

对比维度 项目系统测试（QA） UAT 验收（业务方）
关注点 功能正确性、逻辑完整性 业务价值、流程合理性
样式 细粒度、覆盖式测试 场景式、流程化使用
执行者 测试工程师 产品、运营、业务、使用部门
找的问题 Bug、异常流程 流程不顺、规则冲突、使用不便
上线关系 技术质量门槛 业务决策门槛

两个阶段关注点完全不同，因此没有谁能替代谁。

🧱 为什么 UAT 一定要业务方来做？

UAT 是业务方的”确认上线”仪式。

❌ QA 无法判断：

  • ✔ 这个按钮名字对运营是否友好
  • ✔ 这个时间显示是否符合行业规范
  • ✔ 这个业务流程是否符合 SOP
  • ✔ 这个规则能不能在实际场景跑得起来
  • ✔ 这个报表数据能不能给老板看

这些只有业务自己最清楚。

🧭 UAT 在整个项目流程中的位置

随着公司流程的改进，我们的项目结构大致变成了这样：

需求设计 → 开发 → QA 系统测试 → 预发布 → UAT 验收 → 上线

可以看到：

  • QA 已经保证了系统功能和质量稳定
  • UAT 是确保系统能”真正用于业务”

它属于上线前的最后一道闸口。

📝 UAT 验收一般做什么？

当业务执行 UAT 时，通常会关注：

1. 关键业务流程是否可用

一条业务主链，从头到尾是否顺畅。

2. 真实使用场景是否满足

例如预约、审批、投放、计算规则等。

3. 跨系统联动是否正常

例如数据驱动、推送、自动化流程。

4. 权限、角色、配置是否合理

5. 报表、统计、监控是否准确

6. 文案、字段名、展示是否符合业务习惯

7. 性能体验是否能满足实际工作

不像 QA 要做”覆盖式”测试，UAT 更像”业务沉浸式体验”。

🧨 UAT 不通过怎么办？

大部分公司都会这样处理：

  1. 记录问题
  2. 开发修复
  3. QA 回归
  4. 业务再次确认
  5. 再次 UAT
  6. 最终决定能否上线

一句话：UAT 的通过，是上线的必要条件。

💡 UAT 的一些扩展知识（小科普）

➊ UAT 会找 bug 吗？

会，但主要是流程、业务逻辑、使用体验相关。

➋ UAT 会新增需求吗？

通常不建议，但实际项目中经常会出现业务反馈：

  • “这个流程看起来不太合理”
  • “这个字段能不能改成 xxx”

这属于验收阶段需求变更，需要谨慎控制。

➌ UAT 是不是只要业务随便点点就算通过？

不是。

需要有：

  • 验收用例
  • 验收结果记录
  • 验收意见
  • 验收人确认

越规范，质量越有保障。

📦 写在最后：为什么这次流程升级值得记录？

这次项目流程新增 UAT 环节，对公司而言是：

  • 提升交付质量的关键措施
  • 让业务拥有更多话语权
  • 减少”上线后才发现和预期不一致”的风险
  • 建立更严谨的发布标准
  • 让测试和开发的工作更加可控

对我自己来说，这也是一个很好理解项目完整生命周期的契机。
也希望这篇文章能够帮到正在了解 UAT，或正经历流程升级的你。