小王加班到晚上九点，就为了改一个客户说“按钮点不动”的问题。其实那个按钮一直能用，只是没加 loading 状态，客户以为卡死了。这事儿跟验收测试没做好直接相关——不是代码写错了，是大家对“验什么、怎么验”理解偏差太大。
误区一：把验收测试当成“再测一遍功能”
开发做完，测试照着用例点一遍，通过就交差。结果客户一上手，发现导出 Excel 的文件名全是“report.xlsx”，没带日期；或者微信分享链接里参数漏了，转发后打不开。这些不是功能缺陷，是交付预期没对齐。验收测试不是复测，而是站在用户真实场景里，看它“顺不顺、像不像、靠不靠得住”。
误区二：只让测试人员验，客户全程隐身
某电商后台系统上线前，内部测试全绿，结果客户第一次用就问：“为什么不能按快递单号批量查物流？”——原来需求文档里写了“支持单号查询”，但没明确说“批量”。测试照着单条查的用例过了，没人拉客户一起走一遍典型操作流。验收必须拉真用户来试，哪怕只花半小时，让他自己登录、下单、导数据、发通知，比十份测试报告都管用。
误区三：把“通过”等同于“没问题”
有个 SaaS 工具验收时点了 5 次“生成报表”，每次成功，就标“通过”。可客户实际每天要跑 300 次，第 297 次开始报错：“内存溢出”。验收得模拟真实负载，比如连续操作 10 分钟、上传 100 个文件、切换 20 个账号来回登录。不试极限，就等于埋雷。
误区四：忽略环境差异，本地通=线上稳？
开发者在自己笔记本上验收通过，数据库连的是本地 SQLite；一上生产，换成 MySQL，时间字段格式崩了，订单创建时间全变成“1970-01-01”。还有更隐蔽的：测试环境关了邮件发送，验收时根本没发过一封测试邮件，结果上线后客户收不到注册验证码。验收环境越贴近生产越好，配置、网络、第三方服务一个都不能少。
补救小贴士（不用写总结，直接给干货）
• 验收前，和客户一起列 3～5 个“他每天必做的动作”，只验这些，不贪多；
• 给每个验收项配一句大白话描述，比如“导出的表格，第一行必须是中文标题，不是英文字段名”；
• 把生产环境的数据库备份一份，导入测试库，拿真实数据跑流程；
• 验收记录别只写“通过/失败”，加一行“谁、什么时候、在哪台设备上、做了什么、看到什么”。
验收测试不是终点站，是交付前最后一道“人话翻译”。代码能跑，不等于用户能用；测试通过，不等于问题清零。多问一句“你平时怎么用？”，少写一行“已验证通过”，上线才能少挨骂。