# Test Case Design

> 设计测试用例时使用。适用于功能测试、回归测试、UAT 前用例准备。融合等价类、边界值、决策表、状态转换、错误推测五大黑盒方法。

- Skill: `zhaoxuya520/test-case-design` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add zhaoxuya520/test-case-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhaoxuya520/test-case-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zhaoxuya520 (https://skillmd.com/u/zhaoxuya520)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhaoxuya520/test-case-design

---


# 测试用例设计（Test Case Design）

参考来源：ISTQB Foundation 黑盒测试技术、Cem Kaner《Lessons Learned in Software Testing》、Glenford Myers《The Art of Software Testing》。

## 适用场景

- 功能测试用例设计
- 回归测试用例编写
- UAT 用例准备
- API 接口测试用例
- 表单 / 状态机 / 业务规则测试

## 核心原则

```text
1. 用例 = 前置 + 步骤 + 数据 + 预期 + 后置
   缺一项就不是用例

2. 一个用例只测一件事
   测多个目的会让失败定位困难

3. 预期必须可验证
   "看起来对" 不是预期

4. 用例可独立执行
   不依赖前一个用例的副作用

5. 命名要能"读出"测什么
   `订单-创建-超出库存上限报错` 优于 `test_001`
```

## 五大黑盒方法

### 1. 等价类划分

```text
原则：同一类输入产生同一类行为，每类选一个代表

示例：年龄字段 [0, 150]
  有效等价类：[0, 150] → 取 30
  无效等价类：(-∞, -1] → 取 -1
  无效等价类：[151, +∞) → 取 200
  无效等价类：非数字 → 取 "abc"

→ 4 个用例覆盖所有等价类
```

### 2. 边界值分析

```text
原则：边界附近最易出 Bug，必测

示例：长度 [1, 100]
  必测：0（下界外）, 1（下界）, 2, 99, 100（上界）, 101（上界外）
  
常见边界：
  - 数值：min-1, min, min+1, max-1, max, max+1
  - 长度：0, 1, max, max+1
  - 时间：00:00, 23:59, 月末, 闰年, 跨时区
  - 数组：空, 1 个, 最大长度, 超出
  - 字符串：空, 1 字符, 超长, Unicode, Emoji, RTL
```

### 3. 决策表

```text
原则：多个条件组合时，列表枚举

示例：折扣规则
  条件：会员（是/否）+ 满 100（是/否）+ 优惠券（有/无）

| 会员 | 满 100 | 优惠券 | 折扣 |
|------|-------|-------|------|
| 是   | 是    | 有    | 30%  |
| 是   | 是    | 无    | 20%  |
| 是   | 否    | 有    | 10%  |
| 是   | 否    | 无    | 0%   |
| 否   | 是    | 有    | 15%  |
| 否   | 是    | 无    | 10%  |
| 否   | 否    | 有    | 5%   |
| 否   | 否    | 无    | 0%   |

→ 8 个用例覆盖所有组合，避免漏测
```

### 4. 状态转换测试

```text
原则：每个合法转换 + 每个非法转换都测

示例：订单状态机
  draft → submitted → paid → shipped → delivered
                ↓
              cancelled

合法转换用例：
  - draft → submitted（提交）
  - submitted → paid（支付）
  - paid → shipped（发货）
  - shipped → delivered（确认收货）
  - submitted → cancelled（取消）

非法转换用例（必测）：
  - delivered → cancelled（已收货不能取消）
  - paid → submitted（已支付不能回退）
  - draft → paid（未提交不能直接支付）
```

### 5. 错误推测

```text
原则：基于经验、历史 Bug、领域知识推测可能错误处

常见错误推测点：
  - SQL 注入：'; DROP TABLE users; --
  - XSS：<script>alert(1)</script>
  - 路径穿越：../../etc/passwd
  - 大小写混淆：Email vs email
  - 空值：null, undefined, "", "  ", "\n"
  - 编码：%20, +, &amp;
  - 时区：UTC vs Local, DST 切换
  - 货币：999.99, 0.01, -1, 1e10
  - 分页：page=0, page=-1, page=999999
  - 并发：同时点击两次"提交"
```

## 工作流程

```text
1. 阅读 PRD / API 契约 / UI 流程
   ↓
2. 提取测试点（输入 / 输出 / 状态 / 规则）
   ↓
3. 选择方法
   - 单字段输入 → 等价类 + 边界值
   - 多条件组合 → 决策表
   - 状态机 → 状态转换
   - 历史问题域 → 错误推测
   ↓
4. 写正向用例
   - 主路径成功
   ↓
5. 写反向用例
   - 校验失败 / 权限失败 / 资源不存在
   ↓
6. 写边界用例
   - 0 / 1 / 最大 / 最大+1
   ↓
7. 写状态转换用例
   - 合法 + 非法
   ↓
8. 评审
   - 同事 review，是否漏点
```

## 用例数量参考

```text
单字段输入：
  - 等价类 3~5 个 + 边界值 4~6 个 ≈ 7~10 用例

多条件组合（N 个布尔条件）：
  - 决策表：2^N（避免组合爆炸时用 Pairwise）

状态机：
  - 合法转换数 + 非法转换数

API 端点（CRUD）：
  - 单端点 ≈ 8~12 用例（成功、空、参数错、认证错、权限错、不存在、冲突、限流）
```

## 优先级打分（P0~P3）

| 等级 | 含义 | 比例 |
|------|------|------|
| P0 | 阻塞上线，必测必过 | 10%~20% |
| P1 | 主流程，必测应过 | 30%~40% |
| P2 | 次要路径 | 30%~40% |
| P3 | 边缘场景 | 10%~20% |

打分依据：
- 用户暴露度（多少用户会触发）
- 业务影响（涉及钱 / 权限 / 数据）
- 失败成本（修复难度 / 客诉风险）

## 质量自检

```text
□ 每个用例都有前置 + 步骤 + 预期
□ 预期是可验证的（不是"看起来对"）
□ 一个用例只测一件事
□ 用例可独立执行
□ 命名能读出测什么
□ 五大方法都用上了（不只是正向）
□ 边界值齐全（min-1, min, max, max+1）
□ 状态机非法转换覆盖
□ 优先级有依据，不是拍脑袋
□ 每个验收标准至少 1 条 P0 用例
```

## 常见坑

1. **只写正向用例**——50% Bug 在反向路径
2. **预期写"成功"**——不可验证，应写"返回 200 + status=submitted"
3. **用例依赖顺序**——上一个失败下面全乱
4. **边界值漏 max+1**——经典空指针 / 越界来源
5. **非法状态转换不测**——已支付订单还能再支付
6. **决策表条件爆炸不剪枝**——8 个布尔条件 256 用例
7. **用例命名 test_001**——读不出测什么
8. **用同一个测试账号**——账号污染、无法并发
9. **不写后置清理**——下次跑环境是脏的
10. **抄业务文档当用例**——没有 QA 视角

## 配套模板

- `templates/test-case-template.md` — 单条用例标准模板（前置 + 步骤 + 预期 + 验证点 + 后置）

## 与其他 skill 的协作

```text
上游：
  test-strategy → 测试范围
  risk-based-testing → 优先级输入

平行：
  exploratory-testing → 探索式补充用例

下游：
  api-testing → API 用例细化
  acceptance-testing → 验收用例
  regression-testing → 入回归套件
  bug-reporting → 失败时形成 Bug
```