8.4.1 核心原则
测试用例生成不是"翻译需求"，而是设计验证方案。遵循三条铁律：
- 可追溯：每个用例能对应到具体需求条目（建议用需求编号开头，如 REQ-01-001）
- 可判定：预期结果必须是"是/否"能判断的，避免"页面友好显示"这类模糊描述
- 最简覆盖：优先保证核心流程，而非追求 100% 场景穷举（考虑 ROI）
8.4.2 四大生成方法
1. 需求拆解法（最常用）
将需求文档逐条转化为验证点：
- 功能需求 → 正向用例（正常操作路径）
- 约束条件 → 反向用例（异常处理）
- 性能指标 → 压力/并发用例
2. 等价类+边界值（数据输入类）
以"年龄输入框（18-60 岁）"为例：
- 有效等价类：18, 30, 60
- 无效等价类：17, 61, "abc", 空值
- 边界值：17（无效边界）、18（有效边界）、60、61
3. 场景法（业务流程类）
画流程图 → 识别判断节点 → 覆盖每条分支：
- 基本流：标准业务流程（如：登录→选商品→支付→成功）
- 备选流：异常分支（库存不足、支付超时、优惠券失效）
4. 错误推测法（经验补充）
基于历史 Bug 库补充：
- 高频错误点：并发提交、特殊字符（
'";--）、超长文本（10000 字）、弱网环境
8.4.3 实操流程（推荐）
步骤 1：脑图梳理（XMind）
模块：用户登录
├── 正常登录
│ ├── 手机号+密码
│ └── 手机号+验证码
├── 异常处理
│ ├── 密码错误（3 次锁定？）
│ └── 验证码过期（5 分钟？）
└── 兼容性
├── 手机号格式（+86/空格/横杠）
└── 密码掩码显示（●●●）步骤 2：模板填写（Excel/禅道）
| 用例编号 | 所属模块 | 用例标题 | 前置条件 | 测试步骤 | 预期结果 | 优先级 |
|---------|---------|---------|---------|---------|---------|--------|
| TC_LOGIN_001 | 登录 | 有效手机号密码登录 | 账号已注册且未锁定 | 1. 输入 13800138000<br>2. 输入正确密码<br>3. 点击登录 | 1. 跳转至首页<br>2. 显示用户名<br>3. Session 生成 | P0 |
步骤 3：评审裁剪
- 删除重复：如"登录成功"和"登录后跳转"合并
- 补充边界：检查是否遗漏"SQL 注入尝试"
8.4.4 避坑指南
- 避免步骤堆砌：一个用例验证一个点，步骤超过 7 步考虑拆分
- 拒绝预期结果模糊：不写"提示成功"，写"提示'保存成功'且数据库字段 update_time 更新"
- 数据准备显性化：前置条件写明"准备测试账号 test01/123456"，而非"拥有合法账号"
- 维护成本意识：UI 微调频繁的模块，用例步骤写"点击【确认】按钮"而非写死坐标
8.4.5 工具推荐
- 设计阶段：Excel（简单项目）、XMind（复杂业务流）、Visio（状态机）
- 管理阶段：禅道、Jira+Xray、TestLink
- 自动化辅助：Pairwise 工具（AllPairs）生成组合测试用例，减少用例数 50% 以上
真实案例：某电商订单模块，初版生成 200+ 用例，经等价类合并后精简为 45 个核心用例，上线后缺陷发现率反提升 15%（因测试人员专注执行而非疲于应付冗余用例）。