这周迭代有个重置密码的需求要覆盖正常修改、旧密码错误、两次输入不一致、token过期、账号锁定这类场景手工列用例的话我从需求评审完就开始写写完抬头一看表28分钟过去了。同一间办公室里我旁边工位的同事用他配好的测试用例skill把需求文档里的前置条件、边界值、异常分支全部捞出来40条功能测试用例整整齐齐排进用例管理平台全程大约30秒。这个差距不是手速问题而是方法问题——他用的不是普通提示词而是最近在Claude Code、Codex、Cursor这类agent生态里讨论很多的测试用例skill一套可复用的技能包把资深测试的思考方式直接固化成了执行流程。这篇我就把这个skill的搭建思路、规则文件设计、实测数据和踩过的坑完整拆开讲。1. 为什么是60倍这个skill不是在写用例是在把方法固化1.1 手工写用例的时间都花在哪了先算一笔账30分钟写40条用例平均每条45秒。这个时间其实没花在打字上而是花在四个地方反复回看需求描述确认某个字段到底是必填还是选填确认异常提示文案的准确措辞。在脑子里过黑盒测试的几种设计方法这个模块该用等价类还是边界值要不要上判定表。写前置条件时纠结数据准备比如已注册用户意味着数据库里要有对应记录这个状态怎么描述才准确。用例之间查重、补漏写完正向流程还要倒回去想有没有遗漏的逆向分支。这四个动作本质上是方法调用的过程而AI skill能做的恰恰是把方法固化成规则让模型在生成用例时不用每次重新推理一遍该用什么方法。60倍效率提升的底层逻辑很简单人花30分钟是在思考方法组织语言skill花30秒是在套用方法生成语言语言生成是AI的强项方法套用是规则文件的强项两者一结合时间就压下来了。1.2 skill和普通prompt的区别在哪很多人觉得skill就是个高级prompt这个理解会直接导致skill做出来不好用。我在第一次尝试的时候也以为在对话里写一段你是一个资深测试工程师请根据以下需求生成测试用例就够了结果生成的用例泛泛而谈全是验证功能正常检查系统反应这种正确的废话。真正的skill本质上是一个带目录结构的可执行知识包通常包含三个组成部分说明文件SKILL.md负责告诉agent这个技能是干什么的、什么时候该调用规则文件负责描述具体的方法论和约束条件示例文件负责给出一组高质量的参考输出。三者配合agent才能在有明确规则约束的情况下完成生成任务。普通prompt是一次性的对话指令每次都要重新组织上下文而skill是可以被agent主动发现、重复调用的能力单元这才是效率差距的根源。2. 测试用例skill的骨架SKILL.md、规则文件与示例的三角结构2.1 目录结构怎么搭如果你用的是Claude Code这类支持自定义skill的工具目录结构一般长这样test-case-skill/ ├── SKILL.md ├── rules/ │ ├── blackbox-methods.md │ └── template-format.md ├── examples/ │ ├── login-module-example.md │ └── payment-order-example.md └── scripts/ └── format-to-excel.py这个结构有讲究。SKILL.md放在根目录是为了让agent在扫描技能时第一时间读到元信息rules目录放方法论规则控制生成质量examples目录放参考样例给模型提供few-shot示范scripts目录是可选的用于把生成结果转成Excel或批量导入用例管理平台。我在实际搭建时踩过一个坑一开始把规则全部写进了SKILL.md结果文件超过200行agent读取时注意力被稀释反而忽视了关键约束。后来把方法论拆到rules目录SKILL.md只保留精简的调用说明效果立刻改善。这背后的原因是大模型对超长上下文里优先级的判断并不稳定与其把所有规则堆在一个文件里不如通过文件结构让agent按需加载。2.2 SKILL.md里必须写清楚的三件事每个skill的SKILL.md有三件事是绝对不能含糊的第一技能定位。一句话说明这个skill用于从需求描述、PRD或接口文档中生成结构化的功能测试用例让agent在遇到相关任务时能正确识别并触发调用。第二输入要求。明确告诉agent需要什么格式的输入比如需求文档、用户故事、接口定义以及当输入缺失时应该主动向用户索要哪些信息。这一点非常关键很多skill翻车就是因为输入信息不全agent在信息真空里硬编。第三工作流约束。规定生成用例前必须先做需求拆解再到规则文件里选择适用的测试方法最后按模板输出。这一条约束的是agent的执行顺序避免它跳过分析步骤直接输出结果。我在SKILL.md里加了一段硬性要求生成用例前必须列出需求理解摘要把涉及的功能点、输入字段、约束条件复述一遍。这个设计一开始是为了让输出更可控后来发现它还有一个额外价值——当agent理解偏差时用户在生成结果之前就能从摘要里发现问题避免浪费一整轮对话。3. 把黑盒设计方法装进规则等价类、边界值、判定表和场景法3.1 规则文件里怎么定义测试方法rules/blackbox-methods.md是这个skill的灵魂它负责把黑盒测试的经典方法转译成agent能执行的判断逻辑。我整理了五种方法的使用场景写成了规则表测试方法适用场景规则要点等价类划分输入条件存在取值范围或有效性判断至少覆盖一个有效等价类和两个无效等价类边界值分析输入存在边界区间取上点、内点、离点每个边界至少三条用例判定表多条件组合决定行为条件桩和动作桩齐全合并化简后的规则逐条覆盖场景法业务流程有明确主路径和备路径基本流一条备选流和异常流各至少一条错误推测存在历史缺陷或典型操作失误基于经验补充空值、超长字符、并发操作等用例写这个规则文件时不能用请遵循等价类划分方法这种笼统描述必须给出可判断的具体条件。比如边界值分析我写的是当输入字段有长度限制时必须覆盖min-1、min、min1、max-1、max、max1六个值这样agent生成用例时才有明确的量化依据。3.2 测试用例模板的字段设计测试用例模板决定了输出结果的可用性字段设计必须贴合实际用例管理平台的需求。我最终定下的模板字段如下用例编号模块缩写序号如LOGIN_001。所属模块需求文档里定义的模块名称。用例标题一句话描述测试意图必须包含操作对象和预期结果。前置条件数据准备、环境配置、账号状态等。测试步骤可执行的详细操作步骤每一步独立编号。输入数据具体的测试数据不允许写合法数据这种模糊表述。预期结果可验证的结果描述包含提示文案和系统行为。优先级P0到P3P0为阻塞级P3为一般级。模板文件里我放了一个反例部分专门列出低质量用例的典型特征没有具体输入数据、预期结果写成系统正常、一个用例里塞了多个测试意图。这个设计是从实测教训中来的我发现不给反例时模型倾向于生成语法正确但信息量不足的用例给出反例后输出质量明显提升。3.3 一个实际例子登录模块的用例生成对照用登录模块做个直观对比。手工写用例时一个用户名密码登录功能有经验的测试会覆盖正确登录、用户名错误、密码错误、账号锁定、密码过期、空用户名、空密码、用户名超长、密码边界长度、特殊字符、大小写敏感、连续失败后的锁定策略。这些场景看起来简单但要完整梳理并组织成规范格式20分钟是跑不掉的。skill拿到需求描述后会先做需求理解识别出登录功能涉及用户名输入框、密码输入框、登录按钮、错误提示区域四个界面元素然后调用规则文件对用户名和密码字段做等价类划分对长度限制做边界值分析对登录结果做判定表分析最后用场景法梳理正常登录、密码错误、账号锁定的业务流程。一套流程下来生成的用例数量通常在35到45条之间覆盖度可以达到资深测试手工编写的90%以上。这里要强调一个观点skill的目标不是替代测试人员的设计能力而是把重复性的、结构化的用例编写工作自动化让测试人员把省下来的时间投入到探索性测试和复杂业务逻辑分析上。4. 决定成败的输入设计怎么让skill读懂需求和接口4.1 输入什么PRD、用户故事还是接口文档skill的输入质量直接决定输出质量这一点在我实测中得到反复验证。目前我总结出三种可行的输入形态结构化需求描述包括功能说明、输入字段定义、约束规则、异常处理逻辑这是质量最高的输入。接口文档适合接口测试用例生成包含请求方法、URL、参数列表、必填项、参数类型和取值范围。原始PRD文档可以直接粘贴但需要skill做一轮需求抽取把功能性描述转成字段级的约束条件。实际使用中最省事的做法是让skill支持三段式输入先粘贴需求原文再补充一段关键约束说明字段限制、权限要求、业务规则最后指定要生成的用例类型功能用例、接口用例还是回归用例。当用户只提供第一段时skill应该主动追问第二段和第三段而不是闷头生成。4.2 上下文摄取的两种方式skill获取上下文的方式决定了它在不同场景下的可用性。我在实践里尝试过两种各有适用场景第一种是直接粘贴法。把需求文本、接口定义或相关代码片段直接放在对话中输入适合需求明确、信息集中、不需要跨文件检索的场景。优点是简单直接缺点是当需求文档很长时粘贴内容会占用大量上下文窗口影响生成质量。第二种是引用文件法。在skill的调用说明中支持让用户直接指定文件路径让agent自主读取相关文件。这种方式适合信息分散在多个文档中的情况比如需求文档、接口定义、数据库设计散落在不同目录。我在实际使用中倾向于让用户把核心需求复制粘贴进来同时允许agent按需读取指定的补充文件这样既保证核心信息不丢失又避免上下文窗口被无关内容占满。4.3 输出格式与验收标准为了让输出可以直接落入用例管理平台我要求skill最终输出一个Markdown表格同时提供一份可选的JSON格式方便后续批量导入。JSON的结构我用一个明确的规范固定下来包含module模块名、title用例标题、precondition前置条件、steps步骤数组、expected预期结果、priority优先级六个字段。验收标准是和质量强相关的一张检查清单我把它写进了规则文件每条用例必须有具体输入数据预期结果必须包含可观察的界面行为或系统响应每个输入字段必须覆盖合法和非法两种取值业务流程必须包含正向主路径和至少一条异常分支用例之间不允许存在重复覆盖同一逻辑的情况。生成完成后让skill对照这份清单自查一遍再输出。5. 实测数据与调优记录30分钟怎么压到30秒5.1 首版实测快是快但漏场景第一次跑通的时候生成确实很快一个支付下单功能的需求描述agent在20多秒内生成了28条用例。但我对照自己手工编写的42条用例检查了一遍发现三个问题第一对金额字段的边界值覆盖不全只生成了0元、1元、最大额度三个点缺少最小额度1、最大额度-1、最大额度1这几个关键边界点。第二对支付超时、重复提交、并发下单这类时序类异常完全没有覆盖。第三部分用例的预期结果写得太笼统比如提示错误这种描述没有具体到错误文案和页面行为。这些问题反映出一个本质规则文件对场景完整性的约束不够刚性agent在生成时倾向于覆盖常见路径而忽略边界路径和时序路径。5.2 调优过程让skill学会先问问题针对首版的问题我做了三轮调优。第一轮在规则文件里强化了边界值分析的量化要求明确规定所有数值型字段至少覆盖六个边界点并在示例文件里补了一个金额字段的完整边界用例集。第二轮增加了异常场景清单约束要求生成完正向用例后必须单独生成一组异常用例覆盖超时、并发、重复提交、数据不存在、权限不足、依赖服务不可用六类典型异常。第三轮调整了执行流程让skill在生成前先输出一个信息确认清单列出从需求描述中识别出的功能点、输入字段、约束条件和不确定项并主动向用户确认是否有遗漏。这一步把生成质量问题的发现时机从生成后检查提前到了生成前对齐实际使用中减少了很多返工。三轮调优之后同一个支付下单需求生成的用例数量从28条提升到45条覆盖度基本追平了人工编写的水平生成时间稳定在35秒以内这还不算上agent部分参数可以并行加速的空间。5.3 与人工用例的质量对比对比维度人工编写skill生成调优后耗时25-35分钟30-40秒用例数量40-45条42-48条边界值覆盖完整完整异常场景覆盖依赖个人经验规则清单驱动稳定覆盖格式规范性因人而异统一格式可直接导入业务理解深度理解隐性规则需要人工补充隐性业务知识从表格可以看出skill在效率和规范性上优势明显而人工编写在隐性业务规则理解上仍有不可替代的价值。最合理的用法是先用skill生成完整的基础用例集测试人员基于自己的业务理解增删调整而不是完全放手。这一步经验我在团队里推广时反复强调避免有人以为skill是银弹。6. 从功能用例到接口用例skill的横向扩展思路6.1 接口测试用例生成的特殊性功能用例skill跑通后很自然会想扩展到接口测试用例我在这个方向上做了一些实践。接口用例的生成逻辑和功能用例有本质区别功能用例关注界面操作和用户行为接口用例关注协议、参数、状态码和响应结构。规则文件需要新增针对接口文档的解析规则包括请求方法的覆盖GET、POST、PUT、DELETE、参数必填性校验、参数类型匹配、枚举值合法性、鉴权字段有效性和无效性、响应状态码的预期判断。在输入设计上接口文档的输入格式比需求文档更规整通常包含接口路径、请求参数表、响应结构三个部分。skill读到接口描述后可以直接对每个参数做等价类和边界值分析生成的效果往往比功能用例更好因为接口文档的信息密度高不需要额外做需求抽取。6.2 结合测试管理平台与自动化脚本当skill生成的结果稳定之后我开始考虑怎么减少复制粘贴这一步的人工操作。我在skill的scripts目录下写了一个简单的格式转换脚本可以把skill输出的JSON格式用例自动转换成Excel表格字段对齐到常用用例管理工具的导入模板。用Python实现核心逻辑就是把JSON解析后按模板字段顺序写入Excel遇到步骤列表时智能合并单元格。整个过程把生成用例到导入平台的链路压缩到了一分钟以内。更进一步的方向是直接生成自动化测试脚本。对于接口用例skill可以在生成用例的同时输出对应的Python请求代码每个用例对应一个测试函数参数用pytest的parametrize装饰器组织。我实验过这个功能生成的脚本经过少量调整就能跑通对于接口改动频繁、需要快速回归的场景价值非常直接。6.3 团队推广的注意点最后聊聊在团队里推广这套玩法时容易踩的坑。第一个坑是拿来主义直接从网上下载一个现成的测试用例skill放到团队环境里发现生成的用例全是通用模板完全不贴合自己项目的业务特点。解决办法是让skill的规则文件里带上项目特有的业务规则比如支付项目的金额精度、超时阈值、风控规则这些必须由团队里最了解业务的人补充进去。第二个坑是信任过度有人习惯把skill生成的用例直接作为最终交付物没有做同行评审。我的建议是引入一个简单的抽检机制每个迭代随机抽五条用例由另一名测试人员对照需求复核覆盖度和正确性。这个机制运行了两轮之后团队对skill输出的信任度明显提升生成的用例也能更快地进入正式用例库。第三个坑是版本漂移需求变化之后之前生成的用例集没有及时更新。我目前的处理方式是给skill的输入增加一个变更点描述参数需求变更时让skill针对变更点生成增量用例并在增量用例的编号上增加修订标识这样既保留了历史用例又能快速定位变更影响范围。从我个人的使用体感来说这个测试用例skill最大的价值不在于省了那几十分钟而在于把用例设计的一致性拉到了一个稳定的基准线上。以前团队里五个人写用例风格五花八门覆盖深度参差不齐现在有了skill打底基础的覆盖度和格式规范有了保底大家可以把精力放到更考验功力的探索性测试和复杂业务场景设计上。如果你还在用手工方式写基础用例我建议找个时间把规则文件搭起来30秒出稿的感觉值得体验一次。