把资深测试工程师的经验，封装成AI随取随用的"技能包"
大家好，我是某互联网公司的测试架构师。
上个月，团队里来了一个新项目——电商购物车模块的改版。需求文档不复杂，大概十来页。但测试组长看了一眼排期，皱了下眉："按以前的节奏，光写用例就得3天。"
团队里一个刚转正的测试新人接了这个任务。他花20分钟调用了一个Skill，2小时后交出了一份覆盖正常流程、异常场景、边界值、权限校验的完整用例集。
测试组长看完之后，沉默了一会儿，问了一句："这是谁写的？质量比我自己写还高。"
他说的"那个东西"，就是今天这篇文章要讲的——测试Skill流水线。
一、先搞清楚：Skill到底是什么？
很多人第一次接触"Skill"这个概念的时候，以为就是"高级一点的Prompt"。
完全不是一回事。
Skill是Anthropic在2025年10月推出的"技能包"机制，核心是把提示词、脚本、参考资料打包成一个文件夹，Claude Code在需要时自动发现并调用。它采用"渐进式披露"设计——Claude启动时只预加载技能的元数据，几乎不占用上下文窗口；当它判断某个技能与当前任务相关时，才逐步加载完整指令。
用大白话说：Skill就是把"资深测试工程师怎么做用例设计"的完整经验，封装成一个AI能随时调用的"能力包" 。一次写好，长期复用，团队共享。
一个Skill的核心结构是这样的：
SKILL.md：核心指令文档，告诉AI"怎么做"
scripts/：可选的可执行脚本
references/：参考资料（模板、规范、Checklist）
最关键的是SKILL.md里的description字段——它决定了AI在什么场景下自动启用这个Skill。写得越精确，自动匹配准确率越高。
而测试用例设计的全流程，本质上就是一套可以拆成四个环节的标准化流水线：
需求拆解 → 用例生成 → 场景补全 → 质量评审
每一个环节，都可以封装成一个独立的Skill。四个Skill串在一起，就是一条从需求到高质量用例的"自动化流水线"。
下面，我用一个电商购物车"加入购物车"功能的真实案例，把这四个Skill从头到尾走一遍。
二、Skill ①：需求拆解 —— 把PRD变成"测试地图"
痛点
拿到一份需求文档，很多人第一反应是"从头开始读"。但PRD往往写得不够结构化——功能描述、业务规则、异常说明散落在不同章节。测试人员需要手动提取功能点、梳理业务规则、识别风险点——这个过程高度依赖个人经验。
Skill设计思路
这个Skill的核心任务只有一个：把自然语言的需求文档，变成结构化的"测试地图" ——功能清单、业务规则、数据约束、风险预判。
真实输入
测试新人把PRD中关于"加入购物车"的内容整理了一下，喂给了这个Skill：
功能：用户将商品加入购物车
参与者：已登录用户
前置条件：用户已登录，商品处于上架状态
主流程：用户浏览商品 → 点击"加入购物车" → 系统校验库存 → 商品加入购物车 → 提示添加成功
异常情况：库存不足时提示"库存不足"
Skill输出
几秒钟后，AI输出了一份结构化的"测试地图"：
【功能清单】
F1：已登录用户将商品加入购物车
F2：未登录用户点击"加入购物车"（触发登录引导）
F3：购物车数量上限校验
【业务规则】
R1：商品必须处于"上架"状态才能加入购物车
R2：加入购物车时需校验库存，库存不足则拦截
R3：同一商品多次加入，购物车中数量累加
R4：购物车商品数量有上限（需确认具体数值）
【数据约束】
D1：商品ID：必填，字符串，存在性校验
D2：数量：必填，正整数，≥1
D3：用户ID：必填，存在性校验
【风险预判】
⚠️ 高风险：库存校验的并发场景（超卖）
⚠️ 中风险：购物车数量上限的边界值
⚠️ 中风险：未登录状态的跳转逻辑
⚠️ 低风险：UI文案展示
这个"测试地图"的价值在于：它不是AI凭空想象的，而是从需求文档里"抽"出来的。 测试人员拿到这张地图，对"要测什么"心里已经有了底。
SKILL.md核心片段
name: prd-to-test-map
description: 从PRD中提取功能点、业务规则、数据约束和风险预判，生成结构化测试地图。适用于需求评审、测试点梳理阶段。
任务
将用户提供的需求描述或PRD内容，转化为结构化的测试地图。
输出格式
按以下四个维度组织输出：
- 功能清单：列出所有需要测试的功能点，每个功能用一句话描述
- 业务规则：列出所有业务规则（状态流转、计算公式、权限控制、限制条件）
- 数据约束：列出输入数据的类型、格式、范围、必填性
- 风险预判：基于经验判断哪些功能最容易出问题，标注风险等级（高/中/低）
规则
- 只从输入内容中提取信息，不臆造不存在的功能
- 如果某项信息不明确，标注"需确认"而不是猜测
- 风险预判基于通用测试经验：并发场景、边界值、状态流转通常为高风险
三、Skill ②：用例生成 —— 把"测试地图"变成"测试用例"
痛点
有了测试地图，接下来要把它"翻译"成具体的测试用例。传统方式是手动一条条写——前置条件、操作步骤、预期结果。这个过程步骤繁琐、规则固定、重复性极高。
Skill设计思路
这个Skill的核心任务：基于测试地图，自动生成结构化的测试用例，覆盖正常流程、异常操作、边界条件和权限校验四大场景。
输入
把Skill①输出的"测试地图"直接喂给Skill②。
Skill输出
AI自动生成了一份完整的测试用例表格：
用例编号
测试场景
前置条件
测试步骤
预期结果
场景类型
优先级
TC-001
正常加入购物车
用户已登录；商品A库存充足
1.浏览商品A 2.点击"加入购物车"
商品加入购物车；提示"添加成功"；购物车数量+1
正常流程
P0
TC-002
库存不足时加入
用户已登录；商品A库存为0
1.浏览商品A 2.点击"加入购物车"
提示"库存不足，无法加入"；购物车不变
异常场景
P0
TC-003
未登录时加入
用户未登录
1.浏览商品A 2.点击"加入购物车"
跳转至登录页；登录后商品自动加入购物车
权限校验
P1
TC-004
同一商品重复加入
用户已登录；购物车已有1件商品A
1.再次点击商品A的"加入购物车"
购物车中商品A数量变为2；提示"已加入购物车"
正常流程
P1
TC-005
购物车数量达到上限
用户已登录；购物车已满（假设上限99件）
1.尝试再加入一件商品
提示"购物车已满"；无法加入
边界条件
P1
TC-006
下架商品加入购物车
用户已登录；商品B已下架
1.浏览商品B 2.点击"加入购物车"
提示"商品已下架，无法加入"
异常场景
P1
TC-007
数量输入为0
用户已登录
1.在数量输入框输入0 2.点击"加入购物车"
提示"数量必须大于0"
边界条件
P2
40多条用例，覆盖了正常流程、异常场景、边界值、权限校验四大类 —— 如果人工写，至少要2-3天。AI只用了不到1分钟。
SKILL.md核心片段
name: test-case-generator
description: 根据功能描述自动生成结构化的测试用例。适用于编写测试用例、验证功能完整性、回归测试设计等场景。
任务
根据用户提供的功能描述或测试地图，生成覆盖正常流程、异常操作、边界条件和权限校验四大类场景的测试用例。
输出格式
表格，包含以下字段：
- 用例编号：{模块缩写}-{类型缩写}-{序号}
- 测试场景：一句话描述
- 前置条件：执行前必须满足的条件
- 测试步骤：编号列表，每步一个操作
- 预期结果：执行后的期望结果
- 场景类型：正常流程/异常场景/边界条件/权限校验
- 优先级：P0/P1/P2
规则
- 每个功能点至少生成1条正向用例 + 3条异常/边界场景
- 优先覆盖用户高频操作、核心业务链路、高危边界场景
- 测试步骤必须具体可执行，不能是模糊描述
四、Skill ③：场景补全 —— 查漏补缺，把"没想到"的找出来
痛点
Skill②生成的用例已经很全面了，但AI毕竟不是人——它可能漏掉一些"只有业务老手才知道"的隐藏场景。比如：并发下单时的库存扣减、优惠券和满减的叠加规则、异常状态下的回滚逻辑。
Skill设计思路
这个Skill的核心任务：基于知识图谱或历史Bug模式，自动识别"AI没想到但很可能出问题"的场景，补充到用例集中。
这里的"知识图谱"可以很简单——就是一张Excel表格，记录着"这个模块历史上出过什么类型的Bug"。
输入
把Skill②生成的用例集 + 该模块的历史Bug清单（如果有）喂给Skill③。
Skill输出
AI基于历史Bug模式，自动补充了3条"隐藏场景"：
用例编号
测试场景
补充理由
TC-008
高并发下同时加入同一商品
历史数据显示该模块在秒杀场景下出现过库存超卖
TC-009
购物车商品跨设备同步
用户在多端登录时，购物车数据需实时同步
TC-010
加入购物车时触发价格变更
商品价格在用户浏览和点击加入之间发生变化
这三条场景，Skill②的"通用用例生成"逻辑覆盖不到。只有结合了历史经验和业务上下文，才能发现它们。
SKILL.md核心片段
name: test-scenario-completion
description: 基于历史Bug模式和业务知识，补充AI生成的测试用例中遗漏的隐藏场景。
任务
审查已有的测试用例集，结合历史Bug数据和业务上下文，识别并补充遗漏的测试场景。
检查维度
- 并发场景：多用户/多请求同时操作同一资源
- 状态流转：异常状态下的操作（如已取消订单再次操作）
- 数据一致性：跨模块的数据同步（如订单取消→库存回滚）
- 边界组合：多个边界条件同时出现的情况
- 历史故障：该模块历史上出过什么类型的Bug
输出格式
对每个补充的场景，说明：
- 场景描述
- 补充理由（为什么AI会漏掉、为什么重要）
- 具体的测试步骤和预期结果
五、Skill ④：质量评审 —— 给用例集"打分"并给出改进建议
痛点
用例写完了，但质量怎么样？覆盖全不全？有没有冗余？有没有逻辑矛盾？传统方式是人工评审——开个会，一群人对着Excel一条条看，效率低下且依赖评审人的经验水平。
Skill设计思路
这个Skill的核心任务：对整份用例集做自动化质量评审，从覆盖完整性、用例规范性、逻辑一致性、优先级合理性四个维度打分，并给出改进建议。
输入
把Skill③输出的最终用例集喂给Skill④。
Skill输出
AI自动生成了一份"质量评审报告"：
【测试用例质量评审报告】
📊 总体评分：87/100（良好）
📈 各维度评分：
- 覆盖完整性：92/100 ✅（正常流程和异常场景覆盖完整，边界条件覆盖较好）
- 用例规范性：85/100 ⚠️（部分用例步骤描述不够具体）
- 逻辑一致性：90/100 ✅（前置条件与预期结果逻辑一致）
- 优先级合理性：80/100 ⚠️（部分P1用例应升级为P0）
🔴 待改进项（3项）：
- TC-007（数量输入为0）：步骤描述过于简略，建议补充"输入框的具体位置和操作方式"
- TC-009（跨设备同步）：缺少"同步后验证数据一致性"的步骤
- 优先级调整：TC-003（未登录时加入）涉及核心业务流程，建议从P1升级为P0
✅ 评审结论：用例集整体质量良好，建议优先修复3项待改进项后定稿。
这份评审报告的价值在于：它不是"又一个人工评审"，而是让AI先做一轮"预审"，把明显的问题筛出来，人工只需要关注AI搞不定的部分。
SKILL.md核心片段
name: test-case-reviewer
description: 对测试用例集进行自动化质量评审，从覆盖完整性、规范性、一致性、优先级四个维度打分并给出改进建议。
任务
审查测试用例集的质量，输出结构化的评审报告。
评审维度
- 覆盖完整性：是否覆盖了正常流程、异常场景、边界条件、权限校验？
- 用例规范性：每条用例是否包含完整的"前置条件-步骤-预期结果"？
- 逻辑一致性：前置条件和预期结果之间是否存在逻辑矛盾？
- 优先级合理性：P0/P1/P2的划分是否合理？
输出格式
- 总体评分（百分制）
- 各维度评分
- 待改进项列表（每条说明问题、位置、改进建议）
- 评审结论（通过/有条件通过/不通过）
六、四Skill流水线：一张图看懂全流程
把这四个Skill串在一起，就是一套完整的测试用例生成流水线：
📄 需求文档
↓
[Skill ① 需求拆解] → 测试地图（功能清单+业务规则+风险预判）
↓
[Skill ② 用例生成] → 用例初稿（40+条结构化用例）
↓
[Skill ③ 场景补全] → 用例增强（补充3-5条隐藏场景）
↓
[Skill ④ 质量评审] → 评审报告+改进建议
↓
✅ 高质量用例集（人工审核后定稿）
传统方式：啃PRD（半天）→ 梳理测试点（半天）→ 写用例（1-2天）→ 人工评审（半天）→ 修改（半天）——总计3-4天。
Skill流水线方式：调用四个Skill，AI自动完成从需求到用例的全流程——总计2小时出初稿，人工审核1小时定稿。
效率提升：10倍以上。
七、避坑指南
坑一：一上来就想"全自动化"
不要指望四个Skill一次性跑完所有环节，中间没有任何人工介入。AI生成的是"初稿"，不是"终稿"。我们的流程永远是"AI生成→人工审核→确认定稿"。
解法：在每个Skill的输出环节设置"人工确认点"。比如Skill①输出测试地图后，先让测试负责人确认"功能清单有没有遗漏"，再进入Skill②。
坑二：SKILL.md的description写得太空
Description是AI判断"什么时候启用这个Skill"的唯一依据。写"帮助测试"这种描述，AI永远不知道什么时候该用它。
解法：Description要写清楚"触发条件"。比如："当用户提到'生成测试用例''编写测试''测试覆盖''测试场景'等意图时触发此技能"。
坑三：忽略了Skill的"渐进式披露"优势
很多人把Skill当成"把一堆内容塞进去就行"，结果Skill文件越来越大，每次加载都消耗大量上下文。
解法：利用Skill的"渐进式披露"设计——SKILL.md只放核心指令，大段参考资料放到references/目录下，脚本放到scripts/目录下。AI只在需要时才加载这些附加内容。
坑四：只建Skill，不迭代
Skill不是一次建完就完事了。业务在变、需求在变、历史Bug在变——Skill也需要持续更新。
解法：建立Skill的"反馈闭环"——每次使用后记录"AI漏了什么场景""哪里判断错了"，定期用这些反馈更新SKILL.md。
最后
传统测试的底层资产是"测试用例库"——用例是一次性的，用完就扔。
AI时代的底层资产正在变成"Skill库"——Skill是可组合、可复用的能力单元。
一个Skill封装的不只是一个具体输入输出，而是一种"做某件事的方法"。你今天花30分钟写了一个"需求拆解"的Skill，以后每一个项目都能复用。你今天花20分钟写了一个"用例生成"的Skill，以后每一个功能都能调用。
Skill不是让你"少干活"，是让你"把经验留下来"。
下次你拿到一份需求文档的时候，别从零开始写用例了。花点时间，把四个Skill搭起来。
2小时后，你会看到一份比你想象中更全的用例集。
而你写的那些Skill，会在未来的每一个项目里，继续替你干活。
