AI自动化测试入门路线：7小时从环境搭建到接口实战

先问一个问题：你是不是也收藏了好几个“自动化测试入门”帖子，结果一个月过去，连环境都没装好？

我之前带过不少转测试开发的新人，发现大家普遍不是不努力，而是信息太碎。今天看到有人推 Selenium，明天又看到说 Playwright 更香，后天刷到 AI 一键生成测试用例，越看越焦虑。其实对小白来说，最缺的不是更多资料，而是一条能沿着走下去的路线。

这篇文章就是给你画一条完整的 7 小时入门路线，从环境准备、Web 自动化、接口自动化，到 AI 辅助测试脚本生成和失败分析，全部串起来。代码都是可以直接复制的，每个步骤都会解释为什么这么做。你不需要任何自动化测试基础，只要会一点点 Python，就能跟下来。

1. 为什么是 AI 自动化测试？先搞清楚学什么

1.1 自动化测试与 AI 自动化测试的边界

很多教程把“自动化测试”和“AI 自动化测试”混在一起讲，导致新手一开始就懵。我们先做一个最简单的区分。

传统自动化测试，是指用代码代替手工点击和重复验证。你写一段脚本，让它打开页面、输入账号、点击登录、检查页面是否跳转。这类工作过去全靠测试人员一条条写用例，维护成本不低。

AI 自动化测试，并不是说 AI 能完全替代测试人员，而是让 AI 参与测试的各个环节。比如：

• 根据需求描述生成测试用例。
• 根据页面截图或 HTML 结构，帮助你定位元素。
• 自动分析测试失败日志和截图，给出排查方向。
• 辅助维护脚本，页面元素变了之后，AI 帮你快速修正选择器。

所以，你应该把 AI 理解成一个“结对编程助手”，而不是“自动测试机器人”。这个认知很重要。如果你觉得 AI 能一键生成全部测试脚本且永远不需要维护，那后面一定会失望。

1.2 哪些人适合这条学习路线

这套 7 小时学习路线适合下面几类人：

• 刚接触测试开发，想找一条系统路线的在校学生。
• 手工测试做了几年，想转自动化测试的测试工程师。
• 后端开发或全栈开发，想给自己项目补上测试能力的程序员。
• 产品经理或项目助理，想通过自动化测试提高验收效率。

只要你不是完全没碰过 Python，哪怕只写过几行print("hello")，都能跟上。整套路线不涉及复杂的算法，也不要求你懂机器学习原理。AI 部分更多是教你如何高效使用现成的 AI 工具，而不是从零训练模型。

1.3 7小时学习路线的整体安排

我把学习过程拆成了 7 个可以独立执行的阶段，每个阶段 1 小时左右。这个安排比较符合“短时间建立全貌”的目标。

你不需要一次性学完 7 小时，但建议每次至少学完一个完整阶段，避免知识断层。

2. 环境准备：Python、pip、浏览器驱动与 IDE

很多新人倒在第一步，不是代码写不出来，而是环境乱七八糟。这一章节，我们按顺序把环境理清楚。

2.1 安装 Python 与虚拟环境

建议使用 Python 3.9 及以上版本。如果你还没装 Python，去官网下载安装包即可，安装时记得勾选Add Python to PATH，否则命令行里找不到python命令。

安装完成后，打开终端验证：

python --version

建议为每个项目创建独立的虚拟环境，避免不同项目依赖互相冲突。创建方式如下：

# 创建虚拟环境，venv 是虚拟环境目录名，可以按习惯命名 python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # macOS / Linux: source venv/bin/activate

激活后，终端前面会出现(venv)前缀。这意味着你后续安装的依赖只会进入当前虚拟环境，不会污染全局 Python。

2.2 安装自动化测试依赖

我们需要安装的库很明确：

• selenium：Web 自动化测试的核心库。
• playwright：另一个主流的 Web 自动化框架，后面做对比用。
• requests：发送 HTTP 请求，用于接口自动化。
• pytest：测试用例组织与执行框架。
• pytest-html：生成 HTML 测试报告。

继续在激活后的虚拟环境里执行：

pip install selenium playwright requests pytest pytest-html

如果你使用国内网络环境，下载速度慢时可以配置 pip 镜像源。这里只强调一点，镜像源要选择你所在网络环境能正常访问的地址，不要为了提速去尝试不熟悉的第三方源。

2.3 浏览器与驱动说明

Selenium 本身不包含浏览器，它需要调用你电脑上已安装的浏览器。以 Chrome 为例，你需要保证浏览器和驱动版本匹配。

现在较新版本的 Selenium 已经内置了 Selenium Manager，可以自动下载匹配的驱动。如果是旧版本，则要手动下载chromedriver并配置到环境变量。建议直接使用较新的 Selenium 版本，省去手动管理驱动的麻烦。

Playwright 的驱动管理更简单，安装后执行一条命令，它会下载对应浏览器内核：

playwright install

到这里，环境已经准备完毕。如果你遇到浏览器启动失败或驱动不匹配的报错，先回到这一步检查版本关系，不要急着去改代码。

2.4 IDE 选择

推荐使用 VS Code 或 PyCharm。VS Code 轻量，安装 Python 插件后就能直接运行脚本。PyCharm 社区版免费，对测试工程的项目结构展示更直观。

无论你选择哪个，只需要会两件事：打开终端执行命令、运行 Python 文件。不用追求花哨配置，先把流程跑起来更重要。

3. Web 自动化测试入门：从 Selenium 开始

3.1 第一个可运行的 Selenium 脚本

我们先用一个最简脚本理解 Selenium 的工作流程。为了演示稳定，用https://example.com这个保留示例站点，它不会因为网页改版而导致教程失效。

创建一个文件test_demo.py，写入以下代码：

from selenium import webdriver from selenium.webdriver.chrome.options import Options # 配置浏览器选项，--headless 表示无界面运行，调试时可以注释掉 options = Options() options.add_argument("--headless=new") # 启动 Chrome 浏览器 driver = webdriver.Chrome(options=options) try: # 打开页面 driver.get("https://example.com") # 获取页面标题 title = driver.title print("页面标题:", title) # 断言标题符合预期 assert "Example Domain" in title print("测试通过") finally: # 无论如何都要关闭浏览器，避免残留进程 driver.quit()

在终端运行：

python test_demo.py

如果看到页面标题: Example Domain和测试通过，说明你的 Selenium 环境已经通了。

这里有几个容易踩的坑：

• driver.quit()一定要写在finally中。如果脚本中途报错，浏览器进程可能残留。
• --headless=new是无头模式，不会弹出浏览器窗口，适合服务器或演示。初学者建议先注释掉，能看到浏览器操作过程，理解更直观。
• 不要手动加time.sleep()来做等待，后面会讲到更可靠的显式等待。

3.2 显式等待与元素定位

新手最容易犯的错误，就是页面还没加载完就去找元素，结果报NoSuchElementException。正确的做法是使用显式等待。

下面是一个带显式等待和元素定位的示例：

from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.chrome.options import Options options = Options() options.add_argument("--headless=new") driver = webdriver.Chrome(options=options) try: driver.get("https://example.com") # 等待 <h1> 标签可见，最多等 10 秒 h1 = WebDriverWait(driver, 10).until( EC.visibility_of_element_located((By.TAG_NAME, "h1")) ) print("h1 文本:", h1.text) assert h1.text == "Example Domain" print("显式等待测试通过") finally: driver.quit()

解释一下这里的核心知识点：

• WebDriverWait(driver, 10)表示最长等待 10 秒，但不会傻等，而是每隔一段时间检查一次条件。
• EC.visibility_of_element_located是“元素可见”的预期条件。
• By.TAG_NAME是定位方式，除此之外还有By.ID、By.CLASS_NAME、By.XPATH、By.CSS_SELECTOR。

定位时优先使用id，因为页面中id通常唯一。如果元素没有稳定id，再考虑CSS_SELECTOR或XPATH。不要轻易用XPATH里的绝对路径，比如/html/body/div[1]/div[2]/form/input，这种路径只要页面层级变动一点就会失效。

3.3 AI 辅助编写 Web 测试脚本的思路

很多读者关心“AI 能不能帮我写自动化测试脚本”？答案是能，但你要学会怎么问。

我们拿“非预期弹窗导致失败”这个经典问题举例。页面测试过程中，突然弹出一个非预期的广告弹窗或系统提示框，脚本继续点击原目标按钮时就会失败。传统做法是写一个统一的弹窗兜底逻辑。

你可以把需求描述给 AI，例如：

我正在用 Selenium 做 Web 自动化测试。页面在加载过程中可能随机弹出广告弹窗或 alert 提示框，导致后续点击按钮失败。请帮我写一个通用的弹窗处理函数，要求： - 在每次页面操作前自动检查弹窗 - 如果有 alert，则自动接受或关闭 - 如果是 iframe 弹窗，则切换到 iframe 后关闭 - 不阻塞正常的页面操作

AI 会给你类似下面的代码：

from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.common.exceptions import TimeoutException, NoAlertPresentException from selenium.webdriver.common.alert import Alert def handle_unexpected_popup(driver, timeout=2): """处理非预期弹窗，兼容 alert 和常见 iframe 弹窗。""" # 处理 alert 弹窗 try: alert = WebDriverWait(driver, timeout).until(EC.alert_is_present()) alert.accept() print("已关闭 alert 弹窗") return True except TimeoutException: pass except NoAlertPresentException: pass # 处理带关闭按钮的 iframe 弹窗，这里假设关闭按钮的 class 包含 close try: iframes = driver.find_elements(By.TAG_NAME, "iframe") for iframe in iframes: driver.switch_to.frame(iframe) close_buttons = driver.find_elements(By.CSS_SELECTOR, ".close, [aria-label='关闭'], [aria-label='Close']") if close_buttons: close_buttons[0].click() print("已关闭 iframe 弹窗") driver.switch_to.default_content() return True driver.switch_to.default_content() except Exception as e: print("弹窗处理失败:", e) return False

注意，AI 生成的代码不一定完全符合你的页面结构。比如“关闭按钮的 class”就是需要你根据实际页面调整的地方。正确的使用方式是：

1. 让 AI 生成初版代码。
2. 本地运行，观察报错。
3. 把报错信息贴回给 AI，让它修正。
4. 人工审核后合入测试工程。

这种“人机协作”的方式，才是当前 AI 辅助测试的主流工作模式。

4. 接口自动化测试快速实践：requests + pytest

4.1 接口测试为什么是入门首选

相比 UI 自动化，接口自动化测试上手更快、运行更稳定、排查问题更容易。你可以把它理解成直接向后端服务发请求，然后验证返回结果是否符合预期。

实际项目里，接口自动化覆盖率往往比 UI 自动化更高，因为它不依赖页面加载和元素渲染。对新手来说，先掌握接口自动化，更容易建立起信心。

我们使用requests发送 HTTP 请求，使用pytest来组织测试用例。先安装依赖：

pip install requests pytest

4.2 编写第一个接口测试用例

这里使用 JSONPlaceholder 提供的公开测试接口，避免你自己搭建后端服务。创建一个文件test_api_demo.py：

import requests def test_get_post_by_id(): """测试获取指定 ID 的文章详情。""" response = requests.get("https://jsonplaceholder.typicode.com/posts/1") # 1. 断言 HTTP 状态码 assert response.status_code == 200 # 2. 解析 JSON 响应体 data = response.json() # 3. 断言业务字段 assert data["id"] == 1 assert "title" in data assert "body" in data print("接口测试通过，标题为:", data["title"])

在终端运行：

pytest test_api_demo.py -v

-v参数会输出更详细的执行结果。如果看到1 passed，说明接口测试已经跑通了。

这里有几个关键点：

• 不要只断言状态码。状态码是基本门槛，但不够，一定要对关键业务字段做断言。比如上面例子里的id、title。
• 接口测试中，响应时间也是重要指标。response.elapsed.total_seconds()可以用来判断接口性能是否达标，你可以把耗时断言加进去。
• 真实项目中，接口请求往往需要携带 Token 或签名。不要把这些敏感信息硬编码在代码里，而是通过环境变量或配置文件读取。

4.3 数据驱动与断言技巧

实际工作中，一个接口往往要验证多组测试数据。我们不应该复制粘贴多个用例，而是使用参数化。

pytest通过@pytest.mark.parametrize支持参数化，看下面这个例子：

import pytest import requests @pytest.mark.parametrize("post_id, expected_title_prefix", [ (1, "sunt aut"), (2, "qui est esse"), (3, "ea molestias"), ]) def test_post_content(post_id, expected_title_prefix): """数据驱动示例：循环请求不同文章，验证标题前缀。""" response = requests.get(f"https://jsonplaceholder.typicode.com/posts/{post_id}") assert response.status_code == 200 data = response.json() assert data["id"] == post_id assert data["title"].startswith(expected_title_prefix)

执行：

pytest test_api_demo.py -v

你会看到 4 个测试用例被执行，其中第一条是普通用例，后三条是参数化用例。如果某组数据失败，pytest会单独标记失败，不会影响其他组。

这里也体现出 AI 的用武之地：你只需要把接口文档粘贴给 AI，它就能帮你生成类似的参数化用例。但你要学会检查：

• 期望值是否合理。
• 边界值是否覆盖。
• 异常场景是否缺失，比如传空参数、传非法类型、未携带鉴权头等。

5. 把 AI 引入测试日常：弹窗处理与失败分析

5.1 处理“非预期弹窗导致失败”这类问题

在自动化测试的面试题中，经常会出现“测试过程中遇到非预期弹窗，脚本失败了怎么办”。这不仅是面试题，也是真实的工程问题。

非预期弹窗通常来自三类：

• 应用系统自身的提醒弹框，比如“确认删除吗”。
• 第三方广告或活动弹窗。
• 浏览器原生 alert 或 confirm 框。

处理思路要分情况。如果是业务操作必须确认的弹窗，你应该把它当作测试步骤的一部分，正常去处理。如果是不影响主流程的广告弹窗，则写一个兜底函数，在关键操作前检查并关闭。

我在 3.3 小节给出过一个弹窗兜底函数。这里再补充一个更常见的思路：统一在“点击按钮”这层做封装。

from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def safe_click(driver, locator, timeout=10): """先处理可能出现的弹窗，再点击目标元素。""" # 这里调用上文的弹窗处理函数 handle_unexpected_popup(driver) element = WebDriverWait(driver, timeout).until( EC.element_to_be_clickable(locator) ) element.click()

在页面操作频繁的场景中，把所有点击都收敛到safe_click这类封装方法中，比在每个测试用例里都写弹窗处理逻辑要干净得多。

5.2 AI 辅助失败日志与截图分析

当测试用例失败时，只靠看代码往往很难定位问题。这时候，AI 可以成为一个给力的排查助手。

我们需要做的是，在测试框架中加入截图和日志收集能力。例如，在 pytest 里通过钩子函数，在用例失败时自动截图，并把页面 HTML 或日志保存下来：

import pytest from datetime import datetime @pytest.hookimpl(hookwrapper=True) def pytest_runtest_makereport(item, call): outcome = yield report = outcome.get_result() if report.when == "call" and report.failed: driver = item.funcargs.get("driver") if driver: timestamp = datetime.now().strftime("%Y%m%d_%H%M%S") screenshot_path = f"failure_{timestamp}.png" driver.save_screenshot(screenshot_path) print(f"失败截图已保存: {screenshot_path}")

这段代码的作用是：一旦用例失败，自动保存一张带时间戳的截图。有了截图之后，你可以直接把它丢给 AI 工具，问它：

这张截图来自自动化测试失败现场。请帮我分析： 1. 页面上有没有明显报错提示？ 2. 哪些区域可能遮挡了目标元素？ 3. 根据你的经验，最可能导致脚本失败的原因是什么？

AI 会结合截图内容给出方向性判断。注意，它不一定 100% 准确，但能帮你把排查范围从几十个文件缩小到具体几行代码。这是一种很实用的提效方式。

5.3 常见 Prompt 模板与审核机制

为了让 AI 输出更符合测试需求，我整理了几个可以直接套用的 Prompt 模板。

生成测试用例：

请根据下面的需求，生成 pytest 接口测试用例。 需求：{需求描述} 接口文档：{接口文档} 要求： 1. 覆盖正常场景、异常场景、边界场景。 2. 使用 requests 库。 3. 不硬编码敏感信息。 4. 输出代码，并对关键断言添加注释。

分析失败日志：

下面是我的一条自动化测试失败日志： {日志内容} 请帮我分析： 1. 失败的直接原因是什么？ 2. 可能涉及的模块或配置。 3. 下一步排查步骤。 4. 给出修复建议。

生成页面元素定位：

下面是一个页面的 HTML 片段： {HTML 片段} 我要用 Selenium 点击“提交”按钮，请帮我写一个稳定可靠的元素定位表达式。 要求：优先使用稳定的 id 或 data 属性，避免使用绝对路径。

在使用 AI 生成内容时，必须保留人工审核环节。AI 生成的测试脚本可能包含不存在的属性、错误的依赖版本，或者有安全风险的执行逻辑。任何测试代码进入测试环境之前，都要经过人工 review。

6. 常见问题与排查思路

新手在搭建和运行自动化测试时，最容易遇到下面这些问题。我把现象、原因和解决思路整理成了一张表，方便你直接查阅。

如果你遇到表格里没有的情况，可以按照下面三步排查：

1. 先看报错堆栈，定位是哪个文件、哪一行报错。
2. 根据报错内容判断是环境问题还是代码问题。环境问题优先检查依赖版本和驱动版本，代码问题优先检查定位表达式和等待条件。
3. 把关键报错信息复制给 AI，附上你的代码片段和页面结构，让 AI 给出多条解决思路后再选型。

不要一遇到报错就重装环境，也不要反复刷新页面碰运气。学会读报错，是测试开发的基本功。

7. 工程化建议：从能跑到能用再到可维护

7.1 测试代码结构

入门阶段，很多人会把所有测试脚本放在一个文件里，比如test_demo.py。这在学习阶段没问题，但一旦进入真实项目，就需要一个清晰的项目结构。

下面是一个比较常见的接口自动化测试工程结构：

auto_test/ ├── config/ │ ├── __init__.py │ └── settings.py # 全局配置，如环境地址、超时时间 ├── testcases/ │ ├── __init__.py │ ├── test_api_demo.py # 接口测试用例 │ └── test_web_demo.py # Web 自动化测试用例 ├── common/ │ ├── __init__.py │ ├── request_client.py # 封装 requests 请求 │ ├── webdriver_utils.py # 封装浏览器驱动和弹窗处理 │ └── assert_utils.py # 封装常用断言 ├── data/ │ └── test_data.json # 测试数据文件 ├── reports/ # 测试报告目录 └── requirements.txt # 项目依赖

这种分层结构有三个好处：

• 配置与代码分离，切换测试环境时不用改代码。
• 公共方法封装后，测试用例更简洁。
• 数据与脚本分离，新增测试数据时不用动代码。

7.2 数据隔离、日志与截图

自动化测试最怕什么？最怕“测试环境数据被别人改了，导致用例失败”。这不是代码问题，而是数据管理问题。

为了降低这种脆弱性，建议做到以下几点：

• 每条测试用例尽量使用独立测试数据，比如使用带时间戳的随机用户名、随机订单号。
• 测试涉及创建、修改、删除数据时，用例执行完成后要清理数据。
• 数据库是测试环境的，也要遵循最小权限原则。不要用生产数据库账号去执行测试脚本。
• 涉及 DELETE 或 UPDATE 的测试数据操作，先在测试环境验证，确认影响范围后再执行。

日志和截图同样重要。我在第 5 章演示了失败截图方案。在真实工程中，还可以把关键步骤的日志输出到文件，方便 CI 执行失败时追溯。

import logging logging.basicConfig( level=logging.INFO, format="%(asctime)s - %(levelname)s - %(message)s", handlers=[ logging.FileHandler("test_run.log", encoding="utf-8"), logging.StreamHandler() ] ) logger = logging.getLogger(__name__) logger.info("开始执行登录用例")

日志要能回答这三个问题：执行到哪一步了、传了什么参数、返回了什么结果。这样即使不打开浏览器，也能从日志里还原整个操作流程。

7.3 权限、授权与生产安全

这一点必须单独强调。

自动化测试脚本一旦进入工程化阶段，大概率会涉及系统账号、Token、数据库连接等敏感信息。这些信息不能随手写在代码里，更不能提交到公开仓库。正确做法是通过环境变量或专门的配置中心管理。

# .env 文件示例，不要提交到 git TEST_ENV_BASE_URL=http://test.example.com TEST_ADMIN_USERNAME=admin TEST_ADMIN_PASSWORD=your_secure_password

代码中读取：

import os BASE_URL = os.getenv("TEST_ENV_BASE_URL", "http://test.example.com") USERNAME = os.getenv("TEST_ADMIN_USERNAME", "") PASSWORD = os.getenv("TEST_ADMIN_PASSWORD", "")

在测试环境操作数据时，务必确认你有合法授权。尤其是涉及数据库、线上业务系统的脚本，不要用高权限账号跑一些自己都看不懂的用例。要遵循“最小权限、测试环境验证、先备份再变更”的原则。任何自动化脚本都不应该成为破坏系统的工具。

如果你需要连接数据库校验数据，建议使用只读账号，并明确限定只能访问测试库。不要拿生产库练手，这个底线不能破。

8. 下一步学习路线与收尾

到这里，你已经掌握了 AI 自动化测试入门阶段最重要的内容：环境搭建、Web 自动化、接口自动化、AI 辅助脚本编写和失败分析。

接下来，可以根据你自己的发展方向选择深入方向：

• 如果偏向 Web 测试，继续学习 Page Object 设计模式、Selenium Grid 分布式执行、Playwright 的自动等待与多浏览器支持。
• 如果偏向接口测试，继续学习 pytest 插件体系、Allure 报告、接口签名与加密、性能测试基础。
• 如果对 AI 应用感兴趣，可以研究 AI Agent 在测试领域的落地思路，比如让 AI 根据测试结果自动生成缺陷报告，或根据页面变化自动维护测试脚本。

不过，我不建议一开始就追新概念。先把本文里的代码亲手运行一遍，再找一个你熟悉的网站，照着第 3 章的思路写一个自定义的自动化测试用例。过程中遇到任何报错，都先回到第 6 章的排查表里找答案。

如果按这篇顺序走一遍，7 小时其实比很多人零散刷一个月更有效。剩下的路，就是每天用真实业务页面和接口去积累用例，把 AI 当成一个随时在线的结对程序员，不断把重复劳动交给它。遇到新的问题，再回到上面的排查清单里看一遍，基本能覆盖入门阶段的大部分困惑。

如果这篇文章对你搭建第一条 AI 自动化测试线有帮助，可以收藏备用，也欢迎在评论区聊聊你正在测的项目类型，我会根据典型场景继续整理下一期实战内容。