企业官网建设流程全解析

这次我们来看一个非常实用的自动化组合：Pytest + Skills + MCP，配合 AI Agent 来完成 WEB 自动化测试。

这个组合的核心思路不复杂：Pytest 负责测试用例的结构、断言和报告；MCP 把浏览器操作、页面元素读取、测试执行能力封装成工具接口，让 AI 能直接调用；Skills 则把重复性的提示词和操作经验固化下来，避免每次让 AI 从零开始。

简单说，AI 不再只是帮你写代码，而是能直接驱动浏览器、执行测试、读取结果并给出修复建议。这套链路对熟悉 Pytest 但想接入 AI 的测试工程师，或者已经在用 AI 编程工具但觉得“生成代码容易，跑通测试很难”的人来说，值得花时间研究。

本文会从环境准备、安装部署、功能验证、接口调用、批量任务、问题排查这几个角度展开，全程只讲能落地的操作。

1. 核心能力速览

这套组合最大的价值是：把 AI 的能力从“问答”扩展到了“操作”。AI 能看到页面、能点击按钮、能填写表单、能读取断言结果，而不是只给出“你应该怎么写”的建议。

2. 适用场景与使用边界

2.1 适合谁用

• 有 Pytest 基础，想引入 AI 辅助编写和维护 WEB 自动化用例的测试开发。
• 在使用 Cursor、Claude Desktop 或其他 MCP 客户端，想给 AI 加上浏览器操作能力的开发者。
• 需要在本地快速验证页面功能、拉取页面数据、做回归测试的技术人员。

2.2 能解决什么问题

• 测试用例编写效率：AI 可以直接访问页面，根据实际 DOM 结构生成选择器和断言，而不是凭空生成一堆猜出来的 XPath。
• 用例维护成本：页面结构变化后，AI 能根据报错信息重新读取页面，自动修正选择器。
• 结果反馈闭环：测试失败后，AI 能读取异常日志和页面截图，定位问题原因。
• 测试数据准备：通过浏览器操作自动完成登录、表单填写、数据创建等前置步骤。

2.3 不适合什么场景

• 需要 7x24 小时大规模并发压测的场景不是这个组合的重点，压测应该交给 JMeter 或 Locust 这类专业工具。
• 对响应时间要求极高的线上冒烟测试，也不建议让 AI Agent 参与每一步决策，应该用固定的自动化脚本直连执行。
• 生产环境操作务必谨慎，AI 驱动浏览器执行操作前必须经过充分验证。

2.4 合规与安全边界

使用浏览器自动化和 AI 辅助测试时，必须注意：

• 只在自己有权限的测试环境、测试账号上执行操作。
• 不采集、不保存页面上的非公开敏感数据。
• 不利用自动化绕过登录验证、验证码、风控策略。
• 涉及第三方系统的自动化测试，需要确认是否有接口授权或测试许可。
• AI 生成的代码在运行前要做人工审查，避免误操作。

3. 环境准备与前置条件

下面给出一套通用环境清单，具体版本以你本机和项目实际情况为准。

3.1 基础环境

3.2 Python 依赖

创建虚拟环境并安装 Pytest 和 Playwright：

python -m venv .venv source .venv/bin/activate # Windows 下使用 .venv\Scripts\activate pip install pytest playwright

如果确认使用 Playwright MCP Server，还需要安装对应的服务端依赖。具体包名以你选择的 MCP Server 项目为准，常见的是@playwright/mcp（npm 包）或对应的 Python 实现。

3.3 浏览器驱动

Playwright 需要单独安装浏览器内核：

playwright install chromium

安装完成后可以用下面这段代码验证浏览器能否被驱动：

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

这段代码能正常输出Example Domain，说明 Playwright 环境可用。如果你的网络环境访问 example.com 受限，可以换成自己本地的测试页面地址。

3.4 MCP 客户端准备

不同的 AI 客户端对 MCP Server 的配置方式不同。常见的有 stdio 启动和 HTTP 启动两种模式。stdio 模式适合本地命令行工具，HTTP 模式适合远程服务或局域网访问。你需要先确认自己使用的客户端支持哪种模式，再按对应文档写入配置文件。

4. 安装部署与启动方式

4.1 创建项目结构

建议按下面的目录组织工程：

web_auto_test/ ├── .venv/ # 虚拟环境 ├── config/ # 配置文件 │ └── mcp_config.json # MCP Server 配置 ├── tests/ # Pytest 用例目录 │ ├── conftest.py │ └── test_demo.py ├── pages/ # 页面对象封装 ├── skills/ # Agent Skills 定义 ├── reports/ # 测试报告输出 └── requirements.txt

4.2 MCP Server 配置示例

下面是一份通用的 MCP 配置模板，具体字段名需要按你使用的客户端来调整。示例假设使用的是支持mcpServers配置的客户端：

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"], "env": { "BROWSER": "chromium" } } } }

如果你使用的是 Python 实现的 MCP Server，命令字段需要改成对应的启动命令。这里不写死任何项目名，你需要根据实际选择的 MCP Server 替换command和args部分。

4.3 启动 MCP Server

stdio 模式下，启动操作由 AI 客户端自动完成。你只需要在客户端里启用对应的 MCP Server 配置，然后向 AI 发送一条与浏览器操作相关的指令，客户端就会自动拉起 Server。

如果你想手动验证 MCP Server 是否正常工作，可以查看你的 MCP Server 是否支持独立命令行启动。如果支持，一般类似：

npx @playwright/mcp@latest --port 8931

这里的端口号只是示例，实际端口以你使用的服务为准。启动成功后，服务会等待客户端连接。

4.4 启动 Pytest 用例

常规执行方式：

pytest tests/ -v --html=reports/report.html

如果你安装了 pytest-html 插件，上面的--html参数才有效。没有安装插件时，先运行：

pip install pytest-html

5. 功能测试与效果验证

5.1 验证 Pytest 基础能力

先写一个最小用例，确保 Pytest 能正常运行：

def test_example(): assert 1 + 1 == 2

执行：

pytest tests/test_demo.py -v

预期输出中能看到PASSED。这个步骤是在确认基础测试链路没有断。

5.2 验证 AI 能驱动浏览器

在支持 MCP 的 AI 客户端里，向 AI 发送一条指令：

打开 https://example.com，告诉我页面标题和当前页面的主要文本内容。

如果 MCP Server 配置正确，AI 会调用浏览器工具，打开页面并返回标题和正文摘要。

判断标准：

• AI 返回了页面内容，而不是说自己无法执行。
• 客户端日志中能看到 MCP 工具的调用记录。
• 执行过程中可以观察到浏览器窗口弹出或无头浏览器日志输出。

如果 AI 无法完成操作，优先检查 MCP Server 是否启动、配置中的命令路径是否正确、浏览器内核是否安装完整。

5.3 验证 AI 能执行 Pytest 用例

创建一个真实的 Web 自动化用例。以 Playwright 为例：

import re from playwright.sync_api import Page, expect def test_page_titles(page: Page): page.goto("https://example.com") expect(page).to_have_title(re.compile("Example"))

这里的page参数来自 Pytest 插件pytest-playwright。需要安装：

pip install pytest-playwright

运行上面的用例后，再让 AI 根据测试失败信息修改代码。你可以这样提问：

刚才的测试用例失败了，报错信息如下：<粘贴报错> 请读取当前页面结构，帮我修正选择器和断言。

AI 会重新打开页面、检查 DOM、给出修正后的代码。这个闭环就是 Pytest + MCP 的核心价值：AI 能看到实际页面，而不是凭空生成代码。

5.4 验证 Skills 技能复用

Skills 的本质是把一段反复使用的操作流程固化成可复用能力。比如“登录系统”这个操作，如果让 AI 每次现学，既慢又容易出错。可以把它做成一个 Skill。

Skill 的存储形式通常是目录加描述文件：

skills/ └── login/ ├── SKILL.md # 技能描述，说明适用场景 └── script.py # 登录操作的可执行脚本

SKILL.md里写清楚：

• 这个技能用来做什么。
• 前置条件是什么，比如需要测试账号。
• 调用方式是什么，参数怎么传。

你可以要求 AI Agent 在后续测试中始终调用这个 Skill 来完成登录操作。这样测试流程的稳定性和复用性都会提高。

5.5 验证批量任务能力

Pytest 本身支持参数化，可以用来构造批量测试数据：

import pytest @pytest.mark.parametrize("keyword", ["pytest", "mcp", "playwright"]) def test_search(page: Page, keyword: str): page.goto("https://example.com/search") page.fill("input[name='q']", keyword) page.press("input[name='q']", "Enter") assert page.locator(".result").count() > 0

执行后，Pytest 会自动生成三条独立的测试记录。配合pytest-xdist或 CI 管道，可以把批量测试扩展到多进程执行。

批量任务的关键：

• 用例之间要相互独立，不共享状态。
• 测试数据尽量通过参数传入，不要硬编码在用例里。
• 失败用例要能单独重跑。

6. 接口 API 与批量任务

6.1 MCP 协议与接口能力

MCP 本身不是某个具体项目的 API，而是一套协议。AI Agent 通过 MCP 客户端与 Server 通信，Server 提供tools、resources、prompts三类能力。

• tools：可执行的浏览器操作、测试命令。
• resources：可读取的页面状态、DOM 内容、测试报告。
• prompts：可复用的提示词模板，对应 Skill 能力。

如果你需要把 MCP Server 暴露给其他程序调用，可以选择 HTTP 传输模式的 Server。此时可以像调用普通 REST 接口一样发送请求，但请求格式要遵循 MCP 协议规范。

6.2 通用 HTTP 调用示例

下面给出一个通用的 HTTP 请求模板，实际接口路径、请求体字段以你使用的 MCP Server 文档为准：

import requests url = "http://127.0.0.1:8931/mcp" # 端口仅为示例 payload = { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "browser_navigate", "arguments": { "url": "https://example.com" } } } response = requests.post(url, json=payload, timeout=30) print(response.json())

如果返回结果中包含result字段，说明 MCP Server 正常响应。不同 Server 支持的tools名称不一致，可以先调用tools/list方法查看可用工具列表。

6.3 批量任务的队列设计

批量测试任务建议按下面的思路组织：

# 生成测试数据 python scripts/generate_test_data.py --num 100 # 执行全部用例 pytest tests/ -v --workers 4 --html=reports/report.html # 失败用例单独重跑 pytest tests/ -v --lf --html=reports/report_retry.html

--workers需要安装 pytest-xdist 才能使用：

pip install pytest-xdist

--lf是 pytest 内置参数，表示只重新运行上次失败的用例。

6.4 失败重试策略

在 Pytest 中可以通过 pytest-rerunfailures 实现失败重跑：

pip install pytest-rerunfailures

用法：

pytest tests/ -v --reruns 2 --reruns-delay 1

重试适合解决浏览器偶发超时、元素加载慢等问题。但要注意，如果断言逻辑本身有 bug，重试多少次都无法解决，需要人工介入。

7. 资源占用与性能观察

7.1 观察目标

• MCP Server 进程的 CPU 和内存占用。
• 浏览器实例数量，避免并行执行时打开过多浏览器导致内存不足。
• Pytest 用例执行耗时，是否有明显变慢的用例。
• MCP 请求的超时和失败比例。

7.2 常用命令

Windows 下查看 MCP 相关进程：

tasklist | findstr node tasklist | findstr python

Linux / macOS 下：

ps aux | grep -E "playwright|mcp|chromium" | grep -v grep

7.3 性能影响因素

• 页面加载速度：网络请求、静态资源数量都会影响用例耗时。
• 无头模式与有头模式：无头模式省资源，但排查问题时建议用有头模式看浏览器实际行为。
• 并行数量：并行数过高会导致浏览器进程抢占资源，反而更慢。
• 截图和视频录制：每步都截图会显著增加磁盘和内存占用，建议只在失败时截图。
• MCP 请求大小：如果 AI 频繁读取整个页面 DOM，上下文传输会很大，建议只抓取关键节点。

7.4 降低资源占用的做法

# 只截取失败截图 from pathlib import Path def on_failure(request): pass # conftest.py 中配置失败截图 def pytest_runtest_makereport(item, call): if call.when == "call" and call.excinfo is not None: page = item.funcargs.get("page") if page: screenshot_dir = Path("reports/screenshots") screenshot_dir.mkdir(parents=True, exist_ok=True) page.screenshot(path=f"reports/screenshots/{item.name}.png")

8. 常见问题与排查方法

8.1 最值得先排查的一类问题

MCP 相关配置问题占了大多数。建议第一次接入时，不要一上来就配置复杂的多 Server 环境，先把一个最简单的 MCP Server 跑通，再逐步增加技能和自动化用例。确认链路通的标准是：AI 能真正打开一个页面，而不是只给你一段代码。

9. 最佳实践与使用建议

9.1 先建立最小闭环

第一次尝试时不要直接上手复杂的业务流程测试。先跑通三件事：

1. Pytest 能执行用例。
2. MCP Server 能被 AI 客户端连接。
3. AI 能驱动浏览器并返回执行结果。

这三步通了，后面的流程设计才有意义。

9.2 让 AI 只做擅长的事

AI 在 WEB 自动化测试中适合做：

• 根据页面结构生成选择器和断言。
• 根据失败日志定位问题。
• 批量生成测试数据的脚本。
• 整理测试报告。

AI 不适合做：

• 在没人审查的情况下直接操作生产环境。
• 处理复杂的业务规则判断，尤其是涉及金额、权限的部分。
• 作为唯一的测试结果裁决者，最终判断必须看人工复核。

9.3 把经验沉淀到 Skills 里

建议按照测试流程拆分 Skills：

• 登录技能：统一的登录操作。
• 数据准备技能：构造测试账号、测试数据。
• 页面检查技能：检查某个核心模块是否正常。
• 报告生成技能：汇总测试结果并输出 Markdown 报告。

这样做的好处是，后续再让 AI 跑新的测试用例时，不再需要重复解释业务流程，直接调用对应 Skill 即可。调用链路会更短，出错的概率也明显降低。

9.4 日志和故障恢复

批量任务必须加日志。推荐在conftest.py里做这些事：

• 记录每条用例的开始时间、结束时间、结果。
• 失败时截图并保存页面 HTML。
• 将 MCP Server 的调用日志单独保存。
• 重试逻辑只在确认网络抖动或元素定位偶发失败时开启，避免把真正的 bug 掩盖掉。

9.5 合规提醒

使用 AI Agent 驱动浏览器做自动化，要注意：

• 登录态和 Cookie 属于敏感信息，不要写死在代码或提示词里，使用环境变量注入。
• 不对未授权系统做自动遍历、批量拉取数据。
• 涉及用户个人信息、支付页面等场景，必须限制自动化操作范围，只做白名单内的验证步骤。
• 自动生成的测试代码发布前要人工 review，尤其是删除类、提交类操作。

10. 总结与下一步

这套 Pytest + Skills + MCP 的自动化组合，最值得尝试的点是它把 AI 从“代码生成器”变成了“能动手的执行者”。AI 可以直接操作浏览器、读取页面反馈、修改用例、跑测试、给结论，这比单纯的提示词工程更贴近实际测试工作流。

第一次运行建议先验证下面三个能力：

• MCP Server 能否被 AI 客户端正常调用。
• AI 能否根据页面实际 DOM 生成可运行的 Playwright 用例。
• Pytest 失败用例能否通过 AI 读取页面状态自动定位原因。

最容易踩的坑集中在 MCP Server 配置和浏览器驱动安装两部分。建议先本地把最小链路跑通，再逐步加批量任务和 Skills。

后续可以继续扩展的方向包括：把整套流程接入 CI 管道实现定时回归、结合已有的测试平台统一管理用例、将 Skills 按业务域拆细形成团队共享的测试资产。这套链路的上限不是工具本身，而是你能沉淀出多少可靠的自动化流程。