简介：很多团队尝试用 AI 生成 UI 自动化脚本，却卡在“第一条可运行脚本”上。本文结合管理后台、ERP、审批系统等典型场景，分析 AI 生成测试代码的常见误区，梳理可落地的场景描述方法与脚本设计思路，帮助测试与研发人员提升自动化脚本的可用性和可维护性。
用 AI 辅助生成 UI 自动化测试脚本，听起来效率很高。尤其是后台管理系统、ERP、HR SaaS、内部 OA、审批系统这类项目，页面结构相对稳定，业务路径清晰，似乎很适合批量生成自动化用例。
但真正动手之后，很多人会卡在第一步：生成的脚本跑不起来。
原因通常不是底层自动化框架不好用，也不是模型完全不会写代码，而是测试场景没有被准确、完整地描述出来。
常见的情况是，使用者只给出一句非常笼统的指令，比如：
“帮我写一个后台系统的自动化测试脚本。”
这句话缺少太多关键信息。模型不知道系统入口在哪里，不知道登录方式是什么，不知道页面有哪些字段，不知道按钮文案，也不知道期望结果是什么。最终生成的代码看起来结构完整，一旦运行就会发现元素定位失败、等待时机不对、断言条件错误。
这不是模型能力的问题，而是输入信息不足以支撑代码生成。
很多人以为后台系统自动化就是“打开页面、点几个按钮”。实际上，一个能够稳定运行的脚本，至少需要解决以下问题：
元素定位策略
页面元素是否有稳定 ID？是否依赖动态生成的 class？表格行数变化时如何定位目标行？同一类按钮在页面中出现多次时如何区分？
弹窗与浮层处理
保存成功是否有 toast 提示？删除操作是否需要二次确认？弹窗是页面内浮层还是浏览器原生弹窗？
异步加载与等待机制
列表数据是同步渲染还是异步请求？表单保存后页面是否局部刷新？网络较慢时如何避免误判失败？
断言设计
验证的是页面文案、接口响应、数据状态还是下载文件？断言过于宽泛会导致漏测，过于严格又会增加维护成本。
测试数据准备与清理
新增、编辑、删除操作是否依赖已有数据？测试完成后是否需要恢复现场？重复执行时如何避免数据冲突？
这些问题中，任何一个没有事先定义清楚，AI 生成的脚本都可能无法直接运行。工具只能负责“写代码”，而测试设计仍然需要人来完成。
从实际使用情况来看，AI 生成 UI 自动化脚本最常见的问题集中在以下几个方面。
模型并不真正“看到”页面。如果没有提供 DOM 结构、元素属性或页面截图，它只能根据常见后台系统的通用模式进行猜测。例如，它可能假设登录按钮的文案是“登录”，但实际系统可能是“立即进入”或“Sign in”。
自动化测试脚本需要覆盖一条完整的业务路径。例如，创建一个新用户，可能需要先进入列表页，点击新增按钮，填写表单，选择所属角色，点击保存，再回到列表页验证新记录是否出现。如果只告诉模型“写一个新增用户的测试”，它很难自动推导出这些步骤。
AI 倾向于生成最直接的同步代码，例如点击按钮后立即查找结果。但真实系统中，操作后往往需要等待接口返回、页面渲染或动画结束。如果脚本中没有合理的等待机制，执行结果会非常不稳定。
断言是判定测试是否通过的关键。如果场景描述中没有明确“验证什么”，模型可能会生成一个非常宽泛的断言，例如只验证页面包含某个关键词，而不是验证特定数据行是否出现、状态是否正确。
要让 AI 生成的 UI 自动化脚本真正可运行，核心是提升场景描述的精确度。可以从以下几个方面入手。
在提示中明确说明系统的入口 URL、页面之间的跳转关系、主要元素的选择器类型。例如：
信息越具体，模型生成的定位策略越贴近真实页面。
将测试场景拆解为清晰的步骤，每一步都说明操作对象和预期反馈。例如：
步骤一：打开用户管理页面
步骤二：点击“新增用户”按钮
步骤三：填写姓名为“测试用户”
步骤四：选择角色为“普通用户”
步骤五：点击“保存”
步骤六：验证页面出现“保存成功”的提示，并且用户列表第一行显示“测试用户”
这种描述方式可以让模型生成更有针对性的脚本，而不是泛泛的示例代码。
如果能提供关键元素的 id、name、data-testid 等属性，脚本的稳定性会显著提高。例如：
用户名输入框：
input[name="username"]
密码输入框：input[name="password"]
登录按钮：button[type="submit"]
即便无法提供完整 DOM，也可以描述元素的可见文案、位置关系或父级结构，帮助模型做出更合理的定位选择。
后台系统中存在大量特殊交互，例如：
这些行为直接关系到脚本能不能正确执行。提前说明，可以避免模型采用默认的简化处理方式。
自动化脚本的可重复执行能力，很大程度上取决于测试数据管理。可以在描述中说明：
以下是一个对比示例，展示从“模糊描述”到“可执行描述”的差异。
改进前：
帮我写一个后台登录的自动化测试。
模型可能生成一个简单的脚本：打开登录页，输入 admin 和 123456，点击登录，然后检查页面是否有“欢迎”。如果真实系统包含验证码、加密密码或二次验证，该脚本几乎无法运行。
改进后：
系统登录页地址为
http://xx.xx.xx.xx/login。
登录表单包含以下元素：
- 用户名输入框：
input[name="username"]- 密码输入框：
input[name="password"]- 登录按钮：
button[type="submit"]
系统当前未启用验证码。
使用固定账号test_user和密码Test@123登录。
登录成功后页面跳转至/dashboard，页面顶部右上角显示用户名“测试用户”。
请生成一条登录成功的自动化测试脚本，并断言跳转成功且用户名正确显示。
基于这样的描述，AI 生成的代码会明显更接近真实可用的状态。
AI 工具降低了编写自动化脚本的语法门槛，但测试设计能力仍然是关键。团队需要有人能够：
如果缺乏这些能力，即便 AI 能够生成代码，得到的也只是一堆无法长期维护的脚本片段。
因此，团队在引入 AI 辅助测试时，不应该把重点完全放在“生成代码”上，而应该同时沉淀测试场景描述规范、元素定位规范、数据管理规范和断言设计规范。这些工程化能力的建设，决定了 AI 生成脚本的可用上限。
AI 辅助 UI 自动化测试并非伪需求，很多团队也确实看到了初步效果。但真正决定成败的，不是模型能力，而是场景描述的质量和测试设计的基础能力。
对于后台管理、ERP、OA 这类页面数量多、业务路径清晰但交互细节复杂的系统，AI 更适合作为脚本生成的加速器，而不是替代测试设计的万能方案。把测试场景说清楚，把断言和数据策略定义清楚，AI 生成的脚本才能真正跑起来，并持续产生价值。