03.测试用例

季风1132
94 阅读9分钟

测试用例

1.生活中的用例

1766761736823.png

2.介绍

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入，执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求，其实也是一个能够指导软件测试执行的说明书

也就是为测试项目而设计的执行文档

3.分类

  • 正向用例：把正常的流程和符合预期的结果叫做正向用例
  • 反向用例：异常处理的场景叫做反向用例

4.作用

  • 防止漏测
  • 实施测试的标准

5.编写原则

  1. 期望的结果可判定：测试用例有明确的判定标准，比如系统登录成功显示登录成功文案以及个人信息
  2. 测试用例可重复执行：测试用例应该能被反复执行，并且结果保持稳定
  3. 测试用例具有代表性：测试用例的设计应该从典型到特殊延展，并能覆盖核心业务场景

6.包含内容

1766761867231.png

1766761948040.png

1766292186463.png

测试用例的规格在IEEE标准和国标（GB/T）上都有被定义过，主要包含如下内容：

  • 被测试的对象：对应软件特性或者需求
  • 给予的条件：包括输入信息和测试环境，输入信息包含了测试数据和操作步骤（执行路径）
  • 期望的结果：包含软件的执行预期，即期待的程序输出

7.不同软件开发模型下的测试用例

  1. 瀑布模型：通常会有完善的表格来管理测试用例，并持续维护
  2. 敏捷：使用敏捷的方式，测试用例往往跟随着用户故事（用户故事是一种敏捷需求澄清的方法，包含可验收的最小特性集）
  3. RUP（统一软件开发过程）：则要求测试用例可以追溯验证系统行为，采用类似瀑布的方式维护测试用例，但是每个迭代都需要更新，并持续维护

8.设计方法

介绍

测试用例设计的本质思想是，将原本需要穷举的所有测试数据进行科学的归类、选择、划分，以期用最少的测试数据就可以达到最佳的测试效果

设计测试用例遵守的基本思想是MECE原则，它是Mutually Exclusive,Collectively Exhaustive的缩写，中文意思是 相互独立，完全穷尽。这是一种拆解和分析问题的方法，最开始来自于《金字塔原理》一书，能比较好地指导用例设计的相关实践

在设计测试用例时，每个用例的执行（无论是人工还是自动化）都有成本，那么需要尽可能的节约。相互独立的意思是拆分的用例没有交叉，完全穷尽是说拆分的问题需要覆盖到所有的情况。比如，把测试数据用户分为男性用户和学生用户，这样就发生了重叠。当然，MECE是一种理想情况，在测试过程中，很难达到这种情况，否则缺陷也就不会存在了。但是，我们可以尽可能地参考这个原则来设计用例，让每个用例都物尽其用

1766292273539.png

等价类划分法

介绍

是指将程序的输入值的集合划分为若干等价类，等价类又分为有效等价类和无效等价类，从每一类中选取少量数据进行测试

核心概念
  • 等价类：是指将程序的输入值的集合就是等价类
  • 有效等价类：是指将程序的输入值的集合当中符合输入要求的数据就是有效等价类
  • 无效等价类：是指将程序的输入值的集合当中不符合输入要求的数据就是无效等价类

1766292430903.png

1766292482055.png

1766292518996.png

实战

1766415875869.png

边界值划分法

介绍

边界值分析法是针对输入数据的边界值的测试，一般情况下与等价类划分法结合使用，根据各个等价类的边界值设计测试用例

实战

1766416233290.png

错误推测法

错误推测法是基于经验和直觉，以及参考以往测试结果中出现较频繁及较隐蔽的错误，从而推测出程序所有可能出现的错误或异常，选择这些情况下的用例进行测试

判定表驱动法

介绍

判定表驱动法是根据判定条件列出所有可能的组合

实战

1766416548704.png

注意

这个只是用来帮助梳理思路的，还是要转换成正经的测试用例的

因果图法

介绍

因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，适用于检查程序输入的各种组合条件

因果图法比较合适输入条件比较多的情况，测试所有的输入条件的排列组合，所谓的原因就是输入，所谓的结果就是输出

适用场景

等价类划分法和边界值分析法都是着重考虑输入条件，但没有考虑输入条件的组合以及制约关系。测试时必须考虑组合，但又不能考虑所有组合，所以必须考虑采用一种合适的方法对条件组合进行分析和简化。最终目的是用最少的测试用例覆盖最全面的场景

核心概念

因果关系符号：

1766416943507.png

1766416981645.png

1766416999596.png

1766417017750.png

因与因的约束条件：

  • E（互斥）：所有条件中只能有一个成立，但是可以都不成立
  • I（包含）：所有条件中至少有一个成立。可以多选但不能不选
  • O（唯一）：所有条件中有且仅有一个为1。也就是说多个原因中有且只有一个成立
  • R（要求）：如果条件a成立，则要求条件b必须也成立，一个出现，另一个也一定出现
  • M（强制屏蔽）：条件a成立时，条件b不成立。条件a不成立时，条件b不一定
实战

1766417222494.png

1766417261325.png

1766417311695.png

1766417353830.png

正交试验法

介绍

正交实验法是利用正交表来对程序进行测试，用较少的测试用例进行较全面的测试。根据正交表的正交性，从全面试验中挑选出适量的、有代表性的点进行试验

核心概念

1766417432806.png

实战

1766417455376.png

1766417514468.png

功能图法

介绍

就是用功能图形象的描述程序的功能说明，并生成功能图的测试用例

实战

1766417585043.png

1766417640812.png

1766417698172.png

1766417791265.png

场景法

介绍

前面介绍的几种测试用例的设计方法都是针对单次操作的，软件往往都需要进行多次操作。因此，我们需要测试组合后的操作，通过组合操作来设计测试用例，即为使用场景法

软件的流程控制都是通过事件的触发来完成的。单个事件的测试可以用前面介绍的方法来完成，多个事件则需要根据不同的顺序构建不同的事件流，我们将每个事件触发的情景称为场景

根据事件组合而来的用例，也可以称为复合用例。执行复合用例，可以暴露大量的流程问题，提高测试效果

核心概念

如下图所示，场景法一般包含基本流和备选流

image4.png

上图中的直线表示基本流，是最简单的测试路径，曲线表示备选流，是在某个特定的条件下所发生的异常行为

备选流可以从基本流的任何节点开始，也可以回退、跳过基本流的节点

使用场景法的基本操作方法如下：

  1. 根据业务规则，画出基本流的所有的节点
  2. 考虑每一个节点的异常情况，并画出异常节点
  3. 根据可达性，这些节点构成一个有向的图
  4. 对这个图进行遍历，设计用例
注意事项
  • 场景的划分和选择比较重要，软件的场景可能比较多，需要从最重要的场景开始选择
  • 一个场景中可能有多个用户角色，需要特别注意多个角色交替操作的情况
  • 设计场景可以参考开发文档中的用例（Use Case）设计
实战1

1766417875031.png

1766417905089.png

实战2

需求说明：这是一款收银机软件，业务设定为服务员也需要让收银员来操作系统，不记座位模式，使用号牌，收银员可以进行选菜、下单、退菜、打单、结账等操作。后厨可以进行出菜操作

如下图所示，我们可以根据上述需求来设计用例并进行测试，并给出了对应的测试用例

image5.png

  • 基本流：
    • 收银员开始点餐，启动软件后，能加载菜品列表，并显示详情
    • 收银员选择菜品，并设定数量、口味等，确认菜品无误后进入下一步
    • 收银员收到用户费用后，进入下单打印界面，打印小票给后厨，并打印账单给客户，收银员可以在结账后回到点餐状态，为下一次点餐做准备
    • 后厨看到小票开始做菜，出菜后由后厨确认出菜
    • 系统接收到确认某个订单的所有出菜信息后，标记订单完成，用于统计和收银员对账
  • 备选流1未结账回退：
    • 收银员开始点餐，启动软件后，能加载菜品列表，并显示详情
    • 收银员确认菜品无误后，进入下单打印界面
    • 收银员可以选择返回上一步，软件记录之前的菜品选择
  • 备选流2结账后退菜：
    • 顾客可能点单后选择退菜，软件允许相应的操作
    • 完成基本流的前两个步骤
    • 从历史订单进入，选择退菜操作，只能选择未出菜的菜品项目
  • 备选流3结账后取消订单：
    • 顾客可能点单后选择取消订单，软件允许相应的操作
    • 完成基本流的前两个步骤
    • 从历史订单进入，选择取消订单操作，只能选择未发生出菜的订单

9.测试平台

在一些团队会使用思维导图作为测试用例，但是这种形式比较难以维护。越来越多的公司会创建自己的测试管理平台，思维导图则作为测试用例的补充

avatar
文章
阅读
粉丝