AI自动化测试这两年热度很高但很多零基础同学一上来就搜教程、找框架、装环境结果卡在“工具太多不知道从哪条线开始”。我先给一个比较直接的判断AI不会让你跳过测试基础但会大幅降低写用例、维护脚本、排查失败的门槛。如果你正准备入门自动化测试或者正在做手工测试想转自动化别指望只靠某个“一键生成用例”的工具就能学会。更稳妥的路是先掌握 Python 基础再跑通一个 UI 自动化用例然后让 AI 帮你写用例、定位元素和分析失败接着补接口自动化最后用一到两个实战项目把整条链路串起来。这篇内容不是速成班但会把每一步怎么开始、环境怎么准备、失败怎么看、参数怎么调讲清楚少走弯路。1. 先把学习路径理清楚再决定要不要上 AI很多零基础的同学学自动化测试第一步不是搭环境而是被五花八门的名词吓住Selenium、Playwright、Appium、Airtest、pytest、接口自动化、测试平台、AI Agent。这些工具确实都会出现在日常工作中但你不需要一口气全部学完。1.1 零基础最常见的误区工具优先逻辑靠后我见过不少新人的学习方式是这样的今天看到有人推荐 Selenium装了一下午环境明天看到 Playwright 很火又去装 Node 和浏览器后天看到 AI 能自动生成测试脚本觉得前面的都白学了。这个思路不是完全错但效率很低。工具只是自动化测试的“手”更关键的是测试逻辑怎么设计用例、怎么判断页面是否加载成功、怎么处理不稳定元素、怎么断言结果、怎么在失败时保留现场。这些问题没有想清楚换任何框架都会卡住。AI 确实能帮你写出一段看起来很完整的脚本但只要你不理解脚本里的等待逻辑、元素定位和断言一旦报错你连怎么向 AI 描述问题都说不清楚。这也是很多教程看完就忘的原因。1.2 自动化测试的四个方向先分清再学自动化测试并不是只有“打开网页点按钮”这一种形式。下面四个方向日常工作中最常见也最值得零基础按顺序了解。技术方向核心场景主要掌握内容AI 能帮什么UI 自动化Web 页面、桌面端、移动端界面操作元素定位、等待、断言、页面对象模型生成用例、定位策略、分析失败截图接口自动化后端接口回归、数据校验、业务链路请求构造、断言、数据管理、环境切换生成测试数据、生成接口用例、整理报告测试框架与平台用例管理、执行调度、报告输出pytest、unittest、CI 集成、结果统计生成测试报告摘要、失败自动归类测试辅助工具测试数据准备、Mock、日志采集、环境检查数据库操作、文件处理、Shell 命令生成模拟数据、解释报错日志如果按投入产出比排序我建议零基础先把前两个方向做扎实先学会写最小的 UI 自动化脚本再补接口自动化。这两个方向能直接解决“重复回归”和“接口变更后不知道哪里挂了”的实际问题也最容易积累信心。2. 零基础第一站用 Python 跑通第一个 UI 自动化用例这一节不追求复杂框架只做一件小事用 Python 写一个自动化脚本打开一个网页输入内容点击按钮最后断言页面变化。能把这个闭环跑通你已经比“下载了工具但没跑起来”的人前进了一大步。2.1 环境准备Python、虚拟环境、浏览器驱动先确认本机已经安装 Python建议使用 3.10 或更高的版本。版本太低部分依赖可能不支持报错会特别多。然后创建一个虚拟环境把依赖隔离在项目目录里避免污染全局环境。在命令行里执行python -m venv testenv # Windows 激活 testenv\Scripts\activate # macOS / Linux 激活 source testenv/bin/activate pip install selenium playwright pytest requestsselenium和playwright是 UI 自动化库pytest是测试框架requests是接口自动化会用到的 HTTP 客户端。这条命令一次装好后面不用反复折腾。如果用 Selenium还需要根据浏览器版本下载对应的驱动。不同驱动版本和浏览器版本不对应启动时就会报错。Playwright 不用单独下载驱动直接执行playwright install chromium这一点对新手更友好。注意如果依赖下载速度很慢可以切换为国内镜像源但不要同时混用多个镜像容易出现依赖不完整的问题。2.2 Selenium 最小用例打开页面、输入、点击、断言Selenium 是生态最成熟的 Web UI 自动化工具很多公司的老项目都在用它。下面这段脚本是一个最小闭环from selenium import webdriver from selenium.webdriver.common.by import By driver webdriver.Chrome() driver.get(https://example.com) # 换成你自己的测试地址 driver.find_element(By.ID, username).send_keys(test_user) driver.find_element(By.ID, password).send_keys(123456) driver.find_element(By.CSS_SELECTOR, button.login-btn).click() assert Dashboard in driver.title driver.quit()这段代码很直观find_element负责找页面元素send_keys负责输入click负责点击断言检查页面标题是否发生变化。但要注意这只是最小示例。实际项目里页面加载有快有慢点击按钮后可能需要等待接口返回这时直接断言很容易失败。所以更稳妥的做法是用显式等待。2.3 Playwright 为什么对新手更友好Playwright 是近几年使用率明显上升的自动化方案它的特点是自动等待元素出现不需要你到处写sleep。下面这段脚本和上面的 Selenium 完成同样的事情from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) # headlessTrue 时不开浏览器窗口 page browser.new_page() page.goto(https://example.com) page.locator(#username).fill(test_user) page.locator(#password).fill(123456) page.get_by_role(button, name登录).click() page.wait_for_selector(.dashboard) assert page.title() Dashboard browser.close()Playwright 的三个特点对新手很实用locator的定位语法更接近 CSS 和文本语义比 Selenium 的定位写法更容易读。get_by_role能按按钮名称定位不用死记冗长的 class。wait_for_selector会等到元素出现减少因为加载慢导致的失败。判断一步是否真正跑通我不看“能打开浏览器”而是看同一个脚本能不能连续跑 3 次以上。如果每次都出现等待超时就要调整定位方式或等待条件而不是加大sleep。3. AI 在自动化测试里能帮什么不是替你造火箭是替你干脏活很多人对 AI 自动化的期待是给一个人工智能它自己就懂业务、自动写用例、自动修 bug。现阶段距离这个理想状态还有距离但在测试场景里AI 已经能在四个环节上明显提速。3.1 AI 生成用例和代码从空白开始最快但必须做代码审查AI 最擅长的是把一段明确需求转换成代码。比如你已经有登录页面的元素信息可以直接让 AI 生成 pytest Selenium 用例。重点是你要把上下文给全。下面是一个可用的提示词思路我有一个登录页面 - 用户名输入框 id 是 username - 密码输入框 id 是 password - 登录按钮 class 是 login-btn - 登录成功后会跳转到 dashboard 页面 请帮我生成 pytest Selenium 的用例包含登录成功、密码错误两种情况失败时保存截图。AI 生成的脚本大概率能运行但你不应该直接贴进项目里。原因有三点元素定位可能因为页面结构变化而失效。错误分支可能覆盖不全。断言可能只检查了“没报错”没有检查真正的业务结果。所以我的习惯是AI 生成代码 → 人工审查定位和断言 → 跑一遍最小用例 → 再补充边界场景。AI 在这里是提高效率的助手不是质量背书。3.2 AI 定位元素处理动态 ID、弹窗、iframe、阴影 DOMUI 自动化失败最多的问题就是元素定位。常见场景包括页面加载后元素才出现、点击后弹窗遮挡、元素 ID 每次都变、内容在 iframe 或 shadow DOM 里。这些问题在 Selenium 里处理起来很繁琐。这时候可以把页面的 HTML 片段复制给 AI让它分析给出一组候选定位器。AI 能识别出哪个 ID 是动态的哪个 class 更适合用文本定位是否稳定是不是需要切换 iframe。但注意不要把带有用户真实信息的 HTML 贴到不安全的工具里。学习阶段可以用自己构建的测试页面生产环境要遵循公司数据安全规范。3.3 AI 分析失败非预期弹窗和日志的最快排查方式“自动化测试非预期弹窗导致失败”是最常见的问题之一。脚本跑着跑着突然一个弹窗挡住按钮找不到元素然后报错。很多人第一反应是加异常处理把所有异常吞掉。这是一个非常危险的思路。吞掉异常后脚本可能继续执行最后产生一个假成功的结果。正确的做法是先把失败现场保留下来包括页面截图、页面 HTML、浏览器日志、具体报错信息。然后把这一堆信息交给 AI让它判断“是否存在非预期弹窗弹窗由什么触发是否可以安全关闭”。给 AI 的上下文越完整判断越准确。只发一句“脚本报错元素找不到”AI 也无法知道是弹窗问题还是定位问题。3.4 AI Agent 辅助测试执行边界要提前定好使用 AI Agent 自动执行测试比如让它读取需求、生成代码、跑脚本、分析结果在简单 Web 场景里已经能跑通。现在也出现了很多 AI 编码代理可以辅助生成自动化测试脚本。这个方向值得学但不要抱有不切实际的期待。AI Agent 最大的问题是“看似正确实际无效”。它可能生成一段测试用例断言写了但断言对象根本不是关键业务指标它可能按默认方式等待跑一次通过跑三次就开始飘。所以用 AI Agent 执行测试的时候至少要有三层护栏环境要独立不能让它连接生产数据库。测试数据要可控最好每次使用独立账号。断言标准要人工确认不能只看“用例通过”。4. 接口自动化测试零基础提升最快的第二站很多新手觉得 UI 自动化才是自动化测试的正统接口自动化要往后放。这个想法在实际项目里是反的。接口自动化的稳定性、执行速度、投入产出比通常都比 UI 自动化高得多。4.1 为什么要先补接口自动化接口自动化测试的是后端 API不依赖页面加载、弹窗、元素定位所以失败因素更少。它适合做三类事情数据校验接口返回值是否正确、字段类型是否符合契约。链路回归登录、下单、支付、查询等接口连起来跑一遍。异常场景缺少参数、参数错误、未授权、超时等情况是否返回合理错误。对零基础来说接口自动化还能锻炼一个很重要能力把业务流程拆成数据流。你不需要看到页面也能知道当前业务走到哪一步、失败在哪一层这种能力对以后写复杂 UI 自动化非常有帮助。4.2 用 pytest requests 搭最小接口测试框架先安装依赖pip install requests pytest然后写一个最简单的接口测试文件import requests import pytest BASE_URL http://127.0.0.1:8000 def test_login_success(): resp requests.post( f{BASE_URL}/api/login, json{username: admin, password: 123456}, timeout10 ) assert resp.status_code 200 data resp.json() assert data[code] 0 assert data[data][token]这个用例做三件事请求登录接口、断言 HTTP 状态码、断言业务逻辑字段。注意status_code只表示请求通了不代表登录一定成功。真正的结果要看业务层字段比如code 0和 token 是否存在。在实际项目里接口测试框架会演进成更清晰的结构api_test/ ├── config.py # 环境地址、账号配置 ├── utils.py # 请求封装、日志封装 ├── test_cases/ │ ├── test_login.py │ └── test_order.py └── reports/ └── result.html4.3 接口自动化里的核心参数和判断标准接口自动化看起来只是“发请求 断言”但真正落地时要关注这几个参数和判断点参数或配置建议方式原因请求超时设置timeout10或更大不设置可能一直挂起浪费执行时间BASE_URL通过环境变量切换开发、测试、预发环境地址不同测试数据每个用例独立数据跑完清理避免数据互相干扰失败重试只在明确网络抖动时重试业务断言失败重试没有意义反而掩盖问题报告输出pytest 生成 HTML 报告方便定位失败用例和失败原因一个接口用例是否合格我一般会问三个问题它是否测试了真正的业务逻辑失败时报告能不能说清是哪一步换一套环境数据能不能直接跑如果三个答案都是“能”这个用例才算过关。5. 移动端和平台化Appium、Airtest、自动化测试平台怎么选学完 Web UI 自动化和接口自动化之后很多同学会进入下一个迷茫期要不要学 Appium要不要做测试平台移动端测试和 Web 测试哪个更吃香5.1 先分清移动端测试场景再选工具移动端自动化不是只有一个 Appium。不同场景适合不同工具场景推荐工具原因原生 App 功能回归Appium支持 Android、iOS生态成熟小程序 / H5 页面Appium / Playwright部分 H5 可以复用 Web 定位思路游戏 / 图像识别Airtest、SikuliX基于图像识别不依赖元素属性真机兼容测试云测平台 Appium多机型批量执行成本更高先判断你所在公司或项目最需要哪种再决定要不要深入学不要上来就把 Appium 装一遍装完发现手机连不上环境调试就劝退一大半人。5.2 Appium 为什么不适合新手第一站Appium 的学习成本明显高于 Selenium / Playwright。它需要安装 Android SDK、配置系统环境变量、准备模拟器或真机、安装 Appium Server还要处理设备连接、应用启动参数、权限弹窗等问题。任何一个环节配置不对用例连设备都起不来。我的建议是至少先跑通 Web UI 自动化和接口自动化再回来学 Appium。原因是 Appium 里的元素定位、等待、断言思路和 Selenium 高度相似只是多了设备层的问题。有 Web 基础之后再学环境问题能减少很多。5.3 Airtest图像识别带来便利但也有边界Airtest 对游戏和原生 App 比较友好因为很多界面元素没有办法用标准控件属性定位只能靠截图匹配。但图像识别有一个明显问题分辨率不同、字体渲染不同识别结果可能不稳定。所以用 Airtest 时最好把脚本和测试设备的分辨率版本固定在文档里。脚本写完后要在同一型号设备上跑多次验证稳定性不要只在开发机上跑一次就当作完成。5.4 自动化测试平台要不要学很多公司会自研或采购自动化测试平台实现用例管理、调度执行、报告查看、失败通知、测试环境申请等功能。对零基础来说自己搭一个完整平台不是优先项但可以理解平台的核心能力用例不再放在个人电脑而是集中管理。定时触发和 CI 集成让回归测试自动跑。报告统一展示失败用例一眼可见。失败重试和通知能减少无效人工盯守。如果你未来目标是测试开发可以从“本地接口自动化框架”入手再逐步把用例管理、报告输出、任务调度这几层加上去这就是一个迷你测试平台的雏形。6. 脚本不稳定怎么办非预期弹窗、等待、环境问题的排查顺序自动化测试入门容易稳定难。很多脚本第一次跑能过第二次跑就挂换台机器挂数据一变挂。这一章专门讲排查思路以后再遇到“脚本不知道为什么失败”先按这个顺序找。6.1 不要一遇到弹窗就加 try-except处理非预期弹窗最怕的就是为了“让用例通过”而用异常处理把所有弹窗吞掉。这样做的后果是元素没找到、弹窗没有处理、断言继续执行最后用例可能通过但实际业务已经卡在弹窗后面。更合理的处理方式记录页面截图和 HTML便于定位弹窗来源。判断弹窗是业务提示还是系统异常弹窗。如果是业务提示应该设计正常关闭路径。如果是系统异常应该让用例失败并保留现场。AI 在这里很适合做失败分析。把脚本步骤、页面 HTML、浏览器日志、报错信息一起发给 AI会比你自己在代码里不停猜快很多。6.2 等待策略固定 sleep 是新手最容易犯的错很多人习惯在脚本里写time.sleep(3)靠固定时间等页面加载。这种写法偶尔能跑通但非常脆弱。网络快时白白等 3 秒网络慢时 3 秒又不够最终就会随机失败。更稳定的替代方案Selenium 用WebDriverWait和expected_conditions。Playwright 自带自动等待配合wait_for_selector。接口自动化用轮询等待比如等待异步任务完成。尽量避免无脑sleep如果必须等也要写清等待条件。判断等待策略是否正确看一个标准脚本在慢环境和快环境下都能通过且不会无故多等很多秒。6.3 优先排查顺序我把自动化测试失败的排查顺序固定成五步看现象是启动失败、元素找不到、断言失败还是任务卡住。看输入URL 是否正确、测试账号是否有权限、测试数据是否存在。看环境依赖版本、浏览器驱动、设备连接、系统环境变量是否一致。看参数超时、并发、等待条件、日志级别。看工具本身当前版本是否支持你用的浏览器或 App 版本。这套顺序对 Web UI、接口、移动端都通用。很多问题不是脚本逻辑错了而是前置环境和输入数据没有准备好。6.4 让 AI 帮你排查时需要给足上下文直接把一行报错发给 AI得到的建议往往很泛。效果更好的做法是把以下信息一起给出来- 测试场景登录后跳转 dashboard - 操作步骤第 3 步点击登录按钮 - 期望结果跳转到 dashboard - 实际结果点击按钮后出现非预期弹窗元素找不到 - 页面 HTML粘贴关键片段 - 报错信息粘贴完整 traceback上下文越完整AI 的分析越接近真实原因。这个习惯对人工排查同样适用。7. 从入门到实战按三个项目逐步升级只学命令不练项目很快就会忘。这里给出三个递进项目每个项目都有明确验收标准适合作为零基础到初级测试开发之间的练习路径。7.1 项目一登录流程自动化第一个项目不贪大只做登录流程。你可以用自己的测试站点也可以搭一个本地简单页面。要求是覆盖登录成功、密码错误、用户不存在三种场景。使用显式等待不使用固定 sleep。失败时自动截图并保存到 reports 目录。用 pytest 管理用例能一键执行全部用例并输出报告。验收标准连续运行 10 次没有因为等待问题造成的偶发失败任意失败用例都能通过截图和日志快速定位。做完这个项目你已经掌握了 UI 自动化最核心的几个能力选择器、等待、断言、报告。7.2 项目二接口回归 UI 冒烟混合第二个项目开始贴近真实工作。模拟一个最简单电商流程接口创建商品UI 页面上验证商品是否展示接口下单UI 页面验证订单状态。这样设计的原因是让你理解接口和 UI 如何配合接口负责快速准备数据和验证业务链路。UI 负责验证关键页面展示是否正常。测试数据要独立跑完清理不能污染下次执行。验收标准使用一套命令完成“接口准备数据 → UI 验证 → 数据清理”的全流程重复执行三次不出现数据残留。7.3 项目三AI 辅助用例生成 小型测试平台第三个项目开始引入 AI 和平台化思路。你可以选择一个小模块比如用户注册或订单查询让 AI 生成测试用例和测试数据再由你补充边界场景然后把 pytest 报告输出为 HTML再接入一个简单的定时执行任务。这里不需要真的开发一个很复杂的平台。更实际的做法是用pytest管理用例。用 HTML 报告展示结果。用一个脚本实现定时执行和失败通知。把测试数据用 JSON 或 YAML 文件管理方便替换。验收标准新增一条测试数据后不需要改代码只需修改数据文件就能生成新用例失败时有报告可以直接看出是哪个环节出错。7.4 给零基础的学习节奏建议如果你的目标是朝测试开发方向走建议按这个节奏来第一阶段Python 基础 第一个 UI 自动化项目每天 2 小时大约 2 到 3 周。第二阶段接口自动化 接口与 UI 混合项目大约 3 到 4 周。第三阶段AI 辅助测试 小型平台化项目大约 4 到 6 周。具体时间因人而异重点不是赶进度而是每一步都要有“连续跑多次不飘”的稳定结果。最后留一个个人观点AI 自动化测试真正落地时最该盯住的不是工具多先进而是输入格式、资源占用、失败重试和日志记录。先把最简单的脚本跑稳再用 AI 提升效率这条路比直接追求 AI Agent 自动完成所有事情要可靠得多。踩过几次坑之后会发现很多问题不是 AI 能力不够而是前置环境、测试数据和断言标准没有准备干净。 零基础学AI自动化测试：从Python到实战的完整路径
AI自动化测试这两年热度很高但很多零基础同学一上来就搜教程、找框架、装环境结果卡在“工具太多不知道从哪条线开始”。我先给一个比较直接的判断AI不会让你跳过测试基础但会大幅降低写用例、维护脚本、排查失败的门槛。如果你正准备入门自动化测试或者正在做手工测试想转自动化别指望只靠某个“一键生成用例”的工具就能学会。更稳妥的路是先掌握 Python 基础再跑通一个 UI 自动化用例然后让 AI 帮你写用例、定位元素和分析失败接着补接口自动化最后用一到两个实战项目把整条链路串起来。这篇内容不是速成班但会把每一步怎么开始、环境怎么准备、失败怎么看、参数怎么调讲清楚少走弯路。1. 先把学习路径理清楚再决定要不要上 AI很多零基础的同学学自动化测试第一步不是搭环境而是被五花八门的名词吓住Selenium、Playwright、Appium、Airtest、pytest、接口自动化、测试平台、AI Agent。这些工具确实都会出现在日常工作中但你不需要一口气全部学完。1.1 零基础最常见的误区工具优先逻辑靠后我见过不少新人的学习方式是这样的今天看到有人推荐 Selenium装了一下午环境明天看到 Playwright 很火又去装 Node 和浏览器后天看到 AI 能自动生成测试脚本觉得前面的都白学了。这个思路不是完全错但效率很低。工具只是自动化测试的“手”更关键的是测试逻辑怎么设计用例、怎么判断页面是否加载成功、怎么处理不稳定元素、怎么断言结果、怎么在失败时保留现场。这些问题没有想清楚换任何框架都会卡住。AI 确实能帮你写出一段看起来很完整的脚本但只要你不理解脚本里的等待逻辑、元素定位和断言一旦报错你连怎么向 AI 描述问题都说不清楚。这也是很多教程看完就忘的原因。1.2 自动化测试的四个方向先分清再学自动化测试并不是只有“打开网页点按钮”这一种形式。下面四个方向日常工作中最常见也最值得零基础按顺序了解。技术方向核心场景主要掌握内容AI 能帮什么UI 自动化Web 页面、桌面端、移动端界面操作元素定位、等待、断言、页面对象模型生成用例、定位策略、分析失败截图接口自动化后端接口回归、数据校验、业务链路请求构造、断言、数据管理、环境切换生成测试数据、生成接口用例、整理报告测试框架与平台用例管理、执行调度、报告输出pytest、unittest、CI 集成、结果统计生成测试报告摘要、失败自动归类测试辅助工具测试数据准备、Mock、日志采集、环境检查数据库操作、文件处理、Shell 命令生成模拟数据、解释报错日志如果按投入产出比排序我建议零基础先把前两个方向做扎实先学会写最小的 UI 自动化脚本再补接口自动化。这两个方向能直接解决“重复回归”和“接口变更后不知道哪里挂了”的实际问题也最容易积累信心。2. 零基础第一站用 Python 跑通第一个 UI 自动化用例这一节不追求复杂框架只做一件小事用 Python 写一个自动化脚本打开一个网页输入内容点击按钮最后断言页面变化。能把这个闭环跑通你已经比“下载了工具但没跑起来”的人前进了一大步。2.1 环境准备Python、虚拟环境、浏览器驱动先确认本机已经安装 Python建议使用 3.10 或更高的版本。版本太低部分依赖可能不支持报错会特别多。然后创建一个虚拟环境把依赖隔离在项目目录里避免污染全局环境。在命令行里执行python -m venv testenv # Windows 激活 testenv\Scripts\activate # macOS / Linux 激活 source testenv/bin/activate pip install selenium playwright pytest requestsselenium和playwright是 UI 自动化库pytest是测试框架requests是接口自动化会用到的 HTTP 客户端。这条命令一次装好后面不用反复折腾。如果用 Selenium还需要根据浏览器版本下载对应的驱动。不同驱动版本和浏览器版本不对应启动时就会报错。Playwright 不用单独下载驱动直接执行playwright install chromium这一点对新手更友好。注意如果依赖下载速度很慢可以切换为国内镜像源但不要同时混用多个镜像容易出现依赖不完整的问题。2.2 Selenium 最小用例打开页面、输入、点击、断言Selenium 是生态最成熟的 Web UI 自动化工具很多公司的老项目都在用它。下面这段脚本是一个最小闭环from selenium import webdriver from selenium.webdriver.common.by import By driver webdriver.Chrome() driver.get(https://example.com) # 换成你自己的测试地址 driver.find_element(By.ID, username).send_keys(test_user) driver.find_element(By.ID, password).send_keys(123456) driver.find_element(By.CSS_SELECTOR, button.login-btn).click() assert Dashboard in driver.title driver.quit()这段代码很直观find_element负责找页面元素send_keys负责输入click负责点击断言检查页面标题是否发生变化。但要注意这只是最小示例。实际项目里页面加载有快有慢点击按钮后可能需要等待接口返回这时直接断言很容易失败。所以更稳妥的做法是用显式等待。2.3 Playwright 为什么对新手更友好Playwright 是近几年使用率明显上升的自动化方案它的特点是自动等待元素出现不需要你到处写sleep。下面这段脚本和上面的 Selenium 完成同样的事情from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) # headlessTrue 时不开浏览器窗口 page browser.new_page() page.goto(https://example.com) page.locator(#username).fill(test_user) page.locator(#password).fill(123456) page.get_by_role(button, name登录).click() page.wait_for_selector(.dashboard) assert page.title() Dashboard browser.close()Playwright 的三个特点对新手很实用locator的定位语法更接近 CSS 和文本语义比 Selenium 的定位写法更容易读。get_by_role能按按钮名称定位不用死记冗长的 class。wait_for_selector会等到元素出现减少因为加载慢导致的失败。判断一步是否真正跑通我不看“能打开浏览器”而是看同一个脚本能不能连续跑 3 次以上。如果每次都出现等待超时就要调整定位方式或等待条件而不是加大sleep。3. AI 在自动化测试里能帮什么不是替你造火箭是替你干脏活很多人对 AI 自动化的期待是给一个人工智能它自己就懂业务、自动写用例、自动修 bug。现阶段距离这个理想状态还有距离但在测试场景里AI 已经能在四个环节上明显提速。3.1 AI 生成用例和代码从空白开始最快但必须做代码审查AI 最擅长的是把一段明确需求转换成代码。比如你已经有登录页面的元素信息可以直接让 AI 生成 pytest Selenium 用例。重点是你要把上下文给全。下面是一个可用的提示词思路我有一个登录页面 - 用户名输入框 id 是 username - 密码输入框 id 是 password - 登录按钮 class 是 login-btn - 登录成功后会跳转到 dashboard 页面 请帮我生成 pytest Selenium 的用例包含登录成功、密码错误两种情况失败时保存截图。AI 生成的脚本大概率能运行但你不应该直接贴进项目里。原因有三点元素定位可能因为页面结构变化而失效。错误分支可能覆盖不全。断言可能只检查了“没报错”没有检查真正的业务结果。所以我的习惯是AI 生成代码 → 人工审查定位和断言 → 跑一遍最小用例 → 再补充边界场景。AI 在这里是提高效率的助手不是质量背书。3.2 AI 定位元素处理动态 ID、弹窗、iframe、阴影 DOMUI 自动化失败最多的问题就是元素定位。常见场景包括页面加载后元素才出现、点击后弹窗遮挡、元素 ID 每次都变、内容在 iframe 或 shadow DOM 里。这些问题在 Selenium 里处理起来很繁琐。这时候可以把页面的 HTML 片段复制给 AI让它分析给出一组候选定位器。AI 能识别出哪个 ID 是动态的哪个 class 更适合用文本定位是否稳定是不是需要切换 iframe。但注意不要把带有用户真实信息的 HTML 贴到不安全的工具里。学习阶段可以用自己构建的测试页面生产环境要遵循公司数据安全规范。3.3 AI 分析失败非预期弹窗和日志的最快排查方式“自动化测试非预期弹窗导致失败”是最常见的问题之一。脚本跑着跑着突然一个弹窗挡住按钮找不到元素然后报错。很多人第一反应是加异常处理把所有异常吞掉。这是一个非常危险的思路。吞掉异常后脚本可能继续执行最后产生一个假成功的结果。正确的做法是先把失败现场保留下来包括页面截图、页面 HTML、浏览器日志、具体报错信息。然后把这一堆信息交给 AI让它判断“是否存在非预期弹窗弹窗由什么触发是否可以安全关闭”。给 AI 的上下文越完整判断越准确。只发一句“脚本报错元素找不到”AI 也无法知道是弹窗问题还是定位问题。3.4 AI Agent 辅助测试执行边界要提前定好使用 AI Agent 自动执行测试比如让它读取需求、生成代码、跑脚本、分析结果在简单 Web 场景里已经能跑通。现在也出现了很多 AI 编码代理可以辅助生成自动化测试脚本。这个方向值得学但不要抱有不切实际的期待。AI Agent 最大的问题是“看似正确实际无效”。它可能生成一段测试用例断言写了但断言对象根本不是关键业务指标它可能按默认方式等待跑一次通过跑三次就开始飘。所以用 AI Agent 执行测试的时候至少要有三层护栏环境要独立不能让它连接生产数据库。测试数据要可控最好每次使用独立账号。断言标准要人工确认不能只看“用例通过”。4. 接口自动化测试零基础提升最快的第二站很多新手觉得 UI 自动化才是自动化测试的正统接口自动化要往后放。这个想法在实际项目里是反的。接口自动化的稳定性、执行速度、投入产出比通常都比 UI 自动化高得多。4.1 为什么要先补接口自动化接口自动化测试的是后端 API不依赖页面加载、弹窗、元素定位所以失败因素更少。它适合做三类事情数据校验接口返回值是否正确、字段类型是否符合契约。链路回归登录、下单、支付、查询等接口连起来跑一遍。异常场景缺少参数、参数错误、未授权、超时等情况是否返回合理错误。对零基础来说接口自动化还能锻炼一个很重要能力把业务流程拆成数据流。你不需要看到页面也能知道当前业务走到哪一步、失败在哪一层这种能力对以后写复杂 UI 自动化非常有帮助。4.2 用 pytest requests 搭最小接口测试框架先安装依赖pip install requests pytest然后写一个最简单的接口测试文件import requests import pytest BASE_URL http://127.0.0.1:8000 def test_login_success(): resp requests.post( f{BASE_URL}/api/login, json{username: admin, password: 123456}, timeout10 ) assert resp.status_code 200 data resp.json() assert data[code] 0 assert data[data][token]这个用例做三件事请求登录接口、断言 HTTP 状态码、断言业务逻辑字段。注意status_code只表示请求通了不代表登录一定成功。真正的结果要看业务层字段比如code 0和 token 是否存在。在实际项目里接口测试框架会演进成更清晰的结构api_test/ ├── config.py # 环境地址、账号配置 ├── utils.py # 请求封装、日志封装 ├── test_cases/ │ ├── test_login.py │ └── test_order.py └── reports/ └── result.html4.3 接口自动化里的核心参数和判断标准接口自动化看起来只是“发请求 断言”但真正落地时要关注这几个参数和判断点参数或配置建议方式原因请求超时设置timeout10或更大不设置可能一直挂起浪费执行时间BASE_URL通过环境变量切换开发、测试、预发环境地址不同测试数据每个用例独立数据跑完清理避免数据互相干扰失败重试只在明确网络抖动时重试业务断言失败重试没有意义反而掩盖问题报告输出pytest 生成 HTML 报告方便定位失败用例和失败原因一个接口用例是否合格我一般会问三个问题它是否测试了真正的业务逻辑失败时报告能不能说清是哪一步换一套环境数据能不能直接跑如果三个答案都是“能”这个用例才算过关。5. 移动端和平台化Appium、Airtest、自动化测试平台怎么选学完 Web UI 自动化和接口自动化之后很多同学会进入下一个迷茫期要不要学 Appium要不要做测试平台移动端测试和 Web 测试哪个更吃香5.1 先分清移动端测试场景再选工具移动端自动化不是只有一个 Appium。不同场景适合不同工具场景推荐工具原因原生 App 功能回归Appium支持 Android、iOS生态成熟小程序 / H5 页面Appium / Playwright部分 H5 可以复用 Web 定位思路游戏 / 图像识别Airtest、SikuliX基于图像识别不依赖元素属性真机兼容测试云测平台 Appium多机型批量执行成本更高先判断你所在公司或项目最需要哪种再决定要不要深入学不要上来就把 Appium 装一遍装完发现手机连不上环境调试就劝退一大半人。5.2 Appium 为什么不适合新手第一站Appium 的学习成本明显高于 Selenium / Playwright。它需要安装 Android SDK、配置系统环境变量、准备模拟器或真机、安装 Appium Server还要处理设备连接、应用启动参数、权限弹窗等问题。任何一个环节配置不对用例连设备都起不来。我的建议是至少先跑通 Web UI 自动化和接口自动化再回来学 Appium。原因是 Appium 里的元素定位、等待、断言思路和 Selenium 高度相似只是多了设备层的问题。有 Web 基础之后再学环境问题能减少很多。5.3 Airtest图像识别带来便利但也有边界Airtest 对游戏和原生 App 比较友好因为很多界面元素没有办法用标准控件属性定位只能靠截图匹配。但图像识别有一个明显问题分辨率不同、字体渲染不同识别结果可能不稳定。所以用 Airtest 时最好把脚本和测试设备的分辨率版本固定在文档里。脚本写完后要在同一型号设备上跑多次验证稳定性不要只在开发机上跑一次就当作完成。5.4 自动化测试平台要不要学很多公司会自研或采购自动化测试平台实现用例管理、调度执行、报告查看、失败通知、测试环境申请等功能。对零基础来说自己搭一个完整平台不是优先项但可以理解平台的核心能力用例不再放在个人电脑而是集中管理。定时触发和 CI 集成让回归测试自动跑。报告统一展示失败用例一眼可见。失败重试和通知能减少无效人工盯守。如果你未来目标是测试开发可以从“本地接口自动化框架”入手再逐步把用例管理、报告输出、任务调度这几层加上去这就是一个迷你测试平台的雏形。6. 脚本不稳定怎么办非预期弹窗、等待、环境问题的排查顺序自动化测试入门容易稳定难。很多脚本第一次跑能过第二次跑就挂换台机器挂数据一变挂。这一章专门讲排查思路以后再遇到“脚本不知道为什么失败”先按这个顺序找。6.1 不要一遇到弹窗就加 try-except处理非预期弹窗最怕的就是为了“让用例通过”而用异常处理把所有弹窗吞掉。这样做的后果是元素没找到、弹窗没有处理、断言继续执行最后用例可能通过但实际业务已经卡在弹窗后面。更合理的处理方式记录页面截图和 HTML便于定位弹窗来源。判断弹窗是业务提示还是系统异常弹窗。如果是业务提示应该设计正常关闭路径。如果是系统异常应该让用例失败并保留现场。AI 在这里很适合做失败分析。把脚本步骤、页面 HTML、浏览器日志、报错信息一起发给 AI会比你自己在代码里不停猜快很多。6.2 等待策略固定 sleep 是新手最容易犯的错很多人习惯在脚本里写time.sleep(3)靠固定时间等页面加载。这种写法偶尔能跑通但非常脆弱。网络快时白白等 3 秒网络慢时 3 秒又不够最终就会随机失败。更稳定的替代方案Selenium 用WebDriverWait和expected_conditions。Playwright 自带自动等待配合wait_for_selector。接口自动化用轮询等待比如等待异步任务完成。尽量避免无脑sleep如果必须等也要写清等待条件。判断等待策略是否正确看一个标准脚本在慢环境和快环境下都能通过且不会无故多等很多秒。6.3 优先排查顺序我把自动化测试失败的排查顺序固定成五步看现象是启动失败、元素找不到、断言失败还是任务卡住。看输入URL 是否正确、测试账号是否有权限、测试数据是否存在。看环境依赖版本、浏览器驱动、设备连接、系统环境变量是否一致。看参数超时、并发、等待条件、日志级别。看工具本身当前版本是否支持你用的浏览器或 App 版本。这套顺序对 Web UI、接口、移动端都通用。很多问题不是脚本逻辑错了而是前置环境和输入数据没有准备好。6.4 让 AI 帮你排查时需要给足上下文直接把一行报错发给 AI得到的建议往往很泛。效果更好的做法是把以下信息一起给出来- 测试场景登录后跳转 dashboard - 操作步骤第 3 步点击登录按钮 - 期望结果跳转到 dashboard - 实际结果点击按钮后出现非预期弹窗元素找不到 - 页面 HTML粘贴关键片段 - 报错信息粘贴完整 traceback上下文越完整AI 的分析越接近真实原因。这个习惯对人工排查同样适用。7. 从入门到实战按三个项目逐步升级只学命令不练项目很快就会忘。这里给出三个递进项目每个项目都有明确验收标准适合作为零基础到初级测试开发之间的练习路径。7.1 项目一登录流程自动化第一个项目不贪大只做登录流程。你可以用自己的测试站点也可以搭一个本地简单页面。要求是覆盖登录成功、密码错误、用户不存在三种场景。使用显式等待不使用固定 sleep。失败时自动截图并保存到 reports 目录。用 pytest 管理用例能一键执行全部用例并输出报告。验收标准连续运行 10 次没有因为等待问题造成的偶发失败任意失败用例都能通过截图和日志快速定位。做完这个项目你已经掌握了 UI 自动化最核心的几个能力选择器、等待、断言、报告。7.2 项目二接口回归 UI 冒烟混合第二个项目开始贴近真实工作。模拟一个最简单电商流程接口创建商品UI 页面上验证商品是否展示接口下单UI 页面验证订单状态。这样设计的原因是让你理解接口和 UI 如何配合接口负责快速准备数据和验证业务链路。UI 负责验证关键页面展示是否正常。测试数据要独立跑完清理不能污染下次执行。验收标准使用一套命令完成“接口准备数据 → UI 验证 → 数据清理”的全流程重复执行三次不出现数据残留。7.3 项目三AI 辅助用例生成 小型测试平台第三个项目开始引入 AI 和平台化思路。你可以选择一个小模块比如用户注册或订单查询让 AI 生成测试用例和测试数据再由你补充边界场景然后把 pytest 报告输出为 HTML再接入一个简单的定时执行任务。这里不需要真的开发一个很复杂的平台。更实际的做法是用pytest管理用例。用 HTML 报告展示结果。用一个脚本实现定时执行和失败通知。把测试数据用 JSON 或 YAML 文件管理方便替换。验收标准新增一条测试数据后不需要改代码只需修改数据文件就能生成新用例失败时有报告可以直接看出是哪个环节出错。7.4 给零基础的学习节奏建议如果你的目标是朝测试开发方向走建议按这个节奏来第一阶段Python 基础 第一个 UI 自动化项目每天 2 小时大约 2 到 3 周。第二阶段接口自动化 接口与 UI 混合项目大约 3 到 4 周。第三阶段AI 辅助测试 小型平台化项目大约 4 到 6 周。具体时间因人而异重点不是赶进度而是每一步都要有“连续跑多次不飘”的稳定结果。最后留一个个人观点AI 自动化测试真正落地时最该盯住的不是工具多先进而是输入格式、资源占用、失败重试和日志记录。先把最简单的脚本跑稳再用 AI 提升效率这条路比直接追求 AI Agent 自动完成所有事情要可靠得多。踩过几次坑之后会发现很多问题不是 AI 能力不够而是前置环境、测试数据和断言标准没有准备干净。