1. 从“测试”这件事说起为什么我开始攒 AI 测试 Skill做测试这行十来年我经历过纯手工点页面的年代也经历过 Selenium 脚本满天飞的年代再到后来接口自动化、性能压测、安全扫描各成体系。但真正让我觉得“工作方式被改写”的是最近一两年把 AI 拉进测试流程之后。标题里说的“AI 测试 Skill 大全我日常在用的 25 个”不是什么官方清单而是我自己在项目里反复用、反复改、最后沉淀下来的一套东西。所谓 Skill你可以理解成给 AI 助手预设好的“角色 指令 上下文 输出格式”的组合包它让 AI 从一个什么都聊两句的通用助手变成一个懂测试、懂你项目、能直接产出可用结果的专用工具。这篇文章适合谁看如果你是被重复用例、重复报告、重复排查折磨的测试工程师如果你是带团队、想让 AI 真正落地而不是停留在“帮我写个用例”的测试负责人如果你是刚接触 Agent、Claude 这类工具、想知道别人到底怎么用的新手那这篇内容应该能给你省下不少自己摸索的时间。我不会只列名字而是把每一类 Skill 背后的设计逻辑、关键参数、实操步骤、踩过的坑都摊开讲。25 个 Skill 我会按功能分组但重点不是数量而是让你看完能自己造出第 26 个、第 27 个。先说清楚一个前提Skill 不是插件也不是某个平台的专属功能。它本质是一段结构化的提示词工程产物配合 Agent 的工具调用能力读文件、跑命令、查接口、写报告才能发挥威力。所以你在 Claude、在支持 Agent 的 IDE、在自建的 Agent 框架里都能用同一套思路。我下面讲的所有内容都围绕“怎么设计、怎么用、怎么避坑”展开不绑定任何特定平台。2. 测试 Skill 的整体设计思路先想清楚 AI 该干什么2.1 为什么不是“一个万能提示词”打天下刚开始我也偷懒写了一个巨长的提示词想让 AI 同时干用例生成、缺陷分析、报告汇总。结果就是它每件事都干得马马虎虎生成的用例边界条件不全缺陷分析抓不住根因报告写得像流水账。后来我想明白了这跟带新人一样——你不可能让一个新人同时负责功能测试、性能测试、安全测试还都做到位。Skill 的价值就在于“专事专办”一个 Skill 只解决一类问题输入输出边界清晰AI 的注意力才不会被稀释。我现在的做法是按测试活动的阶段来切分 Skill。需求阶段有需求解析和测试点提取设计阶段有用例生成和用例评审执行阶段有脚本生成、数据构造、日志分析收尾阶段有缺陷归因和报告生成。每个 Skill 独立可测组合起来就是一条完整的 AI 辅助测试流水线。这样做还有个好处某个 Skill 效果不好我单独调它就行不会牵一发动全身。2.2 Skill 的三层结构角色、约束、输出我攒下来的 25 个 Skill拆开看都是同一个骨架我管它叫“三层结构”。第一层是角色设定告诉 AI“你是谁”比如“你是一名有五年经验的接口测试工程师熟悉 RESTful 规范和常见鉴权方式”。第二层是约束条件这是最关键的包括输入格式、必须遵守的规则、禁止做的事情比如“只基于我提供的接口文档生成用例不要臆造字段”“每条用例必须包含前置条件、步骤、预期结果”。第三层是输出格式明确要求用表格、用 JSON、用 Markdown甚至规定字段名。很多人写 Skill 效果差问题基本都出在第二层太弱。AI 天生喜欢“发挥”你不约束它它就给你编。我踩过最典型的一个坑让它根据需求文档生成测试点它把文档里没写的业务规则也“合理推断”进去了结果评审时被产品经理当场指出错误。从那以后我每个 Skill 里都会加一句“信息不足时明确标注‘待确认’禁止自行补充”。2.3 参数化让一个 Skill 适配多个项目Skill 如果写死了项目名、接口地址、字段名那换个项目就得重写太累。我的做法是把可变部分抽成参数用占位符表示比如{{project_name}}、{{api_base}}、{{auth_type}}。调用的时候把参数填进去一个 Skill 就能服务多个项目。这跟写代码抽公共函数是一个道理。下面这张表是我对 Skill 参数化程度的一个分类你可以对照自己的情况看看该做到哪一档。参数化程度特征适用场景维护成本无参数提示词写死项目信息一次性任务、临时验证极低但复用性差轻量参数只抽项目名、环境地址同类型项目快速复用低中度参数抽接口规范、字段映射、鉴权方式团队内多项目共用中高度参数抽业务规则、数据模板、断言策略平台化、跨团队推广高需配套文档我大部分 Skill 停在中度参数化因为再往上维护成本就超过收益了。这个度怎么把握后面讲具体 Skill 的时候我会结合例子说。3. 需求与设计阶段把测试左移落到实处3.1 需求解析 Skill从一段话里挖出可测点产品经理丢过来一段需求描述往往夹杂着业务背景、交互细节和一堆“等等”。人读都要读两遍更别说直接生成用例了。我用的第一个 Skill 就是需求解析它的任务是把非结构化的需求文本拆成结构化的测试点清单。提示词的核心指令是“逐句分析需求识别其中的功能点、业务规则、边界条件、异常场景输出为表格每行包含测试点编号、所属模块、测试点描述、优先级、来源句子”。这里有个关键技巧要求 AI 标注“来源句子”。这样评审的时候任何一个测试点都能追溯到需求原文避免它自己加戏。实测下来这个 Skill 能把需求评审的准备时间压缩一半以上因为测试点清单直接就是评审材料。但要注意AI 对隐含规则的识别能力有限比如“金额不能为负”这种没写出来的常识它有时会漏。所以我的习惯是把它当“第一遍粗筛”人工再过一遍补漏。3.2 用例生成 Skill边界值和等价类怎么交给 AI用例生成是大家最熟悉的场景但也是最容易做砸的。我见过太多人直接说“帮我写登录功能的测试用例”结果 AI 给了一堆“输入正确用户名密码”“输入错误密码”这种没营养的。我的用例生成 Skill 里强制要求 AI 按等价类划分和边界值分析来组织提示词里明确列出“对每个输入字段分别给出有效等价类、无效等价类、上边界、下边界、边界外并说明取值依据”。举个实际例子一个“年龄”字段要求 18 到 60 岁。AI 按我的 Skill 会输出有效等价类取 30无效等价类取 10 和 70上边界取 60、61下边界取 18、17。这样一套下来覆盖度比随手写的高得多。我还会在 Skill 里加一条“每条用例必须可独立执行不依赖其他用例的执行结果”这是为了保证用例能直接进自动化框架。3.3 用例评审 Skill让 AI 当那个“挑刺的人”用例写完评审环节最费人。我做了个用例评审 Skill角色设定是“一名挑剔的资深测试专家”任务是找出用例里的问题。指令包括“检查是否存在重复用例、是否遗漏异常场景、预期结果是否可验证、前置条件是否完整、步骤是否可执行”。输出要求按严重程度分级并给出修改建议。这个 Skill 有意思的地方在于我故意把它的“性格”设得严格一点提示词里写“宁可误报不可漏报”。因为评审阶段多挑出问题比上线后才发现强。实测它能抓出大概七成的用例质量问题剩下三成靠人工。有个小技巧把用例和对应的需求一起喂给它它判断“是否遗漏”会准很多因为有了对照基准。4. 执行阶段脚本、数据、日志三件套4.1 接口脚本生成 Skill从文档到可跑代码接口测试脚本的生成是我用得最频繁的 Skill 之一。输入是接口文档Swagger 或手写 Markdown 都行输出是可直接运行的测试脚本。我的提示词里会指定语言和框架比如“用 Python requests pytest 生成使用参数化断言覆盖状态码、响应字段类型、关键业务字段值”。为什么要指定这么细因为不指定的话AI 可能给你生成一堆风格不统一的代码后期维护很痛苦。这里有个参数计算的实际例子。假设接口返回的金额字段是浮点数直接断言相等会有精度问题。我在 Skill 里加了一条规则“涉及金额、比率等浮点字段断言时使用误差范围默认容差 0.01”。这条规则是我被线上误报坑过之后加的——有次因为浮点精度导致断言失败排查了半天才发现是 0.10.2 不等于 0.3 这种经典问题。AI 默认不会考虑这个必须你告诉它。4.2 测试数据构造 Skill造出“像真的”的数据测试数据难造尤其是涉及关联关系的数据。比如造一个订单得先有用户、有商品、有库存。我做了个数据构造 Skill核心指令是“根据表结构或接口定义生成符合业务规则的测试数据保持外键关联一致性覆盖正常值、边界值、特殊字符”。输出格式我要求用 SQL 或 JSON方便直接导入。这个 Skill 有个进阶用法让它生成“脏数据”。提示词里加一句“额外生成 10% 的异常数据包括超长字符串、特殊字符、空值、类型不匹配”用来测试系统的容错能力。实测下来这些脏数据经常能挖出一些隐藏的边界 bug。但要注意脏数据只能往测试环境灌千万别手滑导到生产库这个我在 Skill 里专门加了警告语。4.3 日志分析 Skill从海量日志里定位异常跑完测试日志一大堆人工翻太慢。日志分析 Skill 的任务是输入一段日志输出异常摘要、可能的根因、相关代码位置建议。提示词里我会定义“异常”的判定标准比如“包含 ERROR、Exception、超时、连接拒绝等关键词的行以及响应时间超过阈值的行”。输出要求按时间线排列并标注出现频次。这个 Skill 的准确度取决于日志格式的规范性。如果日志是结构化的 JSONAI 分析起来很准如果是乱七八糟的文本效果就打折。所以我在 Skill 里加了一步“先判断日志格式非结构化时先做格式归一化”。另外涉及敏感信息的日志比如用户手机号、身份证号我会在 Skill 里要求 AI 自动脱敏后再输出这是合规底线。5. 缺陷与报告让 AI 干“整理”的活5.1 缺陷归因 Skill从现象到根因的推理发现一个 bug现象是“提交订单偶尔失败”。光看现象没法修得归因。缺陷归因 Skill 的角色是“一名擅长排查问题的测试开发工程师”输入是现象描述、相关日志、最近变更记录输出是可能的原因列表按可能性排序并给出验证方法。提示词里我要求它“区分前端问题、后端问题、数据问题、环境问题”这样排查方向更清晰。我踩过的一个坑是早期我让它直接给结论结果它经常“自信地猜错”。后来我改成要求它“给出至少三个可能原因并说明每个原因的验证步骤”这样即使第一个猜错也能顺着验证步骤往下排。这个思路其实来自我自己的排查习惯——先列假设再逐个验证而不是一上来就下结论。5.2 测试报告生成 Skill把零散结果串成一份能看的报告测试做完报告得写。我做的报告生成 Skill输入是测试执行结果通过率、失败用例、缺陷列表输出是结构化的测试报告包含测试范围、执行概况、缺陷统计、风险提示、结论建议。提示词里我规定了报告的语气“客观陈述不夸大通过率对未覆盖部分明确说明”。这里有个细节我要求 AI 在报告里区分“阻塞性缺陷”和“一般缺陷”并给出上线建议。这个判断标准我会在 Skill 里写清楚比如“阻塞性缺陷指导致核心流程不可用的问题”。这样生成的报告直接就能发给项目组省了我大量排版和措辞的时间。但结论部分我坚持人工确认因为上线决策不能全交给 AI。6. 进阶玩法Agent 化与多 Skill 协作6.1 从单 Skill 到 Agent让 AI 自己决定用哪个 Skill单个 Skill 是工具Agent 是会用工具的人。当我把上面这些 Skill 都准备好之后就开始尝试让 Agent 根据任务自动选择 Skill。比如我丢给它一句“帮我测一下这个新接口”它能自己判断先调接口脚本生成 Skill再调数据构造 Skill跑完之后调日志分析 Skill最后调报告生成 Skill。这套流程跑通之后效率提升是数量级的。但 Agent 化有个前提每个 Skill 的输入输出必须标准化。如果 A Skill 的输出格式和 B Skill 的输入格式对不上Agent 就串不起来。所以我在设计每个 Skill 时都会预留“标准输出”格式通常是 JSON字段名统一。这跟微服务之间定接口是一个道理先定契约再谈协作。6.2 多 AI 协作不同模型干不同活我现在的做法是不同 Skill 可以指定不同的模型。比如需要强推理的缺陷归因用推理能力强的模型需要快速生成大量用例的用速度快的模型。这样既保证效果又控制成本。多 AI 协作的关键是“任务分发”和“结果汇总”我会用一个调度 Skill 来协调它负责把任务拆解、分发给对应的 AI、收集结果、合并输出。这里要提醒一句多 AI 协作会放大错误。如果第一个环节的 AI 输出有偏差后面每个环节都会跟着偏。所以我在关键节点都加了“人工确认”开关比如用例生成后、脚本生成后先人工扫一眼再往下走。全自动听起来很美但测试这行完全放手风险太大。6.3 Skill 的版本管理与迭代Skill 是要迭代的。我每个 Skill 都像代码一样有版本号改动记录写清楚“改了什么、为什么改、效果如何”。比如我的用例生成 Skill 从 v1 到 v5v1 是基础版v2 加了边界值要求v3 加了来源标注v4 加了浮点容差v5 加了“禁止臆造字段”。每次迭代都是被实际问题逼出来的。我建议你也养成记录的习惯。不用多复杂一个表格就行Skill 名称、版本、改动点、触发原因、效果对比。时间长了你会发现这些记录本身就是一份宝贵的经验库比任何教程都实用。7. 常见问题与排查技巧实录7.1 Skill 效果不稳定的排查思路用 AI 做测试最头疼的就是“时好时坏”。同一个 Skill昨天生成的用例挺好今天就不行了。我总结了几条排查思路。第一检查输入是否一致很多时候是输入的需求文档格式变了AI 的理解就跟着变。第二检查提示词有没有被无意改动尤其是团队共用的时候。第三检查模型版本有没有更新模型升级有时会改变输出风格。第四检查上下文长度输入太长时 AI 会“遗忘”前面的指令。下面这张表是我整理的常见问题速查表你可以直接拿去用。问题现象可能原因排查方法解决建议输出格式不对提示词输出约束不明确检查输出格式描述用示例明确格式内容臆造约束条件太弱检查是否有“禁止补充”规则加“信息不足标注待确认”效果时好时坏输入不一致或模型变动对比历史输入和模型版本固定输入模板锁定模型版本长输入被截断上下文超限检查输入长度分段处理或先做摘要专业术语用错角色设定不清晰检查角色描述补充领域背景和术语表7.2 避坑经验这些错我替你犯过了第一个坑把敏感数据喂给 AI。早期我图省事直接把生产环境的日志丢进去分析后来意识到里面有用户信息赶紧停了。现在我的做法是所有输入先脱敏或者只用测试环境数据。这是红线不能碰。第二个坑过度依赖 AI 的结论。有次 AI 分析缺陷给了一个看起来很合理的根因我直接信了结果方向完全错浪费了一天。从那以后我要求 AI 必须给“验证步骤”我自己跑一遍才认。第三个坑Skill 写得太复杂。一开始我想把所有功能塞进一个 Skill结果它什么都干不好。后来拆成小 Skill每个只干一件事效果反而好。这跟写函数一样单一职责原则。第四个坑不记录不迭代。用了几个月发现自己一直在重复调同样的参数。后来开始记录才发现有些问题早就解决过只是忘了。7.3 安全与合规的边界用 AI 做测试有几个边界必须守住。第一不把生产数据、用户隐私数据作为输入。第二生成的脚本和用例上线前必须人工审核尤其是涉及删除、修改操作的。第三AI 给出的安全测试建议只用于授权范围内的测试不能用于未授权的目标。第四Skill 里涉及权限、鉴权的部分要确保符合团队的规范。这些不是技术问题是职业操守问题我在每个 Skill 里都会写上相应的约束。8. 我日常在用的 25 个 Skill 清单与分类前面讲了思路和方法这里把 25 个 Skill 按类别列出来每个附一句核心用途方便你对照自己的需求取用。需要说明的是具体提示词内容因项目而异我这里给的是“这个 Skill 解决什么问题”你可以据此自己填充细节。需求与设计类6 个需求解析、测试点提取、用例生成、用例评审、测试策略建议、风险评估。执行类8 个接口脚本生成、UI 脚本生成、测试数据构造、脏数据生成、环境检查、日志分析、性能脚本生成、安全扫描辅助。缺陷与报告类5 个缺陷归因、缺陷去重、回归范围建议、测试报告生成、质量度量分析。协作与调度类3 个任务分发、结果汇总、Skill 版本管理。辅助类3 个术语解释、文档摘要、会议纪要整理。这 25 个不是固定的项目不同会增减。比如做汽车电子测试的同事会额外加“信号仿真”和“诊断协议解析”两个 Skill做 GIS 空间分析的会加“坐标校验”和“图层比对”。核心思路是一样的把你重复做的、有固定套路的工作抽成一个 Skill。9. 最后分享几个实操小技巧技巧一给 Skill 起个好记的名字。我早期用“skill_001”这种编号后来发现根本记不住。改成“用例生成-接口版”“日志分析-通用版”这种一眼就知道干什么。技巧二在 Skill 里加“示例”。AI 对示例的敏感度远高于抽象描述。与其写“输出要规范”不如直接给一个规范输出的例子。我每个 Skill 里都至少放一个输入输出示例效果立竿见影。技巧三定期做“Skill 体检”。每隔一段时间把不用的 Skill 归档把常用的 Skill 优化。我现在的 25 个其实是从四十多个里筛出来的淘汰的那些要么效果不好要么场景太窄。技巧四别追求一步到位。我第一个 Skill 很粗糙但先用起来在用的过程中发现问题、迭代改进。等你想完美了再动手黄花菜都凉了。测试这行快速试错比完美规划重要。技巧五把 Skill 分享给团队。一个人攒不如一群人攒。我们团队现在有个共享的 Skill 库谁发现好用的就贡献进去标注适用场景和注意事项。这样新同事上手快老同事也能捡到别人的经验。当然涉及项目敏感信息的 Skill 要单独管理不能混进公共库。这套东西我用了大半年最大的感受是AI 不会取代测试工程师但会用 AI 的测试工程师确实能把不会用的甩开一截。关键不在于你用了多少个 Skill而在于你有没有想清楚每个 Skill 背后的逻辑有没有在实际项目里反复打磨。工具是死的人是活的把 AI 当成一个需要你带、需要你教的新人你的测试工作会轻松很多。