08｜AI 生成自动化测试脚本怎么做？生成之后怎么验证？

开场先讲当前的现实能力边界：AI 生成脚本比生成用例门槛高（要可执行、要跑在真实环境）——当前成熟的做法是「生成加人工补」而不是「全自动」。

回答思路

第一步：分场景的成熟度排序（分梯度投入）

场景	成熟度	说明
单测生成	最成熟	有函数签名和 docstring 就能生成，开发自测用
接口脚本	较成熟	给 swagger 或抓包报文，生成 requests/pytest 骨架加基础断言，人工补业务断言
UI 脚本	辅助级	给页面结构或现有 PO 生成操作代码——定位器要人工核对（AI 看不到真实页面 DOM）

别在 UI 上硬要全自动。

第二步：讲输入材料决定质量

喂的东西越结构化产出越好：接口文档、swagger、现成的代码样例（让它模仿团队风格）、页面 DOM 片段——垃圾进垃圾出，在代码生成上尤其明显。

第三步：验证机制三层

1. 静态检查：语法、风格、是否符合团队规范先机筛
2. 试运行：沙箱环境跑一遍看能不能执行通过
3. 断言审计（重点人审）：AI 写的断言常常「能过但没测到点上」——比如只断言状态码 200 不断言业务语义

第三层是关键——脚本能不能跑和测没测到是两回事。

收尾：讲维护视角

AI 生成的脚本进库后和普通脚本一样要维护——把 AI 生成时的 prompt 和输入材料存档（脚本出问题知道当时怎么生成的）。生成脚本的可追溯性是长期维护的前提。

考察重点

维度	说明
企业动机	脚本是测试团队最大的工时黑洞，AI 生成脚本是企业最期待的提效点，但也最容易翻车（生成的脚本看着能跑实际是摆设）
过线标准	分场景的成熟度认知 + 三层验证（尤其断言审计）
区分度	讲「能跑和测到是两回事」、讲生成材料存档可追溯的是真在生产里用过的
加分项	让 AI 模仿团队现有代码风格的输入设计
减分项	宣称「AI 一键生成全套脚本直接上线」——不了解断言质量的坑，会被追问打脸

来源

整理自知识星球帖《面试情报 06｜AI 测试提效 20 题》，返回题库。