qa-test-case-design

SKILL.md

---
name: qa-test-case-design
slug: qa-test-case-design
displayName: Test Case Design
version: 1.7.5
description: >-
  当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。适用于将前面的分析产出物整合为 P0-P3 分级、可追溯的标准格式测试用例。

when_to_use: 用户说"设计测试用例"、"用例评审"、"用例覆盖"、"测试用例设计"、"用例模板"、"用例规范"、"用例格式"、需要测试用例结构指导、需要编写或规范测试用例时
allowed-tools: Read Grep Glob
related_skills:
  upstream:
    - qa-req-deconstruction      # 输入：需求解构结果
    - qa-boundary-deep-dive      # 输入：边界分析结果
    - qa-scenario-tree           # 输入：场景树构建结果
  downstream:
    - qa-test-skills           # 输出：测试用例设计结果
    - qa-expert-review           # 输出：用例评审反馈
    - qa-regression-testing
references:
  - references/coverage-and-quality.md
  - references/design-methods.md
  - references/review-standards.md
input_format:
  required:
    - name: 需求描述
      type: string
      description: 功能需求的详细说明
  optional:
    - name: 场景分析
      type: object
      description: 来自qa-scenario-tree的场景树
    - name: 边界条件
      type: object
      description: 来自qa-boundary-deep-dive的边界分析结果
    - name: 业务背景
      type: string
      description: 业务目标和用户角色
output_format:
  structure:
    - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）
    - 覆盖率：标注口径（基于现有需求/输入文档），禁止"全覆盖/100%"绝对化表述；缺失模块标注"未覆盖+原因"
    - test_case_id: "TC_模块_功能_序列"
    - test_type: "功能/性能/安全/兼容性"
    - priority: "P0/P1/P2/P3"
    - test_title: "测试标题"
    - preconditions: "预置条件"
    - test_steps: "留空（用户补充）"
    - expected_results: "预期结果"
  traceability:
    - 每个用例带唯一ID（TC_{模块缩写}_{功能缩写}_{序号}，如 TC_API_LOGIN_001）
    - 关联需求ID（TC_{需求模块缩写}_{功能缩写}_{序号}）
    - 关联场景ID（TC_{场景模块缩写}_{功能缩写}_{序号}）
depth_requirement_quantification:
  reference_value: "根据需求复杂度调整用例设计深度：简单×2/中等×3/复杂×4"
  minimum: "用例总数不低于需求点的3倍"
categories: ['Development','Testing']
error_recovery_guidance:
  on_failure: "用例设计遗漏维度时回退到边界分析和场景树补充"
  retry_behavior: "补充上游后重新设计用例"
---
# 高级测试用例设计专项

## 核心原则

测试用例设计的核心——明确"测什么"，而非"怎么测"。

我们专注于：用例结构设计、场景覆盖策略、分类优先级、测试点识别组织。

> **重要限制**：禁止读取代码——测试用例必须基于需求文档，不得读取代码实现。确保验证"系统应该做什么"，而非"系统如何实现"。
>
> 详细的设计方法、覆盖策略和评审标准参见 `references/` 目录：
> - `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖
> - `references/coverage-and-quality.md` — 覆盖维度 + 质量指标
> - `references/review-standards.md` — 需求文档要求 + 评审标准

## 设计理念

### 为什么测试步骤留空？

```
同一个"登录"功能，不同系统实现完全不同。
AI不知道你们系统用的是哪种实现方式：
- 强制生成步骤 → 步骤与实际不符 → 测试人员需要大量修正 → 增加工作量
- 测试步骤留空 → 用户基于实际系统补充 → 只需补充细节 → 减少工作量
```

## 测试用例结构设计

**重要：输出格式、用例分级、编号规则是固定的，必须严格遵守。**

### 标准用例字段模板

> 📖 完整的字段模板、用例编号规则、级别定义、输出格式和报告结构详见 [`references/output-template-full.md`](references/output-template-full.md)。
>
> 本节保留核心字段概览，详细模板按需加载以节省 context。

## 使用方法

### 触发场景

当用户提供以下类型的请求时，此技能自动激活：

1. **生成测试用例**："帮我设计用户登录功能的测试用例"
2. **完善用例**："这些测试用例不够全面，请补充异常场景"
3. **审查用例**："检查一下这些测试用例是否有遗漏"
4. **评审辅助**："我需要准备测试用例评审，生成一套完整的用例"
5. **覆盖优化**："这个功能还缺哪些测试场景"
6. **质量评估**："评估一下这些测试用例的质量"

### 输入要素

为生成高质量的测试用例，尽量提供以下信息：

1. **需求描述**：功能需求的详细说明
2. **业务背景**：该功能在整体产品中的定位
3. **约束条件**：技术限制、合规要求等
4. **目标用户**：主要使用人群及其特征
5. **关联系统**：涉及的其他模块或第三方服务
6. **风险点**：已知的高风险区域
7. **历史缺陷**：类似功能的历史问题

### 输出内容

1. **完整测试用例集**：涵盖所有识别出的测试点
2. **测试优先级排序**：按P0-P3分级展示
3. **覆盖率说明**：已覆盖的测试维度列表
4. **缺失风险提示**：可能存在的测试盲区建议
5. **测试建议**：针对测试执行的建议

## 最佳实践

### 用例设计原则

✅ **DO - 推荐做法**
- 每个用例只验证一个明确的目标
- 使用清晰的数字序号标记预期结果
- 预期结果使用"应该/必须/会"等确定性词汇
- 包含正向和反向两种情况的验证
- 标注敏感信息的脱敏处理方式
- 为复杂场景添加截图或伪代码说明
- 测试步骤留空，由用户根据实际系统补充

❌ **DON'T - 避免做法**
- 模糊的描述如"检查是否可以正常工作"
- 一次性验证过多无关功能
- 忽略前置条件和环境配置
- 混合多个验证点在一个预期结果中
- 使用主观判断代替客观测量
- 忽略异常处理流程
- 强制生成可能与实际不符的测试步骤

### 用例评审要点

1. **完整性检查**：是否覆盖所有需求点和隐性场景
2. **独立性检查**：用例之间是否存在强依赖关系
3. **可执行性检查**：预期结果是否清晰、客观可测量
4. **可维护性检查**：命名规范、变更可追溯
5. **优先级合理性**：P0用例是否真正关键
6. **覆盖全面性**：功能、数据、权限、集成是否覆盖

## 输出示例

### 示例1：电商下单功能测试用例设计

```markdown
## 订单模块 - 商品下单 - P0

### TC_ORDER_CREATE_001 正常下单流程

**测试类型**: 功能测试
**功能模块**: 订单管理
**子功能**: 商品下单
**用例级别**: P0
**预置条件**:
1. 用户已登录且账户余额充足
2. 商品库存大于0
3. 收货地址已配置

**测试步骤**:
（留空，由用户根据实际系统补充）

**预期结果**:
1. 进入订单确认页
2. 订单金额计算准确（含运费优惠）
3. 订单创建成功，返回订单号
4. 库存扣减正确
5. 收到订单confirmation通知

**实际结果**: 待执行
```

### 示例2：用户注册功能异常场景

```markdown
## 用户模块 - 注册 - P1

### TC_USER_REGISTER_002 邮箱格式错误

**测试类型**: 功能测试
**功能模块**: 用户管理
**子功能**: 用户注册
**用例级别**: P1
**预置条件**: 访问注册页面

**测试步骤**:
（留空，由用户根据实际系统补充）

**预期结果**:
1. 邮箱字段显示红色错误提示
2. 提示内容明确告知格式要求
3. 无法继续提交表单
4. 控制台无报错日志

**实际结果**: 待执行
```

### 示例3：页面跳转测试用例设计

```markdown
## 商品模块 - 列表跳详情 - P0

### TC_PRODUCT_LIST_001 正常跳转详情页

**测试类型**: 功能测试
**功能模块**: 商品管理
**子功能**: 列表跳详情
**用例级别**: P0
**预置条件**:
1. 用户已登录
2. 商品列表页有数据

**测试步骤**:
（留空，由用户根据实际系统补充）

**预期结果**:
1. 成功跳转到商品详情页
2. URL包含正确的商品ID（如/product/12345）
3. 详情页展示的商品信息与列表一致
4. 商品图片、价格、库存等关键信息正确
5. 详情页功能按钮（购买、收藏等）可用

**实际结果**: 待执行
```

## 检查清单

测试用例设计完成后检查：
- [ ] 是否覆盖了所有需求点和隐性场景？
- [ ] 是否包含了正常、异常、边界三种场景？
- [ ] 每条用例是否只验证一个明确目标？
- [ ] 预期结果是否可客观验证？
- [ ] 用例优先级（P0-P3）是否合理？

## 参考资源

- `references/design-methods.md` — 10种设计方法详解 + 复杂场景覆盖
- `references/coverage-and-quality.md` — 覆盖维度 + 覆盖评估 + 质量指标
- `references/review-standards.md` — 需求文档要求 + 用例评审标准
- ISTQB测试术语标准 / ISO/IEC/IEEE 29119 / Google Testing Blog