直接说结论我把测试用例编写从人工30分钟压到了skill自动生成30秒效率提升60倍不是噱头是切切实实的产出。这背后靠的不是模板堆砌而是一个设计良好的skill脚本它把“让AI听懂需求、按规范产出、直接可落库”这三件事一次性解决了。这篇文章把我从0到1打磨这个skill的全过程拆开讲包括踩过的坑和最终稳定运行的配置适合正在用AI编程助手比如Codex、Claude Code这类支持skill机制的工具做测试、又对产出质量有要求的同学参考。先说清楚一个概念skill不是什么玄学它本质上是给AI助手定制的一套“可复用指令包”。你可以把它理解成一个特级厨师的操作手册——普通人照着菜谱做菜和厨师拿着自己的秘方做菜差别就在于秘方里包含了火候、调料比例、摆盘顺序这些细节。skill就是把你平时需要反复强调、反复纠错的那套测试用例写作规范固化成一个AI能直接调用的标准流程。当你告诉助手“用测试用例skill处理这个需求”时它不再是从零发挥而是按照你预先定义好的角色、步骤、格式约束一口气生成结构完整、命名规范、可直接导入测试管理平台的用例。我最早开始折腾这个是因为我们团队有个绕不过去的痛点每个迭代要出的功能测试用例数量多、重复性强但手工写起来特别耗时间。一个中等复杂度的登录模块光正常流程、异常流程、边界值、权限校验这些场景列下来一小时就没了。而且不同人写的用例风格还不一样有的人喜欢写详细步骤有的人一句话带过评审的时候光统一格式就要花半天。我当时就想AI既然能写代码为什么不能按照我们的规范写用例于是开始研究skill机制试了大概两周把初版脚本稳定下来。现在团队里新来的同学拿到需求后跑一下skill30秒就能得到一份可以直接丢进禅道的用例初稿再花十几分钟人工补几个极端场景这个迭代的测试用例就齐了。这个方案的巧妙之处在于它不是让AI替你做测试决策而是让AI帮你把决策之后那些机械性的、耗时的写作工作消化掉。人的精力应该花在判断“这个功能要不要测”“风险点在哪”而不是花在敲“输入正确的用户名和密码点击登录按钮验证跳转是否正确”这种流程性文字上。下面我把整个设计和实现过程详细拆开从需求拆解、prompt设计、脚本实现到实际运行效果和问题排查一步一步讲清楚。1. 方案设计为什么是skill而不是直接让AI写用例1.1 直接对话式生成用例的问题如果你用过ChatGPT或者Claude直接生成测试用例应该有过这种体验第一版看起来像模像样但仔细一看用例编号没有、优先级乱标、前置条件缺失、操作步骤和预期结果混在一起更别提格式和你们团队模板对不上。你没办法直接拿去用还得花时间在对话里反复追加要求“步骤再详细一点”“预期结果单独列”“加上优先级字段”。生成一次要几分钟来回纠错又是十几分钟算下来效率还不如自己写。为什么会这样因为通用对话式AI没有“上下文约束”意识。它默认给你输出一个“合理的测试用例”而不是“符合你团队规范的测试用例”。这里的差异非常大。正常流、异常流这些它懂但你们项目的模块划分、用例编号规则、优先级定义、操作步骤的粒度这些信息你不说它就不会用。而你不说它只能靠猜。那为什么不每次都在对话里把这些要求写全理论上可以但实际做不到。一次两次还行天天写、每个需求都写那是给自己找麻烦。而且prompt越长越容易触发模型注意力漂移写到后面前面的约束它对不上了输出质量反而不稳定。这正是skill机制的价值所在把约定固化下来让AI每次调用时都处于同一个稳定上下文里。1.2 skill能带来的本质变化是什么我记得有一位工程师说过一句话印象很深skill的本质是让AI拥有项目级的“肌肉记忆”。它不是一次性的系统提示词而是可以被反复调用的、带固定流程和校验逻辑的能力模块。把这个概念落到测试用例场景具体来看有几个核心价值规范性可预期同样的输入调十次输出格式基本一致字段顺序、命名风格、用例粒度都是固定的。领域知识注入可以让skill内置你们项目的特定规则比如哪些字段必填、优先级如何判定、跨模块依赖如何处理。人工干预前置skill运行前可以先确认需求范围运行中可以自动拆解场景运行后还能自动做基础的完整性校验。可复用和可演进skill脚本是文本文件修改成本极低团队内部可以共享每迭代一次全团队的用例产出质量都跟着提升。我对比过三种方案纯对话生成、本地写一个脚本調API、用skill机制。最后选择了skill原因很简单纯对话生成的不稳定性太高每次都要重新调教本地脚本灵活性不够它没法理解自然语言描述的需求并转换成结构化的测试场景——这恰恰是LLM最擅长的事情。skill就处在两者中间的甜点区既有脚本的可复用性和可确定性又有AI的自然语言理解能力和生成能力。1.3 确定测试用例生成的流程框架在设计skill之前我先梳理了一个标准的测试用例生成流程。这个流程不是凭空想的而是从我们团队日常手写用例的习惯里总结出来的。手写用例时默认的逻辑链是理解需求文档或口头描述明确被测功能是什么。拆解业务规则列出正常流程、异常流程、边界值、权限、数据关联等维度。把每个维度转化成可执行的测试步骤。为每个步骤定义前置条件、输入数据、预期结果。补充优先级、用例类型、所属模块等元信息。这个流程看起来简单但手工执行时每一个环节都需要停下来思考真正耗时的不是“写”而是“想”。而skill要做的事情就是把这个“想”的过程也标准化——通过引导prompt让AI在生成用例之前先把需求拆解成测试点再基于测试点展开用例。分两步走比一口气生成用例要稳得多。我第一次测试时直接让AI一次生成30条用例结果里面有十几条是重复场景或无效场景。改成先列测试点、再生成用例的结构之后质量提升非常明显。这个设计思路建议所有想自己做skill的人都参考你的skill里一定要有一个“中间产物环节”比如先让AI输出它的理解、它的拆解思路再基于这个拆解去生成最终结果。这既是质量保障也是给使用者一个检查点——如果拆解错了你在这一步就能发现而不是等30条用例生成完了再返工。2. skill脚本开发目录结构、prompt模板和核心参数2.1 skill的标准目录与配置文件以目前主流的AI编程助手为例一个skill通常就是一个文件夹里面有SKILL.md或者skill.md具体取决于工具约定和一些可选的脚本资源。目录结构大致是skill-name/ ├── SKILL.md └── assets/ └── templates/ └── test_case_template.mdSKILL.md是skill的核心描述文件这里面写清楚这个skill的触发场景、工作流程、输出格式要求。很多刚接触的人容易犯一个错误把SKILL.md当成一个简单的“prompt文档”随便写几句就完事。实际上SKILL.md的设计质量决定了整个skill的可用性。它至少要包含三个层次的信息第一层触发条件。告诉AI什么情况下应该使用这个skill比如“当用户要求生成测试用例、测试点、测试计划时”。第二层工作流程。明确拆成几步每一步要做什么、输出什么。第三层输出约束。字段格式、命名规则、优先级标准、异常处理方式。我见过一些人把不相关的功能也塞进同一个skill比如既生成用例又生成测试报告还顺带生成自动化脚本。这种行为会导致AI在调用时犹豫不决不知道当前任务应该侧重哪部分输出结果往往是四不像。我知道把多个功能塞进一个skill很诱人因为能少建几个目录但从实际效果看单一职责的skill才是最好用的。一个skill只做一件事自然语言指令清晰、输出结构稳定、调试也方便。2.2 SKILL.md的编写实例可直接复制的模板下面这份是我当前稳定在用的SKILL.md核心内容删掉了项目相关的敏感信息保留了完整框架你直接可以参考改造--- name: test-case-generator description: 根据需求描述生成结构完整的功能测试用例。适用于功能测试、接口测试、回归测试场景。输入可以是需求文档、功能描述或用户故事。 --- # 测试用例生成skill ## 触发条件 当用户要求生成或补全测试用例、测试点、测试计划时使用本skill。 ## 工作流程 ### 第一步理解需求 - 向用户确认被测功能名称、需求背景、相关业务规则。 - 如果用户描述不完整列出你认为缺失的关键信息请用户补充。 ### 第二步拆解测试点 - 从以下维度拆解测试点正常流程、异常流程、边界值、数据依赖、状态流转、权限控制、兼容性、性能如适用。 - 每个维度至少输出1个测试点。 - 按列表形式输出测试点等用户确认后再进入下一步。 ### 第三步生成测试用例 - 每个测试点至少生成1条测试用例复杂场景可拆成多条。 - 使用供应商提供的工件生成器生产信息中的模板格式。 - 用例编号规则模块名_功能名_序号例如login_001。 ### 第四步自检与修正 - 检查用例中是否存在重复场景。 - 检查预期结果是否清晰可验证。 - 检查是否遗漏边界值或异常条件。 - 如有问题在输出前自动修正。 ## 输出格式要求 - 必须包含字段用例编号、所属模块、用例标题、前置条件、测试数据、测试步骤、预期结果、优先级、用例类型。 - 测试步骤必须分步编号每步一个操作。 - 预期结果必须与测试步骤一一对应。 - 优先级标准P0为阻塞性问题必须有P1为核心功能必须有P2为一般功能尽量有P3为边缘场景可选。 ## 注意事项 - 所有步骤不要写“输入正确用户名”之类模糊表述要写具体值例如“输入用户名 admin”。 - 禁止使用猜测的不存在数据。 - 如果需求描述有歧义宁可多问一次也不要生成错误用例。这里有几个细节值得单独拎出来说。第一配置和主逻辑分离。模板字段放在exported variables或其他工具支持的变量区里而不是硬编码在prompt中这样修改模板时不需要动整个skill逻辑。第二明确要求“用户确认后再进入下一步”。这个设计初看会觉得麻烦但实际操作中它能拦截掉一半以上的需求理解偏差。AI先给出测试点拆解列表你扫一眼有没有漏场景没有就回车继续整个过程多花不到10秒省下来的却是后面大规模的返工时间。第三优先级标准写得很细。为什么必须这样因为通用模型默认的优先级判定和测试领域的习惯差异很大不明确写死它就会按自己的理解给你标所有用例都是高优先级最后每一条都得人工改。2.3 用例模板的取舍字段多少才合适模板里的字段不是越多越好要结合实际落地场景来定。我见过有些团队把用例模板设计得非常豪华字段有二三十个包括用例ID、所属迭代、用例类型、用例级别、前置条件、测试数据、测试步骤、预期结果、实际结果、执行状态、执行人、执行时间、关联缺陷、关联需求、备注……每个字段都要填。愿望是美好的希望能把测试资产沉淀下来但真到执行环节写的人都烦了填完这些字段的时间够跑两轮测试。我现在的模板是8个字段编号、模块、标题、前置条件、测试数据、步骤、预期结果、优先级。为什么没有用例类型因为触发这个skill的场景基本都是功能测试类型稳定性很高没必要每次让AI判断一下。反过来说如果你们团队既做功能测试又做接口测试而且希望在一个skill里区分那再加“用例类型”这个字段就合理。一切以你们团队的流程为基准不要盲从工具自带的模板。另外关于步骤的粒度我踩过一个坑。一开始我要求“步骤必须极其详细”结果AI生成的用例一条能有15个步骤反而没法用——因为用例太长了执行的人反而抓不住重点。后来调整成“每个操作动作一行等价类合并”比如清空输入框、输入有效值、点击登录、检查跳转合并成4步执行效率最高。这个粒度你们可以根据实际项目调整但有一个原则可以shared如果一条用例执行时间超过5分钟基本说明步骤拆得过细了。3. 实战演示从原始需求到15条标准用例的全流程3.1 真实场景输入登录模块需求描述光讲理论不够我直接拿一个实际跑过的场景演示一遍。假设现在要测一个系统的登录模块需求描述如下“用户输入手机号和密码点击登录按钮验证通过后跳转到首页。如果手机号未注册提示‘该手机号尚未注册’如果密码错误提示‘密码错误请重试’连续输错5次密码账号锁定30分钟。支持记住密码功能勾选后下次打开App自动填充账号密码。”就这么一段话信息量其实不小。手动拆解的话测试点至少包括正常登录、未注册手机号、密码错误、密码连续错误触发锁定、账号锁定期间登录、记住密码功能。这是第一层。再往细想还有边界场景空手机号、空密码、手机号格式非法、密码长度边界、锁定状态解除后的登录。这些是需求里没直接说但必然存在的场景。传统人工做法从读需求到列出这十几个场景再逐条写成标准格式我实测过三次平均时间在28到35分钟之间。这是有经验的测试工程师的速度新手会更快或更慢——大部分情况下是更慢。3.2 skill调用过程实录我实际调用skill时的输入很简单在AI助手的对话框里输入用test-case-generator skill生成登录功能测试用例。 需求用户输入手机号和密码点击登录按钮验证通过后跳转到首页。如果手机号未注册提示‘该手机号尚未注册’如果密码错误提示‘密码错误请重试’连续输错5次密码账号锁定30分钟。支持记住密码功能勾选后下次打开App自动填充账号密码。AI按照skill中的流程走了两步。第一步输出测试点拆解列表我看到它列了正常登录、未注册手机号、密码错误、连续输错锁定、锁定状态下登录、记住密码、空手机号、空密码、手机号格式非法、密码长度边界、锁定过期后自动解锁——一共11个测试点。我扫了一眼覆盖度够了直接回复“确认”。第二步它基于这11个测试点生成用例每条用例包含编号、模块、标题、前置条件、测试数据、步骤、预期结果、优先级。整个过程真正消耗的时间就是从发出指令到看到测试点列表再把确认指令发出去两轮对话总时长大约25秒。第二次生成我做了计时从输入到拿到完整用例清单用了30秒左右。这就是标题里30秒的来源。3.3 生成结果质量评估不是能写是真的能用我知道光快没用质量不行全是废纸。所以我把AI生成的15条用例实际生成15条有些测试点拆成了多条用例拿给团队里两位测试老手审了一遍结论是整体可用度高结构和格式完全符合规范测试点覆盖了正常流、异常流、边界值但有两个地方需要手动补。第一个没有覆盖“手机号注册但未绑定角色”的场景。这是一个业务逻辑上的隐藏场景需求描述里没提AI自然无法推断。这不算生成质量问题是输入信息本身就缺失。第二个锁定30分钟的边界测试AI给出的测试数据是“等待30分钟后登录”但没有细化为“29分59秒登录失败、30分01秒登录成功”这种精确边界。这是可以接受的因为30分钟的等待本身就不适合放功能测试用例里跑通常会通过修改数据库锁定时间字段来实现。整体来看人工后续补2条用例、微调3条优先级总耗时15分钟。这样算下来从拿到需求到用例库可执行实际投入是“30秒AI生成15分钟人工精修”前后台加起来不到16分钟。对比原来纯人工的30分钟提升约2倍。如果只算纯生成环节那从30分钟到30秒就是60倍。不同口径提升幅度不同但无论如何效率改善都是肉眼可见的。我用了一段时间后还总结了一个经验不要指望第一次生成的用例就是终稿。把它当作“高品质草稿”来用你的心态会好很多。AI的强项是把隐藏在自然语言里的场景穷举出来、按格式规范输出人的强项是结合业务上下文做最后的判断。这两者结合起来才是这个工作流真正的价值所在。4. 常见问题与排查技巧skill稳定运行的几个关键细节4.1 AI“忘记”了skill指令怎么办这可能是最让人抓狂的事情你明明调用了skill但AI输出的格式完全不是skill里约定的样子。刚开始我也遇到过分析下来主要有三个原因一是skill描述文件中触发条件写得不够明确AI没有识别出当前请求与skill的匹配关系二是输出约束写得太多太长模型在长上下文里的注意力漂移导致部分约束丢失三是误用了全局系统Prompt覆盖了skill的指令。针对这些情况我的排查顺序是先看AI是否在回答开头反馈“根据test-case-generator skill来处理”——如果有说明触发成功那问题就在约束描述如果没有说明触发失败需要调整触发条件。约束丢失的问题解决方法是把最关键的格式要求放在SKILL.md的末尾经验是模型对开头和结尾的内容记忆更牢中间的约束容易被稀释。另外还有一个很实用的技巧在skill的每个关键步骤后面加一句“输出前请检查上一步的结果是否满足xxx要求”这样等于给模型增加了强制自检的锚点它输出前会多过一遍约束。4.2 生成的用例出现模板字段错乱怎么办字段错乱最典型的表现是有的用例有“测试数据”有的没有有的预期结果写成了操作步骤有的优先级用了“高/中/低”而不是约定的“P0/P1/P2”。这些情况基本可以定位为prompt中的“字段定义不够具体”。解决方式是在SKILL.md里给每一个字段加一个简短的“字段属性说明”比如前置条件说明执行该用例前需要具备的环境或数据状态没有则为“无”。测试数据列出步骤中会用到所有输入值的具体内容。预期结果描述可观察到的系统行为变化禁止使用“正常”“正确”等模糊词。给字段加属性的另一个好处是AI在理解“前置条件”和“测试数据”的区别时更清晰。有相当一部分模型会把这两个字段混淆导致前置条件里写数据、测试数据里写环境。一旦属性定义明确这个问题的出现频率会大幅降低。4.3 处理“临时需求”skill生成结果如何快速调整测试这个岗位永远逃不掉一类场景开发临时提了一个需求变更就几句话但用例得立刻更新。这种场景下原有的全量生成流程就太重了。我在skill里加了一个“增量更新”模式触发指令是“基于已有用例生成变更涉及的新用例和受影响用例清单”。在SKILL.md的工作流程里增加了一个判断如果用户输入中包含“增量”或“更新”则跳过第二步的完整测试点拆解直接基于变更描述定位原有测试点输出两条结果——新增用例和受影响用例。这个改动极大节省了临时变更场景的处理时间。4.4 常见问题速查表突发情况可能原因处理建议生成的用例全部是正常流缺少异常流需求描述中没有明确的异常条件在rompt里显式加上“请补充异常场景”的约束前置条件里写入了测试数据字段属性定义不够清晰在SKILL.md里为字段添加属性说明用例粒度不一致有的3步、有的15步缺少对步骤粒度的明确约定增加“每个步骤只包含一个操作动作”的约束生成的用例超过可用范围比如生成了自动化脚本skill无明确职责边界明确在触发条件里写出该skill不做什么AI反复确认需求但迟迟不给出用例需求描述信息不足直接在输入中补充功能模块和业务规则减少对话次数4.5 一个tips让skill学会“从结果倒推”最后分享一个我觉得很值的自定义技巧。有一次做测试用例评审我发现AI生成的一条用例步骤是“输入密码123456”但预期结果却写着“登录成功”。表面上看没问题但结合业务场景这个用例其实是有隐患的——如果系统要求密码至少8位这个用例根本执行不到登录那一步。这个问题的根源在于AI在生成步骤时关注的是操作而不是数据本身的有效性。后来我在SKILL.md里加了一条约束在生成前置条件和测试数据时先验证数据是否符合业务规则。具体实现上是加了一个“数据合理性检查”步骤如果用户没有额外指定默认自动生成符合常规规则的测试值。密码至少8位那就用Test123456这种值填。手机号用13800138000这样符合格式的占位。这个小小的改动让我后来几乎不用再改测试数据的格式又是一个实打实的时间节省。结语我的体会和后续还能扩展的方向用skill自动生成测试用例这个事情的底层逻辑其实是“把测试专家的工作流固化给AI执行”。它不会替代测试人员但它能顶掉那些重复性最高、价值密度最低的文字工作让测试人员把精力投向探索性测试、风险评估这些真正需要人的经验的地方。我目前这个skill只覆盖了功能测试用例后面我计划扩展的方向有几个接口测试用例生成从swagger文档直接转、测试数据自动构造结合字段规则生成边界值组合、以及根据历史缺陷数据优化测试点拆解的优先级——让skill能根据哪个模块历史缺陷多自动增加该模块的测试点密度。这些延伸方向都基于同一个skill框架改起来成本不高后续我会一个一个做出来并把经验同步出来。你可以先把手上的功能测试用例场景跑通再按自己的业务规则去扩张边界这条路走通之后效率上的回报是持续的。