AI测试实战：Skill+MCP打造APP自动化测试工作流

这份标题挺吸引人但先说明一点本文不会讲“刷完即就业”这种无法保证的事而是把 Skill、MCP 这些当前 AI 工程领域高频出现的技术概念和 APP 测试的实际落地流程结合起来给你一套能直接参考的 AI 测试实战方案。文章会从概念讲起带环境准备、配置示例、完整代码、常见问题和工程建议新手可以按顺序读完有测试或开发基础的也可以直接挑实战章节看。1. 背景与核心概念1.1 Skill 和 MCP 是什么先聊 Skill。在 AI Agent 语境下Skill 可以理解成“给模型准备的技能包”。它通常包含一份描述文件、若干 Prompt 模板、可能还带一些可执行脚本或参考知识。模型通过阅读 Skill 的描述知道自己在什么场景下应该按什么流程做事比如“识别 APP 启动异常”“生成接口测试数据”“按 Page Object 模式补全用例”。简单说Skill 让通用模型变成“懂这个领域”的专用助手。MCP 全称 Model Context Protocol中文常翻译为“模型上下文协议”它解决的是模型和外部工具之间的连接问题。没有 MCP 之前AI 要调用测试平台、数据库、设备管理服务往往需要为每个工具写一套定制接口。MCP 出现后模型可以通过统一协议访问外部能力比如读取测试报告、操作模拟器、调用自动化测试框架等。再回到 APP 测试场景。APP 测试涉及设备管理、页面元素定位、接口校验、性能采集、崩溃日志分析等环节这些能力模型本身不具备但它可以通过 Skill 学会“测试流程怎么编排”再通过 MCP 连接“真正能执行测试的工具”。两者配合就是当前 AI 测试比较主流的工作方式。1.2 为什么 AI 测试是当前热门方向从测试行业看传统自动化测试的成本一直不低。脚本维护、元素定位变化、多机型适配、用例稳定性问题都会消耗大量人力。AI 测试的思路不是完全替代自动化脚本而是让 AI 承担一部分“理解需求、生成用例、分析报告、定位根因”的工作把测试工程师从重复劳动里释放出来。另一个现实原因是工具链逐渐成熟。目前很多团队已经在用 Playwright、Appium、uiautomator2 做自动化同时出现了 Playwright MCP Server、Figma MCP、蓝湖 MCP 这类中间层服务AI 可以读取设计稿、查看元素树、操作浏览器或设备进一步打通了“需求理解—用例设计—执行验证—报告生成”的链路。所以对测试工程师来说掌握 Skill 和 MCP不是要学会一套“新魔法”而是学会一种“组织测试能力”的方法。你可以把团队已有的测试工具、脚本、规范封装成 Skill通过 MCP 暴露给 AI让 AI 按你的流程去执行。1.3 AI 测试与传统自动化测试的分工提到 AI 测试常有人问“AI 会不会取代测试工程师”。从实际落地看两者更像是分工关系。传统自动化测试擅长精确执行、重复回归、数据校验确定性高适合做“必须稳定跑”的场景。AI 测试擅长理解模糊需求、批量生成用例、分析失败原因、翻译业务逻辑为测试步骤适合做“需要判断和联想”的场景。一个典型的配合方式是AI 结合 MCP 读取需求文档或设计稿先生成测试点和用例模板测试工程师审核后把关键用例固化为自动化脚本执行时由 AI 调度 MCP 工具收集结果失败时 AI 再结合日志、截图、性能数据给出初步定位。这样一来AI 的灵活性进入测试流程而稳定执行仍然由自动化框架保证。2. 环境准备与版本说明在实际动手之前先确认环境。下面给出一份通用清单版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。2.1 基础环境清单操作系统Windows 10/11、macOS 或主流 Linux 发行版均可编程语言Python 3.10用于编写 MCP Server 和测试脚本Node.js 18部分 MCP Server 和 AI 工具链基于 Node 实现Android 环境Android SDK、adb 命令行工具用于连接模拟器或真机iOS 环境可选macOS Xcode simctl用于 iOS 模拟器操作移动端自动化框架Appium 或 uiautomator2二选一如果本机还没有这些环境建议先安装 Python、Node.js 和 adb这是后续操作的基础。iOS 自动化在 Windows 上无法直接进行需要 macOS这一点提前说明。2.2 MCP 运行时准备MCP 本身是一个协议不是某个独立软件。运行时通常由 AI Agent 端提供比如 Claude Desktop、Claude Code或其他支持 MCP 的 Agent 框架。常见做法是准备一个mcp.json或.mcp配置文件把测试工具的服务地址、命令和参数写进去。不同 Agent 对配置文件名要求不同建议以你使用的 Agent 官方文档为准。一个 MCP Server 通常会暴露若干工具比如find_element按文本或控件类型定位页面元素tap点击指定坐标或元素swipe滑动屏幕get_screenshot截取当前页面get_device_info获取设备信息这些工具可以自己用 Python 写也可以接入开源实现。2.3 测试设备与项目管理准备建议准备一台 Android 模拟器或真机并提前开启开发者模式和 USB 调试。真机测试时注意用测试设备不要用日常使用设备避免造成数据和隐私风险。项目结构可以按下面方式规划ai_test_project/ ├── skills/ │ ├── app_smoke_test/ │ │ ├── SKILL.md │ │ └── prompts/ │ └── bug_analyzer/ │ ├── SKILL.md │ └── prompts/ ├── mcp_servers/ │ └── device_tools_server.py ├── test_cases/ │ └── test_login.py ├── reports/ └── config/ └── mcp.json这个结构的好处是Skill 和 MCP Server 分开管理测试用例独立存放报告输出统一归档。后面实战部分会按这个结构展开。3. Skill 与 MCP 的区别与配合很多刚开始接触 AI 测试的同学会把 Skill 和 MCP 搞混看到 Agent 配置里既有 Skill 又有 MCP不知道二者边界在哪里。这里单独用一个章节说明。3.1 Skill 是给 Agent 的“能力说明书”Skill 的核心价值是“告诉模型怎么做”。它通常是一段结构化文档包含技能名称和适用场景技能描述越具体越好执行步骤或流程图注意事项和禁止行为可参考的示例举个例子你写一个“APP 冒烟测试”Skill描述可以写成# APP 冒烟测试 Skill 当用户要求对移动应用执行冒烟测试时使用本技能。 步骤 1. 启动被测 APP确认能正常进入首页。 2. 依次点击底部主要 Tab验证页面无白屏。 3. 执行一次登录操作验证登录成功或失败有明确提示。 4. 截取关键页面截图输出测试结论。 注意 - 必须使用测试账号禁止使用生产账号。 - 登录失败时不修改业务数据只记录截图和日志。模型读到这个 Skill 后会按照步骤执行。Skill 不负责真正操作 APP它只是给模型“行为准则”。3.2 MCP 是模型与工具之间的“协议通道”MCP 解决的是“模型怎么调用工具”的问题。模型本身不会直接点击屏幕、读取数据库、写入测试报告。它需要通过 MCP Client 连接 MCP Server由 Server 完成实际操作再把结果返回给模型。这样模型就相当于多了一双手。MCP Server 可以采用多种语言编写Python、Node.js、Java 都可以。只要实现 MCP 协议就能接入支持 MCP 的 Agent。MCP 本身不关心你测试什么它更像一条“高速公路”可以承载各种工具调用。所以 MCP 的复用性更强一个设备操作 Server 可以给多个 Skill 使用。3.3 两者如何在测试中配合用一句话总结Skill 告诉模型“做什么、按什么顺序做”MCP 告诉模型“用什么工具、怎么调用”。在实际 AI 测试流程中模型先加载 Skill理解测试目标然后分析用户需求拆解成具体步骤每到一个步骤如果涉及操作设备或读取数据就通过 MCP 调用对应工具执行完后模型结合返回结果继续下一步判断。打个比方Skill 像操作手册MCP 像工具箱里的工具模型是执行者。没有 Skill模型可能不知道该做什么没有 MCP模型想做也做不了。4. 用 Skill MCP 搭建 APP 测试工作流下面从测试流程视角拆解 Skill 和 MCP 如何嵌入 APP 测试的各个阶段。4.1 测试需求梳理先定场景不要一上来就写代码先明确“你要测什么”。常见 APP 测试场景包括安装、启动、升级路径测试登录注册流程测试核心业务链路测试比如下单、支付、发布内容异常场景测试比如弱网、断网、接口超时性能测试比如启动耗时、页面渲染耗时稳定性测试比如反复操作、长时间运行建议把场景写成清单标注优先级。AI 生成用例时这些清单会成为很好的输入。比如针对登录模块可以定义以下测试点正确账号密码登录成功错误密码提示明确空账号、空密码有表单校验网络异常时有友好提示登录成功后跳转正确页面多次登录失败有风控提示这些测试点整理好后可以交给 AI 生成具体测试步骤也可以自己写进 Skill让模型以后自动按这个思路展开。4.2 将测试步骤沉淀为 Skill 脚本业务测试经验是最有价值的资产。每次测试过程中发现的“坑”、验收标准、操作顺序都值得沉淀成 Skill。Skill 不一定非要写代码。它可以是一份 Markdown也可以包含可执行脚本。一个测试 Skill 通常包括场景描述说明这个 Skill 解决什么问题前置条件比如需要已安装 APP、已连接设备测试步骤模型要按这个顺序执行每个步骤的预期结果异常处理方式比如找不到元素时怎么办这里有一个关键点Skill 的文本要尽量结构化让模型容易理解。避免大段含糊描述尽量使用编号列表每条步骤只表达一个操作。4.3 通过 MCP 接入设备调度与断言工具Skill 定好流程后模型要真正操作设备就需要 MCP Server。一个移动设备 MCP Server 至少应提供以下几类能力设备连接与信息查询页面元素定位点击、输入、滑动操作截图与录屏读取日志执行 shell 命令这些能力可以基于 adb、Appium 或 uiautomator2 来实现。下面章节会给出一个最小 MCP Server 示例。另外如果想扩展 AI 测试的覆盖面还可以接入其他 MCP Server比如可以分析设计稿的 Figma MCP、可以读取接口文档的 MCP、可以查数据库的 MCP 等。接入越多AI 能理解的信息越完整测试设计也会更贴近真实业务。4.4 测试执行与结果收集执行阶段AI 会按 Skill 流程逐个调用 MCP 工具。每完成一步记录操作结果、截图和日志。建议统一约定输出格式例如{ step: 点击登录按钮, status: pass, screenshot: reports/login_click.png, message: 登录页面跳转成功 }测试结束时AI 可以汇总所有步骤结果生成一份测试报告。报告里要包含通过率、失败步骤、失败原因初步分析、截图路径、相关日志。结果收集这步很容易被忽略但它对后续回归和问题定位非常重要。建议测试报告自动写入固定目录并保留时间戳。5. 完整实战示例下面用一个登录模块的冒烟测试场景展示如何从零搭建一个基于 Skill MCP 的 AI 测试最小示例。5.1 创建项目结构先创建项目目录并初始化 Python 环境。mkdir ai_test_project cd ai_test_project python3 -m venv venv source venv/bin/activate pip install mcp fastmcp uiautomator2 pillow这里用到mcp和fastmcp作为 MCP Server 框架uiautomator2用于操作 Android 设备pillow用于截图处理。需要注意实际安装时 MCP Python SDK 的包名和 API 可能随版本变化建议以官方文档为准。下面代码演示的是实现思路需要按你的实际版本调整。5.2 编写 MCP Server在mcp_servers目录下创建device_tools_server.py内容如下# 文件路径mcp_servers/device_tools_server.py import uiautomator2 as u2 from fastmcp import FastMCP mcp FastMCP(device-tools) # 全局设备连接实际项目中建议改为连接池 _device None def get_device(): global _device if _device is None: _device u2.connect() return _device mcp.tool() def get_device_info() - str: 获取当前连接的安卓设备信息 device get_device() info device.device_info return f设备型号{info.get(model)}系统版本{info.get(version)} mcp.tool() def find_and_click(text: str) - str: 根据文本定位元素并点击 device get_device() if device(texttext).exists(timeout5): device(texttext).click() return f成功点击元素{text} return f未找到元素{text} mcp.tool() def input_text(text: str, content: str) - str: 向输入框输入文本text 为输入框提示或占位文本 device get_device() if device(texttext).exists(timeout5): device(texttext).set_text(content) return f已向 {text} 输入内容 return f未找到输入框{text} mcp.tool() def take_screenshot(save_path: str) - str: 截图并保存到指定路径 device get_device() device.screenshot(save_path) return f截图已保存{save_path} if __name__ __main__: mcp.run()这个 Server 提供了设备信息查询、按文本点击、输入文本、截图四个工具。实际项目中可能还需要补充滑动、等待、断言、读取日志等能力可以根据需要扩展。需要说明的是uiautomator2的定位方式相对简单实际项目中可能还需要支持 resourceId、className、坐标定位这里只做最小演示。5.3 编写 Skill 描述文件在skills目录下创建登录冒烟测试的 Skill 描述文件。# 文件路径skills/login_smoke_test/SKILL.md # 登录模块冒烟测试 Skill 当用户要求对 APP 登录模块执行冒烟测试时使用本技能。 前置条件 - 已连接 Android 测试设备或模拟器 - APP 已安装并处于未登录状态 执行步骤 1. 启动 APP确认进入登录页面。 2. 输入测试账号 test_user。 3. 输入测试密码 test_password。 4. 点击登录按钮。 5. 等待页面跳转截图并记录结果。 6. 如果登录失败获取当前页面日志输出失败原因。 校验规则 - 登录成功后页面应跳转到首页并显示用户昵称。 - 登录失败时页面应给出明确错误提示禁止使用生产账号测试。 输出格式 - 每一步输出操作结果、截图路径、日志摘要。 - 最后输出测试结论通过或失败。这个 Skill 把测试逻辑写成了模型可读的步骤。模型加载后会按步骤执行并在需要操作设备时调用 MCP 工具。5.4 编写测试用例脚本虽然 Skill 可以让模型自动执行但工程实践中往往需要把核心场景固化为可重复运行的脚本。下面是一个基于 pytest 的登录冒烟测试脚本示例。# 文件路径test_cases/test_login.py import pytest import uiautomator2 as u2 pytest.fixture(scopemodule) def device(): d u2.connect() yield d d.app_stop(com.example.app) def test_login_success(device): # 启动 APP device.app_start(com.example.app) # 这里用 resourceId 定位示例实际以 APP 为准 device(resourceIdcom.example.app:id/username).set_text(test_user) device(resourceIdcom.example.app:id/password).set_text(test_password) device(resourceIdcom.example.app:id/login_btn).click() # 断言进入首页 assert device(text首页).wait(timeout10), 登录后未进入首页 device.screenshot(reports/login_success.png)这里用固定包名和 resourceId 做演示实际项目请替换成被测 APP 的真实信息。如果没有找到对应控件可以用uiautomator2的 dump 功能先查看控件树。5.5 运行与验证启动 MCP Serverpython mcp_servers/device_tools_server.py然后在你使用的 AI Agent 中配置 MCP 连接指向本机的 MCP Server。配置方式因 Agent 而异有的是图形界面添加有的是编辑mcp.json文件。配置完成后可以直接向 AI 提问例如“请对登录模块执行冒烟测试按 login_smoke_test Skill 流程执行并输出报告。”模型会加载 Skill调用 MCP 工具逐步操作设备最终输出测试结论。你也可以直接运行 pytest 脚本做确定性回归pytest test_cases/test_login.py -s运行后会在reports目录下生成截图在终端输出断言结果。6. 常见问题与排查思路实际落地时遇到的坑往往不在 AI 本身而在工具链和环境配合。以下是一些高频问题。问题现象常见原因解决思路MCP Server 无法启动Python 依赖版本冲突或端口被占用检查依赖版本换端口查看日志确认报错位置AI 找不到 MCP 工具MCP Server 未正确注册或 Agent 配置错误在 Agent 中刷新 MCP 连接确认服务端已加载元素定位失败页面 loading 未结束或控件属性不稳定增加等待条件改用 resourceId 或坐标定位测试账号登录频繁触发风控测试环境没有处理验证码策略联系开发配置测试环境关闭风控或使用专用测试账号Appium 或 uiautomator2 无法连接设备adb 未授权或驱动问题检查 USB 调试授权运行 adb devices 确认设备状态截图生成但打不开图片写入路径不存在或权限不足提前创建 reports 目录检查写入权限AI 跳过关键测试步骤Skill 描述不够结构化重写 Skill使用编号步骤和明确的预期结果测试结果不稳定偶发失败网络波动、页面渲染耗时变化加入重试机制或把关键步骤改为确定性脚本排查顺序建议是先确认设备连接正常再确认 MCP Server 是否可调用接着确认 Skill 是否被模型正确读取最后再检查脚本本身。7. 最佳实践与工程建议7.1 安全与权限边界AI 测试涉及设备操作、账号使用、数据读取必须设置权限边界。使用专用测试设备和测试账号禁止使用生产数据。涉及支付、删除、修改等高风险操作时在 Skill 中明确禁止或增加人工确认环节。MCP Server 不要监听公网地址默认绑定 127.0.0.1 即可。日志和截图中可能包含敏感信息注意脱敏避免把个人信息写入测试报告。7.2 用例稳定性与可重复性AI 生成的用例灵活但灵活性也带来不确定性。工程落地时建议采用分层策略。核心回归场景必须固化为确定性脚本保证每次运行结果稳定。AI 适合做探索性测试、用例生成、失败分析但关键链路的执行结果不能完全依赖模型判断。所有用例尽量做到无状态不依赖上一次运行留下的数据。用例开始前重置 APP 数据或使用独立账号避免脏数据影响结果。7.3 报告与日志规范测试报告不是给模型看的是给人看的。生成报告时要考虑阅读者能不能快速定位问题。建议报告包含以下字段测试时间、设备信息、APP 版本用例列表及通过率失败步骤截图和日志摘要失败原因初步分析操作步骤还原方便复现日志规范上统一使用时间戳命名文件目录结构按日期和模块划分。这样后续定位问题时能快速找到对应的截图和日志。7.4 测试环境隔离AI 测试流程涉及多类中间件环境隔离很重要。MCP Server 环境与开发环境分离避免依赖冲突。测试数据与真实数据隔离数据库连接使用只读权限或测试库。多设备执行时设备命名和连接池要做好管理避免并发冲突。每次大规模执行前确认被测 APP 版本和测试环境一致。8. 后续学习路线与总结本文从概念到实战介绍了 Skill 和 MCP 在 APP 测试中的应用方式。核心要点可以归纳为三句话Skill 管流程MCP 管工具模型做编排。把这套思路想清楚AI 测试就不是“让 AI 随便点点”而是“让 AI 按你的工程规范高效执行”。如果你准备从传统测试转向 AI 测试建议按这个顺序去练先掌握至少一个移动端自动化框架比如 uiautomator2 或 Appium理解设备操作的基本原理。再学 MCP 的基础协议和 Server 编写尝试把你的现有测试工具封装成一个 MCP Server。然后写一个自己的测试 Skill把团队常用的测试流程整理成结构化文档让 AI 可以按流程执行。最后把 AI 生成能力、确定性脚本、报告系统组合起来形成一套半自动化的测试闭环。工具变化很快但测试思维不会过时。理解业务流程、设计有效用例、沉淀测试经验这些能力无论工具怎么变都是测试工程师的核心价值。AI 不会替代你分析业务、判断风险、推动质量改进它只是把重复工作接了过去让你有更多时间做真正重要的事。