Skill+MCP 驱动 APP 自动化测试：从环境搭建到流程固化

SkillMCP 用来做 APP 测试这件事值得认真聊一次。原因很简单AI 测试已经不再停留在“让 AI 写用例”“让 AI 生成代码”的层面而是开始真正接管设备操作。之前跑 APP 自动化离不了 Appium、ADB、坐标定位、元素选择器、测试报告这一整套东西现在用 MCP 把设备操作变成模型可以调用的工具再用 Skill 把测试经验固化成流程AI 能直接完成从打开页面、输入数据、点击验证到输出报告的一条链路。这篇内容会围绕环境搭建、MCP Server 接入、Skill 设计、批量回归和常见排错展开适合已经在接触 AI 测试、或者准备往 AI 测试方向走的测试工程师。最值得关注的点不是工具本身多新鲜而是怎么把模型、设备、测试数据、断言规则组合成一套稳定、能复现的流程。1. 先把概念摆正Skill、MCP 和 AI 测试之间的分工很多同学第一次接触“SkillMCP 玩转 APP 测试”时第一反应是MCP 是什么Skill 是什么这俩是不是同一个东西其实不是而且它们俩的关系是组合不是替代。1.1 MCP 是“让模型能操作工具”的协议MCP 全称是 Model Context Protocol翻译过来叫“模型上下文协议”。它的作用是给大模型提供一套标准化的方式去访问外部工具和数据源。以前模型只能在一个对话框里生成文字顶多配合一些内置插件有了 MCP 之后模型可以通过客户端去调用外部 Server 暴露出来的工具比如查数据库、访问文件系统、调用测试接口、操作浏览器、执行 ADB 命令。放到 APP 测试场景里MCP Server 就是那一层“工具代理”。你在终端里怎么用 ADB 点手机MCP Server 就怎么把“点击坐标”“输入文本”“查看当前页面层级”“截图”这些能力封装成一个个工具函数。模型在对话里说“我想点击登录按钮”客户端把它翻译成一个 MCP 工具调用最终落到真机上的执行。1.2 Skill 是“把测试经验写成模型能执行的任务模板”Skill 解决的是另一个问题模型知道了有哪些工具可用但不等于知道“测试该怎么干”。一个没有经验的模型你给它点击、输入、截图的工具它也能折腾一会儿但不会自然地想到先确认页面加载完成、再检查用户名输入框是否可点击、登录失败时要截图保存证据。这些测试经验需要被显式地写出来。Skill 就是这样一个“可复用任务模板”里面包含目标描述、使用条件、步骤清单、断言规则、常见异常处理甚至还可以附带脚本和数据文件。在 Claude 这类产品里Skill 通常是通过在项目中放置SKILL.md文件来实现的在其他平台或自研 Agent 里它叫法可能不同比如“技能”“工作流”“提示词模板”但核心思想一致把固定的执行套路沉淀下来让模型每次执行都不要从零开始“发明”测试步骤。1.3 两者不是替代关系而是分工关系一句话总结MCP 解决“模型能操作什么”Skill 解决“模型应该怎么做”。MCP Server 提供的是原子能力点击、输入、滑动、截图、读取 UI 层级、调接口。Skill 提供的是流程能力先做什么、后做什么、通过标准是什么、失败时如何处理。客户端负责把它们串起来比如 Claude Desktop、Codex CLI、Dify、或者你自己写的 Agent。如果一个项目只接 MCP、不写 Skill那模型会像一个“手里有工具箱但没图纸的新人”能干活但每次都要临时想结果不稳定如果只写 Skill、不接 MCP那 Skill 就是一份纯文字文档模型看得见操作对象但无法真正触达设备。1.4 这套组合在 APP 测试里具体带来了什么变化过去做一个 APP 冒烟测试通常流程是写脚本、配元素定位、跑回归、看日志、出报告。这套流程本身没问题但有几个痛点很现实。写脚本有门槛尤其是元素定位和等待逻辑新手容易在环境上卡一天。需求一改选择器和步骤就要跟着改维护成本高。“用 AI 写测试脚本”只是替代了写代码的人没有替代整个测试执行链路。Skill MCP 的变化在于模型不再“只写代码然后让人去跑”而是直接变成执行者。它自己看页面自己决定下一步自己调用 MCP 工具操作手机自己判断结果是否符合预期。测试执行过程不再是“脚本跑完再看结果”而是“模型像人一样操作一遍并在每一步留下证据”。从这个角度看AI 测试工程师的工作重点也从“写更多脚本”变成了“设计更好的 Skill、维护更可靠的 MCP 工具层、沉淀测试数据和断言规则”。2. 搭一套能用的最小环境设备、Server、客户端2.1 先准备 Android 设备或模拟器优先用真实手机第一次跑通不建议你直接上 iOS。iOS 的自动化依赖 WebDriverAgent、签名证书、Xcode 环境门槛明显更高。Android 这边只要一台能开 USB 调试的手机或者一个 Android 模拟器就可以开始最适合做最小验证。设备准备要点打开“开发者选项”和“USB 调试”。用数据线连接电脑手机弹窗选择“允许 USB 调试”。终端执行adb devices能看到设备 ID状态是device说明连接正常。如果状态是unauthorized说明手机上没点允许如果offline优先换数据线或重启 ADB。模拟器也可以但第一次测试我更推荐真机。原因很简单模拟器环境太“干净”很多真实问题不会暴露真机上的输入法弹窗、权限对话框、网络切换、页面加载速度才是你后面排查问题的主要战场。2.2 准备基础依赖Node.js、Python、ADBMCP 生态里很多客户端和服务端都基于 Node.js 或 Python 开发所以基础环境至少要有一个能用的语言运行时。最低配置可以参考依赖推荐版本作用Python3.10 及以上运行 FastMCP、自写测试 ServerNode.js18 及以上运行各类 MCP 客户端和社区 ServerAndroid SDK Platform-Tools尽量新提供 adb、uiautomator 命令adb版本不低于 33连接 Android 设备检查环境建议按顺序来python --version node -v adb --version这三个命令都能正常输出再继续往下走。这一步很重要因为后面所有“为什么跑不起来”的问题有一大半都出在基础环境不统一、版本太低或 PATH 配置不对。2.3 选择 MCP 客户端Claude / Codex CLI / Dify 还是自研MCP 是协议不是单一软件所以你需要一个“客户端”来装载模型、配置 MCP Server、运行 Skill。几个常见选择按你的实际场景来如果你只是学习 MCP 怎么工作想快速验证可以先用 Claude Desktop 或 Claude Code在配置里加一个 MCP Server。如果你平时用它写代码Codex CLI 也可以用来接 MCP适合在项目目录里放 Skill 文件测试过程中直接让 AI 看代码和改代码。如果你想把测试流程做成内部工具Dify 这类低代码平台也可以添加本地 MCP 服务把测试任务串成应用让业务同学也能触发。如果团队对数据安全要求高或者要跑多设备并发那就需要自己写一个轻量客户端或者直接写一个 Python 任务调度器把 MCP Server 和 Skill 作为执行单元。不建议第一轮就搞得太复杂。我的建议是先用一个带界面的客户端把 MCP Server 配置成功跑通一次工具调用再考虑自研和批量调度。2.4 用 FastMCP 自建一个最简 APP 测试 MCP Server社区里已经有现成的 MCP Server 可以操作浏览器比如 Playwright MCP它很适合 Web 端、H5 端测试。但原生 APP 测试能用的“通用 MCP Server”还没有那么统一。与其等别人的轮子不如先自己写一个最小的 ADB MCP Server既能帮你理解协议原理后面也方便扩展。下面是一个用 Python FastMCP 搭建的最简示例from mcp.server.fastmcp import FastMCP import subprocess mcp FastMCP(app-test-server) def run_adb(*args): cmd [adb] list(args) result subprocess.run(cmd, capture_outputTrue, textTrue, timeout20) if result.returncode ! 0: raise RuntimeError(result.stderr.strip()) return result.stdout.strip() mcp.tool() def device_status() - str: 查看当前连接的Android设备状态 return run_adb(devices) mcp.tool() def tap(x: int, y: int) - str: 点击指定坐标例如 tap(500, 1200) return run_adb(shell, input, tap, str(x), str(y)) mcp.tool() def input_text(text: str) - str: 在当前输入框输入文本只支持ASCII字符中文建议用剪贴板方案 return run_adb(shell, input, text, text) mcp.tool() def swipe(x1: int, y1: int, x2: int, y2: int, duration: int 300) - str: 从(x1,y1)滑动到(x2,y2) return run_adb(shell, input, swipe, str(x1), str(y1), str(x2), str(y2), str(duration)) mcp.tool() def dump_ui() - str: 导出当前页面的UI层级XML返回文件内容 run_adb(shell, uiautomator, dump, /sdcard/window_dump.xml) xml run_adb(shell, cat, /sdcard/window_dump.xml) return xml mcp.tool() def screenshot(path: str /sdcard/screen.png) - str: 截图并拉取到本地当前目录的screens文件夹 run_adb(shell, screencap, -p, path) run_adb(pull, path, ./screens) return screenshot saved启动方式pip install mcp python app_test_server.py注意这是最小示例生产环境还缺三块东西设备参数多设备时需要adb -s 设备号、超时和重试、日志记录。后面会单独讲。3. 从单条命令开始验证 MCP 能操作手机3.1 先确认设备连接和 Server 启动环境搭好之后第一轮测试不要想太多只验证一件事MCP Server 是否真的能通过模型调用设备。先独立确认三个层次设备层adb devices能识别设备。Server 层python app_test_server.py能启动不报导入错误和端口占用。客户端层在 MCP 客户端配置里能看到app-test-server并且工具列表里有tap、input_text、dump_ui、screenshot。如果工具列表是空的优先检查客户端配置里 MCP Server 的启动命令。不同客户端配置方式不同有的是command args有的需要你指定.mcp.json文件路径。这一步最容易出问题也最常见。我一般会先用客户端自带的工具列表页看一眼确认工具都注册成功再开始对话。不要等到跑测试时才去查“为什么模型说没有点击工具”那会浪费很多时间。3.2 第一轮测试读取页面、点击、输入以测试一个登录页为例你可以给模型一条很简单的指令“使用 app-test-server 查看当前手机页面告诉我页面上有哪些可点击区域然后点击登录按钮。”但这里有个问题如果模型不知道当前 APP 有没有打开它执行dump_ui的时候看到的可能是桌面。所以更好的做法是先手工或通过命令把 APP 打开再让模型接管。打开 APP 的最小命令是adb shell am start -n 包名/Activity名如果不想手动查包名可以先执行adb shell monkey -p 包名 -c android.intent.category.LAUNCHER 1这里不展开所有命令重点在于执行顺序先启动 APP保证当前页面是目标页面。再调用dump_ui获取 UI 层级。模型看到 UI 层级后判断哪个节点是登录按钮估算坐标。调用tap点击。再调用dump_ui或screenshot验证页面是否变化。这个顺序很重要。你让模型“自动跑”模型天然会先看页面再操作但你的 Server 必须先提供“看页面”的能力而且 dump 出来的 XML 要足够完整。3.3 不要一上来就“让 AI 自己跑”要先建立断言很多同学第一次看到 AI 能点手机会很兴奋直接说“帮我完成整个登录测试”。结果模型点了一通可能点到了广告弹窗可能输入框没聚焦可能密码含特殊字符被 ADB 的input text拒绝最后它还会理直气壮地告诉你“测试通过”。问题出在哪不是因为模型笨而是因为你没有给模型定义“通过”的标准。AI 测试的最小闭环不是“模型操作了 APP”而是“模型操作了 APP并且每一步有明确的断言依据”。断言可以是点击登录按钮后当前页面是否出现了首页特征元素。输入错误密码时页面是否出现“密码错误”提示。截图和 UI dump 是否和预期一致。所以第一轮测试我会让模型每执行完一步都输出“做了什么、看到了什么、判断依据是什么”。这会让对话变长但能帮你确认模型到底有没有真正理解测试目标。如果你发现模型经常跳过验证步骤那问题不在模型在于 Skill 没写到位。第 4 部分就是在解决这件事。3.4 结果怎么判断截图 UI 层级 日志判断一次操作是否成功不要只看模型说“成功”。要看你留下的证据。我在本地会固定开一个screens目录和一个logs目录每次点击前截一张图。每次关键步骤后截一张图。每次 dump UI 都把 XML 存下来。模型每次调用 MCP 工具的参数和返回结果都记录到日志。这样即使模型最后判断错误你还能从截图和日志里找到真实原因。比如模型说“登录成功”但截图明明停在密码错误提示页那说明断言规则或元素识别有问题需要调整 Skill而不是继续让 AI 全自动跑。4. 把测试流程封装成 Skill一个登录冒烟测试的完整设计4.1 Skill 的目录结构和核心文件当你发现“让模型自由操作”不够稳定下一步就是把流程固化成一个 Skill。Skill 本质上是一个包含说明、脚本、模板、数据的文件夹。你不需要发明复杂框架只要确定目录结构然后让模型在每次执行前先读取这个 Skill 文件。一个参考结构skills/ login-smoke/ SKILL.md data/ accounts.json scripts/ check_login.sh assets/ expected_home.png其中SKILL.md是核心它用自然语言告诉模型这个 Skill 的目标、适用范围、执行步骤和断言规则。data放测试数据scripts放可复用脚本assets放参考截图或预期结果。在 Claude Code 这类工具里Skill 被放在项目.claude/skills目录下模型会自动发现在自研系统里你只需要让主 Agent 在任务开始时先读取指定路径的 Skill 文件效果是一样的。4.2 写 SKILL.md目标、触发条件、步骤、断言SKILL.md不是长篇大论而是要让模型能在一两次阅读里就抓到重点。内容可以分四块。目标这个 Skill 要验证什么。触发条件页面处于什么状态时可以使用。执行步骤从启动 APP 到最终判断按顺序写清楚。断言规则每一步通过的标准是什么。示例# 登录冒烟测试 Skill ## 目标 验证登录功能的基础链路是否可用。 ## 触发条件 手机当前处于登录页或者可以启动到登录页。 ## 执行步骤 1. 启动被测 APP。 2. 等待登录页加载完成调用 dump_ui 确认页面包含用户名输入框和密码输入框。 3. 从 data/accounts.json 读取第一个账号数据。 4. 点击用户名输入框输入用户名。 5. 点击密码输入框输入密码。 6. 点击登录按钮。 7. 等待 2 到 5 秒调用 dump_ui 查看页面变化。 8. 如果页面出现首页特征元素记录“登录成功”否则记录“登录失败”并截图。 ## 判断规则 - 输入框存在UI 层级中 text 属性包含“用户名”或“手机号”。 - 登录成功出现首页底部导航、用户昵称等明确标识。 - 登录失败出现“密码错误”“账号不存在”等提示文案。注意不要让模型只依赖绝对坐标。UI 层级里的bounds属性会给出元素坐标优先让模型通过文本内容定位节点再取bounds中间点这样比硬编码坐标稳定很多。4.3 数据文件、脚本和“失败处理”测试数据单独放文件好处是你可以做参数化。同一个登录 Skill可以传入多组账号正常账号、错误密码、空账号、超长账号。Skill 本身不用改只要数据集不同。accounts.json示例{ cases: [ { name: normal_user, username: demo_user, password: test123, expect: login_success }, { name: wrong_password, username: demo_user, password: badpass, expect: login_failed } ] }除数据外Skill 里还要写失败处理。比如如果输入框没找到不要硬点先 dump_ui 看真实页面。如果出现系统权限弹窗调用tap点击“允许”然后继续。如果页面 10 秒没变化停止操作截图并记录超时。如果点击后页面卡死执行一次返回操作或者重启 APP 再试。有了失败处理模型才不会被某一个异常卡死也不会在错误状态里继续“假装成功”。4.4 从一次执行到多次复用Skill 写完后你可以用不同数据跑多轮。每轮执行时模型读一次 SKILL.md按步骤执行。你会发现模型执行越来越接近“模块化”同样的流程换数据、换环境、换设备都能跑。达到这个状态后可以把 Skill 版本化提交到 Git 仓库。每次 APP 改版、测试流程调整直接改 SKILL.md不用重写整套自动化代码。这里有一个经验Skill 不是越详细越好而是“刚好能让模型稳定复现”就好。太简略模型会自由发挥太冗长模型会忽略关键步骤反而增加上下文负担。我一般会控制在 50 到 100 行以内并且把“判断规则”放在最前面因为那是模型最容易出错的地方。5. 组合进阶UI 操作 接口校验 报告输出5.1 为什么 UI 通过不代表功能通过很多人会把“UI 操作成功”等同于“功能通过”这是一个常见误区。比如登录按钮点击后进入了首页UI 看起来是成功了。但如果后端接口返回 500只是前端做了容错处理或者用户登录态没有真正写入那下一个页面就会暴露问题。又比如你点了“提交订单”界面提示成功但数据库里根本没有这笔订单记录。所以当 Skill 跑稳定之后下一步是在测试流程里加入接口校验。MCP Server 里可以再暴露几个接口测试工具比如发起 HTTP 请求、检查状态码、检查响应字段。模型操作完 UI 后再通过 MCP 工具调接口把 UI 表现和后端数据做交叉验证。5.2 在 Skill 中加入接口断言和后置校验以登录测试为例UI 部分操作完成后可以追加两步从 MCP Server 的http_request工具发起登录接口请求检查状态码是否为 200。检查响应里是否包含token或user_id字段。如果 UI 成功但接口断言失败那基本可以确定是前端假提示或者状态同步问题。这个结论比只跑 UI 有价值的多了。SKILL.md里可以新增一段## 接口校验 - 调用 http_request 工具请求地址/api/login - 方法POST - 请求体{username: 参数中的用户名, password: 参数中的密码} - 通过条件返回状态码 200且响应体中包含 token 字段。这里不建议让模型在 Skill 里写死所有接口地址。更好的做法是把接口地址放在测试数据文件里或者通过环境变量注入。因为不同环境的域名不一样写死会让 Skill 难以复用。5.3 生成结构化报告而不是只看日志当测试任务变多看终端日志就变得很低效。你需要一个结构化报告。报告至少包含这些字段用例 ID测试名称设备信息执行时间每一步操作记录断言结果截图路径失败原因生成方式不强求。简单场景下可以让模型在 Skill 执行结束后把结构化结果写成一个 Markdown 文件复杂场景下可以写一个小脚本把 MCP 工具调用记录和 Skill 结果汇总成 JSON再渲染成 HTML 报告。示例输出{ case: normal_user, device: R58M12345, status: passed, steps: [ {action: dump_ui, result: found_username_input}, {action: input_text, result: ok}, {action: tap_login, result: ok}, {action: dump_ui, result: found_home_page} ], screenshots: [./screens/login_before.png, ./screens/home_after.png], error: null }有了 JSON你就能接上报系统、统计通过率、做趋势分析。如果只是自己学习先输出 Markdown 也够用。5.4 批量回归任务怎么组织批量回归和单条用例是两码事。不要觉得“AI 能跑一条就能自动跑一百条”。批量任务要额外考虑三件事输入列表多条用例怎么组织每次跑哪几条。失败处理某一条失败后是继续跑下一条还是直接中断。资源隔离多台设备并行时每个 MCP Server 是不是同一个进程会不会互相干扰。我的建议是先串行跑小批量比如 3 到 5 条用例观察平均耗时报错率。稳定后再考虑并行。并行时每台设备一个 MCP Server 实例或者给所有操作加一个device_id参数保证命令不会发到错误的机器。失败重试不要无限重试最多重试一次。重试前先截图记录失败现场。批量场景里最忌讳的是让模型在一个超长上下文里跑完所有用例。模型上下文是有限的UI dump 一多它就会“忘记”前面的判断。正确做法是每条用例独立执行让模型每次只处理一条用例结果写入报告后清空上下文或者重新启动一个子任务。6. 排错与边界遇到的问题大多不在模型而在设备6.1 通用排查顺序用 Skill MCP 跑 APP 测试遇到问题不要第一时间怀疑“模型智商不够”。我自己的排错顺序是设备、权限、Server、上下文、最后才是模型行为。现象优先排查方向MCP 工具列表为空客户端配置、启动命令、依赖版本模型说调用工具失败Server 日志、ADB 连接、设备鉴权点击无效坐标是否在当前页面、是否有弹窗遮挡输入中文乱码ADB input text 限制、输入法状态页面加载慢、超时网络状态、等待时间、加载策略模型前后不一致Skill 不够具体、上下文长度不够批量任务互相干扰多设备并发、Server 状态共享按这个顺序排查大多数问题都能快速定位。6.2 MCP 工具注册不上或超时先看这几项工具注册不上是新手最容易卡住的问题。常见原因有MCP Server 启动失败。先在终端手动启动一次看有没有明显报错。客户端配置里的启动命令不对。比如 Python 脚本需要python而不是python3Windows 下可能还需要配置环境变量。依赖版本不匹配。FastMCP 不一定兼容所有 Python 版本建议固定 Python 3.10 或 3.11。防火墙或网络拦截。本地stdio模式一般没这个问题但如果走SSE或HTTP模式就要检查端口和网络策略。Windows 下路径拼接问题。路径里有空格时客户端配置里的 command 要额外注意引号。超时问题则经常出现在 MCP Server 里有同步阻塞操作比如 ADB 命令执行超过 20 秒。你要在 Server 代码里加上超时并对超时场景返回明确提示而不是让模型猜。6.3 元素定位不到优先处理动态布局和输入法用dump_ui定位元素最常见的问题是页面布局还在加载XML 里没有目标节点。页面里有 WebView 或者 Flutter 渲染原生 UI dump 看不到内部元素。输入法弹窗遮挡坐标判断偏差。广告弹窗、权限弹窗改变了界面结构。处理方式先增加固定等待 2 到 3 秒再 dump。如果页面是 Flutteruiautomator dump拿到的 XML 可能只有语义节点不要强求它能识别所有控件必要时用图像匹配加坐标。输入文本时优先用 ADB 的剪贴板方案避免中文和特殊字符问题。adb shell input text不支持中文也容易在特殊字符上报错。点击前先看手机上是否弹了权限框如果弹了先处理弹窗再执行下一个动作。这些处理逻辑都可以写进 Skill 的失败处理部分。模型每次遇到异常会按规则执行而不是随机发挥。6.4 模型上下文有限长任务要拆成多个 SkillAI 执行 APP 测试不是没有限制。UI dump 的 XML 经常有几万行如果模型每操作一步都读一次完整 XML很快上下文就会超限上下文一满模型会丢失前面步骤判断就会漂移。应对办法控制 dump 范围。如果只看登录页就不要让模型分析整张页面 XML 里的所有节点只保留和当前任务相关的按钮、输入框、提示文案。拆解任务。把“登录冒烟测试”“注册流程测试”“头像上传测试”拆成多个 Skill每个 Skill 只做一件事。每个用例独立执行。批量回归时不要让模型在一个对话里完成全部用例。关键结果写入外部文件。模型不需要记住所有中间步骤关键是最后能读取报告文件或者把结果写到 JSON 里保存。如果任务本身复杂比如要完成一个“从注册到下单”的长链路那就把链路拆成几个 Skill注册 Skill、登录 Skill、下单 Skill。每个 Skill 的输入输出通过测试数据文件衔接而不是要求模型在同一段上下文里记住全部状态。6.5 关于“刷完即就业”说实话的部分回到标题里的“刷完即就业”我想说点实在话。Skill MCP 确实是 AI 测试方向里值得重点掌握的组合但它不是“看一遍就能找到工作”的快捷键。面试官真正会问的不是“你听说过 MCP 吗”而是MCP 和 Skill 有什么区别你如何在 AI 测试里保证结果稳定多条设备并发测试时怎么避免资源冲突UI 自动化失败率高了你怎么排查你会不会把一个测试流程抽象成可复用模板这些问题没有动手跑过几轮真实 APP 测试只靠刷课是答不出来的。我的建议是与其焦虑“2026 年是不是 AI 测试元年”不如把下面这套最小项目做出来——自建一个 MCP Server用一个登录页 Skill 跑通真机测试再写一份结构化报告。这个项目本身比任何“速成教程”都有说服力。7. 给测试工程师的三点进阶建议7.1 把协议和工具分层想清楚很多工程师是“用哪个学哪个”但真正能适应变化的人会先理解分层思想。底层是设备系统ADB、Appium、UI Automator、权限管理。中间层是 MCP Server把设备能力封装成工具接口。上层是 Skill 和 Agent把测试经验和流程沉淀下来。最上面是调度和报告批量执行、数据分析、结果展示。理解了这个分层你会发现以后就算 MCP 不再是主流或者出现了更先进的协议你沉淀下来的测试流程、断言逻辑、报告结构依然可以复用。技术会变分层思路不会变。7.2 从“会调 MCP”走向“会设计 Skill”AI 测试能力分三个层次会配置能接入 MCP Server能跑通 Demo。会调优能看懂日志能处理超时、元素定位、上下文超限。会设计能根据业务场景把测试经验抽象成 Skill让团队其他人也能复用。前两个层次花几天就能上手。第三个层次才是真正值钱的能力。它需要你理解测试对象、了解模型的能力边界、懂得怎样把判断规则写得足够稳定。如果你现在开始练最快的切入点是把你手头最常做的一个手工回归用例改写成 SKILL.md然后用 AI 执行三轮。第一轮记录问题第二轮修正断言第三轮看是否能稳定复现。三轮之后你就能深刻理解“为什么 Skill 不是提示词而是工程资产”。7.3 可以做的作品集方向如果是为了面试准备我建议你做一个包含完整过程的“测试项目”而不是只贴一个“AI 自动测试脚本”的链接。可以参考下面这个方向测试项目某开源商城 APP 的核心流程回归 - 设备一台 Android 真机 - 工具自建 MCP Server Playwright MCPWeb 管理端 - Skill登录、注册、加购、下单、订单查询 - 数据accounts.json 中 5 组不同用户数据 - 报告每次执行生成 JSON Markdown 报告 - 亮点处理了输入法弹窗、权限弹窗、页面加载超时三类问题面试谈到这个项目时不要只讲“我让它跑通了”。要讲清楚为什么自建 MCP Server、Skill 里断言规则怎么设计、批量执行时为什么不用一个长上下文、失败重试策略是什么。这些才是面试官判断你是否真做过的东西。7.4 长期来看测试工程师的核心护城河最后说一句可能不太“AI 味”的话工具会不断更新但测试的核心问题永远是“知道什么是对的”。模型能替你点击、输入、截图能帮你生成用例能执行重复回归但它不一定知道你产品的业务规则什么情况下允许注册什么情况下订单不能取消什么文案不能出现什么数据不能外泄。这些判断需要测试工程师沉淀成 Skill、整理成断言规则、维护成测试数据。所以未来 AI 测试工程师的真正工作不是“代码写得好”而是“业务规则摸得清、异常场景理得明、工具层搭得稳”。Skill MCP 是你把手上的测试经验变成模型能力的一条现实路径值得花时间认真跑一遍。