一句话理解

受入テスト（うけいれテスト），即 UAT（用户验收测试），是日本 SAP 项目中由客户业务部门主导的测试阶段：用真实业务场景验证系统"能不能用"。UAT 通过并签字，是系统上线（切替）的前置条件。

实战提示

实战提示：UAT 测的不是功能对不对（那是結合テスト的事），而是"业务能不能跑通"。UAT 前一定要先问客户要 5-10 个最真实的业务场景——比如"月底紧急采购"、"供应商送货差异处理"，照着这些准备，UAT 通过率完全不同。

日本 SAP 项目的测试阶段划分

阶段 日语 执行者 目的
单元测试 単体テスト 开发顾问 程序/配置单元正确
集成测试 結合テスト 顾问团队 流程端到端跑通
用户验收测试 受入テスト（UAT） 客户业务部门 真实业务场景可用
性能测试 性能テスト 顾问 + Basis 大数据量/并发下可用
1
単体テスト开发自测
2
結合テスト顾问按 To-Be 流程全场景测试
3
UAT 準備测试计划、测试用例、数据、环境、培训
4
受入テスト客户业务部门执行
5
障害対応缺陷修复 + 回归测试
6
受入承認客户签字，具备上线条件

UAT 准备的 5 件事

  1. テスト計画書 —— 范围、 schedule、角色分工、通过标准（合否基準），先和客户对齐。
  2. テストケース —— 按基本設計書的功能编号编写，每个用例写清前置条件、操作步骤、期望结果。
  3. テストデータ —— 主数据、期初数据准备好，和生产环境越接近越好。
  4. 操作培训 —— UAT 前给业务部门做操作说明，否则大量"缺陷"其实是"不会用"。
  5. 缺陷管理流程 —— 用什么工具记录、缺陷分级、响应 SLA，提前讲清楚。

缺陷（障害/不具合）分级示例

等级 定义 例子 对应
致命 业务无法继续 采购订单无法保存 必须修复才能 UAT 通过
严重 有变通方案但影响大 报表数据错误 原则上上线前修复
一般 轻微问题 画面显示错位 可延期到上线后改修
建议 改善提案 操作步骤可简化 记录为将来課題
注意

注意：UAT 阶段最常见的纠纷是"这是缺陷还是新需求"。判定标准只有一个：基本設計書里有没有。有，就是缺陷，顾问修；没有，就是新需求，走変更管理。UAT 启动会上先把这条规则和客户对齐，能省掉一半扯皮。

常见问题

Q：UAT 发现大量缺陷，客户拒绝签字怎么办？

A：先分类：真缺陷抓紧修；"不会用"类加强培训；新需求类走变更。把剩余缺陷清单、修复计划、回归测试安排书面给客户，用计划换签字——日本客户接受"有计划的风险"，不接受"没交代的问题"。

Q：UAT 测试数据用真实数据吗？

A：用脱敏后的真实数据或接近真实的模拟数据。全用假数据（如"测试物料 001"）会导致 UAT 通过、上线翻车——真实业务的脏数据才是真正的考验。

Q：UAT 需要多少轮？

A：一般 1-2 轮。第一轮找问题，第二轮回归验证。如果第三轮还有大量新缺陷，说明結合テスト没做扎实，要复盘而不是继续堆轮次。

相关阅读