7种测试用例设计方法实战：从QQ登录到公交卡充值的3个完整案例

测试用例设计实战：从QQ登录到公交卡充值的3个经典案例解析

1. 测试用例设计的核心方法论

测试用例设计是软件质量保障的关键环节，优秀的测试工程师需要掌握如何将抽象的理论转化为可执行的测试方案。在实际工作中，我们通常会遇到两类测试场景：功能性验证和业务流程验证，而7种经典设计方法正是应对这些场景的利器。

等价类划分法和边界值分析法往往形影不离，它们共同解决了输入验证的基础问题。等价类划分将无限可能的输入数据归类为有限的代表性集合，而边界值分析则聚焦那些最容易出错的临界点。这两种方法组合使用，可以覆盖约70%的基础功能测试场景。

对于更复杂的业务规则验证，因果图法和判定表法展现了强大威力。当系统行为由多个输入条件组合决定时，这两种方法能系统性地梳理所有可能的条件组合与对应输出，避免遗漏重要场景。统计显示，使用判定表法设计的测试用例平均能多发现15%的逻辑缺陷。

场景法（也称流程图法）特别适合验证完整的用户业务流程。通过定义基本流（主成功场景）和备选流（异常分支），我们可以构建出用户与系统交互的所有可能路径。在电商、金融等业务系统中，场景法设计的用例通常占到总用例数的30-40%。

正交试验法解决了多参数组合爆炸的难题。研究表明，对于有5个参数、每个参数3个取值的功能，全组合需要243个用例，而正交法仅需15-20个用例就能覆盖大部分错误。这种方法在配置类测试中尤为高效。

最后，错误推测法依赖测试工程师的经验直觉，针对系统可能存在的薄弱环节进行针对性测试。虽然看似主观，但经验丰富的测试人员用这种方法发现的缺陷往往占总缺陷数的10-15%。

2. QQ登录功能测试实战

2.1 需求分析与方法选择

QQ登录功能看似简单，却隐藏着多个需要验证的维度。核心需求可归纳为：

• 账号输入框：6-10位数字，不能以0开头
• 密码输入框：8-16位字符，需包含字母和数字
• 登录按钮：在输入合法时可用，点击后验证账号密码

针对账号输入框，我们采用等价类划分+边界值分析组合策略。密码框同样适用这种方法，而整个登录交互则适合用场景法验证各种用户操作流程。

2.2 账号输入的等价类与边界值设计

首先划分账号输入的有效和无效等价类：

边界值测试用例设计如下：

1. 最小有效边界：6位(100000) 2. 最大有效边界：10位(9999999999) 3. 刚好小于最小：5位(99999) 4. 刚好大于最大：11位(10000000000) 5. 0开头6位(012345) 6. 0开头10位(0123456789)

2.3 密码验证的判定表设计

密码规则相对复杂，适合用判定表梳理所有组合：

对应测试用例示例：

1. "Abcd1234" (8位，含字母数字) → 应接受 2. "Abcdefgh" (8位，仅字母) → 应拒绝 3. "12345678" (8位，仅数字) → 应拒绝 4. "A1" (2位) → 应拒绝

2.4 登录场景的全流程验证

使用场景法设计主流程和备选流：

基本流：

1. 输入有效账号
2. 输入有效密码
3. 点击登录
4. 验证成功，进入主界面

备选流：

1. 账号无效 → 显示错误提示
2. 密码无效 → 显示错误提示
3. 账号密码不匹配 → 显示错误提示
4. 网络不可用 → 显示网络错误
5. 服务器无响应 → 显示超时提示

场景法测试用例示例：

3. 公交卡充值系统测试设计

3.1 业务规则分析

公交卡充值系统涉及复杂的资金流转，其核心规则包括：

• 仅接受50/100元纸币
• 每次只能插入一张纸币
• 充值金额可选50或100元
• 需处理找零、金额不足等异常情况

这种多条件组合且有明确因果关系的场景，因果图法和判定表法是最佳选择。

3.2 因果图构建

首先识别所有原因（输入条件）和结果（系统响应）：

原因：

1. 插入50元
2. 插入100元
3. 选择充值50元
4. 选择充值100元
5. 超时未操作

结果： a. 完成充值并退卡 b. 提示充值成功 c. 退回纸币并提示错误 d. 找零50元

因果图中的约束关系：

• 原因1和2互斥（不能同时插入）
• 原因3和4互斥（不能同时选择）
• 结果a和b必须同时出现
• 结果c可以单独出现

3.3 判定表推导

根据因果图生成完整判定表（部分示例）：

3.4 完整测试用例集

基于判定表设计可执行的测试用例：

关键提示：在金融类系统测试中，除了正常流程，必须重点验证资金计算的准确性。例如TC03中，系统应确保找零金额精确无误，并记录完整的交易流水。

4. 在线购物系统测试案例

4.1 业务流程分解

典型的在线购物流程包含以下关键节点：

1. 用户登录
2. 商品浏览与选择
3. 加入购物车
4. 结算
5. 订单生成

这种线性流程中穿插多个判断分支的场景，最适合使用场景法进行测试设计。

4.2 基本流与备选流定义

基本流（Happy Path）：

1. 用户成功登录
2. 浏览商品并加入购物车
3. 进入结算页面
4. 选择配送方式
5. 支付成功
6. 生成订单

备选流：

1. 登录失败（用户名/密码错误）
2. 商品库存不足
3. 购物车为空时尝试结算
4. 配送信息不完整
5. 支付失败（余额不足/支付超时）
6. 订单生成后库存未扣减

4.3 正交法优化商品选择组合

商品选择涉及多个属性组合（颜色、尺寸、数量等），使用正交法可大幅减少用例数量。假设有以下参数：

• 颜色：红、蓝、黑
• 尺寸：S、M、L
• 数量：1、2、3

全组合需要3×3×3=27个用例，而使用正交表L9(3^4)只需9个：

4.4 支付环节的错误推测

基于经验，支付环节常见问题包括：

• 并发支付导致重复扣款
• 支付成功但订单状态未更新
• 网络中断时的支付超时处理
• 支付金额与订单金额不一致
• 退款原路返回验证

针对这些风险点设计专项测试用例：

1. 快速连续点击支付按钮 → 应防止重复支付 2. 支付完成后断网 → 订单应最终变为"已支付" 3. 修改订单金额后支付 → 应提示金额不匹配 4. 退款时原支付方式已注销 → 应有备用退款流程

5. 测试用例设计的高级技巧

5.1 方法组合策略

在实际项目中，单一方法往往难以覆盖所有测试需求。方法组合的常见模式包括：

1. 等价类+边界值+场景法：先验证单个输入的有效性，再测试完整流程
2. 因果图+判定表+错误推测：针对复杂业务规则，先用因果图分析，再用判定表具象化，最后用错误推测补充边缘情况
3. 正交法+参数化测试：对多参数功能，用正交法设计组合，通过参数化测试技术高效执行

5.2 测试数据准备技巧

优质的测试数据能显著提升用例有效性：

• 边界值数据：包括刚好在边界上、略低于和略高于边界的数据
• 无效数据类型：错误格式、非法字符、超长字符串等
• 状态组合数据：如用户账户的不同状态（正常、冻结、注销）与各种操作的组合
• 性能相关数据：大数据量、高并发场景下的测试数据

5.3 用例维护与管理

随着产品迭代，测试用例需要持续优化：

1. 版本对比：每次迭代时，对比新旧需求规格，标识出需要新增、修改或废弃的用例
2. 缺陷回溯：分析漏测的缺陷，补充相应测试场景
3. 优先级调整：根据功能重要性和缺陷分布，动态调整用例执行优先级
4. 冗余检测：定期检查是否有重复或过于相似的用例

下表展示了一个简单的用例管理矩阵：

6. 常见陷阱与最佳实践

6.1 新手常见错误

1. 过度依赖UI操作：用例中充斥着"点击这里"、"选择那个"等具体操作，一旦UI变化就需要大量修改。应更关注业务逻辑而非具体操作路径。

2. 断言过于简单：仅验证"没有报错"或"页面跳转"，缺乏对业务结果的实质性检查。好的断言应该验证数据变更、状态更新等核心结果。

3. 忽略前置条件：未考虑测试环境的初始状态，导致用例执行结果不稳定。明确的初始状态是可靠测试的基础。

4. 用例间强耦合：多个用例依赖相同的测试数据或执行顺序，难以独立运行。每个用例应该是自包含的。

6.2 行业最佳实践

1. 需求可测试性：在需求阶段就考虑如何验证，确保需求明确、可测量。模糊的需求必然导致低效的测试。

2. 分层测试策略：单元测试覆盖核心算法，API测试验证服务契约，UI测试关注用户体验。不同层次使用不同的测试方法。

3. 可视化报告：使用图表展示需求覆盖率、缺陷分布等关键指标，帮助团队聚焦重点。

4. 自动化适度的原则：不是所有用例都适合自动化。高稳定性、高价值、高频执行的用例优先自动化。

下表对比了不同测试方法的适用场景：