最近我在做一件我自己觉得很有价值的事：
不是让 AI 只帮我“写一点代码”，而是让 AI 真正参与到 UI 自动化测试链路里。
从需求开始，到手工用例生成，再到自动化用例生成，再到执行工具调用、结果查看，整条链路已经可以跑起来了。
这不是“停留在概念验证”的那种尝试。 而是已经进入了一个很真实的阶段：
- 流程能通
- 结果能出
- 部分场景真的能跑
- 但也很明显，还有一些关键短板必须补齐
尤其是两类问题，目前还是瓶颈：
- 前置条件准备类用例还不够稳定
- 异常场景构造能力还不够强
所以这篇文章，我想不讲空话，直接把这套流程是怎么跑起来的、跑通了什么、卡在什么地方、下一步该怎么补，完整整理出来。
一、我想做的，不是“AI 写脚本”，而是“AI 参与测试闭环”
很多人提到 AI + 测试，第一反应是：
- 让 AI 帮忙写几段自动化脚本
- 让 AI 生成几个测试点
- 让 AI 改改断言
这些当然有价值。 但我更想做的，其实是另一件事：
让 AI 能够理解需求、拆解测试、生成用例、产出自动化脚本，并接入执行工具，形成一个可跑的闭环。
也就是说，我想搭的是这样一条链路：
需求 → AI可理解的结构化描述 → 手工用例 → 自动化用例 → 调用执行工具 → 查看结果 → 继续修正
这和单点使用 AI 最大的区别在于：
它不是“AI 帮我做一小段工作”，而是“AI 成为这条测试生产线中的一个稳定节点”。
二、这条流程现在是怎么跑的
第一步：产品先写“AI 能认识的需求”
这一步非常关键。
如果产品写出来的需求还是那种纯自然语言、上下文跳跃很大、依赖大量口头补充的信息，AI 后面其实很难稳定理解。
所以一开始，需求本身就要尽量往 结构化、明确化、可判断 的方向去写。
第二步：开发把需求转成“带楼层”的需求
这一步本质是把需求进一步转成一种 分层、分块、可定位 的表达方式。
比如：
-
- 页面入口
- 1.1 页面展示内容
- 1.2 输入项规则
- 1.3 按钮交互
- 1.4 异常分支
- 1.5 成功路径
- 1.6 依赖前置条件
第三步：根据开发整理后的需求，生成手工测试用例
这一阶段生成的内容一般包括：
- 用例标题
- 前置条件
- 测试步骤
- 预期结果
- 覆盖的需求楼层
- 正常流 / 异常流 / 边界流分类
第四步：根据手工用例生成自动化用例
基于手工用例进一步生成自动化用例，包括：
- 自动化步骤描述
- 页面操作序列
- 元素定位思路
- 断言点
- 执行顺序
- 用例依赖关系
第五步：调用执行工具去跑，并查看执行结果
这一步是关键验证点：
- 调用执行工具
- 实际运行自动化用例
- 获取执行结果
- 查看通过 / 失败情况
目前结论是：
流程整体是通的，而且真的能跑。
三、当前跑通说明了什么
- 需求到测试资产的转化路径成立
- 手工用例可以作为自动化生成中间层
- 自动化执行不是完全脱节，部分结果可真实回收
四、当前两个明显瓶颈
问题一：前置条件准备能力不足
很多场景依赖复杂前置条件，比如账号状态、数据前置、权限配置、环境开关等。
AI 现在往往知道“需要前置条件”，但不一定知道“如何稳定造出前置条件”。
问题二：异常场景构造能力不足
AI 可以想到很多异常，但难点在于把异常变成可复现、可执行、可验证的工程动作。
五、我的判断
生成层已经逐渐形成方法
包括：
- AI 可识别需求写法
- 带楼层结构化需求
- 需求→手工用例→自动化用例
执行层还要继续深挖
重点在：
- 稳定准备前置条件
- 工程化构造异常
- 执行结果可回收与自动归因
- 降低 UI 自动化脆弱性
- 打通“生成-执行-失败回流-再修正”闭环
六、真正难点
AI 测试真正难的，不是让 AI 生成内容，而是：
- 输入是否标准
- 中间层是否稳定
- 执行基础设施是否工程化
七、最后结论
AI 不会简单替代测试工程师，但会明显改写测试工作的方式。
测试的重心会逐步从“手工生产测试资产”，转向“设计一条让 AI 稳定生产测试资产的系统”。
如果你也在做 AI + 测试，欢迎交流。 我也会继续把这条链路后续踩过的坑、验证过的方法持续整理出来。
