如果你最近在找 AI 和自动化测试相关的学习资料大概率刷到过类似“2026 最强 AI 自动化测试完整版实战教程”的标题。这种标题最大的问题不是内容差而是它把学习过程压缩成了“看完一套视频就能就业”的幻想。真正能落地的路径是一条由接口自动化、UI 自动化、AI 辅助测试、CI 集成和项目实战组成的工程链路而不是某个单一工具的速成演示。这篇文章默认读者有三类零基础想转自动化测试的人、已经在做功能测试想升级测试开发的人、想搞清楚 AI 辅助测试到底是不是噱头的人。我不会去复刻课程目录而是按“学什么、怎么搭、怎么测、怎么接入 CI、怎么准备面试”的顺序把 AI 在自动化测试里真正能落地的几个方向拆开并给出一套可以直接改着用的项目骨架。先说结论AI 自动化测试不是某一个具体工具而是一套组合能力。底层是 Python 编程、接口自动化、UI 自动化、移动端自动化的基本功上层是用大模型做测试用例生成、智能断言、元素定位辅助、异常弹窗兜底和测试数据生成。基本功不稳AI 只是让坏代码写得更快。所以这篇文章虽然也会讲大模型辅助测试但大部分篇幅仍然放在测试工程本身。1. AI 自动化测试核心能力速览很多刚接触这个领域的人会把“AI 自动化测试”理解成“用 AI 代替测试人员”。实际上当前工程中最常见的是 AI 与既有测试框架结合提升用例生成效率、定位稳定性、断言准确性和数据分析能力。下面是 AI 自动化测试中常见的几个能力方向能力方向常用工具 / 技术主要解决什么问题难度接口自动化测试Python requests pytest后端接口回归、参数校验、契约测试低UI 自动化测试Selenium、PlaywrightWeb 端界面回归、端到端主流程验证中移动端自动化测试Appium、AirtestApp 功能回归、跨版本兼容验证中高AI 辅助测试用例生成大模型 提示词工程快速生成正常和异常场景测试用例中AI 智能元素定位大模型 Playwright / 视觉模型弱化前端变更带来的 selector 维护成本中高AI 智能断言大模型语义判断对模糊、自然语言类返回结果做准确性判断中测试数据生成大模型 Faker批量构造符合规则的测试数据低CI/CD 集成Jenkins、GitLab CI、Docker自动化执行、质量门禁、报告归档中从就业角度看最容易快速上手的是接口自动化测试这也是大多数自动化测试岗位面试中的必考项。UI 自动化适合系统学习后作为项目亮点展示。AI 辅助测试则可以作为差异化优势帮你回答“你了解 AI 在测试中的应用吗”这类开放题。需要提醒的是不要把“2026 最强”这类宣传语当成选型标准。软件测试领域的工具迭代速度没有互联网标题那么快pytest、requests、Selenium、Playwright、Appium 这些基础设施仍然是当前岗位的主要技术要求AI 是在它们之上做增强而不是替代。2. 适用场景与使用边界AI 自动化测试适合解决哪些问题最典型的是回归测试。比如一个系统每次发布前都要重复验证登录、下单、支付、查询等核心流程人工回归成本高自动化测试可以反复执行并把结果汇总到报告中。接口自动化测试适合前后端分离的项目。后端接口稳定后前端界面还在频繁调整此时先对接口做自动化覆盖成本低且反馈快。UI 自动化适合验证主流程是否通畅、关键页面是否正常展示以及跨浏览器兼容性。AI 辅助测试适合在两类场景中落地测试用例生成。大模型可以根据需求描述、接口文档或历史缺陷输出覆盖正常流程、边界条件、异常输入的测试用例。生成结果需要人工评审后转换成自动化脚本。智能断言与异常处理。比如页面出现非预期弹窗导致脚本失败可以设计兜底逻辑识别并关闭弹窗接口返回自然语言描述时可以借助大模型判断是否符合预期。但这个方向也有明确边界。AI 不能完全替代人工测试因为很多业务规则、用户体验问题和隐性需求仍然依赖人来判断。AI 生成的测试用例也存在误导性如果不加限制直接执行可能导致大量误报或无效用例。更稳妥的做法是让 AI 生成初稿由测试人员审核并补充边界条件。这里还要强调数据安全与版权边界。做接口自动化测试时应该使用测试环境的数据不要直接往生产环境写入大量压测数据。涉及用户手机号、身份证号、地址等个人信息时需要脱敏处理。使用大模型生成测试数据或代码时不要把包含敏感信息的业务数据直接放进提示词如果需要使用第三方大模型 API更要注意数据对外传输的风险。涉及商业系统的分享、截图、录制时应确认是否允许公开。3. 零基础学习路线与环境准备零基础入门 AI 自动化测试不建议一上来就研究复杂框架。更稳的路线是先掌握 Python 基础再学接口自动化接着学 UI 自动化然后引入 AI 辅助能力最后把整套项目接入 CI。Python 基础阶段需要掌握变量、数据类型、条件判断、循环、函数、文件读写、异常处理、类和模块化。不需要学很深的数据结构与算法但代码阅读能力和简单脚本能力必须过关。之后学习 requests 库发 HTTP 请求、pytest 组织测试用例、断言与 fixture、数据驱动、Allure 报告。UI 自动化阶段Selenium 是经典选择资料多Playwright 是当前团队更常用的选择自带自动等待和录制功能对新手更友好。移动端自动化可以放到工作后按需学习零基础求职阶段不是必选项。AI 辅助阶段重点不是训练模型而是学会使用提示词。你可以用 OpenAI、DeepSeek、Qwen 等通用大模型也可以用本地部署的开源模型。关键在于设计结构化提示词让大模型输出格式稳定的测试用例。环境准备方面需要准备一台普通电脑即可不需要高配 GPU。操作系统建议 Windows 10/11、macOS 或 Ubuntu 都是常见选择。核心软件包括Python 3.9 以上版本。Git用于代码版本管理。VS Code 或 PyCharm。PyCharm 有大量 AI 插件可以辅助补全代码和生成注释。一个可用的浏览器例如 Chrome 或 Edge。本地或远程的测试环境用于跑接口和页面测试。下面是一份基础 requirements.txt安装最新版本即可pytest requests allure-pytest python-dotenv pyyaml playwright pytest-xdist pytest-rerunfailures安装命令pip install -r requirements.txt # 安装 Playwright 浏览器内核 playwright install chromium如果 pip 下载速度慢可以临时切换到国内镜像pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple安装完成后建议初始化一个项目目录后续所有实战内容都放在这个目录里auto_test_project/ ├── config/ │ ├── settings.yaml │ └── .env ├── tests/ │ ├── api/ │ ├── ui/ │ └── conftest.py ├── data/ ├── utils/ ├── reports/ ├── requirements.txt └── pytest.inipytest.ini 可以先配置基础选项[pytest] testpaths tests addopts -v --alluredir./reports/allure-results这样执行 pytest 时会自动收集 tests 目录下的用例并把 Allure 结果输出到固定目录。4. 实战项目一接口自动化测试框架搭建接口自动化测试是 AI 自动化测试中最值得先学的部分。原因是成本低、见效快、面试中高频出现。这里搭建一个小而完整的接口自动化测试框架包含配置管理、请求封装、测试用例、数据驱动、报告输出。先创建 config/settings.yaml保存测试环境地址和公共参数base_url: http://127.0.0.1:8080 timeout: 15 headers: Content-Type: application/json然后封装一个简单的请求客户端放在 utils/http_client.pyimport requests import yaml with open(config/settings.yaml, r, encodingutf-8) as f: settings yaml.safe_load(f) class HttpClient: def __init__(self): self.base_url settings[base_url] self.timeout settings[timeout] self.session requests.Session() def request(self, method, path, **kwargs): url f{self.base_url}{path} kwargs.setdefault(timeout, self.timeout) kwargs.setdefault(headers, settings.get(headers, {})) response self.session.request(method, url, **kwargs) return response def get(self, path, **kwargs): return self.request(GET, path, **kwargs) def post(self, path, **kwargs): return self.request(POST, path, **kwargs)接着在 tests/conftest.py 中定义公共 fixtureimport pytest from utils.http_client import HttpClient pytest.fixture(scopesession) def client(): return HttpClient()现在写一个登录接口的测试用例放在 tests/api/test_login.pyimport pytest def test_login_success(client): resp client.post(/api/login, json{ username: tester, password: 123456 }) assert resp.status_code 200 data resp.json() assert data.get(token) is not None def test_login_wrong_password(client): resp client.post(/api/login, json{ username: tester, password: wrong }) assert resp.status_code in (200, 401) assert resp.json().get(token) is None这是最基础的版本。实际项目中建议加入数据驱动把测试数据放到 data/login_cases.yaml- case: 正常登录 username: tester password: 123456 expect_code: 200 expect_token: true - case: 密码错误 username: tester password: wrong expect_code: 401 expect_token: false然后通过 pytest 的 parametrize 读取 YAML 数据。这样后续增加用例时只需要添加数据不需要新增代码。执行测试pytest tests/api -n 2 --reruns 1这里-n 2是并行执行--reruns 1是失败重试一次。并行和重试是面试中常提到的稳定性手段也是实际项目的常见实践。测试完成后查看 Allure 报告allure serve reports/allure-results这个框架虽然小但已经覆盖了配置管理、请求封装、公共 fixture、数据驱动、并行执行、失败重试和报告展示。把它吃透再去扩展 Java 接口自动化测试框架时思想是相通的只是把 pytest 换成 TestNG/JUnit把 requests 换成 RestAssured 或 HttpClient。5. 实战项目二UI 自动化测试与 AI 元素定位UI 自动化测试的难点不在怎么写脚本而在如何稳定维护。传统的 Selenium 需要写大量显式等待和 sleep脚本很容易因为前端组件变化而挂掉。Playwright 自带自动等待逻辑并且可以录制操作生成脚本对新手更友好。先看一个最典型的登录流程测试使用 Playwright 的同步 APIfrom playwright.sync_api import sync_playwright def test_login(): with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.goto(http://127.0.0.1:8080/login) page.fill(#username, tester) page.fill(#password, 123456) page.click(button[typesubmit]) page.wait_for_selector(.user-info) assert tester in page.inner_text(.user-info) browser.close()这段代码虽然可以跑但布局选择器很容易失效。工程中建议给前端关键元素加稳定的>input>page.get_by_test_id(login-username).fill(tester)选择器更稳定前端样式改动不会影响测试脚本。除了稳定的选择器实际 Web 自动化最头疼的问题是“非预期弹窗导致失败”。比如活动弹窗、广告浮层、Cookie 同意框在没有人点击时突然出现把按钮遮住脚本直接报错。这种问题在热词里被反复提到说明它确实是高频痛点。针对性方案是做一个通用兜底函数在每次操作前检测常见弹窗文本一旦出现就尝试关闭。这里给出一个简化版POPUP_MARKERS [我知道了, 确定, 关闭, 知道了, 好] def close_unexpected_popup(page): for marker in POPUP_MARKERS: btn page.locator(fbutton:has-text({marker})) if btn.count() 0 and btn.first.is_visible(): btn.first.click() page.wait_for_timeout(300) return True return False调用方式也很简单在关键点击之前执行一次close_unexpected_popup(page) page.click(button[typesubmit])要注意这种弹窗兜底只能作为辅助手段。真正稳定可靠的 UI 自动化必须满足两个条件前端提供稳定的数据标识测试环境关闭不必要的弹窗或埋点。靠脚本去适应混乱环境成本会持续走高。那 AI 元素定位怎么加入常规做法是让大模型辅助分析页面源码或截图。例如页面结构变化后旧的 CSS 选择器失效你可以把一段 HTML 片段发给大模型自动生成新的 Playwright 定位表达式。大模型输出结果需要人工确认不能直接无脑替换。另外也可以结合视觉回归工具对不同版本截图做像素级对比定位界面偏移。这个概念叫智能视觉回归测试适合页面布局、样式频繁调整的项目。主流工具有 Applitools 等商业产品也有开源的 image comparison 方案。6. 实战项目三AI 辅助生成测试用例与智能断言AI 在测试中最容易落地的场景是测试用例生成。这里不是让大模型生成一段完整的自动化脚本而是先生成测试用例再人工转成 pytest 用例效率会高很多。设计提示词时最关键的是输出格式约束。如果只写一句“帮我想一些测试用例”大模型会输出一大段无法解析的文本。更好的方式是限定输出为 Markdown 表格并且指定字段你是资深测试工程师请根据以下接口需求生成测试用例 接口POST /api/login 参数usernamepassword 说明登录成功后返回 token密码错误返回 401用户名不存在返回 404参数缺失返回 400。 要求 1. 覆盖正常登录、密码错误、用户名不存在、参数缺失、空字符串、超长字符串。 2. 输出 Markdown 表格字段为用例编号、前置条件、请求参数、预期结果。 只输出表格不要输出解释。这种提示词输出的结果稍作整理就能直接转成 pytest 的参数化数据。为了拿到更稳定的输出可以把示例也写进提示词里做 one-shot 或 few-shot 示范。另一个 AI 应用方向是智能断言。传统断言主要是代码层面的比较比如assert resp.status_code 200。但有些接口返回的是自然语言提示或者结果语义正确但具体文案经常变动这时候就可以让大模型判断结果是否符合预期。给出一个简化思路把接口响应文本和期望描述拼成提示词让大模型输出 PASS 或 FAIL并给出简短原因。由于调用模型会有延迟和成本不建议对每个接口都做智能断言只建议在传统断言难以表达的场景使用。AI 生成测试数据也比较有用。比如需要批量构造一批符合手机号格式、身份证格式、邮箱格式的测试数据可以直接用大模型生成规则也可以用 Faker 库实现from faker import Faker fake Faker(zh_CN) for _ in range(10): print(fake.phone_number(), fake.email(), fake.name())在真实测试环境中这些数据要确保不涉及真实用户隐私。如果大模型参与生成还要关注生成内容是否包含不当信息。这里必须强调安全边界不要直接让 AI 生成生产环境的增删改查脚本然后无审核执行。AI 生成的用例和代码必须经过人工 review尤其要注意权限边界、数据清洗、敏感信息处理和异常恢复。自动化测试的理想状态是发现问题而不是制造数据事故。7. 自动化测试接入 CI 与批量执行本地能跑通的测试价值有限。真正体现工程能力的是把测试接入 CI让代码提交后自动触发测试并把结果反馈给团队。这样自动化测试才能从“能跑”变成“能用”。常见的 CI 系统有 Jenkins、GitLab CI、GitHub Actions。这里以 GitLab CI 为例给一个简化配置。测试阶段安装依赖、执行 pytest、上传 Allure 结果。stages: - test api-test: stage: test script: - pip install -r requirements.txt - pytest tests/api -n 2 --reruns 1 --alluredir./reports/allure-results artifacts: when: always paths: - reports/allure-results expire_in: 7 daysGitLab CI 中artifacts 是测试报告和失败截图的关键。无论测试是否通过都应该把报告保存下来方便团队分析。如果项目组使用 Jenkins可以在构建步骤中执行同样的命令再配合 Allure Jenkins 插件自动生成报告页面。批量任务的另一个维度是测试数据量与执行规模。接口自动化常见做法是准备测试环境启动服务后用 pytest 批量执行几百条数据驱动用例。UI 自动化则适合按业务模块分组比如登录、商品搜索、购物车、订单流程各一个文件分别执行失败后重试。执行策略建议接口自动化可以并行跑提高速度。UI 自动化尽量串行避免多个浏览器抢同一测试账号或互相影响。每个用例尽量幂等即无论重复执行多少次结果一致。测试账号要隔离不要多个用例同时操作同一个账号否则会出现偶发失败。CI 环境中还要注意端口冲突和进程残留问题。如果测试服务端口被占用可以通过lsof -i :8080或netstat -ano | findstr 8080查看进程并替换端口。测试结束后浏览器进程需要可靠关闭避免 CI 机器资源耗尽。接入 CI 后通常还要设计失败通知。简单的做法是在 CI 结果中集成企业微信、钉钉、飞书机器人 webhook测试失败时自动发送通知。这样团队成员不需要每天打开 CI 页面收到通知后直接看失败用例和日志。8. 常见问题与排查方法在学习和实战过程中很多问题并不是代码逻辑错误而是环境、依赖、浏览器驱动、端口冲突、数据不稳定导致。下面整理一份高频问题排查表。问题现象可能原因排查方式解决方案pip 安装依赖失败Python 版本过低或网络源不稳定查看错误日志确认 Python 版本升级 Python切换国内镜像源Playwright 无法启动浏览器浏览器内核未安装或系统缺少依赖执行playwright install chromium安装内核并安装系统依赖接口测试偶发失败依赖上游接口数据或网络超时查看请求日志和响应码增加重试机制准备稳定的测试环境UI 元素定位不到前端版本更新导致 selector 失效打开 DevTools 校验选择器使用> AI+自动化测试实战：从接口到UI再到CI的完整工程链路
如果你最近在找 AI 和自动化测试相关的学习资料大概率刷到过类似“2026 最强 AI 自动化测试完整版实战教程”的标题。这种标题最大的问题不是内容差而是它把学习过程压缩成了“看完一套视频就能就业”的幻想。真正能落地的路径是一条由接口自动化、UI 自动化、AI 辅助测试、CI 集成和项目实战组成的工程链路而不是某个单一工具的速成演示。这篇文章默认读者有三类零基础想转自动化测试的人、已经在做功能测试想升级测试开发的人、想搞清楚 AI 辅助测试到底是不是噱头的人。我不会去复刻课程目录而是按“学什么、怎么搭、怎么测、怎么接入 CI、怎么准备面试”的顺序把 AI 在自动化测试里真正能落地的几个方向拆开并给出一套可以直接改着用的项目骨架。先说结论AI 自动化测试不是某一个具体工具而是一套组合能力。底层是 Python 编程、接口自动化、UI 自动化、移动端自动化的基本功上层是用大模型做测试用例生成、智能断言、元素定位辅助、异常弹窗兜底和测试数据生成。基本功不稳AI 只是让坏代码写得更快。所以这篇文章虽然也会讲大模型辅助测试但大部分篇幅仍然放在测试工程本身。1. AI 自动化测试核心能力速览很多刚接触这个领域的人会把“AI 自动化测试”理解成“用 AI 代替测试人员”。实际上当前工程中最常见的是 AI 与既有测试框架结合提升用例生成效率、定位稳定性、断言准确性和数据分析能力。下面是 AI 自动化测试中常见的几个能力方向能力方向常用工具 / 技术主要解决什么问题难度接口自动化测试Python requests pytest后端接口回归、参数校验、契约测试低UI 自动化测试Selenium、PlaywrightWeb 端界面回归、端到端主流程验证中移动端自动化测试Appium、AirtestApp 功能回归、跨版本兼容验证中高AI 辅助测试用例生成大模型 提示词工程快速生成正常和异常场景测试用例中AI 智能元素定位大模型 Playwright / 视觉模型弱化前端变更带来的 selector 维护成本中高AI 智能断言大模型语义判断对模糊、自然语言类返回结果做准确性判断中测试数据生成大模型 Faker批量构造符合规则的测试数据低CI/CD 集成Jenkins、GitLab CI、Docker自动化执行、质量门禁、报告归档中从就业角度看最容易快速上手的是接口自动化测试这也是大多数自动化测试岗位面试中的必考项。UI 自动化适合系统学习后作为项目亮点展示。AI 辅助测试则可以作为差异化优势帮你回答“你了解 AI 在测试中的应用吗”这类开放题。需要提醒的是不要把“2026 最强”这类宣传语当成选型标准。软件测试领域的工具迭代速度没有互联网标题那么快pytest、requests、Selenium、Playwright、Appium 这些基础设施仍然是当前岗位的主要技术要求AI 是在它们之上做增强而不是替代。2. 适用场景与使用边界AI 自动化测试适合解决哪些问题最典型的是回归测试。比如一个系统每次发布前都要重复验证登录、下单、支付、查询等核心流程人工回归成本高自动化测试可以反复执行并把结果汇总到报告中。接口自动化测试适合前后端分离的项目。后端接口稳定后前端界面还在频繁调整此时先对接口做自动化覆盖成本低且反馈快。UI 自动化适合验证主流程是否通畅、关键页面是否正常展示以及跨浏览器兼容性。AI 辅助测试适合在两类场景中落地测试用例生成。大模型可以根据需求描述、接口文档或历史缺陷输出覆盖正常流程、边界条件、异常输入的测试用例。生成结果需要人工评审后转换成自动化脚本。智能断言与异常处理。比如页面出现非预期弹窗导致脚本失败可以设计兜底逻辑识别并关闭弹窗接口返回自然语言描述时可以借助大模型判断是否符合预期。但这个方向也有明确边界。AI 不能完全替代人工测试因为很多业务规则、用户体验问题和隐性需求仍然依赖人来判断。AI 生成的测试用例也存在误导性如果不加限制直接执行可能导致大量误报或无效用例。更稳妥的做法是让 AI 生成初稿由测试人员审核并补充边界条件。这里还要强调数据安全与版权边界。做接口自动化测试时应该使用测试环境的数据不要直接往生产环境写入大量压测数据。涉及用户手机号、身份证号、地址等个人信息时需要脱敏处理。使用大模型生成测试数据或代码时不要把包含敏感信息的业务数据直接放进提示词如果需要使用第三方大模型 API更要注意数据对外传输的风险。涉及商业系统的分享、截图、录制时应确认是否允许公开。3. 零基础学习路线与环境准备零基础入门 AI 自动化测试不建议一上来就研究复杂框架。更稳的路线是先掌握 Python 基础再学接口自动化接着学 UI 自动化然后引入 AI 辅助能力最后把整套项目接入 CI。Python 基础阶段需要掌握变量、数据类型、条件判断、循环、函数、文件读写、异常处理、类和模块化。不需要学很深的数据结构与算法但代码阅读能力和简单脚本能力必须过关。之后学习 requests 库发 HTTP 请求、pytest 组织测试用例、断言与 fixture、数据驱动、Allure 报告。UI 自动化阶段Selenium 是经典选择资料多Playwright 是当前团队更常用的选择自带自动等待和录制功能对新手更友好。移动端自动化可以放到工作后按需学习零基础求职阶段不是必选项。AI 辅助阶段重点不是训练模型而是学会使用提示词。你可以用 OpenAI、DeepSeek、Qwen 等通用大模型也可以用本地部署的开源模型。关键在于设计结构化提示词让大模型输出格式稳定的测试用例。环境准备方面需要准备一台普通电脑即可不需要高配 GPU。操作系统建议 Windows 10/11、macOS 或 Ubuntu 都是常见选择。核心软件包括Python 3.9 以上版本。Git用于代码版本管理。VS Code 或 PyCharm。PyCharm 有大量 AI 插件可以辅助补全代码和生成注释。一个可用的浏览器例如 Chrome 或 Edge。本地或远程的测试环境用于跑接口和页面测试。下面是一份基础 requirements.txt安装最新版本即可pytest requests allure-pytest python-dotenv pyyaml playwright pytest-xdist pytest-rerunfailures安装命令pip install -r requirements.txt # 安装 Playwright 浏览器内核 playwright install chromium如果 pip 下载速度慢可以临时切换到国内镜像pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple安装完成后建议初始化一个项目目录后续所有实战内容都放在这个目录里auto_test_project/ ├── config/ │ ├── settings.yaml │ └── .env ├── tests/ │ ├── api/ │ ├── ui/ │ └── conftest.py ├── data/ ├── utils/ ├── reports/ ├── requirements.txt └── pytest.inipytest.ini 可以先配置基础选项[pytest] testpaths tests addopts -v --alluredir./reports/allure-results这样执行 pytest 时会自动收集 tests 目录下的用例并把 Allure 结果输出到固定目录。4. 实战项目一接口自动化测试框架搭建接口自动化测试是 AI 自动化测试中最值得先学的部分。原因是成本低、见效快、面试中高频出现。这里搭建一个小而完整的接口自动化测试框架包含配置管理、请求封装、测试用例、数据驱动、报告输出。先创建 config/settings.yaml保存测试环境地址和公共参数base_url: http://127.0.0.1:8080 timeout: 15 headers: Content-Type: application/json然后封装一个简单的请求客户端放在 utils/http_client.pyimport requests import yaml with open(config/settings.yaml, r, encodingutf-8) as f: settings yaml.safe_load(f) class HttpClient: def __init__(self): self.base_url settings[base_url] self.timeout settings[timeout] self.session requests.Session() def request(self, method, path, **kwargs): url f{self.base_url}{path} kwargs.setdefault(timeout, self.timeout) kwargs.setdefault(headers, settings.get(headers, {})) response self.session.request(method, url, **kwargs) return response def get(self, path, **kwargs): return self.request(GET, path, **kwargs) def post(self, path, **kwargs): return self.request(POST, path, **kwargs)接着在 tests/conftest.py 中定义公共 fixtureimport pytest from utils.http_client import HttpClient pytest.fixture(scopesession) def client(): return HttpClient()现在写一个登录接口的测试用例放在 tests/api/test_login.pyimport pytest def test_login_success(client): resp client.post(/api/login, json{ username: tester, password: 123456 }) assert resp.status_code 200 data resp.json() assert data.get(token) is not None def test_login_wrong_password(client): resp client.post(/api/login, json{ username: tester, password: wrong }) assert resp.status_code in (200, 401) assert resp.json().get(token) is None这是最基础的版本。实际项目中建议加入数据驱动把测试数据放到 data/login_cases.yaml- case: 正常登录 username: tester password: 123456 expect_code: 200 expect_token: true - case: 密码错误 username: tester password: wrong expect_code: 401 expect_token: false然后通过 pytest 的 parametrize 读取 YAML 数据。这样后续增加用例时只需要添加数据不需要新增代码。执行测试pytest tests/api -n 2 --reruns 1这里-n 2是并行执行--reruns 1是失败重试一次。并行和重试是面试中常提到的稳定性手段也是实际项目的常见实践。测试完成后查看 Allure 报告allure serve reports/allure-results这个框架虽然小但已经覆盖了配置管理、请求封装、公共 fixture、数据驱动、并行执行、失败重试和报告展示。把它吃透再去扩展 Java 接口自动化测试框架时思想是相通的只是把 pytest 换成 TestNG/JUnit把 requests 换成 RestAssured 或 HttpClient。5. 实战项目二UI 自动化测试与 AI 元素定位UI 自动化测试的难点不在怎么写脚本而在如何稳定维护。传统的 Selenium 需要写大量显式等待和 sleep脚本很容易因为前端组件变化而挂掉。Playwright 自带自动等待逻辑并且可以录制操作生成脚本对新手更友好。先看一个最典型的登录流程测试使用 Playwright 的同步 APIfrom playwright.sync_api import sync_playwright def test_login(): with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.goto(http://127.0.0.1:8080/login) page.fill(#username, tester) page.fill(#password, 123456) page.click(button[typesubmit]) page.wait_for_selector(.user-info) assert tester in page.inner_text(.user-info) browser.close()这段代码虽然可以跑但布局选择器很容易失效。工程中建议给前端关键元素加稳定的>input>page.get_by_test_id(login-username).fill(tester)选择器更稳定前端样式改动不会影响测试脚本。除了稳定的选择器实际 Web 自动化最头疼的问题是“非预期弹窗导致失败”。比如活动弹窗、广告浮层、Cookie 同意框在没有人点击时突然出现把按钮遮住脚本直接报错。这种问题在热词里被反复提到说明它确实是高频痛点。针对性方案是做一个通用兜底函数在每次操作前检测常见弹窗文本一旦出现就尝试关闭。这里给出一个简化版POPUP_MARKERS [我知道了, 确定, 关闭, 知道了, 好] def close_unexpected_popup(page): for marker in POPUP_MARKERS: btn page.locator(fbutton:has-text({marker})) if btn.count() 0 and btn.first.is_visible(): btn.first.click() page.wait_for_timeout(300) return True return False调用方式也很简单在关键点击之前执行一次close_unexpected_popup(page) page.click(button[typesubmit])要注意这种弹窗兜底只能作为辅助手段。真正稳定可靠的 UI 自动化必须满足两个条件前端提供稳定的数据标识测试环境关闭不必要的弹窗或埋点。靠脚本去适应混乱环境成本会持续走高。那 AI 元素定位怎么加入常规做法是让大模型辅助分析页面源码或截图。例如页面结构变化后旧的 CSS 选择器失效你可以把一段 HTML 片段发给大模型自动生成新的 Playwright 定位表达式。大模型输出结果需要人工确认不能直接无脑替换。另外也可以结合视觉回归工具对不同版本截图做像素级对比定位界面偏移。这个概念叫智能视觉回归测试适合页面布局、样式频繁调整的项目。主流工具有 Applitools 等商业产品也有开源的 image comparison 方案。6. 实战项目三AI 辅助生成测试用例与智能断言AI 在测试中最容易落地的场景是测试用例生成。这里不是让大模型生成一段完整的自动化脚本而是先生成测试用例再人工转成 pytest 用例效率会高很多。设计提示词时最关键的是输出格式约束。如果只写一句“帮我想一些测试用例”大模型会输出一大段无法解析的文本。更好的方式是限定输出为 Markdown 表格并且指定字段你是资深测试工程师请根据以下接口需求生成测试用例 接口POST /api/login 参数usernamepassword 说明登录成功后返回 token密码错误返回 401用户名不存在返回 404参数缺失返回 400。 要求 1. 覆盖正常登录、密码错误、用户名不存在、参数缺失、空字符串、超长字符串。 2. 输出 Markdown 表格字段为用例编号、前置条件、请求参数、预期结果。 只输出表格不要输出解释。这种提示词输出的结果稍作整理就能直接转成 pytest 的参数化数据。为了拿到更稳定的输出可以把示例也写进提示词里做 one-shot 或 few-shot 示范。另一个 AI 应用方向是智能断言。传统断言主要是代码层面的比较比如assert resp.status_code 200。但有些接口返回的是自然语言提示或者结果语义正确但具体文案经常变动这时候就可以让大模型判断结果是否符合预期。给出一个简化思路把接口响应文本和期望描述拼成提示词让大模型输出 PASS 或 FAIL并给出简短原因。由于调用模型会有延迟和成本不建议对每个接口都做智能断言只建议在传统断言难以表达的场景使用。AI 生成测试数据也比较有用。比如需要批量构造一批符合手机号格式、身份证格式、邮箱格式的测试数据可以直接用大模型生成规则也可以用 Faker 库实现from faker import Faker fake Faker(zh_CN) for _ in range(10): print(fake.phone_number(), fake.email(), fake.name())在真实测试环境中这些数据要确保不涉及真实用户隐私。如果大模型参与生成还要关注生成内容是否包含不当信息。这里必须强调安全边界不要直接让 AI 生成生产环境的增删改查脚本然后无审核执行。AI 生成的用例和代码必须经过人工 review尤其要注意权限边界、数据清洗、敏感信息处理和异常恢复。自动化测试的理想状态是发现问题而不是制造数据事故。7. 自动化测试接入 CI 与批量执行本地能跑通的测试价值有限。真正体现工程能力的是把测试接入 CI让代码提交后自动触发测试并把结果反馈给团队。这样自动化测试才能从“能跑”变成“能用”。常见的 CI 系统有 Jenkins、GitLab CI、GitHub Actions。这里以 GitLab CI 为例给一个简化配置。测试阶段安装依赖、执行 pytest、上传 Allure 结果。stages: - test api-test: stage: test script: - pip install -r requirements.txt - pytest tests/api -n 2 --reruns 1 --alluredir./reports/allure-results artifacts: when: always paths: - reports/allure-results expire_in: 7 daysGitLab CI 中artifacts 是测试报告和失败截图的关键。无论测试是否通过都应该把报告保存下来方便团队分析。如果项目组使用 Jenkins可以在构建步骤中执行同样的命令再配合 Allure Jenkins 插件自动生成报告页面。批量任务的另一个维度是测试数据量与执行规模。接口自动化常见做法是准备测试环境启动服务后用 pytest 批量执行几百条数据驱动用例。UI 自动化则适合按业务模块分组比如登录、商品搜索、购物车、订单流程各一个文件分别执行失败后重试。执行策略建议接口自动化可以并行跑提高速度。UI 自动化尽量串行避免多个浏览器抢同一测试账号或互相影响。每个用例尽量幂等即无论重复执行多少次结果一致。测试账号要隔离不要多个用例同时操作同一个账号否则会出现偶发失败。CI 环境中还要注意端口冲突和进程残留问题。如果测试服务端口被占用可以通过lsof -i :8080或netstat -ano | findstr 8080查看进程并替换端口。测试结束后浏览器进程需要可靠关闭避免 CI 机器资源耗尽。接入 CI 后通常还要设计失败通知。简单的做法是在 CI 结果中集成企业微信、钉钉、飞书机器人 webhook测试失败时自动发送通知。这样团队成员不需要每天打开 CI 页面收到通知后直接看失败用例和日志。8. 常见问题与排查方法在学习和实战过程中很多问题并不是代码逻辑错误而是环境、依赖、浏览器驱动、端口冲突、数据不稳定导致。下面整理一份高频问题排查表。问题现象可能原因排查方式解决方案pip 安装依赖失败Python 版本过低或网络源不稳定查看错误日志确认 Python 版本升级 Python切换国内镜像源Playwright 无法启动浏览器浏览器内核未安装或系统缺少依赖执行playwright install chromium安装内核并安装系统依赖接口测试偶发失败依赖上游接口数据或网络超时查看请求日志和响应码增加重试机制准备稳定的测试环境UI 元素定位不到前端版本更新导致 selector 失效打开 DevTools 校验选择器使用>