AI 测试提效 ｜ 告别手工写脚本，分享我的 Playwright + Skill 批量生成 UI 自动化脚本方案

上一篇我们聊了 ui-page-parser，解决了 UI 自动化「抓元素」的痛点，拿到了一份标准化的 pages.yaml。

但拿到页面元素定义只是第一步。接下来的事情，可能比抓元素更折磨人。

写过 UI 自动化脚本的同学，看看这些场景熟不熟悉：

• POM 类写到手抽筋。 每个页面要封装一个 Page Object 类，元素定位、操作方法、等待条件，全靠人工逐行敲。20 个页面就是 20 个类，重复且枯燥。
• 测试数据构造费时费力。 正向数据、边界值、非法格式、SQL 注入、空值......每个表单字段都要造一堆测试数据，还得跟脚本绑定，工作量巨大。
• 定位策略全凭个人习惯。 张三用 XPath，李四用 CSS Selector，王五用 getByText，同一个项目的脚本风格千奇百怪，后人接手想骂人。
• 编码效率低得让人怀疑人生。 一个完整的登录流程脚本（含 POM + 用例 + 数据），手写至少半天。20 个页面的电商系统，光脚本编写就要一两周。
• 用例与页面定义脱节。 手写脚本时，很容易遗漏 pages.yaml 里已解析好的元素，或者写的定位跟标准化定义不一致，导致脚本质量参差不齐。
• 新人上手门槛高。 POM 模式、数据驱动、框架规范......新人想写一个合格的 UI 测试脚本，没个一周培训根本下不来。

脚本编写，是 UI 自动化落地过程中最耗人力的环节，没有之一。

那既然已经有了标准化的 pages.yaml，能不能用 Agent Skill 把脚本生成这一步也自动化？

答案还是那句话，可以，而且效果比你想象的更好。

核心思路依然是，AI 负责批量生成，人负责校验和调试。

这篇文章就带你完整拆解这个过程。

ui-testscript-generator 在整条链路中的位置

先回顾一下 UI 自动化的完整 Skill 链路：

页面 URL / DOM 结构 / 用例描述
  │
  ▼
ui-page-parser ──→ 标准化页面定义 (pages.yaml)
  │
  ▼
ui-testscript-generator ──→ POM + 测试脚本 + 测试数据  ← 这一篇
  │
  ├──→ ui-testscript-enhancer ──→ 健壮性增强（等待+异常+截图）
  │         │
  │         ▼
  │   ui-visual-assert ──→ 视觉断言 + 多浏览器适配
  │         │
  │         ▼
  │   ui-auto-maintainer ──→ 页面变更检测 + 定位自愈
  │
  └──→ pages.yaml 也可直接用于前端组件文档生成、无障碍审计

上一步 ui-page-parser 输出的 pages.yaml，就是 ui-testscript-generator 的核心输入。

这个 Skill 做的事情，就是把一份结构化的页面定义 + 一份业务测试用例，一次性转换成完整可运行的 UI 自动化测试工程。

具体来说，它一次性批量产出三层代码：

产出层	内容	替代了什么人工劳动
pages/ 层	页面对象类（POM）	逐页手写元素定位和操作方法
testcases/ 层	测试用例脚本	逐条手写测试流程、断言逻辑
data/ 层	测试数据文件	逐个字段手造正向/边界/异常数据

一步生成，直接可用。 这不是 demo 级的代码片段拼接，而是符合团队框架规范、可直接导入 IDE 运行的完整工程结构。

ui-testscript-generator skill 技能介绍

为什么这一步最耗人力？

传统 UI 脚本开发，拿到页面元素信息之后，测试工程师需要做三件事：

第一，手写 POM 类。 每个页面对应一个类，封装元素定位和操作方法。定位策略要按规范选最优的（data-testid > 语义化 > CSS > XPath），操作方法要区分原子操作（fill、click）和组合操作（登录流程、下单流程）。一个 20 个页面的系统，光 POM 类就要写一周。

第二，手写测试用例脚本。 基于业务测试用例，组装完整的操作链路、断言逻辑、异常分支。还要处理数据驱动（YAML/JSON 参数化）、前置条件（登录态预设）、后置清理（数据回滚）。

第三，手造测试数据。 每个表单字段都要造正向数据、边界值、非法格式、空值、SQL 注入......一个登录表单 3 个字段，至少 15 组测试数据，全靠人工想。

这三件事加起来，是整个 UI 自动化流程中工作量最大的环节。 传统模式下，一个 20 个页面的系统，从 POM 到用例到数据，至少需要 2-3 周。

我的方案

ui-testscript-generator 是专门用于基于结构化页面定义，一次性批量生成页面对象模型（POM）、测试用例脚本、定位策略、测试数据的 Skill。

将数据生成与脚本生成合并为一个综合 Skill，简化调用流程，提升上手效率。

核心能力：

• 测试数据智能构造：基于表单字段定义，自动构造正向数据、边界值、非法格式、空值、SQL 注入/XSS、超长数据、业务规则冲突数据，覆盖全场景
• POM 页面对象生成：每个页面对应一个 POM 类，智能推导定位策略，封装原子操作（fill、click、select）和组合操作（登录流程、下单流程）
• 测试用例脚本生成：按场景分类生成测试用例（Normal/Exception/Boundary/Security），自动绑定测试数据，自动生成多维度断言
• 按需生成约束：以业务测试用例为唯一输入源，pages.yaml 仅作为元素定位的查询数据库，测试用例涉及哪些页面，就只生成哪些代码，杜绝冗余
• 框架规范固化：团队 UI 自动化框架规范（框架选型、目录结构、定位策略优先级、等待机制、断言策略）作为 Skill 的基础能力，保证生成脚本的规范性
• 工程化项目结构：自动生成完整的项目目录结构（config、pages、tests、data、utils、fixtures、reports），符合 POM 分层设计

输入：

1. ui-page-parser 输出的 pages.yaml（标准化页面对象定义）
2. 业务测试用例文件（Excel 版详细测试用例，或自然语言描述）
3. 测试数据规则（可选，用于自定义数据构造规则）

实操演示

将技能安装好，在技能列表中，选择 ui-testscript-generator 技能。

输入两份文件：

/ui-testscript-generator
请基于以下文件生成 UI 自动化测试脚本：
1. pages.yaml（ui-page-parser 输出的页面对象定义）
2. 测试用例文件（Excel 版业务测试用例）

为了方便调试，测试用例文件建议先精简，先只保留少数核心业务用例：

接下来，Skill 会自动完成六个步骤：

第一步，解析输入，建立生成范围。

Skill 读取测试用例文件，提取涉及的页面名称（如登录页、注册页），然后从 pages.yaml 中筛选对应页面的元素定义。只生成测试用例涉及到的页面代码，无关页面一律不生成。

第二步，初始化项目结构，生成 POM 页面对象。

根据团队框架规范，自动创建标准化的项目目录结构，然后为每个页面生成对应的 POM 类，封装元素定位和业务操作方法。

第三步，生成测试用例脚本。

基于业务测试用例的交互链路，自动组装完整的测试流程，添加多维度断言（元素可见性、文本内容、URL 跳转），按场景分类（正向流程、异常分支、边界值、安全测试）。

第四步，生成测试数据、fixtures 和 DataFactory。

基于表单字段定义，自动构造覆盖全场景的测试数据（正向、边界、非法、空值、注入），生成数据工厂和 fixtures，实现脚本与数据解耦。

第五步，生成配置文件。

自动生成 Playwright 配置、环境配置、pytest.ini 等工程化配置文件。

第六步，检查验证，生成交付清单。

检查生成后的代码完整性，输出最终的项目结构和文件清单。

最终输出什么？

打开自动生成的 ui-test-automation 项目目录，用 VSCode 检查一下：

最终产出的完整工程结构如下：

ui-test-automation/
├── config/                     # 配置管理
│   ├── settings.py             # 全局配置（环境、超时、浏览器）
│   └── environments/           # 环境隔离配置
│       ├── dev.yaml
│       ├── staging.yaml
│       └── prod.yaml
├── pages/                      # 页面对象层（POM）
│   ├── base_page.py            # 所有 Page 的基类
│   ├── components/             # 可复用 UI 组件
│   └── [module]/               # 按业务模块划分
│       ├── login_page.py       # 登录页 POM
│       └── register_page.py    # 注册页 POM
├── tests/                      # 测试用例层
│   ├── conftest.py             # Pytest 全局 fixture
│   └── [module]/
│       ├── test_login.py       # 登录测试用例
│       └── test_register.py    # 注册测试用例
├── data/                       # 测试数据层
│   └── [module]/
│       ├── login_positive.yaml    # 正向数据
│       ├── login_negative.yaml    # 异常数据
│       └── login_boundary.yaml    # 边界值数据
├── utils/                      # 工具层
│   ├── data_loader.py          # 数据加载
│   ├── retry_decorator.py      # 重试装饰器
│   └── screenshot_helper.py    # 截图辅助
├── fixtures/                   # 测试夹具
│   └── auth_fixture.py         # 登录态预设
├── reports/                    # 报告输出
│   ├── screenshots/            # 失败截图
│   └── traces/                 # Playwright Trace
├── pytest.ini                  # Pytest 配置
└── requirements.txt            # 依赖管理

核心价值：替代人工从零编写 POM 和用例，一步完成「数据 + 页面 + 用例」的全量产出，保证脚本的规范性和可维护性。合并数据生成与脚本生成，上手更快、操作更简单、一步生成即用，特别适合快速落地、小型项目、新手入门。

全流程串联回顾

把上面整个过程用命令行风格串起来，就是这样的：

# 1. 准备输入（上一步 ui-page-parser 的产出 + 业务测试用例）
pages.yaml          ← 标准化页面对象定义（21 个页面）
testcases.xlsx      ← 业务测试用例（精简版，2-3 条核心用例）

# 2. 一句指令启动生成
/ui-testscript-generator 请基于 pages.yaml 和测试用例文件生成脚本

# 3. AI 自动完成六步（无需人工干预）
   ├─ Step 1: 解析输入 → 建立生成范围（只涉及登录、注册页）
   ├─ Step 2: 初始化项目结构 → 生成 POM 页面对象类
   ├─ Step 3: 生成测试用例脚本 → 正向/异常/边界/安全分类
   ├─ Step 4: 生成测试数据 → 数据工厂 + fixtures
   ├─ Step 5: 生成配置文件 → Playwright + pytest + 环境隔离
   └─ Step 6: 检查验证 → 输出交付清单

# 4. 最终产出
   ui-test-automation/
   ├── pages/        ← POM 页面对象类
   ├── tests/        ← 测试用例脚本
   ├── data/         ← 测试数据文件（YAML）
   ├── utils/        ← 工具函数
   ├── fixtures/     ← 测试夹具
   ├── config/       ← 环境配置
   └── reports/      ← 报告输出目录

# 5. 下游直接消费（下一篇内容）
   基础脚本 → ui-testscript-enhancer → 健壮性增强（等待+异常+截图+验证码）

AI 负责生成，人负责调试

这里有一个关键认知需要说清楚，AI 生成的脚本，不一定能立刻跑通，需要人工调试。

ui-testscript-generator 能帮你完成的是「从 0 到 80」的编码工作，把数天甚至数周的手写代码压缩到几分钟。但以下这些事情，AI 做不了，仍然需要人来把关：

AI 负责的事	人负责的事
POM 类结构生成	检查元素定位是否跟真实页面一致
测试数据批量构造	校验数据是否符合业务规则
测试用例脚本组装	调试断言逻辑是否合理
项目工程结构搭建	补充特殊业务逻辑（如验证码处理）
定位策略优先级推导	确认定位策略在真实环境中的稳定性
数据驱动适配	调试环境依赖（数据库、Mock 服务）

虽然自动生成好的脚本不一定能立马直接执行（脚本执行和调试会在后续内容讲解），但所有基础编码、页面封装、脚本结构、框架搭建等前置工作均已完成。

这些工作同样能极大减少人工重复编码的工作量，让我们可以把精力集中在脚本调试、业务逻辑适配等核心工作上。

特别提醒： 在调试期间，建议先把测试用例精简到10 条左右的核心流程上，验证 Skill 的生成质量和定位策略准确性后，再逐步扩大用例范围。

还有一个重要的设计原则值得提一下。在这个 Skill 的设计中，脚本生成以业务测试用例文件为唯一输入源，pages.yaml 仅作为元素定位的查询数据库。

什么意思呢？即使你的 pages.yaml 包含了全站 100 多个页面的元素定义，但测试用例只涉及「登录」和「注册」，那最终就只生成这两个页面的 POM 类和测试脚本，其余页面一律不生成。

按需生成，杜绝冗余。 这个约束看似简单，但在实际项目中能帮你省掉大量无效代码和维护成本。

Skill 源码与完整教程

大家可以自己根据本文提供的思路进行开发 skill，如果需要现成的教程和 skill，也可以加入「狂师 . AI 进化社」获取，里面有各类 AI 技术落地保姆级图文教程、视频教程，包括 AI 赋能测试全流程的实战教程（保姆级手把手喂饭教程，跟着步骤操作，零基础也能快速上手，目前含有 30 多个 AI 测试全场景的 Agent Skill）

温馨提醒，「AI 测试」只是 AI 进化社八大技能版块之一。

写在最后

回顾一下整个流程：

痛点： POM 类写到手抽筋、测试数据造到头秃、定位策略全凭个人习惯、新人上手门槛高。

方案： 用 ui-testscript-generator Skill，输入 pages.yaml + 业务测试用例，一次性批量生成 POM 类、测试脚本、测试数据、配置文件，输出完整的工程化项目结构。

效果： 传统模式下，人工编写 20 个页面的 POM + 用例 + 数据，至少需要 2-3 周。而 ui-testscript-generator 只需要几分钟，就能完成全量代码产出，且符合团队框架规范。

边界： AI 负责批量生成，人负责校验和调试。AI 把「从 0 到 80」的编码工作干完，人聚焦在「从 80 到 100」的调试和业务适配。

这里再说一个设计上的考量。为什么把数据生成和脚本生成合并到一个 Skill 里？

因为在 UI 测试中，数据构造与脚本编写高度耦合。同一表单字段的测试数据直接驱动对应的页面操作步骤，数据变化直接影响脚本执行路径。拆开反而增加了调用复杂度，合并后一步拿到完整可运行的项目，上手更快。

目前这套 AI 测试赋能的 Skill 技能组合，「狂师 . AI 进化社」的成员都在使用，很多同学反馈，UI 自动化脚本编写效率提升了数倍，不再被重复编码折磨了。

下一篇，我们聚焦 ui-testscript-enhancer，聊聊如何对基础脚本进行健壮性增强，自动补全智能等待、异常处理、弹窗拦截、验证码识别、失败截图等能力，让脚本从「能跑」进化为「跑得稳」。