有人问过我一个问题："你们用 AI 生成测试用例，质量真的过关吗？"
我当时的回答是："取决于你怎么用。"
这个回答听起来像在回避，但它恰恰是这件事的核心。很多团队尝试用 AI 生成测试用例，最终以失望收场------不是因为 AI 不够聪明，而是因为他们把一件需要设计的事情，当成了一件只需要"问一句"的事情。
Skills 驱动的测试用例生成，和"把需求文档丢给 ChatGPT 让它写用例"，是两件完全不同的事。前者是一套工程化的方案，后者是一次碰运气的实验。
这篇文章想做的，是把前者讲清楚------不只是"能做什么"，更是"怎么做、做到什么程度、踩过哪些坑"。
一、为什么"直接问 AI"行不通
在讲方案之前，我们先把反面案例说清楚，因为很多人正在重蹈这个覆辙。
典型的错误用法是这样的：把一份 PRD 或接口文档复制粘贴给 AI，然后问："帮我写这个功能的测试用例。"
AI 会给你一份看起来很完整的用例列表。格式整齐，场景分类清晰，正向负向都有。然后你发现：
-
边界值不对------AI 不知道你们系统的数值约束
-
业务逻辑有误------AI 不了解你们特有的规则（比如某个状态只有 VIP 用户才能触发）
-
缺少历史高频缺陷场景------它不知道你们踩过什么坑
-
格式无法导入工具------和你们的测试管理平台完全对不上
问题的根源在于：AI 没有你们团队的上下文。它给你的，是一份基于通用常识的用例，而不是基于你们业务的用例。
**Skills 解决的正是这个问题。**它的本质，是把你们团队的上下文、业务规则、历史经验，结构化地注入 AI 的判断逻辑里。
二、Skills 方案的整体架构
在动手之前，先建立一个整体视图。一套可落地的 Skills 测试用例生成方案，由三个层次组成：
输入层决定了 AI 能"看到"什么。输入越结构化、越完整，输出质量越高。
Skills 层是核心。它决定了 AI 用什么逻辑来处理输入、生成什么样的输出。这是需要投入最多设计精力的地方。
输出层决定了生成结果能否真正进入工作流。格式不对，一切都是空谈。
接下来，我们逐层拆解。
三、输入层：给 AI 喂什么，比让 AI 做什么更重要
3.1 结构化接口文档
最理想的输入是 OpenAPI（Swagger）格式的接口文档。它天然包含了参数名称、类型、是否必填、枚举值、示例值等信息，AI 可以直接解析并推导测试场景。
如果你们没有维护 OpenAPI 文档，退而求其次，可以提供以下信息的组合：
XML
接口名称：用户登录
请求方法：POST
路径：/api/v1/auth/login
请求参数：
- username（string，必填，长度 6-20，仅允许字母数字下划线）
- password（string，必填，长度 8-16，需包含大小写和数字）
- captcha（string，选填，登录失败 3 次后必填）
业务规则：
- 连续失败 5 次，账号锁定 30 分钟
- 同一 IP 每分钟最多 10 次请求
- 密码错误不返回具体原因（安全要求）注意最后的"业务规则"部分------这是大多数人遗漏的关键。接口文档描述的是"怎么调用"，业务规则描述的是"什么情况下怎么处理"。两者都要给到 AI。
3.2 历史缺陷数据
这是一个经常被忽视的宝贵输入。把过去在这个模块出现过的线上 Bug 或测试中发现的高频缺陷，以结构化方式提供给 Skills：
XML
历史高频缺陷（登录模块）：
1. captcha 字段为空字符串时，系统未触发验证码校验
2. username 含空格时，系统报 500 而不是参数错误
3. 并发登录场景下，锁定计数出现竞争条件，未正确锁定Skills 会将这些缺陷模式纳入推理逻辑，确保生成的用例优先覆盖历史高风险场景。
3.3 代码变更 diff（适用于回归场景）
如果是版本发布前的回归测试，把 Git diff 作为输入，让 Skills 识别变更范围，推荐需要回归的用例集合。这个能力在 CI/CD 流程里价值极高。
四、Skills 层：这才是真正需要设计的地方
4.1 一个 Skill 的基本结构
一个有效的测试用例生成 Skill，通常包含以下四个部分：
角色定义：告诉 AI 它是谁，建立判断的基准视角。
推理规则：明确它应该用什么逻辑来分析输入、推导场景。这是 Skill 的核心，也是注入团队经验的地方。
覆盖清单：列出必须覆盖的场景类别，作为检查点。
输出规范：定义用例的格式、字段、优先级标准，确保输出可以直接进入工具链。
4.2 一个完整的 Skill 示例
以接口测试为例，下面是一个可以直接使用的 Skill 配置：
XML
## 角色定义
你是一名有 5 年经验的接口测试工程师，熟悉 RESTful API 测试方法论，
对边界值分析、等价类划分、场景组合有深入理解。
## 推理规则
当我提供接口定义时，按以下步骤分析：
1. 参数分析
- 逐字段识别类型、约束、必填性
- 对字符串类型：识别长度限制、格式约束、特殊字符敏感性
- 对数值类型：识别范围约束、精度要求、边界值
- 对枚举类型：识别所有合法值及非法值场景
2. 业务规则分析
- 识别有状态逻辑（如锁定、限流、权限校验）
- 识别多步骤依赖场景（如需要先登录才能调用）
- 识别并发敏感场景
3. 安全场景分析
- SQL 注入（字符串参数）
- 越权访问（涉及用户隔离的接口）
- 重放攻击（涉及支付、核销等高风险操作）
4. 历史缺陷场景
- 将提供的历史缺陷模式转化为具体用例，标注来源
## 覆盖清单（每个接口必须覆盖）
- [ ] 正常路径（典型业务场景，至少 2 条）
- [ ] 必填参数缺失
- [ ] 参数类型错误
- [ ] 边界值（最大值、最小值、边界±1）
- [ ] 空值和空字符串
- [ ] 业务规则触发场景
- [ ] 安全场景（视接口类型选择）
## 输出规范
以 Markdown 表格输出，包含以下字段：
| 用例编号 | 场景描述 | 前置条件 | 请求参数 | 预期状态码 | 预期响应体关键字段 | 优先级 |
优先级规则：
- P0：核心业务路径 + 安全场景 + 历史高频缺陷
- P1：主要异常场景 + 边界值
- P2：低频异常 + 边界±1 场景4.3 针对不同测试类型的 Skill 变体
一个 Skill 不能通吃所有场景。根据测试类型，你需要设计不同的变体：
功能测试 Skill：侧重业务路径覆盖，输入以 PRD 和用户故事为主，输出包含操作步骤和预期页面状态。
接口测试 Skill：如上示例，侧重参数组合和边界值，输入以接口文档为主，输出包含请求参数和响应断言。
回归测试 Skill：侧重变更影响范围识别，输入以 Git diff 和模块依赖图为主，输出包含推荐回归用例集合和跳过理由。
性能测试 Skill：侧重并发场景和压力边界，输入以接口 SLA 要求为主，输出包含测试场景和监控指标。
五、一个完整的实战案例
纸上谈兵不够，我们用一个真实场景走一遍完整流程。
场景背景
某电商平台，商品加入购物车接口，近期发生了两次线上问题：一次是同一商品加了两次但库存只扣了一次（并发问题），一次是限购商品未校验用户已购数量就允许加车（业务规则漏洞）。
第一步：准备输入
XML
接口：POST /api/v1/cart/add
请求参数：
- user_id（string，必填）
- sku_id（string，必填）
- quantity（integer，必填，范围 1-99）
业务规则：
- 同一用户同一 SKU 加车后，购物车数量累加（不新增行）
- 部分 SKU 有限购规则（最大购买数量存于 sku_limit 字段）
- 库存不足时返回具体的可购数量提示
- 已下架商品不可加车
历史缺陷：
1. 并发加车场景下，库存扣减出现竞争条件
2. 限购校验未考虑购物车已有数量，只校验本次 quantity第二步：调用 Skill，生成用例
Skill 处理后，输出以下用例（节选关键部分）：
| 用例编号 | 场景描述 | 请求参数 | 预期状态码 | 预期响应关键字段 | 优先级 |
|---|---|---|---|---|---|
| TC-001 | 正常加车：有库存商品，数量合法 | sku_id="A001", quantity=1 | 200 | cart_count +1 | P0 |
| TC-002 | 并发：同一用户同一 SKU 并发 10 次请求 | 并发请求，quantity=1 | 200 | 库存扣减总量 = 10，无超扣 | P0 |
| TC-003 | 限购校验：购物车已有 3 件，再加 3 件超出限购 5 件 | cart 已有 3，quantity=3 | 400 | error_code="LIMIT_EXCEEDED" | P0 |
| TC-004 | 已下架商品加车 | sku_id="已下架SKU" | 400 | error_code="SKU_OFFLINE" | P0 |
| TC-005 | 库存不足：请求数量超过库存 | quantity=100，库存=50 | 200/400 | available_stock=50 | P1 |
| TC-006 | quantity 为 0 | quantity=0 | 400 | 参数错误 | P1 |
| TC-007 | quantity 为 100（超出上限） | quantity=100 | 400 | 参数错误 | P1 |
| TC-008 | sku_id 包含 SQL 注入字符 | sku_id="' OR 1=1--" | 400 | 安全过滤生效 | P0 |
注意 TC-002 和 TC-003------这两条正是基于历史缺陷生成的，Skill 自动将缺陷模式转化为了可执行用例，并标注为 P0 优先级。
第三步：人工审查，补充上下文
人工审查发现：TC-005 的预期结果写了"200/400"，说明 Skill 不确定库存不足的返回码。这是一个需要人工补充的业务规则------查阅文档后确认应返回 200，并在响应体里包含 available_stock 字段给前端展示。
同时，审查者补充了一条 Skill 没有生成的场景：用户账号被风控封禁时尝试加车------这是一个和账号状态有关的前置条件，Skill 没有"读过"相关的风控文档，所以没有覆盖。
这正是人工审查的价值：补充 Skill 上下文之外的场景。
第四步：迭代 Skill
把"账号风控状态"这个维度补充到 Skill 的推理规则里，下次这个 Skill 处理同类接口时，会自动考虑这个场景。
六、落地过程中的三个真实障碍
障碍一：团队习惯"直接问"，不愿意设计 Skill
这是推广阶段最常见的阻力。大家觉得"先设计 Skill 再生成"比"直接问 AI"更麻烦，为什么不直接问？
破局方式：用数字说话。统计"直接问"的用例，人工修改的比例是多少；统计 Skill 生成的用例，人工修改的比例是多少。通常这个数字的差距，足以让团队改变习惯。
障碍二：Skill 覆盖率随时间下降
业务在演进，但 Skill 没有同步更新。三个月后，Skill 生成的用例开始遗漏新加的业务规则。
破局方式：把 Skill 更新纳入需求评审流程。每次新需求上线前，评估是否需要更新对应的 Skill。让 Skill 维护成为研发流程的一部分，而不是测试团队的额外负担。
障碍三：输出格式和工具链对不上
生成了很好的用例，但无法导入 Jira 或 TestRail，只能手动复制，反而增加了工作量。
破局方式：在 Skill 设计阶段，就把输出格式和工具链的导入格式对齐。TestRail 支持 CSV 导入，Jira 支持特定 JSON 格式------把这些格式要求写进 Skill 的输出规范，一步到位。
尾声：这不是银弹，但它是目前最接近银弹的东西
我不想给你一个"用了 Skills 就能解决一切"的结论，因为那不是真的。
Skills 生成的用例，仍然需要人工审查。Skills 本身，仍然需要持续维护。深度的业务判断，仍然需要有经验的测试工程师来做。
但它确实在改变一件事：生产测试用例这件事，正在从"人做"变成"人把关"。
这个转变的意义，不只是效率提升。它让测试工程师从一个不断重复的生产者，变成一个持续优化系统的设计者。你写的不再是用例，而是生成用例的规则。你积累的不再是文档，而是可以复用的判断逻辑。
这是一种更有意思的工作方式。
如果你在实际落地中遇到了具体的问题，欢迎在评论区描述你的场景，我们一起讨论解决方案。