test-case-design

测试用例设计与验证技能

前置依赖

调用本 skill 前需读 skill: document-norms §1（文档归属矩阵）/ §2（frontmatter 字段标准，特别是 type=test-case + §2.6 req_slug+sub_req_slug 引用契约）。modules/ 体系下用例落盘到 projects/modules/<basic>/<sub>/requirements/<req_slug>/<sub_req_slug>/test-cases/，YAML 顶层字段 type: test-case + module: <basic>/<sub> + req_slug: <req_slug> + sub_req_slug: <sub_req_slug> 必填（version 字段已废除）。

适用场景

• @qa 收到 pending_qa 状态的任务时
• 代码变更后需要做功能验证时
• 回归验证时

五步流程

第 1 步：解析验收标准

读取需求来源，提取验收标准：

来源	提取内容
projects/modules/<basic>/<sub>/requirements/<req_slug>/<sub_req_slug>/prd.md	GWT 场景式 AC 和规则式 AC
Issue	Bug 的复现场景和期望修复结果
@dev 交付说明	改动点和 QA 关注点
历史相关功能 / current-state/	需要回归的已有能力

第 2 步：用例矩阵生成

基于 AC 和代码变更，生成三类测试用例。

落盘路径：projects/modules/<basic>/<sub>/requirements/<req_slug>/<sub_req_slug>/test-cases/<TC-ID>.yaml

YAML 顶层字段（不是 markdown frontmatter——test-case 文件本身就是 .yaml）：需含 type: test-case（document-norms §2.3 文档类型枚举）+ case_type: happy_path|sad_path|boundary（用例细分类）+ module: <basic>/<sub> + req_slug: <req_slug> + sub_req_slug: <sub_req_slug> + case_id + ac_ref + preconditions + steps + expected 等业务字段（三类用例的字段 schema 见本 skill 下文，不在 document-norms）。version 字段已废除。

schema 说明：type 字段沿用 document-norms 全局文档类型分类（取值 test-case），与 PRD/spec/decision 等并列；case_type 是测试用例内部的细分类，独立字段，不与 type 冲突。

2.1 Happy Path（正向流）

验证"一切正常时的预期行为"。

# document-norms §2.1 通用必填字段
type: test-case          # §2.3 文档类型（固定值）
status: draft            # draft | in_progress | approved | implemented | deprecated | superseded
owner_role: qa
updated: <ISO-8601 带时区>  # §2.7
related: []
tags: []
# modules/ 体系下还需补：module: "<basic>/<sub>" / req_slug: "<req_slug>" / sub_req_slug: "<sub_req_slug>"
# test-case 细分类（独立字段，不与 §2.3 type 冲突）
case_type: happy_path    # happy_path | sad_path | boundary
case_id: TC-HP-001
ac_ref: AC-01
preconditions: "{前置条件}"
steps:
  - "{操作1}"
  - "{操作2}"
expected: "{期望结果}"

2.2 Sad Path（异常流）

验证"异常情况的处理"。