# 一、测试用例核心要素
测试用例是验证软件需求的**最小执行单元**，完整的用例应包含：
1. **用例编号**：TC-模块名-序列号（如TC-Login-001）
2. **测试标题**：简明描述验证目标（如"验证正确用户名密码登录成功"）
3. **前置条件**：执行测试前的系统状态（如用户已注册并激活）
4. **测试步骤**：可执行的操作序列（输入用户名→输入密码→点击登录）[2][4]
5. **预期结果**：符合需求定义的明确预期（跳转到用户主页）
6. **优先级**：P0（核心功能）到P3（边缘场景）的等级划分[4]

# 二、经典设计方法
## 2.1 等价类划分法
将输入域划分为有效/无效等价类，例如：
- 用户名输入框：有效（6-20位字符）、无效（5位/21位/特殊符号）[3]

## 2.2 边界值分析法
重点测试输入域的边界条件：
- 密码长度限制8-16位时，测试7/8/9和15/16/17位的情况[1]

## 2.3 判定表法
处理多条件组合场景（推荐代替因果图法）：
| 条件组合 | 已登录 | 有权限 | 预期结果 |
|---------|--------|--------|----------|
| 1       | 是     | 是     | 访问成功 |
| 2       | 是     | 否     | 提示无权限 |
| 3       | 否     | -      | 跳转登录 | [1]

# 三、编写实践技巧
1. **需求映射**：每个用例必须对应明确的需求点（如PRD第3.2条）[5]
2. **正向用例优先**：先保证核心流程正确性（如成功登录）
3. **异常场景覆盖**：网络中断、数据异常等边缘情况（登录时断网）[3]
4. **参数化设计**：使用变量提高用例复用性（不同用户角色共用登录流程）

# 四、典型错误规避
1. **大而全的用例**：单个用例包含多个验证点（应拆分为原子用例）
2. **模糊描述**：使用"适量数据"等不明确表述（应改为"输入15位数字"）
3. **忽略前置条件**：未说明测试环境状态导致结果不稳定[4]
4. **缺乏维护**：需求变更后未及时更新关联用例[5]

> **实战案例**：微信朋友圈发布功能测试
> 1. 正常场景：图文混排+定位发送
> 2. 异常场景：无网络时发布、超过9张图片
> 3. 边界测试：输入1000个字符检查截断逻辑[3][4]

# 五、质量提升checklist
1. 每个用例是否可独立执行？
2. 预期结果是否可量化验证？
3. 是否覆盖所有需求分支？
4. 是否经过同行评审？[5]
5. 是否关联到缺陷管理系统？

通过合理的用例设计，测试团队可提升缺陷发现率30%以上[2]。建议新人在编写前先使用**测试大纲法**梳理测试点，再逐步细化为具体用例。记住：好的测试用例应该像导航路线一样，让执行者无需额外思考就能完成验证[4][5]。

## 参考资料
1. ISTQB Foundation Syllabus：https://www.istqb.org/certifications/certified-tester-foundation-level/
2. IEEE 29119 Software Testing：https://standards.ieee.org/ieee/29119-1/6400/
3. 等价类与边界值分析介绍：https://www.guru99.com/equivalence-partitioning-boundary-value-analysis.html
4. 决策表测试方法：https://www.toolsqa.com/software-testing/decision-table-testing/
5. 软件测试文档与用例管理实践（Atlassian）：https://www.atlassian.com/software/confluence/testing