AI自动化测试零基础入门：Python+Playwright+pytest实战

AI自动化测试是最近几年测试领域讨论最多的话题之一，但“热门”和“容易入门”并不是同一回事。很多零基础同学看到招聘要求里写“熟悉自动化测试、了解AI工具”，立刻去刷了一堆框架教学，结果仍然不会写用例，更不知道怎么处理元素定位失败、弹窗遮挡、脚本偶发报错。真实情况是：AI确实能帮你生成脚本、推荐定位方式、分析失败原因，但它无法替代你对业务规则和稳定性的判断。这篇文章不推荐你看完所有教程再动手，而是围绕“最小可运行项目”这条主线，把自动化测试的安装、用例设计、AI辅助、失败排查和项目落地串起来。学完之后，你能独立搭建一个 Python + Playwright + pytest 的测试工程，看懂 AI 生成的代码，并知道遇到“非预期弹窗导致失败”这类问题该从哪里查起。

1. 不要急着写脚本，先理解AI自动化测试的边界

1.1 为什么传统自动化测试会让新手放弃

很多零基础同学第一次接触自动化测试，是从一个令人兴奋的演示开始：打开浏览器、填写登录框、点击按钮、自动断言结果。但一旦把同样的思路放进真实项目，问题就来了：页面元素加了动态属性，脚本挂了；登录后出现一个广告弹窗，点击被拦截；接口返回慢了 100 毫秒，断言超时；测试数据被上一次运行污染，第二次执行直接失败。

这些问题不全是代码能力造成的，而是自动化测试本身有一个隐藏门槛：测试脚本要同时处理“业务逻辑”“页面状态”“网络时序”和“运行环境”。新手往往只盯住某一处操作，忽略了测试的稳定性设计。于是脚本比手工点一遍还慢，最后只好放弃。

理解自动化测试的正确姿势，不是把所有交互都写出来，而是先想清楚哪些内容要验证、哪些内容可以抽象、哪些变化会导致失败。AI 的介入，是为了帮你处理其中一部分“批量操作”和“不确定性”，但前提是你得先有一个能稳定运行的基础框架。

1.2 AI在自动化测试中的四个真实落点

AI 做不了的事很多，但能做的事已经足够有价值。零基础入门的重点，是先把下面四个方向搞清楚。

第一，测试数据生成。以前构造一批登录账号、订单数据、边界值，要么在数据库里手工造，要么写生成脚本。现在可以用自然语言描述字段规则，让模型生成结构化的测试数据，再通过代码写入测试环境。

第二，用例代码生成与转换。你可以用一句“用 Playwright 写一个登录成功后断言首页显示用户昵称”的描述，换来一段可运行的脚本草稿。也可以把 Selenium 的旧用例翻译成 Playwright 的新写法。这类场景下，AI 更像个“熟练的初级开发”，能给你一份不完美但可修改的初稿。

第三，元素定位与自动修复。页面 DOM 变动后，AI 可以根据当前页面结构和历史定位信息，推荐更稳定的选择器，甚至直接给出修复后的代码。它对页面结构混乱的项目尤其有用，但需要你配置好页面源码获取链路。

第四，失败分析与缺陷分类。脚本运行失败后，截图、日志和页面状态通常散落在多个地方。AI 可以把这些信息汇总，按“元素未找到”“非预期弹窗”“超时”“断言失败”“环境问题”等类别给出初步结论，帮助测试人员快速定位问题。

这四个方向没有一个是“全自动测试”的魔法，但都能降低重复工作的成本。入门时应该从第一和第二个方向开始练习，因为它们更容易看到效果，也更容易被人工验证。

1.3 哪些场景现在还不适合依赖AI

依赖 AI 输出的代码，必须区分场景。涉及支付金额计算、权限越权、敏感数据展示、复杂审批流这类高风险业务，AI 生成的断言只能当作参考，核心校验必须由测试人员手工设计，并且经过代码评审。

同样，依赖视觉判断的 UI 测试，例如“页面配色是否合理”“图标是否清晰”“图片是否被拉伸”，并不是自然语言模型擅长的事情。更合适的是视觉回归测试工具，通过基线图片对比像素差异。

还有一类场景不适合直接用 AI 生成，就是测试环境本身不稳定。如果页面经常出现随机弹窗、接口超时、数据被并发任务污染，AI 生成的脚本只会把不稳定因素复制得更快。先把环境稳定下来，再谈让 AI 提升效率，才是正确的顺序。

2. 工具选型：从哪个技术栈开始最不容易劝退

2.1 主流自动化测试工具横向对比

零基础选工具，最怕一上来就撞上复杂的学习曲线。下面表格列出几种主流工具，重点是它们各自适合什么场景，以及和 AI 能力结合的容易程度。

如果目标是尽快建立“自动化测试能跑通”的信心，建议先选 Web 端的 UI 自动化或接口自动化。移动端自动化需要准备模拟器、真机、驱动版本匹配等环节，容易在环境阶段就被劝退。

2.2 为什么推荐 Python + Playwright + pytest 作为入门组合

对于完全没有开发经验的人来说，Python 的语法更接近自然语言，变量和断言都更容易读懂。Playwright 的核心优势是自带自动等待机制，它会在点击元素前主动检查元素是否可操作，不会像旧式脚本那样频繁使用固定延时，这对新手非常友好。

pytest 则提供简单的断言、夹具、参数化和报告能力。你可以用assert page.title() == "登录页"这种写法验证结果，而不需要理解复杂的断言框架。这三个工具组合起来，能让新手把精力放在业务逻辑上，而不是耗费在环境兼容和等待时间上。

这个组合也适合 AI 辅助。Playwright 的定位方法、等待方法命名比较规范，AI 模型训练数据多，生成的代码通常偏离不大。Selenium 同样可以学习，但在处理动态页面时，需要自己写得更多。

2.3 AI辅助工具和模型怎么选

市面上能辅助测试的 AI 能力大体分三类：通用大模型、代码生成模型、测试平台自带 AI 功能。通用大模型适合理解业务描述和生成初稿；代码生成模型适合补全函数和处理转换；测试平台 AI 功能适合团队统一管理，但往往需要引入额外平台依赖。

选型时要重点确认三件事。第一，模型能不能接收长文本，因为页面 DOM 很大，截断之后定位逻辑会缺失。第二，数据是否安全，生产环境的页面文本、用户信息不要直接传给外部模型服务，优先使用公司内部模型网关或脱敏后再处理。第三，生成结果是否可追溯，AI 给出的代码应当能对应到具体的 prompt、页面版本和修改时间。

下面是一个调用模型接口生成选择器建议的最小示例，实际项目要换成你自己的模型服务地址和 API Key：

from openai import OpenAI client = OpenAI( api_key="your-api-key", base_url="https://your-model-gateway.example.com/v1" ) def suggest_locator(page_snippet: str) -> str: resp = client.chat.completions.create( model="your-model", messages=[ {"role": "system", "content": "你是测试开发助手，擅长根据HTML片段推荐稳定的测试选择器。"}, {"role": "user", "content": f"请根据下面HTML推荐5个定位方式，并说明优先级：\n{page_snippet}"} ] ) return resp.choices[0].message.content

这段代码只用于说明思路，直接放在生产项目前，还要补充超时、重试、日志和脱敏处理。

3. 本地环境搭建：把最小可运行环境跑起来

3.1 Python环境准备

在动手之前，先确认电脑上装了 Python 3.10 或更高版本。打开终端执行以下命令，创建一个独立的虚拟环境，避免全局环境依赖互相污染：

python -m venv venv

Windows 系统激活虚拟环境：

venv\Scripts\activate

macOS 或 Linux 系统激活虚拟环境：

source venv/bin/activate

激活后，命令行提示符前面会出现(venv)。这一步很重要，后续安装的依赖都会保留在这个环境里，换一台电脑时只需要导出依赖清单再重建。

3.2 安装自动化测试依赖

安装 Playwright 的 pytest 插件和浏览器内核：

pip install --upgrade pip pip install pytest-playwright playwright install chromium

playwright install chromium会下载浏览器运行时，体积较大，需要等待一段时间。如果只做接口测试，这一步可以跳过。如果后面要接入 AI 模型，再执行：

pip install openai

安装完成之后，建议先看一眼版本，方便后续排查问题：

python --version pytest --version

3.3 设计测试项目目录

零基础阶段不需要一开始就做很复杂的工程，但建议按下面的目录组织代码，避免所有脚本堆在一个文件里：

web_test/ pages/ login_page.py cart_page.py tests/ test_login.py test_cart.py utils/ driver.py handle_popup.py conftest.py pytest.ini requirements.txt

pages目录放页面封装，tests目录放测试用例，utils目录放通用工具，conftest.py放全局夹具。这样的结构看起来很基础，但能让你在项目变大时不用大规模重构。

3.4 第一个冒烟测试：打开首页并断言标题

先不写登录、不写购物车，只验证一件事：浏览器能启动，页面能打开，标题正确。在tests目录下新建test_smoke.py：

from playwright.sync_api import sync_playwright def test_page_title(): with sync_playwright() as p: browser = p.chromium.launch(headless=True) page = browser.new_page() page.goto("https://example.com") assert page.title() == "Example Domain" browser.close()

运行测试：

pytest tests/test_smoke.py -v

如果看到1 passed，说明环境已经完全跑通。这里的headless=True表示无头模式，浏览器不会弹出窗口；调试时可以改成headless=False，方便观察页面信息。

注意：不要只验证程序能启动。第一个用例跑通后，应该故意改错断言，例如把标题改成错误值，确认它会失败。这能帮助你理解测试的真正作用。

4. 实战：用AI辅助写一个登录+购物车自动化用例

4.1 页面模型与核心操作

自动化脚本最容易失控的部分是页面定位和重复操作。页面模型（Page Object Model, POM）的核心思路，是把“某页面上有哪些元素”和“某个用例要做什么”分开。

比如LoginPage专门负责登录页相关的定位和动作，测试用例只描述业务意图。这种设计的收益是在页面结构变化时，只需要修改对应页面类，而不需要修改所有用例。

下面是一个最简LoginPage示例：

from playwright.sync_api import Page class LoginPage: def __init__(self, page: Page): self.page = page def goto(self, url: str): self.page.goto(url) def login(self, username: str, password: str): self.page.get_by_test_id("username").fill(username) self.page.get_by_test_id("password").fill(password) self.page.get_by_test_id("login-button").click()

这里使用了get_by_test_id，要求页面元素上有>你是测试开发工程师。业务场景：用户在登录页输入用户名和密码，点击登录按钮，成功进入首页。请用 Python Playwright 的 Page Object 风格生成 LoginPage 类。要求： 1. 使用>from playwright.sync_api import Page def test_login_success(page: Page): login_page = LoginPage(page) login_page.goto("https://demo.test.local/login") login_page.login("test_user", "test_pass") profile_name = page.get_by_test_id("profile-name") profile_name.wait_for() assert profile_name.inner_text() == "test_user"

这里没有用固定延时，而是用wait_for()等待“登录成功后页面上会出现用户信息”这一状态，稳定性会好很多。

4.3 关键参数：等待策略

测试不稳定最主要的原因是等待不当。下面表格列出几种常见等待方式，方便你写代码时对照选择。

在实际项目中，最推荐第三种和第四种组合。例如点击按钮前，让 Playwright 自动等待按钮可操作；登录成功后，用显式等待等待业务标志出现。

4.4 结合AI处理非预期弹窗

“自动化测试非预期弹窗导致失败”是热搜里出现频率很高的问题，也是新手最容易卡住的地方。弹窗通常分两类：一类是浏览器原生对话框，一类是网页上的广告浮层或遮罩。处理方式不同。

原生对话框可以监听并处理：

page.on("dialog", lambda dialog: dialog.dismiss())

网页浮层则需要关闭按钮。以下函数会对页面中常见的弹窗关闭元素做一次“尝试关闭”，并吞掉超时异常：

from playwright.sync_api import TimeoutError as PlaywrightTimeoutError def close_popups(page): selectors = [ ".modal-close", ".pop-up-close", ".ad-close", "button:has-text('我知道了')" ] for selector in selectors: locator = page.locator(selector) try: if locator.count() > 0: locator.first.click(timeout=1000) except PlaywrightTimeoutError: pass

这里的关键是“尝试关闭”而不是“必须关闭”。如果页面上没有弹窗，这个函数应该安静地返回。AI 在这里的作用不是替你写死所有选择器，而是根据截图和 DOM 生成新的选择器候选，再人工确认。

在测试环境的控制台里，也可以直接关闭弹窗生成开关。比 Allowed 更好的是：找开发确认测试环境是否有可配置的“关闭所有广告位”开关，有的话优先使用，脚本里的浮层处理代码只是兜底。

4.5 运行用例并生成HTML报告

给 pytest 添加 HTML 报告能力，可以让失败信息更直观。先安装插件：

pip install pytest-html

运行整个测试目录并输出报告：

pytest tests -v --html=report.html --self-contained-html

打开report.html，可以看到每个用例的执行时间、失败断言和现场截图。对零基础阶段来说，报告最重要的作用是复盘：失败时先看堆栈，再看截图，远比在终端里猜原因高效。

5. 接口自动化：AI不只能写UI脚本，还能帮你设计断言

5.1 UI自动化为什么不能覆盖所有场景

UI 自动化解决的是“从用户视角确认功能可用”的问题，但它的执行速度慢，而且对页面结构变化非常敏感。一个典型场景是：后端接口已经报错，但页面仍然显示“加载成功”，UI 脚本会用肉眼看不到的页面状态通过测试，而接口测试可以在毫秒级发现返回体异常。

接口自动化更贴近业务逻辑，稳定性更高，也是学习和上手速度最快的分支。建议零基础同学在学完 UI 自动化基本流程后，立刻转向接口测试，因为它能帮助你理解前后端协议，也能扩充简历里的技术点。

5.2 搭建最简单的接口自动化框架

接口自动化不需要浏览器，只需要发送 HTTP 请求并断言响应。目录结构比 UI 测试更简单：

api_test/ tests/ test_user.py utils/ http_client.py data/ login_data.json conftest.py requirements.txt

http_client.py里封装一个简单的请求会话：

import requests class HttpSession: def __init__(self, base_url): self.base_url = base_url self.session = requests.Session() def post(self, path, **kwargs): return self.session.post(self.base_url + path, **kwargs)

具体用例可以这样写：

def test_login_success(): api = HttpSession("https://api.example.com") resp = api.post("/login", json={"username": "tester", "password": "test_pass"}) assert resp.status_code == 200 assert resp.json()["token"] != ""

运行时要注意两点：一是把base_url指向测试环境，二是用户名和密码不要硬编码在测试代码里，可以放到环境变量或配置文件中。

5.3 AI如何生成测试数据和参数用例

接口测试里最耗时的是数据准备和参数组合。你可以让 AI 先基于接口定义生成一份边界值表，例如：

登录接口字段：username（字符串，长度1-20），password（字符串，长度6-18）。 请生成等价类和边界值用例，包括非法输入和预期状态码，输出为 Markdown 表格。

得到表格后，再把它转成 pytest 的参数化数据：

import pytest cases = [ {"username": "", "password": "test_pass", "expect": 400}, {"username": "tester", "password": "123", "expect": 400}, {"username": "tester", "password": "correct_password", "expect": 200}, ] @pytest.mark.parametrize("case", cases) def test_login_batch(case): resp = HttpSession("https://api.example.com").post("/login", json={ "username": case["username"], "password": case["password"] }) assert resp.status_code == case["expect"]

这里的expect字段需要测试人员根据接口文档确认，不能只依赖 AI 推断。AI 的价值是快速生成候选组合，而不是替代业务判断。

5.4 把AI生成的用例和手工审查结合起来

AI 生成测试数据很方便，但容易出现两类问题：一是它可能生成不符合真实业务含义的数据，比如把邮箱字段生造成了手机号；二是它可能生成过于理想化的用例，忽略了权限、状态机、并发这些复杂条件。

推荐的做法是：让 AI 生成“草稿用例集”，然后按照业务优先级人工挑选 20% 的用例进入自动化框架。这 20% 通常覆盖登录、核心接口、关键状态流转。其余用例先保存为文本文档，等框架稳定后再逐步加入。

注意：任何 AI 输出的断言预期值，都必须以接口文档或测试环境实际行为为准。如果环境行为与 AI 输出冲突，先确认接口定义，再决定修改测试还是提交缺陷。

6. 常见失败与排查：非预期弹窗、定位失效、AI代码不容错

6.1 非预期弹窗导致失败

现象很典型：脚本运行到点击登录按钮时，报Element is not clickable或直接超时；从截图上看，按钮被一个弹窗遮住了。

处理非预期弹窗时，不要全部靠脚本解决。先在测试环境里找到弹窗开关，能关就关；不能关再写兜底逻辑。否则每换一个页面，你都要维护一份弹窗选择器列表。

6.2 元素定位失效

AI 生成的选择器失效，是接入 AI 后最常见的挫败感来源。原因通常是页面版本更新后，生成选择器时参考的 DOM 已经变了，或者 AI 给出的是非常长的绝对 XPath。

解决方向有三个。第一，优先选择带有># 容易失败：依赖页面层级和顺序 page.locator("/html/body/div[2]/form/div[1]/input").fill("test") # 推荐：使用可读性更强的属性 page.get_by_test_id("username").fill("test")

如果你要保留 AI 推荐的选择器，可以在页面类里建一个选择器常量表，并把页面版本和生成日期写进注释，方便后续排查。

6.3 AI生成的代码能跑但断言错误

有时候 AI 生成的脚本能正常打开页面，也能点击按钮，但断言却失败了。这时候要先验证断言对象本身。比如你断言“登录成功后页面显示 admin”，但实际页面上显示的是完整用户名Admin User，需要区分包含关系和精确匹配。

处理方式是在断言前打印关键值：

print(profile_name.inner_text()) assert "admin" in profile_name.inner_text().lower()

如果打印出的值和预期完全对不上，再回去看接口返回或页面渲染逻辑。不要先用try...except把断言异常吞掉，那样只会让失败变得更难发现。

6.4 测试不稳定/偶发失败

偶发失败是自动化测试项目经理要求必须解决的问题。常见原因包括：测试用例之间存在依赖，第二个用例依赖第一个用例留在页面上的状态；多个用例并发执行，操作了同一份测试账号；接口响应很慢，等待超时；运行环境 CPU 高，导致点击事件被延迟。

针对这些情况，可以从四方面改进：

• 用例互相独立，每个用例都从登录开始，不依赖前序用例的结果。
• 测试数据隔离，每个用例使用不同的账号或订单号，避免相互覆盖。
• 等待条件细化，不要只等待元素出现，还要等待元素可点击或已隐藏。
• 使用 pytest-rerunfailures 插件对偶发超时做有限次重试，但不要把重试当作遮羞布，长期偶发失败仍需找出根因。

安装重试插件：

pip install pytest-rerunfailures

运行时只对超时类失败重试：

pytest tests --reruns 1 --only-rerun timeout

6.5 完整排查链路

遇到自动化测试失败，建议按下面的顺序排查，避免一开始就怀疑工具和 AI：

1. 查看失败堆栈，定位是在哪一行报错。
2. 查看截图或 trace，确认页面状态是否符合预期。
3. 确认操作前的前置条件是否满足，例如是否已经登录、是否处于正确的页面。
4. 检查是否出现弹窗、遮罩、通知栏等干扰元素。
5. 检查定位是否唯一，是否匹配到了多个元素。
6. 检查等待条件是否覆盖了异步加载完成的时刻。
7. 对比手工操作，确认用例步骤本身有没有遗漏。
8. 检查测试环境数据是否被其他任务污染。
9. 如果涉及 AI 生成的代码，回看 prompt 输入阶段是否缺少页面上下文。

这条链路适用于绝大多数 UI 和接口自动化失败问题。只要按照顺序排查，大多数“看起来奇怪”的失败都能变成明确的技术问题。

7. 从入门到能落地的学习路径

7.1 阶段一：梳理业务路径

不要一上来就写代码，先在项目里选一条最核心的业务路径，例如“注册 -> 登录 -> 加入购物车 -> 提交订单”。用表格列出每一步的输入、操作、预期结果、可能出现异常的地方。这一步是为后续用例设计打底，也是 AI 提示词里需要提供给模型的上下文。

7.2 阶段二：UI自动化

用 Playwright 和 pytest 把这个路径写成最简脚本。目标不是追求完整，而是让每一步都能在测试环境稳定执行。写完后再做三件事：抽取页面模型、处理弹窗、加入失败截图。这个阶段通常需要 2 到 3 周业余时间，是打好自动化基础的关键。

7.3 阶段三：接口自动化

选择登录接口和订单接口，搭建 requests + pytest 框架。写接口测试时注意三点：状态码校验、核心字段校验、数据库状态校验。接口自动化会帮助你理解后端逻辑，也是后续 AI 生成测试数据的主要场景。

7.4 阶段四：AI辅助接入

当你已经能手工写用例时，再开始让 AI 介入。先用 AI 生成测试数据和选择器，再让它辅助做页面代码转换。AI 生成内容必须经过 review，这一步能有效防止把错误逻辑复制到项目里。

7.5 阶段五：CI/CD和测试平台

把测试命令接入持续集成流水线，让每次提交代码后自动运行冒烟测试。再考虑是否要搭建测试平台，统一展示用例、报告、设备和历史结果。测试平台不是入门阶段必须做的东西，项目达到一定规模后再引入。

7.6 学习环境与生产环境差异对比

生产环境里最重要的一条是：不要把生产数据直接传给外部 AI 模型。如果团队要使用 AI 辅助测试，应该先搭内部模型网关，或对输入内容做脱敏。

8. 最佳实践和上线前检查清单

8.1 可复用的最佳实践建议

这些建议不是口号，每一条都应该在代码评审时被问到。

• 定位元素优先>