Skip to content

怎么写测试用例.md

Latest commit

 

History

History
539 lines (322 loc) · 25.5 KB

怎么写测试用例.md

File metadata and controls

539 lines (322 loc) · 25.5 KB

怎么写测试用例

编写测试用例的步骤

  1. 理解需求：详细阅读并理解功能需求文档（FRD）和技术设计文档（TDD）。确保清楚了解系统的功能和用户期望的行为。

  2. 确定测试范围：根据需求和设计，确定测试的功能模块和边界。

  3. 定义测试场景：列出所有可能的测试场景，包括正常场景和异常场景。

  4. 设计测试用例：根据测试场景编写详细的测试用例，确保覆盖所有功能点和边界情况。

软件测试工程师的工作职责：

  1. 找缺陷（Bug）、提交缺陷、跟踪缺陷。

  2. 运行程序，执行测试用例，进行功能测试和非功能测试等。

  3. 设计并编写测试用例，用例评审等工作。

  4. 测试总结，出局测试报告。

  5. 测试计划和测试方案的辨析。

测试用例的写作规范

编号 所属模块 标题 重要级别 前置条件 测试数据 测试试骤 预期结果 测试结果
TC_001 用户登录 成功登录 高 用户已注册并存在有效的用户名和密码 用户名: testuser
密码: password123		 1. 打开登录页面
2. 输入用户名 testuser
3. 输入密码 password123
4. 点击登录按钮		 用户成功登录，跳转到主页 通过

测试数据

简单来说就是输入项及取值

  1. 输入项的名称: 取值

  2. 建议所有的输入项都体现在用例的测试数据项中

  3. 一个用例是一组数据的测试

  4. 设计测试数据时，可以选择精确数据，也可以选择范围数据

  5. 既要设计有效数据，也要设计无效数据

测试步骤

输入 -> 执行 -> 输出 的过程

  • 同一个功能点，测试步骤理论上是相同的

  • 测试步骤不要写的过长，描述关键步骤即可

预期结果

检查场景是否正确

  • 是用户所期望的将结果，同一个数据只能有一种预期结果

  • 预期结果包括总体结果和具体说明

前置条件

特定场景

测试用例设计方法

等价类

概述

如果涉及到下拉框、单选框等，可能会需要设计多种组合，以确保下拉框、单选框等的覆盖范围。

等价类划分是通过将输入数据划分为等价类（归类），从而减少测试用例的数量，同时确保测试的覆盖范围。

每个等价类中的所有值应被认为是相等的，即他们会引起相同的行为。

这种方法有效地较低了冗余测试，提高了测试效率。

等价类划分步骤

  1. 确定要测试的功能或输入域：明确输入数据的范围和输出结果的预期。

  2. 划分等价类：将输入数据分为有效等价类和无效等价类。

    • 为每个输入项划分等价类。

  3. 设计测试用例：为每个等价类取一个代表值，作为测试用例的输入数据。

示例

假设我们有一个年龄输入字段，要求输入的年龄范围是 18 到 60 岁。

  1. 确定输入域：

    • 年龄（整数）

  2. 划分等价类

    • 有效等价类

      • 18 到 60 之间的任何整数（例如：30）

    • 无效等价类

      • 小于 18 的任何整数（例如：17）

      • 大于 60 的任何整数（例如：61）

      • 非整数（例如：字符或浮点数，如“abc”或25.5）

  3. 设计测试用例

编号 所属模块 标题 重要级别 前置条件 测试数据 测试步骤 预期结果 测试结果
TC_003 用户注册 输入有效年龄 高 无 年龄：30 1. 打开注册页面
2. 在年龄字段输入30
3. 点击提交按钮		 表单提交成功，用户注册成功 通过
TC_004 用户注册 输入无效年龄 - 小于18 高 无 年龄：17 1. 打开注册页面
2. 在年龄字段输入17
3. 点击提交按钮		 表单提交失败，显示“年龄必须在18到60之间” 通过
TC_005 用户注册 输入无效年龄 - 大于60 高 无 年龄：61 1. 打开注册页面
2. 在年龄字段输入61
3. 点击提交按钮		 表单提交失败，显示“年龄必须在18到60之间” 通过
TC_006 用户注册 输入无效年龄 - 非整数 高 无 年龄：abc 1. 打开注册页面
2. 在年龄字段输入“abc”
3. 点击提交按钮		 表单提交失败，显示“请输入有效的整数年龄” 通过

总结

等价类划分的优点

  • 减少测试用例数量：通过选择代表性测试用例来减少冗余。

  • 提高测试效率：覆盖了所有可能的输入类型，但不需要测试每个具体值。

  • 发现边界问题：通常与边界值分析结合使用，能有效发现输入边界的缺陷。

    • 边界条件通常是最容易出错的地方。在划分等价类时，应特别注意边界值。

    • 通常，边界值会被单独列为一个等价类。例如，年龄的边界值18和60应分别作为一个单独的等价类。

==每一种异常值都有可能作为一个单独的等价类==

边界值

概述

边界值分析法是一种补充等价划分的测试用例设计方法。专注于输入域的边界值，因为许多缺陷往往出现在这些边界上。通过测试输入域的边界，可以更有效地发现潜在的缺陷。

边界值分析原则

  1. 识别输入域的边界：确定输入参数的最小值、最大值及其附近的值。

  2. 测试边界值和附近值：通常测试最小值、最大值以及比最小值小1、比最大值大1的值。

  3. 考虑正负边界：对于包含正负值的输入域，考虑正负边界。

示例

假设我们有一个复杂的用户名输入字段，要求如下：

  • 用户名长度在5到15个字符之间

  • 用户名只能包含字母和数字

  • 用户名必须以字母开头

  1. 确定输入域的边界

    1. 长度：

      • 最小长度：5字符

      • 最大长度：15字符

    2. 字符类型：

      • 用户名只能包含字母和数字

      • 用户名必须以字母开头

  2. 测试边界值和附近值

    1. 长度边界值和附近值：

      • 边界值：5字符，15字符

      • 边界值附近的值：4字符，6字符，14字符，16字符

    2. 字符类型边界值：

      • 仅包含字母和数字的有效用户名

      • 包含特殊字符的无效用户名

    3. 开头字符边界值：

      • 以字母开头的有效用户名

      • 以数字开头的无效用户名

  3. 设计测试用例

编号 所属模块 标题 重要级别 前置条件 测试数据 测试步骤 预期结果 测试结果
TC_001 用户注册 输入有效用户名 - 最小长度 高 无 用户名：abcde 1. 打开注册页面
2. 在用户名字段输入 abcde
3. 点击提交按钮		 表单提交成功，用户注册成功 通过
TC_002 用户注册 输入有效用户名 - 最大长度 高 无 用户名：abcdefghijklmno 1. 打开注册页面
2. 在用户名字段输入 abcdefghijklmno
3. 点击提交按钮		 表单提交成功，用户注册成功 通过
TC_003 用户注册 输入无效用户名 - 长度小于最小值 高 无 用户名：abcd 1. 打开注册页面
2. 在用户名字段输入 abcd
3. 点击提交按钮		 表单提交失败，显示“用户名长度必须在5到15个字符之间” 通过
TC_004 用户注册 输入无效用户名 - 长度大于最大值 高 无 用户名：abcdefghijklmnop 1. 打开注册页面
2. 在用户名字段输入 abcdefghijklmnop
3. 点击提交按钮		 表单提交失败，显示“用户名长度必须在5到15个字符之间” 通过
TC_005 用户注册 输入有效用户名 - 边界附近最小值+1 高 无 用户名：abcdef 1. 打开注册页面
2. 在用户名字段输入 abcdef
3. 点击提交按钮		 表单提交成功，用户注册成功 通过
TC_006 用户注册 输入有效用户名 - 边界附近最大值-1 高 无 用户名：abcdefghijklmn 1. 打开注册页面
2. 在用户名字段输入 abcdefghijklmn
3. 点击提交按钮		 表单提交成功，用户注册成功 通过
TC_007 用户注册 输入无效用户名 - 含特殊字符 高 无 用户名：abcde!@# 1. 打开注册页面
2. 在用户名字段输入 abcde!@#
3. 点击提交按钮		 表单提交失败，显示“用户名只能包含字母和数字” 通过
TC_008 用户注册 输入无效用户名 - 数字开头 高 无 用户名：1abcdef 1. 打开注册页面
2. 在用户名字段输入 1abcdef
3. 点击提交按钮		 表单提交失败，显示“用户名必须以字母开头” 通过

==内边界的附近值（如最大值-1、最小值+1），可以考虑删除该用例，因为通过最小长度和最大长度的测试用例，足以覆盖该部分测试需求==。

等价类划分和边界值分析可以结合使用，以确保测试的全面性和有效性。

例如，首先使用等价类划分来确定输入的有效和无效范围，然后在这些范围内使用边界值分析来确定具体的测试数据。

判定表

概述

判定表测试是一种系统地考虑多种输入条件及其组合的方法。

判定表测试法通过系统地列出所有条件及其组合，可以确保对系统的复杂逻辑进行全面覆盖。它特别适用于条件较多且相互组合可能产生不同结果的场景。

判定表的组成

  1. 条件桩（Condition Stub）：列出所有的输入条件。

  2. 条件项（Condition Entry）：列出每个条件的可能取值（通常是布尔值）。

  3. 动作桩（Action Stub）：列出所有可能的输出或动作。

  4. 动作项（Action Entry）：列出再各种条件组合下的输出或动作。

示例

假设我们要设计一个系统，该系统根据以下条件进行不同的响应：

  • 用户是否登录（已登录/未登录）

  • 用户是否有权限（有权限/无权限）

  • 用户请求的操作类型（读取/写入）

系统的响应包括：

  • 允许操作

  • 拒绝操作

  • 要求登录

判定表
条件编号 C1：用户是否登录 C2：用户是否有权限 C3：操作类型
条件组合 登录 有权限 读取
登录 有权限 写入
登录 无权限 读取
登录 无权限 写入
未登录 有权限 读取
未登录 有权限 写入
未登录 无权限 读取
未登录 无权限 写入
动作编号 A1：允许操作 A2：拒绝操作 A3：要求登录
动作组合 X
X
X
X
X
X
X
X
生成测试用例
编号 条件 操作类型 预期结果 实际结果
TC_001 用户已登录，有权限 读取 允许操作 通过
TC_002 用户已登录，有权限 写入 允许操作 通过
TC_003 用户已登录，无权限 读取 拒绝操作 通过
TC_004 用户已登录，无权限 写入 拒绝操作 通过
TC_005 用户未登录，有权限 读取 要求登录 通过
TC_006 用户未登录，有权限 写入 要求登录 通过
TC_007 用户未登录，无权限 读取 要求登录 通过
TC_008 用户未登录，无权限 写入 要求登录 通过

适用于条件较多且相互组合可能产生不同结果的场景

因果图

概述

因果图（Cause-Effect Graphing）是一种系统的测试用例设计方法，主要用于处理复杂的业务规则和条件组合。它通过将输入条件（原因）和输出结果（效果）绘制成图形，并进行逻辑分析，生成测试用例。

因果图的组成

  1. 原因（Cause）：输入条件，表示触发某个结果的前提条件。

  2. 结果（Effect）：输出结果，表示输入条件满足后的系统行为。

  3. 节点：表示原因和结果，分为输入节点和输出节点。

  4. 连线：表示原因和结果之间的关系，分为直线连线和逻辑连线（如与、或、非）。

因果图的步骤

  1. 确定输入条件和输出结果：列出所有可能的输入条件和预期输出结果。

  2. 绘制因果图：根据输入条件和输出结果之间的关系绘制因果图。

  3. 转换为判定表：价格因果图中的关系转换为判定表，以便生成测试用例。

  4. 生成测试用例：根据判定表生成测试用例，确保覆盖所有组合和条件。

示例

假设我们有一个用户登录系统，输入条件和输出结果如下：

  • 输入条件：

    • C1：用户名有效

    • C2：密码有效

    • C3：用户已激活

  • 输出结果：

    • E1：允许登录

    • E2：拒绝登录

因果图
C1: 用户名有效 -------------------------+
                                         | 
C2: 密码有效 -------------------+         +----> E1: 允许登录
                                 |        |
C3: 用户已激活 ------------------+--------+

!C1 OR !C2 OR !C3 ---------------> E2: 拒绝登录

#####判定表

编号 C1: 用户名有效 C2: 密码有效 C3: 用户已激活 E1: 允许登录 E2: 拒绝登录
1 Y Y Y X
2 Y Y N X
3 Y N Y X
4 Y N N X
5 N Y Y X
6 N Y N X
7 N N Y X
8 N N N X
测试用例
Test Case ID 条件 预期结果 实际结果
TC_001 用户名有效，密码有效，用户已激活 允许登录 待填写
TC_002 用户名有效，密码有效，用户未激活 拒绝登录 待填写
TC_003 用户名有效，密码无效，用户已激活 拒绝登录 待填写
TC_004 用户名有效，密码无效，用户未激活 拒绝登录 待填写
TC_005 用户名无效，密码有效，用户已激活 拒绝登录 待填写
TC_006 用户名无效，密码有效，用户未激活 拒绝登录 待填写
TC_007 用户名无效，密码无效，用户已激活 拒绝登录 待填写
TC_008 用户名无效，密码无效，用户未激活 拒绝登录 待填写

总结

通过因果图，可以清晰地表示输入条件与输出结果之间的逻辑关系，并通过判定表生成覆盖全面的测试用例。这种方法特别适用于处理复杂的业务规则和多条件组合的场景。

正交表

概述

正交表（Orthogonal Array Testing）是一种用于减少测试用例数量的设计方法。

过排列组合输入条件，确保在有限的测试用例中覆盖尽可能多的场景。这种方法特别适用于组合爆炸问题，即输入参数和取值范围较多时，全面测试所需的用例数过多的情况。

==感觉正交表还是排列组合问题，即覆盖功能测试，最少能有多少种排列组合。==

正交表步骤

  1. 确定测试参数及其取值：列出所有要测试的参数及其可能的取值。

  2. 确定合适的正交表：根据参数数量和每个参数的取值数量，选择对应的正交表。

  3. 分配参数到正交表：将测试参数分配到正交表的列中。

  4. 生成测试用例：根据正交表生成测试用例。

示例

假设我们要测试一个电商平台的结账功能，该功能涉及多个参数和取值：

  • 参数A：支付方式（3个取值）：信用卡、PayPal、银行转账

  • 参数B：配送方式（3个取值）：标准配送、快速配送、店内自提

  • 参数C：优惠券（2个取值）：有优惠券、无优惠券

  • 参数D：用户状态（3个取值）：未登录用户、注册用户、VIP用户

使用正交表测试方法，我们可以构建一个4个因素、3个水平^[1]^的正交表（L9表），以确保在有限的测试用例中覆盖尽可能多的组合。

[1] 在正交表测试方法中，因素（Factors）指的是需要测试的输入变量，每个因素有若干个水平（Levels），即每个因素可能的取值。选择4个因素、3个水平是基于以下原因：

  • 因素数量：选择4个因素（支付方式、配送方式、优惠券、用户状态）是因为这些变量对于结账功能的影响较大，且相互之间存在组合关系。

  • 水平数量：每个因素的取值数量选择3个，是为了在有限的测试用例中能够覆盖尽可能多的组合情况。具体来说：

    • 支付方式：常见的有3种主要方式（信用卡、PayPal、银行转账）。

    • 配送方式：常见的有3种主要方式（标准配送、快速配送、店内自提）。

    • 优惠券：有或没有优惠券这两种情况。

    • 用户状态：通常有未登录用户、注册用户和VIP用户这三种。

正交表L9（3^4）
用例编号 A：支付方式 B：配送方式 C：优惠券 D：用户状态
1 信用卡 标准配送 有优惠券 未登录用户
2 信用卡 快速配送 无优惠券 注册用户
3 信用卡 店内自提 有优惠券 VIP用户
4 PayPal 标准配送 无优惠券 注册用户
5 PayPal 快速配送 有优惠券 VIP用户
6 PayPal 店内自提 无优惠券 未登录用户
7 银行转账 标准配送 有优惠券 VIP用户
8 银行转账 快速配送 无优惠券 未登录用户
9 银行转账 店内自提 有优惠券 注册用户
测试用例
测试用例编号 支付方式 配送方式 优惠券 用户状态 预期结果 实际结果
TC_001 信用卡 标准配送 有优惠券 未登录用户 提示登录或注册，结账成功 待填写
TC_002 信用卡 快速配送 无优惠券 注册用户 结账成功，费用正确 待填写
TC_003 信用卡 店内自提 有优惠券 VIP用户 结账成功，应用优惠，费用正确 待填写
TC_004 PayPal 标准配送 无优惠券 注册用户 结账成功，费用正确 待填写
TC_005 PayPal 快速配送 有优惠券 VIP用户 结账成功，应用优惠，费用正确 待填写
TC_006 PayPal 店内自提 无优惠券 未登录用户 提示登录或注册，结账成功 待填写
TC_007 银行转账 标准配送 有优惠券 VIP用户 结账成功，应用优惠，费用正确 待填写
TC_008 银行转账 快速配送 无优惠券 未登录用户 提示登录或注册，结账成功 待填写
TC_009 银行转账 店内自提 有优惠券 注册用户 结账成功，应用优惠，费用正确 待填写

总结

利用正交表方法在有限的测试用例中覆盖尽可能多的组合情况，从而在保证测试全面性的同时，减少测试工作量，提高测试效率。正交表测试方法在处理多因素、多水平组合时，能够有效地优化测试过程，确保不同组合的充分测试。

场景法

概述

场景法（Scenario Testing）是一种以用户视角出发，模拟实际使用情况来设计测试用例的方法。通过描绘典型用户在实际使用系统过程中的场景，可以确保测试覆盖用户的主要使用路径和关键功能，提升测试的实际效用。

场景法步骤

  1. 确定目标用户和目标功能：明确需要测试的目标用户和目标功能。

  2. 分析用户行为：了解目标用户的行为模式和使用习惯，定义实际使用中的典型场景。

  3. 描述场景：详细描述每个场景中的用户操作步骤和预期结果。

  4. 设计测试用例：基于描述的场景，设计具体的测试用例，包括输入、操作、预期结果等。

示例

假设我们要测试一个电商平台的购物流程，场景法可以帮助我们模拟典型用户的购物过程。

目标功能

测试电商平台的完整购物流程，包括浏览商品、加入购物车、结账支付等功能。

目标用户

普通注册用户、VIP用户

用户行为分析

  1. 用户登录平台

  2. 浏览商品列表

  3. 查看商品详情

  4. 加入购物车

  5. 结账支付

场景描述

  1. 场景1：普通用户的购物流程

    • 用户登录平台

    • 浏览商品列表，选择某一商品查看详情

    • 将商品加入购物车

    • 查看购物车并进行结账

    • 选择支付方式并完成支付

  2. 场景2：VIP用户的购物流程

    • VIP用户登录平台

    • 浏览商品列表，选择多种商品加入购物车

    • 查看购物车并使用VIP优惠券

    • 进行结账，选择快速配送方式

    • 选择支付方式并完成支付

测试用例设计
测试用例编号 场景描述 操作步骤 预期结果
TC_001 普通用户的购物流程 1. 用户登录平台
2. 浏览商品列表，选择某一商品查看详情
3. 将商品加入购物车
4. 查看购物车并进行结账
5. 选择支付方式并完成支付		 1. 登录成功
2. 商品详情显示正确
3. 商品成功加入购物车
4. 购物车显示正确
5. 结账成功，订单生成
TC_002 VIP用户的购物流程 1. VIP用户登录平台
2. 浏览商品列表，选择多种商品加入购物车
3. 查看购物车并使用VIP优惠券
4. 进行结账，选择快速配送方式
5. 选择支付方式并完成支付		 1. 登录成功
2. 多种商品成功加入购物车
3. 优惠券应用成功，价格折扣正确
4. 选择配送方式正确
5. 结账成功，订单生成

总结

一个企业级项目的测试用例一般由多种测试用例设计方法组合而成。根据不能的场景，搭配不同的设计方法。说白了，还是组合模式。选用搭配最佳的那套方案。

场景法适用场景

  1. 用户行为测试：模拟用户在系统中的实际操作路径，确保关键功能的正确性。

  2. 复杂流程测试：覆盖多个子功能和模块的综合测试，验证系统的整体协同能力。

  3. 回归测试：在功能变更或修复后，验证系统的关键使用路径是否仍然正常。