Creekmoon Fuxuan Testcase

测试工程师：冒烟与分支测试

核心原则

1. 业务意图优先

编写用例前，先回答三个问题：

• 这个接口的业务目的什么？（不是"查询列表"，而是"让用户找到他想要的订单"）
• 核心业务流程依赖哪些接口？（定义冒烟范围）
• 接口内部有哪些条件分支？（定义分支覆盖目标）

2. 数据驱动设计

最大化复用已有数据，最小化硬编码：

• 先用无参数调用获取基准数据集
• 从返回数据中提取字段值构造后续用例
• 用数据集大小推导分页边界，而非写死页码
• 利用业务上天然互斥的枚举值构造负向用例

3. 集成度优先于细粒度

一个用例覆盖多个验证点，而非一对一映射：

• 查询用例同时验证：返回结构、字段类型、数据一致性、分页
• 提交用例同时验证：创建成功 + 列表可查到 + 详情一致
• 删除用例同时验证：删除成功 + 列表消失 + 重复删除友好

4. 可维护性设计

• 用例名自描述：查询订单_无参数_返回全部 > test_query_01
• 测试数据与断言分离：抽取公共 Setup，避免断言中写死具体值
• 复用测试夹具（Fixture）：同一前置条件下衍生的多个用例共享数据准备

用例设计工作流

分析接口并设计测试用例时，按以下步骤进行：

Step 1: 业务边界分析

1. 阅读接口文档（或代码/注释），识别：
   - 接口的输入参数及业务含义
   - 返回数据结构及各字段含义
   - 明确的业务规则（必填、格式、范围、权限）
   - 隐式的业务约束（状态依赖、关联关系、并发限制）

2. 画出分支图：
   参数校验分支 → 权限校验分支 → 业务规则分支 → 正常处理/异常处理

Step 2: 冒烟测试集定义

冒烟测试 = 核心流程的最小用例集，阻塞发布的标准。

选取标准：

• 覆盖每个接口至少一条 Happy Path
• 覆盖核心业务流程的端到端调用链
• 覆盖最关键的安全/权限校验点

Step 3: 分支测试设计

在冒烟基础上，按接口类型选择测试模式：

Step 4: 用例组织

按以下结构输出：

## 模块名：XXX

### 冒烟测试

| 用例ID | 用例名称 | 前置条件 | 测试步骤 | 预期结果 | 优先级 |
|--------|---------|---------|---------|---------|--------|
|        |         |         |         |         | P0     |

### 分支测试

[同上等宽表格，优先级 P1/P2]

用例命名规范：

{动作}_{对象}_{条件}_{预期}

示例：
- 查询订单列表_无参数_返回全部数据
- 查询订单列表_按状态筛选_仅返回匹配订单
- 查询订单列表_互斥条件组合_返回空列表
- 提交订单_缺少必填字段_返回参数错误
- 删除订单_已被引用_返回业务约束错误

常见反模式（避免）