让 AI 扮演用户，跑完应用验收测试

代码测试通过了，用户就能顺利干活吗？作者在把一款沙龙业务应用交给真实店主前，让另一个独立的 AI 会话在测试电脑上扮演店主，用假数据跑了四轮、共 61 个验收场景。第一轮发现 19 个缺陷，其中一些相当严重；修复后，后续轮次未再发现问题。

这次实践值得看的是场景怎么选：重复导入、错误时区、断网、越权访问，都是正常演示容易绕开的麻烦。它也明确留下了假数据无法验证的部分，等真实店主参与时再检查。

测试通过，为什么还要扮演用户走一遍

作者区分了两个问题：自动化测试检查代码是否按编写时的预期运行，验收测试则检查用户能否用它完成实际工作。

对沙龙店主来说，任务不是让某个导入函数返回成功，而是登录系统、导入预约、核对记录，再把空闲时段分享出去。任何一个环节出错，整条业务流程都可能卡住。

作者因此安排了一个独立的 AI 会话，在测试电脑上使用假数据操作应用。这种安排提供了另一个观察角度，但原文没有交代 AI 使用了什么模型、如何控制电脑，也没有说明场景由谁设计、结果如何逐项确认。

这次验收的价值，主要来自对真实工作流程和异常情况的覆盖。

61 个场景，专门挑哪些麻烦

四轮验收并非只重复正常操作，而是主动制造容易遗漏的条件。

登录方面，检查首次登录后的强制改密，以及多次输错密码后锁定机制的表现。权限方面，准备两家沙龙，每家有多名用户，检查数据是否跨店泄漏，以及员工能否访问店主设置。

导入场景尤其贴近日常业务：Excel 使用意大利语列名，日期混用三种格式，电话号码里有空格、短横线和 +39 前缀，姓名带重音字符，还夹杂少量损坏行。他们还重复导入同一个文件，并检查两次导入之间发生预约取消时，系统如何处理。测试电脑也被设置成错误时区。

这些情况考验的不是单独一个字段能不能解析，而是数据经过多次操作后，业务状态还能否保持正确。

数据量也拉到了 500 名客户、2000 条预约，用来观察列表不再很小时页面如何表现。交互检查则包括双击、慢网络、断网，以及表单填写过程中会话过期。

界面检查覆盖 390 像素宽的手机视口和桌面视口、浅色与深色主题，还要求每个表单都能通过键盘操作。能点开页面，只是验收的起点。

假数据验收，必须留下哪些待办

第一轮发现的 19 个缺陷全部修复，后续轮次结果干净。但作者没有把这个结果当成所有业务都已验证。

测试电脑无法接触沙龙预约软件的真实 Excel 导出，也无法验证一条真实 WhatsApp 消息。于是，这些问题被留到与店主的首次使用环节：

登录应用，导入两周的预约，从中抽查三条并与原始记录核对；手动报告一个空闲时段，再用店主自己的手机打开链接。

这里划出了很实用的边界：假数据能覆盖复杂输入，却不能证明真实导出文件一定兼容；测试电脑上的流程能走通，也不能替代真实手机上的最后一步。

我的判断

我认可这套做法。小应用交付时，最容易漏掉的往往是跨步骤的问题：重复操作如何处理、登录状态失效后表单怎么办、不同账号到底能看见什么。按用户任务走流程，确实能补充只围绕函数和接口编写的测试。

不过，作者关于「验收会发现另一类错误」的结论，目前仍是这次项目的经验之谈。原文没有列出 19 个缺陷的具体内容，也没有提供人工验收与 AI 验收的对照数据，无法据此判断 AI 的发现率或成本优势。

自动化测试同样可以覆盖业务流程和权限隔离，区别不能简单按工具划分。更重要的是检查目标、数据和操作顺序。作者也没有给出页面性能指标，因此 500 名客户、2000 条预约只能视为一次指定规模的检查，不能当作容量承诺。

能拿来做什么

• 给小型管理后台增加一次按用户任务组织的交付验收，从首次登录走到核心业务完成，并记录每一步的预期结果。
• 对 Excel 导入功能准备脏数据样本，覆盖混合日期格式、电话号码差异、损坏行和重复导入，同时检查两次导入之间的业务变更。
• 验收前端表单时加入双击、断网、慢网络和会话过期，再检查手机视口、主题切换及键盘操作是否影响任务完成。
• 把真实文件、真实账号和真实设备才能验证的事项单独列出，安排用户首次使用时逐项核对，避免把假数据验收通过当作交付完成。