黑盒测试用例设计方法

测试数据选择

• 等价类划分
• 边界值分析法

测试步骤设计

• 因果图法
• 判定表法
• 正交实验法
• 功能图法
• 场景法

测试数据选择

等价类划分法

确定等价类的原则

• 在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类
• 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效的等价类和一个无效的等价类
• 在输入条件为一个布尔值的情况下，可以确定一个有效等价类和一个无效等价类
• 在规定了输入数据必须遵守的规则的情况下，可确定一个有效等价类和若干个无效等价类（从不同角度违反规则）

划分等价类和列出等价类表

• 有效等价类
• 无效等价类

确定测试用例：

• 为每个等价类规定一个唯一的编号
• 设计新的测试用例，使其尽可能地覆盖尚未覆盖地有效等价类。重复这一步
• 设计新的测试用例，使其只覆盖一个无效等价类。重复这一步

边界值分析法

• 如果输入条件规定了值的范围，则应取刚到达这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据
• 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据
• 如果程序的规格说明书给出的输入域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例
• 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例
• 分析规格说明书，找出其他可能的边界条件

测试步骤设计

因果图法（分析设计缺陷）

因果图法是一种适合于描述对于多种输入条件组合的测试方法
它适合于检查程序输入条件涉及的各种组合情况

步骤：（适合局部小功能）

• 根据功能说明书中规定的原因和结果之间的关系画出因果图
• 根据功能说明在因果图中加上约束条件
  互斥
  包含
  唯一
  要求
  要求
  屏蔽
  其中互斥、包含、唯一、要求是对原因的约束，屏蔽是对结果的约束
• 根据因果图画出判定表
• 为判定表的每一列设计一个测试用例

正交实验法

• 基本思想：
  在一项实验中，把影响实验结果的量称为试验因素，简称因素。在实验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。
  每列中不同的数字出现的次数相等。
  在任意2列其横向组成的数字对中，每种数字出现的次数相等。
• 基本步骤：
  1 确定因素：这里的因素是指对软件运行结果有影响的软件
  确定因素的取值范围或集合
  2 确定每个因素的水平
  根据因素的取值范围或集合，采用等价类划分、边界值分析以及其他软件测试技术，在每个因素的取值范围或集合内挑选有效等价类、无效等价类、正好等于、刚刚大于等有代表性的测试值
  3 选择正交表
  根据确定的因素和水平，选择合适的正交表
• 正交实验法

正交表：一种特制的表
m是水平数，k因素数,n是需要进行实验的行数

行数：正交表中的行的个数，即实验的次数
因素数：正交表中列的个数，即要测试的功能点
水平数：任何单个因素能够取得的值的最大个数

正交表的种类

各列水平数均相同的正交表
混合水平正交表

正交表的特性

整齐可比、均衡分散

场景法

• 原理：
  现在的软件几乎都是用事件触发来控制流程。测试时，可以生动的描述出事件触发时的场景，有利于设计测试用例，同时使测试用例更容易理解哈执行。
  基本流：软件功能按照正常的事件流实现的一条正确流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。
  备选流：除了基本流之外的各支流，包括各种不同的情况。
• 设计测试用例的步骤
  根据说明，描述出程序的基本流及各项备选流
  根据基本流和各项备选流生成不同的场景
  对每个场景生成相应的测试用例
  对生成的所有测试用例重新复审，去掉多余的测试用例
  测试用例确定后，对每个测试用例确定测试数据值
  场景法适合解决业务流程清晰的系统或功能

状态迁徙法（功能图）（局部分析）

• 来源
  在遇到有事务流或由于某种条件成立导致状态改变的软件时
• 目标
  设计足够多的测试用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖
• 未完

测试大纲法

• 一种着眼于需求的方法
• 为列出各种测试条件，将需求转换为大纲的形式

用例设计方法选择的综合策略

• 首先进行等价类划分
• 在任何情况下都必须使用边界值分析法
• 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法
• 对于参数配置类的软件，要使用正交实验法选择较少的组合方式达到最佳的效果
• 状态迁移图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据
• 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程
• 可以用错误推测法追加一些测试用例
• 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例