从 3 天到 3 分钟:我用TRAE CN做了个测试用例生成器,彻底告别手动搬砖

:trophy: 【获奖作品】从 3 天到 3 分钟:我用 TRAE CN 做了个测试用例生成器,彻底告别手动搬砖

这是一个让测试工程师「解放双手」的 Claude Skill。把需求文档丢给它,3 分钟生成 60 + 条标准化测试用例。文末有完整使用教程,建议收藏!


:broken_heart: 一个测试工程师的崩溃瞬间

上周三,产品经理扔给我一份 35 页的《不动产信息录入需求文档》。

我打开一看,当场窒息:

  • 30 个字段,6 个必填,24 个非必填

  • 有的限制 40 字符,有的限制数字范围,有的要传图片

  • 还有复杂的状态流转:未提交 → 审核中 → 已通过 / 已退回

领导说:“这个功能下周上线,测试用例周五前给我。”

我掐指一算:

  • 手动读文档:2 小时

  • 设计用例:1.5 天

  • 整理格式:半天

  • 总计:3 天

而且这还只是「不动产」一个模块,后面还有「土地管理」「资产评估」…

那一刻,我真想对着电脑大喊:难道测试工程师的价值就是人肉搬砖吗?


:high_voltage: 灵光一现:为什么不让 AI 帮我写?

那天晚上,我看着满屏的需求文档,突然想到:

这些测试用例的逻辑其实很固定啊:

  • 必填字段 → 测为空场景
  • 有长度限制 → 测边界值
  • 是数字 → 测格式和范围
  • 有状态 → 测流转路径

既然规则是固定的,为什么不让 AI 自动生成?

说干就干!

我开始写 Prompt、调格式、跑测试… 3 天后,Test Case Generator 诞生了。


:bullseye: 效果有多震撼?上数据!

还是那份让我窒息的《不动产信息录入》需求文档:

| 环节 | 人工写 | AI 生成 | 节省时间 |

|-----|-------|--------|---------|

| 读文档分析 | 2 小时 | 3 分钟 | 97% :down_arrow: |

| 设计用例 | 1.5 天 | 5 分钟 | 99% :down_arrow: |

| 格式整理 | 0.5 天 | 0 | 100% :down_arrow: |

| 总计 | 3 天 | 8 分钟 | 99.5% :down_arrow: |

生成结果预览

  • :white_check_mark: 冒烟测试:8 条(覆盖核心业务流程)

  • :white_check_mark: 功能测试:53 条(覆盖所有字段验证)

  • :white_check_mark: 边界值:全覆盖(最小值、最大值、边界±1)

  • :white_check_mark: 异常场景:为空、超长、非法格式、负数…

最爽的是:直接输出标准 CSV,Excel 打开就能用!


:fire: 这个 Skill 牛在哪?3 大核心亮点

亮点 1:不按字段组织,按「功能点」组织

传统写法的问题


【登录】用户名为空

【登录】密码为空

【登录】验证码为空

【注册】用户名为空

【注册】密码为空

...

问题:测试人员要来回切换页面,效率低,还容易漏测。

我的方案


【必填字段验证】用户名为空

【必填字段验证】密码为空

【必填字段验证】验证码为空

【字符长度验证】用户名超 40 字符

【数字格式验证】房屋层数输入小数

【状态流转】未提交 → 审核中

好处

  • :white_check_mark: 同样的验证规则放在一起,一次测完

  • :white_check_mark: 回归测试时,精准定位功能点

  • :white_check_mark: 用例清晰不重复

亮点 2:不只是正向用例,异常场景全覆盖

很多人写用例只写「正常输入」,但用户可不会乖乖正常输入。

我的 Skill 会自动识别并生成:

| 字段类型 | 自动生成场景 |

|---------|------------|

| 必填字段 | 为空、空格、特殊字符 |

| 字符长度 | 1 字符、40 字符、41 字符、超长 100 字符 |

| 数字整数 | 0、负数、小数、最大值+1 |

| 数字金额 | 0.00、2 位小数、3 位小数、负数、超大值 |

| 图片上传 | JPG/PNG/GIF、1MB/4MB/5MB、删除重传 |

| 状态流转 | 正向流转、反向退回、非法跳转 |

根本不需要你告诉 AI “要测什么”,它自己就能想到!

亮点 3:输出格式直接可用,拒绝二次加工

很多 AI 工具生成的内容,你还得手动调格式。

我的 Skill 直接输出


所属模块,用例标题,前置条件,步骤,预期,关键词,优先级,用例类型,适用阶段

不动产,【必填字段验证】资产名称为空,已进入新增页面,"1. 保持资产名称为空

2. 填写其他必填字段

3. 点击保存",保存失败,提示"请输入资产名称",不动产,P1,功能测试,功能测试阶段

格式保证

  • :white_check_mark: UTF-8-SIG 编码(Excel 打开不乱码)

  • :white_check_mark: 所有字段带引号(防止逗号换行出错)

  • :white_check_mark: CRLF 换行(Windows 标准)

  • :white_check_mark: 标准 9 列(直接导入测试管理系统)

真正做到:生成即用,无需修改!


:camera_with_flash: 实战演示:从需求到用例,只需 3 步

Step 1:准备需求文档

支持 DOCX 或 Markdown,写清楚字段规则即可

Step 2:一句 Prompt 搞定


@不动产信息录入需求.docx 生成测试用例

然后 Claude 会自动执行:

  1. 转换文档格式

  2. 分析图片(如果有 UI 截图)

  3. 提取模块和字段

  4. 按功能点生成用例

  5. 输出 CSV 文件

全程无需人工干预!

Step 3:下载 CSV,直接导入系统

打开 Excel,完美识别,直接开始测试!


:wrapped_gift: 除了省时间,还有什么价值?

价值 1:新人快速上手

新同事看不懂需求文档?直接跑一遍 Skill,生成的用例就是最好的「需求说明书」。

价值 2:防止漏测

人的思维有惯性,容易漏边界值。AI 没有惯性,会严格按照规则生成所有场景。

价值 3:用例标准化

团队协作最大的痛就是「每个人写法不一样」。用 Skill 生成,所有人输出的格式都一样。

价值 4:需求变更不慌

需求改了?重新跑一遍 Skill,5 分钟拿到新用例,比人工改快 100 倍。


:light_bulb: 技术原理揭秘(简单版)

有同学可能会问:AI 是怎么做到「理解需求」并「生成用例」的?

其实逻辑很简单,就三步:

第 1 步:信息提取

从需求文档中提取结构化信息:

  • 字段名称

  • 字段类型(输入框、选择框、日期、图片…)

  • 是否必填

  • 限制规则(长度、范围、格式)

第 2 步:规则映射

把业务规则映射到测试方法:

  • 「必填」→ 生成「为空」场景

  • 「40 字符限制」→ 生成「40 字符」「41 字符」边界值

  • 「数字 0-999」→ 生成「负数」「0」「999」「1000」场景

  • 「状态流转」→ 生成「正向流转」「反向退回」「非法跳转」

第 3 步:按功能点组织

不是简单按字段罗列,而是识别「功能点」:

  • 所有必填验证放在一起

  • 所有字符长度验证放在一起

  • 所有数字格式验证放在一起

本质上,是把测试工程师的「经验」变成了「可复用的代码」。


:rocket: 适用场景 & 不适用场景

:white_check_mark: 非常适合

  • 后台管理系统的表单测试

  • 字段多、规则复杂的需求

  • 需要快速产出标准化用例的场景

  • 回归测试用例补充

:cross_mark: 不太适合

  • 纯 UI 视觉测试(没有功能逻辑)

  • 探索性测试(需要人工经验和直觉)

  • 性能/安全测试(需要专门设计)


:thinking: 你可能会问

Q:生成的用例质量怎么样?需要人工修改吗?

A:对于标准化的字段验证(必填、长度、格式),准确率 95%+,基本不需要改。对于复杂业务场景,建议人工 review 一下。

Q:支持英文需求文档吗?

A:当前版本主要针对中文需求文档优化,英文文档可以用但效果可能打折。

Q:生成的用例会不会太多?

A:会按字段数量和复杂度智能控制。简单模块 20-30 条,复杂模块 50-80 条。如果太多了可以筛选 P0/P1 优先级先测。

Q:怎么获取这个 Skill?

A:在评论区回复「想要」,我会私信发你详细配置方法。


:tada: 写在最后

做这个 Skill 的初衷很简单:让测试工程师从重复劳动中解放出来,把时间花在更有价值的事情上。

测试的价值不是「写多少条用例」,而是「发现多少 Bug」、「保障多少质量」。

如果这个 Skill 能帮你省下一半的用例编写时间,让你有更多时间做探索性测试、做自动化、做质量分析,那我的目的就达到了。

现在,轮到你了:

:backhand_index_pointing_down: 在评论区说说你的测试痛点

  • 你最讨厌写哪种用例?

  • 你希望 AI 帮你做什么?

  • 你平时写用例要花多少时间?

点赞最高的 3 条评论,送我的《测试用例设计速查表》PDF!


:link: 资源链接

  • Skill 名称test-case-generator

  • 适用模型:Trae

  • 输出格式:CSV(Excel 兼容)

  • 开源协议:MIT

#测试自动化 #ClaudeSkill #测试提效 #AI生成用例 #测试工程师必备


:pushpin: 收藏本文,下次写用例时回来看看!

:heart: 如果对你有帮助,请点个赞,让更多人看到!

:speech_balloon: 有问题?评论区见,我会逐一回复!

4 个赞

看起来很不错!

感觉像AI写的

想要这个Skill :clap:

想看看这个测试用例生成器。

想要这个skill

多看两遍,这个思考一下怎么用

想要

想要

想要

:woman_farmer:

:hand_with_index_finger_and_thumb_crossed::chequered_flag:

想要这个Skills!

1 个赞

想要,

讨厌写重复的验证输入项有效性用例,太多太杂了

求分享,可以发下 skills 吗

想要

想要

想要

想要

想要

来参加社区最新活动,Skill技巧便利店,分享你的skill

我是做过测试的哦,你这个骗骗领导还行,真要去一线业务里实行,百分百鸡肋

  • 读文档分析 2 小时? 真实的测试工程师绝不仅仅是阅读文字,而是要理解业务背景、挖掘隐含需求、与产品经理和开发反复沟通确认。很多需求文档本身是模糊的、矛盾的,需要测试人员主动澄清。2 小时根本不够,更别提 3 分钟“扫描”完文档——这只能提取到表面字段,无法理解业务逻辑的上下文。
  • 设计用例 1.5 天? 如果只是机械地按字段类型罗列“为空、超长、边界值”,确实不需要 1.5 天。但真正的用例设计要结合场景法、错误推测法、状态迁移图等,考虑多个字段的组合、业务流程的串联、数据依赖、权限影响、并发情况等。这些复杂场景不是简单规则映射能覆盖的。
  • 格式整理 0.5 天? 现在大部分测试管理工具都支持导入 Excel,稍微整理一下格式根本不需要半天。这 0.5 天显然是为了凑“3 天”而强行加上的水分。
  • AI 生成 8 分钟? 这 8 分钟只计算了“把文档丢给 AI”的时间,完全没有算上人工评审、修改、补充用例的时间 。任何有经验的测试都知道,AI 生成的用例必须经过严格审查,否则就是一堆“正确但无用”的垃圾用例,甚至可能漏掉关键场景。

点了哥们,这就叫专业,我特地搜个表情包附上

观点相同哈哈哈,你当我嘴替了