Skills + MCP + Playwright：AI 自动化测试的“假通过”怎么治？

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

上周帮一个团队看 AI 生成的 UI 自动化脚本。

脚本跑得很漂亮：打开页面、填表、点击提交，最后页面弹出“提交成功”，报告里一片绿色。

但测试同学顺手去后台查了一下——这笔申请根本没有创建成功。

原因并不复杂：前端 Toast 提示先出来了，接口实际返回异常；而 AI 生成的脚本把“看见成功提示”当成了唯一断言。

这类问题在研发团队接入 Coding Agent、AI 自动化之后，会越来越常见。

AI 很会“把流程跑完”，但不天然知道：

页面完成一次点击，和业务真正成功，不是一回事。

01 AI 写出了脚本，为什么还会出现假通过？
现在用 Codex、Claude Code 这类工具补一条 Playwright 脚本，已经很方便。

给它一个页面、一段需求描述，通常几十秒就能生成这样的代码：

def test_apply_refund(page):
page.goto("https://test.example.com/refund/apply")

page.get_by_label("订单号").fill("A20260831001")
page.get_by_label("退款原因").select_option("重复下单")
page.get_by_role("button", name="提交申请").click()

expect(page.get_by_text("提交成功")).to_be_visible()
它的问题在于：这段代码只验证了页面说自己成功了。

但在真实业务中，至少还可能出现几种情况：

点击后前端乐观更新，接口其实返回 500；
接口返回成功，但退款单没有正确落库；
落库成功，但状态机流转错误，例如本应是 PENDING，却直接进入了 CLOSED；
测试环境里残留旧数据，页面展示的是上一轮的结果。
所以，AI 自动化最危险的不是“脚本不会写”。

而是：脚本把错误的结果，当成了正确的验证标准。

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

02 给 AI 一个“UI—接口—业务状态一致性”Skill
解决这件事，不是每次都重新提醒 AI：

“不要只断言页面提示，还要校验接口和数据。”

更好的做法，是把这条测试原则固化成一个项目级 Skill。

例如，在仓库里放一个 ui-api-consistency/SKILL.md：

---

name: ui-api-consistency
description: 用于涉及创建、提交、支付、审批等关键业务操作的 UI 自动化测试

测试规则

1. 不允许只用 Toast、弹窗或按钮状态作为成功断言。
2. 必须捕获关键请求，并校验 HTTP 状态码和响应体关键字段。
3. 对创建类操作，必须通过业务查询接口验证最终状态。
4. 断言应覆盖：请求参数、接口响应、业务实体状态。
5. 测试失败时，输出 requestId、响应体和页面截图，便于定位。
   它的价值不在于多写了一个 Markdown 文件。

而在于以后无论是 Codex、Claude Code，还是团队里其他人调用 Agent 补脚本，都能沿用同一套质量规则。

Prompt 是一次性对话。 Skill 是可复用、可审查、可跟随项目演进的测试经验。

03 Playwright 负责操作，MCP 负责让 Agent 看见真实系统
有了规则，还要让 Agent 真正拿到验证业务结果的能力。

这时可以把能力拆开：

能力
在测试中的作用
Playwright
操作页面、监听网络请求、获取页面状态
MCP
连接 Swagger、测试数据服务、缺陷平台、业务查询接口等工具
Skills
固化什么时候必须做多层校验、失败后输出什么信息
Coding Agent
理解任务并组合调用这些能力，生成或维护测试代码
下面把刚才那条“假通过”脚本，改成真正能校验退款申请状态的版本：

import pytest
from playwright.sync_api import expect

@pytest.mark.e2e
def test_apply_refund_should_create_pending_refund(page, api_client):
order_no = "A20260831001"

page.goto("https://test.example.com/refund/apply")
page.get_by_label("订单号").fill(order_no)
page.get_by_label("退款原因").select_option("重复下单")

1. 点击动作和关键接口请求必须绑定

with page.expect_response(
lambda response: "/api/refunds" in response.url
and response.request.method == "POST"
) as response_info:
page.get_by_role("button", name="提交申请").click()

response = response_info.value

2. 校验接口真正成功，而不是只看页面提示

assert response.status == 201
payload = response.json()
refund_id = payload["data"]["refundId"]
assert payload["data"]["status"] == "PENDING"

3. 通过业务查询接口确认最终状态

refund = api_client.get(f"/api/refunds/{refund_id}").json()["data"]
assert refund["orderNo"] == order_no
assert refund["status"] == "PENDING"

4. 页面反馈只作为体验层补充校验

expect(page.get_by_text("退款申请已提交")).to_be_visible()
这段代码的核心不是“多写了几个断言”。

而是把一次业务提交，拆成了三个层次：

页面层：用户是否完成操作；
接口层：服务是否真正成功处理请求；
业务层：最终数据和状态是否符合规则。
这才是 AI 自动化在关键链路上应该有的测试思维。

04 这类 Skill，恰恰是团队接入 AI 后最该先沉淀的
很多团队一上来就让 AI 做“自动生成测试用例”“自动写脚本”。

真正跑一段时间才发现，难的不是生成，而是控制生成结果的质量。

建议优先沉淀这几类测试 Skills：

关键链路一致性 Skill：UI、接口、数据库或业务状态的联合校验；
失败归因 Skill：自动收集请求响应、日志、截图和 Trace，辅助区分产品 Bug、环境问题、脚本问题；
测试数据 Skill：生成数据、清理数据、避免测试之间互相污染；
需求风险分析 Skill：读取 PRD、历史缺陷和接口文档，输出高风险测试点；
回归报告 Skill：按团队规范汇总通过率、失败原因、风险项和发布建议。
Skills 不是替代测试工程师判断。

它做的是把那些反复验证过的判断标准，先交给 AI 严格执行。

当团队把这些规则逐步沉淀下来，AI 才不会只是“跑得很快的脚本生成器”，而会开始成为真正可控的质量协作对象。

图片

如果你现在正在接触 Codex、Claude Code、Skills、MCP 或 Playwright，不妨先问自己一个问题：

AI 帮我把测试跑完了，它验证的是页面表象，还是业务事实？

这两者之间，往往就是一条 Skill 的距离。

我们近期也会围绕 Agent、MCP、Skills、RAG 和 AI 自动化测试，持续拆解能够放进真实研发流程的测试场景。

推荐学习
智能化测试-测试用例生成公益训练营，从行业大模型特性讲起，带你搞懂AI测试的全链路：大模型能力评测、智能体Harness工程、Skill技能体系、CLI与MCP工具体系、RAG知识图谱——最后直接上手打造一个能自动生成测试用例的智能体。

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

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

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

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

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