Req Testcases

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.

Output Types

Case design content (scenario expansion, coverage, ordering) is identical across all types; only output fields and format differ:

Generate only the types the user requests. If the request does not specify a type, ask which type(s) to generate before producing output.

AI自测用例 feasibility check: generating AI自测用例 requires that the AI can actually execute the verification — a reachable service/interface, a runnable build artifact, or command-line/filesystem access to the target environment. When these conditions are absent (typical cases: C++ desktop/GUI projects with no API surface, embedded target hardware not available, cross-compiled artifacts that cannot run locally, verification that depends entirely on physical hardware or human senses), do not force command-level cases. Tell the user why AI自测 is infeasible and switch to generating 人工自测用例 instead — the case design content stays the same, only the output template changes. If the user explicitly insists on AI自测用例 anyway, generate them but annotate in each affected case what execution environment is required.

Language Requirement

Always write the final user-facing test cases in Chinese unless the user explicitly requests another language. This applies to module names, case names, preconditions, steps, expected results, priorities, case types, life stages, 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 for internal coverage checks.

2. Build a requirement coverage map (internal check, not a deliverable).

   • 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 with the template of each selected output type (see Output Templates).

   • Number multi-line steps and expected results so they correspond one-to-one.
   • Keep requirement-ID traceability in the internal coverage check only; do not put it in deliverables.

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.
   • State expected results directly. For undefined behavior pick a reasonable default; only note it as a one-line assumption on the relevant case when it matters. Do not accumulate clarification items.

Output Templates

All templates group cases under ## 模块：<模块名> headings and follow the ordering rules in references/testcase-design.md.

1. AI自测用例

For AI self-testing after development is complete: steps must be commands/interfaces the AI can invoke directly, and expected results must be machine-verifiable assertions. When generating, if implementation code exists, first read the backend routes, parameter contracts, and filesystem/systemd side effects, and write the real endpoints and assertion points into the cases.

Writing rules:

• Steps are concrete commands the AI can execute directly (curl/ssh/filesystem operations), not UI clicks; interface paths, parameter fields, and status codes follow the actual implementation.
• Expected results are machine-checkable assertions: HTTP status code and response fields, command stdout, file existence and content, process/systemd state. Never write “Toast 提示成功” or “界面显示正常” style results.
• Prefer assertion points that are implementation-independent facts (systemd state, deploy directory artifacts, downloaded file content, log file records) so most assertions still hold if the interface implementation changes.
• UI visual cases (theme/font/layout/visual feedback) are not verifiable by the AI: keep only page and static-resource reachability checks, and state explicitly that visual verification is delegated to 人工自测用例.
• If the implementation lacks a requirement feature, keep the case, note the missing interface, and count it as “未执行” in the final summary.

Document conventions:

• Put 执行约定 and 测试资产与环境 (access address, terminal access, sample file paths and how to prepare them, response contract) at the document head.
• Execute in document order; change [ ] to [x] immediately after each case is verified. A failure stays [ ]; report 用例名 + executed command + key output in the reply.
• After all cases finish, output a summary: 总数 / 通过 / 失败 / 未执行.

2. 系统测试用例

Columns and order follow the team test template exactly:

• 用例名称: 一级模块-二级模块/功能-测试点+测试, e.g. 设置-工位设置-工厂名称输入测试.
• 优先级: 高 / 中 / 低 (criteria in the reference).
• 测试用例类型: 功能（默认）/ 异常 / 性能 / 安全 / 兼容.
• 生命阶段: required; values follow the project's stage definitions, e.g. [初始化]; default to [初始化] when there is no definition.

3. 人工自测用例

• Keep only these three columns plus module headings; add no other fields.
• Related checks of one scenario may merge into a single row; steps and expected results stay number-aligned.

Export Formats

• Default output is Markdown files per the templates above.
• XLSX (when the user requests it): applies to 系统测试用例. Create one workbook with a single 测试用例 sheet using the 系统测试用例 columns. Column widths follow references/testcase-design.md.
• DOCX/PDF (when the user requests a formal document): use an available document skill.

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. State expected results with reasonable defaults; add a one-line assumption note on the relevant case only when it matters.
• 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:

• Output types generated and their file paths.
• Number of modules covered.
• Number of requirements covered (from the internal coverage check).
• Number of test cases produced per type.
• One-line notes of key assumptions, if any.