Test Case Generator (testcase-generator)

1. Objective

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

2. Input & Output

Input:

test-case/plan.md

clarified-requirements/index.md

CLAUDE.md

Output:

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

test-case/all_cases.md

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

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

4. Core Theories

4.1 Equivalence Partitioning Method

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 Boundary Value Analysis Method

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 Test Case Quantity Judgment

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. Test Case Format Specifications

5.1 Markdown Text Protocol Format (v0.2)

Generate a

.md

file for each Test Point, following this format:

markdown

## [P1] Test Case Title
[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][Negative] Test Case Title
[Test Type] Function
[Preconditions] Precondition description
[Test Steps] 1. Step 1. 2. Step 2
[Expected Results] 1. Expected Result 1. 2. Expected Result 2

5.2 Field Explanations

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 Test Type Enumeration (12 Types)

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 Step Format Specifications

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 Test Data Requirements

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 Expected Result Requirements

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 Directory Structure

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

5.8 Merging Rules

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. Test Case Generation Process

Step 1: Prepare Context

bash

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

Step 2: Understand Test Points

For each POINT:

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

Step 3: Identify Input Items

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

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: Design Test Cases

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: Unified Verification After Generation

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. Examples

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

markdown

## [P1] Verify successful login with valid username and password
[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][Negative] Verify login failure when username is empty
[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] Verify password length boundary value (8 characters)
[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

Example 2: Comprehensive Scenario (Multiple Input Items)

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

## [P1] Verify successful filtering with single condition
[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] Verify successful filtering with multiple combined conditions
[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][Negative] Verify filtering failure when time range exceeds 365 days
[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][Negative] Verify empty return when filtering with non-existent account name
[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] Verify filter condition clear function
[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][Negative] Verify error prompt when end time is earlier than start time
[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

Example 3: Incorrect Test Cases

markdown

## [P1] Verify login success
[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. Inspection Process

Step 1: After Generating Each Test Item

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: After All Generation is Complete

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: Generate Quality Report

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

9. Checklists

Pre-Generation Check

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)

Check When Generating Each POINT

Generated case file for each POINT
Reasonable number of cases (based on scenario complexity)
All cases have priority (P1-P5)
All cases have test type (one of 12 types)
Test data is specific (no placeholders)
Expected results are verifiable (no vague descriptions)
Number of test steps matches expected results
Case titles start with "Verify"

Governance Phase Check

Executed global validation script
Checked for duplicate cases
Format complies with specifications (passed validate.py check)
Generated all_cases.md
No duplicate cases (passed validate.py --check-duplicates check)
Generated quality report

10. Script Interfaces

validate.py

bash

# Single file validation
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

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

# 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/{Module}/{Test Point}.md" -o "output.xlsx"

11. Exception Handling

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. Stop Points

✅ 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

testcase-generator

NPX Install

Tags

SKILL.md Content (Chinese)

Test Case Generator (testcase-generator)

1. Objective

2. Input & Output

3. Core Principles

Trigger Conditions

4. Core Theories

4.1 Equivalence Partitioning Method

4.2 Boundary Value Analysis Method

4.3 Test Case Quantity Judgment

5. Test Case Format Specifications

5.1 Markdown Text Protocol Format (v0.2)

5.2 Field Explanations

5.3 Test Type Enumeration (12 Types)

5.4 Step Format Specifications

5.5 Test Data Requirements

5.6 Expected Result Requirements

5.7 Directory Structure

5.8 Merging Rules

6. Test Case Generation Process

Step 1: Prepare Context

Step 2: Understand Test Points

Step 3: Identify Input Items

Step 4: Partition Equivalence Classes and Boundary Values

Step 5: Design Test Cases

Step 6: Unified Verification After Generation

7. Examples

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

Example 2: Comprehensive Scenario (Multiple Input Items)

Example 3: Incorrect Test Cases

8. Inspection Process

Step 1: After Generating Each Test Item

Step 2: After All Generation is Complete

Step 3: Generate Quality Report

9. Checklists

Pre-Generation Check

Check When Generating Each POINT

Governance Phase Check

10. Script Interfaces

validate.py

to_excel.py

11. Exception Handling

12. Stop Points