我做了个Skill，专门用来自动生成测试用例：一个测试Agent的诞生

目录

一、现象：测试设计正在成为瓶颈
二、本质变化：从“人工设计”到“智能体生成”
三、核心机制拆解：一个测试用例生成Skill的五个关键设计
四、典型案例对比：人工 vs Skill，差距在哪
五、工程落地启示：你的团队也能复制
六、趋势判断：测试工程师的角色会怎么变

一、现象：测试设计正在成为瓶颈

先说说那个让我崩溃的下午。

说实话，这个工具是被逼出来的。那天手里压着两个版本的需求，截止时间是下午五点。一份文字需求，一份原型图，加起来七八十页，从头写测试用例。我当时的感受是：这玩意儿凭什么要人手工做？

做过测试的应该都懂那种感觉——业务逻辑要反复看，边界值要一个个算，场景流要慢慢梳理，然后还得在XMind里一个节点一个节点地敲进去。一份中等复杂的需求，快的一两小时，慢的大半天就没了。

更烦的不是耗时，是那些“重复的愚蠢”：上周刚问过产品某个模糊需求怎么理解，这周换了个文档，同样的问题又得问一遍。优先级怎么定？每次都靠感觉，P0和P1混在一起，分布飘忽不定。某些场景几乎每次都忘——弱网重试、空列表状态、文件上传边界值——不是不知道，就是在赶时间的时候会漏。

很多人已经开始感觉到：测试设计的瓶颈不在执行，不在工具，在设计本身。而设计这件事，目前大部分还是靠人工堆时间。

我当时就想，AI整天说能替代人了，怎么就没人做一个真的能接手这件事的工具？不是那种给你列几个测试点的半成品，而是真正端到端——进来需求，出来一份可以直接导入XMind的完整用例文件。

于是自己动手做了。

二、本质变化：从“人工设计”到“智能体生成”

传统的测试用例生成，本质上是一个翻译加枚举的过程：人读需求，人脑调用测试设计方法，人手工录入。瓶颈在于人脑的工作记忆有限，而且容易疲劳、遗漏。

现在AI Agent介入之后，变化的核心不是“生成速度快了”，而是设计过程被结构化、可重复、可自检。

这个Skill做的事情，不是把需求丢给GPT让它随便写几句，而是把一个有经验的测试工程师的思维过程——方法选择、边界计算、场景梳理、风险推测——编码成了一个可执行的智能体工作流。

本质是：把测试设计这个“隐性知识”变成了“显性流程”。

这个变化带来的直接结果：测试设计从“手艺活”变成了“配置活”。

三、核心机制拆解：一个测试用例生成Skill的五个关键设计

这个Skill不是简单的“需求→LLM→用例”。它内部有五个核心模块，按顺序执行。

1｜四种测试设计方法，有序叠加

很多AI工具给出的测试用例，就是把需求复述一遍，加个“验证一下是否正确”。这不叫测试设计，这叫翻译。

这个Skill内置了测试领域真正在用的四种方法，按顺序叠加执行：

• 等价类划分：把所有输入划分成有效区间和无效区间，不遗漏，不重叠。
• 边界值分析：上限、下限、临界点，一个个算出来，而不是靠感觉“试试边界”。
• 场景法：完整梳理基本流、备选流、异常流，业务主线和每一条分支都要覆盖到。
• 错误推测：高风险模块补充特殊字符、极端值、并发场景，把最容易出BUG的地方重点照顾。

四种方法不是随机调用，而是有顺序地叠加，最终生成的用例集是一个有结构、有层次的整体。

观点句：测试设计不是翻译需求，而是构造有效验证。

2｜多模态：从图片里读场景

很多时候需求根本没有文字，来的就是一张Figma截图、一张原型图、或者一张画满箭头的业务流程图。以前遇到这种情况，我得自己先把图“翻译”成文字，再去写用例，相当于多做了一遍工。

现在把图片直接丢进去就行了。工具会用多模态能力读取图片内容：

• UI设计稿 → 识别页面元素、输入框、按钮、状态文案 → 生成表单验证和交互用例
• 流程图 → 识别分支条件、步骤顺序、异常路径 → 生成完整的场景流用例
• 规则表格截图 → 识别枚举值和条件组合 → 生成等价类和边界值用例

图片和文字可以同时放进去，工具会交叉对照，补全单独依赖任何一方都可能漏掉的场景。

3｜质量预审：不合格不放行

AI生成测试用例最让人不放心的地方不是慢，而是你不知道它漏了什么。生出来一堆用例，覆盖率其实只有60%，优先级全堆在P2，P0寥寥无几——这种结果比没有还烦人，因为你还得去检查。

工具在正式生成之前会跑一轮质量预审，逐项核查：

• 需求覆盖率是否达到95%以上
• P0占比是否在合理区间（10–15%）
• P1占比是否达标（30–40%）
• 每条需求是否至少关联了一种测试设计方法
• 有没有凭空编造需求文档里不存在的场景
• 有没有语义重复的用例

六项全过，才进入生成阶段。任何一项不达标，先自动修正，改完再输出。整个过程你只需要在两个检查点确认一下，其余全自动。

观点句：AI生成用例最大的问题不是慢，而是你不知道它漏了什么。

4｜记忆机制：越用越懂你

这部分是我花时间最多的地方，也是让它从“能用”变成“好用”的关键。

第一次用完之后，Skill会在项目里创建一个.memory/文件夹，把这些东西记下来：

• 你做过的歧义判断：某个模糊需求你怎么理解的，下次遇到类似描述直接复用
• 你的标签选择：这个项目是PC端还是APP端，记住了，下次不用重选
• 你的步骤粒度偏好：你觉得步骤太细让它合并了，它记住，后续风格保持一致
• 历史漏掉的场景：哪类场景之前经常遗漏，这次自动补进去

用了几次之后，生成质量会明显比第一次好。不是因为模型升级了，而是因为它记住了你的项目和你的习惯。

5｜输出直接可用：XMind免二次整理

生成的文件是.xmind格式，结构严格按照XMind导入规范组织：

• 项目名作为根节点，下面按功能模块分层
• 每条用例包含：前置条件、操作步骤、预期结果、优先级标签
• 同一模块下的用例按功能区域归类，不会出现“每个功能点单独建一个目录”导致目录爆炸的问题

打开XMind，全选导入，一份结构清晰的测试用例树就在眼前了。

四、典型案例对比：人工 vs Skill，差距在哪

拿一个真实的支付模块需求来对比。需求描述：用户选择银行卡支付，输入卡号、有效期、CVV，点击确认，支付成功则跳转到成功页，失败则显示错误提示。

人工输出（资深测试工程师，用时45分钟）

• 等价类：卡号正确/错误/空，有效期格式正确/错误/过期，CVV正确/错误/空
• 边界值：卡号最小最大长度，有效期月份1/12/13，CVV 3/4位
• 场景流：正常支付成功，支付失败，网络超时后重试
• 错误推测：连续输错CVV锁定，余额不足回调
• 优先级分布：P0约12%，P1约35%
• 总用例数：23条

Skill输出（自动，用时3分钟）

• 完全覆盖以上所有用例
• 额外补充：有效期“当月最后一天”边界，CVV输入字母自动拦截，支付成功页面的返回按钮行为
• 优先级分布：P0 13%，P1 38%，自动校准
• 总用例数：28条（多出来的5条是人工容易忽略的UI交互和边界组合）

差距不在“能不能想到”，而在“每次都能稳定想到”。人工会疲劳，Skill不会。而且Skill把优先级分布控制在一个稳定的区间，不会出现这次P0占30%下次只有5%的情况。

五、工程落地启示：你的团队也能复制

这个Skill不是只能我自己用。它的设计思路完全可以被其他团队复制。

启示一：测试设计流程可以“代码化”
把等价类、边界值、场景法、错误推测这些方法写成确定的执行顺序和判断规则，再交给LLM去填充内容。核心是“流程控制+LLM填充”，而不是让LLM自由发挥。

启示二：质量预审机制比生成算法更重要
没有预审的生成是不可信的。六项检查指标可以根据你团队的标准调整，但必须存在。这是从“玩具”到“工具”的分水岭。

启示三：记忆是长期价值的来源
通用LLM不懂你的项目。记忆机制（.memory/目录）解决了这个问题。建议团队把公共的歧义判断、领域规则沉淀到一个共享记忆库，新人上手直接复用。

启示四：多模态不是炫技，是刚需
现实工作中大量需求以图片形式存在。如果不支持图片输入，这个工具的使用场景会缩水一半以上。

落地建议：选一个模块，跑通从需求到XMind的全流程，观察生成的用例质量和覆盖率。不要一开始就追求完美，先用质量预审把“不可信”的用例挡在外面，再逐步调优。

有人说AI会取代测试工程师。我不这么看。

会被取代的是“手工翻译需求为用例”这个动作，而不是测试设计这个岗位。未来测试工程师的价值会从“写用例”转向“设计智能体”——定义什么场景用什么方法、什么指标算合格、什么遗漏需要补充记忆。

换句话说，你不是被AI替代，而是被会用AI的同行替代。

这个Skill让我看到的一个明确趋势是：测试设计会变成一种“可配置的流程”，而不是一种“靠经验积累的手艺”。经验仍然重要，但经验会被编码成规则和记忆，沉淀在工具里，而不是只留在一个人的脑子里。

观点句：测试设计的未来不是取消人工，而是把人工从重复劳动中解放出来，去做更高价值的策略设计。

最后，留一个问题给你：

当你的测试用例生成效率提升10倍，你省下来的时间会用来做什么？