zhaoxuya520 测试用例设计（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, +, &
- 时区：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 用例
常见坑
- 只写正向用例——50% Bug 在反向路径
- 预期写"成功"——不可验证，应写"返回 200 + status=submitted"
- 用例依赖顺序——上一个失败下面全乱
- 边界值漏 max+1——经典空指针 / 越界来源
- 非法状态转换不测——已支付订单还能再支付
- 决策表条件爆炸不剪枝——8 个布尔条件 256 用例
- 用例命名 test_001——读不出测什么
- 用同一个测试账号——账号污染、无法并发
- 不写后置清理——下次跑环境是脏的
- 抄业务文档当用例——没有 QA 视角
配套模板
templates/test-case-template.md— 单条用例标准模板（前置 + 步骤 + 预期 + 验证点 + 后置）
与其他 skill 的协作
上游：
test-strategy → 测试范围
risk-based-testing → 优先级输入
平行：
exploratory-testing → 探索式补充用例
下游：
api-testing → API 用例细化
acceptance-testing → 验收用例
regression-testing → 入回归套件
bug-reporting → 失败时形成 Bug