关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集上周帮一个团队看 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 自动化最危险的不是“脚本不会写”。而是脚本把错误的结果当成了正确的验证标准。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关键链路一致性 SkillUI、接口、数据库或业务状态的联合校验失败归因 Skill自动收集请求响应、日志、截图和 Trace辅助区分产品 Bug、环境问题、脚本问题测试数据 Skill生成数据、清理数据、避免测试之间互相污染需求风险分析 Skill读取 PRD、历史缺陷和接口文档输出高风险测试点回归报告 Skill按团队规范汇总通过率、失败原因、风险项和发布建议。Skills 不是替代测试工程师判断。它做的是把那些反复验证过的判断标准先交给 AI 严格执行。当团队把这些规则逐步沉淀下来AI 才不会只是“跑得很快的脚本生成器”而会开始成为真正可控的质量协作对象。如果你现在正在接触 Codex、Claude Code、Skills、MCP 或 Playwright不妨先问自己一个问题AI 帮我把测试跑完了它验证的是页面表象还是业务事实这两者之间往往就是一条 Skill 的距离。我们近期也会围绕 Agent、MCP、Skills、RAG 和 AI 自动化测试持续拆解能够放进真实研发流程的测试场景。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。