AI 自动化测试脚本为何首跑即失败

一、一个普遍的错觉：AI 会写代码，自动化就能补起来

后台管理系统、订单平台、审批流、数据报表这类项目，页面结构相对规整，业务路径清晰，看上去非常适合用 UI 自动化批量覆盖。很多团队的想法很直接：既然智能编程工具已经能写出像模像样的代码，那把页面地址和操作步骤丢给它，脚本不就批量产出了吗？

真正动手之后，第一条脚本往往就跑不起来。

需要先澄清一点：这不是自动化框架不好用，也不是模型完全不会写代码。卡住大多数人的环节，是测试场景没有被讲清楚。不少人给智能编程工具的提示词只有一句话——“帮我写一个自动化测试脚本”。这句话的信息量几乎为零。模型只能去猜页面结构、猜按钮文案、猜登录方式、猜断言点，最终生成的代码看上去结构完整、语法正确，一执行就报错：元素找不到、登录态丢失、弹窗没关掉、异步数据没加载完就断言。

后台系统自动化的难点，从来不是“点一个按钮”这么简单。它真正考验的是一整条工程链路：

• 页面怎么进入，入口 URL 与前置路由是什么；
• 登录态怎么复用，是否需要绕过验证码、是否有多因子环节；
• 元素怎么定位，用角色定位、文本定位还是测试专用属性；
• 弹窗、遮罩、新标签页怎么处理；
• 异步请求与渲染怎么等待，等待什么条件；
• 断言点设在哪里，断言什么内容才算有效验证；
• 测试数据怎么准备、怎么清理，避免用例之间互相污染；
• 脚本怎么组织、怎么接入持续集成流水线。

AI 生成脚本的上限，不取决于模型多聪明，而取决于你把测试场景描述到什么颗粒度。 这也是为什么同样使用智能编程工具，有人能快速产出一批可维护脚本，有人只能得到一堆无法运行的示例代码。

二、这类系统为什么“适合自动化”却“做不起来”

先看这类系统的共性。管理后台、客户关系管理、企业资源计划、人力资源系统、财务结算平台、内部办公与审批系统、数据报表平台，它们的页面形态高度重复：列表页、查询条件区、表单、弹窗、详情页、导入导出、权限控制。单个页面不复杂，但页面数量极大。

从技术角度看，现代浏览器自动化框架对这类应用的支持相当完整：可以处理登录跳转、新标签页、弹窗、文件上传下载、网络请求监听与 mock。例如下载场景中，可以在点击前监听下载事件，再从下载对象中读取文件流；网络场景中，可以监听、修改甚至拦截页面请求，用来构造边界条件。这些都是成熟能力，不存在技术障碍。

但团队依然做不起来，原因很现实：

1. 页面太多，手写成本高。 数百个页面，每个页面三五个用例，人工编写与维护的工作量难以承受。
2. 业务变化快，脚本容易坏。 选择器写死、文案硬编码，界面一改脚本全红。
3. 测试人员不熟悉前端结构。 知道业务该怎么测，但说不清 DOM 层级与组件行为。
4. 前端人员不懂测试设计。 能定位元素，但不知道断言该设在哪、边界该怎么覆盖。

智能编程工具出现后，很多人以为上述问题会自动消解。实际情况是：它降低了写代码的门槛，但没有自动补齐测试设计能力。 你让模型写“登录测试”，它会给你一段登录代码；但它不知道你的系统有没有图形验证码、是否要求短信二次验证、登录成功后是跳转首页还是弹出引导层、失败时的错误提示是行内文案还是全局通知。这些信息缺失，代码再工整也无法执行。

三、把“一句话需求”拆成“可执行规格”

要让 AI 产出可运行脚本，提示词必须从“意图描述”升级为“规格描述”。一份合格的规格至少应覆盖以下维度。

1. 环境与入口

明确基础地址、目标路由、是否需要特定环境变量、是否依赖预置数据。例如：

基础地址从环境变量 BASE_URL 读取；
登录页路径 /login；
登录成功后应跳转到 /dashboard，以 URL 包含 /dashboard 作为成功判据。

2. 登录态复用策略

这是后台系统自动化的第一道坎。要说明验证码如何处理（测试环境关闭、固定值、还是通过接口预置令牌），登录态是每次用例重新登录，还是通过存储状态（storageState）在用例间复用。明确写出：优先使用一次登录、保存状态、后续上下文复用的方式，避免每条用例重复登录拖慢整体执行。

3. 元素定位约定

给出稳定的定位优先级，并要求模型遵守：

定位优先级：get_by_role > get_by_label > get_by_test_id > get_by_text；
禁止使用绝对 XPath 与含随机索引的 CSS 选择器；
若页面缺少测试专用属性，在输出中标注需补充的属性建议，而不是硬编码文本。

4. 交互细节

把容易出错的交互显式写出：弹窗是确认后关闭还是自动消失；下拉框是原生 select 还是自定义组件；表格是否存在虚拟滚动；上传是点击触发还是拖拽触发；是否存在新标签页需要切换上下文。

5. 异步等待规则

禁止固定时长睡眠，要求以条件等待为主：等待网络请求返回、等待特定元素可见、等待加载遮罩消失。可给出示意：

page.get_by_role("button", name="查询").click()
page.wait_for_response(lambda r: "/api/orders" in r.url and r.status == 200)
expect(page.get_by_role("table")).to_be_visible()

6. 断言设计

断言必须有业务含义，而不是“页面没报错”。要求区分三类断言：结果数据断言（列表条数、字段值）、状态断言（跳转 URL、提示文案）、副作用断言（数据落库后的查询结果）。同时要求每个用例至少包含一个正向断言和一个失败路径断言。

7. 测试数据管理

说明数据从哪来（预置夹具、接口创建、还是页面创建），用例结束后如何清理，如何保证用例可重复执行、互不干扰。建议要求模型将数据准备封装为独立夹具，而不是散落在用例步骤中。

8. 工程结构与集成

明确目录结构、页面对象划分粒度、配置读取方式、报告输出格式、是否需要在无头模式下运行、失败重试与截图留存策略。这些约束会让生成的脚本直接具备进入持续集成流水线的条件，而不是停留在“本地能跑一次”的示例。

四、对比：模糊提示与结构化提示的产出差异

假设目标是测试订单列表的查询功能。

模糊提示：

帮我写一个订单列表查询的自动化测试。

模型大概率给出：打开某地址、点击“查询”、断言页面标题。选择器靠猜，等待靠 sleep，断言几乎无意义。

结构化提示（节选）：

场景：订单列表按状态筛选。
前置：已登录，登录态从 storageState 复用；进入 /orders 页面。
步骤：
1. 在“订单状态”下拉框中选择“已发货”，该组件为自定义下拉，需先点击触发器再选择选项；
2. 点击“查询”按钮；
3. 等待 /api/orders 请求返回且状态码为 200；
断言：
- 表格所有行的状态列文本均为“已发货”；
- 表格行数等于接口返回的 total 字段值；
- 若无数据，应展示空状态文案而非空白表格。
约束：禁止 sleep；定位优先使用 role 与 test id；输出页面对象类与用例分离。

后者的产出才具备可运行、可维护、可评审的基础。差别不在于模型能力，而在于输入信息的密度与结构。

五、落地建议：从“能跑”到“可维护”

第一，先做一条样板脚本。选一个页面结构最典型、业务价值最高的场景，按上述规格完整写一次提示，人工评审并跑通，把它作为团队的提示模板与代码范式。

第二，建立场景描述清单。把环境、登录、定位、等待、断言、数据、集成七类信息做成填写模板，测试人员填业务部分，开发人员补技术约束，减少反复沟通。

第三，把稳定性约束前置。在提示中明确禁止固定睡眠、禁止脆弱选择器、要求失败时输出截图与请求日志，从生成阶段就规避最常见的脚本腐化原因。

第四，小步接入流水线。先让脚本在合并请求中按标签运行关键路径，稳定后再扩大覆盖面，避免一次性铺开导致维护成本失控。

结语

智能编程工具确实改变了 UI 自动化的成本结构，但它改变的是“写代码”这一段，而不是“设计测试”这一段。后台系统自动化的真正门槛，始终在于能否把业务场景拆解为环境、状态、定位、等待、断言、数据、集成这些可执行要素。把这些讲清楚，AI 才能把代码写对；讲不清楚，再强的模型也只能产出看起来像那么回事、跑起来就报错的示例。第一条可运行脚本的距离，往往就是一份规格说明的距离。