最近和几位测试朋友聊天大家都有一个共同的体感软件测试这个岗位最消耗人的往往不是测试本身而是测试周围的“杂活”。需求评审结束业务只丢过来一段描述你得手动拆成几十条测试用例接口文档更新一版之前的脚本断言全要跟着改回归测试开始前又得翻历史用例确认这次到底覆盖哪些模块收工后还要把通过率、失败原因整理成报告。这些工作有一个共同特征规则明确、流程固定、重复性极高。过去的提效手段是建模板、写脚本、上测试平台。这些方法都有效但都有一个共同问题它们不会自动“接活”。模板不会在对话里自动识别需求场景脚本不会主动判断该在哪一步运行测试报告也不会在用例执行完后自动汇总。Skill 正在改变这个局面。它不是一个新测试平台也不是传统意义上的测试框架而是把测试方法论、执行脚本和判断规则打包成一个 AI Agent 可以直接读取和执行的能力包。你可以把它理解成“给测试工程师配了一个按标准流程工作的数字助手”。当 Agent 识别到用户正在描述登录功能需求时它会自动加载测试用例生成 Skill按照你预设的用例设计规则产出结构化用例当用户给出 OpenAPI 文档时接口测试 Skill 会自动生成 pytest 脚本。测试人员需要做的开始从“写”变成“审”。这篇文章就来拆解一套测试人可落地的“测试全流程提效 Skill 合集”。我会先解释 Skill 到底是什么再分别给出测试用例生成、接口自动化、UI 自动化三个场景的完整 Skill 结构、脚本代码和验证方式最后整理常见问题与工程建议。读完你可以直接照着做一个属于自己团队的 Skill并把测试流程中相对机械的部分交给 Agent 执行。1. 测试全流程提效的核心痛点与 Skill 的解决思路在引入 Skill 之前先想清楚一个问题测试流程里到底哪些环节是真正值得提效的从工作量分布看测试工作的重复劳动集中在四个环节。第一测试用例设计。需求描述到测试用例之间存在一层固定的“翻译”工作。等价类、边界值、异常流、主路径这些方法是有套路的但每次需求变化都得手工重来。第二接口自动化脚本。接口字段、必填参数、返回状态码这些信息在接口文档里已经写清楚了但人工转成 pytest 脚本仍然要花不少时间。第三UI 自动化维护。元素定位器一变脚本就要跟着调整个过程重复且没有创造性。第四测试报告汇总。执行完用例统计通过率、整理失败原因、汇总遗留风险规则简单但操作琐碎。传统做法也会做“提效”把用例模板做成 Excel把接口脚本放在 Git 仓库里复用把报告模板做成 Word 文档。但这些资产都是“等用户调用”的静态文件。如果你不记得有某个模板它就永远躺在那里如果你不手动执行脚本它就永远不会跑如果你不打开 Word 模板报告也不会自己生成。Skill 的解决思路完全不同它把“流程”本身交给 Agent。你输入需求或接口文档Agent 根据 Skill 里的说明文件自动判断当前属于哪个测试场景然后按设定步骤执行脚本、加工输出。也就是说以前是你“找工具”现在变成了“工具找你”。这里需要明确一个判断Skill 并不是要替代测试工程师的思考而是把已经成熟的测试规则固化成标准动作。真正需要判断力的场景比如业务风险的权衡、复杂缺陷的定位、测试策略的选择仍然由人来完成。Skill 最适合取代的是“方法明确但操作繁琐”的环节这类环节在测试流程中恰好占比很高。2. 什么是 SkillAgent Skill 与 MCP 的边界“Skill”这个词在测试圈出现频率还不高但在 AI Agent 领域已经是核心概念。简单说Skill 是一个结构化的能力包通常包含一个说明文件、若干脚本和参考资源。它的作用是教会 AI Agent 完成某一类具体任务。以测试场景为例一个“测试用例生成 Skill”可能包含以下内容一个 SKILL.md 说明文件写明这个 Skill 适用于什么场景、如何触发、执行步骤有哪些、输出格式是什么。一个 Python 脚本负责把需求文本解析成用例 JSON。一份参考文档记录团队常用的边界值规则、缺陷统计和命名规范。当 Agent 收到用户消息“帮我给登录功能生成测试用例”时它会检测到这条消息与某个 Skill 的 description 匹配于是读取该 Skill 的说明文件按说明中的步骤调用脚本、生成并格式化结果最终输出测试用例给用户。整个过程相当于给 Agent 装上了“测试领域的操作手册”。很多人会把 Skill 和 MCPModel Context Protocol混淆这两个概念确实相关但解决的问题不同。MCP 解决的是“连接”问题。它是一套标准协议让 AI Agent 能够调用外部工具、查询数据库、读写文件系统、访问第三方系统。你可以把 MCP Server 理解成一个标准化的 API 网关Agent 通过它拿到外部数据或操作外部系统。Skill 解决的是“方法”问题。它不直接连接外部系统而是教 Agent“遇到某类任务时应该按什么步骤做、用什么脚本、产出什么格式”。Skill 更像一份带工具的工作流程说明书。两者可以组合使用。一个接口自动化测试 Skill 可以定义测试流程和代码生成逻辑而流程中需要调用内网测试环境接口时则通过 MCP Server 完成调用。简单总结对比项SkillMCP核心目标固化任务流程与业务规则统一外部工具与数据连接存在形式目录中的说明文件、脚本、资源MCP Server 提供的工具接口是否需要网络服务一般不需要通常需要 Server 运行典型例子测试用例生成 Skill通过 MCP 查询缺陷库、操作测试环境与 Agent 的关系决定“怎么做”决定“能做什么”对测试团队来说这两个不是二选一的关系。比较自然的落地方式是先积累 Skill把团队最常用的测试流程固化下来当 Skill 中的脚本需要访问具体测试系统时再通过 MCP 打通。3. 环境准备与 Skill 基本结构写 Skill 并不需要特别复杂的工具链核心是准备一个支持 Skill 机制的 Agent 环境并安装必要的测试依赖。环境准备清单如下支持 Skills 机制的 Agent 客户端或编码助手命令行工具。目前多家主流 AI 编程工具都在引入类似能力建议查阅你所用工具的最新文档确认它通过skills目录还是SKILL.md文件加载技能。Python 3 解释器版本以当前项目实际环境为准。本文的脚本均基于 Python 开发不依赖特定 Python 小版本。测试相关 Python 库至少包含pytest、requests、Appium-Python-Client。安装命令如下pip install pytest requests Appium-Python-Client如果涉及 UI 自动化准备已安装 Appium Server 的机器或模拟器环境。建议使用 Git 对 Skill 目录进行版本管理。准备完成后先理解 Skill 的标准目录结构。这里给出一个测试用例生成 Skill 的示例skills/ └── test-case-generator/ ├── SKILL.md ├── scripts/ │ └── generate_test_cases.py └── references/ └── boundary_rules.md其中SKILL.md是这个 Skill 的入口文件承担两个职责一是让 Agent 知道自己适合处理什么任务二是告诉 Agent 处理任务的具体步骤。scripts目录存放可执行脚本references目录存放供 Agent 和用户参考的业务规则、模板和案例。一个最小可用的SKILL.md长这样--- name: test-case-generator description: 根据功能需求描述生成标准测试用例骨架。当用户提供需求描述并提到“生成测试用例”“写测试点”“整理用例”时使用。 --- # 测试用例生成 Skill ## 适用场景 - 需求文本已确认需要快速生成正向、反向、边界用例。 - 测试计划中需要结构化用例清单。 ## 使用步骤 1. 读取用户提供的需求描述。 2. 运行 python scripts/generate_test_cases.py --requirement 需求描述 --output test_cases.json。 3. 打开生成的 JSON逐条补充业务细节和测试数据。 4. 删除或降级明显不适用的用例按 P0/P1/P2 排序。开发 Skill 时有一个关键点description字段决定 Agent 是否会触发这个 Skill。如果 description 写得太窄Agent 可能识别不到写得太宽无关任务也会误命中。这个字段应该包含“任务场景词”和“用户常见说法”两部分。4. 测试用例生成 Skill从需求文本到结构化用例测试用例设计是测试流程中最适合第一个 Skill 化的环节因为规则相对固定正向用例覆盖主路径反向用例覆盖异常输入边界用例覆盖临界值。任何需求都可以先按这三类生成骨架再人工补足业务细节。先创建脚本目录和脚本文件# 文件路径skills/test-case-generator/scripts/generate_test_cases.py import argparse import json import re from datetime import datetime def parse_requirement(text: str) - dict: 从需求文本中提取模块名。这里是最简解析实际场景可以接入更细规则。 lines [line.strip() for line in text.splitlines() if line.strip()] module lines[0][:20] if lines else 未命名模块 return {module: module} def generate_case(prefix: str, case_type: str, module: str) - dict: if case_type positive: return { case_id: f{prefix}-01, module: module, type: 正例, title: 验证正常业务主路径, preconditions: 系统处于可测试状态已有对应业务数据, steps: [进入功能模块, 输入符合规则的合法数据, 点击提交], expected_result: 操作成功页面提示正确数据落库正确, priority: P0, } elif case_type negative: return { case_id: f{prefix}-02, module: module, type: 反例, title: 验证非法输入的拦截, preconditions: 系统处于可测试状态, steps: [进入功能模块, 输入为空或超长或格式非法, 点击提交], expected_result: 系统给出校验提示不能提交成功, priority: P1, } else: return { case_id: f{prefix}-03, module: module, type: 边界, title: 验证边界值场景, preconditions: 系统处于可测试状态, steps: [进入功能模块, 输入边界值附近数据, 点击提交], expected_result: 边界值按照需求规则被正确接受或拒绝, priority: P1, } def generate_cases(requirement_text: str): info parse_requirement(requirement_text) module info[module] cases [ generate_case(TC-001, positive, module), generate_case(TC-002, negative, module), generate_case(TC-003, boundary, module), ] return {module: module, generated_at: datetime.now().isoformat(), cases: cases} if __name__ __main__: parser argparse.ArgumentParser(description根据需求文本生成测试用例骨架) parser.add_argument(--requirement, requiredTrue, help需求描述文本或文件路径) parser.add_argument(--output, defaulttest_cases.json, help输出 JSON 文件路径) args parser.parse_args() if args.requirement.endswith(.txt) or args.requirement.endswith(.md): with open(args.requirement, r, encodingutf-8) as f: requirement_text f.read() else: requirement_text args.requirement result generate_cases(requirement_text) with open(args.output, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2) print(f生成完成{args.output}共 {len(result[cases])} 条用例)这个脚本的核心逻辑是按固定模板生成三类用例。真实项目中你可以把“需求规则描述”和“历史缺陷类型”作为参考文件放到references目录然后在脚本中解析这些规则生成和团队业务更贴近的用例。运行方式如下cd skills/test-case-generator python scripts/generate_test_cases.py --requirement 用户登录手机号验证码登录验证码有效期60秒 --output login_cases.json预期会得到一份包含正例、反例、边界用例的 JSON 文件。Agent 拿到这个 JSON 文件后会根据 SKILL.md 指示结合用户描述继续补全具体测试数据并将最终用例整理成 Markdown 表格或测试管理平台可导入的格式。这里真正容易踩坑的地方是不要指望脚本一次性生成可以直接执行的完整用例。脚本生成的是骨架业务正确性需要人工补充。因此 SKILL.md 中务必写清楚“生成后需要人工审核”这一步避免 Agent 把未经验证的用例直接作为最终输出。5. 接口自动化测试 Skill一键生成 pytest 脚本接口测试是自动化收益最明显的领域。接口文档已经明确了路径、方法、参数和返回结构人工写脚本的价值主要在于处理断言逻辑、参数组合和测试数据。但第一步“骨架脚本生成”完全可以交给 Skill 完成。设计一个接口测试 Skill核心流程是读取 OpenAPI 规范文件解析路径和参数生成 pytest 测试函数骨架。# 文件路径skills/api-test-generator/scripts/gen_api_tests.py import argparse import json from typing import List, Dict def parse_openapi(path: str) - List[Dict]: 简化版从 OpenAPI JSON 中抽取基础路径、路径和参数信息。 with open(path, encodingutf-8) as f: spec json.load(f) tests [] base_path spec.get(servers, [{}])[0].get(url, http://127.0.0.1:8080) for full_path, methods in spec.get(paths, {}).items(): for method, detail in methods.items(): if method not in (get, post, put, delete): continue parameters detail.get(parameters, []) query_params [p[name] for p in parameters if p.get(in) query] tests.append({ function_name: test_ full_path.strip(/).replace(/, _).replace(-, _) _ method, method: method.upper(), path: full_path, query_params: query_params, base_path: base_path, }) return tests def render_pytest(tests: List[Dict], output: str) - None: lines [ import requests, , BASE_URL \http://127.0.0.1:8080\, , ] for t in tests: params_def , .join(f{p} for p in t[query_params]) lines.append(fdef {t[function_name]}({params_def}):) lines.append(f resp requests.{t[method].lower()}() lines.append(f BASE_URL \{t[path]}\,) if t[query_params]: params_call , .join(t[query_params]) lines.append(f params{params_call},) lines.append( )) lines.append( assert resp.status_code in (200, 201)) lines.append() with open(output, w, encodingutf-8) as f: f.write(\n.join(lines)) print(f已生成 {len(tests)} 个接口测试函数{output}) if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--spec, requiredTrue, helpOpenAPI JSON 文件路径) parser.add_argument(--output, defaulttest_api.py) args parser.parse_args() tests parse_openapi(args.spec) render_pytest(tests, args.output)这一步的输出是test_api.py。它生成了每个接口的测试函数并为查询参数预留了空字符串默认值。用户拿到这个文件后用实际测试数据替换空参数再补充断言细节即可。运行方式cd skills/api-test-generator python scripts/gen_api_tests.py --spec openapi.json --output test_api.py pytest test_api.py -q这个 Skill 的价值体现在“接口文档更新后”的场景传统做法是打开旧脚本逐个修改请求路径和参数容易漏改Skill 的做法是重新读取最新 OpenAPI重新生成一份基础脚本测试人员只需关注增量变化。这个流程将机械劳动压缩到了秒级。需要注意的是生成的脚本只包含基础断言。真正的价值判断比如响应体结构校验、数据库状态校验、异常响应校验仍需测试人员补充或通过业务规则库沉淀到 Skill 中。6. UI 自动化测试 SkillAppium 元素定位提效UI 自动化最容易被低估的难点是元素定位。移动端 App 的页面层级结构经常变化元素 ID 不稳定导致测试脚本维护成本远高于编写成本。Skill 在这个场景的价值是把“定位元素”这个最耗时的环节前置处理。设计一个 Appium UI 辅助 Skill它提供两个能力一是导出当前页面层级结构二是基于页面结构给出可用的定位器。下面是导出页面层级并统计可定位元素的脚本# 文件路径skills/appium-ui-helper/scripts/dump_hierarchy.py import argparse from appium import webdriver from appium.webdriver.common.appiumby import AppiumBy def dump_hierarchy(platform_version, device_name, app_package, app_activity, server_urlhttp://127.0.0.1:4723): # 以 Android 为例iOS 同理可根据实际设备调整 capabilities caps { platformName: Android, appium:platformVersion: platform_version, appium:deviceName: device_name, appium:appPackage: app_package, appium:appActivity: app_activity, appium:automationName: UiAutomator2, appium:noReset: True, } driver webdriver.Remote(server_url, caps) try: page_source driver.page_source with open(page_dump.xml, w, encodingutf-8) as f: f.write(page_source) print(页面层级已导出到 page_dump.xml) elements driver.find_elements(AppiumBy.XPATH, //*[resource-id]) print(f检测到 {len(elements)} 个带 resource-id 的元素) finally: driver.quit() if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--platform-version) parser.add_argument(--device-name, requiredTrue) parser.add_argument(--app-package, requiredTrue) parser.add_argument(--app-activity, requiredTrue) parser.add_argument(--server-url, defaulthttp://127.0.0.1:4723) args parser.parse_args() dump_hierarchy(args.platform_version, args.device_name, args.app_package, args.app_activity, args.server_url)运行时先确认设备已连接adb devices python dump_hierarchy.py --device-name emulator-5554 --app-package com.example.app --app-activity .MainActivity脚本会输出一份page_dump.xml里面记录了当前页面的完整控件层级。测试人员或 Skill 中的分析逻辑可以基于这份 XML推荐最稳定的定位方式优先使用 resource-id其次使用文本内容最后再考虑坐标。这套规则可以沉淀到 Skill 的参考文档中让 Agent 在生成 UI 自动化脚本时自动遵循。这个 Skill 解决的核心问题是“元素找不到”。当一个用例失败时执行 dump 脚本对比新旧页面层级通常几秒钟就能看出是元素 ID 变了还是页面结构完全改了。相比直接改脚本里的定位器这种排查方式更有据可依。7. 运行结果与效果验证Skill 做出来后需要用最小场景验证流程是否走通。下面用一个完整的验证过程说明预期效果。第一步验证测试用例生成 Skillcd skills/test-case-generator python scripts/generate_test_cases.py --requirement 用户登录手机号验证码登录验证码有效期60秒 --output login_cases.json cat login_cases.json预期输出会是一个 JSON包含module、created_at和cases三个字段。cases中包含三条用例case_id 分别为 TC-001-01、TC-001-02、TC-001-03。看到三条用例且字段完整说明脚本运行成功。如果输出为空或报编码错误优先检查 Python 版本和输入文本是否为 UTF-8 编码。第二步验证接口测试 Skillcd skills/api-test-generator python scripts/gen_api_tests.py --spec openapi.json --output test_api.py pytest test_api.py -q预期输出中gen_api_tests.py会打印“已生成 N 个接口测试函数”pytest会显示每个测试用例的执行结果。如果 pytest 执行失败不要急着改脚本先检查test_api.py中生成的 BASE_URL 是否正确、测试环境是否可访问。第三步验证 Appium UI 辅助 Skilladb devices cd skills/appium-ui-helper python scripts/dump_hierarchy.py --device-name emulator-5554 --app-package com.example.app --app-activity .MainActivity预期输出为“页面层级已导出到 page_dump.xml”和“检测到 N 个带 resource-id 的元素”。如果报连接错误先确认 Appium Server 是否启动再检查设备是否授权。整个验证过程的核心判断标准是脚本能完整跑通Agent 可以根据 SKILL.md 的指引自动完成脚本调用。如果一个 Skill 需要人工反复干预才能运行说明流程设计还不够标准应该继续拆分任务或补充参考文档。8. 测试 Skill 常见问题与排查方法上手 Skill 时会遇到不少问题这里整理最典型的几种问题现象可能原因排查方式解决方案Agent 不触发 SkillSKILL.md 中的 description 写得模糊缺少触发场景词查看 Agent 日志确认是否加载了该 Skill 目录重写 description明确触发条件和用户常见说法生成的测试用例全是模板业务性差脚本只有固定模板没有结合业务规则库查看生成 JSON对比脚本输入输出把团队历史缺陷、业务边界规则写入 references 文件接口测试脚本 pytest 运行失败生成的 BASE_URL 与实际环境不一致或依赖未安装运行pytest --collect-only检查报错信息统一环境变量配置执行pip install pytest requestsAppium 连接失败设备未连接、Appium Server 未启动运行adb devices检查 Appium Server 日志重启设备连接使用appium-doctor检查环境同一个需求生成结果不稳定SKILL.md 中的步骤描述不够细化多次运行对比输出差异拆分更明确的步骤把输出格式、审核要求写进说明文件多个 Skill 同时命中不同 Skill 的 description 有重叠场景检查各 SKILL.md 的触发条件为 Skill 增加边界说明明确各自适用场景这些问题的共性原因是 Skill 的说明文件没有把“何时用、怎么用、输出什么”讲清楚。Agent 对 Skill 的依赖本质上是文档驱动。文档越精确行为越可控。9. 测试 Skill 最佳实践与工程建议从零开始搭建测试 Skill 合集时可以直接参考以下工程经验避免走弯路。第一SKILL.md 结构标准化。每个 Skill 至少包含五部分适用场景、使用步骤、输入要求、输出格式、人工审核点。这样 Agent 在加载时能快速理解任务边界同时也能提醒测试人员哪些环节需要人工介入。第二Skill 命名规范。目录名建议使用 kebab-case例如test-case-generator、api-test-generator、appium-ui-helper。脚本统一放在scripts目录规则文档统一放在references目录。命名和目录结构保持一致后续扩展时更容易维护。第三脚本入参与出参保持稳定。Skill 脚本的可复用性取决于入参设计。例如测试用例生成脚本--requirement是入参输出文件是--output指定的 JSON。当这些接口固定下来后即使脚本内部实现大改Agent 的调用方式也不需要变化。第四测试环境信息通过环境变量注入。Skill 脚本里不要写死测试环境地址、账号和密码。例如接口测试的 BASE_URL应该支持通过环境变量TEST_BASE_URL覆盖避免因为环境切换而修改脚本。第五Skill 纳入版本管理。Skill 本质上也是代码资产应当纳入 Git。每次修改 SKILL.md 或脚本都需要走代码评审流程。特别是涉及测试规则变更时要像修改业务代码一样留下变更记录。第六建立 Skill 效果评估维度。可以统计使用 Skill 后用例设计耗时、接口脚本生成耗时、UI 用例维护频率这些指标。不需要做复杂平台用表格记录前后对比即可发现某个 Skill 长期没有减少耗时就说明它没有真正解决痛点。第七渐进式落地。不要一开始就做“测试全流程平台”而是选择一个最痛的点先跑通。推荐从测试用例生成开始因为它规则最清晰、风险最低、业务方最容易接受。跑通后再扩展接口自动化和 UI 辅助。第八注意安全边界。Skill 内不要存放任何敏感信息尤其是数据库连接串、云厂商密钥、用户个人信息。涉及外部系统调用时按照最小权限原则申请权限并在测试环境验证不要在生产环境直接执行未经验证的 Skill 脚本。10. 总结测试全流程提效 Skill 的核心理念是把测试人员已经验证过的规则、流程和脚本打包成 Agent 可执行的能力包让重复劳动回归自动化让人回归判断。这篇文章从 Skill 的基本概念出发给出了测试用例生成、接口自动化、Appium 辅助三个 Skill 的完整实现思路并补充了运行验证、常见问题排查和工程最佳实践。如果你现在正被重复的测试用例设计和接口脚本维护困住最好的起步方式不是重构整个测试流程而是先做一个最小 Skill把团队最常用的测试用例模板固化成一个脚本用一条命令让 Agent 帮你生成用例骨架。跑通之后再往里面加业务规则、接口生成、UI 辅助。测试提效的本质不是让工具替你思考而是把已经确定的方法论沉淀下来让 AI 替你执行重复部分你只做判断。 测试提效新利器：用Skill打包测试用例生成与接口自动化流程
最近和几位测试朋友聊天大家都有一个共同的体感软件测试这个岗位最消耗人的往往不是测试本身而是测试周围的“杂活”。需求评审结束业务只丢过来一段描述你得手动拆成几十条测试用例接口文档更新一版之前的脚本断言全要跟着改回归测试开始前又得翻历史用例确认这次到底覆盖哪些模块收工后还要把通过率、失败原因整理成报告。这些工作有一个共同特征规则明确、流程固定、重复性极高。过去的提效手段是建模板、写脚本、上测试平台。这些方法都有效但都有一个共同问题它们不会自动“接活”。模板不会在对话里自动识别需求场景脚本不会主动判断该在哪一步运行测试报告也不会在用例执行完后自动汇总。Skill 正在改变这个局面。它不是一个新测试平台也不是传统意义上的测试框架而是把测试方法论、执行脚本和判断规则打包成一个 AI Agent 可以直接读取和执行的能力包。你可以把它理解成“给测试工程师配了一个按标准流程工作的数字助手”。当 Agent 识别到用户正在描述登录功能需求时它会自动加载测试用例生成 Skill按照你预设的用例设计规则产出结构化用例当用户给出 OpenAPI 文档时接口测试 Skill 会自动生成 pytest 脚本。测试人员需要做的开始从“写”变成“审”。这篇文章就来拆解一套测试人可落地的“测试全流程提效 Skill 合集”。我会先解释 Skill 到底是什么再分别给出测试用例生成、接口自动化、UI 自动化三个场景的完整 Skill 结构、脚本代码和验证方式最后整理常见问题与工程建议。读完你可以直接照着做一个属于自己团队的 Skill并把测试流程中相对机械的部分交给 Agent 执行。1. 测试全流程提效的核心痛点与 Skill 的解决思路在引入 Skill 之前先想清楚一个问题测试流程里到底哪些环节是真正值得提效的从工作量分布看测试工作的重复劳动集中在四个环节。第一测试用例设计。需求描述到测试用例之间存在一层固定的“翻译”工作。等价类、边界值、异常流、主路径这些方法是有套路的但每次需求变化都得手工重来。第二接口自动化脚本。接口字段、必填参数、返回状态码这些信息在接口文档里已经写清楚了但人工转成 pytest 脚本仍然要花不少时间。第三UI 自动化维护。元素定位器一变脚本就要跟着调整个过程重复且没有创造性。第四测试报告汇总。执行完用例统计通过率、整理失败原因、汇总遗留风险规则简单但操作琐碎。传统做法也会做“提效”把用例模板做成 Excel把接口脚本放在 Git 仓库里复用把报告模板做成 Word 文档。但这些资产都是“等用户调用”的静态文件。如果你不记得有某个模板它就永远躺在那里如果你不手动执行脚本它就永远不会跑如果你不打开 Word 模板报告也不会自己生成。Skill 的解决思路完全不同它把“流程”本身交给 Agent。你输入需求或接口文档Agent 根据 Skill 里的说明文件自动判断当前属于哪个测试场景然后按设定步骤执行脚本、加工输出。也就是说以前是你“找工具”现在变成了“工具找你”。这里需要明确一个判断Skill 并不是要替代测试工程师的思考而是把已经成熟的测试规则固化成标准动作。真正需要判断力的场景比如业务风险的权衡、复杂缺陷的定位、测试策略的选择仍然由人来完成。Skill 最适合取代的是“方法明确但操作繁琐”的环节这类环节在测试流程中恰好占比很高。2. 什么是 SkillAgent Skill 与 MCP 的边界“Skill”这个词在测试圈出现频率还不高但在 AI Agent 领域已经是核心概念。简单说Skill 是一个结构化的能力包通常包含一个说明文件、若干脚本和参考资源。它的作用是教会 AI Agent 完成某一类具体任务。以测试场景为例一个“测试用例生成 Skill”可能包含以下内容一个 SKILL.md 说明文件写明这个 Skill 适用于什么场景、如何触发、执行步骤有哪些、输出格式是什么。一个 Python 脚本负责把需求文本解析成用例 JSON。一份参考文档记录团队常用的边界值规则、缺陷统计和命名规范。当 Agent 收到用户消息“帮我给登录功能生成测试用例”时它会检测到这条消息与某个 Skill 的 description 匹配于是读取该 Skill 的说明文件按说明中的步骤调用脚本、生成并格式化结果最终输出测试用例给用户。整个过程相当于给 Agent 装上了“测试领域的操作手册”。很多人会把 Skill 和 MCPModel Context Protocol混淆这两个概念确实相关但解决的问题不同。MCP 解决的是“连接”问题。它是一套标准协议让 AI Agent 能够调用外部工具、查询数据库、读写文件系统、访问第三方系统。你可以把 MCP Server 理解成一个标准化的 API 网关Agent 通过它拿到外部数据或操作外部系统。Skill 解决的是“方法”问题。它不直接连接外部系统而是教 Agent“遇到某类任务时应该按什么步骤做、用什么脚本、产出什么格式”。Skill 更像一份带工具的工作流程说明书。两者可以组合使用。一个接口自动化测试 Skill 可以定义测试流程和代码生成逻辑而流程中需要调用内网测试环境接口时则通过 MCP Server 完成调用。简单总结对比项SkillMCP核心目标固化任务流程与业务规则统一外部工具与数据连接存在形式目录中的说明文件、脚本、资源MCP Server 提供的工具接口是否需要网络服务一般不需要通常需要 Server 运行典型例子测试用例生成 Skill通过 MCP 查询缺陷库、操作测试环境与 Agent 的关系决定“怎么做”决定“能做什么”对测试团队来说这两个不是二选一的关系。比较自然的落地方式是先积累 Skill把团队最常用的测试流程固化下来当 Skill 中的脚本需要访问具体测试系统时再通过 MCP 打通。3. 环境准备与 Skill 基本结构写 Skill 并不需要特别复杂的工具链核心是准备一个支持 Skill 机制的 Agent 环境并安装必要的测试依赖。环境准备清单如下支持 Skills 机制的 Agent 客户端或编码助手命令行工具。目前多家主流 AI 编程工具都在引入类似能力建议查阅你所用工具的最新文档确认它通过skills目录还是SKILL.md文件加载技能。Python 3 解释器版本以当前项目实际环境为准。本文的脚本均基于 Python 开发不依赖特定 Python 小版本。测试相关 Python 库至少包含pytest、requests、Appium-Python-Client。安装命令如下pip install pytest requests Appium-Python-Client如果涉及 UI 自动化准备已安装 Appium Server 的机器或模拟器环境。建议使用 Git 对 Skill 目录进行版本管理。准备完成后先理解 Skill 的标准目录结构。这里给出一个测试用例生成 Skill 的示例skills/ └── test-case-generator/ ├── SKILL.md ├── scripts/ │ └── generate_test_cases.py └── references/ └── boundary_rules.md其中SKILL.md是这个 Skill 的入口文件承担两个职责一是让 Agent 知道自己适合处理什么任务二是告诉 Agent 处理任务的具体步骤。scripts目录存放可执行脚本references目录存放供 Agent 和用户参考的业务规则、模板和案例。一个最小可用的SKILL.md长这样--- name: test-case-generator description: 根据功能需求描述生成标准测试用例骨架。当用户提供需求描述并提到“生成测试用例”“写测试点”“整理用例”时使用。 --- # 测试用例生成 Skill ## 适用场景 - 需求文本已确认需要快速生成正向、反向、边界用例。 - 测试计划中需要结构化用例清单。 ## 使用步骤 1. 读取用户提供的需求描述。 2. 运行 python scripts/generate_test_cases.py --requirement 需求描述 --output test_cases.json。 3. 打开生成的 JSON逐条补充业务细节和测试数据。 4. 删除或降级明显不适用的用例按 P0/P1/P2 排序。开发 Skill 时有一个关键点description字段决定 Agent 是否会触发这个 Skill。如果 description 写得太窄Agent 可能识别不到写得太宽无关任务也会误命中。这个字段应该包含“任务场景词”和“用户常见说法”两部分。4. 测试用例生成 Skill从需求文本到结构化用例测试用例设计是测试流程中最适合第一个 Skill 化的环节因为规则相对固定正向用例覆盖主路径反向用例覆盖异常输入边界用例覆盖临界值。任何需求都可以先按这三类生成骨架再人工补足业务细节。先创建脚本目录和脚本文件# 文件路径skills/test-case-generator/scripts/generate_test_cases.py import argparse import json import re from datetime import datetime def parse_requirement(text: str) - dict: 从需求文本中提取模块名。这里是最简解析实际场景可以接入更细规则。 lines [line.strip() for line in text.splitlines() if line.strip()] module lines[0][:20] if lines else 未命名模块 return {module: module} def generate_case(prefix: str, case_type: str, module: str) - dict: if case_type positive: return { case_id: f{prefix}-01, module: module, type: 正例, title: 验证正常业务主路径, preconditions: 系统处于可测试状态已有对应业务数据, steps: [进入功能模块, 输入符合规则的合法数据, 点击提交], expected_result: 操作成功页面提示正确数据落库正确, priority: P0, } elif case_type negative: return { case_id: f{prefix}-02, module: module, type: 反例, title: 验证非法输入的拦截, preconditions: 系统处于可测试状态, steps: [进入功能模块, 输入为空或超长或格式非法, 点击提交], expected_result: 系统给出校验提示不能提交成功, priority: P1, } else: return { case_id: f{prefix}-03, module: module, type: 边界, title: 验证边界值场景, preconditions: 系统处于可测试状态, steps: [进入功能模块, 输入边界值附近数据, 点击提交], expected_result: 边界值按照需求规则被正确接受或拒绝, priority: P1, } def generate_cases(requirement_text: str): info parse_requirement(requirement_text) module info[module] cases [ generate_case(TC-001, positive, module), generate_case(TC-002, negative, module), generate_case(TC-003, boundary, module), ] return {module: module, generated_at: datetime.now().isoformat(), cases: cases} if __name__ __main__: parser argparse.ArgumentParser(description根据需求文本生成测试用例骨架) parser.add_argument(--requirement, requiredTrue, help需求描述文本或文件路径) parser.add_argument(--output, defaulttest_cases.json, help输出 JSON 文件路径) args parser.parse_args() if args.requirement.endswith(.txt) or args.requirement.endswith(.md): with open(args.requirement, r, encodingutf-8) as f: requirement_text f.read() else: requirement_text args.requirement result generate_cases(requirement_text) with open(args.output, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2) print(f生成完成{args.output}共 {len(result[cases])} 条用例)这个脚本的核心逻辑是按固定模板生成三类用例。真实项目中你可以把“需求规则描述”和“历史缺陷类型”作为参考文件放到references目录然后在脚本中解析这些规则生成和团队业务更贴近的用例。运行方式如下cd skills/test-case-generator python scripts/generate_test_cases.py --requirement 用户登录手机号验证码登录验证码有效期60秒 --output login_cases.json预期会得到一份包含正例、反例、边界用例的 JSON 文件。Agent 拿到这个 JSON 文件后会根据 SKILL.md 指示结合用户描述继续补全具体测试数据并将最终用例整理成 Markdown 表格或测试管理平台可导入的格式。这里真正容易踩坑的地方是不要指望脚本一次性生成可以直接执行的完整用例。脚本生成的是骨架业务正确性需要人工补充。因此 SKILL.md 中务必写清楚“生成后需要人工审核”这一步避免 Agent 把未经验证的用例直接作为最终输出。5. 接口自动化测试 Skill一键生成 pytest 脚本接口测试是自动化收益最明显的领域。接口文档已经明确了路径、方法、参数和返回结构人工写脚本的价值主要在于处理断言逻辑、参数组合和测试数据。但第一步“骨架脚本生成”完全可以交给 Skill 完成。设计一个接口测试 Skill核心流程是读取 OpenAPI 规范文件解析路径和参数生成 pytest 测试函数骨架。# 文件路径skills/api-test-generator/scripts/gen_api_tests.py import argparse import json from typing import List, Dict def parse_openapi(path: str) - List[Dict]: 简化版从 OpenAPI JSON 中抽取基础路径、路径和参数信息。 with open(path, encodingutf-8) as f: spec json.load(f) tests [] base_path spec.get(servers, [{}])[0].get(url, http://127.0.0.1:8080) for full_path, methods in spec.get(paths, {}).items(): for method, detail in methods.items(): if method not in (get, post, put, delete): continue parameters detail.get(parameters, []) query_params [p[name] for p in parameters if p.get(in) query] tests.append({ function_name: test_ full_path.strip(/).replace(/, _).replace(-, _) _ method, method: method.upper(), path: full_path, query_params: query_params, base_path: base_path, }) return tests def render_pytest(tests: List[Dict], output: str) - None: lines [ import requests, , BASE_URL \http://127.0.0.1:8080\, , ] for t in tests: params_def , .join(f{p} for p in t[query_params]) lines.append(fdef {t[function_name]}({params_def}):) lines.append(f resp requests.{t[method].lower()}() lines.append(f BASE_URL \{t[path]}\,) if t[query_params]: params_call , .join(t[query_params]) lines.append(f params{params_call},) lines.append( )) lines.append( assert resp.status_code in (200, 201)) lines.append() with open(output, w, encodingutf-8) as f: f.write(\n.join(lines)) print(f已生成 {len(tests)} 个接口测试函数{output}) if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--spec, requiredTrue, helpOpenAPI JSON 文件路径) parser.add_argument(--output, defaulttest_api.py) args parser.parse_args() tests parse_openapi(args.spec) render_pytest(tests, args.output)这一步的输出是test_api.py。它生成了每个接口的测试函数并为查询参数预留了空字符串默认值。用户拿到这个文件后用实际测试数据替换空参数再补充断言细节即可。运行方式cd skills/api-test-generator python scripts/gen_api_tests.py --spec openapi.json --output test_api.py pytest test_api.py -q这个 Skill 的价值体现在“接口文档更新后”的场景传统做法是打开旧脚本逐个修改请求路径和参数容易漏改Skill 的做法是重新读取最新 OpenAPI重新生成一份基础脚本测试人员只需关注增量变化。这个流程将机械劳动压缩到了秒级。需要注意的是生成的脚本只包含基础断言。真正的价值判断比如响应体结构校验、数据库状态校验、异常响应校验仍需测试人员补充或通过业务规则库沉淀到 Skill 中。6. UI 自动化测试 SkillAppium 元素定位提效UI 自动化最容易被低估的难点是元素定位。移动端 App 的页面层级结构经常变化元素 ID 不稳定导致测试脚本维护成本远高于编写成本。Skill 在这个场景的价值是把“定位元素”这个最耗时的环节前置处理。设计一个 Appium UI 辅助 Skill它提供两个能力一是导出当前页面层级结构二是基于页面结构给出可用的定位器。下面是导出页面层级并统计可定位元素的脚本# 文件路径skills/appium-ui-helper/scripts/dump_hierarchy.py import argparse from appium import webdriver from appium.webdriver.common.appiumby import AppiumBy def dump_hierarchy(platform_version, device_name, app_package, app_activity, server_urlhttp://127.0.0.1:4723): # 以 Android 为例iOS 同理可根据实际设备调整 capabilities caps { platformName: Android, appium:platformVersion: platform_version, appium:deviceName: device_name, appium:appPackage: app_package, appium:appActivity: app_activity, appium:automationName: UiAutomator2, appium:noReset: True, } driver webdriver.Remote(server_url, caps) try: page_source driver.page_source with open(page_dump.xml, w, encodingutf-8) as f: f.write(page_source) print(页面层级已导出到 page_dump.xml) elements driver.find_elements(AppiumBy.XPATH, //*[resource-id]) print(f检测到 {len(elements)} 个带 resource-id 的元素) finally: driver.quit() if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--platform-version) parser.add_argument(--device-name, requiredTrue) parser.add_argument(--app-package, requiredTrue) parser.add_argument(--app-activity, requiredTrue) parser.add_argument(--server-url, defaulthttp://127.0.0.1:4723) args parser.parse_args() dump_hierarchy(args.platform_version, args.device_name, args.app_package, args.app_activity, args.server_url)运行时先确认设备已连接adb devices python dump_hierarchy.py --device-name emulator-5554 --app-package com.example.app --app-activity .MainActivity脚本会输出一份page_dump.xml里面记录了当前页面的完整控件层级。测试人员或 Skill 中的分析逻辑可以基于这份 XML推荐最稳定的定位方式优先使用 resource-id其次使用文本内容最后再考虑坐标。这套规则可以沉淀到 Skill 的参考文档中让 Agent 在生成 UI 自动化脚本时自动遵循。这个 Skill 解决的核心问题是“元素找不到”。当一个用例失败时执行 dump 脚本对比新旧页面层级通常几秒钟就能看出是元素 ID 变了还是页面结构完全改了。相比直接改脚本里的定位器这种排查方式更有据可依。7. 运行结果与效果验证Skill 做出来后需要用最小场景验证流程是否走通。下面用一个完整的验证过程说明预期效果。第一步验证测试用例生成 Skillcd skills/test-case-generator python scripts/generate_test_cases.py --requirement 用户登录手机号验证码登录验证码有效期60秒 --output login_cases.json cat login_cases.json预期输出会是一个 JSON包含module、created_at和cases三个字段。cases中包含三条用例case_id 分别为 TC-001-01、TC-001-02、TC-001-03。看到三条用例且字段完整说明脚本运行成功。如果输出为空或报编码错误优先检查 Python 版本和输入文本是否为 UTF-8 编码。第二步验证接口测试 Skillcd skills/api-test-generator python scripts/gen_api_tests.py --spec openapi.json --output test_api.py pytest test_api.py -q预期输出中gen_api_tests.py会打印“已生成 N 个接口测试函数”pytest会显示每个测试用例的执行结果。如果 pytest 执行失败不要急着改脚本先检查test_api.py中生成的 BASE_URL 是否正确、测试环境是否可访问。第三步验证 Appium UI 辅助 Skilladb devices cd skills/appium-ui-helper python scripts/dump_hierarchy.py --device-name emulator-5554 --app-package com.example.app --app-activity .MainActivity预期输出为“页面层级已导出到 page_dump.xml”和“检测到 N 个带 resource-id 的元素”。如果报连接错误先确认 Appium Server 是否启动再检查设备是否授权。整个验证过程的核心判断标准是脚本能完整跑通Agent 可以根据 SKILL.md 的指引自动完成脚本调用。如果一个 Skill 需要人工反复干预才能运行说明流程设计还不够标准应该继续拆分任务或补充参考文档。8. 测试 Skill 常见问题与排查方法上手 Skill 时会遇到不少问题这里整理最典型的几种问题现象可能原因排查方式解决方案Agent 不触发 SkillSKILL.md 中的 description 写得模糊缺少触发场景词查看 Agent 日志确认是否加载了该 Skill 目录重写 description明确触发条件和用户常见说法生成的测试用例全是模板业务性差脚本只有固定模板没有结合业务规则库查看生成 JSON对比脚本输入输出把团队历史缺陷、业务边界规则写入 references 文件接口测试脚本 pytest 运行失败生成的 BASE_URL 与实际环境不一致或依赖未安装运行pytest --collect-only检查报错信息统一环境变量配置执行pip install pytest requestsAppium 连接失败设备未连接、Appium Server 未启动运行adb devices检查 Appium Server 日志重启设备连接使用appium-doctor检查环境同一个需求生成结果不稳定SKILL.md 中的步骤描述不够细化多次运行对比输出差异拆分更明确的步骤把输出格式、审核要求写进说明文件多个 Skill 同时命中不同 Skill 的 description 有重叠场景检查各 SKILL.md 的触发条件为 Skill 增加边界说明明确各自适用场景这些问题的共性原因是 Skill 的说明文件没有把“何时用、怎么用、输出什么”讲清楚。Agent 对 Skill 的依赖本质上是文档驱动。文档越精确行为越可控。9. 测试 Skill 最佳实践与工程建议从零开始搭建测试 Skill 合集时可以直接参考以下工程经验避免走弯路。第一SKILL.md 结构标准化。每个 Skill 至少包含五部分适用场景、使用步骤、输入要求、输出格式、人工审核点。这样 Agent 在加载时能快速理解任务边界同时也能提醒测试人员哪些环节需要人工介入。第二Skill 命名规范。目录名建议使用 kebab-case例如test-case-generator、api-test-generator、appium-ui-helper。脚本统一放在scripts目录规则文档统一放在references目录。命名和目录结构保持一致后续扩展时更容易维护。第三脚本入参与出参保持稳定。Skill 脚本的可复用性取决于入参设计。例如测试用例生成脚本--requirement是入参输出文件是--output指定的 JSON。当这些接口固定下来后即使脚本内部实现大改Agent 的调用方式也不需要变化。第四测试环境信息通过环境变量注入。Skill 脚本里不要写死测试环境地址、账号和密码。例如接口测试的 BASE_URL应该支持通过环境变量TEST_BASE_URL覆盖避免因为环境切换而修改脚本。第五Skill 纳入版本管理。Skill 本质上也是代码资产应当纳入 Git。每次修改 SKILL.md 或脚本都需要走代码评审流程。特别是涉及测试规则变更时要像修改业务代码一样留下变更记录。第六建立 Skill 效果评估维度。可以统计使用 Skill 后用例设计耗时、接口脚本生成耗时、UI 用例维护频率这些指标。不需要做复杂平台用表格记录前后对比即可发现某个 Skill 长期没有减少耗时就说明它没有真正解决痛点。第七渐进式落地。不要一开始就做“测试全流程平台”而是选择一个最痛的点先跑通。推荐从测试用例生成开始因为它规则最清晰、风险最低、业务方最容易接受。跑通后再扩展接口自动化和 UI 辅助。第八注意安全边界。Skill 内不要存放任何敏感信息尤其是数据库连接串、云厂商密钥、用户个人信息。涉及外部系统调用时按照最小权限原则申请权限并在测试环境验证不要在生产环境直接执行未经验证的 Skill 脚本。10. 总结测试全流程提效 Skill 的核心理念是把测试人员已经验证过的规则、流程和脚本打包成 Agent 可执行的能力包让重复劳动回归自动化让人回归判断。这篇文章从 Skill 的基本概念出发给出了测试用例生成、接口自动化、Appium 辅助三个 Skill 的完整实现思路并补充了运行验证、常见问题排查和工程最佳实践。如果你现在正被重复的测试用例设计和接口脚本维护困住最好的起步方式不是重构整个测试流程而是先做一个最小 Skill把团队最常用的测试用例模板固化成一个脚本用一条命令让 Agent 帮你生成用例骨架。跑通之后再往里面加业务规则、接口生成、UI 辅助。测试提效的本质不是让工具替你思考而是把已经确定的方法论沉淀下来让 AI 替你执行重复部分你只做判断。