general-testcase

General Test Case Generator Skill

Overview

This skill automates the process of generating a test case document from a requirements document. It analyzes the requirements content, extracts functional modules and test points, and generates a structured Markdown test case document. When the user explicitly requests it, it can also convert the Markdown into XMind mind map format.

Core Features：

✅ In-depth requirements analysis, uncovering all testing details
✅ Organize test cases by complete functional flow
✅ Generate Markdown format by default, generate XMind mind maps on demand
✅ Timestamp version management: Each generation adds a timestamp suffix, retaining all historical versions

🚨 Core Principles (Must Read)：

Analyze requirements in depth: Do not stay on the surface; you must analyze the requirements document sentence by sentence and uncover all testing details
Fully cover details: There is no upper limit on the number of verification items; every detail of the core functionality must have a corresponding verification item
Do not impose artificial limits: Do not merge verification items just to control the count; every independently verifiable point should be listed separately
Quality over quantity: Better to have detailed and lengthy test cases than to omit testing details of core functionality
Retain historical versions: Add a timestamp to each generation; all versions are retained, making version management and comparison easier

When to Use This Skill

Use this skill in the following situations:

The user provides a requirements document and requests test case generation
The user requests creating test cases from a product specification or design document
The user needs to convert an existing requirements document into test cases
The user mentions keywords such as "test cases", "test cases", "requirements document"

XMind Generation Trigger Conditions：

The user explicitly requests generating the "mind map format" or "mindmap format"
The user explicitly requests generating the "xmind format"
The user requests "generate both md and xmind"

Default Behavior: Generate only the Markdown-format test case document

Workflow

Step 0: Initialization (must be executed first)

🚨 Before executing any other steps, you must first read all of the following reference documents! This is mandatory and cannot be skipped.

必须依次读取以下文件：
1. {skills_dir}/references/testcase_template.md   — 格式规范（生成文档必须严格遵守）
2. {skills_dir}/references/analysis_guide.md      — 需求分析方法和验证项生成示例
3. {skills_dir}/references/quality_standard.md    — 质量标准、命名规范、SMART原则
4. {skills_dir}/references/module_merge_guide.md  — 功能模块归并指南和示例

After reading is complete, use the contents of these documents as the basis for executing all subsequent steps.

Step 1: Read and analyze the requirements document

Read the requirements document content from the provided source (file path or direct content).This step is key to test case quality; you must analyze in depth and not stay on the surface.

1.1 Document Reading

Important Note：

If the requirements are provided as a URL (such as a Feishu document),first try to read the document content directly, and if the content cannot be obtained, then try using the fetch-doc skill to download the document
If the requirement is provided as a file path, read the file content directly
Focus on the text content; ignore images unless they contain key information

1.2 In-depth Requirement Analysis Method

Requirements must be analyzed in depth; do not stop at the surface! See references/analysis_guide.md。

Use the following five analysis methods to mine test details sentence by sentence:

Sentence-by-sentence analysis method: Identify conditional words/action words/state words/data words, and extract the verification item corresponding to each element
Business process analysis method: Identify process nodes, decision branches, and abnormal exits; every node must have a test point
Data flow analysis method: Trace the complete chain of data acquisition → processing → storage → display
State transition analysis method: Identify all states and transition conditions; every state transition must have a verification item
User scenario analysis method: Analyze from the perspectives of different roles and normal/abnormal/extreme scenarios

1.3 Organizing Analysis Results

Organize the analysis results into: a functional module list, a business rule list, an abnormal scenario list, and a test data list.

Step 2: Generate the Markdown test case document

Important note: You must strictly follow the format specifications defined in references/testcase_template.md !

2.0 File Naming Rules

Core principle: Add a timestamp suffix to every generation for easy version management and historical tracing

This skill uses an automated script to add a timestamp suffix to each test case file, ensuring that all versions are retained for easy comparison and tracing.

2.0.1 Naming Rules

File name format：

{需求文档名称}-v{MMdd_HHmmss}.md
{需求文档名称}-v{MMdd_HHmmss}.xmind

Timestamp format：

Format:MMdd_HHmmss(month-day_hour-minute-second)
Example:0318_143052 represents March 18, 14:30:52

2.0.2 Usage

python3 scripts/generate_filename.py "<base_name>" "<output_dir>"
# 输出JSON：{"md_file": "...", "xmind_file": "...", "base_name": "..."}

2.1 Standard Format Structure

Create the Markdown test case document according to the following standard structure:

# {产品需求名称} - 测试用例

## 一、{功能模块名称}

### 1.1 {子功能名称}

#### 1.1.1 {功能点名称}
- **测试点：{测试点名称}**
  - [ ] {验证项1}
  - [ ] {验证项2}
  - [ ] {验证项3}

- **测试点：{测试点名称}**
  - [ ] {验证项1}
  - [ ] {验证项2}

### 1.2 {子功能名称}

#### 1.2.1 {功能点名称}
- **测试点：{测试点名称}**
  - [ ] {验证项1}

2.2 Format Specification Requirements

Format rules that must be followed：

Heading level specifications：
- # 一级标题: Product name (document root title)
- ## 二级标题: Functional module (use Chinese numbering such as "一、二、三、")
- ### 三级标题: Sub-function (use numbering such as "1.1、1.2、2.1、")
- #### 四级标题: Function point (use numbering such as "1.1.1、1.1.2、")
Test point format specifications：
- Must use bold markup:**测试点：XXX验证**
- Test point names should be specific and clear, describing the verification objective
- Example:**测试点：触发条件验证**、**测试点：展示验证**
Verification item format specifications：
- Must use the to-do item format:- [ ] 验证项内容
- Use 2 spaces of indentation to indicate hierarchical relationships
- Each verification item should be specific, executable, and verifiable
- Avoid vague descriptions; for example, "verify the function works normally" should be changed to "verify that clicking the button navigates to the correct page"
Text processing specifications：
- Preserve bold markup **文本**
- Support emoji and special characters
- Do not use checkbox markup [x]; uniformly use [ ]

2.3 Test Case Generation Quality Standards

The following quality standards must be followed when generating test cases, see references/quality_standard.md。

Required test types: Functional testing, UI/UX testing, exception scenario testing (network/data/concurrency/permissions) Recommended test types: Boundary condition testing, performance testing, compatibility testing, security testing

Test point naming：{对象}{类型}验证, such as "trigger condition verification", "network exception verification", "login process verification"

Verification item writing (SMART principles)：

❌ Incorrect: Verify the function works normally → ✅ Correct: Verify that after clicking the "Submit" button, the form data is successfully submitted to the server
❌ Incorrect: The page loads quickly → ✅ Correct: The page's first load time does not exceed 2 seconds

Number of verification items：No upper limit, core functions must fully cover all conditional branches, business rules, boundary cases, exception handling, and state transitions. Every independently verifiable point should be listed separately; do not merge them artificially.

2.4 Test case generation process

When generating test cases, please strictly follow the process below:

2.4.1 Requirements analysis phase (most important)

Goal: deeply understand the requirements and uncover all testing details

Read through the requirements document：
- Carefully read the entire requirements document; do not skip any part
- Understand the business background and target users
- Identify key business processes and core value
Analyze requirements sentence by sentence：
- Perform in-depth analysis of every sentence, extract test points
- Mark all conditional judgments (if/when/if/when...时)
- Mark all action operations (click/input/select/submit, etc.)
- Mark all state changes (display/hide/enable/disable, etc.)
- Mark all data interactions (create/read/update/delete, etc.)
Identify and merge functional modules：

🚨 Core principle: organize tests by complete functional flow, not by requirements document chapters, see references/module_merge_guide.md。

Merging criteria: different dimensions/layers of the same function → merge into one module; different functions → each remains independent.

Each functional module is organized according to the following process: trigger condition verification → business rule verification → data preparation verification → display content verification → interaction behavior verification → result handling verification.
Extract business rules：
- Record all business rules and constraints
- Every rule should be converted into a verification item
- Pay attention to implicit business logic
Uncover exception scenarios：
- Think about possible exception situations for each function
- Network exceptions, data exceptions, permission exceptions, etc.
- Boundary conditions and extreme cases
Analyze user scenarios：
- Think about usage scenarios from the user's perspective
- Consider the behavior of different user roles
- Consider different usage environments

For detailed requirements analysis examples, see references/analysis_guide.md。

2.4.2 Test point design phase

Goal: design comprehensive test points for each function point

Analyze function points one by one：
- Do not miss any function point
- Each function point contains at least one test point
- Complex feature points should be split into multiple test points
Design test point types：
- Functional verification type: verify whether the function works as expected
- Display verification type: verify whether the UI display is correct
- Interaction verification type: verify whether user interaction is smooth
- Exception verification type: verify whether exception handling is reasonable
- Performance verification type: verify whether performance metrics meet standards
- Security verification type: verify whether security measures are in place
Consider test scenarios：
- Positive scenario: normal business process
- Negative scenario: abnormal and error situations
- Boundary scenario: critical values and extreme values
- Concurrency scenario: multiple users or multiple operations

2.4.3 Verification Item Writing Stage

Objective: Write detailed and executable verification items for each test point

Refine each test point：
- Break down test points into specific verification steps
- Each verification item corresponds to one executable test operation
- Do not limit the number of verification items; ensure sufficient coverage
Use specific descriptions：
- Avoid vague descriptions such as "verify the function works normally"
- Use specific descriptions such as "verify that after clicking the XX button, it jumps to the XX page"
- Include preconditions, operation steps, and expected results
Cover all details：
- Do not miss any detail in the requirements
- Each detail should have a corresponding verification item
- Better to write more than to write less
Annotate test data：
- Clarify the data types required for testing
- Annotate special test data requirements
- Explain the data preparation method

2.4.4 Quality Check Stage

Objective: Ensure the completeness and accuracy of test cases

Requirement coverage check：
- Against the requirements document, check item by item whether there is a corresponding test case
- Ensure every requirement point is covered
- Do not omit any functional detail
Format specification check：
- Check whether the format complies with the testcase_template.md specification
- Check whether the heading levels are correct
- Check whether the verification item format is standardized
Verification item quality check：
- Check whether the verification items are specific and clear
- Check whether the verification items are executable
- Check whether the verification items have omissions
Duplication check：
- Check whether there are duplicate test points
- Check whether there are duplicate verification items
- Merge or delete duplicate content

2.5 Quality Check Checklist

After generating test cases, the following checks must be performed:

Format check：

Whether the heading levels are correct (#, ##, ###, ####)
Whether test points use bold markers
Whether verification items use - [ ] format
Whether indentation uses 2 spaces

Content check：

Whether all functional modules are covered
Whether functional testing, exception testing, and boundary testing are included
Is the verification item specific and executable
Are there any missing test scenarios

Quality Check：

Is the test point naming standardized
Do the verification items comply with the SMART principles
Are there duplicate test points or verification items
Is the overall structure clear and easy to understand

Step 3: Convert to XMind format (optional)

🚨 Important Notice: This step is performed only when the user explicitly requests to generate a "mind map format" or "xmind format". By default, skip this step.

After generating the Markdown document, if the user requests the mind map format, use the conversion script to convert it to XMind format.

Important Notice: The conversion script has built-in format handling logic and will automatically follow the conversion rules in testcase_template.md.

3.1 Script Location

scripts/md_to_xmind.py: A Python script that converts a Markdown test case document to XMind format

3.2 Usage

python3 {skills_dir}/scripts/md_to_xmind.py <input.md> <output.xmind> [title]

Parameter Description：

input.md: The path of the generated Markdown test case document (must conform to the testcase_template.md format)
output.xmind: The output XMind file path
title: (Optional) XMind worksheet title, default is "Test Cases"

3.3 Conversion Rules

The script will automatically convert according to the following rules:

Markdown to XMind Mapping：

Markdown Element	XMind Element	Description
`# 一级标题`	Root Topic	Product Name
`## 二级标题`	First-level Subtopic	Functional Module
`### 三级标题`	Second-level Subtopic	Sub-function
`#### 四级标题`	Third-level Subtopic	Function Point
`- 测试点：XXX`	Fourth-level Subtopic	Test Point (with blue star)
`- [ ] 验证项`	Fifth-level Subtopic	Verification Item (marked with green flag)

Special Handling：

Checkbox Conversion：[ ] → ☐(incomplete status)
Bold Handling: Keep the bold text content, remove the**markers
Level Determination：
- Heading level: Based on#quantity determination
- List level: Determined by the number of indentation spaces (one level per 2 spaces)

3.4 Output Result

After the conversion is complete, generate:

A valid XMind 3.0+ format file
Can be opened normally in XMind or XMind Zen
Preserves the complete hierarchical structure and formatting
Supports further editing and beautification

Step 4: Display Results

After completing the test case generation, the complete test case document and statistics must be shown to the user.

4.1 Display Content

Display the Markdown file：
- Use open_result_view to display the generated test case document
- Allow users to view and edit the Markdown source file
Report Statistics：
- Total number of test points
- Total number of verification items
- Coverage情况 by module classification
- Distribution of test types (functional testing, exception testing, performance testing, etc.)
Provide the XMind file path(only when XMind has been generated):
- Inform the user of the full path of the XMind file
- Explain the file size and number of nodes
Provide testing recommendations：
- Test priority recommendations (P0, P1, P2, P3)
- Key module testing tips
- Testing risk tips
- Test environment preparation recommendations

4.2 Quality Report

Provide the user with a test case quality report:

📊 测试用例统计信息：
- 总测试点数：XX个
- 总验证项数：XX个
- 平均每个测试点验证项数：XX个

📈 测试覆盖情况：
- 功能测试：XX个测试点（XX%）
- 异常测试：XX个测试点（XX%）
- 性能测试：XX个测试点（XX%）
- 兼容性测试：XX个测试点（XX%）

✅ 质量检查结果：
- 格式规范：通过
- 完整性检查：通过
- 具体性检查：通过

Packaging Resources

Scripts

scripts/generate_filename.py: test case file name generator, automatically adds a timestamp suffix

Add a timestamp suffix on every generation (format: -vMMdd_HHmmss)
Output the file path in JSON format for easy program invocation
How to use:python3 scripts/generate_filename.py "<base_name>" "<output_dir>"

scripts/md_to_xmind.py: a Python script that converts Markdown test case documents into XMind format

Supports multi-level heading hierarchy
Preserves the test point format
Converts checkbox markers (☐ means unchecked, ☑ means checked)
Generates valid XMind 3.0+ format

Reference Materials

references/testcase_template.md: test case document format specification (standard structure, format examples, XMind mapping rules)

references/analysis_guide.md: requirements in-depth analysis guide (sentence-by-sentence analysis method, business process/data flow/state transition/user scenario analysis methods, detailed examples of verification item generation)

references/quality_standard.md: test case quality standards (test coverage types, naming conventions, SMART principles, best practices, test coverage checklist)

references/module_merge_guide.md: functional module consolidation guide (chapter relationship identification, consolidation judgment criteria, test structure design, consolidation examples)

Best Practices

See references/quality_standard.mdfor details, including: detailed explanation of SMART principles, test point organization principles (by module/function/scenario/priority P0~P3), test coverage checklist (must-test/important/optional scenarios).

Usage Examples

Common steps for all scenarios:Obtain document content → deeply analyze requirements → generate test cases → quality check → display results

Example 1: Generate test cases from a local document

User: "Generate test cases based on this requirements document" → Read the file directly → analyze requirements → generate Markdown → display results + statistics

Example 2: Generate mind map format

User: "Generate test cases in mind map format based on this requirements document" → Read the document → generate Markdown → execute the XMind conversion script → display Markdown + inform of the XMind path

Example 3: Generate test cases from an online document (Feishu/Tencent Docs, etc.)

User: "Generate test cases based on this Feishu document https://xxx.feishu.cn/xxx "

First try to read the URL content directly; if it cannot be obtained, use fetch-doc skill to download the document
Analyze requirements → generate Markdown (if XMind is needed, convert at the same time) → display results

Notes

Format Requirements

Must strictly follow references/testcase_template.md the format specifications defined in
All generated test case documents must conform to standard Markdown format
The conversion script depends on the standard format; format errors may cause conversion failure

Quality Assurance

Test case quality depends on the clarity and completeness of the requirements document
Each verification item must be specific, executable, and verifiable
Must include multiple test types such as functional testing, exception testing, and boundary testing
Quality checks must be performed after generation

Usage Restrictions

This skill focuses on generating test cases from requirements documents
Generating test cases from code or databases is not supported
For very large documents, it is recommended to split them into multiple modules and generate separately
Image content will be ignored; only text information is processed

Output Format

Default output: Generate Markdown format only
XMind trigger condition: Generate only when the user explicitly requests "mind map format" or "xmind format"
Markdown documents facilitate version control and collaborative editing
XMind mind maps facilitate visual presentation and review

Subsequent Maintenance

Test cases need to be regenerated when requirements change
It is recommended to regularly review and update test cases
You can manually edit the Markdown document and then convert it to XMind again

Frequently Asked Questions

Incorrect format: Check whether it conforms to the testcase_template.md specification, and regenerate
XMind conversion failed: Check whether the Markdown heading levels and test point format are standardized
Incomplete coverage: Provide a more detailed requirements document, or manually supplement the missing scenarios
Filename timestamp: Automatically add the -vMMdd_HHmmss suffix on each generation, retaining all historical versions
Generate XMind only: Not supported; XMind must be converted from Markdown, and both formats are generated at the same time