这次聊的方向比较新Skill MCP APP测试。它不是传统意义上的自动化测试框架教程而是把大模型智能体接入 APP 测试流程的工程思路。很多测试工程师已经能写脚本、跑用例但面对“AI 测试工程师”这个岗位要求时往往卡在同一个问题上模型到底怎么操作我的手机、怎么读取界面、怎么按流程执行用例MCP 解决的是工具接入问题Agent Skill 解决的是流程编排问题。两者组合起来可以让大模型不再只是“聊天窗口里的建议机器人”而是真正能调用设备、执行点击、读取控件、汇总结果的测试执行体。这篇文章会按一条完整链路展开先讲清楚 MCP 和 Agent Skill 在测试场景里分别扮演什么角色再给出环境准备、MCP Server 搭建、Skill 设计、功能测试、批量任务与接口服务、问题排查和工程化建议。下面是适合的读者画像已经在做 APP 功能测试或自动化测试、想了解 AI 测试落地方向、准备测试工程师面试时聊 AI 技能的读者。1. 核心能力速览能力项说明技术方向MCP 协议 Agent Skill APP 功能测试 / 自动化测试核心价值让大模型通过 MCP 调用真实测试工具通过 Skill 按固定流程执行测试任务主要功能设备发现、界面元素读取、点击输入操作、用例生成、断言汇总、批量回归硬件门槛常规开发机即可若使用本地大模型则需要对应 GPU若走云端模型 API 则对 GPU 无硬性要求操作系统Windows / macOS / Linux 均可以实际 MCP 客户端支持情况为准启动方式命令行启动 MCP Server或在 MCP 客户端配置文件中声明 server接口能力MCP 基于 JSON-RPC 暴露工具调用工具可被 AI 模型或外部脚本复用批量任务支持通过循环调用 MCP 工具或按 Skill 批量执行用例适合场景APP 冒烟测试、回归测试、用例生成、UI 自动化辅助、测试报告汇总有一个需要提前说明的点MCP 客户端、底层大模型、Agent Skill 的具体实现方式在不同平台有差异。下面的内容以通用思路为主具体命令和参数需要根据你选用的项目文档调整。2. 适用场景与使用边界Skill MCP 做 APP 测试比较适合这几类任务APP 冒烟测试启动应用、检查首页核心元素、走一遍关键路径。回归用例生成把历史用例文本喂给模型让模型拆成可执行的测试步骤再通过 MCP 工具去执行。UI 自动化脚本辅助维护模型帮忙定位控件、生成断言代码减少手写工作量。测试报告汇总让模型读取多个用例执行结果生成结构化总结和失败原因分析。接口与设备管理通过 MCP 工具统一管理多台测试机替代手动 adb 命令。也有不太适合直接用这套组合的场景需要强业务判断的复杂场景模型对业务规则的理解还有概率性复杂账务、合规链路不能全交给模型判断。高合规要求的生产环境操作不要在未授权环境下让 AI 自动执行账号操作、支付操作或数据修改。完全替代人工探索式测试模型适合执行已知流程不适合承担试探性、创造性测试的全部工作。使用边界必须强调涉及真机、账号、用户数据时必须先确认授权和隐私合规。测试数据要脱敏不能把生产环境账号、真实用户身份信息直接传给外部模型服务。录制、截图、日志如果包含敏感信息要注意存储和传播边界。3. MCP、Agent Skill 与 AI 测试的关系在实操之前先把概念理清楚。三个概念经常被放在一起聊但它们在测试链路中的位置完全不同。3.1 MCP 是什么MCP 的中文意思是“模型上下文协议”它做的事情是把模型与外部工具之间的调用方式标准化。标准的 MCP 结构里有一个 MCP Server负责暴露工具有一个 MCP 客户端负责把模型请求转发给 Server并把工具结果返回给模型。类比一下MCP Server 就像给模型准备的一套工具箱。工具箱里的每个工具都有名称、描述、参数格式、返回格式。模型阅读工具描述后决定用哪个工具、传什么参数然后等待结果。整个过程通过 JSON-RPC 完成。在 APP 测试场景里MCP Server 可以暴露这些工具get_devices获取当前 adb 能识别的测试设备列表。launch_app启动指定 APP。tap在指定设备上执行点击。input_text在输入框中输入文本。get_screen_text获取当前界面的可访问性文本。screenshot截取当前屏幕。这样一来模型不需要关心 adb 命令怎么写只需要调用 MCP 工具即可。3.2 Agent Skill 是什么Agent Skill 可以理解为“给模型预设的操作套路”。MCP 解决的是“模型能调用什么工具”的问题Skill 解决的是“模型应该按什么顺序调用这些工具”的问题。继续做类比MCP 是一套工具Skill 是使用这些工具的作业指导书。测试流程通常有先后顺序不能乱来。比如登录测试必须先打开 APP、再输入账号密码、再点击登录按钮、再断言是否跳转成功。如果没有 Skill 约束模型可能会跳步、漏步或者用错误的参数执行工具。有了 Skill模型会按照预设的步骤列表一步步执行。3.3 MCP 与 Skill 的区别维度MCPAgent Skill层次工具接入层提示词与流程层解决的核心问题模型怎么调用外部能力模型按什么策略完成任务表现形式MCP Server、工具函数提示词模板、步骤列表、规则集示例点击按钮、读取文本、启动 APP冒烟测试步骤、登录用例步骤、断言规则测试失败时的影响工具不可用、调用失败流程乱序、漏步骤、断言不严谨3.4 两者结合跑通 APP 测试在实际链路中两者是这样配合的用户输入测试请求 ↓ Agent大模型 上下文 ↓ 读取 Skill 中的步骤和规则 ↓ 按 Skill 步骤调用 MCP 工具 ↓ MCP Server 执行设备操作 ↓ 返回结果给 Agent ↓ Agent 判断结果、生成断言、输出汇总当用户说“对设备 emulator-5554 执行登录功能冒烟测试”时模型会先读取登录冒烟测试的 Skill看步骤是什么然后调用 MCP 工具完成“启动 APP - 输入账号 - 输入密码 - 点击登录 - 读取结果”整个过程模型不直接执行 adb 命令也不需要手工编写测试脚本而是通过工具层操作真实设备。这就是 Skill MCP 做 APP 测试的基本形态。4. 本地部署环境准备开始搭建之前先检查本机环境。这套链路对硬件要求不高普通开发机就能跑前提是装好依赖。4.1 软件环境推荐准备以下环境具体版本以你选择的 MCP 客户端和 SDK 文档为准Python 3.10 或更高版本。Node.js 16 或更高版本部分 MCP 客户端和工具依赖它。一个支持 MCP 的客户端比如 Claude Desktop、Cursor、Codex 或同类工具。Android 测试环境Android SDK Platform Tools确保 adb 可用。测试驱动Appium 或 uiautomator2用于控件读取和操作也可以直接用 adb 命令实现部分能力。如果测试 iOS需要 macOS 环境、Xcode 工具链和对应的驱动服务。4.2 硬件与设备一台开发机建议内存 16G 以上避免编译和运行测试服务时卡顿。一台 Android 测试机或模拟器开启开发者模式和 USB 调试。如果用本地大模型还需要对应的 GPU显存大小取决于模型规模如果走云端模型 API则对本地 GPU 没有硬性需求。4.3 环境检查清单在终端里执行下面的命令确认基础环境正常python --version pip --version node -v adb devices重点看adb devices的输出。如果列表里没有任何设备先解决设备连接问题再继续后面的步骤。常见原因是 USB 调试未开启、驱动未安装、模拟器端口未连接。4.4 网络与安全准备MCP Server 默认监听本地地址不要随意绑定到公网。如果模型走云端 API需要确认 API 访问正常但同时要注意测试数据的隐私边界。在团队协作场景建议把 MCP Server 部署在内网通过配置管理工具分发而不是直接把内部测试凭据暴露给外部服务。5. 从零搭建 MCP Server这一节的目标是写出一个最小可用的 MCP Server暴露几个 APP 测试常用工具。实际项目里工具内部可以替换成 adb 命令、Appium 调用或自研的测试框架封装。5.1 安装依赖假设使用 Python 生态需要安装 MCP 相关的 Python SDK。命令如下pip install mcp不同版本 SDK 的 API 略有差异下面的代码基于常用写法如果接口有调整以官方 SDK 示例为准。5.2 编写 MCP Server创建一个文件app_test_server.py内容如下from mcp.server.fastmcp import FastMCP mcp FastMCP(app-test-mcp) mcp.tool() def get_test_devices() - list: 获取当前可用的测试设备列表。 # 真实场景调用 adb devices 解析设备序列号。 # 这里只返回示例结构实际项目需要替换为 adb 命令执行结果。 return [ {serial: emulator-5554, status: device}, {serial: emulator-5556, status: device}, ] mcp.tool() def launch_app(device_serial: str, package_name: str, activity_name: str) - str: 在指定设备上启动一个 APP。 # 真实场景执行 adb shell am start -n package_name/activity_name。 return flaunched {package_name} on {device_serial} mcp.tool() def tap_element(device_serial: str, x: int, y: int) - str: 在指定设备上点击坐标。 # 真实场景执行 adb shell input tap x y。 return ftapped {device_serial} at ({x}, {y}) mcp.tool() def get_screen_text(device_serial: str) - str: 获取指定设备当前界面的文本内容。 # 真实场景执行 uiautomator dump 并解析 XML 文本。 return 示例界面文本实际项目中替换为控件树解析结果 if __name__ __main__: mcp.run()启动方式python app_test_server.py这里有几个关键点每个工具函数必须有清晰的中文或英文描述模型会根据描述决定是否调用。参数要定义完整缺少必填参数会导致工具调用失败。工具函数内部的 adb 命令、Appium 调用在实际项目中需要自己封装示例代码只是骨架。5.3 在 MCP 客户端中配置 Server打开 MCP 客户端的配置文件把刚才写的 Server 注册进去。通用配置格式如下{ mcpServers: { app-test-mcp: { command: python, args: [D:/projects/app_test_server.py], env: {} } } }注意替换args里的绝对路径。某些客户端要求command写 Python 解释器的绝对路径Windows 下可能是python.exe的完整路径。配置完成后重启客户端正常情况下可以看到app-test-mcp下的工具列表。5.4 通过 MCP 客户端测试工具在对话框里输入类似这样的指令获取当前可用的测试设备列表。模型会调用get_test_devices工具返回设备列表。如果这一步能跑通说明 MCP Server 接入成功后续工具可以按同样方式扩展。6. 设计 Agent SkillAPP 冒烟测试流程MCP Server 搭建好之后模型已经手握工具但还缺少流程约束。这一节设计一个最小可用的冒烟测试 Skill用于指导模型执行“启动 APP - 检查首页文本 - 点击核心入口 - 返回结果”的完整流程。6.1 Skill 的通用文件结构不同 Agent 平台对 Skill 的格式有差异但大体包含以下字段name: app_smoke_test description: 对 Android 设备执行 APP 冒烟测试流程 trigger: 用户要求执行冒烟测试、快速回归或启动检查 steps: - step: 获取测试设备 tool: get_test_devices condition: 必须存在状态为 device 的设备 - step: 启动 APP tool: launch_app params: package_name: com.example.demo activity_name: .MainActivity - step: 读取首页文本 tool: get_screen_text expected: - 首页标题 - 核心按钮名称 - step: 点击核心入口 tool: tap_element params: x: 500 y: 800 - step: 汇总结果 output: 以表格形式输出每个步骤的执行结果和断言结论6.2 把 Skill 转化为提示词如果平台没有专门的 Skill 文件格式也可以把上面的内容改写成一段结构化提示词让模型在测试时先读取这段提示词再按照步骤执行。提示词示例你现在是一名 APP 测试执行员。请严格按照以下冒烟测试流程执行 1. 调用 get_test_devices 获取测试设备列表选择状态为 device 的设备。 2. 调用 launch_app 启动 com.example.demo 的 .MainActivity。 3. 调用 get_screen_text 获取首页文本检查是否包含“首页标题”和“核心按钮名称”。 4. 调用 tap_element 点击首页核心入口按钮。 5. 输出每个步骤的执行结果并给出 PASS/FAIL 结论。 如果某一步失败不要继续执行后续步骤直接输出失败原因。这种方式的好处是不依赖特定平台的 Skill 格式把“Skill”落地为一段可复用的 Prompt 资产。更正规的 Agent 平台可以把这个流程封装成平台原生 Skill 或 Agent Skill 文件。6.3 Skill 与 MCP 的组合逻辑Skill 负责指定“做什么、按什么顺序做”MCP 负责“每一步具体怎么调用工具”。比如在“读取首页文本”这一步模型需要调用get_screen_text工具在“点击核心按钮”这一步模型需要调用tap_element工具。如果没有 Skill模型可能跳过“读取文本”直接点击如果没有 MCP模型知道要点击也没有办法真正操作设备。在实际工程中建议把 Skill 和 MCP 工具分开维护。Skill 变更时不需要改 MCP ServerMCP 工具增加时也不需要改 Skill只要工具描述清晰模型就能在 Skill 引导下正确选择工具。6.4 Skill 的粒度控制Skill 不是越细越好。太细会导致提示词过长、模型上下文被占满太粗又容易出现步骤遗漏。建议按下面粒度拆分系统级 Skill设备连接检查、APP 启动、应用卸载清理。业务级 Skill登录测试、搜索测试、下单测试。数据级 Skill测试数据准备、断言规则、结果汇总。第一次做的时候建议先写一个登录测试 Skill跑通后再扩展其他场景。7. 功能测试与效果验证MCP Server 和 Skill 都准备好之后接下来要验证这套链路是否真的能用。建议按下面的测试顺序执行每验证一步记录结果出问题时能快速定位。7.1 测试场景一工具连通性验证测试目的确认 MCP Server 能启动、工具能被模型调用。操作步骤启动 MCP Server。打开 MCP 客户端。输入“调用 get_test_devices 获取设备列表”。预期结果模型返回设备列表格式为 JSON 数组。判断标准模型实际调用了工具而不是直接编造一个设备列表。关键看返回内容是否与 MCP Server 打印的日志一致。失败排查如果模型说“无法调用工具”先检查客户端配置和 Server 启动日志。7.2 测试场景二冒烟测试流程测试目的验证 Skill 流程能否被模型完整执行。操作步骤准备一个测试 APP确认包名和 Activity 路径。提示模型执行冒烟测试流程使用 6.2 的提示词。观察模型是否按步骤调用get_test_devices、launch_app、get_screen_text、tap_element。预期结果模型按顺序输出每一步结果最后给出 PASS/FAIL 结论。判断标准步骤顺序与 Skill 一致。每个工具参数完整。检测到失败时模型停止执行并输出原因。常见失败原因模型跳步说明 Skill 步骤不够明确。工具参数错误说明工具描述里缺少参数示例。返回内容为空说明设备端控件树读取失败需要检查 adb 权限或 Appium 服务。7.3 测试场景三自然语言生成测试用例测试目的验证模型能否根据需求生成结构化的测试用例并映射到 MCP 工具。操作步骤输入“生成登录页面的 5 个测试用例并说明每个用例会调用哪些 MCP 工具”。检查模型输出。预期结果模型能拆解出正常登录、错误密码、空账号、账号不存在、连续失败等用例并关联到input_text、tap_element、get_screen_text等工具。判断标准用例描述是否覆盖正常和异常路径工具映射是否合理。说明这一步不要求模型真的执行测试重点看它是否理解工具能力边界。7.4 测试场景四断言结果验证测试目的验证模型能否根据工具返回内容做断言。操作步骤让模型执行登录测试。在get_screen_text返回的文本中包含“登录成功”或“密码错误”。检查模型是否识别到关键字并给出 PASS/FAIL。预期结果模型根据返回文本内容判断用例是否通过并输出结构化结果。判断标准模型在 Prompt 中描述断言规则时是否能准确提取关键字。失败排查如果模型忽略断言规则说明 Skill 中的 expected 字段不够明确需要在提示词中补充“必须检查 X 文本是否存在存在则 PASS否则 FAIL”。7.5 验证过程中的日志记录建议在 MCP Server 的每个工具函数中加入日志输出方便确认调用顺序和参数。日志格式示例[2026-01-01 10:00:01] get_test_devices called [2026-01-01 10:00:02] launch_app called with params: {package_name: com.example.demo} [2026-01-01 10:00:03] get_screen_text called有了完整日志排查问题时能快速判断是模型没调用工具、参数传错、还是设备端执行失败。8. 接口 API 与批量任务大部分测试工作不是单条指令就能完成的真实场景里要批量跑回归、批量处理多台设备。MCP Server 本身是接口服务可以用两种方式做批量任务。8.1 MCP Server 作为接口服务MCP Server 启动后除了被 AI 客户端调用也可以被其他服务调用。支持 SSE 的模式可以暴露 HTTP 接口方便测试平台、CI/CD 系统接入。接入方式# 启动支持 SSE 的 MCP Server python app_test_server.py --transport sse --port 8000具体启动参数以项目文档为准。接入后测试平台可以调用 MCP Server 暴露的工具比如执行launch_app、get_screen_text等。8.2 外部脚本批量调用 MCP 工具如果不想引入复杂的 Agent也可以写一个 Python 脚本通过 MCP 客户端 SDK 循环调用工具。下面的代码是通用模板import time import logging logging.basicConfig(levellogging.INFO) def run_test_case(case_name: str): # 实际项目中这里是调用 MCP 工具的函数 # 返回 {status: PASS} 或 {status: FAIL, reason: ...} result { status: PASS, case_name: case_name, } return result def run_batch(cases: list): for case in cases: max_retry 2 retry_count 0 while retry_count max_retry: try: result run_test_case(case) if result[status] PASS: logging.info(f{case} 执行通过) break else: logging.error(f{case} 执行失败: {result.get(reason)}) except Exception as exc: logging.warning(f{case} 执行异常: {exc}) retry_count 1 time.sleep(1) if __name__ __main__: test_cases [login, search, pay, home_ui] run_batch(test_cases)注意示例中的run_test_case需要替换为实际的 MCP 工具调用代码。批量任务的关键是加日志、加超时、加重试避免单条用例卡死整个任务。8.3 批量任务设计建议设备管理先调用get_test_devices获取全部在线设备然后按设备并行执行用例。用例清单用 JSON 或 YAML 文件维护测试用例清单脚本循环读取。结果汇总每条用例执行后写入日志文件最后汇总成 Markdown 或 JSON 报告。失败重试对于偶发失败重试两次对于确定性失败不要重试直接标记失败原因。中断恢复批量任务记录当前执行到哪条用例如果服务中断下次从断点继续。{ devices: [ {serial: emulator-5554, cases: [login, home_ui]}, {serial: emulator-5556, cases: [search, pay]} ], retry: 2, timeout: 60, output_dir: ./reports }8.4 接口调用的安全限制MCP Server 如果暴露成 HTTP 接口必须限制访问范围。建议只绑定内网地址或 localhost不要直接暴露公网。如果是内网测试平台使用可以加一个简单的 Token 校验。不要在生产环境把设备控制接口开放给无关人员。9. 常见问题与排查方法实践过程中最容易踩的坑集中在配置、工具调用、设备连接三个层面。下面用表格整理常见问题和排查思路。问题现象可能原因排查方式解决方案MCP Server 启动失败Python 依赖缺失或 SDK 版本不匹配查看启动日志确认报错模块按项目文档安装指定版本 SDK客户端连不上 MCP Server配置路径错误或命令不可用检查配置文件的 command 和 args改成绝对路径验证 python 命令可用工具没有出现在客户端Server 名称写错或注册失败查看客户端日志检查 MCP Server 名称确保配置中的名称与代码注册名一致模型不调用工具工具描述不清晰或模型未理解查看工具描述检查 Skill 步骤在工具描述中补充使用场景和参数示例adb 识别不到设备USB 调试未开启或驱动异常执行 adb devices开启开发者模式安装驱动重插 USB工具调用后无返回设备端执行超时查看 MCP Server 日志增加超时时间检查设备状态点击坐标不准确不同分辨率设备坐标差异检查截图和设备分辨率改用控件 id 或文本定位不用坐标批量任务卡住单条用例执行无超时查看日志停在哪个工具给每个工具调用增加超时和重试模型输出与设备实际不符上下文里没有实时结果检查是否把工具返回结果传给模型确保 MCP 返回内容完整进入 Agent 上下文数据隐私风险生产账号传入外部模型审查 Prompt 和数据流使用脱敏测试数据本地部署模型或走私有化 API有一个非常常见的误区工具已经调用成功但模型回答时仍然没有引用工具结果。这通常是客户端配置的问题模型没有拿到工具返回内容。解决办法是查看 MCP 工具的返回结果是否展示在客户端输出中如果没有需要检查 MCP Server 的返回格式是否符合协议要求。10. 最佳实践与工程建议把 Skill MCP 用于 APP 测试不能只在本地跑通 demo 就结束。进入真实工程环境后有几个实践原则能明显降低维护成本。10.1 先小参数验证再全量接入第一次接入时不要直接把几十个用例全部交给 Agent 执行。先跑通“获取设备 - 启动 APP - 读取文本”这三步确认整个链路稳定后再逐步增加业务用例。全量接入前先用少量用例评估模型的工具调用准确率和流程执行准确率。10.2 工具描述要像接口文档一样规范MCP 工具是给模型看的也是给团队其他成员看的。写工具描述时要包含工具用途。参数说明。参数示例。返回结果示例。失败场景说明。举例工具get_screen_text 用途获取指定设备当前界面的可访问性文本。 参数 device_serial: 设备序列号例如 emulator-5554。 返回 {text: 首页 搜索 我的, error: null} 失败场景 设备离线时返回 error。描述越清晰模型调用越准确团队成员排查问题也越容易。10.3 Skill 与工具分离管理Skill 文件建议按业务场景拆分不要把所有步骤写在一个超长 Prompt 里。MCP Server 工具建议按领域拆分比如设备管理工具、业务操作工具、数据查询工具。这样模型调度时上下文更短工具选择更准确。10.4 测试数据脱敏与合规不要使用真实用户手机号、身份证号等敏感数据做测试。测试账号单独申请使用独立测试环境。截图、日志如果包含用户信息归档前做脱敏处理。如果模型走云端 API测试数据不能包含敏感业务数据。涉及账号、支付、权限操作时生成测试数据要比手工测试更谨慎。10.5 建立执行日志与反馈闭环每次执行都要保存完整日志包括模型接收到的用户指令。模型调用的工具步骤。每个工具的入参和返回结果。最终断言结论。这些日志是优化 Skill 和 Prompt 的重要依据。如果某一轮模型频繁跳步翻日志后大概率能发现是 Skill 描述不清晰。建议每轮迭代都保留一套最小可信用例集用来回归验证 Agent 在优化后没有变笨。10.6 面向测试团队的协作方式Skill MCP 不是让测试工程师写一套脚本就结束而是要沉淀成团队资产。建议在团队中MCP Server 由测试开发或工具团队维护保证工具稳定。Agent Skill 由业务测试维护因为业务规则通常掌握在业务测试手里。定期评审工具描述和 Skill 步骤淘汰过时用例。把验证通过的最小配置和常见排查方法写入团队文档。11. 总结与下一步Skill MCP 做 APP 测试最值得关注的一点是它把“让 AI 做测试”从聊天层面推进到了执行层面。模型不再只是输出“我建议你排查一下登录功能”而是真的能调用工具去启动 APP、读取界面文本、执行点击、给出断言结果。对测试工程师来说这是一个和传统自动化测试完全不同的技能组合。如果你是第一次尝试建议先把 MCP Server 的最小 demo 跑通也就是让模型调用get_test_devices拿到设备列表。这一步验证通过后再尝试写登录测试的 Skill让模型按步骤执行。最容易踩的坑基本集中在 MCP Server 配置路径、设备连接、工具描述不清晰这三块遇到问题优先看 Server 日志和客户端日志。这套链路后续可以继续扩展的方向很多把执行结果回传给模型做智能断言、建立历史测试用例知识库、接入 CI/CD 流水线、支持多设备并行测试、对不同业务的 Skill 做版本管理。如果你已经能稳定跑通上述流程下一步建议直接挑一个真实业务模块把登录、首页检查、核心功能入口这几个场景做成可复用的 Skill 资产。这样既能在日常测试中看到实际产出也能在技术分享或面试时拿出完整的实战链路。