| 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, +, &
- 时区: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