AI 测试在 2026 年前后已经不再停留在“让模型帮你写用例”这个阶段。真正被测试团队采用的是一套把 Agent、工具调用和测试流程组合起来的工作方式Skill 负责告诉 AI 怎么测MCP 负责让 AI 真正操作设备、读取页面、拿到可验证的结果。这篇文章从概念、环境、最小实现到排错和面试表达完整梳理 Skill MCP 做 APP 测试的落地路径。你会看到一套能跑通的最小案例也会明白为什么很多人把 Skill 和 MCP 混在一起却在实际项目中一用就乱。1. 先分清 Skill 和 MCP一个管“怎么测”一个管“用什么测”做 APP 测试时AI 面对的问题往往不是“不会写代码”而是两个更实际的问题不知道完整测试流程以及碰不到被测 APP 的真实设备。Skill 和 MCP 分别解决这两件事。1.1 MCP 解决的是“模型触不到真实系统”MCP 全称 Model Context Protocol是一套开放协议。它让 AI 应用、Agent 能够通过标准化的方式连接外部工具、数据源和系统能力。简单说MCP 是一个“工具插座”模型只需要知道某个 MCP Server 提供了哪些工具就能像调用函数一样让 MCP Server 去执行真实操作再把结果返回给模型。在 APP 测试场景里MCP Server 可以暴露的能力非常具体通过 adb 获取当前连接的 Android 设备列表。启动或停止被测 APP。获取当前页面的 UI 层级返回 XML 结构。在指定坐标执行点击、长按、滑动。输入文本、清理输入框。截取当前屏幕并保存图片。读取设备日志并过滤关键字。如果没有 MCP模型只能生成测试代码片段能不能跑、跑在哪台设备上完全不可控。有了 MCP模型可以把每一步操作委托给真实可执行的工具从而拿到可验证、可回溯的结果。1.2 Skill 解决的是“模型不知道测试流程”Skill 是近两年在 Agent 平台中普及的一种能力组织方式它解决的是“模型知道能调用工具但不知道按什么顺序调用更合理”的问题。一个 Skill 通常是一个文件夹里面包含一份SKILL.md描述文件和若干辅助脚本、提示词、测试数据。SKILL.md定义了这个 Skill 的适用场景、执行步骤、注意事项和输出要求。Agent 在收到用户任务后会根据任务描述判断是否需要加载某个 Skill然后按照 Skill 里的流程逐步执行。在 APP 测试中Skill 的价值是沉淀测试经验登录功能应该先做什么后做什么。什么时候应该等待页面稳定。出现弹窗和 Toast 时怎么处理。断言哪些信息才能判断测试通过。失败时应该保留哪些截图和日志。这些经验如果靠用户在每次任务里口头描述既不稳定也不可复用。写成 Skill 后测试团队可以把规范固化下来让不同的 AI 会话执行同一套标准流程。1.3 Skill 与 MCP 的分工组合两者的关系不是竞争关系而是互相配合。MCP 回答的是“我能调用什么”Skill 回答的是“我应该怎么调用”。一个真正能落地到 APP 测试的 AI 流程通常是这样的用户下发任务对指定 APP 执行一轮登录回归。Agent 读取对应的测试 Skill得到执行步骤和判断标准。Agent 根据 Skill 里的步骤按需调用 MCP Server 暴露的工具。MCP Server 通过 adb、Appium 或设备驱动完成真实操作。工具返回截图、页面 XML、日志或执行状态。Agent 对照 Skill 里的断言逻辑判断通过或失败输出报告。下面的表格可以快速区分两者维度SkillMCP本质可复用的流程、知识和脚本集合模型与外部工具之间的通信协议回答的问题怎么执行、按什么顺序做能调用什么工具、怎么连接系统存储位置Agent 的 Skill 目录通常是一个文件夹MCP Server 配置由模型运行时加载是否可执行代码可以包含脚本但主体是流程说明真正执行系统操作的代码在测试中的角色定义测试用例和回归规范操作设备、抓取页面、收集证据变更频率随测试规范迭代而更新随设备能力和工具链更新实际使用中两者必须同时存在。只有 Skill 没有 MCP模型说得头头是道但操作不了设备。只有 MCP 没有 Skill模型能调用工具却不知道先点哪里、后等多久、怎么判断结果。2. 搭建 Skill MCP 的 APP 测试最小环境理解了概念之后最好的验证方式是搭一套最小环境。下面这套环境以 Android 模拟器、adb和一个自建的 MCP Server 为例。学习阶段不需要买真机集群一台电脑加一个模拟器就能跑通全流程。2.1 需要准备的工具与版本搭建这套环境建议先确认本机具备以下组件组件作用说明Android SDK / adb与模拟器或真机通信需要把adb所在目录加入 PATHAndroid 模拟器作为被测设备也可以使用支持无线调试的真机Node.js 18运行 MCP Server示例使用 modelcontextprotocol/sdkClaude Code / Codex 等 Agent加载 Skill 并调用 MCP不同 Agent 对 Skill 和 MCP 的配置路径略有差异被测 APP 安装包提供测试对象示例中以com.example.sample作为占位包名这里要注意不同 Agent 平台对 Skill 的目录位置、MCP 配置文件格式、权限模型都有不同约定。下面示例用于说明思路实际项目要结合自己的平台版本和项目路径调整不要把示例配置直接复制到生产环境。安装完成后可以先执行一条最基础的命令验证 adb 是否可用adb devices正常输出会列出当前已连接的设备例如List of devices attached emulator-5554 device如果这里看不到设备后面所有 MCP 工具都会失败所以这是第一个检查点。2.2 创建 APP 测试 MCP ServerMCP Server 的本质是一个可以通过标准输入输出或 HTTP 与 Agent 通信的进程。下面用 Node.js 的modelcontextprotocol/sdk写一个最小示例暴露三个工具获取当前页面层级、点击指定位置、截屏。先创建一个工程目录mkdir app-test-mcp cd app-test-mcp npm init -y安装依赖npm install modelcontextprotocol/sdk zod npm install typescript types/node --save-dev创建src/index.ts实现一个通过adb操作设备的 MCP Serverimport { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { z } from zod; import { execSync } from node:child_process; function runAdb(args: string): string { return execSync(adb ${args}, { encoding: utf-8, timeout: 15000, stdio: [pipe, pipe, pipe], }); } const server new McpServer({ name: app-test-mcp, version: 0.1.0, }); server.tool( get_page_hierarchy, 获取当前 APP 页面的 UI 层级返回 XML 文本用于定位控件, {}, async () { const xml runAdb(exec-out uiautomator dump /dev/tty); return { content: [{ type: text, text: xml }], }; } ); server.tool( tap, 在屏幕上指定坐标执行点击x 和 y 是屏幕像素坐标, { x: z.number(), y: z.number() }, async ({ x, y }) { runAdb(shell input tap ${x} ${y}); return { content: [{ type: text, text: 已点击坐标 ${x}, ${y} }], }; } ); server.tool( screenshot, 截取当前设备屏幕返回截图文件路径, { savePath: z.string().optional() }, async ({ savePath }) { const target savePath ?? /tmp/app-test-${Date.now()}.png; runAdb(exec-out screencap -p ${target}); return { content: [{ type: text, text: 截图已保存到 ${target} }], }; } ); const transport new StdioServerTransport(); await server.connect(transport);这个示例的关键点有几个每个server.tool定义了一个 Agent 可调用的工具包含工具名、描述和参数。描述文本很重要Agent 会靠它判断什么时候该用哪个工具。execSync带超时避免 adb 长时间卡住导致 Agent 无响应。生产环境不建议直接用execSync拼接命令变量拼接前要做转义和校验。2.3 把 MCP Server 注册进 AgentMCP Server 写好后需要注册到 Agent 运行时。常见的做法是在项目或用户配置中增加mcpServers配置。下面以项目级.mcp.json为例{ mcpServers: { app-test: { command: node, args: [/path/to/app-test-mcp/dist/index.js], env: { ANDROID_HOME: /path/to/android-sdk } } } }配置完成后重启 Agent 会话让配置重新加载。之后可以在 Agent 对话中直接问“当前有哪些 MCP 工具”正常应该能看到get_page_hierarchy、tap、screenshot这三个工具。这里有个容易忽略的细节如果本地 adb 不在 PATH 中MCP Server 进程内执行adb会直接失败。建议在env中显式传入 adb 的完整路径或者在工具内部通过ANDROID_HOME解析 adb 位置。2.4 创建第一个测试 Skill 目录Skill 通常是一个包含SKILL.md的目录。先创建目录结构app-test-skill/ ├── SKILL.md ├── scripts/ │ ├── check_device.sh │ └── start_app.sh └── resources/ └── test_accounts.json其中scripts用于放一些可复用的辅助脚本resources用于放测试账号、测试数据等资源。SKILL.md是核心Agent 主要靠它理解任务上下文。下面是一个最小SKILL.md示例覆盖 APP 登录回归的主流程--- name: app-login-regression description: 针对移动端 APP 的登录功能执行回归测试。当用户要求验证登录、登出、登录失败提示时使用。 --- # APP 登录回归测试 ## 适用场景 - APP 发版后需要对登录链路做冒烟回归。 - 登录页 UI 或登录接口变化后做功能验证。 ## 执行步骤 1. 调用设备检查脚本确认至少有一台设备在线。 2. 启动被测 APP包名由环境变量 APP_PACKAGE 提供。 3. 等待 3 秒获取页面层级确认当前处于登录页。 4. 定位账号输入框和密码输入框输入测试账号。 5. 点击登录按钮。 6. 等待 3 秒后截图判断是否进入首页。 7. 分别验证三个分支 - 正确账号密码应进入首页。 - 错误密码应出现错误提示。 - 空账号登录按钮应不可用或给出校验提示。 8. 输出测试报告包含每步截图和结论。 ## 注意事项 - 每一步操作后都要截图失败时保留现场。 - 页面层级获取失败时先检查无障碍服务是否开启。 - 不要连续点击登录按钮等待时间不得少于 2 秒。需要特别说明的是description字段决定 Agent 会不会在相关任务中加载这个 Skill。描述写得越具体越容易被正确命中。如果描述写得太泛比如“APP 测试”Agent 在面对登录回归任务时可能不会加载它。3. 用 Skill 定义测试流程用 MCP 执行设备操作从概念搭建到真正执行关键一步是让 Skill 和 MCP 在同一个任务里形成配合。下面以一个具体需求为例说明对 Android 模拟器上的某个 APP 执行登录回归测试。3.1 从“登录回归”需求拆解测试步骤登录回归看似简单但拆解成可执行的流程后至少有八个步骤检查设备在线状态。启动被测 APP。等待页面加载。获取页面层级定位输入框。输入账号和密码。点击登录。等待跳转。截图判断结果补充分支验证。这八步就是 Skill 要固化的内容。MCP 工具要能支撑每一步。如果某个阶段缺少工具Agent 就会“卡壳”或者编造结果。所以设计 Skill 时要反向检查每一步对应的 MCP 工具是否存在。上面的流程对应关系如下测试步骤需要的 MCP 工具用途检查设备返回 adb devices 列表的工具确认测试环境可用启动 APP启动指定包名的工具拉起被测应用等待加载不必须可由 Agent 等待固定时长让页面稳定获取页面层级get_page_hierarchy定位控件和输入框输入账号密码input_text往输入框写入文本点击登录tap触发登录操作截图screenshot保存现场证据输出报告不必须Agent 自行生成文本汇总结果如果发现某个步骤没有工具就不应该把这个步骤写进 Skill。否则 Agent 只能假装完成测试报告没有任何可信度。3.2 SKILL.md 怎么写才能让 Agent 稳定执行实际编写 SKILL.md 时建议遵循几个原则一个 Skill 只覆盖一条测试链路。不要写“综合测试”这种大而全的 Skill。步骤要按时间顺序写明确前置条件。每条步骤尽量说明异常情况怎么处理。把断言写清楚不要只说“检查结果”。引用脚本时不写死绝对路径使用相对路径。测试账号不要直接写在 SKILL.md 里从resources或环境变量读取。下面是一个更规范的示例片段## 账号与密码读取 测试账号位于 resources/test_accounts.json结构如下 {valid: {username: test01, password: 123456}} 加载方式由 Agent 读取文件后填入工具参数。 不要打印完整密码到最终报告只保留后四位用于追溯。这样写的好处是测试数据可以单独更新无需修改 Skill 主体。而把密码遮蔽规则写进 Skill可以避免测试报告里泄漏敏感信息。3.3 MCP 工具如何支撑每一步操作要让上述流程真正跑通还需要补几个工具get_device_status、start_app、input_text。以start_app为例server.tool( start_app, 通过 adb 启动指定 Android 应用, { packageName: z.string() }, async ({ packageName }) { const result runAdb(shell monkey -p ${packageName} -c android.intent.category.LAUNCHER 1); return { content: [{ type: text, text: result || 已启动 ${packageName} }], }; } );实际项目中启动 APP 的方式还包括am start指定 Activity或通过深度链接拉起指定页面。用monkey的方式优点是能拉起应用默认入口缺点是无法精确指定某个页面。这个取舍要在 Skill 里说明避免 Agent 误以为start_app能直接进入登录页。3.4 一个完整任务从下发到结束的长什么样假设用户输入使用 app-login-regression skill对 com.example.sample 执行登录回归测试。Agent 的理想执行链路如下1. 读取 app-login-regression/SKILL.md获取七个执行步骤。 2. 调用 get_device_status确认 emulator-5554 在线。 3. 调用 start_app传入 com.example.sample。 4. 等待 3 秒。 5. 调用 get_page_hierarchy确认登录页元素存在。 6. 调用 input_text输入账号。 7. 调用 input_text输入密码。 8. 调用 tap点击登录按钮。 9. 等待 3 秒。 10. 调用 screenshot保存登录后截图。 11. 根据截图和页面层级判断是否登录成功。 12. 生成 Markdown 报告。这套链路看起来自然但要让 Agent 稳定执行还需要在 Skill 里写明“必须等待 2 秒以上”“截图必须是 png 并保存到指定目录”等约束。否则模型可能跳过等待或直接凭经验猜测结果。4. 运行验证与结果可回溯代码写完后最重要的不是“Agent 有没有执行”而是“测试结论能不能被验证”。下面给出验证方法和预期输出。4.1 启动 Agent 并执行回归测试如果你的 Agent 支持命令行启动可以在项目根目录执行类似命令claude然后在对话中输入使用 app-login-regression skill 对 com.example.sample 执行登录回归测试。观察 Agent 的思考过程和工具调用记录。此时重点检查两件事Agent 是否在第一步读取了 SKILL.md。是否按顺序调用了 MCP 工具而不是直接生成一段代码让你自己跑。如果 Agent 没有加载 Skill而是直接写脚本说明 Skill 的description与用户任务匹配度不够或者 Skill 目录没有被正确识别。4.2 期望输出与报告样例一个合格的测试报告至少应包含设备信息、APP 信息、执行时间、用例结果、证据文件路径和失败原因。示例# APP 登录回归测试报告 - 设备emulator-5554 - 系统版本Android 14 - APP 包名com.example.sample - 测试时间2026-02-18 10:30:00 ## 用例结果 | 用例 | 预期 | 实际 | 结果 | 证据 | | --- | --- | --- | --- | --- | | 启动 APP | 进入登录页 | 进入登录页 | 通过 | screenshot_001.png | | 正确账号登录 | 进入首页 | 进入首页 | 通过 | screenshot_002.png | | 错误密码登录 | 显示错误提示 | 显示错误提示 | 通过 | screenshot_003.png | | 空账号提交 | 给出校验提示 | 登录按钮不可用 | 通过 | screenshot_004.png | ## 失败分析 无 ## 设备日志关键字 无异常这里的每一条“通过”都要有截图或页面层级作为证据。如果 Agent 输出“通过”但没有任何证据这个结论就不应该被信任。4.3 验证测试结论不能只看“通过”AI 测试最大的风险是“假通过”模型根据经验推测结果而不是根据真实页面判断。规避办法有几种在 Skill 中明确要求“页面层级中出现某个关键节点才算通过”。对截图进行二次校验比如让模型描述截图中的关键元素。输出证据文件路径由人审或脚本核对。对比登录前后的页面层级确认确实发生了跳转。下面这段提示词约束可以写进 Skill 的注意事项判断登录成功时必须同时满足以下条件 1. 页面层级中不再出现 password 输入框节点。 2. 首页关键节点出现在页面层级中。 3. 截图文件中能看到首页标志性内容。 缺少任一条件都判定为失败不要凭经验猜测。4.4 学习环境、测试环境、生产环境的区别这套方案在本地跑通后千万不要直接搬到生产环境。三个环境的本质差异如下环境设备数量数据要求稳定性要求报告要求学习环境1-2 个模拟器模拟测试账号能跑通即可截图 文本报告测试环境多台真机/模拟器脱敏数据失败能自动重试和告警同步到测试管理平台生产环境受限或灰度设备严格权限控制必须可回滚、有熔断全量日志 监控指标生产环境还要额外考虑MCP Server 进程是否常驻、ADB 连接池是否复用、多设备并发时工具参数如何路由、日志如何收集、失败操作是否影响线上用户。这些不是一篇文章能覆盖的但至少要有意识。5. Skill MCP 做 APP 测试的常见坑实际跑过一套 AI 测试流程后下面这些坑几乎都会遇到。每个坑都给出现象、原因和解决办法。5.1 Agent 不按 Skill 执行现象用户要求执行登录回归Agent 却直接生成一段 Python 脚本没有读取 SKILL.md也没有调用 MCP 工具。可能原因Skill 目录位置错误Agent 没有识别到。description与用户任务表达不匹配。Agent 平台的 Skill 功能被禁用或需要手动开启。Skill 名称被识别到但 Agent 认为用户要求与描述无关。检查方式查看 Agent 启动日志确认 Skill 是否加载。在对话中直接问“有哪些 Skill 可用”。检查 SKILL.md 的 YAML front matter 是否有语法错误。处理建议将 description 改得更接近用户真实表达 description: 当用户希望验证 APP 登录、登出、登录失败、密码错误等场景时使用。5.2 设备操作类的 MCP 工具反复失败现象MCP Server 能启动但调用adb shell input tap或adb exec-out screencap时返回空结果或报错。可能原因adb 不在 MCP Server 的 PATH 中。设备离线或未授权。工具参数类型错误比如把字符串传给数字参数。模拟器不支持某些input命令。检查方式adb devices adb shell input tap 100 100 adb exec-out screencap -p /tmp/test.png处理建议在 MCP Server 中使用 adb 完整路径。在工具内部加入错误捕获返回明确错误信息。设备连接前先检查adb devices返回值无设备时不执行操作。5.3 页面层级不稳定导致定位不到控件现象get_page_hierarchy返回空或 XML 中找不到目标控件。可能原因被测 APP 开启了禁止 UI 自动化读取的配置。页面是 Flutter、React Native 等自绘引擎默认层级信息不足。无障碍服务未开启。页面还没加载完就执行 dump。检查方式adb shell settings get secure enabled_accessibility_services adb exec-out uiautomator dump /dev/tty处理建议在 Skill 中增加等待逻辑不要立即 dump。对 Flutter 应用尝试开启 Flutter 的 accessibility 支持。如果层级信息确实不可用退化为基于图片的 UI 识别或坐标断言。5.4 模型陷入循环或 token 消耗失控现象Agent 反复截图、反复调用工具迟迟不输出结论消耗大量 token。可能原因Skill 里的结论条件不够明确。断言要求过多模型一直在寻找“绝对可靠”的证据。MCP 工具没有超时某次 adb 调用长时间阻塞。Agent 对话历史过长模型丢失了已完成的步骤。处理建议在 Skill 中写明最大尝试次数例如“最多重试 2 次”。给 MCP 工具统一加超时限制。每一轮工具调用后让 Agent 记录已执行步骤下一步基于记录继续。设置单任务的 token 预算超过后停止并输出部分报告。问题现象常见原因检查方式处理建议不读 Skill目录或描述不匹配查看 Agent 日志修正 Skill 放置位置和 descriptionadb 工具失败环境变量或设备离线直接执行 adb 命令显式设置 adb 路径增加设备检查找不到控件自绘引擎或无障碍未开手工执行 uiautomator dump增加等待打开无障碍循环调用断言不明确、无超时查看 token 消耗和调用链限重试、限次数、加超时假通过只凭模型经验判断检查报告是否附带证据强制要求截图和层级双重校验6. 把 Skill MCP 沉淀成可复用的 AI 测试体系单个测试链路跑通只是开始。要让这套方案在团队里复用需要把它当成软件工程的一部分来管理。6.1 Skill 仓库与版本管理Skill 不是随笔写在文档里的提示词它应该进入 Git 仓库和代码一样走评审、测试、发布流程。建议目录结构ai-test-skills/ ├── skills/ │ ├── app-login-regression/ │ │ ├── SKILL.md │ │ ├── scripts/ │ │ └── resources/ │ └── app-payment-regression/ ├── mcp-servers/ │ └── app-test-mcp/ ├── docs/ │ └── how-to-add-a-skill.md └── tests/ ├── test_mcp_tools.py └── test_skill_structure.py每次修改 SKILL.md 都要说明变更原因比如“登录按钮在 iOS 端变成浮动按钮更新定位策略”。这样半年后回头看能知道每个版本为什么调整。6.2 测试用例分层和 Skill 粒度测试用例分层的思路同样适用于 Skill层级例子Skill 粒度执行频率冒烟启动、进入首页小 Skill步骤少每次发版功能登录、注册、搜索按模块拆 Skill每日回归核心路径全量验证组合多个 Skill每周探索随机路径和异常场景不用 Skill直接对话按需不要试图用一个万能 Skill 覆盖所有场景。粒度过大Agent 加载后不知道重点粒度过小Agent 频繁切换 Skill效率反而低。6.3 建立人审 AI 执行 日志留痕的质量闭环AI 测试的产出必须可信。建议建立三层保障工具执行层MCP Server 每次调用都记录参数、耗时、返回结果到日志文件。Agent 流程层保存每轮思考摘要和工具调用顺序。人工复核层AI 输出“失败”时人工直接看截图确认AI 输出“通过”但证据不足时标记为“待复核”。这套闭环可以让 AI 测试从“演示功能”变成“可交付的测试能力”。6.4 面试里如何讲清这套实践如果这是你准备展示给面试官的项目建议按这个顺序讲先说痛点传统 AI 生成测试代码的方式无法直接操作设备断言不可靠。再说方案用 MCP 暴露设备操作能力用 Skill 固化测试流程。举一个案例登录回归测试说清楚从任务下发到报告输出的全部链路。讲排错遇到过 Agent 不读 Skill、页面层级为空、adbcall 超时等问题怎么解决。讲工程化Skill 进 Git、MCP Server 加日志、报告可回溯。面试官如果追问“MCP 和直接把命令扔给模型有什么区别”可以回答MCP 提供了标准化、可复用的工具接入方式不依赖某个模型也不依赖提示词里写死命令Skill 则提供了可复用的流程两者组合才让 AI 测试从“随机对话”变成“确定性流程”。7. 可复用清单和扩展方向最后给出两份可以直接使用的清单以及后续可以继续深入的方向。7.1 AI 测试环境检查清单在开始执行任何 AI 测试任务前按这个清单检查[ ] 设备在线adb devices能看到目标设备。[ ] 设备授权设备列表中状态是device不是unauthorized。[ ] adb 路径MCP Server 能解析到 adb 命令。[ ] 被测 APP 已安装adb shell pm list packages | grep package。[ ] MCP Server 已启动Agent 中能看到工具列表。[ ] Skill 目录可用Agent 能看到对应 Skill。[ ] 测试账号可用resources中的数据格式正确。[ ] 截图保存目录存在避免运行时发现目录不存在。[ ] 日志目录已配置MCP 调用日志能落盘。7.2 新增一条测试链路时的落地顺序接到新需求时按下面顺序推进拆解测试步骤列出每一步需要的设备能力。检查 MCP Server 是否已有对应工具没有则补充。编写 SKILL.md先写主流程再写分支和断言。用最小场景验证主流程。补充分支用例和异常处理。输出一次完整测试报告确认证据完整。提交 Git写清变更说明。在测试环境试运行一周观察稳定性和 token 消耗。7.3 可以继续接入的扩展方向通过 Appium 替换底部 adb 命令获得更稳定的跨平台控件定位。接入页面性能采集工具在测试流程中记录启动耗时和 CPU 占用。将截图和日志同步到统一报告平台替代本地 Markdown。在 MCP Server 中封装无线连接能力减少 USB 线依赖。对 iOS 使用 idb 或 XCUITest 封装对应工具形成双端覆盖。将已经较稳定的 SKill 组合成更上层的测试编排形成“测试计划级”的 Skill。7.4 下一步建议Skill MCP 做 APP 测试最值得投入的方向不是继续堆工具而是把流程质量做扎实。能让 AI 测试长期可靠运行的不是某一次漂亮的对话而是可复用的 Skill、可观测的工具调用和可回溯的结果证据。如果你刚开始接触这套技术建议先拿登录链路练手把 MCP 工具、SKill 加载、报告生成全部走通再逐步扩展到支付、搜索、消息推送等场景。等到本地流程稳定后再考虑多设备并发、CI/CD 集成和测试平台对接。这条路径不依赖某一个 Agent 平台也不需要一开始就上重型测试框架关键是先把“模型 Skill 工具”三者之间的协作边界理清楚。 AI测试落地：Skill与MCP协同构建APP自动化测试流程
AI 测试在 2026 年前后已经不再停留在“让模型帮你写用例”这个阶段。真正被测试团队采用的是一套把 Agent、工具调用和测试流程组合起来的工作方式Skill 负责告诉 AI 怎么测MCP 负责让 AI 真正操作设备、读取页面、拿到可验证的结果。这篇文章从概念、环境、最小实现到排错和面试表达完整梳理 Skill MCP 做 APP 测试的落地路径。你会看到一套能跑通的最小案例也会明白为什么很多人把 Skill 和 MCP 混在一起却在实际项目中一用就乱。1. 先分清 Skill 和 MCP一个管“怎么测”一个管“用什么测”做 APP 测试时AI 面对的问题往往不是“不会写代码”而是两个更实际的问题不知道完整测试流程以及碰不到被测 APP 的真实设备。Skill 和 MCP 分别解决这两件事。1.1 MCP 解决的是“模型触不到真实系统”MCP 全称 Model Context Protocol是一套开放协议。它让 AI 应用、Agent 能够通过标准化的方式连接外部工具、数据源和系统能力。简单说MCP 是一个“工具插座”模型只需要知道某个 MCP Server 提供了哪些工具就能像调用函数一样让 MCP Server 去执行真实操作再把结果返回给模型。在 APP 测试场景里MCP Server 可以暴露的能力非常具体通过 adb 获取当前连接的 Android 设备列表。启动或停止被测 APP。获取当前页面的 UI 层级返回 XML 结构。在指定坐标执行点击、长按、滑动。输入文本、清理输入框。截取当前屏幕并保存图片。读取设备日志并过滤关键字。如果没有 MCP模型只能生成测试代码片段能不能跑、跑在哪台设备上完全不可控。有了 MCP模型可以把每一步操作委托给真实可执行的工具从而拿到可验证、可回溯的结果。1.2 Skill 解决的是“模型不知道测试流程”Skill 是近两年在 Agent 平台中普及的一种能力组织方式它解决的是“模型知道能调用工具但不知道按什么顺序调用更合理”的问题。一个 Skill 通常是一个文件夹里面包含一份SKILL.md描述文件和若干辅助脚本、提示词、测试数据。SKILL.md定义了这个 Skill 的适用场景、执行步骤、注意事项和输出要求。Agent 在收到用户任务后会根据任务描述判断是否需要加载某个 Skill然后按照 Skill 里的流程逐步执行。在 APP 测试中Skill 的价值是沉淀测试经验登录功能应该先做什么后做什么。什么时候应该等待页面稳定。出现弹窗和 Toast 时怎么处理。断言哪些信息才能判断测试通过。失败时应该保留哪些截图和日志。这些经验如果靠用户在每次任务里口头描述既不稳定也不可复用。写成 Skill 后测试团队可以把规范固化下来让不同的 AI 会话执行同一套标准流程。1.3 Skill 与 MCP 的分工组合两者的关系不是竞争关系而是互相配合。MCP 回答的是“我能调用什么”Skill 回答的是“我应该怎么调用”。一个真正能落地到 APP 测试的 AI 流程通常是这样的用户下发任务对指定 APP 执行一轮登录回归。Agent 读取对应的测试 Skill得到执行步骤和判断标准。Agent 根据 Skill 里的步骤按需调用 MCP Server 暴露的工具。MCP Server 通过 adb、Appium 或设备驱动完成真实操作。工具返回截图、页面 XML、日志或执行状态。Agent 对照 Skill 里的断言逻辑判断通过或失败输出报告。下面的表格可以快速区分两者维度SkillMCP本质可复用的流程、知识和脚本集合模型与外部工具之间的通信协议回答的问题怎么执行、按什么顺序做能调用什么工具、怎么连接系统存储位置Agent 的 Skill 目录通常是一个文件夹MCP Server 配置由模型运行时加载是否可执行代码可以包含脚本但主体是流程说明真正执行系统操作的代码在测试中的角色定义测试用例和回归规范操作设备、抓取页面、收集证据变更频率随测试规范迭代而更新随设备能力和工具链更新实际使用中两者必须同时存在。只有 Skill 没有 MCP模型说得头头是道但操作不了设备。只有 MCP 没有 Skill模型能调用工具却不知道先点哪里、后等多久、怎么判断结果。2. 搭建 Skill MCP 的 APP 测试最小环境理解了概念之后最好的验证方式是搭一套最小环境。下面这套环境以 Android 模拟器、adb和一个自建的 MCP Server 为例。学习阶段不需要买真机集群一台电脑加一个模拟器就能跑通全流程。2.1 需要准备的工具与版本搭建这套环境建议先确认本机具备以下组件组件作用说明Android SDK / adb与模拟器或真机通信需要把adb所在目录加入 PATHAndroid 模拟器作为被测设备也可以使用支持无线调试的真机Node.js 18运行 MCP Server示例使用 modelcontextprotocol/sdkClaude Code / Codex 等 Agent加载 Skill 并调用 MCP不同 Agent 对 Skill 和 MCP 的配置路径略有差异被测 APP 安装包提供测试对象示例中以com.example.sample作为占位包名这里要注意不同 Agent 平台对 Skill 的目录位置、MCP 配置文件格式、权限模型都有不同约定。下面示例用于说明思路实际项目要结合自己的平台版本和项目路径调整不要把示例配置直接复制到生产环境。安装完成后可以先执行一条最基础的命令验证 adb 是否可用adb devices正常输出会列出当前已连接的设备例如List of devices attached emulator-5554 device如果这里看不到设备后面所有 MCP 工具都会失败所以这是第一个检查点。2.2 创建 APP 测试 MCP ServerMCP Server 的本质是一个可以通过标准输入输出或 HTTP 与 Agent 通信的进程。下面用 Node.js 的modelcontextprotocol/sdk写一个最小示例暴露三个工具获取当前页面层级、点击指定位置、截屏。先创建一个工程目录mkdir app-test-mcp cd app-test-mcp npm init -y安装依赖npm install modelcontextprotocol/sdk zod npm install typescript types/node --save-dev创建src/index.ts实现一个通过adb操作设备的 MCP Serverimport { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { z } from zod; import { execSync } from node:child_process; function runAdb(args: string): string { return execSync(adb ${args}, { encoding: utf-8, timeout: 15000, stdio: [pipe, pipe, pipe], }); } const server new McpServer({ name: app-test-mcp, version: 0.1.0, }); server.tool( get_page_hierarchy, 获取当前 APP 页面的 UI 层级返回 XML 文本用于定位控件, {}, async () { const xml runAdb(exec-out uiautomator dump /dev/tty); return { content: [{ type: text, text: xml }], }; } ); server.tool( tap, 在屏幕上指定坐标执行点击x 和 y 是屏幕像素坐标, { x: z.number(), y: z.number() }, async ({ x, y }) { runAdb(shell input tap ${x} ${y}); return { content: [{ type: text, text: 已点击坐标 ${x}, ${y} }], }; } ); server.tool( screenshot, 截取当前设备屏幕返回截图文件路径, { savePath: z.string().optional() }, async ({ savePath }) { const target savePath ?? /tmp/app-test-${Date.now()}.png; runAdb(exec-out screencap -p ${target}); return { content: [{ type: text, text: 截图已保存到 ${target} }], }; } ); const transport new StdioServerTransport(); await server.connect(transport);这个示例的关键点有几个每个server.tool定义了一个 Agent 可调用的工具包含工具名、描述和参数。描述文本很重要Agent 会靠它判断什么时候该用哪个工具。execSync带超时避免 adb 长时间卡住导致 Agent 无响应。生产环境不建议直接用execSync拼接命令变量拼接前要做转义和校验。2.3 把 MCP Server 注册进 AgentMCP Server 写好后需要注册到 Agent 运行时。常见的做法是在项目或用户配置中增加mcpServers配置。下面以项目级.mcp.json为例{ mcpServers: { app-test: { command: node, args: [/path/to/app-test-mcp/dist/index.js], env: { ANDROID_HOME: /path/to/android-sdk } } } }配置完成后重启 Agent 会话让配置重新加载。之后可以在 Agent 对话中直接问“当前有哪些 MCP 工具”正常应该能看到get_page_hierarchy、tap、screenshot这三个工具。这里有个容易忽略的细节如果本地 adb 不在 PATH 中MCP Server 进程内执行adb会直接失败。建议在env中显式传入 adb 的完整路径或者在工具内部通过ANDROID_HOME解析 adb 位置。2.4 创建第一个测试 Skill 目录Skill 通常是一个包含SKILL.md的目录。先创建目录结构app-test-skill/ ├── SKILL.md ├── scripts/ │ ├── check_device.sh │ └── start_app.sh └── resources/ └── test_accounts.json其中scripts用于放一些可复用的辅助脚本resources用于放测试账号、测试数据等资源。SKILL.md是核心Agent 主要靠它理解任务上下文。下面是一个最小SKILL.md示例覆盖 APP 登录回归的主流程--- name: app-login-regression description: 针对移动端 APP 的登录功能执行回归测试。当用户要求验证登录、登出、登录失败提示时使用。 --- # APP 登录回归测试 ## 适用场景 - APP 发版后需要对登录链路做冒烟回归。 - 登录页 UI 或登录接口变化后做功能验证。 ## 执行步骤 1. 调用设备检查脚本确认至少有一台设备在线。 2. 启动被测 APP包名由环境变量 APP_PACKAGE 提供。 3. 等待 3 秒获取页面层级确认当前处于登录页。 4. 定位账号输入框和密码输入框输入测试账号。 5. 点击登录按钮。 6. 等待 3 秒后截图判断是否进入首页。 7. 分别验证三个分支 - 正确账号密码应进入首页。 - 错误密码应出现错误提示。 - 空账号登录按钮应不可用或给出校验提示。 8. 输出测试报告包含每步截图和结论。 ## 注意事项 - 每一步操作后都要截图失败时保留现场。 - 页面层级获取失败时先检查无障碍服务是否开启。 - 不要连续点击登录按钮等待时间不得少于 2 秒。需要特别说明的是description字段决定 Agent 会不会在相关任务中加载这个 Skill。描述写得越具体越容易被正确命中。如果描述写得太泛比如“APP 测试”Agent 在面对登录回归任务时可能不会加载它。3. 用 Skill 定义测试流程用 MCP 执行设备操作从概念搭建到真正执行关键一步是让 Skill 和 MCP 在同一个任务里形成配合。下面以一个具体需求为例说明对 Android 模拟器上的某个 APP 执行登录回归测试。3.1 从“登录回归”需求拆解测试步骤登录回归看似简单但拆解成可执行的流程后至少有八个步骤检查设备在线状态。启动被测 APP。等待页面加载。获取页面层级定位输入框。输入账号和密码。点击登录。等待跳转。截图判断结果补充分支验证。这八步就是 Skill 要固化的内容。MCP 工具要能支撑每一步。如果某个阶段缺少工具Agent 就会“卡壳”或者编造结果。所以设计 Skill 时要反向检查每一步对应的 MCP 工具是否存在。上面的流程对应关系如下测试步骤需要的 MCP 工具用途检查设备返回 adb devices 列表的工具确认测试环境可用启动 APP启动指定包名的工具拉起被测应用等待加载不必须可由 Agent 等待固定时长让页面稳定获取页面层级get_page_hierarchy定位控件和输入框输入账号密码input_text往输入框写入文本点击登录tap触发登录操作截图screenshot保存现场证据输出报告不必须Agent 自行生成文本汇总结果如果发现某个步骤没有工具就不应该把这个步骤写进 Skill。否则 Agent 只能假装完成测试报告没有任何可信度。3.2 SKILL.md 怎么写才能让 Agent 稳定执行实际编写 SKILL.md 时建议遵循几个原则一个 Skill 只覆盖一条测试链路。不要写“综合测试”这种大而全的 Skill。步骤要按时间顺序写明确前置条件。每条步骤尽量说明异常情况怎么处理。把断言写清楚不要只说“检查结果”。引用脚本时不写死绝对路径使用相对路径。测试账号不要直接写在 SKILL.md 里从resources或环境变量读取。下面是一个更规范的示例片段## 账号与密码读取 测试账号位于 resources/test_accounts.json结构如下 {valid: {username: test01, password: 123456}} 加载方式由 Agent 读取文件后填入工具参数。 不要打印完整密码到最终报告只保留后四位用于追溯。这样写的好处是测试数据可以单独更新无需修改 Skill 主体。而把密码遮蔽规则写进 Skill可以避免测试报告里泄漏敏感信息。3.3 MCP 工具如何支撑每一步操作要让上述流程真正跑通还需要补几个工具get_device_status、start_app、input_text。以start_app为例server.tool( start_app, 通过 adb 启动指定 Android 应用, { packageName: z.string() }, async ({ packageName }) { const result runAdb(shell monkey -p ${packageName} -c android.intent.category.LAUNCHER 1); return { content: [{ type: text, text: result || 已启动 ${packageName} }], }; } );实际项目中启动 APP 的方式还包括am start指定 Activity或通过深度链接拉起指定页面。用monkey的方式优点是能拉起应用默认入口缺点是无法精确指定某个页面。这个取舍要在 Skill 里说明避免 Agent 误以为start_app能直接进入登录页。3.4 一个完整任务从下发到结束的长什么样假设用户输入使用 app-login-regression skill对 com.example.sample 执行登录回归测试。Agent 的理想执行链路如下1. 读取 app-login-regression/SKILL.md获取七个执行步骤。 2. 调用 get_device_status确认 emulator-5554 在线。 3. 调用 start_app传入 com.example.sample。 4. 等待 3 秒。 5. 调用 get_page_hierarchy确认登录页元素存在。 6. 调用 input_text输入账号。 7. 调用 input_text输入密码。 8. 调用 tap点击登录按钮。 9. 等待 3 秒。 10. 调用 screenshot保存登录后截图。 11. 根据截图和页面层级判断是否登录成功。 12. 生成 Markdown 报告。这套链路看起来自然但要让 Agent 稳定执行还需要在 Skill 里写明“必须等待 2 秒以上”“截图必须是 png 并保存到指定目录”等约束。否则模型可能跳过等待或直接凭经验猜测结果。4. 运行验证与结果可回溯代码写完后最重要的不是“Agent 有没有执行”而是“测试结论能不能被验证”。下面给出验证方法和预期输出。4.1 启动 Agent 并执行回归测试如果你的 Agent 支持命令行启动可以在项目根目录执行类似命令claude然后在对话中输入使用 app-login-regression skill 对 com.example.sample 执行登录回归测试。观察 Agent 的思考过程和工具调用记录。此时重点检查两件事Agent 是否在第一步读取了 SKILL.md。是否按顺序调用了 MCP 工具而不是直接生成一段代码让你自己跑。如果 Agent 没有加载 Skill而是直接写脚本说明 Skill 的description与用户任务匹配度不够或者 Skill 目录没有被正确识别。4.2 期望输出与报告样例一个合格的测试报告至少应包含设备信息、APP 信息、执行时间、用例结果、证据文件路径和失败原因。示例# APP 登录回归测试报告 - 设备emulator-5554 - 系统版本Android 14 - APP 包名com.example.sample - 测试时间2026-02-18 10:30:00 ## 用例结果 | 用例 | 预期 | 实际 | 结果 | 证据 | | --- | --- | --- | --- | --- | | 启动 APP | 进入登录页 | 进入登录页 | 通过 | screenshot_001.png | | 正确账号登录 | 进入首页 | 进入首页 | 通过 | screenshot_002.png | | 错误密码登录 | 显示错误提示 | 显示错误提示 | 通过 | screenshot_003.png | | 空账号提交 | 给出校验提示 | 登录按钮不可用 | 通过 | screenshot_004.png | ## 失败分析 无 ## 设备日志关键字 无异常这里的每一条“通过”都要有截图或页面层级作为证据。如果 Agent 输出“通过”但没有任何证据这个结论就不应该被信任。4.3 验证测试结论不能只看“通过”AI 测试最大的风险是“假通过”模型根据经验推测结果而不是根据真实页面判断。规避办法有几种在 Skill 中明确要求“页面层级中出现某个关键节点才算通过”。对截图进行二次校验比如让模型描述截图中的关键元素。输出证据文件路径由人审或脚本核对。对比登录前后的页面层级确认确实发生了跳转。下面这段提示词约束可以写进 Skill 的注意事项判断登录成功时必须同时满足以下条件 1. 页面层级中不再出现 password 输入框节点。 2. 首页关键节点出现在页面层级中。 3. 截图文件中能看到首页标志性内容。 缺少任一条件都判定为失败不要凭经验猜测。4.4 学习环境、测试环境、生产环境的区别这套方案在本地跑通后千万不要直接搬到生产环境。三个环境的本质差异如下环境设备数量数据要求稳定性要求报告要求学习环境1-2 个模拟器模拟测试账号能跑通即可截图 文本报告测试环境多台真机/模拟器脱敏数据失败能自动重试和告警同步到测试管理平台生产环境受限或灰度设备严格权限控制必须可回滚、有熔断全量日志 监控指标生产环境还要额外考虑MCP Server 进程是否常驻、ADB 连接池是否复用、多设备并发时工具参数如何路由、日志如何收集、失败操作是否影响线上用户。这些不是一篇文章能覆盖的但至少要有意识。5. Skill MCP 做 APP 测试的常见坑实际跑过一套 AI 测试流程后下面这些坑几乎都会遇到。每个坑都给出现象、原因和解决办法。5.1 Agent 不按 Skill 执行现象用户要求执行登录回归Agent 却直接生成一段 Python 脚本没有读取 SKILL.md也没有调用 MCP 工具。可能原因Skill 目录位置错误Agent 没有识别到。description与用户任务表达不匹配。Agent 平台的 Skill 功能被禁用或需要手动开启。Skill 名称被识别到但 Agent 认为用户要求与描述无关。检查方式查看 Agent 启动日志确认 Skill 是否加载。在对话中直接问“有哪些 Skill 可用”。检查 SKILL.md 的 YAML front matter 是否有语法错误。处理建议将 description 改得更接近用户真实表达 description: 当用户希望验证 APP 登录、登出、登录失败、密码错误等场景时使用。5.2 设备操作类的 MCP 工具反复失败现象MCP Server 能启动但调用adb shell input tap或adb exec-out screencap时返回空结果或报错。可能原因adb 不在 MCP Server 的 PATH 中。设备离线或未授权。工具参数类型错误比如把字符串传给数字参数。模拟器不支持某些input命令。检查方式adb devices adb shell input tap 100 100 adb exec-out screencap -p /tmp/test.png处理建议在 MCP Server 中使用 adb 完整路径。在工具内部加入错误捕获返回明确错误信息。设备连接前先检查adb devices返回值无设备时不执行操作。5.3 页面层级不稳定导致定位不到控件现象get_page_hierarchy返回空或 XML 中找不到目标控件。可能原因被测 APP 开启了禁止 UI 自动化读取的配置。页面是 Flutter、React Native 等自绘引擎默认层级信息不足。无障碍服务未开启。页面还没加载完就执行 dump。检查方式adb shell settings get secure enabled_accessibility_services adb exec-out uiautomator dump /dev/tty处理建议在 Skill 中增加等待逻辑不要立即 dump。对 Flutter 应用尝试开启 Flutter 的 accessibility 支持。如果层级信息确实不可用退化为基于图片的 UI 识别或坐标断言。5.4 模型陷入循环或 token 消耗失控现象Agent 反复截图、反复调用工具迟迟不输出结论消耗大量 token。可能原因Skill 里的结论条件不够明确。断言要求过多模型一直在寻找“绝对可靠”的证据。MCP 工具没有超时某次 adb 调用长时间阻塞。Agent 对话历史过长模型丢失了已完成的步骤。处理建议在 Skill 中写明最大尝试次数例如“最多重试 2 次”。给 MCP 工具统一加超时限制。每一轮工具调用后让 Agent 记录已执行步骤下一步基于记录继续。设置单任务的 token 预算超过后停止并输出部分报告。问题现象常见原因检查方式处理建议不读 Skill目录或描述不匹配查看 Agent 日志修正 Skill 放置位置和 descriptionadb 工具失败环境变量或设备离线直接执行 adb 命令显式设置 adb 路径增加设备检查找不到控件自绘引擎或无障碍未开手工执行 uiautomator dump增加等待打开无障碍循环调用断言不明确、无超时查看 token 消耗和调用链限重试、限次数、加超时假通过只凭模型经验判断检查报告是否附带证据强制要求截图和层级双重校验6. 把 Skill MCP 沉淀成可复用的 AI 测试体系单个测试链路跑通只是开始。要让这套方案在团队里复用需要把它当成软件工程的一部分来管理。6.1 Skill 仓库与版本管理Skill 不是随笔写在文档里的提示词它应该进入 Git 仓库和代码一样走评审、测试、发布流程。建议目录结构ai-test-skills/ ├── skills/ │ ├── app-login-regression/ │ │ ├── SKILL.md │ │ ├── scripts/ │ │ └── resources/ │ └── app-payment-regression/ ├── mcp-servers/ │ └── app-test-mcp/ ├── docs/ │ └── how-to-add-a-skill.md └── tests/ ├── test_mcp_tools.py └── test_skill_structure.py每次修改 SKILL.md 都要说明变更原因比如“登录按钮在 iOS 端变成浮动按钮更新定位策略”。这样半年后回头看能知道每个版本为什么调整。6.2 测试用例分层和 Skill 粒度测试用例分层的思路同样适用于 Skill层级例子Skill 粒度执行频率冒烟启动、进入首页小 Skill步骤少每次发版功能登录、注册、搜索按模块拆 Skill每日回归核心路径全量验证组合多个 Skill每周探索随机路径和异常场景不用 Skill直接对话按需不要试图用一个万能 Skill 覆盖所有场景。粒度过大Agent 加载后不知道重点粒度过小Agent 频繁切换 Skill效率反而低。6.3 建立人审 AI 执行 日志留痕的质量闭环AI 测试的产出必须可信。建议建立三层保障工具执行层MCP Server 每次调用都记录参数、耗时、返回结果到日志文件。Agent 流程层保存每轮思考摘要和工具调用顺序。人工复核层AI 输出“失败”时人工直接看截图确认AI 输出“通过”但证据不足时标记为“待复核”。这套闭环可以让 AI 测试从“演示功能”变成“可交付的测试能力”。6.4 面试里如何讲清这套实践如果这是你准备展示给面试官的项目建议按这个顺序讲先说痛点传统 AI 生成测试代码的方式无法直接操作设备断言不可靠。再说方案用 MCP 暴露设备操作能力用 Skill 固化测试流程。举一个案例登录回归测试说清楚从任务下发到报告输出的全部链路。讲排错遇到过 Agent 不读 Skill、页面层级为空、adbcall 超时等问题怎么解决。讲工程化Skill 进 Git、MCP Server 加日志、报告可回溯。面试官如果追问“MCP 和直接把命令扔给模型有什么区别”可以回答MCP 提供了标准化、可复用的工具接入方式不依赖某个模型也不依赖提示词里写死命令Skill 则提供了可复用的流程两者组合才让 AI 测试从“随机对话”变成“确定性流程”。7. 可复用清单和扩展方向最后给出两份可以直接使用的清单以及后续可以继续深入的方向。7.1 AI 测试环境检查清单在开始执行任何 AI 测试任务前按这个清单检查[ ] 设备在线adb devices能看到目标设备。[ ] 设备授权设备列表中状态是device不是unauthorized。[ ] adb 路径MCP Server 能解析到 adb 命令。[ ] 被测 APP 已安装adb shell pm list packages | grep package。[ ] MCP Server 已启动Agent 中能看到工具列表。[ ] Skill 目录可用Agent 能看到对应 Skill。[ ] 测试账号可用resources中的数据格式正确。[ ] 截图保存目录存在避免运行时发现目录不存在。[ ] 日志目录已配置MCP 调用日志能落盘。7.2 新增一条测试链路时的落地顺序接到新需求时按下面顺序推进拆解测试步骤列出每一步需要的设备能力。检查 MCP Server 是否已有对应工具没有则补充。编写 SKILL.md先写主流程再写分支和断言。用最小场景验证主流程。补充分支用例和异常处理。输出一次完整测试报告确认证据完整。提交 Git写清变更说明。在测试环境试运行一周观察稳定性和 token 消耗。7.3 可以继续接入的扩展方向通过 Appium 替换底部 adb 命令获得更稳定的跨平台控件定位。接入页面性能采集工具在测试流程中记录启动耗时和 CPU 占用。将截图和日志同步到统一报告平台替代本地 Markdown。在 MCP Server 中封装无线连接能力减少 USB 线依赖。对 iOS 使用 idb 或 XCUITest 封装对应工具形成双端覆盖。将已经较稳定的 SKill 组合成更上层的测试编排形成“测试计划级”的 Skill。7.4 下一步建议Skill MCP 做 APP 测试最值得投入的方向不是继续堆工具而是把流程质量做扎实。能让 AI 测试长期可靠运行的不是某一次漂亮的对话而是可复用的 Skill、可观测的工具调用和可回溯的结果证据。如果你刚开始接触这套技术建议先拿登录链路练手把 MCP 工具、SKill 加载、报告生成全部走通再逐步扩展到支付、搜索、消息推送等场景。等到本地流程稳定后再考虑多设备并发、CI/CD 集成和测试平台对接。这条路径不依赖某一个 Agent 平台也不需要一开始就上重型测试框架关键是先把“模型 Skill 工具”三者之间的协作边界理清楚。