Back to Details

test-cases

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Test Cases Generator

测试用例生成器

This skill generates comprehensive, requirement-driven test cases from PRD documents or user requirements.
此技能可从PRD文档或用户需求中生成全面的、以需求为导向的测试用例。

Purpose

用途

Transform product requirements into structured test cases that ensure complete coverage of functionality, edge cases, error scenarios, and state transitions. The skill follows a pragmatic testing philosophy: test what matters, ensure every requirement has corresponding test coverage, and maintain test quality over quantity.
将产品需求转换为结构化的测试用例，确保全面覆盖功能、边界场景、错误场景和状态转换。该技能遵循务实的测试理念：测试关键内容，确保每个需求都有对应的测试覆盖，并且优先保证测试质量而非数量。

When to Use

适用场景

Trigger this skill when:
  • User provides a PRD or requirements document and requests test cases
  • User asks to "generate test cases", "create test scenarios", or "plan QA"
  • User mentions testing coverage for a feature or requirement
  • User needs structured test documentation in markdown format
在以下场景触发此技能：
  • 用户提供PRD或需求文档并请求生成测试用例
  • 用户要求“生成测试用例”、“创建测试场景”或“规划QA”
  • 用户提及某个功能或需求的测试覆盖
  • 用户需要Markdown格式的结构化测试文档

Core Testing Principles

核心测试原则

Follow these principles when generating test cases:
  1. Requirement-driven, not implementation-driven - Test cases must map directly to requirements, not implementation details
  2. Complete coverage - Every requirement must have at least one test case covering:
    • Happy path (normal use cases)
    • Edge cases (boundary values, empty inputs, max limits)
    • Error handling (invalid inputs, failure scenarios, permission errors)
    • State transitions (if stateful, cover all valid state changes)
  3. Clear and actionable - Each test case must be executable by a QA engineer without ambiguity
  4. Traceable - Maintain clear mapping between requirements and test cases
生成测试用例时需遵循以下原则：
  1. 以需求为导向，而非实现为导向 - 测试用例必须直接映射到需求，而非实现细节
  2. 全面覆盖 - 每个需求必须至少有一个测试用例覆盖：
    • 正常路径（常规用例）
    • 边界场景（边界值、空输入、最大限制）
    • 错误处理（无效输入、故障场景、权限错误）
    • 状态转换（如果有状态，覆盖所有有效的状态变化）
  3. 清晰可执行 - 每个测试用例必须足够明确，QA工程师无需额外说明即可执行
  4. 可追溯 - 保持需求与测试用例之间的清晰映射

Workflow

工作流程

Step 1: Gather Requirements

步骤1：收集需求

First, identify the source of requirements:
  1. If user provides a file path to a PRD, read it using the Read tool
  2. If user describes requirements verbally, capture them
  3. If requirements are unclear or incomplete, use AskUserQuestion to clarify:
    • What are the core user flows?
    • What are the acceptance criteria?
    • What are the edge cases or error scenarios to consider?
    • Are there any state transitions or workflows?
    • What platforms or environments need testing?
首先，确定需求来源：
  1. 如果用户提供PRD的文件路径，使用Read工具读取
  2. 如果用户口头描述需求，记录下来
  3. 如果需求不明确或不完整，使用AskUserQuestion工具澄清：
    • 核心用户流程是什么？
    • 验收标准是什么？
    • 需要考虑哪些边界场景或错误场景？
    • 是否存在状态转换或工作流？
    • 需要测试哪些平台或环境？

Step 2: Extract Test Scenarios

步骤2：提取测试场景

Analyze requirements and extract test scenarios:
  1. Functional scenarios - Normal use cases from requirements
  2. Edge case scenarios - Boundary conditions, empty states, maximum limits
  3. Error scenarios - Invalid inputs, permission failures, network errors
  4. State transition scenarios - If the feature involves state, map all transitions
For each requirement, identify:
  • Preconditions (what must be true before testing)
  • Test steps (actions to perform)
  • Expected results (what should happen)
  • Postconditions (state after test completes)
分析需求并提取测试场景：
  1. 功能场景 - 需求中的常规用例
  2. 边界场景 - 边界条件、空状态、最大限制
  3. 错误场景 - 无效输入、权限失败、网络错误
  4. 状态转换场景 - 如果功能涉及状态，映射所有转换
针对每个需求，确定：
  • 前置条件（测试前必须满足的条件）
  • 测试步骤（需要执行的操作）
  • 预期结果（应该发生的情况）
  • 后置条件（测试完成后的状态）

Step 3: Structure Test Cases

步骤3：结构化测试用例

Organize test cases using this structure:
markdown
undefined
使用以下结构组织测试用例：
markdown
undefined

Test Cases: [Feature Name]

Test Cases: [Feature Name]

Overview

Overview

  • Feature: [Feature name]
  • Requirements Source: [PRD file path or description]
  • Test Coverage: [Summary of what's covered]
  • Last Updated: [Date]
  • Feature: [Feature name]
  • Requirements Source: [PRD file path or description]
  • Test Coverage: [Summary of what's covered]
  • Last Updated: [Date]

Test Case Categories

Test Case Categories

1. Functional Tests

1. Functional Tests

Test cases covering normal user flows and core functionality.
Test cases covering normal user flows and core functionality.

TC-F-001: [Test Case Title]

TC-F-001: [Test Case Title]

  • Requirement: [Link to specific requirement]
  • Priority: [High/Medium/Low]
  • Preconditions:
    • [Condition 1]
    • [Condition 2]
  • Test Steps:
    1. [Step 1]
    2. [Step 2]
    3. [Step 3]
  • Expected Results:
    • [Expected result 1]
    • [Expected result 2]
  • Postconditions: [State after test]
  • Requirement: [Link to specific requirement]
  • Priority: [High/Medium/Low]
  • Preconditions:
    • [Condition 1]
    • [Condition 2]
  • Test Steps:
    1. [Step 1]
    2. [Step 2]
    3. [Step 3]
  • Expected Results:
    • [Expected result 1]
    • [Expected result 2]
  • Postconditions: [State after test]

2. Edge Case Tests

2. Edge Case Tests

Test cases covering boundary conditions and unusual inputs.
Test cases covering boundary conditions and unusual inputs.

TC-E-001: [Test Case Title]

TC-E-001: [Test Case Title]

[Same structure as above]
[Same structure as above]

3. Error Handling Tests

3. Error Handling Tests

Test cases covering error scenarios and failure modes.
Test cases covering error scenarios and failure modes.

TC-ERR-001: [Test Case Title]

TC-ERR-001: [Test Case Title]

[Same structure as above]
[Same structure as above]

4. State Transition Tests

4. State Transition Tests

Test cases covering state changes and workflows (if applicable).
Test cases covering state changes and workflows (if applicable).

TC-ST-001: [Test Case Title]

TC-ST-001: [Test Case Title]

[Same structure as above]
[Same structure as above]

Test Coverage Matrix

Test Coverage Matrix

Requirement IDTest CasesCoverage Status
REQ-001TC-F-001, TC-E-001✓ Complete
REQ-002TC-F-002⚠ Partial
Requirement IDTest CasesCoverage Status
REQ-001TC-F-001, TC-E-001✓ Complete
REQ-002TC-F-002⚠ Partial

Notes

Notes

  • [Any additional testing considerations]
  • [Known limitations or assumptions]
undefined
  • [Any additional testing considerations]
  • [Known limitations or assumptions]
undefined

Step 4: Generate Test Cases

步骤4：生成测试用例

For each identified scenario, create a detailed test case following the structure above. Ensure:
  1. Unique IDs - Use prefixes: TC-F (functional), TC-E (edge), TC-ERR (error), TC-ST (state)
  2. Clear titles - Descriptive titles that explain what's being tested
  3. Requirement traceability - Link each test case to specific requirements
  4. Priority assignment - Mark critical paths as High priority
  5. Executable steps - Steps must be clear enough for any QA engineer to execute
  6. Measurable results - Expected results must be verifiable
针对每个识别出的场景，按照上述结构创建详细的测试用例。确保：
  1. 唯一ID - 使用前缀：TC-F（功能）、TC-E（边界）、TC-ERR（错误）、TC-ST（状态）
  2. 清晰标题 - 描述性标题，说明测试内容
  3. 需求可追溯 - 每个测试用例链接到具体需求
  4. 优先级分配 - 将关键路径标记为高优先级
  5. 可执行步骤 - 步骤必须足够清晰，任何QA工程师都能执行
  6. 可衡量结果 - 预期结果必须可验证

Step 5: Validate Coverage

步骤5：验证覆盖范围

Before finalizing, verify:
  1. Every requirement has at least one test case
  2. Happy path is covered for all user flows
  3. Edge cases are identified for boundary conditions
  4. Error scenarios are covered for failure modes
  5. State transitions are tested if feature is stateful
If coverage gaps exist, generate additional test cases.
最终确定前，验证：
  1. 每个需求至少有一个测试用例
  2. 所有用户流程的正常路径都已覆盖
  3. 边界条件的边界场景已识别
  4. 故障模式的错误场景已覆盖
  5. 如果功能有状态，状态转换已测试
如果存在覆盖缺口，生成额外的测试用例。

Step 6: Output Test Cases

步骤6：输出测试用例

Write the test cases to 
tests/<name>-test-cases.md
where 
<name>
is derived from:
  • The feature name from the PRD
  • The user's specified name
  • A sanitized version of the requirement title
Use the Write tool to create the file with the structured test cases.
将测试用例写入
tests/<name>-test-cases.md
，其中
<name>
来源于：
  • PRD中的功能名称
  • 用户指定的名称
  • 需求标题的 sanitized 版本
使用Write工具创建包含结构化测试用例的文件。

Step 7: Summary

步骤7：总结

After generating test cases, provide a brief summary in Chinese:
  • Total number of test cases generated
  • Coverage breakdown (functional, edge, error, state)
  • Any assumptions made or areas needing clarification
  • File path where test cases were saved
生成测试用例后，提供中文的简要总结：
  • 生成的测试用例总数
  • 覆盖情况细分（功能、边界、错误、状态）
  • 所做的任何假设或需要澄清的领域
  • 测试用例保存的文件路径

Quality Checklist

质量检查清单

Before finalizing test cases, verify:
  • Every requirement has corresponding test cases
  • Happy path scenarios are covered
  • Edge cases include boundary values, empty inputs, max limits
  • Error handling covers invalid inputs and failure scenarios
  • State transitions are tested if applicable
  • Test case IDs are unique and follow naming convention
  • Test steps are clear and executable
  • Expected results are measurable and verifiable
  • Coverage matrix shows complete coverage
  • File is written to tests/<name>-test-cases.md
最终确定测试用例前，验证：
  • 每个需求都有对应的测试用例
  • 正常路径场景已覆盖
  • 边界场景包含边界值、空输入、最大限制
  • 错误处理覆盖无效输入和故障场景
  • 适用的话，状态转换已测试
  • 测试用例ID唯一且遵循命名规范
  • 测试步骤清晰可执行
  • 预期结果可衡量、可验证
  • 覆盖矩阵显示全面覆盖
  • 文件已写入tests/<name>-test-cases.md

Example Usage

示例用法

User: "Generate test cases for the user authentication feature in docs/auth-prd.md"
Process:
  1. Read docs/auth-prd.md
  2. Extract requirements: login, logout, password reset, session management
  3. Identify scenarios: successful login, invalid credentials, expired session, etc.
  4. Generate test cases covering all scenarios
  5. Write to tests/auth-test-cases.md
  6. Summarize coverage in Chinese
用户：“为docs/auth-prd.md中的用户认证功能生成测试用例”
流程：
  1. 读取docs/auth-prd.md
  2. 提取需求：登录、登出、密码重置、会话管理
  3. 识别场景：成功登录、无效凭证、过期会话等
  4. 生成覆盖所有场景的测试用例
  5. 写入tests/auth-test-cases.md
  6. 用中文总结覆盖情况

References

参考资料

For detailed testing methodologies and best practices, see:
  • references/testing-principles.md
    - Core testing principles and patterns
有关详细的测试方法论和最佳实践，请参阅：
  • references/testing-principles.md
    - 核心测试原则和模式