Token导航 LogoToken导航TokenDH.com
待分类权限需确认github未标认证来源可访问许可证需确认审计异常

testcase-generator测试用例生成器

Agent Skill

用于辅助测试设计、自动化测试、用例整理和回归验证。它适合让 Agent 编写单元测试、端到端测试、测试计划或根据失败日志定位问题。使用时需要确认项目测试框架、运行命令和夹具数据,避免为了通过测试而改坏真实逻辑;涉及浏览器或外部服务时,应区分本地模拟、测试环境和生产环境。

总安装

4,140

周安装

176

GitHub Stars

9

下载量

1,450
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:testcase-generator(测试用例生成器)
来源仓库:https://github.com/chyax98/twu
仓库路径:skills/testcase-generator
安装命令:
npx skills add https://github.com/chyax98/twu --skill testcase-generator
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/chyax98/twu --skill testcase-generator

简介

用于根据测试点自动生成结构化测试用例,覆盖正向、反向和边界场景。

  • 基于等价类划分法等原则,提供具体测试数据和可验证预期结果。
  • 使用时需结合项目需求文档和现有代码结构,确保用例贴合实际逻辑。
  • 通过 GitHub 安装,需确认项目路径和框架兼容性,避免因环境差异导致执行失败。
  • testcase-generator 属于待分类类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

测试用例生成器(testcase-generator)

1. 目标

根据测试点生成结构化测试用例,覆盖正向、反向、边界场景。

2. 输入输出

  • 输入test-case/plan.mdclarified-requirements/index.mdCLAUDE.md
  • 输出test-case/{ITEM}/{POINT}.mdtest-case/all_cases.md

3. 核心原则

  1. 策略指导:提供判断标准,而非强制数量
  2. 场景驱动:基于实际场景复杂度生成用例
  3. 数据具体:测试数据必须具体,不用占位符
  4. 可验证性:预期结果必须明确可验证

触发条件

  • 用户执行 /testcase-gen 命令
  • test-case/plan.md 存在

4. 核心理论

4.1 等价类划分法

将输入数据划分为若干等价类,从每类中选取代表性数据测试。

应用示例:

POINT: 用户名密码登录

输入项: 用户名、密码

用户名等价类:
  有效: [6-20字符,字母数字下划线] → "test_user123"
  无效: [<6] "ab" | [>20] "verylongusername12345" | [特殊字符] "user@name" | [空] ""

密码等价类:
  有效: [8-20字符,含大小写+数字] → "Test1234"
  无效: [<8] "Test12" | [缺大写] "test1234" | [空] ""

生成原则: 一次测试一个等价类,其他保持有效

4.2 边界值分析法

边界是最容易出错的地方。

边界三点法: 离点(min-1) | 上点(min) | 内点(中间值) | 上点(max) | 离点(max+1)

应用示例:

用户名长度 6-20 字符:
- 离点-下: 5字符 "abcde" → 失败
- 上点-下: 6字符 "abcdef" → 成功
- 内点: 13字符 "test_user_123" → 成功
- 上点-上: 20字符 "test_user_1234567890" → 成功
- 离点-上: 21字符 "test_user_12345678901" → 失败

4.3 用例数量判断

不强制数量,根据场景复杂度自适应调整。

判断标准

  • 输入项数量:输入项越多,用例越多
  • 业务规则复杂度:规则越复杂,用例越多
  • 风险等级:Critical 和 High 需要更多用例
  • 测试关注点:关注点越多,用例越多

5. 用例格式规范

5.1 Markdown文本协议格式 (v0.2)

每个测试点生成一个 .md 文件,格式如下:

## [P1] 用例标题
[测试类型] 功能
[前置条件] 前置条件描述
[测试步骤] 1. 步骤1。2. 步骤2
[预期结果] 1. 预期1。2. 预期2

## [P3][反向] 用例标题
[测试类型] 功能
[前置条件] 前置条件描述
[测试步骤] 1. 步骤1。2. 步骤2
[预期结果] 1. 预期1。2. 预期2

5.2 字段说明

  • 优先级:P1-P5(必填)

- P1: 核心功能正向流程 - P2: 基本功能正向流程 - P3: 核心功能异常场景 - P4: 边界条件 - P5: 低频场景

  • [反向]:反向用例标记(可选)
  • 测试类型:功能、接口、性能、安全、兼容、易用、安装部署、可靠、本地化、可维护、可扩展、配置(12选1)
  • 前置条件:测试前的准备工作
  • 测试步骤:操作步骤,用句号分隔
  • 预期结果:期望的结果,与步骤一一对应

5.3 测试类型枚举(12种)

功能
兼容性
易用性
性能
稳定性
安全性
可靠性
效果(AI类、资源类)
效果(硬件器件类)
可维护性
可移植性
埋点

注意:

  • 不能写"功能测试",必须是"功能"
  • 括号必须是中文括号
  • 大小写敏感

5.4 步骤格式规范

推荐格式: 使用中文句号分隔,编号连续

[测试步骤] 1. 打开登录页面。2. 输入用户名test_user。3. 输入密码Test1234。4. 点击登录按钮
[预期结果] 1. 页面正常显示。2. 用户名输入框显示内容。3. 密码输入框显示密码。4. 登录成功,跳转到首页

重要: 编号必须从1开始,连续递增;测试步骤和预期结果的编号数量必须一致。

5.5 测试数据要求

必须具体,不用占位符:

正确示例

  • 用户名:test_user
  • 密码:Test1234
  • 手机号:13800138000
  • 金额:99.99

错误示例

  • 用户名:{valid_username}
  • 密码:{password}
  • 手机号:{phone}
  • 金额:{amount}

5.6 预期结果要求

必须明确可验证:

正确示例

  • 跳转到 /home 页面,顶部显示"欢迎,test_user"
  • 提示"密码长度不足,请输入8-20位密码"
  • 订单状态变为"已支付",库存减少1

错误示例

  • 登录成功
  • 提示错误信息
  • 系统正常处理

5.7 目录结构

test-case/
├── plan.md
├── {ITEM}/
│   ├── {POINT1}.md
│   ├── {POINT2}.md
│   └── ...
└── all_cases.md

5.8 合并规则

将所有 {ITEM}/{POINT}.md 合并到 all_cases.md

  1. 按 ITEM 分组
  2. 每个 ITEM 下按 POINT 排序
  3. 添加分隔标记:# ITEM 名称## POINT 名称

6. 用例生成流程

Step 1: 准备上下文

cat test-case/plan.md
cat clarified-requirements/index.md
cat CLAUDE.md

Step 2: 理解测试点

对每个 POINT:

  • 读取 POINT 名称、风险等级、测试关注点
  • 读取需求文档中的相关描述

Step 3: 识别输入项

  • 列出所有输入项(字段、参数、操作等)
  • 识别输入项的约束条件

Step 4: 划分等价类和边界值

  • 有效等价类:符合规则的输入
  • 无效等价类:违反规则的输入
  • 边界值:临界点(最小值、最大值、临界值)

Step 5: 设计测试用例

基于以下策略设计:

核心思考框架:

  1. 输入分析

- 该场景涉及哪些输入项? - 每个输入有什么约束(长度、格式、范围)?

  1. 等价类识别

- 有效等价类:正常情况下的典型值 - 无效等价类:各种异常情况(空值、越界、格式错误)

  1. 测试价值评估

- 这个等价类失败时,会暴露不同的缺陷吗? - 如果和其他等价类的测试逻辑相同,是否可以合并? - 测试关注点中提到的场景,如何在用例中体现?

  1. 覆盖判断

- 有效流程至少有一个用例 - 核心异常场景已覆盖 - 边界条件根据实际情况选择

  1. 用例设计

- 核心正向用例(P1):最常见的成功场景 - 基本正向用例(P2):其他有效等价类 - 核心异常用例(P3):关键失败场景 - 边界条件用例(P4):边界值测试 - 低频场景用例(P5):不常见但需覆盖的场景

用例质量标准:

  • 数据具体("test123",不要"正确用户名")
  • 预期结果可验证("显示错误提示'用户名不能为空'",不要"提示错误")
  • 命名规范(以"验证"开头)

Step 6: 生成完毕后统一校验

  • 每个测试项(ITEM)生成完毕后,调用校验脚本检查格式
  • 全部测试项生成完毕后,再次调用校验脚本进行整体检查
  • 校验脚本路径:.claude/skills/testcase-generator/scripts/validate.py

7. 示例

示例1:正确的用例(用户名密码登录)

## [P1] 验证有效用户名和密码登录成功
[测试类型] 功能
[前置条件] 已注册用户test_user,密码Test1234
[测试步骤] 1. 输入用户名test_user,输入密码Test1234,点击登录。2. 验证跳转到首页并显示用户名
[预期结果] 1. 登录请求成功。2. 跳转到/home页面,顶部显示'欢迎,test_user'

## [P3][反向] 验证用户名为空时登录失败
[测试类型] 功能
[前置条件] 进入登录页
[测试步骤] 1. 不输入用户名,输入密码Test1234,点击登录。2. 验证提示'用户名不能为空'
[预期结果] 1. 登录请求被拒绝。2. 停留在登录页,用户名输入框下方显示红色提示'用户名不能为空'

## [P4] 验证密码长度边界值(8位)
[测试类型] 功能
[前置条件] 已注册用户test_user,密码Test1234
[测试步骤] 1. 输入用户名test_user,输入8位密码Test1234,点击登录。2. 验证登录成功
[预期结果] 1. 登录请求成功。2. 跳转到/home页面

示例2:综合场景(多输入项)

POINT: 广告账户列表-筛选功能

输入项分析:

  1. 时间范围: [今天|昨天|近7天|自定义]
  2. 账户名称: [文本模糊搜索]
  3. 账户状态: [正常|封禁|审核中]

生成用例(6个):

## [P1] 验证单一条件筛选成功
[测试类型] 功能
[前置条件] 广告账户列表页面,有10个账户
[测试步骤] 1. 选择时间"近7天",点击查询。2. 验证返回符合条件的账户
[预期结果] 1. 列表刷新。2. 仅显示近7天有数据的账户

## [P1] 验证多条件组合筛选成功
[测试类型] 功能
[前置条件] 同上
[测试步骤] 1. 选择时间"近7天",输入名称"test",选择状态"正常",点击查询
[预期结果] 1. 列表刷新。2. 仅显示同时满足3个条件的账户

## [P3][反向] 验证时间超过365天筛选失败
[测试类型] 功能
[前置条件] 同上
[测试步骤] 1. 选择自定义时间,开始日期2023-01-01,结束日期2024-01-02,点击查询
[预期结果] 1. 显示提示"时间范围不能超过365天",列表不刷新

## [P3][反向] 验证不存在的账户名筛选返回空
[测试类型] 功能
[前置条件] 同上
[测试步骤] 1. 输入不存在的账户名"nonexistent123",点击查询
[预期结果] 1. 列表刷新。2. 显示"暂无数据"

## [P2] 验证筛选条件清空功能
[测试类型] 功能
[前置条件] 已应用筛选条件
[测试步骤] 1. 点击"重置"按钮。2. 验证所有筛选条件清空,列表恢复默认
[预期结果] 1. 所有筛选项恢复默认值。2. 列表显示全部账户

## [P4][反向] 验证结束时间早于开始时间提示错误
[测试类型] 功能
[前置条件] 同上
[测试步骤] 1. 选择自定义时间,开始日期2024-01-02,结束日期2024-01-01,点击查询
[预期结果] 1. 显示提示"结束时间不能早于开始时间"

说明:

  • 中等复杂度 POINT(多输入项)生成 6 个用例
  • 覆盖:有效组合、无效边界、清空操作
  • 选择代表性用例,覆盖主要场景

示例3:错误的用例

## [P1] 验证登录成功
[测试类型] 功能
[前置条件] 用户已注册
[测试步骤] 1. 输入用户名{username},输入密码{password},点击登录
[预期结果] 1. 登录成功

为什么错误

  • 测试数据使用占位符({username}、{password})
  • 预期结果不可验证("登录成功"太模糊)

8. 检验流程

Step 1: 每个测试项生成完毕后

调用校验脚本检查格式:

uv run .claude/skills/testcase-generator/scripts/validate.py \
  --single "test-case/{模块}/{测试点}.md"

脚本会输出日志,指出格式问题(如优先级错误、字段缺失等)。AI 分析日志,决定是否需要修改。

Step 2: 全部生成完毕后

再次调用校验脚本进行整体检查:

uv run .claude/skills/testcase-generator/scripts/validate.py "test-case/" --check-duplicates

脚本会检查重复用例、格式一致性等。脚本只提供日志,不直接修改文件。AI 分析日志,决定是否需要调整。

Step 3: 生成质量报告

  • 统计用例数量(按 ITEM、按优先级)
  • 统计等价类覆盖率
  • 统计边界值覆盖率
  • 列出重复用例(如果有)

9. 检查清单

生成前检查

  • 已读取 test-case/plan.md
  • 已读取 clarified-requirements/index.md
  • 已读取 CLAUDE.md 业务背景
  • 理解测试项(ITEM)和测试点(POINT)的层级关系

每个POINT生成时检查

  • 每个 POINT 都已生成用例文件
  • 用例数量合理(基于场景复杂度)
  • 所有用例都有优先级(P1-P5)
  • 所有用例都有测试类型(12种之一)
  • 测试数据具体(无占位符)
  • 预期结果可验证(无模糊描述)
  • 测试步骤与预期结果数量一致
  • 用例标题以"验证"开头

治理阶段检查

  • 执行了全局校验脚本
  • 检查了重复用例
  • 格式符合规范(已通过 validate.py 检查)
  • 已生成 all_cases.md
  • 无重复用例(已通过 validate.py --check-duplicates 检查)
  • 已生成质量报告

10. 脚本接口

validate.py

# 单文件校验
uv run .claude/skills/testcase-generator/scripts/validate.py \
  --single "test-case/{模块}/{测试点}.md"

# 全局校验
uv run .claude/skills/testcase-generator/scripts/validate.py "test-case/"

# 全局校验 + 重复检测
uv run .claude/skills/testcase-generator/scripts/validate.py "test-case/" --check-duplicates

# 仅重复检测
uv run .claude/skills/testcase-generator/scripts/validate.py "test-case/" --duplicates-only

校验项:

  • Schema格式
  • 必填字段(优先级、测试类型、测试步骤、预期结果)
  • 测试类型枚举(12种)
  • 步骤编号连续性
  • 步骤与预期结果数量一致性
  • 等价类覆盖检查(--check-equivalence)
  • 边界值覆盖检查(--check-boundary)
  • 重复检测(--check-duplicates)

to_excel.py

# 从目录导出
uv run .claude/skills/testcase-generator/scripts/to_excel.py "test-case/" -o "test-case/export.xlsx"

# 从单个文件导出
uv run .claude/skills/testcase-generator/scripts/to_excel.py "test-case/{模块}/{测试点}.md" -o "output.xlsx"

11. 异常处理

错误处理方式
单文件校验失败重试3次,仍失败则跳过并记录
用例数过多(>15)提示检查是否有冗余等价类
缺少边界用例警告并建议补充
缺少无效等价类警告并建议补充异常场景
步骤编号不连续报错并要求修正
测试类型不在枚举报错并要求修正
步骤与预期数量不一致报错并要求修正
导出失败检查openpyxl依赖

12. 停止点

用例生成完成

产物:

  • test-case/{ITEM}/{POINT}.md - 各测试点的用例文件
  • test-case/all_cases.md - 所有用例汇总

质量保证:

  • 基于等价类理论生成
  • 边界值全覆盖
  • 用例数量合理(基于场景复杂度)

统计示例:

📊 生成统计:
  - 测试项: 8个
  - 测试点: 20个
  - 测试用例: 75个

  覆盖率:
  - 有效等价类: 100% (每POINT至少1个)
  - 无效等价类: 80% (主要异常全覆盖)
  - 边界值: 90% (所有范围型输入)

  用例分布:
  - P1(核心正向): 20个(27%)
  - P2(基本正向): 15个(20%)
  - P3(核心异常): 25个(33%)
  - P4(边界条件): 12个(16%)
  - P5(低频场景): 3个(4%)

下一步:

  • 人工审核测试用例
  • 导出为 Excel 格式(可选)
  • 根据业务理解调整用例

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

38.69%
按下载量换算561

Claude

31.35%
按下载量换算455

Cursor

18.16%
按下载量换算263

Gemini CLI

9.64%
按下载量换算140

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

未通过

权限和风险

权限需确认

当前来源未能明确判断权限范围,默认进入异常复核队列。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills