SuperAPI AI Directory
Partner中文AI newsFavorites
Skillstest-case-design

test-case-design

Testing & quality

View repository

Updated 10-16 09:56

About this skill

Test Case Design

References: ISTQB Foundation black-box testing techniques, Cem Kaner's Lessons Learned in Software Testing, Glenford Myers' The Art of Software Testing.

Applicable Scenarios

  • Functional test case design
  • Regression test case writing
  • UAT test case preparation
  • API interface test cases
  • Form / state machine / business rule testing

Core Principles

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

  1. One test case tests only one thing Testing multiple purposes makes failure localization difficult

  2. Expectations must be verifiable "Looks right" is not an expectation

  3. Test cases can be executed independently Do not depend on the side effects of the previous test case

  4. Naming should "read out" what is being tested 订单-创建-超出库存上限报错 is better than test_001


## 五大黑盒方法

### 1. 等价类划分

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

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

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

2. Boundary Value Analysis

原则：边界附近最易出 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. Decision Table

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

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

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

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

4. State Transition Testing

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

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

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

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

5. Error Guessing

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

Workflow

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

Test Case Quantity Reference

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

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

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

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

Priority Scoring (P0~P3)

Level Meaning Proportion
P0 Blocks release, must test and must pass 10%~20%
P1 Main flow, must test and should pass 30%~40%
P2 Secondary paths 30%~40%
P3 Edge scenarios 10%~20%

Scoring basis:

  • User exposure (how many users will trigger it)
  • Business impact (involves money / permissions / data)
  • Failure cost (fix difficulty / customer complaint risk)

Quality Self-Check

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

Common Pitfalls

  1. Only writing positive test cases——50% of bugs are in negative paths
  2. Writing the expectation as "success"——Not verifiable; should write "return 200 + status=submitted"
  3. Test cases depend on order——If the previous one fails, everything below is messed up
  4. Boundary values miss max+1——Classic source of null pointers / out-of-bounds
  5. Illegal state transitions are not tested——A paid order can still be paid again
  6. Decision table condition explosion without pruning——8 boolean conditions, 256 test cases
  7. Test case named test_001——Cannot read out what is being tested
  8. Using the same test account——Account pollution, cannot run concurrently
  9. Not writing post-test cleanup——The environment is dirty the next time it runs
  10. Copying business documents as test cases——No QA perspective

Supporting Templates

  • templates/test-case-template.md — Standard template for a single test case (preconditions + steps + expectations + verification points + postconditions)

Collaboration with Other Skills

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

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

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