testcase-generator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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

Test Case Generator (testcase-generator)

1. 目标

1. Objective

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

Generate structured test cases based on Test Points, covering positive, negative, and boundary scenarios.

2. 输入输出

2. Input & Output

输入：

test-case/plan.md

、

clarified-requirements/index.md

、

CLAUDE.md

输出：

test-case/{ITEM}/{POINT}.md

、

test-case/all_cases.md

Input:

test-case/plan.md

clarified-requirements/index.md

CLAUDE.md

Output:

test-case/{ITEM}/{POINT}.md

test-case/all_cases.md

3. 核心原则

3. Core Principles

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

Strategy Guidance: Provide judgment criteria instead of mandatory quantities
Scenario-Driven: Generate cases based on actual scenario complexity
Specific Data: Test data must be specific, no placeholders allowed
Verifiability: Expected results must be clearly verifiable

触发条件

Trigger Conditions

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

User executes the
```
/testcase-gen
```
command
```
test-case/plan.md
```
exists

4. 核心理论

4. Core Theories

4.1 等价类划分法

4.1 Equivalence Partitioning Method

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

应用示例:

POINT: 用户名密码登录

输入项: 用户名、密码

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

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

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

Divide input data into several equivalence classes, select representative data from each class for testing.

Application Example:

POINT: Username & Password Login

Input Items: Username, Password

Username Equivalence Classes:
  Valid: [6-20 chars, letters numbers underscores] → "test_user123"
  Invalid: [<6] "ab" | [>20] "verylongusername12345" | [special chars] "user@name" | [empty] ""

Password Equivalence Classes:
  Valid: [8-20 chars, uppercase + lowercase + numbers] → "Test1234"
  Invalid: [<8] "Test12" | [missing uppercase] "test1234" | [empty] ""

Generation Principle: Test one equivalence class at a time, keep others valid

4.2 边界值分析法

4.2 Boundary Value Analysis Method

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

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

应用示例:

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

Boundaries are the most error-prone areas.

Three-Point Boundary Method: Off-point (min-1) | On-point (min) | Inner-point (middle value) | On-point (max) | Off-point (max+1)

Application Example:

Username length 6-20 characters:
- Off-point (lower): 5 chars "abcde" → Fail
- On-point (lower): 6 chars "abcdef" → Pass
- Inner-point: 13 chars "test_user_123" → Pass
- On-point (upper): 20 chars "test_user_1234567890" → Pass
- Off-point (upper): 21 chars "test_user_12345678901" → Fail

4.3 用例数量判断

4.3 Test Case Quantity Judgment

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

判断标准：

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

No mandatory quantity, adjust adaptively based on scenario complexity.

Judgment Criteria:

Number of input items: More inputs mean more cases
Business rule complexity: More complex rules mean more cases
Risk level: Critical and High require more cases
Test focus areas: More focus areas mean more cases

5. 用例格式规范

5. Test Case Format Specifications

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

5.1 Markdown Text Protocol Format (v0.2)

每个测试点生成一个

.md

文件,格式如下:

markdown

undefined

Generate a

.md

file for each Test Point, following this format:

markdown

undefined

[P1] 用例标题

[P1] Test Case Title

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

[Test Type] Function [Preconditions] Precondition description [Test Steps] 1. Step 1. 2. Step 2 [Expected Results] 1. Expected Result 1. 2. Expected Result 2

[P3][反向] 用例标题

[P3][Negative] Test Case Title

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

undefined

[Test Type] Function [Preconditions] Precondition description [Test Steps] 1. Step 1. 2. Step 2 [Expected Results] 1. Expected Result 1. 2. Expected Result 2

undefined

5.2 字段说明

5.2 Field Explanations

优先级：P1-P5（必填）
- P1: 核心功能正向流程
- P2: 基本功能正向流程
- P3: 核心功能异常场景
- P4: 边界条件
- P5: 低频场景
[反向]：反向用例标记（可选）
测试类型：功能、接口、性能、安全、兼容、易用、安装部署、可靠、本地化、可维护、可扩展、配置（12选1）
前置条件：测试前的准备工作
测试步骤：操作步骤，用句号分隔
预期结果：期望的结果，与步骤一一对应

Priority: P1-P5 (Required)
- P1: Core function positive flow
- P2: Basic function positive flow
- P3: Core function exception scenarios
- P4: Boundary conditions
- P5: Low-frequency scenarios
[Negative]: Negative test case marker (Optional)
Test Type: Choose 1 from 12 options: Function, Interface, Performance, Security, Compatibility, Usability, Installation & Deployment, Reliability, Localization, Maintainability, Scalability, Configuration
Preconditions: Preparation work before testing
Test Steps: Operation steps, separated by periods
Expected Results: Expected outcomes, one-to-one correspondence with steps

5.3 测试类型枚举(12种)

5.3 Test Type Enumeration (12 Types)

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

注意:

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

Function
Compatibility
Usability
Performance
Stability
Security
Reliability
Effect (AI, Resource)
Effect (Hardware Device)
Maintainability
Portability
Buried Point

Notes:

Cannot write "Function Test", must use "Function"
Parentheses must be English parentheses
Case-sensitive

5.4 步骤格式规范

5.4 Step Format Specifications

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

markdown

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

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

Recommended Format: Separated by Chinese periods, continuous numbering

markdown

[Test Steps] 1. Open login page. 2. Enter username test_user. 3. Enter password Test1234. 4. Click login button
[Expected Results] 1. Page displays normally. 2. Username input box shows content. 3. Password input box shows password. 4. Login succeeds, redirect to homepage

Important: Numbering must start from 1 and be continuous; the number of test steps must match the number of expected results.

5.5 测试数据要求

5.5 Test Data Requirements

必须具体，不用占位符：

正确示例：

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

错误示例：

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

Must be specific, no placeholders:

Correct Examples:

Username: test_user
Password: Test1234
Phone number: 13800138000
Amount: 99.99

Incorrect Examples:

Username: {valid_username}
Password: {password}
Phone number: {phone}
Amount: {amount}

5.6 预期结果要求

5.6 Expected Result Requirements

必须明确可验证：

正确示例：

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

错误示例：

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

Must be clearly verifiable:

Correct Examples:

Redirect to /home page, top displays "Welcome, test_user"
Prompt "Password length insufficient, please enter 8-20 characters"
Order status changes to "Paid", inventory decreases by 1

Incorrect Examples:

Login succeeds
Prompt error message
System processes normally

5.7 目录结构

5.7 Directory Structure

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

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

5.8 合并规则

5.8 Merging Rules

将所有

{ITEM}/{POINT}.md

合并到

all_cases.md

：

按 ITEM 分组
每个 ITEM 下按 POINT 排序
添加分隔标记：
```
# ITEM 名称
```
和
```
## POINT 名称
```

Merge all

{ITEM}/{POINT}.md

into

all_cases.md

Group by ITEM
Sort by POINT under each ITEM
Add separators:
```
# ITEM Name
```
and
```
## POINT Name
```

6. 用例生成流程

6. Test Case Generation Process

Step 1: 准备上下文

Step 1: Prepare Context

bash

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

bash

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

Step 2: 理解测试点

Step 2: Understand Test Points

对每个 POINT：

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

For each POINT:

Read POINT name, risk level, test focus areas
Read relevant descriptions in requirement documents

Step 3: 识别输入项

Step 3: Identify Input Items

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

List all input items (fields, parameters, operations, etc.)
Identify constraints for each input item

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

Step 4: Partition Equivalence Classes and Boundary Values

有效等价类：符合规则的输入
无效等价类：违反规则的输入
边界值：临界点（最小值、最大值、临界值）

Valid Equivalence Classes: Input that complies with rules
Invalid Equivalence Classes: Input that violates rules
Boundary Values: Critical points (minimum, maximum, threshold values)

Step 5: 设计测试用例

Step 5: Design Test Cases

基于以下策略设计：

核心思考框架:

输入分析
- 该场景涉及哪些输入项？
- 每个输入有什么约束（长度、格式、范围）？
等价类识别
- 有效等价类：正常情况下的典型值
- 无效等价类：各种异常情况（空值、越界、格式错误）
测试价值评估
- 这个等价类失败时，会暴露不同的缺陷吗？
- 如果和其他等价类的测试逻辑相同，是否可以合并？
- 测试关注点中提到的场景，如何在用例中体现？
覆盖判断
- 有效流程至少有一个用例
- 核心异常场景已覆盖
- 边界条件根据实际情况选择
用例设计
- 核心正向用例（P1）：最常见的成功场景
- 基本正向用例（P2）：其他有效等价类
- 核心异常用例（P3）：关键失败场景
- 边界条件用例（P4）：边界值测试
- 低频场景用例（P5）：不常见但需覆盖的场景

用例质量标准:

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

Design based on the following strategies:

Core Thinking Framework:

Input Analysis
- Which input items are involved in this scenario?
- What constraints does each input have (length, format, range)?
Equivalence Class Identification
- Valid Equivalence Classes: Typical values under normal circumstances
- Invalid Equivalence Classes: Various abnormal situations (empty values, out-of-bounds, format errors)
Test Value Evaluation
- Will failure of this equivalence class expose different defects?
- Can it be merged if the test logic is the same as other equivalence classes?
- How to reflect the test focus areas in the test cases?
Coverage Judgment
- At least one case for valid flows
- Core abnormal scenarios are covered
- Boundary conditions are selected based on actual situations
Test Case Design
- Core Positive Cases (P1): Most common success scenarios
- Basic Positive Cases (P2): Other valid equivalence classes
- Core Exception Cases (P3): Key failure scenarios
- Boundary Condition Cases (P4): Boundary value tests
- Low-Frequency Scenario Cases (P5): Uncommon but necessary coverage scenarios

Test Case Quality Standards:

Specific data ("test123" instead of "valid username")
Verifiable expected results ("Show error prompt 'Username cannot be empty'" instead of "Prompt error")
Standard naming (starts with "Verify")

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

Step 6: Unified Verification After Generation

每个测试项（ITEM）生成完毕后，调用校验脚本检查格式
全部测试项生成完毕后，再次调用校验脚本进行整体检查

校验脚本路径：

.claude/skills/testcase-generator/scripts/validate.py

After generating each Test Item (ITEM), call the validation script to check format
After generating all Test Items, call the validation script again for overall inspection

Validation script path:

.claude/skills/testcase-generator/scripts/validate.py

7. 示例

7. Examples

示例1：正确的用例（用户名密码登录）

Example 1: Correct Test Cases (Username & Password Login)

markdown

undefined

markdown

undefined

[P1] 验证有效用户名和密码登录成功

[P1] Verify successful login with valid username and password

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

[Test Type] Function [Preconditions] Registered user test_user with password Test1234 [Test Steps] 1. Enter username test_user, enter password Test1234, click login. 2. Verify redirect to homepage and display username [Expected Results] 1. Login request succeeds. 2. Redirect to /home page, top displays 'Welcome, test_user'

[P3][反向] 验证用户名为空时登录失败

[P3][Negative] Verify login failure when username is empty

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

[Test Type] Function [Preconditions] Enter login page [Test Steps] 1. Do not enter username, enter password Test1234, click login. 2. Verify prompt 'Username cannot be empty' [Expected Results] 1. Login request is rejected. 2. Stay on login page, red prompt 'Username cannot be empty' displays below username input box

[P4] 验证密码长度边界值（8位）

[P4] Verify password length boundary value (8 characters)

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

undefined

[Test Type] Function [Preconditions] Registered user test_user with password Test1234 [Test Steps] 1. Enter username test_user, enter 8-character password Test1234, click login. 2. Verify login succeeds [Expected Results] 1. Login request succeeds. 2. Redirect to /home page

undefined

示例2：综合场景（多输入项）

Example 2: Comprehensive Scenario (Multiple Input Items)

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

输入项分析:

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

生成用例（6个）:

markdown

undefined

POINT: Ad Account List - Filter Function

Input Item Analysis:

Time Range: [Today | Yesterday | Last 7 Days | Custom]
Account Name: [Text fuzzy search]
Account Status: [Normal | Banned | Under Review]

Generated Test Cases (6 Cases):

markdown

undefined

[P1] 验证单一条件筛选成功

[P1] Verify successful filtering with single condition

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

[Test Type] Function [Preconditions] Ad account list page with 10 accounts [Test Steps] 1. Select time "Last 7 Days", click query. 2. Verify return of eligible accounts [Expected Results] 1. List refreshes. 2. Only accounts with data in last 7 days are displayed

[P1] 验证多条件组合筛选成功

[P1] Verify successful filtering with multiple combined conditions

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

[Test Type] Function [Preconditions] Same as above [Test Steps] 1. Select time "Last 7 Days", enter name "test", select status "Normal", click query [Expected Results] 1. List refreshes. 2. Only accounts meeting all 3 conditions are displayed

[P3][反向] 验证时间超过365天筛选失败

[P3][Negative] Verify filtering failure when time range exceeds 365 days

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

[Test Type] Function [Preconditions] Same as above [Test Steps] 1. Select custom time, start date 2023-01-01, end date 2024-01-02, click query [Expected Results] 1. Display prompt "Time range cannot exceed 365 days", list does not refresh

[P3][反向] 验证不存在的账户名筛选返回空

[P3][Negative] Verify empty return when filtering with non-existent account name

[测试类型] 功能 [前置条件] 同上 [测试步骤] 1. 输入不存在的账户名"nonexistent123"，点击查询 [预期结果] 1. 列表刷新。2. 显示"暂无数据"

[Test Type] Function [Preconditions] Same as above [Test Steps] 1. Enter non-existent account name "nonexistent123", click query [Expected Results] 1. List refreshes. 2. Display "No data available"

[P2] 验证筛选条件清空功能

[P2] Verify filter condition clear function

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

[Test Type] Function [Preconditions] Filter conditions have been applied [Test Steps] 1. Click "Reset" button. 2. Verify all filter conditions are cleared, list returns to default [Expected Results] 1. All filter options return to default values. 2. List displays all accounts

[P4][反向] 验证结束时间早于开始时间提示错误

[P4][Negative] Verify error prompt when end time is earlier than start time

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


**说明**:
- 中等复杂度 POINT（多输入项）生成 6 个用例
- 覆盖：有效组合、无效边界、清空操作
- 选择**代表性用例**，覆盖主要场景

[Test Type] Function [Preconditions] Same as above [Test Steps] 1. Select custom time, start date 2024-01-02, end date 2024-01-01, click query [Expected Results] 1. Display prompt "End time cannot be earlier than start time"


**Explanation**:
- Medium complexity POINT (multiple input items) generates 6 cases
- Coverage: Valid combinations, invalid boundaries, clear operation
- Select **representative cases** to cover main scenarios

示例3：错误的用例

Example 3: Incorrect Test Cases

markdown

undefined

markdown

undefined

[P1] 验证登录成功

[P1] Verify login success

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


**为什么错误**：
- 测试数据使用占位符（{username}、{password}）
- 预期结果不可验证（"登录成功"太模糊）

---

[Test Type] Function [Preconditions] User has registered [Test Steps] 1. Enter username {username}, enter password {password}, click login [Expected Results] 1. Login succeeds


**Why Incorrect**:
- Test data uses placeholders ({username}, {password})
- Expected results are not verifiable ("Login succeeds" is too vague)

---

8. 检验流程

8. Inspection Process

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

Step 1: After Generating Each Test Item

调用校验脚本检查格式：

bash

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

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

Call validation script to check format:

bash

uv run .claude/skills/testcase-generator/scripts/validate.py \
  --single "test-case/{Module}/{Test Point}.md"

The script will output logs indicating format issues (e.g., priority errors, missing fields). AI analyzes logs to decide whether modifications are needed.

Step 2: 全部生成完毕后

Step 2: After All Generation is Complete

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

bash

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

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

Call validation script again for overall inspection:

bash

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

The script will check for duplicate cases, format consistency, etc. The script only provides logs and does not modify files directly. AI analyzes logs to decide whether adjustments are needed.

Step 3: 生成质量报告

Step 3: Generate Quality Report

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

Count number of test cases (by ITEM, by priority)
Count equivalence class coverage
Count boundary value coverage
List duplicate cases (if any)

9. 检查清单

9. Checklists

生成前检查

Pre-Generation Check

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

Read
```
test-case/plan.md
```
Read
```
clarified-requirements/index.md
```
Read business background in
```
CLAUDE.md
```
Understand hierarchical relationship between Test Item (ITEM) and Test Point (POINT)

每个POINT生成时检查

Check When Generating Each POINT

治理阶段检查

Governance Phase Check

10. 脚本接口

10. Script Interfaces

validate.py

bash

undefined

bash

undefined

单文件校验

Single file validation

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

uv run .claude/skills/testcase-generator/scripts/validate.py
--single "test-case/{Module}/{Test Point}.md"

全局校验

Global validation

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

全局校验 + 重复检测

Global validation + duplicate detection

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

仅重复检测

Duplicate detection only

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


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

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


**Validation Items**:
- Schema format
- Required fields (priority, test type, test steps, expected results)
- Test type enumeration (12 types)
- Step number continuity
- Consistency between number of steps and expected results
- Equivalence class coverage check (`--check-equivalence`)
- Boundary value coverage check (`--check-boundary`)
- Duplicate detection (`--check-duplicates`)

to_excel.py

bash

undefined

bash

undefined

从目录导出

Export from directory

uv run .claude/skills/testcase-generator/scripts/to_excel.py "test-case/" -o "test-case/export.xlsx"

从单个文件导出

Export from single file

uv run .claude/skills/testcase-generator/scripts/to_excel.py "test-case/{模块}/{测试点}.md" -o "output.xlsx"

---

uv run .claude/skills/testcase-generator/scripts/to_excel.py "test-case/{Module}/{Test Point}.md" -o "output.xlsx"

---

11. 异常处理

11. Exception Handling

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

Error	Handling Method
Single file validation failed	Retry 3 times, skip and record if still failed
Too many test cases (>15)	Prompt to check for redundant equivalence classes
Missing boundary cases	Warn and suggest supplement
Missing invalid equivalence classes	Warn and suggest supplement exception scenarios
Discontinuous step numbering	Report error and require correction
Test type not in enumeration	Report error and require correction
Mismatch between number of steps and expected results	Report error and require correction
Export failed	Check openpyxl dependency

12. 停止点

12. Stop Points

✅ 用例生成完成

产物:

```
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 格式（可选）
根据业务理解调整用例

✅ Test Case Generation Complete

Deliverables:

```
test-case/{ITEM}/{POINT}.md
```
- Case files for each Test Point
```
test-case/all_cases.md
```
- All cases summary

Quality Assurance:

Generated based on equivalence class theory
Full boundary value coverage
Reasonable number of cases (based on scenario complexity)

Statistics Example:

📊 Generation Statistics:
  - Test Items: 8
  - Test Points: 20
  - Test Cases: 75

  Coverage:
  - Valid Equivalence Classes: 100% (at least 1 per POINT)
  - Invalid Equivalence Classes: 80% (main exceptions covered)
  - Boundary Values: 90% (all range-based inputs)

  Case Distribution:
  - P1 (Core Positive): 20 (27%)
  - P2 (Basic Positive): 15 (20%)
  - P3 (Core Exception): 25 (33%)
  - P4 (Boundary Conditions): 12 (16%)
  - P5 (Low-Frequency): 3 (4%)

Next Steps:

Manual review of test cases
Export to Excel format (optional)
Adjust cases based on business understanding