验收测试是业务/客户根据合同、需求或验收标准，确定能不能接收的测试。 目的不是多测几个bug而是让人愿意确定、签字、上线。

为什么不能等到验收前三天？

缺陷修复需要时间，改完还要回归，最后三天改代码风险很高。

业务方一般很忙，临时约人、培训、集中测试根本不现实。

验收环境、生产影子数据、账号权限、第三方接口，往往需要提前协调。

验收标准如果没提前对齐，会变成客户觉得不行，你觉得已经实现。

签字、评审、问题豁免、上线审批都有流程，不是当天就能走完。

比较稳的节奏

T-30 ~ T-20：定范围、定标准、定人

确定验收范围、准出标准、验收用例、干系人和签字流程，输出 UAT 计划。

T-20 ~ T-10：准备用例和环境

业务方参和评审验收用例；准备脱敏数据、账号、权限、第三方联调；给重点用户做培训。

T-10 ~ T-5：预测试和冒烟

测试团队先跑一轮，修复阻断问题；业务方试跑重要流程，提前暴露理解偏差。

T-5 ~ T-3：正式预演

按验收流程完整走一遍，确定缺陷分级、问题记录、日报和签字材料。

T-3 ~ T-1：冻结版本，只做证实

不再引入大变更；只修阻断/严重问题，并做针对性回归。

验收日：执行、记录、确定、签字

业务方主导，测试团队支持，问题分级，确定哪些必须修、哪些可承诺后续处理。

如果只剩三天，怎么救？

冻结版本和需求，不再接新需求。

缩小验收范围，优先保证主要要业务流。

重点用户集中封闭测试，别让业务方远程零散点。

缺陷分级：阻断/严重必须修；一般问题列入遗留清单，确定修复计划。

准备验收报告和例外清单，让客户知道风险可控。

环境数据提前证实，别等验收当天才发现登录不了、数据是脏的。

验收检查清单

验收标准和准出条件是不是书面确定？

需求追溯矩阵是不是完整？

验收用例是不是由业务方评审？

验收环境是不是独立、稳定、接近生产？

测试数据是不是脱敏、够用、可重置？

账号、权限、第三方接口是不是就绪？

主要流程冒烟和回归是不是通过？

缺陷分级和修复承诺是不是达成一致？

操作手册部署文档、培训材料是不是齐备？

用户和签字人时间是不是锁定？

回滚方案和上线计划是不是确定？

验收测试的准备，应该从项目启动或需求评审时就开始，而不是验收前三天。