在自动化测试面试和实战里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 安装PlaywrightWeb UI 自动化支持 Chromium/Firefox/WebKitrequests接口测试请求通过 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.pyimport os import requests def chat_with_llm(messages, temperature0.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: fBearer {api_key}}, jsonpayload, timeout30, ) 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 │
