很多测试同学拿到 AI 写好的 pytest 脚本后第一反应是“代码长得挺像样跑起来却哪哪都不对”。定位符不稳定、不知道被测页面真实结构、失败之后只能把报错复制进对话框反复问模型来回几次已经没有耐心。问题本质不是模型能力不够而是整个工作链路缺了三样东西一套靠谱的测试执行框架、一套能让 AI 记住项目规范的“操作手册”、一条让 AI 直接看到真实页面的通道。这套链路就是 Pytest Skills MCP。本文将围绕“AI 玩转 WEB 自动化”这个目标用 90 分钟带你跑通一套闭环方案。你会看到如何用 Pytest 组织浏览器自动化用例如何用 Skill 让 AI 遵守团队规范如何用 MCP 让 AI 打开浏览器、查看真实页面、执行 pytest 并自动修正代码。整个过程不炒概念直接给命令、给代码、给配置也把容易踩的坑说明白。通过本文你将能独立搭建一套 AI 辅助 WEB 自动化环境让 AI 不只停留在“生成一段用例代码”而是真正参与“写代码 - 运行 - 看结果 - 修问题 - 回归”的完整循环。这套方法同样适合接口自动化、UI 冒烟测试、回归测试等场景。1. 背景与核心概念1.1 为什么 WEB 自动化需要 AI 辅助传统 WEB 自动化测试通常用 Selenium、Playwright 这类工具写浏览器操作脚本。脚本本身不难真正花时间的是三点元素定位、等待策略、用例维护。页面结构一改定位符就要跟着改接口返回变慢等待时间又要重新调测试数据不干净用例就直接红。AI 辅助测试的目标是让大模型帮我们处理这些重复劳动。AI 可以根据自然语言描述生成用例、根据失败日志修改定位符、根据页面 DOM 调整断言。但这里有个前提AI 必须掌握足够多关于你项目的上下文。它要知道被测系统的 URL、登录方式、关键业务路径、元素定位习惯、断言规范、运行命令是什么。这些信息如果都靠每次对话重复输入效率极低。Skills 和 MCP 正好解决这个问题。Skills 把“怎么写这个项目的自动化用例”沉淀成规范文档MCP 把“打开浏览器看页面”“执行 pytest 命令”变成 AI 可以直接调用的工具。两者组合在一起AI 才真正像一个熟悉项目的测试开发。1.2 三个名词到底是什么意思Pytest是 Python 生态里最常用的测试框架。它负责用例发现、用例执行、断言、fixture 管理、报告输出。在 WEB 自动化场景中它扮演的是“执行引擎”。你可以把测试脚本交给 pytestpytest 会找到以test_开头的函数或Test开头的类按顺序执行并输出通过或失败的结果。Skills在 AI 编程助手语境下是一组预先定义好的能力包。通常表现为一个目录目录里包含SKILL.md说明文件和若干辅助脚本。这个说明文件告诉模型在什么场景下使用这个技能、执行步骤是什么、代码风格是什么、有哪些注意事项。Skills 的价值是把项目经验、团队规范、最佳实践固化下来AI 在生成代码时自动参考不再每次从零推理。MCP全称 Model Context Protocol模型上下文协议。它解决的是“AI 怎么与外部工具通信”的问题。MCP 采用 C/S 架构AI 应用作为客户端工具服务作为 Server。Server 可以暴露“打开浏览器”“获取网页结构”“执行命令”等能力。AI 可以像调用函数一样使用这些能力。MCP 相当于给 AI 加了眼睛和手解决了“模型看不到真实页面”的痛点。1.3 Agent Skill 和 MCP 有什么区别很多同学看到 Skill 和 MCP 同时出现容易混淆。两者并不冲突它们工作的层级不同。维度SkillMCP本质一套指令与规范一套通信协议作用对象指导 AI 如何思考和组织代码让 AI 连接外部工具与数据主要载体Markdown 文档、脚本、模板MCP Server 程序举个例子告诉 AI 优先用get_by_role定位元素等待用expect而不是time.sleep提供一个open_browser工具AI 调用它就能打开浏览器关系Skill 决定“怎么做更规范”MCP 决定“能做什么事”实际项目中两者经常配合使用。Skill 告诉 AI“写这套代码要遵守哪些约定”MCP 提供工具让 AI“真正运行代码、看真实页面”。后面实战环节会完整展示这个配合方式。2. 环境准备与项目结构2.1 依赖清单假设本地环境是 Windows 或 macOSPython 版本建议 3.10 及以上。在开始前先确认 Python 能正常使用python --version pip --version如果还没有 Python 环境建议安装 3.11 或 3.12 的稳定版本。Windows 用户安装时记得勾选“Add Python to PATH”避免后续命令找不到。接下来准备以下核心组件组件作用pytest测试执行框架playwright浏览器自动化库pytest-playwright可选的 pytest 插件提供 page fixtureruff可选用于代码格式检查node / npx运行 Playwright MCP Server部分 AI 客户端需要版本说明不同版本的 pytest 和 playwright 接口略有差异本文示例以当前主流版本为准配置思路通用。如果后续接口有变化以官方文档为准即可。2.2 安装 Python 依赖在项目目录创建虚拟环境是推荐做法避免污染全局环境mkdir ai-web-test cd ai-web-test python -m venv .venvWindows 激活虚拟环境.venv\Scripts\activatemacOS / Linux 激活虚拟环境source .venv/bin/activate激活后安装依赖pip install pytest playwright pytest-playwright安装完成后下载浏览器内核。Playwright 不像 Selenium 需要单独下载驱动它直接管理浏览器内核playwright install chromium如果你需要测试 Chrome 的完整行为也可以安装playwright install chrome下载时间取决于网络环境耐心等待即可。下载完成后可以快速验证playwright --version如果输出版本号说明安装成功。2.3 项目结构设计一个结构清晰的自动化项目不仅方便人读也方便 AI 理解。推荐下面的目录结构ai-web-test/ ├── .venv/ # 虚拟环境 ├── pages/ # 页面对象层 │ ├── __init__.py │ └── login_page.py ├── tests/ # 测试用例目录 │ ├── __init__.py │ ├── conftest.py # pytest 夹具配置 │ └── test_search.py ├── skills/ # 自定义 Skills 目录 │ └── web-test-skill/ │ └── SKILL.md ├── mcp/ # 自定义 MCP Server 目录 │ └── pytest_server.py ├── pytest.ini # pytest 配置 └── requirements.txt # 依赖清单页面对象层不是必须的但对于业务相对复杂的项目能显著降低维护成本。后面在实战中会用到页面对象让代码更好维护。3. 核心知识pytest fixture、Skills 与 MCP 的工作方式3.1 pytest fixture 怎么支撑浏览器用例在 pytest 中fixture 是一种依赖注入机制。你可以在 fixture 里创建资源测试函数通过参数引用它。pytest 会自动管理生命周期。以 Playwright 为例最简单的浏览器 fixture 如下# 文件路径tests/conftest.py import pytest from playwright.sync_api import sync_playwright pytest.fixture(scopefunction) def page(): with sync_playwright() as p: browser p.chromium.launch( headlessFalse, slow_mo200, ) context browser.new_context() page context.new_page() yield page context.close() browser.close()这里的关键点scopefunction表示每个测试函数都创建一套全新浏览器环境保证用例隔离。headlessFalse启动有头浏览器方便观察操作过程。slow_mo200让每一步操作停顿 200 毫秒便于看到执行过程调试时可以配大一点。yield page之后的代码在用例执行完成后运行用于资源清理。如果安装了pytest-playwright插件其实自带page、browser、context等 fixture不需要自己手写。但理解底层原理很重要排错时才知道是浏览器问题还是 pytest 问题。3.2 Skill 的工作方式与目录规范以常见的编程助手为例Skills 通常放在用户目录下的配置目录中。例如Claude Desktop~/.claude/skills/Codex CLI~/.codex/skills/Cline~/.cline/skills/或项目.claude/skills/每个技能是一个独立目录目录名即技能名内放SKILL.md。AI 在对话中如果判断当前任务与该技能相关会读取该文件作为上下文。SKILL.md的结构可以灵活定义但推荐包含以下内容name技能名称description技能适用场景帮助 AI 判断何时使用when_to_use使用时机steps执行步骤rules必须遵守的规则examples代码示例一个针对 WEB 自动化测试的项目 Skill 模板会在实战部分给出。3.3 MCP 的通信链路与典型部署方式MCP 的基础通信方式是 JSON-RPC。AI 客户端启动时会读取配置文件中的 MCP Server 信息然后启动对应的 Server 进程。Server 会向客户端暴露工具列表。AI 根据用户问题决定是否调用某个工具。以 Playwright MCP Server 为例完整链路是用户提问 - AI 判断需要查看页面 - 调用 mcp__playwright__open_browser - 浏览器打开 - mcp__playwright__snapshot - 返回页面结构 - 用户继续提问 - AI 根据结构生成 pytest 代码典型配置方式有两种使用官方已发布的 MCP Server比如 Playwright 官方playwright/mcp。自己写一个 MCP Server把内部测试命令暴露给 AI。第一种适合通用场景第二种适合团队私有测试平台、内部接口、专属回归脚本。在下面的实战中两种都会用到。4. 完整实战90 分钟跑通 AI 辅助 WEB 自动化4.1 阶段一用 pytest 写好两条核心用例这个阶段的目标是让本地 pytest 能稳定执行登录和搜索业务。我们以一个常见的电商后台系统为例假设地址是http://localhost:5173这里你需要替换成自己的测试环境地址。先创建 pytest 配置# 文件路径pytest.ini [pytest] testpaths tests addopts -v -stestpaths告诉 pytest 去哪里找用例addopts表示运行时默认追加-v显示详细信息和-s允许打印输出。然后创建页面对象把登录页相关操作封装起来# 文件路径pages/login_page.py 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_label(用户名).fill(username) self.page.get_by_label(密码).fill(password) self.page.get_by_role(button, name登录).click() self.page.wait_for_url(**/dashboard)封装的好处是登录逻辑只写一次后续用例直接复用。AI 在生成新用例时如果知道有这个页面对象就不会重复写定位代码。接下来写测试# 文件路径tests/test_search.py from playwright.sync_api import Page, expect from pages.login_page import LoginPage BASE_URL http://localhost:5173 def test_login_and_search(page: Page): login_page LoginPage(page) login_page.goto(BASE_URL /login) login_page.login(demo_user, demo_pass) # 登录后进入搜索页 page.get_by_role(link, name商品管理).click() page.get_by_placeholder(搜索商品).fill(pytest) page.get_by_role(button, name搜索).click() # 等待结果出现 expect(page.locator(.search-result)).to_be_visible() # 收集结果数量 count page.locator(.search-result-item).count() print(f搜索结果条数: {count}) assert count 0, 搜索结果不能为空运行测试pytest如果一切正常你会看到类似输出tests/test_search.py::test_login_and_search PASSED4.2 阶段二接入 Playwright MCP让 AI 看见真实页面AI 生成的定位符不稳定的根本原因是它不知道页面真实 DOM 结构。AI 只能基于猜测写代码。接入 MCP 后AI 可以直接打开浏览器查看页面问题迎刃而解。Playwright MCP 官方包安装简单。首先确认 Node.js 环境可用node --version npx --version然后将 MCP 配置写入 AI 客户端的配置文件。不同客户端配置文件路径不一样但格式基本一致。以 Claude Desktop 为例配置文件为claude_desktop_config.json{ mcpServers: { playwright: { command: npx, args: [playwright/mcplatest] } } }Windows 用户如果 npx 命令无法被直接找到需要写完整路径{ mcpServers: { playwright: { command: C:\\Program Files\\nodejs\\npx.cmd, args: [playwright/mcplatest] } } }配置完成后重启 AI 客户端在对话中可以看到 playwright 相关工具已加载。你可以这样引导 AI请打开浏览器访问 http://localhost:5173/login获取登录页面元素结构然后帮我写一条 pytest 用例。AI 会调用 playwright MCP 工具的open_browser、snapshot等操作把页面的可交互元素展示出来再基于真实 DOM 生成定位器。这里的关键点MCP 工具返回的页面结构是简化后的 accessibility snapshot专门为 AI 理解页面设计的。AI 会根据 snapshot 中的 label、role、placeholder 等信息使用get_by_role、get_by_label、get_by_placeholder等方式定位而不是生成一长串 CSS path。4.3 阶段三把项目测试规范固化成 SkillMCP 让 AI 能看到页面但还不能让 AI 遵守团队规范。比如有的团队禁止使用time.sleep要求所有等待用expect有的团队要求用例必须包含关键业务断言。这些规范如果只存在于个人脑中AI 永远学不会。我们需要为项目写一个 Skill。在项目根目录的skills/web-test-skill/SKILL.md中写入# web-test-skill ## description 用于编写和维护基于 Playwright Pytest 的 WEB 自动化测试用例。当用户要求编写浏览器自动化测试、修改定位符、分析 pytest 失败原因时使用本技能。 ## when_to_use - 编写新的 WEB 自动化测试用例 - 修复失败的 UI 用例 - 优化元素定位策略 - 分析页面结构并生成断言 ## steps 1. 确认被测环境地址与账号信息。 2. 打开 MCP playwright 工具访问目标页面获取页面结构。 3. 优先使用 Playwright 推荐定位方式get_by_role、get_by_label、get_by_placeholder、get_by_text、get_by_ti tle。 4. 等待元素时使用 expect(locator).to_be_visible()禁止使用 time.sleep。 5. 将公共操作提取到 pages/ 目录下的页面对象中。 6. 测试用例放入 tests/ 目录文件名以 test_ 开头。 7. 运行 pytest -q 验证失败后分析 traceback 并修复。 ## rules - 用例之间必须相互独立禁止依赖其他用例的执行结果。 - 断言必须能反映业务价值避免只断言页面无报错。 - 涉及登录的用例优先复用 LoginPage 登录。 - 不要修改测试环境数据测试数据尽量使用独立账号。 - AI 生成的代码必须人工 review 后才允许进入 CI。 ## example python def test_search_product(page: Page): login_page LoginPage(page) login_page.goto(BASE_URL /login) login_page.login(demo_user, demo_pass) page.get_by_placeholder(搜索商品).fill(pytest) page.get_by_role(button, name搜索).click() expect(page.locator(.search-result)).to_be_visible() count page.locator(.search-result-item).count() assert count 0 print(f共 {count} 条结果)python # 文件路径pages/login_page.py 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_label(用户名).fill(username) self.page.get_by_label(密码).fill(password) self.page.get_by_role(button, name登录).click() self.page.wait_for_url(**/dashboard)这个小节里值得注意的细节Page类型来自playwright.sync_api代表了浏览器中的一个标签页会话。get_by_label(用户名)会优先匹配label元素关联的输入框比直接写input[nameusername]更接近用户视角。wait_for_url(**/dashboard)能确保登录成功跳转后再继续执行避免在跳转过程中操作页面导致竞态问题。如果页面没有label也可以改用get_by_placeholder(请输入用户名)。这种定位方式在 AI 辅助场景下非常关键因为 AI 能通过 MCP 读取页面快照直接看到输入框的 placeholder 和按钮可访问名称生成更贴近页面真实结构的代码。4.4 阶段四本地 MCP 暴露 pytest runnerAI 能写代码但要真正“玩转”自动化还需要能自己执行测试并读取结果。最直接的方式是把 pytest 执行封装成本地 MCP 工具。以 MCP Python SDK 为例可以创建一个简单的工具服务# 文件路径mcp/pytest_server.py import subprocess from mcp.server.fastmcp import FastMCP mcp FastMCP(pytest-runner) mcp.tool() def run_pytest(test_path: str) - str: 运行指定测试路径并返回 pytest 输出。test_path 必须位于项目目录内。 result subprocess.run( [python, -m, pytest, test_path, -q, --disable-warnings], capture_outputTrue, textTrue, timeout300, ) return fSTDOUT:\n{result.stdout}\nSTDERR:\n{result.stderr}在 AI 客户端中把该本地 MCP 也注册进去AI 就能调用这个工具生成用例后让 AI 调用run_pytest跑一遍。如果失败AI 读取输出分析 traceback结合页面 MCP 快照修改定位符。再跑再修直到通过。这就实现了“AI 自主执行 - 自主分析 - 自主修复”的闭环。需要特别说明的是timeout300防止用例卡死导致 MCP 工具无响应。capture_outputTrue能拿到完整日志方便让模型分析。在真实项目里不要允许任意命令执行尽量限制 test_path 必须在项目根目录内避免安全问题。4.5 90 分钟节奏表下面是整个落地的节奏建议适合边看边操作时间段任务产出0-15 分钟理解 Pytest、Skills、MCP 三者的关系清楚各自解决的问题15-30 分钟搭建虚拟环境、安装依赖、下载浏览器pytest 能正常启动30-50 分钟编写登录和搜索核心用例两条用例通过50-65 分钟接入 Playwright MCPAI 打开真实页面AI 能看到页面结构并改进定位65-80 分钟沉淀项目 Skill编写本地 pytest MCPAI 能按规范生成和运行测试80-90 分钟让 AI 根据失败日志自动修复用例完成一轮失败 - 修复 - 通过前半段可能稍慢因为环境问题因人而异后半段会比较快因为 AI 在 MCP 和 Skill 的辅助下生成代码的准确率会高很多。5. 常见问题与排查思路5.1 常见问题速查表问题现象常见原因解决思路pytest 提示 no tests rantestpaths 配置错误或测试文件不在 tests 目录检查 pytest.ini确认测试文件以 test_ 开头浏览器启动失败缺少系统依赖或内核未下载执行 playwright install chromium排查系统依赖npx 不是内部或外部命令Node.js 未安装或未加入 PATH安装 Node.js或配置 npx.cmd 完整路径MCP 工具在客户端里看不到配置文件路径错误或 JSON 格式错误检查 mcpServers 配置重启客户端查看日志AI 生成的定位符不稳定AI 没有看到真实页面结构让 AI 调用 playwright MCP 获取页面快照页面元素加载太慢导致超时没有使用正确的等待机制用 expect(locator).to_be_visible() 替代固定 sleepWindows 下 MCP Server 启动失败Python 或 node 命令路径无法获取使用完整路径避免依赖系统 PATH5.2 核心排查方法遇到 MCP 工具没有加载时首先看 AI 客户端的日志或状态面板。大多数客户端会显示 MCP Server 的启动状态。如果出现 “spawn ... ENOENT”说明可执行文件路径不对。遇到 AI 生成的测试代码无法运行时先让 AI 把失败 traceback 贴出来并明确告诉它当前项目结构、依赖版本和页面访问地址。因为 MCP 工具已经能看到页面AI 会主动通过 snapshot 检查实际 DOM再修正定位符。一个非常实用的技巧是不要只问 AI“为什么失败”而是让它“先查看页面结构再对比代码中的定位符”。这样 AI 就能从两个角度交叉分析定位问题的正确率会明显提高。6. 最佳实践与工程落地建议6.1 不要把 AI 生成的代码直接跑进 CIAI 生成代码速度快但可能出现团队不认可的风格、隐藏的边界条件、甚至对业务数据的误解。比较稳妥的流程是AI 负责生成初稿并本地执行通过。人工 review 核心业务断言是否合理。通过后提交到 CI 执行。失败时继续让 AI 基于日志和页面快照修复。这样既保留了 AI 的效率又把最终质量掌控在人手里。6.2 定位符规范优先级推荐优先级从高到低get_by_role(button, name登录)基于可访问名称定位语义明确。get_by_label(用户名)表单控件场景最合适。get_by_placeholder(搜索商品)输入框无 label 时的替代。get_by_text(商品管理)定位链接、文本内容。locator([data-testid...])有测试属性时优先使用测试属性。避免使用绝对 CSS 路径比如#root div form div input页面结构一变就挂。这些规则可以直接写进 Skill让 AI 自动遵守。6.3 测试数据与登录态管理自动化最怕脏数据。建议使用独立测试账号不要影响线上数据。登录后复用浏览器 context 的 storage_state避免每条用例都走登录。用例之间尽量互不依赖。Playwright 保存登录态的方式# 首次登录后保存状态 context.storage_state(pathstate.json) # 后续用例复用状态 context browser.new_context(storage_statestate.json)在 AI 辅助场景中把登录态文件加入.gitignore因为它包含敏感 token不应该提交到仓库。6.4 MCP 与安全边界MCP 给了 AI 执行能力也让 AI 的工具调用存在误操作风险。落地时注意本地 MCP Server 只在本机运行不要暴露到公网。MCP 工具函数里做路径校验、白名单、超时控制拒绝任意命令。被测环境尽量使用测试环境或沙箱环境。涉及账号密码时通过环境变量或配置文件读取不要硬编码。6.5 日志与结果沉淀AI 修复用例依赖日志而日志的质量直接影响修复效果。建议在测试里保留足够有业务含义的断言信息并在失败时捕获页面截图和 HTML。示例import pytest from playwright.sync_api import Page, expect pytest.fixture() def trace_on_failure(page: Page): yield if page.locator(body).count() 0: return # 失败时截图 page.screenshot(pathfailure.png)这样 AI 在分析失败时除了 traceback还可以查看截图和页面快照修复效率更高。7. 总结与下一步学习方向本文完整演示了如何把 Pytest、Skills、MCP 组合成一套 AI 辅助 WEB 自动化工作流。核心认知有三点第一Pytest 负责执行它保证用例可以被标准化运行、断言和回归。第二Skills 负责规范把团队约定固化成 AI 可读的资料让 AI 生成代码时自动遵循。第三MCP 负责打通让 AI 看见真实页面、运行测试、获取结果实现从“只会写代码”到“能自己调试”的跨越。接下来如果你要继续深入建议按顺序尝试以下方向把登录态复用、失败截图、HTML 报告集成到 pytest 配置中让整个测试框架更工程化。编写更细粒度的 Skill比如“登录相关用例”“订单流程用例”“数据驱动用例”让 AI 在不同业务模块内更专业。把 pytest 输出结果通过 MCP 回传给团队内部的测试平台形成一键分析和自动提单的能力。尝试让 AI 基于页面快照自动生成测试用例覆盖清单把自动化从“写用例”升级到“设计用例”。这套链路的技术栈还在快速演进尤其是 Skills 和 MCP 的工具链版本差异会比较明显。建议你在实际操作时以官方文档为准不要拘泥于某个具体命令。重点是理解“执行框架 技能规范 工具协议”这个组合思路。思路对了工具随时可以换。如果这篇文章对你搭建 AI 辅助测试环境有帮助可以先收藏起来等真正动手搭环境时再对照操作。毕竟这类工具链最怕的就是“眼睛会了手还没跟上”。 AI辅助WEB自动化测试：Pytest+Skills+MCP全链路实战
很多测试同学拿到 AI 写好的 pytest 脚本后第一反应是“代码长得挺像样跑起来却哪哪都不对”。定位符不稳定、不知道被测页面真实结构、失败之后只能把报错复制进对话框反复问模型来回几次已经没有耐心。问题本质不是模型能力不够而是整个工作链路缺了三样东西一套靠谱的测试执行框架、一套能让 AI 记住项目规范的“操作手册”、一条让 AI 直接看到真实页面的通道。这套链路就是 Pytest Skills MCP。本文将围绕“AI 玩转 WEB 自动化”这个目标用 90 分钟带你跑通一套闭环方案。你会看到如何用 Pytest 组织浏览器自动化用例如何用 Skill 让 AI 遵守团队规范如何用 MCP 让 AI 打开浏览器、查看真实页面、执行 pytest 并自动修正代码。整个过程不炒概念直接给命令、给代码、给配置也把容易踩的坑说明白。通过本文你将能独立搭建一套 AI 辅助 WEB 自动化环境让 AI 不只停留在“生成一段用例代码”而是真正参与“写代码 - 运行 - 看结果 - 修问题 - 回归”的完整循环。这套方法同样适合接口自动化、UI 冒烟测试、回归测试等场景。1. 背景与核心概念1.1 为什么 WEB 自动化需要 AI 辅助传统 WEB 自动化测试通常用 Selenium、Playwright 这类工具写浏览器操作脚本。脚本本身不难真正花时间的是三点元素定位、等待策略、用例维护。页面结构一改定位符就要跟着改接口返回变慢等待时间又要重新调测试数据不干净用例就直接红。AI 辅助测试的目标是让大模型帮我们处理这些重复劳动。AI 可以根据自然语言描述生成用例、根据失败日志修改定位符、根据页面 DOM 调整断言。但这里有个前提AI 必须掌握足够多关于你项目的上下文。它要知道被测系统的 URL、登录方式、关键业务路径、元素定位习惯、断言规范、运行命令是什么。这些信息如果都靠每次对话重复输入效率极低。Skills 和 MCP 正好解决这个问题。Skills 把“怎么写这个项目的自动化用例”沉淀成规范文档MCP 把“打开浏览器看页面”“执行 pytest 命令”变成 AI 可以直接调用的工具。两者组合在一起AI 才真正像一个熟悉项目的测试开发。1.2 三个名词到底是什么意思Pytest是 Python 生态里最常用的测试框架。它负责用例发现、用例执行、断言、fixture 管理、报告输出。在 WEB 自动化场景中它扮演的是“执行引擎”。你可以把测试脚本交给 pytestpytest 会找到以test_开头的函数或Test开头的类按顺序执行并输出通过或失败的结果。Skills在 AI 编程助手语境下是一组预先定义好的能力包。通常表现为一个目录目录里包含SKILL.md说明文件和若干辅助脚本。这个说明文件告诉模型在什么场景下使用这个技能、执行步骤是什么、代码风格是什么、有哪些注意事项。Skills 的价值是把项目经验、团队规范、最佳实践固化下来AI 在生成代码时自动参考不再每次从零推理。MCP全称 Model Context Protocol模型上下文协议。它解决的是“AI 怎么与外部工具通信”的问题。MCP 采用 C/S 架构AI 应用作为客户端工具服务作为 Server。Server 可以暴露“打开浏览器”“获取网页结构”“执行命令”等能力。AI 可以像调用函数一样使用这些能力。MCP 相当于给 AI 加了眼睛和手解决了“模型看不到真实页面”的痛点。1.3 Agent Skill 和 MCP 有什么区别很多同学看到 Skill 和 MCP 同时出现容易混淆。两者并不冲突它们工作的层级不同。维度SkillMCP本质一套指令与规范一套通信协议作用对象指导 AI 如何思考和组织代码让 AI 连接外部工具与数据主要载体Markdown 文档、脚本、模板MCP Server 程序举个例子告诉 AI 优先用get_by_role定位元素等待用expect而不是time.sleep提供一个open_browser工具AI 调用它就能打开浏览器关系Skill 决定“怎么做更规范”MCP 决定“能做什么事”实际项目中两者经常配合使用。Skill 告诉 AI“写这套代码要遵守哪些约定”MCP 提供工具让 AI“真正运行代码、看真实页面”。后面实战环节会完整展示这个配合方式。2. 环境准备与项目结构2.1 依赖清单假设本地环境是 Windows 或 macOSPython 版本建议 3.10 及以上。在开始前先确认 Python 能正常使用python --version pip --version如果还没有 Python 环境建议安装 3.11 或 3.12 的稳定版本。Windows 用户安装时记得勾选“Add Python to PATH”避免后续命令找不到。接下来准备以下核心组件组件作用pytest测试执行框架playwright浏览器自动化库pytest-playwright可选的 pytest 插件提供 page fixtureruff可选用于代码格式检查node / npx运行 Playwright MCP Server部分 AI 客户端需要版本说明不同版本的 pytest 和 playwright 接口略有差异本文示例以当前主流版本为准配置思路通用。如果后续接口有变化以官方文档为准即可。2.2 安装 Python 依赖在项目目录创建虚拟环境是推荐做法避免污染全局环境mkdir ai-web-test cd ai-web-test python -m venv .venvWindows 激活虚拟环境.venv\Scripts\activatemacOS / Linux 激活虚拟环境source .venv/bin/activate激活后安装依赖pip install pytest playwright pytest-playwright安装完成后下载浏览器内核。Playwright 不像 Selenium 需要单独下载驱动它直接管理浏览器内核playwright install chromium如果你需要测试 Chrome 的完整行为也可以安装playwright install chrome下载时间取决于网络环境耐心等待即可。下载完成后可以快速验证playwright --version如果输出版本号说明安装成功。2.3 项目结构设计一个结构清晰的自动化项目不仅方便人读也方便 AI 理解。推荐下面的目录结构ai-web-test/ ├── .venv/ # 虚拟环境 ├── pages/ # 页面对象层 │ ├── __init__.py │ └── login_page.py ├── tests/ # 测试用例目录 │ ├── __init__.py │ ├── conftest.py # pytest 夹具配置 │ └── test_search.py ├── skills/ # 自定义 Skills 目录 │ └── web-test-skill/ │ └── SKILL.md ├── mcp/ # 自定义 MCP Server 目录 │ └── pytest_server.py ├── pytest.ini # pytest 配置 └── requirements.txt # 依赖清单页面对象层不是必须的但对于业务相对复杂的项目能显著降低维护成本。后面在实战中会用到页面对象让代码更好维护。3. 核心知识pytest fixture、Skills 与 MCP 的工作方式3.1 pytest fixture 怎么支撑浏览器用例在 pytest 中fixture 是一种依赖注入机制。你可以在 fixture 里创建资源测试函数通过参数引用它。pytest 会自动管理生命周期。以 Playwright 为例最简单的浏览器 fixture 如下# 文件路径tests/conftest.py import pytest from playwright.sync_api import sync_playwright pytest.fixture(scopefunction) def page(): with sync_playwright() as p: browser p.chromium.launch( headlessFalse, slow_mo200, ) context browser.new_context() page context.new_page() yield page context.close() browser.close()这里的关键点scopefunction表示每个测试函数都创建一套全新浏览器环境保证用例隔离。headlessFalse启动有头浏览器方便观察操作过程。slow_mo200让每一步操作停顿 200 毫秒便于看到执行过程调试时可以配大一点。yield page之后的代码在用例执行完成后运行用于资源清理。如果安装了pytest-playwright插件其实自带page、browser、context等 fixture不需要自己手写。但理解底层原理很重要排错时才知道是浏览器问题还是 pytest 问题。3.2 Skill 的工作方式与目录规范以常见的编程助手为例Skills 通常放在用户目录下的配置目录中。例如Claude Desktop~/.claude/skills/Codex CLI~/.codex/skills/Cline~/.cline/skills/或项目.claude/skills/每个技能是一个独立目录目录名即技能名内放SKILL.md。AI 在对话中如果判断当前任务与该技能相关会读取该文件作为上下文。SKILL.md的结构可以灵活定义但推荐包含以下内容name技能名称description技能适用场景帮助 AI 判断何时使用when_to_use使用时机steps执行步骤rules必须遵守的规则examples代码示例一个针对 WEB 自动化测试的项目 Skill 模板会在实战部分给出。3.3 MCP 的通信链路与典型部署方式MCP 的基础通信方式是 JSON-RPC。AI 客户端启动时会读取配置文件中的 MCP Server 信息然后启动对应的 Server 进程。Server 会向客户端暴露工具列表。AI 根据用户问题决定是否调用某个工具。以 Playwright MCP Server 为例完整链路是用户提问 - AI 判断需要查看页面 - 调用 mcp__playwright__open_browser - 浏览器打开 - mcp__playwright__snapshot - 返回页面结构 - 用户继续提问 - AI 根据结构生成 pytest 代码典型配置方式有两种使用官方已发布的 MCP Server比如 Playwright 官方playwright/mcp。自己写一个 MCP Server把内部测试命令暴露给 AI。第一种适合通用场景第二种适合团队私有测试平台、内部接口、专属回归脚本。在下面的实战中两种都会用到。4. 完整实战90 分钟跑通 AI 辅助 WEB 自动化4.1 阶段一用 pytest 写好两条核心用例这个阶段的目标是让本地 pytest 能稳定执行登录和搜索业务。我们以一个常见的电商后台系统为例假设地址是http://localhost:5173这里你需要替换成自己的测试环境地址。先创建 pytest 配置# 文件路径pytest.ini [pytest] testpaths tests addopts -v -stestpaths告诉 pytest 去哪里找用例addopts表示运行时默认追加-v显示详细信息和-s允许打印输出。然后创建页面对象把登录页相关操作封装起来# 文件路径pages/login_page.py 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_label(用户名).fill(username) self.page.get_by_label(密码).fill(password) self.page.get_by_role(button, name登录).click() self.page.wait_for_url(**/dashboard)封装的好处是登录逻辑只写一次后续用例直接复用。AI 在生成新用例时如果知道有这个页面对象就不会重复写定位代码。接下来写测试# 文件路径tests/test_search.py from playwright.sync_api import Page, expect from pages.login_page import LoginPage BASE_URL http://localhost:5173 def test_login_and_search(page: Page): login_page LoginPage(page) login_page.goto(BASE_URL /login) login_page.login(demo_user, demo_pass) # 登录后进入搜索页 page.get_by_role(link, name商品管理).click() page.get_by_placeholder(搜索商品).fill(pytest) page.get_by_role(button, name搜索).click() # 等待结果出现 expect(page.locator(.search-result)).to_be_visible() # 收集结果数量 count page.locator(.search-result-item).count() print(f搜索结果条数: {count}) assert count 0, 搜索结果不能为空运行测试pytest如果一切正常你会看到类似输出tests/test_search.py::test_login_and_search PASSED4.2 阶段二接入 Playwright MCP让 AI 看见真实页面AI 生成的定位符不稳定的根本原因是它不知道页面真实 DOM 结构。AI 只能基于猜测写代码。接入 MCP 后AI 可以直接打开浏览器查看页面问题迎刃而解。Playwright MCP 官方包安装简单。首先确认 Node.js 环境可用node --version npx --version然后将 MCP 配置写入 AI 客户端的配置文件。不同客户端配置文件路径不一样但格式基本一致。以 Claude Desktop 为例配置文件为claude_desktop_config.json{ mcpServers: { playwright: { command: npx, args: [playwright/mcplatest] } } }Windows 用户如果 npx 命令无法被直接找到需要写完整路径{ mcpServers: { playwright: { command: C:\\Program Files\\nodejs\\npx.cmd, args: [playwright/mcplatest] } } }配置完成后重启 AI 客户端在对话中可以看到 playwright 相关工具已加载。你可以这样引导 AI请打开浏览器访问 http://localhost:5173/login获取登录页面元素结构然后帮我写一条 pytest 用例。AI 会调用 playwright MCP 工具的open_browser、snapshot等操作把页面的可交互元素展示出来再基于真实 DOM 生成定位器。这里的关键点MCP 工具返回的页面结构是简化后的 accessibility snapshot专门为 AI 理解页面设计的。AI 会根据 snapshot 中的 label、role、placeholder 等信息使用get_by_role、get_by_label、get_by_placeholder等方式定位而不是生成一长串 CSS path。4.3 阶段三把项目测试规范固化成 SkillMCP 让 AI 能看到页面但还不能让 AI 遵守团队规范。比如有的团队禁止使用time.sleep要求所有等待用expect有的团队要求用例必须包含关键业务断言。这些规范如果只存在于个人脑中AI 永远学不会。我们需要为项目写一个 Skill。在项目根目录的skills/web-test-skill/SKILL.md中写入# web-test-skill ## description 用于编写和维护基于 Playwright Pytest 的 WEB 自动化测试用例。当用户要求编写浏览器自动化测试、修改定位符、分析 pytest 失败原因时使用本技能。 ## when_to_use - 编写新的 WEB 自动化测试用例 - 修复失败的 UI 用例 - 优化元素定位策略 - 分析页面结构并生成断言 ## steps 1. 确认被测环境地址与账号信息。 2. 打开 MCP playwright 工具访问目标页面获取页面结构。 3. 优先使用 Playwright 推荐定位方式get_by_role、get_by_label、get_by_placeholder、get_by_text、get_by_ti tle。 4. 等待元素时使用 expect(locator).to_be_visible()禁止使用 time.sleep。 5. 将公共操作提取到 pages/ 目录下的页面对象中。 6. 测试用例放入 tests/ 目录文件名以 test_ 开头。 7. 运行 pytest -q 验证失败后分析 traceback 并修复。 ## rules - 用例之间必须相互独立禁止依赖其他用例的执行结果。 - 断言必须能反映业务价值避免只断言页面无报错。 - 涉及登录的用例优先复用 LoginPage 登录。 - 不要修改测试环境数据测试数据尽量使用独立账号。 - AI 生成的代码必须人工 review 后才允许进入 CI。 ## example python def test_search_product(page: Page): login_page LoginPage(page) login_page.goto(BASE_URL /login) login_page.login(demo_user, demo_pass) page.get_by_placeholder(搜索商品).fill(pytest) page.get_by_role(button, name搜索).click() expect(page.locator(.search-result)).to_be_visible() count page.locator(.search-result-item).count() assert count 0 print(f共 {count} 条结果)python # 文件路径pages/login_page.py 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_label(用户名).fill(username) self.page.get_by_label(密码).fill(password) self.page.get_by_role(button, name登录).click() self.page.wait_for_url(**/dashboard)这个小节里值得注意的细节Page类型来自playwright.sync_api代表了浏览器中的一个标签页会话。get_by_label(用户名)会优先匹配label元素关联的输入框比直接写input[nameusername]更接近用户视角。wait_for_url(**/dashboard)能确保登录成功跳转后再继续执行避免在跳转过程中操作页面导致竞态问题。如果页面没有label也可以改用get_by_placeholder(请输入用户名)。这种定位方式在 AI 辅助场景下非常关键因为 AI 能通过 MCP 读取页面快照直接看到输入框的 placeholder 和按钮可访问名称生成更贴近页面真实结构的代码。4.4 阶段四本地 MCP 暴露 pytest runnerAI 能写代码但要真正“玩转”自动化还需要能自己执行测试并读取结果。最直接的方式是把 pytest 执行封装成本地 MCP 工具。以 MCP Python SDK 为例可以创建一个简单的工具服务# 文件路径mcp/pytest_server.py import subprocess from mcp.server.fastmcp import FastMCP mcp FastMCP(pytest-runner) mcp.tool() def run_pytest(test_path: str) - str: 运行指定测试路径并返回 pytest 输出。test_path 必须位于项目目录内。 result subprocess.run( [python, -m, pytest, test_path, -q, --disable-warnings], capture_outputTrue, textTrue, timeout300, ) return fSTDOUT:\n{result.stdout}\nSTDERR:\n{result.stderr}在 AI 客户端中把该本地 MCP 也注册进去AI 就能调用这个工具生成用例后让 AI 调用run_pytest跑一遍。如果失败AI 读取输出分析 traceback结合页面 MCP 快照修改定位符。再跑再修直到通过。这就实现了“AI 自主执行 - 自主分析 - 自主修复”的闭环。需要特别说明的是timeout300防止用例卡死导致 MCP 工具无响应。capture_outputTrue能拿到完整日志方便让模型分析。在真实项目里不要允许任意命令执行尽量限制 test_path 必须在项目根目录内避免安全问题。4.5 90 分钟节奏表下面是整个落地的节奏建议适合边看边操作时间段任务产出0-15 分钟理解 Pytest、Skills、MCP 三者的关系清楚各自解决的问题15-30 分钟搭建虚拟环境、安装依赖、下载浏览器pytest 能正常启动30-50 分钟编写登录和搜索核心用例两条用例通过50-65 分钟接入 Playwright MCPAI 打开真实页面AI 能看到页面结构并改进定位65-80 分钟沉淀项目 Skill编写本地 pytest MCPAI 能按规范生成和运行测试80-90 分钟让 AI 根据失败日志自动修复用例完成一轮失败 - 修复 - 通过前半段可能稍慢因为环境问题因人而异后半段会比较快因为 AI 在 MCP 和 Skill 的辅助下生成代码的准确率会高很多。5. 常见问题与排查思路5.1 常见问题速查表问题现象常见原因解决思路pytest 提示 no tests rantestpaths 配置错误或测试文件不在 tests 目录检查 pytest.ini确认测试文件以 test_ 开头浏览器启动失败缺少系统依赖或内核未下载执行 playwright install chromium排查系统依赖npx 不是内部或外部命令Node.js 未安装或未加入 PATH安装 Node.js或配置 npx.cmd 完整路径MCP 工具在客户端里看不到配置文件路径错误或 JSON 格式错误检查 mcpServers 配置重启客户端查看日志AI 生成的定位符不稳定AI 没有看到真实页面结构让 AI 调用 playwright MCP 获取页面快照页面元素加载太慢导致超时没有使用正确的等待机制用 expect(locator).to_be_visible() 替代固定 sleepWindows 下 MCP Server 启动失败Python 或 node 命令路径无法获取使用完整路径避免依赖系统 PATH5.2 核心排查方法遇到 MCP 工具没有加载时首先看 AI 客户端的日志或状态面板。大多数客户端会显示 MCP Server 的启动状态。如果出现 “spawn ... ENOENT”说明可执行文件路径不对。遇到 AI 生成的测试代码无法运行时先让 AI 把失败 traceback 贴出来并明确告诉它当前项目结构、依赖版本和页面访问地址。因为 MCP 工具已经能看到页面AI 会主动通过 snapshot 检查实际 DOM再修正定位符。一个非常实用的技巧是不要只问 AI“为什么失败”而是让它“先查看页面结构再对比代码中的定位符”。这样 AI 就能从两个角度交叉分析定位问题的正确率会明显提高。6. 最佳实践与工程落地建议6.1 不要把 AI 生成的代码直接跑进 CIAI 生成代码速度快但可能出现团队不认可的风格、隐藏的边界条件、甚至对业务数据的误解。比较稳妥的流程是AI 负责生成初稿并本地执行通过。人工 review 核心业务断言是否合理。通过后提交到 CI 执行。失败时继续让 AI 基于日志和页面快照修复。这样既保留了 AI 的效率又把最终质量掌控在人手里。6.2 定位符规范优先级推荐优先级从高到低get_by_role(button, name登录)基于可访问名称定位语义明确。get_by_label(用户名)表单控件场景最合适。get_by_placeholder(搜索商品)输入框无 label 时的替代。get_by_text(商品管理)定位链接、文本内容。locator([data-testid...])有测试属性时优先使用测试属性。避免使用绝对 CSS 路径比如#root div form div input页面结构一变就挂。这些规则可以直接写进 Skill让 AI 自动遵守。6.3 测试数据与登录态管理自动化最怕脏数据。建议使用独立测试账号不要影响线上数据。登录后复用浏览器 context 的 storage_state避免每条用例都走登录。用例之间尽量互不依赖。Playwright 保存登录态的方式# 首次登录后保存状态 context.storage_state(pathstate.json) # 后续用例复用状态 context browser.new_context(storage_statestate.json)在 AI 辅助场景中把登录态文件加入.gitignore因为它包含敏感 token不应该提交到仓库。6.4 MCP 与安全边界MCP 给了 AI 执行能力也让 AI 的工具调用存在误操作风险。落地时注意本地 MCP Server 只在本机运行不要暴露到公网。MCP 工具函数里做路径校验、白名单、超时控制拒绝任意命令。被测环境尽量使用测试环境或沙箱环境。涉及账号密码时通过环境变量或配置文件读取不要硬编码。6.5 日志与结果沉淀AI 修复用例依赖日志而日志的质量直接影响修复效果。建议在测试里保留足够有业务含义的断言信息并在失败时捕获页面截图和 HTML。示例import pytest from playwright.sync_api import Page, expect pytest.fixture() def trace_on_failure(page: Page): yield if page.locator(body).count() 0: return # 失败时截图 page.screenshot(pathfailure.png)这样 AI 在分析失败时除了 traceback还可以查看截图和页面快照修复效率更高。7. 总结与下一步学习方向本文完整演示了如何把 Pytest、Skills、MCP 组合成一套 AI 辅助 WEB 自动化工作流。核心认知有三点第一Pytest 负责执行它保证用例可以被标准化运行、断言和回归。第二Skills 负责规范把团队约定固化成 AI 可读的资料让 AI 生成代码时自动遵循。第三MCP 负责打通让 AI 看见真实页面、运行测试、获取结果实现从“只会写代码”到“能自己调试”的跨越。接下来如果你要继续深入建议按顺序尝试以下方向把登录态复用、失败截图、HTML 报告集成到 pytest 配置中让整个测试框架更工程化。编写更细粒度的 Skill比如“登录相关用例”“订单流程用例”“数据驱动用例”让 AI 在不同业务模块内更专业。把 pytest 输出结果通过 MCP 回传给团队内部的测试平台形成一键分析和自动提单的能力。尝试让 AI 基于页面快照自动生成测试用例覆盖清单把自动化从“写用例”升级到“设计用例”。这套链路的技术栈还在快速演进尤其是 Skills 和 MCP 的工具链版本差异会比较明显。建议你在实际操作时以官方文档为准不要拘泥于某个具体命令。重点是理解“执行框架 技能规范 工具协议”这个组合思路。思路对了工具随时可以换。如果这篇文章对你搭建 AI 辅助测试环境有帮助可以先收藏起来等真正动手搭环境时再对照操作。毕竟这类工具链最怕的就是“眼睛会了手还没跟上”。