把 APP 测试交给 AIAgent 时最容易被忽略的是 Skill。很多人习惯了用一句自然语言让 Agent 写测试脚本但真正的痛点往往不在脚本本身而在测试设计是否完整、缺陷报告是否可追溯、回归范围是否收敛。Skill 恰好解决的是这一层问题它不是又一个自动化框架而是一份可以反复调用的“岗位说明书”把测试规范、输出模板、判断标准全部灌进 Agent 的上下文里。这篇文章按 90 分钟的时间线展开从零写一个面向 APP 测试的 Skill并验证它在用例生成、缺陷报告和回归清单三个场景里的实际效果。1. 先搞清楚 Skill 在 AIAgent 里到底扮演什么角色1.1 从“临时提问”到“岗位说明书”使用 AIAgent 做测试时常规做法是每次临时描述需求比如“帮我写登录页的测试用例”。这种写法的结果很不稳定同样是“登录页”昨天生成的用例可能是 10 条今天可能变成 6 条昨天包含密码边界值今天只写了正常流程。问题不在模型而在每次对话都没有统一的业务规则、模板和验收标准。Skill 解决的就是这个不稳定性。它本质上是一个结构化的指令包通常以目录形式存在目录里包含一个核心说明文件常见命名为 SKILL.md和若干辅助文件。你可以把它理解成给一个能力很强的实习生写了一份入职文档文档里写清楚他的职责边界、做事步骤、输出格式、常见错误和检查清单。Agent 在需要时加载这份文档按里面的规则执行输出结果自然更稳定、更符合团队约定。在 APP 测试场景里Skill 能沉淀的东西非常具体用例设计规则、缺陷报告模板、平台差异注意事项、回归优先级判断标准。这些内容如果每次靠口头描述既啰嗦又容易遗漏放进 Skill 之后就是一次编写、反复使用。1.2 Skill 与 MCP、普通 Prompt 的边界很多人会把 Skill 和 MCPModel Context Protocol搞混因为它们的名字都带“能力扩展”的感觉。这里需要先把边界划清楚。普通 Prompt 是一次性的口头交代它的优点是灵活缺点是约束力弱Agent 很容易在长对话中偏离原始要求。MCP 解决的是 Agent“能做什么”的问题它把外部工具、API、数据源以协议方式暴露给 Agent。比如通过 MCP 服务Agent 可以查询测试环境数据、调用缺陷管理系统接口、读取 CI 产物。Skill 解决的是 Agent“做得符不符合规范”的问题。它不直接提供工具而是提供做事的标准流程和输出模板。一个比较形象的比喻是MCP 给 Agent 提供了手Skill 给 Agent 提供了操作手册。两者可以配合使用但职责不同。维度普通 PromptSkillMCP本质一次性的自然语言指令可复用的结构化能力包工具和数据接入协议解决什么问题临时问答输出稳定性和规范性外部能力调用是否需要维护不需要需要版本管理需要服务部署在 APP 测试中的例子“写一个登录测试用例”“按团队模板生成登录模块测试用例”“从缺陷系统读取 bug 列表”1.3 APP 测试场景里 Skill 能沉淀什么移动端测试和 Web 测试有一个明显区别环境碎片化。Android 要面对厂商 ROM、屏幕尺寸、系统版本iOS 要面对不同机型和系统收敛。这些差异如果全部靠测试人员每次口头交代给 Agent效率极低。Skill 可以把这些注意事项固化下来。一个面向 APP 测试的 Skill建议优先沉淀以下五类内容测试设计规则等价类、边界值、场景法等基础方法的应用要求。用例模板用例编号、优先级、前置条件、操作步骤、预期结果、测试数据。缺陷报告模板严重级别、环境信息、复现步骤、实际结果、预期结果、日志和截图要求。平台差异清单Android 和 iOS 在权限弹窗、返回手势、键盘表现等方面的差异。回归范围判断规则根据改动模块推导影响面确定冒烟、增量、全量回归的范围。注意不要把 Skill 写成一本教科书。它应该像一份可执行的工作手册而不是大而全的测试理论合集。规则过多反而会稀释 Agent 对关键规则的遵循度。2. 90 分钟时间线先搭环境再跑通第一个 Skill2.1 先按时间分配任务90 分钟听起来很短但如果目标只是跑通一个最小闭环时间是充足的。关键是不能在环境问题上恋战。建议按下面的时间块推进时间段任务产出物0-10 分钟理解 Skill 概念和加载机制确定用哪种 Agent 工具10-25 分钟安装 Agent CLI、确认运行环境能打开 Agent 交互终端25-50 分钟编写第一个 APP 测试 Skill可加载的 Skill 目录50-65 分钟接入 adb 命令和模板文件用例、缺陷报告、回归清单模板65-80 分钟用三个场景做运行验证验证结果和问题记录80-90 分钟修正规则、补充 few-shot 示例稳定可复用的 Skill 版本这个时间线假设你已经具备基本的 APP 测试常识比如知道冒烟测试和回归测试的区别知道 adb 是 Android 调试桥。如果这些概念还不熟环境搭建部分需要额外预留时间。2.2 准备好 Agent 运行环境当前常见的 Agent 工具有 Claude Code、Codex CLI、Cursor 以及 opencode 等开源方案。不同工具对 Skill 的命名和加载位置有差异但核心思路一致在一个约定的目录里放置 Skill 文件Agent 根据描述信息决定何时加载。以通用方式描述你至少需要准备一个可用的 Agent CLI 工具安装完成后在终端执行版本命令能正常输出版本号。Git 环境用于管理 Skill 版本。一个测试目标 APP 的包名、入口 ActivityAndroid或 Bundle IDiOS。本机安装 adbAndroid 调试桥并且能通过adb devices看到已连接的设备或模拟器。以下命令可以用来快速确认环境是否就绪# 确认 CLI 工具可用实际命令以你选择的工具为准 claude --version # 确认 Git 可用 git --version # 确认 adb 可用并且设备已连接 adb devices如果原始材料没有给出明确的版本要求落地前要先确认你选择工具的 Skill 文档重点看三件事SKILL.md 的文件名要求、前置元数据字段要求、支持的辅助文件类型。不同工具对这三个点的兼容性不算高这是新手换工具后最容易踩的坑。2.3 Skill 的目录结构和加载方式绝大多数 Agent 工具的 Skill 都采用类似下面的目录结构skills/ └── app-test-assistant/ ├── SKILL.md ├── templates/ │ ├── test-case-template.json │ ├── bug-report-template.md │ └── regression-checklist.md └── examples/ ├── login-smoke-cases.md └── crash-bug-report.mdSKILL.md 是主文件通常以 YAML frontmatter 开头声明 name 和 description。description 字段非常关键因为 Agent 会读取它来判断“当前任务是否需要加载这个 Skill”。描述写得越具体加载命中率越高。一个最小可用的 SKILL.md 模板如下--- name: app-test-assistant description: 适用于移动 APP 测试场景用于生成测试用例、编写缺陷报告、制定回归清单。当用户提到 APP 测试、用例设计、bug 报告或回归时使用。 --- # APP 测试助手 你是一个移动 APP 测试专家。你的任务是按照团队规范输出高质量的测试产物。 ## 工作流程 1. 确认测试对象APP 名称、平台、版本。 2. 确认测试类型冒烟、功能、回归、兼容性。 3. 按对应模板输出结果。 ## 输出要求 - 所有用例必须包含编号、优先级、前置条件、操作步骤、预期结果。 - 预期结果必须可验证不能出现“正常”“良好”这类模糊描述。这个模板的关键点在于用 description 告诉 Agent 何时加载用工作流程约束处理顺序用输出要求约束最终格式。三层约束各管一件事。2.4 用最小闭环验证 Skill 是否生效写完模板后不要直接写复杂规则先用一个最小问题验证 Skill 有没有被加载。可以这样问请为 APP 的登录功能生成 5 条冒烟测试用例。如果 Agent 输出的用例包含编号、优先级、前置条件、操作步骤、预期结果五个字段说明 Skill 已经生效。如果输出的是自由格式说明 Skill 没有被加载需要检查文件路径、文件名或 description 是否匹配。注意不要只验证 Agent 能不能“说话”要验证它是否按 Skill 里的约定“办事”。一次加载成功的标志不是回答变长了而是输出结构和模板一致。3. 写一个面向 APP 测试场景的 Skill3.1 先定义 Skill 需要处理的测试任务类型APP 测试场景很多一个 Skill 不可能也不需要覆盖全部。建议先圈定四类高频任务冒烟测试用例生成用于新版本提测后的第一轮快速验证。功能测试用例生成针对某个模块做系统性的功能覆盖。缺陷报告编写从测试现象、日志、截图整理出可执行的 bug 单。回归清单制定根据本次改动范围确定回归策略。每一种任务对应一种输出协议。把协议写清楚Agent 才不会把冒烟用例写成功能用例也不会把缺陷报告写成散文。3.2 用例生成把需求描述转换成结构化用例用例生成是 Agent 最容易“自由发挥”的部分所以 Skill 里必须写清楚用例结构。推荐在 SKILL.md 里直接嵌入一个 JSON 模板要求 Agent 按模板输出。{ caseId: LOGIN_001, module: 登录, priority: P0, title: 正确账号密码登录成功, preconditions: APP 已安装网络正常账号已注册, steps: [ 1. 打开 APP进入登录页, 2. 输入正确手机号和密码, 3. 点击登录按钮 ], expectedResult: 登录成功进入首页顶部显示用户昵称, testData: phone: 13800138000, password: Test123 }同时Skill 里要内置测试设计方法的最低要求否则 Agent 只会写“正常流程”。可以在规则里写明每个输入框至少包含正常值、边界值、空值、非法格式。流程类用例至少覆盖主路径、分支路径、异常路径。每个用例只验证一个核心结果不要在一个用例里堆多个断言。用少数规则加一个模板比堆砌二十条抽象规则更有效。3.3 缺陷报告让 Agent 输出可执行 bug 单缺陷报告的价值在于“别人拿到就能复现”。Skill 里的缺陷模板必须强制要求以下字段字段是否必填填写要求缺陷标题是现象 模块例如“登录页输入错误密码无提示”严重级别是P0-P3并给出判断理由环境信息是设备型号、系统版本、APP 版本、网络类型复现步骤是每条步骤必须有具体操作对象和动作实际结果是描述观察到的现象附上截图或日志预期结果是需求文档中的规定行为日志/截图是指定日志抓取命令和截图方式下面是一个符合要求的缺陷报告示例## 缺陷标题 登录页输入错误密码后无任何错误提示界面无响应 ## 严重级别 P1阻断用户登录且无错误反馈 ## 环境信息 - 设备Pixel 6 - 系统Android 14 - APP 版本v2.3.0 - 网络Wi-Fi ## 复现步骤 1. 打开 APP进入登录页 2. 输入已注册手机号 13800138000 3. 输入错误密码 123456 4. 点击登录按钮 ## 实际结果 页面停留 3 秒后无任何提示无跳转无 Toast ## 预期结果 提示“密码错误”输入框保留已输入内容 ## 日志与截图 adb logcat -d -v time | grep -i errorSkill 里的规则要特别强调一点复现步骤里的每个动作都必须描述“操作对象、操作动作、输入数据”不允许出现“随便”“正常”这类词。3.4 回归范围让 Agent 给出可收敛的清单回归测试最容易出现的两个极端是范围过大和范围过小。范围过大会浪费测试时间范围过小会漏测。Skill 里需要写一套简化版的回归判断规则例如改动登录模块则回归范围 登录模块冒烟 账号相关模块 支付流程。改动列表页则回归范围 列表展示 下拉刷新 详情页跳转 分页加载。修改公共组件则回归范围 所有引用该组件的页面冒烟。新增字段则额外关注数据兼容和旧版本解析。同时要求 Agent 输出回归清单时标注每条用例的优先级和预计执行时间方便测试人员排期。## 回归清单v2.4.0 登录模块改动 | 优先级 | 用例编号 | 用例名称 | 预计耗时 | 说明 | | --- | --- | --- | --- | --- | | P0 | LOGIN_SMOKE_001 | 手机号密码正确登录 | 5 分钟 | 冒烟必跑 | | P0 | LOGIN_SMOKE_002 | 退出登录 | 3 分钟 | 冒烟必跑 | | P1 | USER_001 | 修改昵称后首页展示 | 8 分钟 | 账号相关 | | P1 | PAY_001 | 未登录状态下发起支付跳转登录 | 10 分钟 | 涉及登录态 |4. 把 Skill 接入 APP 测试执行链路4.1 根据当前条件选择接入模式Skill 只是让 Agent 输出的内容更规范真正执行测试还需要链路支撑。根据团队自动化程度有三种接入模式模式工作方式适用场景优点缺点内容助手Agent 只产出用例、报告、清单人工执行无自动化基础的小团队接入成本低见效快人工执行仍有耗时半自动Agent 输出 adb 命令和脚本片段人工复制执行有部分自动化基础保留人的判断风险可控需要人工复制粘贴全自动通过 CI 调用 Skill 生成的测试代码并由框架执行有成熟自动化框架效率最高可做质量门禁依赖框架稳定性和样本质量如果你只有 90 分钟建议先选内容助手或半自动模式。这两种模式不依赖复杂框架即使测试执行链路还没搭建Skill 也能先产生价值。4.2 半自动模式用 adb 命令连接 Agent 与设备在半自动模式下Skill 需要内置一组最常用的 adb 命令让 Agent 在输出测试步骤时直接给出可复制的命令。下面这组命令在 Android 测试中足够覆盖大部分场景# 查看当前前台页面对应的 Activity adb shell dumpsys window | grep mCurrentFocus # 启动指定应用的指定页面需要包名和 Activity 名 adb shell am start -W -n com.example.app/.MainActivity # 抓取崩溃和错误日志 adb logcat -d -v time *:E # 截取当前屏幕并保存到本地 adb exec-out screencap -p screen.png # 通过 monkey 做随机压力测试 adb shell monkey -p com.example.app 500在 SKILL.md 里可以要求 Agent 输出用例时在操作步骤后面追加对应的 adb 命令方便测试人员直接执行。要注意的是不同 APP 的包名和 Activity 不同Skill 应该要求 Agent 先向用户确认这两个信息而不是自己编造。4.3 定义“测试通过”的可验证标准Agent 生成的测试用例经常存在一个问题预期结果写得太抽象。比如“页面显示正常”“功能正常”这类表述测试人员执行后无法判断到底算不算通过。Skill 里必须强制约定预期结果要写成“可观测的行为”。弱断言示例页面正常跳转。数据展示正确。强断言示例点击登录按钮后5 秒内跳转到首页首页顶部显示当前登录用户昵称。列表页下拉刷新后第一条数据的标题从空变为“北京今日天气”刷新时间戳更新为当前时间。规则可以写成预期结果必须包含观察对象、变化状态和可量化条件。一次会话中如果没有改动需求仍应输出可验证的断言而不是声称“测试通过”。注意在自动化未覆盖的场景里“人工确认并通过”本身就是一种结论。Skill 可以要求 Agent 在回归清单里增加“执行人”“执行结果”“备注”字段让人的确认动作成为流程的一部分。5. 运行验证用三个典型场景检验 Skill 效果5.1 场景一生成登录模块冒烟测试用例给 Agent 输入以下需求登录模块冒烟测试Android 设备v2.3.0 版本。验证点输出是否包含 5 条以上的冒烟用例。每条用例是否包含编号、优先级、前置条件、操作步骤、预期结果。用例是否覆盖正常登录、错误密码、空输入、网络异常、退出登录五个方向。预期结果是否可验证而不是“正常”“成功”这类空泛词。如果前两点不达标优先检查 SKILL.md 的 description 是否被命中或模板是否放在 Agent 能找到的位置。5.2 场景二根据崩溃日志生成缺陷报告给 Agent 输入一段真实或模拟的崩溃日志片段FATAL EXCEPTION: main java.lang.NullPointerException: Attempt to invoke virtual method void android.widget.TextView.setText (java.lang.CharSequence) on a null object reference at com.example.app.login.LoginActivity$1.onClick(LoginActivity.java:88)验证点缺陷报告是否包含复现步骤、环境信息、严重级别。是否根据日志定位到了 LoginActivity 第 88 行的空指针。是否补充了日志获取方式和截图建议。这里最常见的失败情况是 Agent 只复述日志内容没有按要求输出结构化 bug 单。如果出现这种情况检查模板文件是否被 Skill 引用以及示例文件 examples/crash-bug-report.md 是否提供了足够的 few-shot 参考。5.3 场景三发布前的回归清单给 Agent 输入本次改动涉及登录页重写、用户协议弹窗新增、首页 Tab 结构调整请制定回归清单。验证点清单是否区分 P0/P1/P2 优先级。是否覆盖登录回归、协议合规检查、首页冒烟、账号相关模块。是否给出预计耗时方便排期。5.4 验证后的修正动作三组场景跑完后把不满足要求的输出记录下来回到 SKILL.md 里补两样东西一是补充失败场景对应的规则二是补充一条成功输出的 few-shot 示例。经过一到两轮迭代Skill 的稳定性会有非常明显的提升。6. 常见问题与排查路径6.1 Skill 加载了但 Agent 不按规则执行现象Agent 回答里带有 Skill 里的模板字段但格式仍不完整或者步骤描述依然很笼统。可能原因有三个规则的粒度不够示例不足输出要求被放在规则末尾Agent 在长输出时遗忘了。检查方式先看 SKILL.md 前 40 行是否已经写清楚“输出必须包含哪些字段”再看是否提供了至少一个完整示例。处理建议把强制要求放在 SKILL.md 最前面并且用“输出必须符合以下结构”这样带有强制意味的表述。同时补充一个示例让“照着做”的成本降到最低。6.2 测试步骤太笼统无法落到具体操作现象Agent 写的步骤是“输入手机号”“点击登录”没有具体账号密码也没有说明在哪个页面操作。原因SKILL.md 没有规定步骤必须包含操作对象、操作动作和输入数据。检查方式抽查生成的用例统计有多少条步骤包含具体数据。处理建议在规则里增加一条硬性要求例如“操作步骤中出现的每个输入框都必须提供测试数据不允许使用‘输入正确账号’这种表述”。6.3 输出格式不稳定后续无法自动解析现象同一份需求问两次一次输出 JSON一次输出 Markdown 表格。原因SKILL.md 里没有指定输出格式或者同时给了多种格式让 Agent 自行选择。检查方式对比两次输出确认是否存在格式漂移。处理建议在模板里明确指定唯一格式并在 SKILL.md 中写明“默认输出 Markdown 表格除非用户明确要求 JSON”。如果需要自动化解析建议直接让 Agent 输出 JSON 并附上 schema。6.4 不同 Agent 工具的 Skill 不通用现象在 Claude Code 中写好的 Skill放到 Codex 或 Cursor 里无法加载。原因不同工具对 file 命名、frontmatter 字段、目录位置的要求不一致。检查方式查看目标工具的 Skill 文档确认 frontmatter 是否使用 name/description是否依赖额外配置文件。处理建议把 Skill 的核心内容与工具适配层分离。SKILL.md 里的测试规则保持工具无关只在导入时写一层适配配置。这样同一套测试规范可以复用到多个工具。6.5 排查清单序检查项检查方法1Skill 目录是否在 Agent 的扫描范围内查看工具日志或加载命令2SKILL.md 文件名和 frontmatter 是否正确对比官方示例3description 是否与任务描述匹配用典型提问验证加载4模板文件路径是否被正确引用要求 Agent 输出模板内容5规则是否与示例一致比对示例输出和规则字段6是否区分了学习环境与生产环境确认用例中的包名、设备信息非虚构7. 最佳实践与扩展方向7.1 让 Skill 保持最小职责一个 Skill 只负责一类职责不要试图写一个“万能测试 Skill”。用例生成、缺陷报告、回归清单可以分拆成三个 Skill通过引用关系组合。这样每个 Skill 的规则少而精Agent 遵循度更高排查问题也更容易定位。7.2 用示例驱动不要用规则堆砌对于大模型来说两三个完整示例比十条抽象规则更有约束力。在 examples 目录里放一份优秀用例、一份优秀缺陷报告、一份优秀回归清单让 Agent 在不确定时模仿示例的输出结构。规则负责兜底示例负责定调。7.3 版本管理和效果评估Skill 本身也是代码资产应该放进 Git 管理。每次调整规则后补一条 changelog并准备一组固定的评估样例例如三个标准需求每次改动后用同一组样例回归验证确保新规则没有破坏旧输出。7.4 扩展方向从测试助手走向质量门禁Skill 的下一步不是停留在“生成内容”而是接入 CI 构建链路需求变更触发 Agent 调用回归 Skill生成回归清单交由自动化框架执行再把执行结果汇总给测试人员。再进一步可以让 Skill 结合 MCP 连接缺陷管理系统测试人员确认 bug 后直接通过调用创建缺陷单。到这个阶段Skill 才真正从一个“工作搭子”变成质量体系里的一环。对新手来说90 分钟能完成的只是第一步跑通结构、验证规则、沉淀模板。真正有价值的是后续迭代把团队自己的测试规范一点点灌进 Skill 里。这个循环跑顺之后你的 APP 测试效率提升不是来自某个神秘工具而是来自一套可复用、可追溯、可改进的 Agent 工作规范。