testcase-generator

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

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "testcase-generator" with this command: npx skills add chyax98/twu/chyax98-twu-testcase-generator

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

  1. 目标

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

  1. 输入输出

  • 输入：test-case/plan.md 、clarified-requirements/index.md 、CLAUDE.md

  • 输出：test-case/{ITEM}/{POINT}.md 、test-case/all_cases.md

  1. 核心原则

  • 策略指导：提供判断标准，而非强制数量

  • 场景驱动：基于实际场景复杂度生成用例

  • 数据具体：测试数据必须具体，不用占位符

  • 可验证性：预期结果必须明确可验证

触发条件

  • 用户执行 /testcase-gen 命令

  • test-case/plan.md 存在

  1. 核心理论

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 需要更多用例

  • 测试关注点：关注点越多，用例越多

  1. 用例格式规范

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 ：

  • 按 ITEM 分组

  • 每个 ITEM 下按 POINT 排序

  • 添加分隔标记：# ITEM 名称 和 ## POINT 名称

  1. 用例生成流程

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: 设计测试用例

基于以下策略设计：

核心思考框架:

输入分析

  • 该场景涉及哪些输入项？

  • 每个输入有什么约束（长度、格式、范围）？

等价类识别

  • 有效等价类：正常情况下的典型值

  • 无效等价类：各种异常情况（空值、越界、格式错误）

测试价值评估

  • 这个等价类失败时，会暴露不同的缺陷吗？

  • 如果和其他等价类的测试逻辑相同，是否可以合并？

  • 测试关注点中提到的场景，如何在用例中体现？

覆盖判断

  • 有效流程至少有一个用例

  • 核心异常场景已覆盖

  • 边界条件根据实际情况选择

用例设计

  • 核心正向用例（P1）：最常见的成功场景

  • 基本正向用例（P2）：其他有效等价类

  • 核心异常用例（P3）：关键失败场景

  • 边界条件用例（P4）：边界值测试

  • 低频场景用例（P5）：不常见但需覆盖的场景

用例质量标准:

  • 数据具体（"test123"，不要"正确用户名"）

  • 预期结果可验证（"显示错误提示'用户名不能为空'"，不要"提示错误"）

  • 命名规范（以"验证"开头）

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

  • 每个测试项（ITEM）生成完毕后，调用校验脚本检查格式

  • 全部测试项生成完毕后，再次调用校验脚本进行整体检查

  • 校验脚本路径：.claude/skills/testcase-generator/scripts/validate.py

  1. 示例

示例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: 广告账户列表-筛选功能

输入项分析:

  • 时间范围: [今天|昨天|近7天|自定义]

  • 账户名称: [文本模糊搜索]

  • 账户状态: [正常|封禁|审核中]

生成用例（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}）

  • 预期结果不可验证（"登录成功"太模糊）

  1. 检验流程

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、按优先级）

  • 统计等价类覆盖率

  • 统计边界值覆盖率

  • 列出重复用例（如果有）

  1. 检查清单

生成前检查

  • 已读取 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 检查）

  • 已生成质量报告

  1. 脚本接口

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"

  1. 异常处理

错误 处理方式

单文件校验失败 重试3次，仍失败则跳过并记录

用例数过多(>15) 提示检查是否有冗余等价类

缺少边界用例 警告并建议补充

缺少无效等价类 警告并建议补充异常场景

步骤编号不连续 报错并要求修正

测试类型不在枚举 报错并要求修正

步骤与预期数量不一致 报错并要求修正

导出失败 检查openpyxl依赖

  1. 停止点

✅ 用例生成完成

产物:

  • 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 格式（可选）

  • 根据业务理解调整用例

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Open in GitHubOpen in ClawHub

Related Skills

Related by shared tags or category signals.

General

testcase-planner

No summary provided by upstream source.

Repository SourceNeeds Review
-5
chyax98
General

req-merger

No summary provided by upstream source.

Repository SourceNeeds Review
-4
chyax98
General

req-parser

No summary provided by upstream source.

Repository SourceNeeds Review
-4
chyax98