1. 项目概述当AI编程助手遇上UI自动化测试最近在折腾一个老项目的UI自动化测试重构传统的脚本维护起来实在让人头疼。每次页面元素一变就得满世界找定位器改完还得祈祷别的地方没被牵连。正好手头在用Cursor这玩意儿写代码的体验确实颠覆就琢磨着能不能让它来帮我搞定测试脚本的生成和维护。再加上Playwright这个现代浏览器自动化工具以及新兴的MCP协议感觉能拼凑出一个挺有意思的自动化测试新玩法。简单来说这个组合的核心思路是用Cursor作为AI驱动的“大脑”来理解和生成测试逻辑用Playwright作为可靠的“双手”来执行浏览器操作再通过MCP协议让它们俩能顺畅地“对话”和协作。这不仅仅是把AI当个代码补全工具而是让它深度参与到测试用例设计、脚本生成、元素定位甚至异常处理的全流程中。对于测试开发、前端工程师或者任何需要频繁与Web界面打交道的人来说这套组合拳能显著降低编写和维护自动化测试脚本的门槛和心智负担。你不用再死记硬背各种CSS选择器语法或者为复杂的异步等待逻辑焦头烂额可以把更多精力放在测试场景的设计和业务逻辑的验证上。2. 核心工具栈深度解析与选型考量2.1 Cursor不止于代码补全的AI编程伙伴很多人刚开始用Cursor觉得它就是个加强版的VS Code带了个厉害的AI补全。但用它来做UI自动化测试你得换个思路——把它当成一个能理解你意图的编程协作者。它的核心优势在于基于大模型的代码理解和生成能力这对于UI测试这种模式固定但细节繁琐的任务简直是天作之合。为什么选Cursor而不是其他AI工具首先它深度集成在IDE里上下文感知能力极强。当你在写一个Playwright测试文件时Cursor能看到你整个项目结构、已有的Page Object模型、甚至测试数据。你可以直接对它说“帮我在登录页面对象里加一个忘记密码的测试方法要包含邮箱格式验证。” 它生成的代码会直接引用你项目中已有的定位器和工具函数风格也和你之前的代码保持一致。其次它的“Chat with Workspace”功能允许你上传整个测试目录让它分析找出定位器重复、等待策略不一致等问题并提出重构建议。这相当于请了个随时待命的代码评审专家。注意Cursor的免费版本有使用次数限制对于重度自动化脚本编写可能会遇到额度问题。我的经验是在构思框架、设计复杂用例逻辑、或者解决棘手定位问题时使用它的对话功能对于简单的代码补全和修改用它的编辑指令Cmd/CtrlK会更节省额度。2.2 Playwright为现代Web而生的自动化利器在Selenium、Cypress和Playwright之间我最终坚定地选择了Playwright。原因很直接它对现代Web技术的支持最全面异步架构原生高效而且自带超可靠的自动等待机制。对于UI自动化测试来说稳定性是生命线而“元素未找到”是稳定性最大的杀手。Playwright的auto-wait功能会在执行操作如点击、输入前自动等待元素满足一系列可操作性条件如可见、启用、稳定等这省去了大量手写sleep或复杂等待逻辑的功夫。另一个关键点是它的多浏览器支持和网络拦截能力。一套脚本无需修改就能在Chromium、Firefox和WebKit上运行对于跨浏览器兼容性测试非常方便。而网络拦截功能允许我们模拟慢速网络、拦截特定API请求并返回Mock数据或者监听请求/响应来作为测试断言的一部分这让测试场景的构造能力上了个大台阶。与Selenium的对比Selenium的生态庞大但核心的WebDriver协议有时在面对复杂SPA应用时显得力不从心需要大量额外等待。Playwright直接通过DevTools Protocol与浏览器通信控制力更强执行速度也更快。与Cypress的对比Cypress的开发者体验很好但它在同源策略和iframe支持上曾经有局限新版本有改善且测试运行在浏览器内对于需要与外部系统交互的场景稍显复杂。Playwright的Node.js运行环境更灵活可以轻松集成其他后端服务或数据库操作。2.3 MCP连接AI与工具的关键协议MCP全称是Model Context Protocol你可以把它理解为一套让大语言模型安全、可控地使用外部工具和数据的“插座”标准。在这个项目里MCP扮演的角色是**“翻译官”和“安全员”**。没有MCP的时候你让Cursor去操作浏览器只能通过生成Playwright代码来实现。但有了MCP我们可以创建一个“Playwright Server”这个服务器暴露出一系列安全的操作比如goto(url),click(selector),get_text(selector)。然后通过MCP协议Cursor这样的AI客户端就能直接“调用”这些操作而不是生成代码。这带来了两个根本性的变化交互模式变革从“生成代码-执行代码”的离线模式变为“发出指令-立即执行并反馈”的交互模式。你可以像和人对话一样对AI说“去首页点击登录按钮在用户名框里输入‘test_user’。” AI通过MCP调用对应的服务器函数动作立刻在浏览器中发生并将结果成功或失败以及可能的页面文本返回给AI供它决定下一步操作。这使得基于自然语言的实时自动化流程编排成为可能。安全与控制MCP服务器定义了AI可以做什么不可以做什么。你可以严格控制AI能访问的URL范围比如只允许测试环境、能执行的操作类型禁止文件下载、系统操作等。这比让AI直接生成任意代码要安全得多尤其在企业环境中至关重要。为什么不是所有场景都需要MCP如果你只是需要AI批量生成一批静态的测试脚本那么直接用Cursor写Playwright代码就足够了MCP反而增加了复杂度。但如果你设想的是一个能理解自然语言测试需求、并动态执行探索性测试的AI智能体那么MCP就是必不可少的桥梁。它让AI从“编剧”变成了“导演兼演员”。3. 环境搭建与核心配置实战3.1 基础开发环境准备首先你需要一个Node.js环境建议LTS版本这是Playwright的运行基础。创建一个新的项目目录初始化并安装核心依赖mkdir ai-ui-automation cd ai-ui-automation npm init -y npm install playwright playwright/test这里我同时安装了playwright核心库和playwright/test测试运行器。后者提供了测试结构、断言、并行运行等更丰富的测试框架功能比单纯用playwright写脚本更规范。接下来安装Playwright所需的浏览器。不建议全局安装最好在项目内安装保证环境一致性npx playwright install chromium firefox --with-deps我通常只安装Chromium用于日常开发和调试因为速度最快。Firefox和WebKit可以在CI/CD流水线中按需安装用于兼容性测试。3.2 Cursor项目配置与优化打开Cursor进入刚才的项目目录。为了让Cursor更好地理解我们的项目并给出精准建议有几个配置技巧创建.cursorrules文件在项目根目录创建这个文件用于定义项目规范。这对于保持生成的测试代码风格一致非常重要。# .cursorrules - 使用 playwright/test 作为测试框架。 - 所有页面元素定位器优先使用 getByRole, getByText, getByLabel 等语义化定位器。 - 每个测试文件必须以 .spec.ts 或 .test.ts 结尾。 - 使用 test.describe 对相关测试用例进行分组。 - 每个测试用例使用 test 函数定义并包含描述性的标题。 - 在 beforeEach 钩子中初始化页面并在 afterEach 中截图如果失败。 - 使用 expect 进行断言语法为 expect(actual).toBe(expected)。利用.gitignore和playwright.config.ts提供上下文Cursor会读取这些配置文件来理解项目结构。确保你的playwright.config.ts配置完善比如设置了基础URL、超时时间、截图和视频存储路径等。这能帮助Cursor生成更符合你项目配置的代码。安装Cursor相关插件可选社区有一些增强Playwright开发的Cursor插件或代码片段可以进一步提升效率。3.3 构建一个简单的MCP Server概念验证为了演示MCP如何工作我们来构建一个最简单的、与Playwright交互的MCP服务器。这里使用Node.js和modelcontextprotocol/sdk。首先安装SDKnpm install modelcontextprotocol/sdk创建一个mcp-playwright-server.js文件const { Server } require(modelcontextprotocol/sdk/server/index.js); const { StdioServerTransport } require(modelcontextprotocol/sdk/server/stdio.js); const { chromium } require(playwright); class PlaywrightMCPServer { constructor() { this.server new Server( { name: playwright-mcp-server, version: 0.1.0, }, { capabilities: { tools: {}, // 声明我们将提供工具 }, } ); this.browser null; this.context null; this.page null; // 定义工具即AI可调用的函数 this.server.setRequestHandler(tools/list, async () { return { tools: [ { name: navigate_to, description: Navigate the browser to a specific URL, inputSchema: { type: object, properties: { url: { type: string, description: The URL to navigate to } }, required: [url] } }, { name: click_element, description: Click on an element using a Playwright selector, inputSchema: { type: object, properties: { selector: { type: string, description: The Playwright selector for the element } }, required: [selector] } }, { name: fill_input, description: Fill text into an input field, inputSchema: { type: object, properties: { selector: { type: string, description: Selector for the input }, text: { type: string, description: Text to input } }, required: [selector, text] } }, { name: get_page_text, description: Get the main text content of the current page, inputSchema: { type: object, properties: {} } } ] }; }); // 处理工具调用 this.server.setRequestHandler(tools/call, async (request) { const { name, arguments: args } request.params; try { let result; switch (name) { case navigate_to: if (!this.page) { await this.initBrowser(); } await this.page.goto(args.url, { waitUntil: networkidle }); result Navigated to ${args.url} successfully.; break; case click_element: await this.page.click(args.selector); result Clicked element with selector: ${args.selector}; break; case fill_input: await this.page.fill(args.selector, args.text); result Filled ${args.text} into ${args.selector}; break; case get_page_text: const text await this.page.textContent(body); result text ? text.substring(0, 500) ... : No text found; // 截断长文本 break; default: throw new Error(Unknown tool: ${name}); } return { content: [{ type: text, text: JSON.stringify({ success: true, result }) }] }; } catch (error) { return { content: [{ type: text, text: JSON.stringify({ success: false, error: error.message }) }] }; } }); } async initBrowser() { this.browser await chromium.launch({ headless: false }); // 调试时用有头模式 this.context await this.browser.newContext(); this.page await this.context.newPage(); } async run() { const transport new StdioServerTransport(); await this.server.connect(transport); console.error(Playwright MCP Server running on stdio...); } } const server new PlaywrightMCPServer(); server.run().catch(console.error);这个服务器暴露了四个基本工具导航、点击、输入和获取页面文本。AI客户端如配置了MCP的Cursor可以通过标准输入/输出与这个服务器通信调用这些工具。实操心得这是一个极简的示例。生产级的MCP服务器需要处理更复杂的错误、管理多个页面和浏览器上下文、添加资源过滤和安全策略如URL白名单并且最好以独立的守护进程运行。但上述代码清晰地展示了MCP如何将Playwright的能力“封装”成AI可安全调用的API。4. 工作流实战从需求到自动化脚本4.1 场景一利用Cursor快速生成基础测试脚本假设我们有一个简单的登录页面需要测试。传统的做法是打开Playwright文档手写定位器和操作。现在我们可以在Cursor里新建一个login.spec.ts文件然后直接对Cursor说“使用Playwright Test为以下登录场景编写测试访问本地服务器http://localhost:3000/login找到ID为username和password的输入框分别输入testexample.com和password123然后点击文本为‘Sign In’的按钮。断言登录成功后页面会跳转到/dashboard并且页面中包含‘Welcome’文本。使用beforeEach钩子初始化页面afterEach钩子在失败时截图。”Cursor很可能会生成如下结构的代码import { test, expect, Page } from playwright/test; test.describe(Login Page, () { let page: Page; test.beforeEach(async ({ browser }) { page await browser.newPage(); await page.goto(http://localhost:3000/login); }); test.afterEach(async ({}, testInfo) { if (testInfo.status ! testInfo.expectedStatus) { const screenshotPath testInfo.outputPath(failure-${testInfo.title}.png); await page.screenshot({ path: screenshotPath, fullPage: true }); } await page.close(); }); test(should login successfully with valid credentials, async () { // 使用语义化定位器这是Playwright推荐的最佳实践 await page.getByLabel(Username or email).fill(testexample.com); await page.getByLabel(Password).fill(password123); await page.getByRole(button, { name: Sign In }).click(); // 等待导航并断言 await expect(page).toHaveURL(/\/dashboard/); await expect(page.getByText(Welcome)).toBeVisible(); }); test(should show error message with invalid credentials, async () { // Cursor同样可以生成负面测试用例 await page.getByLabel(Username or email).fill(wrongexample.com); await page.getByLabel(Password).fill(wrongpass); await page.getByRole(button, { name: Sign In }).click(); await expect(page.getByText(Invalid username or password)).toBeVisible(); await expect(page).toHaveURL(http://localhost:3000/login); // 应停留在登录页 }); });你会发现Cursor不仅生成了代码还遵循了我们之前在.cursorrules里定义的规范优先使用了getByRole和getByText等更健壮的定位方式。这比手动编写快得多而且减少了语法错误。4.2 场景二通过对话让Cursor修复和优化脚本生成的脚本可能不完美。比如页面结构可能变了getByLabel找不到元素。这时你可以把错误信息或者测试失败的截图Playwright会自动附加到测试报告中提供给Cursor。你可以选中失败的测试代码块按Cmd/CtrlK调出编辑指令输入“这个测试失败了报错说找不到getByLabel(‘Username or email’)。请检查这个页面的HTML结构我可以提供部分HTML并改用其他更稳定的定位策略比如getByTestId如果存在的话或者使用getByPlaceholder。”Cursor会分析你提供的HTML片段然后建议修改定位器。它甚至可能会建议“我发现这个输入框有一个>常见失败现象可能原因排查步骤与解决方案Timeout Error超时1. 元素定位器失效。2. 页面加载过慢或网络请求未完成。3. 等待条件设置不当。1. 使用Playwright Inspector (playwright codegen) 重新录制验证定位器。2. 增加page.goto的timeout值或使用waitUntil: networkidle。3. 检查是否为动态加载内容改用page.waitForSelector或等待特定请求。Element not visible / not enabled1. 元素被遮挡或样式隐藏。2. 元素处于不可交互状态如disabled。3. 在iframe内未切换上下文。1. 使用page.locator(‘…’).hover()或强制点击{ force: true }谨慎使用。2. 检查元素属性或等待其变为可用状态。3. 使用page.frameLocator(‘iframeSelector’)来定位iframe内元素。Assertion Failed断言失败1. 期望值与实际值不符。2. 断言时机过早页面状态未稳定。1. 在测试运行中打印实际值 (console.log)或使用Playwright的page.pause()调试。2. 在断言前添加适当的等待或使用Playwright的异步断言expect().toPass()。Browser launch issues1. 浏览器未正确安装或版本不匹配。2. 系统依赖缺失多见于Linux CI环境。1. 运行npx playwright install重新安装。2. 在CI脚本中使用官方Docker镜像mcr.microsoft.com/playwright可避免环境问题。6.3 MCP Server连接与调用问题问题Cursor无法连接到MCP服务器或调用工具无响应。排查服务器是否正常运行确保你的Node.js MCP服务器脚本没有报错退出。检查是否有端口冲突或权限问题。Cursor配置是否正确在Cursor的设置中找到MCP服务器配置部分确保服务器启动命令和参数正确。通常是node /path/to/your/mcp-server.js。协议兼容性确保使用的modelcontextprotocol/sdk版本与Cursor客户端兼容。查看双方的文档。工具调用权限在MCP服务器端检查工具列表是否正确暴露并且工具调用的输入参数格式是否符合AI客户端发送的格式。可以在服务器代码中添加详细的日志来调试请求和响应。6.4 性能与稳定性优化建议测试隔离确保每个测试都是独立的。使用test.describe和test.beforeEach来为每个测试创建新的浏览器上下文Context而不是共享Page这样可以避免Cookie、LocalStorage等状态污染。选择性截图/视频虽然失败时截图很有用但录制所有测试的视频会极大影响性能和存储。在playwright.config.ts中配置video: ‘on-first-retry’或video: ‘retain-on-failure’。合理使用定位器坚持使用Playwright推荐的语义化定位器Role, Text, Label。它们比脆弱的CSS选择器如.container div:nth-child(3) button稳定得多。让Cursor生成代码时也强调这一点。Mock外部依赖对于支付网关、短信服务等不稳定或收费的外部接口使用page.route()进行拦截和Mock。你可以让Cursor帮你生成Mock响应“为这个测试编写一个page.route拦截当URL匹配到/api/payment时返回一个状态码为200、body为{“success”: true}的JSON响应。”这套由Cursor、Playwright和MCP组成的工具链其威力不在于完全取代测试工程师而在于将工程师从重复、繁琐的代码编写和定位器维护中解放出来。它改变了工作流的重心从“如何编写代码来实现测试”转向“如何清晰地描述测试意图和场景”。你需要培养的是精准描述需求、设计测试用例、以及分析和解决复杂异步问题的能力。AI负责将你的意图转化为可执行代码的草稿而你则负责审核、优化和赋予其灵魂——确保测试的可靠性、可维护性和对业务价值的覆盖。刚开始融合这些工具时可能会觉得有些别扭但一旦适应你会发现编写和维护UI自动化测试的效率和质量都得到了质的提升。