general-testcase

General Test Case Generator Skill

Overview

This skill automates the process of generating test case documents from requirements documents. It analyzes requirements content, extracts functional modules and test points, and generates structured Markdown test case documents. When users explicitly request it, it can also convert Markdown to XMind mind map format.

Core Features：

✅ In-depth requirements analysis to uncover all test details
✅ Organize test cases by complete functional flow
✅ Generate Markdown format by default, and generate XMind mind maps on demand
✅ Timestamp version management: Add a timestamp suffix on each generation to retain all historical versions

🚨 Core Principles (Required Reading)：

Analyze requirements in depth: Do not stay on the surface; analyze the requirements document sentence by sentence to uncover all test details
Cover details sufficiently: There is no upper limit on the number of verification items; every detail of core functionality must have a corresponding verification item
Do not impose artificial limits: Do not merge verification items to control quantity; every independently verifiable point should be listed separately
Quality over quantity: Prefer detailed and lengthy test cases over missing test details of core functionality
Retain historical versions: Add a timestamp on each generation so that all versions are retained for version management and comparison

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 product specifications or design documents
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 "mind map format" or "mindmap format"
The user explicitly requests generating "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 step, you must first read all 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 and requires in-depth analysis, not surface-level work.

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 Methods

You must perform an in-depth analysis of the requirements; 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 generated file to facilitate version management and historical traceability

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

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 heading)
- ## 二级标题: Functional module (use Chinese ordinals 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 markers:**测试点：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-space indentation to indicate hierarchy
- 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：
- Retain bold markers **文本**
- Support emoji and special characters
- Do not use checkbox markers [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 flow verification"

Writing verification items (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 first page 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 point that can be verified independently 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 stage (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 the requirements sentence by sentence：
- Perform an in-depth analysis of each sentence, extract test points
- Mark all conditional judgments (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 consolidate functional modules：

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

Consolidation criteria: different dimensions/levels of the same function → consolidate into one module; different functions → keep each independent.

Organize each functional module according to the following flow: 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
- Each 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 stage

Goal: design comprehensive test points for each function point

Analyze each function point one by one：
- Do not miss any function point
- Each function point contains at least one test point
- Complex function points should be split into multiple test points
Design test point types：
- Function 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 indicators 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 is normal"
- 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
- Every 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：
- Compare against the requirements document and check item by item whether there is a corresponding test case
- Ensure every requirement point is covered
- Do not miss any functional detail
Format specification check：
- Check whether the format conforms to the testcase_template.md specification
- Check whether the heading levels are correct
- Check whether the verification item format is standard
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
Whether the verification items are specific and executable
Whether any test scenarios are missing

Quality Check：

Whether test point naming follows conventions
Whether verification items comply with the SMART principles
Whether there are duplicate test points or verification items
Whether the overall structure is clear and easy to understand

Step 3: Convert to XMind format (optional)

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

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

Important Note: The conversion script has built-in format handling logic and automatically follows the conversion rules in testcase_template.md.

3.1 Script Location

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

3.2 Usage

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

Parameter Description：

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

3.3 Conversion Rules

The script automatically converts 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 (with green flag marker)

Special Handling：

Checkbox conversion：[ ] → ☐(incomplete state)
Bold handling: Keep the bold text content, remove the**markers
Level determination：
- Heading level: determined by the number of#Quantity judgment
- List level: determined by the number of indentation spaces (one level per 2 spaces)

3.4 Output Result

After conversion is complete, generate:

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

Step 4: Present the Results

After completing test case generation, you must present the complete test case document and statistics to the user.

4.1 Presentation Content

Present the Markdown file：
- Use open_result_view to display the generated test case document
- Allow the user to view and edit the Markdown source file
Report statistics：
- Total number of test points
- Total number of verification items
- Coverage by module
- 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 the number of nodes
Provide testing recommendations：
- Test priority recommendations (P0, P1, P2, P3)
- Hints on key modules to test
- Test risk warnings
- Suggestions for test environment preparation

4.2 Quality report

Provide the user with a test case quality report:

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

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

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

Packaged 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 programmatic invocation
Usage: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 hierarchies
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: In-depth requirements 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 the SMART principles, test point organization principles (by module/function/scenario/priority P0~P3), and the test coverage checklist (must-test/important/optional scenarios).

Usage examples

Common steps for all scenarios:Obtain document content → Analyze requirements in depth → Generate test cases → Quality check → Present 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 → Present 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 → Present 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 the fetch-doc skill to download the document
Analyze requirements → Generate Markdown (convert to XMind at the same time if needed) → Present results

Notes

Format requirements

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

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
A quality check 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 textual information is processed

Output Format

Default output: Generate Markdown format only
XMind trigger condition: Generated 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 display 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 reconvert it to XMind

FAQ

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 standard
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 simultaneously