req-testcases

name

req-testcases

description

Generate comprehensive test cases from already analyzed or decomposed requirements specifications. Use when the input is a completed requirements breakdown, feature specification, PRD analysis, user story map, acceptance criteria list, or module/function requirements and the user wants test case design, scenario expansion, module-based test flows, coverage review, or exportable test case documents in Markdown, Excel/XLSX, CSV, or document formats.

Requirements To Testcases

Purpose

Convert a completed requirements breakdown into a complete, reviewable test case set. Preserve the requirement structure, cover every explicit requirement and reasonable extension point, and organize cases by module/function so execution follows a coherent user or business flow.

Language Requirement

Always write the final user-facing test cases in Chinese unless the user explicitly requests another language. This applies to module names, function names, case titles, preconditions, steps, expected results, priorities, case types, test data, notes, coverage matrices, assumptions, and export file content.

Keep Chinese output clear and direct. Prefer concise, executable wording such as “输入正确手机号并提交” and observable expected results such as “系统提示发送成功，并生成一条短信发送记录”. Avoid vague phrases such as “功能正常” or “符合预期” unless paired with a concrete observable result.

Required Input Assumption

Assume the user has already provided decomposed requirements. If the input is raw, ambiguous, or only a product idea, first state that the requirements need decomposition and ask for the missing specification unless the user explicitly asks to infer.

Accepted inputs include:

• Requirement specification after analysis
• Feature/module breakdown
• User stories with acceptance criteria
• Flow descriptions with business rules
• API/interface requirement lists
• Existing requirement traceability tables

Core Workflow

1. Parse the requirement structure.

   • Identify modules, functions, roles, states, data objects, business rules, constraints, integrations, and non-functional requirements.
   • Preserve requirement IDs when present. If missing, assign stable IDs such as REQ-01, REQ-02.

2. Build a requirement coverage map.

   • Map each requirement to at least one positive test case.
   • Add negative, boundary, exception, permission, compatibility, data integrity, and regression cases where relevant.
   • Include requirement extension points: implicit variants, edge conditions, dependent flows, state transitions, abnormal inputs, concurrency, rollback, notification, audit, and integration failure paths.

3. Design by module and execution flow.

   • Group cases by module/function, then order them according to a reasonable testing path: setup -> basic success path -> rule branches -> boundary/negative cases -> cross-module/integration -> cleanup or regression.
   • Avoid one case per tiny point when related checks can share one coherent scenario.
   • Split cases when expected results differ materially, setup differs materially, or one case would become hard to execute/debug.

4. Produce test cases.

   • Use clear case titles that describe behavior under test.
   • Make steps executable, not vague.
   • Make expected results observable and verifiable.
   • Add priority and case type.
   • Include traceability back to requirement IDs.

5. Validate before delivery.

   • Check every requirement has coverage.
   • Check important extension points are covered.
   • Check modules are ordered logically.
   • Check cases are not duplicated, fragmented, or overloaded.
   • Flag assumptions, gaps, and requirements that need clarification.

Output Fields

Use a lean default case table. These fields are required unless the user provides a company template:

字段	用途
用例编号	Stable ID such as TC-MODULE-001; required for tracking and coverage matrix links.
所属模块	Requirement module or business area; required for module-based execution flow.
需求编号	Source requirement ID(s); required for traceability.
测试场景	Short behavior under test; required for quick review.
前置条件	Required user, data, state, config, or environment; required for executable cases.
操作步骤	Numbered executable steps; required.
预期结果	Observable and verifiable result; required.
优先级	P0/P1/P2/P3; required for execution planning.
用例类型	正向、反向、边界、权限、集成、数据、兼容性、性能、安全、回归等; required for coverage balance.

Optional fields. Add them only when they materially improve execution or match the user's template:

字段	何时使用
功能点	Only when a module contains many distinct sub-functions and scenario names alone are not enough to group cases.
测试数据	Only when test data is complex, reusable, or must be prepared separately. Otherwise include it in 前置条件 or 操作步骤.
备注	Avoid in the main case table by default. Put assumptions, dependencies, risks, and clarification items in 假设与待确认.

If the user provides a company template, follow that template exactly even when it includes more fields.

Output Formats

• For Markdown: produce module sections and tables. Keep long steps readable with numbered lists inside cells only when necessary.
• For XLSX: use the spreadsheets skill when available. Create one workbook with:
  • 测试用例 sheet for all cases
  • 需求覆盖矩阵 sheet mapping requirement IDs to case IDs
  • 假设与待确认 sheet for gaps and assumptions
• For CSV: use the lean default case table unless the user requests optional fields.
• For DOCX/PDF: use the appropriate document skill when the user requests a formal report.

Quality Rules

Read references/testcase-design.md when producing a real test case set or reviewing coverage.

Do not:

• Invent business rules that contradict the requirement.
• Hide uncertainty inside test cases. Put uncertainty in assumptions or clarification notes.
• Collapse unrelated modules into one long scenario.
• Generate only happy-path cases.
• Ignore non-functional requirements when the input mentions performance, security, audit, compatibility, availability, usability, or compliance.

Delivery Checklist

Before final response, report:

• Number of modules covered.
• Number of requirements covered.
• Number of test cases produced.
• Output files created, if any.
• Remaining assumptions or clarification items.