用Playwright MCP + GitHub Copilot实现自动化脚本自动生成

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

我在3个迭代里，把27条E2E脚本的编写时间从28小时压到了90分钟

上个月产品扔过来一个需求：新上线的B端商户后台，要补全核心流程的E2E自动化回归集，一共27条用例，要求两周内交付完。

搁以前我得先开F12扒元素，挨个写选择器，填等待，补断言，光手写加调试至少要三个整天。这次我直接把Playwright MCP和GitHub Copilot串起来跑，三个迭代下来，整套27条脚本全部落地，总耗时90分钟，平均每条脚本不到3分半。

这篇我不聊环境配置的基础步骤，直接给你三个我在项目里真跑通的实战案例，从“第一次生成就翻车”到“零修改直接进CI”，每一步都是我踩完坑之后磨出来的落地流程。

Playwright mcp技术学习交流群

伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「Playwright mcp技术学习交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇

案例一：商户登录+短信验证码流程，从生成到可运行只用了7分钟

这个场景是整个后台的入口，以前手写的时候最头疼。短信验证码是动态的，前端元素还做了动态渲染，之前写的老脚本三天两头因为“获取验证码按钮未找到”挂掉。

这次我完全没碰选择器，全程只做了三件事。

第一步，我先手动打开浏览器，走完一遍登录流程，拿到了已经登录态的浏览器上下文，然后启动Playwright MCP，把当前页面的远程调试端口9222直接挂载到Copilot里。没有重新开无头浏览器，也没有让AI自己去走一遍登录，直接把真实可交互的页面状态喂给了它。

第二步，我在Copilot里只输入了一段非常具体的指令： “基于当前打开的商户登录页，生成一条Playwright测试脚本。覆盖三个场景：正常输入正确手机号和验证码登录成功；手机号格式非法时提示文案正确；验证码错误三次后账号锁定15分钟。不要硬编码验证码，调用我本地的短信Mock接口获取动态码，所有定位器优先用getByRole和getByLabel，不要用任何带动态class的CSS选择器。”

第三步，我等它生成完，扫了一眼代码，发现它自动做了三个我以前手写时经常忘的细节：

• 点击“获取验证码”之后自动加了toast提示的等待，等“验证码已发送”文案出现才往下走

• 验证码错误三次之后，自动刷新页面，重新尝试登录，断言锁定提示文案

• 每条场景结束之后自动调用后台的解锁接口清理测试数据，不会影响下一条用例执行

整个脚本从生成到第一次跑通，我只改了Mock接口的地址，全程7分钟。最绝的是上周前端把登录页的按钮样式全改了，class名换了一遍，这条脚本跑起来一点事都没有。

我后来翻了它生成的定位器，根本没有用任何.btn-login这种样式类，全是page.getByRole('button', { name: '获取验证码' })，完全免疫前端样式改动。

这个案例里的实战踩坑点

• 一开始我让它自己去生成获取验证码的逻辑，它直接写了个20秒的硬等待，跑起来极不稳定。后来我在指令里明确要求“等待toast提示出现再往下走”，它自动就把硬等待替换成了文本断言等待。

• 第一次生成锁定场景时，它忘了最后解锁账号，导致后面所有依赖登录的脚本全部卡在锁定状态。我在指令里加了“场景结束后清理数据”，第二次生成就自动补上了解锁接口调用。

案例二：商户订单全流程，12条关联脚本，零手工敲代码

这个是整个后台最复杂的流程：商户创建商品→提交订单→修改订单状态→导出订单报表。以前手写这一套关联脚本，光处理页面跳转和状态同步就要花四五个小时，中间稍微有一步状态不对，整条链路就全断了。

这次我没有一次性让它生成整条大流程，而是拆成了四个独立的小任务，用MCP的页面状态接力的方式跑。

第一步：生成“创建商品”脚本

我停在商品创建页，给Copilot指令：“生成创建商品的脚本，覆盖正常创建、商品价格为负数、商品名称超长三个场景。创建成功后自动记录新商品的ID到全局环境变量里。” 生成完直接跑通，商品ID自动存在了环境变量里，不用我手动去复制粘贴。

第二步：生成“提交订单”脚本

MCP带着刚才的浏览器上下文跳转到订单提交页，我直接告诉Copilot：“用刚才生成的商品ID，生成提交订单的脚本。覆盖正常提交、库存不足时拦截、重复提交幂等性三个场景。订单提交成功后把订单号存到环境变量。” 它自动从环境变量里读到了商品ID，直接拼进了订单提交的接口参数里，完全不用我在脚本里硬编码。

第三步：生成“修改订单状态”脚本

带着前面的订单号上下文，跳转到订单详情页，生成修改订单状态的脚本，覆盖待发货→已发货→已完成的完整状态流转，同时校验非法状态跃迁时系统的拦截提示。

第四步：生成“导出订单报表”脚本

最后停在订单列表页，生成导出脚本，断言导出的Excel文件里包含刚才创建的那条订单记录，文件行数和订单列表数量完全一致。

四个步骤跑下来，12条关联脚本全部生成完毕，全程我没有敲一行代码，只在最后检查了一遍环境变量的传递逻辑。整套脚本第一次完整跑通，耗时不到25分钟。

最惊喜的是它自动给每条脚本都加了独立的测试数据隔离，每个场景跑完之后自动把创建的商品和订单标记为已删除，不会在后台留下一堆垃圾测试数据。

这个案例里的实战踩坑点

• 一开始我图省事，让它一次性生成整条12步的大流程脚本，结果它中间跳了“选择商品规格”这一步，整条链路直接在提交订单时失败。后来拆成四个独立脚本接力，每一步都基于上一步的真实页面状态生成，再也没出现过跳步的问题。

• 第一次生成导出脚本时，它只断言了“导出按钮点击成功”，根本没校验导出文件的内容。我在指令里补了“下载文件后读取Excel内容校验订单号”，第二次生成直接自动调用了pandas库做文件断言，连依赖导入都给我写好了。

案例三：30分钟修复15条老脚本，全量适配前端大改版

上周前端做了一次全站组件升级，几乎所有页面的class名全部换掉了，之前手工写的15条老E2E脚本集体挂掉，CI pipeline直接红了一大片。

搁以前我得花至少半天时间，挨个打开F12，重新扒元素，替换所有失效的选择器，一条一条重新调试。这次我用Playwright MCP的自愈能力，30分钟就把15条脚本全部修完，全部重新跑绿。

我没有逐条去改老脚本，而是做了三件事：

1. 把所有失效的老脚本全部集中到一个目录里，启动MCP打开升级后的新页面，把新页面的可访问性树全部喂给Copilot。

2. 给它一条批量指令：“遍历当前目录下所有test_*.py文件，把所有失效的CSS选择器全部替换成基于getByRole和getByLabel的稳定定位器，保留原有所有断言和业务逻辑不变。”

3. 生成完之后批量执行一遍，失败的脚本自动触发自愈流程，从备选定位器里重新尝试，全部跑完之后输出修复报告。

最后15条脚本里，13条直接零修改修复完成，剩下2条因为页面结构改动太大，Copilot自动生成了新的步骤替换逻辑，我只微调了两个断言文本就全部跑通。前后总耗时30分钟，比我预估的时间快了十倍都不止。

修复完我翻了一遍生成的报告，它一共替换了47个老的CSS选择器，其中有21个是我以前写的带动态hash的垃圾定位器，这次全部换成了稳定的角色定位器。等于顺便给整套自动化脚本做了一次全面的质量升级。

这个案例里的实战踩坑点

• 一开始我直接让它批量修改，它把几个本来就正常的定位器也给换掉了，反而引入了新问题。后来我在指令里加了“只替换当前页面里找不到的失效定位器，正常工作的定位器保持不变”，就再也没出现过乱改的情况。

• 有两个页面是懒加载的，元素滚动到视口之外就找不到了，它生成的新定位器第一次执行失败。我在指令里补了“定位元素前先自动滚动到元素位置”，第二次生成就自动给所有操作前加上了scroll_into_view_if_needed()。

最后：我总结的三条实战铁律

跑了这么多真实场景下来，我发现很多人用Playwright MCP生成脚本效果差，根本不是工具不好用，是指令写得太懒了。

1. 永远不要说“帮我写一个登录脚本”，要说清楚“覆盖哪几个异常场景、用什么方式处理动态验证码、用哪类定位器、失败后怎么清理数据”。你给的约束越具体，生成出来的脚本越不用改。‌

2. 长流程永远拆成短片段接力，不要试图一次性生成几十步的大脚本。基于真实页面状态一步步往下生成，稳定性比大段脑补出来的代码高10倍。‌

3. 生成完别直接丢进CI，花30秒扫一眼断言。只要断言不是“页面200”，是真正落到业务数据和提示文案上的，这套脚本的长期稳定性就不会差。‌

我现在写E2E自动化的方式已经完全变了。我不再是天天扒F12改选择器的脚本搬运工，我只需要定义清楚测试规则、场景边界和断言标准，剩下所有枯燥的代码生成工作，全交给Playwright MCP和Copilot去完成。

以前你花3小时写脚本，现在你花3分钟定义规则，产出的脚本质量反而比你手写的更高。这才是自动化脚本自动生成真正该有的样子。

推荐学习

自动化智能体与测试用例生成课程，限时免费，机会难得。扫码报名，参与直播，希望您在这场课程中收获满满，开启智能自动化测试的新篇章！

关于我们

霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。