在自动化测试面试和实战里，AI+自动化测试已经不是一个新鲜名词。很多团队真正想解决的问题是：脚本维护成本高、元素定位容易失效、运营弹窗导致 CI 频繁失败、接口断言写不到位。面对这些问题，单纯靠录制回放或手写更多脚本，并不能提升稳定性；更需要一套能把测试用例生成、执行、失败分析、异常兜底串起来的工程方法。
这篇文章会从一个最小可运行项目出发，把 AI 辅助能力落在四个具体环节：用大模型生成 Web UI 测试用例、把用例解析成可执行的 pytest 参数化脚本、用 AI 辅助生成接口断言结构、处理自动化测试里最常见的非预期弹窗问题。
很多人看到“学完即可就业”这类标题，容易把它理解成看完就能拿到 Offer。实际应该理解成：把一个从环境到运行、从失败到排查的闭环彻底做完，并能在面试里讲清楚自己的判断和排错过程。下面直接进入正题。
1. 先理解 AI+自动化测试解决的是什么问题
1.1 传统自动化测试脚本为什么越跑越脆
刚开始学习 Web 自动化时，很多教程会教你先定位元素，再点击按钮，最后断言页面文本。单条用例跑起来没有问题，但放到真实项目里，脚本最常见的结局是：上线两周后开始大面积报错。
原因通常是这几类：
- 页面结构改版，CSS 类名或 XPath 失效，脚本找不到元素。
- 网络或资源加载慢，固定等待时间不够，点击时元素不可见。
- 运营弹窗、活动遮罩、系统通知临时出现，挡住了原本可以点击的按钮。
- 测试数据互相污染，上一个用例留下的登录态影响了下一个用例。
- 失败后只能靠人肉看日志定位，排错成本高。
接口自动化相对稳定，但它的问题在另一边：接口文档不完整、返回字段经常变化、断言写得太粗或太细。断言只判断status_code == 200，接口返回错误数据结构时测试仍然通过；断言把字段值写死，又会在正常数据变化时产生误报。
这些痛点不是 AI 单独能解决的，但 AI 可以显著降低“生成和维护测试资产”的成本，让测试工程师把精力放在更重要的稳定性分析上。
1.2 AI 可以在四个环节提供真实帮助
AI 在自动化测试里的落地方式，不是让模型替你把所有测试写完，而是在重复度较高的环节里减少人工投入。
| 环节 | 传统做法 | AI 辅助做法 | 落地难度 |
|---|---|---|---|
| 测试用例生成 | 手工写 Excel 或用例文档 | 设计 Prompt，让大模型输出结构化用例清单 | 低 |
| 元素定位 | 手写 CSS/XPath | 根据页面上下文生成或修复选择器 | 中 |
| 失败分析 | 看日志和截图 | 把日志与截图交给多模态模型分析 | 中 |
| 接口断言生成 | 手写断言逻辑 | 根据接口返回样例生成 JSON Schema 或断言代码 | 低 |
在 Web UI 自动化中，Playwright、Selenium 仍然是执行层工具；AI 主要负责生成用例初稿、辅助修复定位器、分析失败原因。在接口自动化中，AI 更适合做“结构分析”和“数据生成”。在移动端，Appium 依赖控件树，Airtest 依赖图像识别，AI 也能参与跨平台用例生成和异常界面识别，但核心仍然要有一份稳定的测试框架。
1.3 AI 辅助不等于 AI 全自动：职责边界必须先划清
大模型生成代码有一个很现实的问题：它可能一本正经地生成一个不存在的选择器，或者调用一个不存在的 API。测试脚本如果直接信任模型输出，相当于把质量判断权交给了概率模型。
推荐的工作流是：
- AI 生成初稿。
- 人审查关键逻辑、选择器、断言。
- 测试运行，得到真实结果。
- 失败后把日志和截图交给 AI 辅助分析。
- 修正后再次运行。
这条链路里，AI 负责提效，人负责控制质量。测试结果是否可信，最终由人负责。面试时如果能把这个边界讲清楚，比单纯说“我用 AI 自动写测试”更有价值。
2. 搭建一套可复制的 AI 辅助自动化测试环境
2.1 环境组件与版本选择
本文示例使用 Python 生态，因为 pytest、Playwright、requests 的组合在自动化测试领域最通用，资料也最多。
| 组件 | 作用 | 建议 |
|---|---|---|
| Python 3.10+ | 运行脚本与测试框架 | 建议安装 3.10 或更高版本 |
| pytest | 用例组织、执行、断言 | 通过 pip 安装 |
| Playwright | Web UI 自动化 | 支持 Chromium/Firefox/WebKit |
| requests | 接口测试请求 | 通过 pip 安装 |
| Flask | 本地 Mock 服务，只用于学习 | 通过 pip 安装 |
| jsonschema | 校验接口返回结构 | 通过 pip 安装 |
| 大模型 API 服务 | 生成用例、断言、失败分析 | 可选，需要 API Key |
原始材料没有给出明确版本，落地前先以官方网站的当前稳定版为准。版本冲突时，优先通过虚拟环境隔离依赖。
2.2 用最小命令完成安装
先创建项目目录和虚拟环境。虚拟环境能避免把依赖装到全局 Python 环境里，后续换项目时不会互相影响。
mkdir ai_test_project && cd ai_test_project python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate pip install -U pip pip install pytest playwright requests flask jsonschema playwright install chromium如果下载速度慢，可以使用国内镜像源：
pip install -i https://mirrors.aliyun.com/pypi/simple pytest playwright requests flask jsonschema安装完成后，运行下面的命令验证环境：
pytest --version python -c "import playwright; print(playwright.__version__)" python -m playwright --version确认没有报错后，再继续下面的项目。
2.3 大模型接口的通用接入方式
接入大模型最稳妥的方式，是封装成一个独立的客户端模块。这样测试代码不会关心你用的是哪家模型服务，将来替换模型服务时只改一个文件。
新建ai_helper/llm_client.py：
import os import requests def chat_with_llm(messages, temperature=0.2): api_key = os.getenv("LLM_API_KEY") api_base = os.getenv("LLM_API_BASE", "https://your-llm-service.example.com/v1") model = os.getenv("LLM_MODEL", "your-model-name") if not api_key: raise RuntimeError("没有找到 LLM_API_KEY 环境变量") payload = { "model": model, "messages": messages, "temperature": temperature, } resp = requests.post( f"{api_base}/chat/completions", headers={"Authorization": f"Bearer {api_key}"}, json=payload, timeout=30, ) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"]这里把 API Key 放到环境变量里，避免硬编码进测试仓库。temperature调低到 0.2，可以让模型输出更稳定。生成测试用例时，稳定输出比创造性更重要。
注意：自动化测试工程里，任何外部模型输出都要先做校验再进入执行链路，不要直接把返回字符串当成可用代码。
2.4 没有 API Key 时的替代学习方案
如果暂时没有可用的模型服务，可以先手工准备一份用例 JSON 文件，按后面章节的格式写入cases/cart_cases.json，让整个执行链路先跑通。等拿到 API Key 后，再把“手工写 JSON”替换成“调用chat_with_llm生成 JSON”。
另一种做法是在本地用 Ollama 等工具部署开源模型。这种方式需要额外显卡资源，通常只作为进阶方案，不建议零基础阶段把精力消耗在模型部署上。
3. Web UI 自动化实战：让 AI 先生成用例，再转成可执行脚本
3.1 项目目标和目录结构
这一章完成一个最小闭环：AI 生成购物车测试用例，脚本解析用例，并通过 Playwright 在本地页面执行。
为什么选择购物车场景？因为购物车包含加购、数量变化、删除商品、清空购物车等清晰业务规则，既容易复现，也方便验证多种断言方式。
项目结构如下：
ai_test_project/ ├── ai_helper/ │ ├── __init__.py │ ├── executor.py │
