这次我们来看一套 AI 自动化测试实战教程。它最大的特点是直接用 30 个项目实战带学习而不是先堆几个月的理论课。内容覆盖 Web UI 自动化、接口自动化、移动端测试同时把 AI 应用在自动化测试里生成测试用例、辅助元素定位、分析失败原因、自动维护脚本。视频教程里常见的“从零到能面试讲项目”的路径在这套内容里被拆成了一个个能实际操作的项目学完能到市面上的软件测试、测试开发岗位面试中聊清楚项目做到“有东西可讲、有代码可看、有理念可谈”。这里先说一个理性的预期没有任何教程能保证“学完即可就业”。能否拿到 Offer 取决于技术扎实程度、项目真实性、表达能力和市场环境。但这套教程的价值在于它帮你把“AI 自动化测试”这个方向的学习路径压缩了30 个项目覆盖的技术点基本对应初级测试开发岗位的实际工作内容。这篇文章会按“能力速览 - 技术栈拆解 - 环境准备 - 核心玩法 - 批量任务 - 资源占用 - 排错 - 最佳实践”的顺序把所有值得关注的技术点拆开讲。1. AI 自动化测试实战教程核心能力速览先给一张信息密度比较高的表把教程核心能力一次看明白。表中“内容方向”和“项目数量”来自公开标题“技术栈细节”是行业通用做法具体以小章节为准。能力项说明内容形式视频实战教程30 个项目实战项目方向Web UI 自动化、接口自动化、移动端自动化、AI 辅助测试用例生成、测试报告与分析核心语言Python 为主主要框架Selenium、Playwright、pytest、Requests、AppiumAI 技术点大模型生成测试用例、AI 元素定位、失败日志智能分析、AI Agent 自动执行测试流程操作系统Windows / macOS / Linux 均可硬件要求常规笔记本即可若涉及本地大模型推理建议 16G 内存或 NVIDIA 显卡显存 8G 以上更稳部署方式本地 Python 环境 项目源码运行是否支持接口 API是接口自动化测试是核心项目之一是否支持批量任务是pytest 批量执行、数据驱动、并发测试覆盖适合人群功能测试转自动化、初级测试开发、准备测试面试的在校生从这套内容的设计来看它不是单一工具的教学。Selenium 是老牌主流Playwright 是近几年效率较高的新选择Appium 覆盖移动端pytest 负责用例组织和批量执行Requests 负责接口层验证。AI 在这里不是单独一课而是渗透到用例生成、脚本维护、结果分析等环节。2. 适用人群与学习边界先说适合谁。第一类是功能测试工程师。已经掌握手工测试、用例设计想往自动化测试和测试开发方向转这套内容的实战密度合适。第二类是刚入行的初级测试开发能用 Python 写简单脚本但缺一套完整的项目经验30 个项目可以快速补齐“框架选型、断言设计、批量执行、失败处理”这些实操能力。第三类是准备面试的求职者需要的不是零散的知识点而是能讲清楚“我做过什么项目、用了什么技术、解决了什么问题”这套内容正好给了一条完整项目线。再说边界。这套教程虽然项目多但不适合完全没有编程基础的人。至少要先掌握 Python 的基本语法、函数、类和异常处理。否则在学习 Selenium 脚本时很容易卡在“不知道哪里报错”的层面上反而浪费时间。还要注意合规和安全边界。做自动化测试时只能对自己拥有授权、或明确标注可测试的系统进行操作。不要用自动化脚本去爬取未授权网站、不要对线上系统做未授权的压测、不要绕过登录限制。如果项目中涉及 AI 生成测试代码也要人工复核后再集成到测试工程里AI 代码出现逻辑错误的风险并不低。关于“学完即可就业”我的建议是把这里面的“就业”理解成“具备初级测试开发岗位的项目表达能力和实操能力”。面试时面试官更在意你是否能讲清楚一个项目的被测系统、框架设计、数据构造、失败处理和结果产出。只要能把这 30 个项目里最核心的 3 到 4 个项目拆明白面试阶段的“项目关”问题就不大。3. 学习路线30 个实战项目应该怎么拆30 个实战项目听起来很多但学习时不能平均用力。合理拆法是分成五个阶段每个阶段解决一类问题难度逐步叠加。第一阶段是 Web UI 自动化基础。大约 6 个项目包括登录页面自动化、表单填写提交、列表分页测试、搜索过滤测试、购物车流程、后台管理系统关键链路遍历。这一阶段主要掌握 Selenium 或 Playwright 的基本操作、元素定位、等待策略和断言。第二阶段是接口自动化测试。大约 6 个项目包括接口请求封装、JSON 断言、鉴权 token 处理、数据驱动测试、接口依赖处理、接口测试报告输出。这一阶段用的主要是 Requests、pytest 和 Allure 报告目标是把接口层跑通并能批量执行。第三阶段是 AI 辅助自动化测试。大约 7 个项目这是整套教程和传统自动化测试教程最大的差异点。典型项目包括用大模型根据需求自动生成测试用例、用大模型分析页面截图推荐元素定位、用大模型解析失败日志并给出修复建议、AI Agent 根据自然语言指令自动点击页面完成冒烟测试。这类项目的核心不是“调用一下大模型接口”而是把大模型输出转成可执行的测试步骤并加入校验和兜底。第四阶段是移动端自动化测试。大约 5 个项目包括 Appium 环境搭建、Android 端登录流程测试、iOS 真机测试基础、App 崩溃日志抓取、移动端兼容性批量用例。这个阶段对设备要求高一些但也更贴近真实企业项目。第五阶段是测试数据与报告体系。大约 6 个项目包括测试数据准备、数据库断言、测试结果统一收集、Allure 报告定制、CI 中集成自动化测试、定时批量回归。这个阶段解决的是“自动化脚本能稳定运行并被团队使用”的问题。建议学习顺序就是按阶段走。前面没跑通不要急着碰 AI 项目。AI 项目看起来“酷”但底层还是 Web 自动化基本功元素都定位不住AI 再强也没法稳定驱动浏览器。4. 本地开发环境准备学习这套项目实战内容环境准备不需要特殊硬件。一台普通笔记本即可。建议配置操作系统Windows 10/11 或 macOS。Python3.10 或 3.11建议使用 Anaconda 或 miniconda 管理环境。IDEPyCharm 社区版或 VS Code。浏览器Chrome 或 Edge。移动端Android Studio 自带模拟器或有真机用于 Appium 测试。磁盘至少预留 20GB 空间用于依赖、浏览器驱动、测试报告和截图文件。推荐为每个项目单独创建虚拟环境避免包版本互相污染。# 创建 Python 虚拟环境 python -m venv venv # 激活虚拟环境Windows venv\Scripts\activate # 激活虚拟环境macOS/Linux source venv/bin/activate基础依赖建议用 requirements.txt 管理不同项目单独维护。一个通用模板如下selenium4.21.0 playwright1.44.0 pytest8.2.1 requests2.32.3 appium-python-client3.2.1 webdriver-manager4.0.1 allure-pytest2.13.5 pytest-xdist3.6.1安装命令pip install -r requirements.txt如果需要使用 AI 能力比如调用大模型 API 或接入本地大模型需要额外安装 OpenAI SDK 或对应的模型服务 SDK。项目里通常还会用到 python-dotenv 管理密钥避免把 API Key 写死在代码里。pip install openai python-dotenv requests环境准备阶段最容易踩的坑有三个。第一个是 Python 版本过高或过低导致依赖安装失败直接换成 3.10/3.11 最省事。第二个是浏览器驱动与浏览器版本不匹配这个用 webdriver-manager 可以自动化解决。第三个是 Playwright 需要单独下载浏览器内核运行playwright install才能用。命令行执行playwright install这部分不复杂但必须耐心。环境不通后面每个项目都会卡在启动阶段很容易误判成代码问题。5. Selenium 和 Playwright 怎么选实战对比在 AI 自动化测试项目中框架选型直接决定后续代码风格和工作量。Selenium 的优势是生态成熟、团队使用多、资料多、招聘岗位里出现频率高。Playwright 的优势是自动等待机制更好、支持多浏览器一致行为、录制脚本方便、自带 trace 回放近年热度很高。从实战教程角度来看建议两个都要学但上手先用 Playwright 跑通核心流程再回到 Selenium 补齐主流技能。Playwright 的一个典型登录测试脚本如下from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.goto(http://127.0.0.1:8000/login) page.fill(#username, test_user) page.fill(#password, test_pass) page.click(button[typesubmit]) page.wait_for_selector(.user-info) print(登录成功页面标题, page.title()) browser.close()Selenium 的相同功能脚本from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.chrome.service import Service from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from webdriver_manager.chrome import ChromeDriverManager driver webdriver.Chrome(serviceService(ChromeDriverManager().install())) wait WebDriverWait(driver, 10) driver.get(http://127.0.0.1:8000/login) driver.find_element(By.ID, username).send_keys(test_user) driver.find_element(By.ID, password).send_keys(test_pass) driver.find_element(By.CSS_SELECTOR, button[typesubmit]).click() wait.until(EC.visibility_of_element_located((By.CSS_SELECTOR, .user-info))) print(登录成功页面标题, driver.title) driver.quit()两者对比Playwright 在等待机制上更省心页面元素不出现时会自动等待Selenium 需要自己写显式等待。AI 自动化测试项目里我建议以 Playwright 作为执行引擎因为自动等待和 trace 回放能力能大幅降低脚本维护成本。但在面试和职场中Selenium 仍然是必须掌握的基础技能很多存量项目都是用 Selenium 写的。6. AI 在自动化测试里的几种落地方式这是整套实战教程的重点。AI 在自动化测试里不是“用人工智能替代测试”而是把测试工程师从重复劳动里解放出来。具体来看有四种落地方式。6.1 AI 生成测试用例把需求描述或页面功能描述发给大模型让它输出完整的测试点。这种方式可以快速覆盖边界条件。示意代码如下import os from openai import OpenAI client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) def generate_test_cases(requirement_text: str): prompt f 根据下面的需求描述生成完整的测试用例覆盖正常流程、异常流程、边界值 {requirement_text} 输出格式为用例编号、用例名称、前置条件、操作步骤、预期结果。 resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.2 ) return resp.choices[0].message.content这里强调一点AI 生成的用例只能作为初稿必须人工评审后使用。特别是涉及业务规则和权限控制的用例AI 很难完全理解。6.2 AI 元素定位传统 Selenium 定位靠 id、name、xpath、css selector。当元素定位不到时可以给大模型提供页面源码或截图让它推荐更稳定的定位策略。这种方式在实际项目中成功率不低尤其是复杂页面。实际工程里不会写一个“AI 定位一切”的脚本更合理的做法是优先使用内置定位策略。定位失败时进入 AI 辅助定位流程截图并提取 DOM 关键信息发给模型。模型返回推荐表达式脚本自动尝试成功则记录到本地。6.3 AI 失败日志分析自动化测试最耗时的环节是失败排查。一个用例失败后要判断是代码问题、数据问题还是业务真实缺陷。大模型可以把堆栈信息、截图、页面 DOM 拼到一起输出可能的失败原因和修复建议。这个能力可以有效降低熬夜排查脚本的时间。6.4 AI Agent 自动执行测试流程更进阶的方向是用大模型 Agent 驱动浏览器。用户输入“打开登录页输入正确账号密码验证登录成功”Agent 将任务拆成步骤调用 Playwright 执行并根据页面反馈调整下一步。示意代码如下from playwright.sync_api import sync_playwright def run_agent_test(task_desc: str): # 将 task_desc 发送给 Agent 模型Agent 返回结构化操作步骤 # 典型步骤[{action: goto, url: http://127.0.0.1:8000/login}, ...] steps agent_plan(task_desc) with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() for step in steps: if step[action] goto: page.goto(step[url]) elif step[action] fill: page.fill(step[selector], step[value]) elif step[action] click: page.click(step[selector]) elif step[action] assert: page.wait_for_selector(step[selector]) browser.close()这种项目在真实场景中适合冒烟测试和探索性测试不建议直接替代全部回归测试。Agent 理解偏差可能导致误操作所以执行环境必须是测试环境不能直接对生产环境做自动操作。7. 接口自动化测试与批量任务接口自动化测试是 30 个项目中工作量最大的一部分也是与面试中“接口自动化测试”要求最贴近的项目。核心不是用 Requests 调一个接口而是要把接口用例组织成可持续维护的测试套件并支持批量执行。典型的接口测试项目结构如下api_test_project/ ├── config/ │ └── settings.py ├── common/ │ └── request_util.py ├── test_cases/ │ ├── test_login.py │ └── test_order.py ├── test_data/ │ └── login_test_data.json ├── reports/ └── conftest.py先封装一个通用的请求方法import requests class RequestUtil: def __init__(self): self.session requests.Session() self.base_url http://127.0.0.1:8000 self.token None def post(self, path, jsonNone, headersNone): if self.token: headers headers or {} headers[Authorization] fBearer {self.token} return self.session.post(f{self.base_url}{path}, jsonjson, headersheaders, timeout10) def set_token(self, token): self.token token再写登录接口和业务接口用例import pytest from common.request_util import RequestUtil request RequestUtil() def test_login_success(): resp request.post(/api/login, json{username: admin, password: 123456}) assert resp.status_code 200 assert resp.json().get(token) is not None request.set_token(resp.json().get(token)) def test_get_order_list_need_auth(): resp request.post(/api/order/list, json{page: 1, size: 20}) assert resp.status_code 200 assert items in resp.json()批量执行使用 pytest 命令行即可pytest test_cases/ -v --tbshort --maxfail5如果要生成 HTML 报告建议用 Allurepytest test_cases/ --alluredir./reports/allure-results allure serve ./reports/allure-results如果有大量用例可以用 pytest-xdist 做进程级并行pytest test_cases/ -n 4 --dist loadscope这里要注意并行执行时测试数据必须隔离避免多个用例同时操作同一份数据导致断言失败。批量任务的关键设计是“数据可重置、失败可重试、结果可追踪”。8. 移动端自动化测试Appium 基础路径Appium 在移动端自动化测试中仍然是主流。AI 自动化测试项目中移动端的重点不是复杂手势而是把 Web 端已经验证过的登录、数据流、核心业务链路搬到 App 上。Appium 环境准备比 Web 自动化麻烦通常需要Node.js 环境。Appium Server。Android SDK。模拟器或真机。appium-python-client 库。启动 Appium Server 后Python 侧脚本如下from appium import webdriver caps { platformName: Android, platformVersion: 13, deviceName: emulator-5554, appPackage: com.example.app, appActivity: .MainActivity, automationName: UiAutomator2, noReset: True } driver webdriver.Remote(http://127.0.0.1:4723/wd/hub, caps) driver.implicitly_wait(10) driver.find_element(id, username).send_keys(test_user) driver.find_element(id, password).send_keys(test_pass) driver.find_element(xpath, //android.widget.Button[text登录]).click() driver.quit()实际项目里移动端自动化最大的坑是环境碎片化。不同 Android 版本、不同机型、不同分辨率都会导致元素定位差异。建议优先做核心链路比如注册、登录、下单、支付不要一开始追求全部页面覆盖。还能结合云真机平台或本地设备池做批量测试但这部分往往需要企业级资源个人学习阶段用一个模拟器和一个真机就足够。9. 资源占用与运行效果观察自动化测试虽然是写代码但运行时的资源占用同样值得关注。执行 Web 自动化脚本时每启动一个浏览器实例内存占用就会明显上升。如果用例没有做好隔离一个 pytest 进程里连续打开多个浏览器窗口内存可能直接打满导致测试中断。这里给一个资源观察思路CPU浏览器渲染、Python 脚本执行、AI 模型推理三个环节都可能占 CPU。内存每个浏览器实例约占用 300MB 到 800MB 内存具体取决于页面复杂度。磁盘截图、日志、trace 文件、Allure 报告都会占磁盘空间长期批量执行后要及时清理。网络接口测试中大量请求会导致被测服务负载升高要控制并发数。如果是本地跑大模型做失败日志分析或者 AI 元素定位需要额外关注显存。本地部署 7B 到 14B 参数模型时建议 8GB 以上显存如果内存 32GB 以下更稳妥的方式是直接调用云端大模型 API把本地资源留给批量测试执行。运行过程中可以随时用nvidia-smi查看显存占用nvidia-smi降低资源占用的通用方法headless 模式运行浏览器不弹界面。控制 pytest 并行数不要一味追求 -n 8。测试数据用独立环境减少接口响应等待。对截图文件按日期归档定期清理。AI 模型请求加缓存相同页面不重复推理。10. 常见问题与排查方法AI 自动化测试项目推进过程中很多问题不是代码语法问题而是环境、数据、调试方式的问题。下面整理了一张排查表。问题现象可能原因排查方式解决方案pip install 安装包失败网络源不稳定或 Python 版本不兼容查看完整错误日志使用国内镜像源加速或更换 Python 3.10/3.11浏览器无法启动浏览器驱动和浏览器版本不匹配chrome://version查看版本使用 webdriver-manager 自动加载匹配驱动Playwright 运行报浏览器缺失未下载浏览器内核执行playwright install根据终端提示下载对应内核页面元素定位失败页面异步渲染元素未加载打印当前页面源码和截图使用显式等待或改用更稳定的 text/label 定位运行时弹出非预期弹窗导致测试失败被测页面有广告弹窗、浏览器通知、自定义弹窗录制弹窗出现时的页面状态在用例前置步骤中增加弹窗兜底关闭逻辑接口请求超时被测服务响应慢或网络问题查看请求耗时和接口日志添加 timeout 和重试机制区分“服务故障”和“网络抖动”用例并行执行相互影响多个用例共用同一测试账号或数据检查执行顺序和数据变更每个用例使用独立测试数据执行后清理AI 生成的测试用例质量不稳定模型 temperature 设置过高或提示词不完整检查 prompt 和被测试业务描述降低 temperature增加业务规则描述人工复核AI 分析失败原因不准确给模型的信息太少拼接完整截图、堆栈、日志把截图和日志一起作为上下文输入测试数据脏掉反复失败上一次执行残留数据没有清理检查数据库或接口返回在 conftest 中加自动造数和清理逻辑对于“非预期弹窗”问题再补充一个通用处理思路。在用例执行前统一注册弹窗处理逻辑比如自动点击关闭按钮或按 Esc。Playwright 中可以直接监听 dialog 和 popup 事件Selenium 中通过 Alert 接口和 JS 处理。但要小心弹窗兜底逻辑可能误点关键操作建议只对明确识别为广告或通知类弹窗做自动处理。11. 最佳实践与就业面试建议把这套教程的 30 个项目跑完之后真正拉开差距的不是代码量而是工程化程度。下面这几点值得作为长期习惯。第一目录结构要清晰。每个实战项目都应该有 config、common、test_cases、test_data、reports 五个基础目录从第一天就按标准结构维护。不要所有脚本都堆在根目录。常见的最小工程结构auto_test_project/ ├── config/ │ └── settings.py ├── common/ │ ├── request_util.py │ └── browser_util.py ├── test_cases/ │ ├── test_login.py │ └── test_order.py ├── test_data/ │ ├── login_data.json │ └── order_data.json ├── reports/ └── conftest.py第二测试用例要可重复执行。每条用例执行前必须保证测试数据可用执行后要清理或重置数据。自动化测试最忌讳“第一次能过第二次就挂”这种项目讲给面试官听反而是减分项。第三AI 辅助代码必须带人工审查环节。让 AI 生成元素定位、测试用例、日志分析建议都没问题但最终提交到测试工程里的代码必须经过 review。特别是 AI 生成的断言逻辑经常会“看起来对但没真正校验”这比不写断言更危险。第四面试讲项目的逻辑要清晰。面试官问“聊聊你的自动化测试项目”时不要只背代码。按这五个点讲被测系统是什么业务链路是什么。框架选型和技术栈是什么。怎么构造测试数据怎么处理依赖接口。用例失败时怎么定位问题怎么处理弹窗、数据污染等问题。最终测试结果如何统计、如何展示是否跑在 CI 流水线里。遇到 AI 自动化测试的问题可以重点讲 AI 在生成测试用例、智能定位、失败分析方面的实际应用效果以及你对 AI 输出可靠性的把控方案。面试官更关心你懂不懂边界而不是你调过多少次 API。12. 总结与下一步这套 AI 自动化测试实战教程最值得尝试的点是它把“自动化测试”和“AI 应用”揉进了 30 个项目里让学习者不只是在代码层面练手而是在项目层面理解测试工程。比起收藏几十个零散知识点跟着实战项目走一遍收获会更扎实。开始学习前先按顺序做三件事装好 Python 环境、跑通一个最简单的 Playwright 登录脚本、用 pytest 管理一条完整用例。先把这三个点打通后续的接口测试、移动端测试、AI Agent 测试才有支撑。最容易踩的坑是环境问题浏览器驱动不匹配、Python 版本不对、依赖安装失败。遇到这些问题不要急着怀疑代码先看日志和环境。后续可以继续扩展的方向有三个第一把 AI 失败日志分析接入现有测试框架做一个自动化回归报告第二用智能体 Agent 做探索性测试让 AI 自动发现页面异常第三把测试工程接入 CI定时批量执行并生成报告。能把这三件事做完AI 自动化测试就不再是一个学习目录而是一套能用的工程能力。