定制软件UAT怎么做：把业务场景写成可复验的任务

从业务终点、场景矩阵、测试数据、预期结果和缺陷复测入手，把定制软件UAT写成岗位人员能独立执行的任务。

软件演示顺利，并不等于业务人员接手后就能完成工作。演示通常沿着准备好的数据和操作顺序进行，而实际工作中还有资料缺失、单据退回、多人交接和重复操作。用户验收测试通常简称UAT，本文聚焦其中的业务场景设计：约定范围内的任务，能否由指定岗位完成，并留下可核对的结果。它不展开源码、部署和备份交接，而是帮助业务负责人把“系统应该好用”转换成能够独立操作、能够复验的验收任务。

先确定任务的业务终点

一份有用的任务不能只写“测试采购模块”。它需要说明起点、参与人员、输入资料、操作过程和最终结果。例如“采购员根据获批需求建立订单，仓库分批验收，采购负责人核对剩余数量”就比“采购功能正常”更容易检查。这里的采购情景是教学假设，不是广深互联客户案例。终点也不应只到页面提示成功，还要看到订单剩余量和责任记录是否符合约定。一个任务涉及多个页面时，应按同一业务编号串联证据，避免每个页面各自通过，整条流程却断开。

用场景矩阵覆盖正常和异常

可以先按业务频率与出错影响选出关键任务，再为每个任务补充必要变化。以收货为例，既要验证足量一次收货，也要考虑分批到货、数量不足、质量待检和误操作撤回。不是所有异常都必须在首版开发，但哪些情况支持、哪些情况提示人工处理，应在验收前说清。场景矩阵至少包含角色、前置状态、输入条件、预期结果和证据位置。不要用大量重复点击代替有意义的覆盖；同一个规则换十组相同性质的数据，未必比一组边界数据更有价值。

准备能够人工核对的数据

测试资料应当让业务人员自己算出正确答案。若订单数量为十件，分两次收取六件与四件，大家就能明确核对剩余量变化。涉及金额、税额或计量单位时，要写清采用什么口径，并由相应负责人确认，开发人员不能临时替企业决定。优先使用专门构造的数据和测试账号，不应为了方便复制真实客户电话、合同或完整交易明细。资料需要覆盖空值、边界值与关联关系，并保存一份稳定基线，才能在修复后准确比较结果，避免测试输入变化造成结论漂移。

让使用岗位独立完成任务

项目经理可以组织验收，但不能代替所有岗位判断。仓管关心批次与可售数量，采购关心剩余交付，主管关心审批与责任交接。验收前应为每个关键场景指定业务确认人，并说明争议由谁处理。让岗位人员按任务说明独立操作，观察他们在哪一步需要帮助，比边演示边提示更能发现问题。培训不足与功能缺陷也需要区分：前者可能通过说明或交互调整解决，后者必须修复实现，不能把所有失败都归咎于员工不会使用，更不能替操作者完成困难步骤后再记为通过。

预期结果要明确到可观察对象

“结果正确”还不够具体，可以改成“订单剩余数量为四件，收货记录关联原订单，第二次收货完成后剩余量为零”。预期中还要说明不应该发生的事情，例如没有增加重复明细、没有提前关闭未完成任务。对一个操作引起的多个变化，分别指定查询入口。若业务规则本身尚无统一解释，应先由业务负责人决定，而不是边验收边猜答案。验收任务要能由另一名同岗位人员重复完成，并根据相同依据得到相同结论，才具有实际交接价值。

问题复测与影响回归分别安排

有效问题单应包含任务编号、账号角色、发生时间、前置条件、具体步骤、实际结果和预期结果，必要时附脱敏截图。优先级应结合业务影响确认。修复后，先用原输入重跑失败场景，再核对受影响的相邻步骤。例如分批收货修正后，还需要检查剩余量与整单结束条件，不能只看原报错消失。问题关闭应有复测人和证据，不用一句“已经处理”代替。没有相关变化的场景可复用有效结果，涉及规则调整的场景则必须重新判断证据是否仍然适用。

最终的业务验收结论，应列出通过场景、未关闭问题、明确接受的限制，以及限制解除前的处理办法。不能用一张签字单掩盖尚未执行的任务，也不能把业务场景通过说成所有上线条件已经满足。广深互联提供软件定制与行业业务系统开发相关服务，本文由广深互联技术团队整理。讨论项目时，可以先准备最常见的一条流程与最担心的三类异常，据此确认业务验收范围，具体功能和交付边界以实际评估与书面约定为准。