1. 从“会用AI”到“用AI干活”我为什么攒下这25个测试Skill这两年AI Agent的概念被炒得火热但真正落到日常测试工作里能稳定跑、能省时间、能让我少加班的其实就那么一批固定套路。我把它们叫做“Skill”——不是那种花哨的插件市场里下载完就吃灰的东西而是我每天打开编辑器、终端、浏览器就会顺手调用的能力单元。说白了Skill就是一套被固化下来的提示词加工具链加执行逻辑你给它一个输入它给你一个可用的输出中间不需要你反复解释背景。我最初也是从零散地用AI写用例、生成测试数据开始的。那时候每次都要重新描述项目结构、接口规范、断言风格效率极低。后来我意识到测试工作里有大量重复的“认知模式”比如根据接口文档推导边界值、根据日志定位失败原因、根据页面元素生成稳定的定位器、根据历史缺陷归纳回归范围。这些模式一旦被抽象成固定的Skill就可以像函数一样被反复调用。我攒下的这25个Skill覆盖了从需求分析、用例设计、自动化脚本生成、执行调度、结果分析到缺陷归因的完整链路。这篇文章不是要给你一个“万能工具箱”而是想把我筛选、打磨、淘汰Skill的完整思路摊开讲。你会看到哪些Skill真正经得起项目考验哪些看起来很美但实际会拖后腿以及我是怎么把多个Skill串成一条自动化流水线的。如果你正在做AI测试开发、Agent架构设计或者只是想让日常测试少点手工活这些内容应该能直接抄作业。2. 需求解析与用例生成让AI先读懂“要测什么”2.1 从PRD到测试点的结构化拆解Skill很多人拿到需求文档第一反应是直接让AI“生成测试用例”结果出来的东西要么太泛要么漏掉关键分支。我用的第一个Skill叫需求切片器它的核心逻辑不是生成而是拆解。具体做法是把PRD按“用户角色-操作路径-数据流转-异常分支”四个维度切成小块每一块单独喂给AI要求它输出“可验证的测试点”而不是“测试用例”。这个区别很关键——测试点是“什么情况下会发生什么”测试用例是“具体怎么操作、预期什么结果”。先有测试点再展开用例覆盖率会高很多。这个Skill的提示词结构大概是这样的先给AI设定角色为“资深测试架构师”然后提供一段需求描述要求它按固定JSON格式输出字段包括场景ID、前置条件、触发动作、预期状态变化、涉及数据实体。我实测下来用JSON约束输出比自由文本的可用率高出一大截因为后续可以直接解析成表格导入测试管理平台。注意需求切片器最怕的是需求本身有歧义。如果PRD里出现“系统应快速响应”这种模糊表述Skill会直接标记为“不可验证项”提醒你去找产品确认。这个设计帮我挡掉了很多后期扯皮。2.2 边界值与等价类自动推导Skill边界值分析是测试设计的基本功但手工推导容易漏。我用的第二个Skill专门干这个输入一个参数的定义域比如“年龄整数1-120”它自动输出边界值集合和等价类划分。这个Skill背后其实是一套规则引擎加AI补全——规则引擎负责数学上严谨的边界min-1, min, min1, max-1, max, max1AI负责补充业务语义上的特殊值比如年龄为0、负数、超大整数、非数字字符。我把它和接口测试框架pytest结合使用效果很直接以前写一个接口的边界用例要十分钟现在Skill输出后我复制粘贴改改断言两分钟搞定。而且它输出的格式可以直接转成pytest的pytest.mark.parametrize装饰器参数省去了手工整理测试数据的步骤。2.3 基于历史缺陷的回归范围推荐Skill这个Skill是我个人觉得最值钱的一个。它的输入是当前版本的代码变更列表比如Git diff摘要加上历史缺陷库输出是“本次变更最可能影响的测试范围”。原理不复杂把代码变更涉及的文件路径、函数名、接口路径提取出来和历史缺陷记录里的“缺陷位置”做相似度匹配再结合缺陷的严重程度和复发次数加权排序。我试过在一个迭代里代码改了支付模块的三个文件这个Skill推荐了12个回归测试点其中8个是历史上有过支付相关缺陷的。实际执行下来确实抓到了一个之前修过又复现的边界问题。如果没有这个Skill我可能只会跑一遍主流程那个边界问题就漏了。3. 自动化脚本生成从“能跑”到“跑得稳”的Skill组合3.1 页面元素定位器智能生成Skill做UI自动化最头疼的就是定位器不稳定。我用的Skill叫定位器优选器输入是页面DOM片段或截图输出是推荐的定位策略。它的逻辑是优先用>tasks: - skill: 需求切片器 input: ./requirements/sprint-23.md - skill: 边界值推导 input: ./api-specs/payment.yaml - skill: 接口脚本生成 input: ./api-specs/payment.yaml - skill: 执行pytest input: ./generated_tests/ - skill: 结果分析 input: ./test-results/这个编排器本身不复杂但它是把零散Skill变成流水线的关键。我一般用cron或CI的定时任务触发它早上到公司直接看结果报告。4.2 多AI协作的冲突消解Skill当多个Agent同时操作同一套测试环境时冲突是难免的。比如两个Skill同时往测试数据库写数据可能互相干扰。我用的冲突消解Skill基于简单的锁机制每个Skill在执行前先申请一个资源锁比如“数据库写锁”拿到锁才能执行执行完释放。如果申请超时就排队等待或跳过。这个Skill看起来不起眼但在多AI协作场景下是刚需。我试过没有锁的时候两个Agent同时跑接口测试结果一个把另一个的数据删了排查了半天才发现是并发问题。加上锁之后再没出现过这类诡异失败。4.3 执行失败自动重试与降级Skill自动化测试最怕“假失败”——网络抖动、环境不稳定导致的偶发失败。我用的重试Skill会分析失败原因如果是超时或连接错误自动重试最多三次如果是断言失败不重试直接标记为真实缺陷。降级策略是如果某个Skill连续失败超过阈值自动切换到备用方案比如用录制的mock数据代替真实接口。这个Skill帮我过滤掉了大概30%的噪音失败让真正需要关注的缺陷更突出。5. 结果分析与缺陷归因AI怎么帮我“看懂”失败5.1 日志智能摘要Skill测试跑完一堆日志人工翻看效率极低。我用的日志摘要Skill输入原始日志文件输出结构化的失败摘要失败用例列表、每个失败的异常类型、堆栈关键行、可能的根因分类环境问题、数据问题、代码缺陷、脚本问题。它用正则提取关键信息再用AI做分类和归因。我实测下来这个Skill对“环境问题”和“脚本问题”的识别准确率很高基本能帮我快速排除掉非代码缺陷的失败。对于真正的代码缺陷它会给出“疑似涉及模块”和“建议排查方向”虽然不能完全替代人工分析但能大幅缩短定位时间。5.2 缺陷报告自动生成Skill发现缺陷后写报告也是个体力活。我用的缺陷报告Skill输入失败用例的执行记录、日志摘要、截图如果有输出一份格式规范的缺陷报告草稿包括标题、严重程度建议、复现步骤、实际结果、预期结果、附件链接。我只需要审核和补充业务背景就能直接提交到缺陷管理系统。这个Skill的提示词里我特意加了一条“如果复现步骤超过7步尝试合并为更简洁的路径”。因为很多自动化失败是因为步骤太细碎导致的合并后往往能发现更本质的问题。5.3 测试覆盖率缺口分析Skill最后这个Skill叫覆盖率缺口分析器输入是代码覆盖率报告和需求测试点列表输出是“哪些需求点没有被任何测试覆盖”以及“哪些代码分支没有被执行到”。它把需求测试点和代码覆盖率数据做交叉比对找出盲区。我一般在一个迭代结束前跑一次这个Skill确保没有重大遗漏。有一次它发现“退款流程”的需求测试点里有一个“部分退款”的分支完全没有对应用例而代码覆盖率显示那个分支确实没被执行过。补上用例后果然抓到了一个金额计算错误。6. 我踩过的坑和最后几条实在建议Skill攒多了坑也踩了不少。最早的时候我追求“大而全”一个Skill恨不得覆盖所有场景结果提示词越写越长AI反而容易跑偏。后来我学乖了一个Skill只干一件事输入输出格式固定宁可多拆几个也不要糅在一起。比如“生成测试数据”和“清理测试数据”就是两个独立Skill虽然经常一起用但拆开后各自更稳定。另一个坑是过度依赖AI的判断。有段时间我让Skill自动决定哪些失败需要重试结果它把一些真实的断言失败也重试了浪费了执行时间还掩盖了问题。后来我改成重试策略必须基于明确的错误类型白名单比如只对TimeoutError和ConnectionError重试其他一律不重试。这个规则写死在Skill里不让AI自由发挥。还有一点关于多AI协作的体会锁的粒度要细但申请锁的顺序要固定。我试过两个Skill互相等待对方释放锁直接死锁。后来规定所有Skill必须按“数据库锁→文件锁→网络锁”的固定顺序申请问题就解决了。这个经验在Agent架构设计里应该也通用。最后说个最实在的别为了用AI而用AI。有些测试任务比如简单的冒烟测试写个固定脚本跑就完了硬套Skill反而增加复杂度。我现在的原则是如果一个任务我手工做超过三次且每次逻辑基本一致才考虑做成Skill。这样攒下来的25个每一个都是真正被日常高频使用的没有一个是摆设。