测试必学：推荐4个测试用例设计最值得掌握的Agent Skill，几乎覆盖所有用例设计场景！

做软件测试的朋友都清楚，测试用例设计有多么重要。它直接决定了测试覆盖是否全面，也直接影响了后续整体测试流程的质量。

传统模式下，大家手动一条一条编写用例，不仅耗时费力，还经常因为考虑不周，漏掉异常场景、边界条件，给线上质量埋下隐患。

如今借助 AI + Agent Skill 能力，我们可以把用例设计的标准化流程、通用规则封装为可复用技能。这样一来，测试人员就能从机械重复的编写工作中抽离出来，把更多精力放在业务分析、风险识别等高价值工作上。

并且在 AI 赋能测试的各类场景中，测试用例设计是入门门槛最低、落地效果最直观的场景，它规则清晰、模板统一、重复工作量大，特别适合用AI技术来提效。

结合多个真实项目的落地经验，我提炼出了四款核心 Agent Skill ，搭建起一套「需求拆解 → 用例生成 → 场景补全 → 质量评审」的完整用例设计全流程闭环。

今天把这四个Skill分享给大家。

可以这样说，掌握了这套Agent Skill技能组合，日常绝大多数的用例设计工作都能轻松搞定，实测下来，几乎能适配所有用例设计场景。

目前这套用例设计Skill技能组合，「狂师 . AI进化社」的成员都在使用，很多同学都表示，测试用例设计效率比原先提升了至少5～10倍以上了。

1. 传统测试用例设计的核心痛点

在需求分析完成、进入测试执行前，测试用例设计是保障测试覆盖度、发现缺陷效率、回归质量可控的核心前置环节。

行业通用的传统用例设计流程大致如下：

bash 复制代码

理解需求文档 → 梳理测试点 → 编写设计测试用例 → 用例评审与优化 → 定稿或导入到测试管理平台 (可选)

flowchart LR A $理解需求文档$ --> B $梳理测试点$ B --> C $编写设计测试用例$ C --> D $用例评审与优化$ D -->|评审不通过| C D -->|评审通过| E $定稿或导入到测试管理平台$

而回到真实的日常项目场景里，我们会发现一个普遍痛点：即便需求文档已经相对完善，从需求到用例的转化过程仍然高度依赖测试工程师的个人经验和思维深度。

还是以我们熟悉的电商购物车模块为例，需求文档可能已经给出了用户故事的完整描述：

US-005：用户将商品添加到购物车

参与者：已登录用户

前置条件：用户已登录，商品处于上架状态

主流程：1. 用户浏览商品 → 2. 点击"加入购物车" → 3. 系统校验库存 → 4. 商品加入购物车 → 5. 提示添加成功

异常情况：库存不足时提示"库存不足"

这样一个需求用户故事，看似清晰，但转化成测试用例时，测试工程师需要手动完成以下工作：

提取测试点：从用户故事中识别出所有需要验证的功能点
划分等价类：对输入条件进行有效/无效等价类划分
确定边界值：找出所有边界条件（数量边界、金额边界、字符长度边界等）
设计正反向用例：覆盖正常路径、异常路径、边界路径
补充交叉场景：多条件组合、并发操作、状态迁移等
标注优先级：区分 P0/P1/P2 优先级
格式化输出：按照团队模板整理成标准用例文档

如果完全依靠人工，这个过程步骤繁琐、规则固定、重复性极高，且极度依赖测试工程师的经验水平。新手容易遗漏边界值和异常场景，老手虽然经验丰富，但面对大量需求时同样会疲劳出错。

很多后期线上缺陷，根源都是测试用例设计阶段考虑不全------边界值没覆盖、异常场景遗漏、业务规则交叉点未验证。这也是测试工程师日常最消耗精力、最容易出错的环节。

2. 测试用例编写的三种形式

据我观察，在实际测试工作中测试用例的编写形式，也会影响团队协作效率、用例质量、评审成本与维护成本。

目前国内绝大多数测试团队，使用的用例编写载体基本可以归纳为三种主流形式：

XMind 思维导图
Excel 标准化表格
测试管理平台

三种方式各有适用场景、优势与明显短板，也直接决定了 AI + Agent Skill 该如何切入、如何赋能。

2.1 XMind 思维导图式用例

以 XMind、ProcessOn 这类思维导图工具编写测试用例，是很多敏捷团队、小团队、快速迭代项目最常用的方式。

优点：

思维不受限，发散性强：不用被固定字段束缚，想到什么测试点就挂什么节点，思路流畅、梳理快。
结构层级清晰：模块→子模块→功能点→测试点，一眼看清整体覆盖范围。
上手成本极低：不用学模板、不用填大量字段，适合快速梳理测试思路。
适合需求评审、测试设计初期：用来脑暴、拆点、对齐范围非常高效。

缺点：

难以统一规范：每个人的层级、命名、粒度、标注方式完全不同，团队协作成本高。
信息表达有限：很难完整承载 "前置条件、操作步骤、预期结果、优先级、数据、备注" 等完整用例信息。
不利于执行与统计：无法直接统计用例数、通过率、覆盖率，执行时不方便勾选、记录结果。

我的建议：

XMind 更适合做测试点梳理、测试范围对齐、脑暴场景 ，不太适合作为最终可执行、可管理、可追溯的正式用例载体。

2.2 Excel 标准化表格用例

Excel 是目前中大型团队、传统项目、质量管控严格项目最主流的正式用例载体。团队通常会先统一一份《测试用例模板》，所有人必须按固定字段、固定规范填写。

典型字段一般包括：用例编号、模块、用例标题、优先级、前置条件、操作步骤、预期结果、测试数据、备注、作者等。

优点：

格式高度统一：团队输出一致，评审、交接、维护都非常规范。
信息完整可执行：能承载完整用例信息，测试人员拿到就能直接执行。
便于统计与复盘：可筛选、排序、计数、统计覆盖率。
便于 AI 赋能：结构固定、规则清晰，非常适合 Agent Skill 自动生成、自动补全、自动审查。

缺点：

编写效率低、重复劳动多：复制粘贴、填格式、调样式非常耗时。
思维容易被模板束缚：一开始就要填大量字段，不利于发散思考。
协作不便：多人同时编辑容易冲突，不支持在线实时协同。

我的建议：

Excel 是正式用例交付的最佳载体，也是 AI 最容易标准化赋能的格式。

2.3 测试管理平台 / 测试系统用例

现在越来越多团队使用禅道、TestLink、Jira、Tapd、腾讯云测、自研平台等编写用例。

本质上：

它只是把 Excel 的表格结构搬到了网页上，包装了界面、权限、流程、协同能力，本质导出后依然是 JSON、Markdown、Excel 结构。

优点：

在线协同、版本管理、权限管控
支持用例执行、缺陷联动、统计报表
便于流程化、规范化管理
支持与自动化、CI/CD 打通

缺点：

平台重、操作步骤多，快速梳理测试点不如 XMind 流畅。
不同平台字段不统一，AI 适配成本略高。

我的建议：

测试平台适合项目管理、流程管控、质量统计 ，但测试设计阶段依然离不开 XMind + Excel 的组合。

2.4 我的建议

三种用例形式没有绝对好坏，只有在什么场景下，谁更多适配：

XMind ：更适合快速拆解测试点、范围对齐、思维发散
Excel ：更适合正式交付、标准化、AI 赋能、团队统一
测试平台 ：更适合执行管理、协同、统计、流程管控

而 AI + Agent Skill 的最佳切入方式，就是：

先用 XMind 思维梳理测试点 → 再由 AI 生成标准 Excel 测试用例 → 再用 AI 补全遗漏场景 → 最后用 AI 评审质量，形成完整提效闭环。

3. 测试用例设计 Agent Skill 全流程

测试用例设计Skill 全流程中共包含了四个Skill：

3.1 generator-testcase-xmind（思维导图版测试点生成）

该 Skill 基于需求用户故事系统化拆解测试点，自动提取全维度测试点，并按功能、边界值、异常、业务规则、非功能五大维度分类，最终输出 XMind 思维导图格式的测试点清单，解决人工梳理测试点不全面、层级混乱的问题。

特别适合以下场景：

需求评审前快速梳理测试范围
敏捷团队快速拆解需求、输出测试点，与产品/开发对齐测试范围；
测试设计初期的场景脑暴、测试点全覆盖校验；
新人快速上手需求拆解，降低经验依赖。

generator-testcase-xmind 技能的工作流程分为五步：

接收与解析用户故事 --- 支持直接输入文本或读取 .docx/.txt 文档，提取编号、标题、描述和关键功能点
系统化拆解测试点 --- 按五大维度逐一拆解：
- 功能测试（正常流程、分支流程）
- 边界值测试（等价类划分+边界值分析）
- 异常测试（错误输入、系统异常、网络异常）
- 业务规则测试（逻辑约束、状态转换）
- 非功能性测试（性能、安全性、兼容性）
标注优先级 --- P0（阻塞主流程）/ P1（重要功能异常）/ P2（边缘场景）
构建 JSON 数据 --- 按规范格式整理，测试点编号全局连续
生成 XMind 文件 --- 调用 generate_xmind.py 脚本，输出 .xmind 格式思维导图

使用方式很简单：用户只需要提供用户故事后，技能会自动触发，完成测试点拆解并生成可直接用 XMind 打开编辑的思维导图文件，接下来，我们来测试验证一下 Skill 效果。

第一种：以文本的形式输入需求来验证：

「输入」 ：以 shop-lab 项目中"用户注册"功能的用户故事为例

US-001：用户通过手机号注册

参与者：未注册用户

前置条件：用户未注册，手机号未被占用

主流程：1. 进入注册页面 → 2. 选择手机号注册 → 3. 输入手机号 → 4. 获取验证码 → 5. 输入验证码 → 6. 设置密码 → 7. 点击注册 → 8. 注册成功，自动登录并跳转首页

替代流程：无

后置条件：用户注册成功，系统自动登录

异常情况：

手机号格式错误：提示"请输入正确的手机号"

手机号已注册：提示"该手机号已注册，请直接登录"

验证码错误：提示"验证码错误，请重新输入"

验证码过期：提示"验证码已过期，请重新获取"

密码不符合要求：提示"密码至少8位，包含字母和数字"

打开任意AI Agent工具，比如此处用Workbuddy（当然，你想用Claude Code或Codex也都是可以的），点击技能 ->选择generator-testcase-xmind这个技能。

输入用户故事，点击执行，workbuddy会自动读取generator-testcase-xmind技能的SKILL.md文件，并按照技能预定的工作流程来将用户输入的需求用户故事拆解为测试点。

最终，基于用户手机号注册这个需求故事点，该技能自动帮我们生成了27个测试点，159个子测试点。

打开xmind测试点文件，内容很详细，检查了一下，整理质量效果还不错。

第二种：以docx需求文档的形式输入验证：

上传 shop-lab 项目的需求用户故事 docx 文档，调用技能：

bash 复制代码

/generator-testcase-xmind
请读取该文档中的用户故事，生成对应的测试用例，并输出到xmind文件中。

发送执行，workbuddy会先读取文档中的需求用户故事，然后按照技能流程系统化拆解所有测试点，生成JSON数据并输出为xmind文件。

从workbuddy用例统计结果可知，shop-lab电商系统，包含了30个需求用户故事，总共生成了458条测试点。

打开xmind测试用例，看了一下，生成的测试点还是非常详细的。（细心的你，应该还会发现，在xmind测试用例中每个测试点还会关联对应的用户故事编号，方便测试工程师知道每个测试点对应测试的是哪个需求，很贴心吧）

温馨提醒 ：xmind测试用例生成好之后，人工需要验证一下，若发现用例粒度不合理、场景遗漏等问题，可直接向 AI 提出优化要求，AI 会自动更新 SKILL.md 内容。

3.2 generator-testcase-excel（标准化测试用例生成）

测试点提取完成后，下一步可以将每个测试点展开为详细的、标准的、可执行的excel版测试用例。

但这一步，根据现实不同的团队现状，又可进一步细分为两种场景：

第一种，是基于上一步生成的测试点（xmind格式），生成详细的excel版测试用例。
第二种，是基于原始的需求用户故事（docx格式），生成详细的excel版测试用例。

因此该技能，主要是基于 XMind 测试点或原始需求用户故事，自动生成符合团队规范的 Excel 标准化测试用例，完整覆盖等价类划分、边界值分析、异常场景设计，解决人工编写用例格式不统一、重复劳动多的问题。

该技能特别适合以下场景：

中大型团队正式用例交付、用例库标准化建设；
批量需求的用例快速生成，提升交付效率；
测试管理平台（禅道、TestLink 等）的用例快速导入。

在技能列表中，选择技能：generator-testcase-excel

这里为了加快验证速度，我们就只选择两个最常用的场景：

基于xmind测试点文件，生成excel版完整测试用例
基于需求用户故事文档，生成excel版完整测试用例

1、第一种：基于xmind测试点文件，生成excel版完整测试用例

点击执行，稍等一会，workbuddy共帮我们生成了308条完整的测试用例，并且在测试用例总览中，还会罗列出各分类维度、不同优先级用例数量占比分布。

如果想查看excel版测试用例，可以直接在任务制品中打开excel文件

也可以进入到工作目录中，单独打开：

2、第二种：基于docx需求用户故事文件，生成excel版完整测试用例

点击执行，基于需求用户故事共生成了211 条测试用例。

同样的，如果想查看excel版测试用例，可以直接在任务制品中打开excel文件或者也可以进入到工作目录中，单独打开：

3.3 safe-testcase（高频遗漏场景智能补全）

通过前两个 Skill 生成的测试用例，通常已经可以稳定覆盖 90% 左右的常规功能场景，能够满足基础的功能验证与流程测试。

但在实际项目中，线上问题、回归 Bug、隐蔽缺陷 往往并不出现在正向主流程里，而是集中在非功能性场景、极端边界条件、历史高频线上 Bug、业务隐藏规则等人工最容易疏忽、AI 默认不会主动生成的薄弱区域。

这些场景恰恰是决定测试完整性、保障线上质量的关键。

因此，在基础用例生成完成后，safe-testcase这个技能则是专注于 "查漏补缺" 的 Skill。专门用来 补全易遗漏场景、还原历史高频 Bug、补齐非功能与边界用例，让整体用例覆盖更完整、更严谨、更具备防故障能力，真正做到从 "可用用例" 升级为 "可上线用例"。

该技能，适合用在以下场景：

用例质量校验、评审前的场景补全；
历史 BUG 回归用例补充；
高风险模块（支付、登录、核心交易）的用例强化。

接下来，我们来测试验证一下效果：

1、上传excel版测试用例，验证测试用例补全效果

从技能列表中选择safe-testcase技能。

上传excel版测试用例文件，以及提供项目历史高频BUG列表（建议直接从BUG管理系统中导出项目历史BUG记录作为数据喂给AI）、补充业务特定规则（按需，有就提供，非必须）

点击执行，等待workbuddy返回结果：

从测试用例补全的结果可知，此次我们共补全了50条用例，从原先的211条用例，通过补全后增加到了261条。并且还对补全后的用例分类和优先级进行了划分。

打开Shop-Lab电商系统-测试用例（用户故事版）【场景补全版】.xlsx 文件，如下图所示，在文件中最右侧新增了一列：「补充标识」，这样就方便过滤的同时，也不会影响到原有测试用例的描述了。

2、上传xmind版测试点，验证测试点补全效果

从技能列表中选择safe-testcase技能，上传xmind版测试点文件，以及提供项目历史高频BUG列表（建议直接从BUG管理系统中导出项目历史BUG记录作为数据喂给AI）、补充业务特定规则（按需，有就提供，非必须）

将提示词发送给workbuddy后，根据11个检查维度进行系统性分析，并进行测试点补全。从统计结果可知，最终测试点从原先的599条测试点，新增补全了48条，补全后最终为647条测试点。

并且，在xmind中，补全测试点时，会以labels的方式显示"Al补全-场景遗漏"，既保证了标题干净，可在XMind中按label过滤查看。

进入到workbuddy工作目录：

双击打开Shop-Lab电商系统-测试点分析【场景补全版】.xmind 文件，在xmind文件中，我们可以看到新增补全的测试点，都会自动带上一个名为"Al补全-场景遗漏"的labels显示。

到了这一步，我们已经跑通了AI + Agent Skill 赋能测试用例生成流程 ：既能快速生成XMind 测试点 与Excel 标准用例 ，也能结合项目历史高频 BUG 与业务专属规则，自动完成易遗漏场景的深度补全。

3.4 review-testcase（用例质量量化评审）

利用 AI 赋能，确实能帮我们快速生成大量、覆盖度极高 的测试用例，效率远超人工数倍。但这里有一个非常重要的认知：用例多，不代表全部可用、好用、值得执行。

AI 生成的用例，天然存在这些特点：

会生成冗余、重复、无业务价值的用例
会出现粒度太细、无法执行、不符合团队习惯的用例
会混入超出当前迭代范围、优先级极低的场景
无法自主判断业务重要性、执行成本、回归价值

所以，我们绝对不能只追求 "用例数量多"，更不能直接把 AI 输出的全部用例拿去执行。AI 产出的用例从来不是拿来就用、全部可用，必须经过人工把关。

真正成熟的做法是：

对 AI 生成的用例进行分级、分类、筛选、去重 ，并建立可量化的统计标准 （如覆盖率、有效率、冗余率、高优先级占比），只保留高价值、可执行、符合业务目标的用例。

我的建议是将 AI 生成的用例分为三类：

第一类（可用）：标准正向用例，常规流程、基础操作，可直接入库
第二类（待修改）：待修改用例 ，逻辑方向对，但描述或数据需要调整，这类不用直接删掉，人工微调后就能复用
第三类（错误/无效）：直接废弃用例 ，业务逻辑错误、与需求不符、完全脱离实际业务、无法执行，这类直接剔除

除了用例分级分类外，还需建立核心指标进行量化校验。（具体量化指标，看图即可）

因此，review-testcase 这个Skill技能的作用，就是对 AI 生成的测试用例进行分类分级、并会从5个维度进行综合评审打分，再结合 7 项量化指标进行统计。

同样的，我们来验证一下技能的实测效果，在技能列表中，选择review-testcase 技能

上传excel版测试用例，验证测试用例评审效果

点击执行，调用review-testcase技能，会先自动读取excel文件中的测试用例，然后将全部的用例导出为结构化的json数据，再分批评审。

由于用例数量较多，workbuddy在执行用例评审时，会启动4个并行的评审Agent，对261条用例进行并行评审。

等待一会后，261条用例全部评审完毕，其中直接可用的用例占比为26.4%，待修改的用例占比为51.7%，错误无效的用例为21.8%。

问题主要的内容集中在：

预期结果模糊（~80条）："页面展示正确""数据状态正确"等不可验证表述
空引号「」（~75条）：提示信息为空，缺少具体内容
步骤与标题不匹配（~20条）：标题测A功能，步骤却是B功能
模板式填充（~25条）："执行触发xxx的操作"等占位符，无法执行

打开最终评审版用例，可以看到每条用例都会有详细的用例分类，详细评分、以及扣分原因和改进建议。

还可以查看到评审汇总后的信息

并且还会输出一份用例评审报告（markdown格式），在用例评审报告中，详细记录了各维度的用例评审得分情况、问题根因分析、改进建议等。

我们先抛开部分指标得分偏低的问题 ------ 其实这一点完全在预料之中。AI 初次评审时出现得分不高，是非常正常的现象。

是用例颗粒度太粗？是场景缺失？是优先级不合理？还是原始需求描述不够清晰？

找到原因后，我们只需要针对性做两件事：

优化 Skill 内部的评审规则、判断逻辑、评分标准
或进一步细化、完善原始需求文档

经过几轮迭代调整，最终这套评审技能能达到的整体用例校验效果、质量把关能力依然非常出色，完全可以胜任团队日常用例质量评审工作。

4. 写在最后

需要注意，AI 永远替代不了人的业务经验，核心场景必须由人来把关。

虽然 AI 可以帮我们批量生成、快速补全、标准化校验，但它不懂业务背景、不懂历史坑点、不懂线上风险。真正关键的核心流程、高风险业务、复杂业务规则，最终还是要靠测试工程师的经验来判断、来兜底、来拍板。

甚至，我们还可以联动上一篇教程中需求分析阶段搭建好的各类 Skill，实现跨环节协同作业。

将全部 Skill 按照业务流程依次串联调用，从原始需求解析、用户故事结构化、用户故事质量校验，到 XMind/Excel 用例生成、场景补全、质量评审，全链路打通，一键输出最终可用的高质量测试用例，形成一套完整的测试用例自动化生产闭环，实现测试用例全流程自动化提效。

详细的AI测试手把手实战开发教程及完整设计思路、Agent Skill项目源码，在「狂师 . AI 进化社」中可免费学习获取。