AI测试这个概念喊了几年真正把测试工程师从重复劳动里解放出来的案例还是太少。问题并不出在模型能力上而是出在模型怎么连接工具这件事上。AI 确实能写出像样的测试用例可当你让它真正去拉起 Appium、操作模拟器、抓一轮截图再给出结论时过去每个团队都得自研一条路。MCP模型上下文协议把这条路径标准化以后AI 自动化测试才从单个工具演示走向工程化落地。我先把判断放在前面对测试岗位来说MCP 和 Agent Skill 的组合核心价值不是用 AI 替代人写脚本而是把测试脚本从写死的代码升级成Agent 可以按需调用的动态能力。理解并亲手搭一遍这条链路比收藏一百篇概念讲解都有用。这篇文章会用一套完整实战带你从零搭建一个自定义 MCP Server把测试设备接入 AI Agent再写一个 Skill 封装登录回归流程最终让 Agent 独立跑完一次 APP 测试。你不需要已经是 AI 专家但最好有基础的 Python 或 Node.js 经验。1. 为什么说 MCP 和 Skill 是 AI 测试的分水岭先看一个真实的痛感场景。APP 版本迭代越来越快每轮回归要覆盖几十条用例涉及不同机型、不同 Android 版本还要处理偶发的网络导致的问题。测试团队最常见的状态是每天花大量时间跑冒烟、改定位符、调隐式等待、截图、整理报告。测试脚本本身写得不错但维护成本高到让人不敢轻易改动。引入大模型之后很多团队发现一个新问题AI 写用例很快但执行成了瓶颈。今天要接 Appium明天要接性能监控工具后天要接 bug 管理平台每个工具都要开发独立的适配代码。更麻烦的是各家 Agent 框架的接入方式不统一换一个客户端适配代码可能就要重写。这是 AI 测试落地最大的隐性成本。MCP 把这件事一次性标准化了。它定义了 AI 模型应用与外部工具、数据源之间的通信协议工具提供方只要按规范暴露能力任何支持 MCP 的 Agent 都能直接调用。对测试领域来说这就意味着 Appium、设备管理、截图、接口校验、报告生成都可以通过统一的协议暴露给 AI。它的意义不在于某一个工具而在于整个工具链的接入方式被统一了。但能调用工具不等于知道怎么测试。这时候就需要 Agent Skill 出场。Skill 是封装在 Agent 内部的能力包它告诉模型在什么场景下该做什么事、执行顺序是什么、中间需要调用哪些工具、有哪些约束条件。如果说 MCP 解决了AI 的手脚能不能动的问题Skill 解决的就是AI 的大脑知道该怎么干活的问题。两者缺一不可合在一起才构成完整的 AI 测试体系。2. 先分清两个概念MCP 与 Agent Skill很多初学者把 MCP 和 Agent Skill 混为一谈其实它们处在完全不同的技术层次。2.1 MCP 是模型连接外部世界的USB-C 接口MCPModel Context Protocol模型上下文协议是一个开放协议它规定了 AI 模型应用如何发现、连接和调用外部工具。你可以把它理解成AI 世界的 USB-C过去每个设备都有自己的充电口现在大家统一成一个接口设备生产方和充电器生产方都只需要按同一套标准开发。在 MCP 的架构里有几个关键角色MCP Client运行在 Agent 客户端中负责与 Server 通信。MCP Server暴露具体工具、资源和提示词的服务。Tool一个可被模型调用的具体函数比如执行 Appium 脚本、获取设备截图。Resource可供模型读取的数据比如设备列表、测试报告。对测试工程师来说你不需要成为协议专家但需要理解一个核心动作把测试工具封装成 MCP Server 后Agent 就能在对话中直接调用它。传统方式是人写脚本脚本调用工具新方式是人描述意图Agent 通过 MCP 调用工具。2.2 Agent Skill 是给模型装配的专业能力包Skill 的定义在不同 Agent 平台里略有差异但核心思想是一致的它是一份结构化描述包含技能的名称、触发条件、执行流程、依赖的工具和约束条件。我们可以把它类比成员工手册或武器卡——每个 Skill 都封装了某一类任务的完整做法。举例来说登录回归测试这个 Skill 会写清楚何时使用用户要求验证登录功能或发版前需要做登录模块回归。执行流程清理缓存、启动 Appium、执行登录用例、检查关键接口、收集截图。依赖工具需要 MCP 暴露的设备管理工具和测试执行工具。约束条件只在测试环境运行不修改线上账号数据。模型读到这份 Skill 之后就不会凭空发挥而是按你编排好的流程一步步执行。这就是 Skill 和普通 Prompt 的区别普通 Prompt 是临时的指令Skill 是可复用、可版本管理、可共享的标准作业程序。2.3 两者的边界与配合对比维度MCPAgent Skill本质模型与外部工具/数据之间的通信协议Agent 可复用的任务能力封装解决的问题AI 如何稳定调用外部能力AI 知道在什么场景按什么流程执行类比外部系统的 USB-C 接口装有完整作业流程的能力包典型实体MCP Server、Client、ToolSkill 描述文件、Prompt、工具引用测试中的角色管“能执行”管“知道怎么测”示例Appium MCP Server、设备管理 MCP登录回归 Skill、崩溃报告分析 Skill一个容易踩坑的误区是只搭了 MCP Server没有写 Skill。结果 Agent 虽然能调用工具却不知道什么时候调、按什么顺序调最终还是靠人一步步提示。反过来只写 Skill 不接 MCPAgent 就像一个只会纸上谈兵的测试员说得头头是道真正执行时没有手脚。正确做法是先用 MCP 解决工具接入再用 Skill 封装任务流程让两者形成闭环。3. AI 测试体系的整体架构与工作流如果要给团队规划 AI 测试体系建议先从架构上分层思考。一个可落地的 AI 测试体系大致可以分成四层从下往上看资源层是测试设备、被测应用、测试数据、Appium 和工具链工具层通过 MCP Server 把这些资源暴露给上层编排层由 Agent 和 Skill 组成负责理解需求、拆解任务、调用工具最上层是交互层测试工程师用自然语言描述需求读取 Agent 生成的测试报告。传统的 APP 测试流程通常是分析需求、编写用例、准备数据、执行脚本、定位失败、写报告每一步都依赖人参与。引入 Skill 和 MCP 之后流程变成了这样测试工程师向 Agent 描述目标例如对测试包做登录功能回归。Agent 检索匹配的 Skill确认执行流程。Skill 引导 Agent 调用 MCP 工具比如先检查设备是否在线再执行 Appium 用例。测试过程自动收集截图、日志和接口响应。Agent 汇总结果生成结构化测试报告并标注疑似缺陷。这个流程里人的角色从逐条执行测试变成了定义测试标准和验收条件。这也正是 AI 测试工程师这个岗位的核心能力不是会写多少条用例而是能否把测试经验结构化地沉淀为 Skill能否准确地评估 Agent 的执行结果。4. 环境准备与前置条件在动手之前先确认基础环境。下面列出的工具和版本请以你实际安装时的发布版本为准这里重点演示通用思路。4.1 操作系统与运行环境操作系统Windows 10/11、macOS、主流 Linux 发行版都可以。Python建议 3.11 及以上用于运行 MCP Server 示例脚本。Node.js建议 20 及以上部分 MCP 工具链依赖它。Android SDK / adb连接安卓模拟器或真机。Appium 2.x作为 APP 自动化测试的执行引擎。支持 MCP 的 Agent 客户端可以是桌面端、IDE 插件或 Dify 之类的平台工具选择你熟悉的即可。这里容易踩坑的是环境变量。Android SDK 需要配置ANDROID_HOMEadb需要加入系统 PATHAppium 需要安装对应平台的 driver。如果这些没配好MCP Server 本身没问题但 Agent 调用工具执行设备操作时会频繁失败。4.2 Python 依赖准备一个独立的虚拟环境避免污染全局环境。python -m venv .venv source .venv/bin/activate # Windows 下可使用 .venv\Scripts\activate pip install mcp如果使用社区封装可以参考 FastMCP 这类库的安装方式。具体包名以官方 SDK 文档为准。4.3 准备一台测试设备建议先启动一个 Android 模拟器或者连接一台开启 USB 调试的真机。确认设备在线adb devices预期输出类似List of devices attached emulator-5554 device关于 Appium 的初始化不同版本差异较大建议先手动跑通一条 Appium 脚本再接入 MCP。这样后续排查问题时你能分清是测试脚本的问题还是MCP 链路的问题。5. 搭建一个自定义 MCP Server把测试能力暴露给 Agent5.1 项目结构为了便于管理我建议把 MCP Server 和测试脚本分开存放app-test-ai/ ├── server/ │ └── app_test_mcp_server.py ├── scripts/ │ └── test_login.py ├── skills/ │ └── app_login_regression.yaml └── mcp.json5.2 编写 MCP Server 示例下面是一个基于 FastMCP 风格的自定义 MCP Server它暴露了两个能力获取设备列表、执行指定测试脚本。以下代码是示意代码重点是理解如何把测试能力封装成 MCP Tool。# server/app_test_mcp_server.py from mcp.server.fastmcp import FastMCP mcp FastMCP(app-test-hub) mcp.tool() def list_devices() - list[str]: 返回当前已连接的测试设备列表 import subprocess result subprocess.run([adb, devices], capture_outputTrue, textTrue) lines result.stdout.strip().split(\n) devices [] for line in lines[1:]: if line.strip() and device in line: devices.append(line.split(\t)[0]) return devices mcp.tool() def run_test_script(script_name: str, device_id: str) - str: 在指定设备上执行 Appium 测试脚本返回执行结果 import subprocess result subprocess.run( [python, -m, pytest, fscripts/{script_name}.py, --device, device_id], capture_outputTrue, textTrue, ) return fexecuted {script_name} on {device_id}, returncode{result.returncode} if __name__ __main__: mcp.run()这段代码的核心逻辑是用mcp.tool()装饰器把普通函数声明为 MCP Tool。每个 Tool 的 docstring 会被模型读取所以描述要写清楚这个工具是干什么的。实际项目中run_test_script内部可以封装更复杂的 Appium 调用、日志采集和报告输出。5.3 配置接入 Agent在你的 Agent 客户端中通常有一个 MCP 配置文件。常见形式是mcp.json写法如下{ mcpServers: { app-test-hub: { command: python, args: [server/app_test_mcp_server.py], env: { APPIUM_HOST: 127.0.0.1, APPIUM_PORT: 4723 } } } }配置完成后重启 Agent 客户端。如果一切正常工具列表里应该能看到list_devices和run_test_script。不同客户端的配置入口不一样关键是理解这条链路配置文件告诉 Agent 启动哪个 MCP ServerServer 暴露哪些工具Agent 通过协议发现并调用它们。5.4 验证 Server 是否被识别先用命令行直接启动 Server看是否有报错python server/app_test_mcp_server.py如果启动正常没有抛出异常说明代码层面没问题。然后在 Agent 客户端里直接问一句请调用工具 list_devices查看当前有哪些设备在线。如果 Agent 能返回设备列表说明 MCP 链路已经打通。这一步是整篇文章最关键的验证点做完它你已经完成了从零到AI 能操作测试工具的跨越。6. 编写 Agent Skill把回归流程装进技能包MCP 打通之后下一步是让 Agent 不止会调用工具还知道怎么组织一场测试。这就是 Skill 的职责。6.1 Skill 要回答的问题一份合格的 Skill 描述文件至少要回答四个问题这个技能是做什么的什么情况下应该触发它执行步骤是什么需要依赖哪些工具有哪些红线约束6.2 登录回归测试 Skill 示例# skills/app_login_regression.yaml name: app_login_regression description: 对目标 App 做登录模块回归测试覆盖正常登录、错误密码、验证码、登出等场景 when_to_use: 用户要求验证登录功能或发版前需要做登录模块回归 workflow: - 启动 Appium Server确认目标设备在线 - 清理目标 App 缓存重新安装本次构建包 - 按顺序执行: 正常登录 - 错误密码 - 验证码 - 登出 - 每一步收集截图和关键接口响应 - 汇总结果生成结构化测试报告 tools_required: - app-test-hub constraints: - 只在测试环境执行 - 不修改线上账号数据 - 使用隔离的测试账号这个 Skill 文件不包含具体代码它描述的是流程和约束。Agent 读取之后会把模型的能力和 MCP 工具结合起来按这个流程执行测试。你的测试经验越细Skill 描述越具体执行效果就越稳定。6.3 为什么 Skill 不能替代 MCP从上面的文件可以看出来Skill 本身没有执行能力它只是指挥计划。真正去操作设备、执行脚本的还是 MCP 暴露的工具。这就好比一个测试主管写下测试方案但他需要测试工程师去执行MCP 就是那个随叫随到的执行工程师。实践中的常见错误是把 Skill 写成了万能 Prompt里面写满了你应该认真测试你应该仔细检查但没有可执行步骤也没有工具引用。这样的 Skill 无论写多少份Agent 都不知道具体该做什么。Skill 的核心是可编排的动作序列而不是正确的废话。6.4 如何验证 Skill 能正常触发把 YAML 文件放到 Agent 对应的 Skill 目录后在对话中直接用自然语言描述场景请对测试包执行一次登录模块回归测试先确认设备在线再按流程执行。观察 Agent 是否会主动加载app_login_regressionSkill并按 workflow 执行。如果 Agent 没有触发 Skill优先检查when_to_use的描述是否足够精确。模型靠它来判断当前任务是否匹配这个技能。7. 完整实战让 Agent 独立执行一次登录回归测试7.1 目标场景假设你手上有一个 Android 测试包需要做登录模块的回归。传统方式是你打开 IDE、启动 Appium、写脚本、跑用例、看报告整个过程至少几十分钟。现在你和 Agent 的对话可能是这样的你对测试包做一次登录回归设备用 emulator-5554。 Agent好的我将加载 app_login_regression Skill执行登录模块回归测试。7.2 执行过程的内部拆解Agent 在第一层会确认设备在线调用 MCP 的list_devices工具# 示意Agent 内部的工具调用序列 devices mcp_tool_invoke(list_devices) assert emulator-5554 in devices然后按 Skill 的 workflow依次执行正常登录、错误密码、验证码、登出场景。每个步骤都通过 MCP 的run_test_script工具调用 Appium 测试脚本并收集截图和日志。7.3 预期输出示例整个流程跑完Agent 输出的报告大致是这样的[Skill] 开始执行: app_login_regression [Tool] 设备检查: emulator-5554 在线 [Case] 正常登录用例: PASS [Case] 错误密码用例: PASS [Case] 验证码用例: PASS [Case] 登出用例: PASS [Report] 通过率: 4/4截图: 12 张 [结论] 登录模块回归通过未发现阻塞缺陷。这不是虚构某次测试结果而是这条链路正常工作的预期形态。你可以把它当作验证标准如果你的 Agent 最终能产出类似结构的结果说明 MCP 和 Skill 已经真实地在工作。7.4 如何判断是否成功判断标准有三个工具调用真实发生而不是模型假装执行。可以看 MCP Server 的日志确认工具被实际调用过。测试结果是脚本真实返回的而不是模型猜测的。工具返回值里应该有 returncode、用例结果等客观数据。失败用例能给出定位线索。好的链路会在失败时附上截图路径、日志片段或接口响应。如果你的 Agent 在反馈中说测试通过但没有任何工具调用记录那只是模型在幻觉链路并没有真正闭环。这一点务必警惕。8. 常见问题与排查思路8.1 常见问题排查表问题现象可能原因排查方式解决方案Agent 连接不上 MCP Server配置文件路径错误或端口被占用先单独启动 Server 看输出核对 mcp.json 的命令和参数工具列表为空MCP Server 启动失败或 SDK 版本不匹配查看 Server 启动日志和协议握手信息升级或回退 MCP SDK 版本Skill 没有被触发描述信息不够精确查看 Agent 加载 Skill 的日志补充 when_to_use 中的关键词和场景工具调用超时设备未上线或 Appium 未启动执行 adb devices、检查 Appium 日志先手动跑通脚本再接入 Agent中文路径导致脚本报错环境变量或路径包含中文检查 ANDROID_HOME 和项目路径统一使用纯英文路径Agent 声称执行成功但实际未调用工具工具调用链没生效模型在猜测检查 MCP Server 的请求日志重新配置连接并验证工具可被调用8.2 一个容易忽略的排查方向很多问题出在你手动能跑通但 Agent 跑不通。这种情况通常不是 MCP 的问题而是测试脚本对环境有隐式依赖。比如脚本里写了绝对路径、依赖了某个全局变量、或者需要特定的工作目录。建议把这些隐式依赖全部改成显式参数让 Agent 可以通过 MCP 工具传入。最理想的状态是每个测试工具函数都像一个纯函数输入明确输出明确没有隐藏状态。9. 最佳实践与工程建议9.1 安全边界MCP 工具要收敛不要暴露万能能力这是最重要的一条。MCP Server 暴露的工具越细越容易控制风险。不要直接暴露一个可以执行任意 shell 命令的通用工具否则模型一旦走偏后果不可控。更好做法是把操作封装到具体业务级工具比如执行登录测试脚本、获取设备截图。9.2 权限最小化只让它动测试环境AI 测试链路必须严格限定在测试环境。所用账号必须是隔离的测试账号不能携带真实用户数据。涉及生产数据的接口、数据库、线上配置不应该出现在 MCP 工具的可达范围内。测试环境的一次误操作可以接受线上环境的一次误操作就是事故。9.3 可观测性MCP Server 一定要有日志建议给 MCP Server 加上请求日志记录每次工具调用的时间、参数、返回值和耗时。这对排查模型幻觉、工具异常、链路抖动都极有价值。没有日志你面对 Agent 的解释会非常被动有日志你可以直接看到真实的调用情况。9.4 从小场景开始落地不要一上来就想构建全自动 AI 测试平台。最务实的路径是找一条你每天都会回归的用例把它接进 MCP再用一个 Skill 封装它跑通后评估效果。有了第一个闭环再逐步扩大范围。测试团队的信心和信任是靠一次次稳定复现建立起来的。9.5 Skill 和 MCP 配置纳入版本管理Skill 描述文件、mcp.json、测试脚本都应该进入 Git 仓库。Skill 的变更历史其实就是团队测试经验的演进历史。每次 AI 测试效果变差可以先检查最近有没有人改过 Skill 或 MCP 工具定义。9.6 明确人机分工2026 年的 AI 测试仍然需要人做决策。Agent 更适合做重复执行、信息收集、初步筛选而测试策略的制定、边界场景的设计、缺陷的最终确认仍然需要测试工程师的判断。把 AI 当作一个执行能力极强的初级测试员是最稳妥的定位。10. 给测试工程师的学习路线建议如果你准备系统学习 AI 测试建议按下面四个阶段推进。10.1 阶段一先掌握 Prompt 驱动的测试思维第一阶段不需要懂代码主要练习用自然语言描述测试需求、边界条件和验收标准。能写清当输入什么时预期出现什么结果是后续所有能力的基础。10.2 阶段二会配置 MCP能看懂工具链路这个阶段要亲手搭建一个简单的 MCP Server哪怕只暴露一个获取系统时间的工具也行。重点是理解 Server、Client、Tool 的关系知道配置文件在哪里、日志去哪里看。10.3 阶段三能把团队常用流程封装为 Skill把你日常最熟悉的一条测试流程写成 Skill 描述文件并接入真实测试环境验证。这个阶段完成后你已经具备了让 Agent 替你干活的能力。10.4 阶段四设计测试体系评估 AI 测试效果最后一步是站在全局视角设计团队级别的 AI 测试体系。你会关心工具链覆盖、用例沉淀、错误率、耗时、成本这些指标。这个阶段就是 AI 测试工程师的核心价值所在也是面试官真正关注的能力。面试时除了概念题一定要能讲清你自己的实践案例为什么这样设计 MCP 工具Skill 里的 workflow 是怎么排出来的遇到工具调用异常怎么排查。一个能说出我的工具调用链出过什么问题、怎么解决的的候选人永远比只会背诵概念的人更有竞争力。回到开头的判断Skill 和 MCP 不会让测试工程师失业但会重塑测试工程师的工作方式。建议你今天就做一个小实验把一条你最常用的测试用例接进 MCP再写一个 5 行描述以上的 Skill让 Agent 跑通一次。这个最小闭环的价值远大于收藏任何一份教程。