test-case-design

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

测试用例设计（Test Case Design）

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

适用场景

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

核心原则

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

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

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

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

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

五大黑盒方法

1. 等价类划分

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

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

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

2. 边界值分析

原则：边界附近最易出 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. 决策表

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

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

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

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

4. 状态转换测试

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

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

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

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

5. 错误推测

原则：基于经验、历史 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
  - 并发：同时点击两次"提交"

工作流程

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

用例数量参考

单字段输入：
  - 等价类 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%

打分依据：

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

质量自检

□ 每个用例都有前置 + 步骤 + 预期
□ 预期是可验证的（不是"看起来对"）
□ 一个用例只测一件事
□ 用例可独立执行
□ 命名能读出测什么
□ 五大方法都用上了（不只是正向）
□ 边界值齐全（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 的协作

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

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

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