软件测试理论基础总结(四)--编写测试用例的方法

1、等价类

概念:

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过。

类型:

有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合

无效等价类：根据需求说明书，不满足需求的集合

适用场景：

有数据输入的地方，就可以使用等价类划分法。如：输入框

思考出发点：

考虑输入数据的数据类型(输入类型)

考虑数据范围（输入长度）

为每一个等价类进行编号

从一个等价类中选举一个测试数据构造测试用例

例：

2.边界值

概念:

是有效等价类和无效等价类之间的分界点

三点:

上点：边界上的点

离点：里上点最近的点

内点：边界有效范围内任意一点

如何确定离点？

如果边界是闭区间，则离点在外

如果边界是开区间，则离点在内

以[6,18],(6,18)为例

上点：6,18

[6,18]的离点：5,19

(6,18)的离点：7,17

内点：10

适用场景：

有数据输入的地方，在实际工作中，一般和等价类划分一起适用。

3.因果图/判定表（不太重要，当熟练后可以直接适用判定表，不画因果图）

概念:

通过画图的方式表达输入条件和输出结果之间的关系

原因和结果之间的关系：

与：只有2个原因都为真，那么结果为真

或：2个原因中有一个为真时，结果就为真

非：只有原因为假，结果才为真

与非：先与后非，2个都为真，结果为假

或非：先或后非，两个为假，结果为真

原因和原因的关系：

包含性约束：不可以同时为假

排他性约束：不能同时为真

必要性约束：当原因a为真时，原因b必须同时为真；但是原因b为真时，原因a既可以为真，也可以为假。

例如：2个原因--你是妈妈，你结婚了

唯一性约束：有且只有原因a和原因b中的一个为真

例如：男女

结果与结果的关系:

掩码标记（结果约束）：如果结果b为真，那么结果a一定为假，如果结果b为假，则结果a的状态不定

例如：2个结果—你变得难看了、你变得漂亮了

名词术语:

因果表：

因：输入条件

果：输出结果

判定表：

条件桩：问题的所有条件

动作桩：问题的所有输出

条件项：针对条件桩的取值

动作项：条件项的各种取值情况下的输出结果

规则：动作项和条件项组合在一起，形成的业务逻辑处理规则

例：一胖妞减肥，第一条件必须是每餐只能吃一个苹果或者一块牛肉，第二个条件必须每天锻炼1个小时，在此情况下则可以每天减肥1斤。但如果第一个条件不满足，则出现经常晕倒情况；如果第二个条件不满足，则只能减1俩肉

确定原因和结果：

确定因果逻辑关系：

原因c1还可以细分为2个原因：第一是吃一个苹果（c11），或者是吃一块牛肉（c12）

确定约束关系：

根据因果图画决策表：

根据原因分析结果：分析每一种状态对应的结果，并根据约束关系，去掉不可能出现的状态：

设计测试用例：

判定表：

适用场景：

对于复杂业务逻辑时，可以利用该表理清业务逻辑关系

4.正交排列法（不重要）

概念:

因子：所有参与试验的影响试验结果的条件称为因子

水平：影响试验因子的取值或输入称为水平

特点：

在同一张正交表中，每个因子每个水平出现的次数完全相同，试验中，每个因子的每个水平与其他因子的水平参与试验的机率完全相同

同一张正交表中，任意两列的水平搭配是完全相同的

设计流程

分析测试需求获取因子及水平

根据因子水平选择合适的正交表

替换因子水平，获取试验次数

根据经验或其他因素补充试验次数

细化输出获得测试用例

例：对某人进行查询

假设查询某个人时有三个查询条件：

根据“姓名”查询

根据“身份证号码”查询

根据“手机号码 ”查询

考虑查询条件要么不填写，要么填写，此时可用正交表进行设计

因素数和水平数：

有三个因素：

姓名、身份证号、手机号码

每个因素有两个水平：

姓名：填、不填

身份证号：填、不填

手机号码：填、不填

选择正交表

表中的因素数＞＝3

表中至少有三个因素的水平数＞＝2

行数取最少的一个

姓名：0-->填写,1-->不填写

身份证号：0-->填写,1-->不填写

手机号码：0-->填写,1-->不填写

测试用例

1：填写姓名、填写身份证号、填写手机号

2：填写姓名、不填身份证号、不填手机号

3：不填姓名、填写身份证号、不填手机号

4：不填姓名、不填身份证号、填写手机号

增补测试用例

5：不填姓名、不填身份证号、不填手机号

测试用例减少数：8-->5

适用场景：

在一个界面中有多个控件，每个控件有多个取值，要考虑不同控件不同取值之间的组合 ，且组合数量较大的话，我们就可以使用正交排列法

5.状态图（不重要）

概念:

关注被测对象的状态变化，在需求规格说明书中是否有不可达到的状态和非法的状态，是否产生非法的状态转移

状态：被测对象在特定输入条件下所保持的响应形式

方法流程：

根据需求提取全部状态

绘制状态迁移图

根据状态迁移图推导测试路径（状态迁移树）

选取测试数据，构造测试用例

状态迁移图的优缺点：

优点：保证每一个功能/状态的可达项都被覆盖

缺点：对无效的路径无法覆盖

例：

需求：路人甲打电话预订飞机票，要去某地。

分析：

测试需求分析：

a).客户向航空公司打电话预订机票。此时，机票信息处于“完成预订”状态；

b).顾客支付了机票款项后，机票信息变为“已支付”状态；

c).客户当天到达机场并使用身份证换领登机牌后，机票信息变为“已出票”状态；

d).检票登机后，机票信息变为“已使用”状态；

e).在登机前，可以取消自己的订票信息，若已支付机票费用，则可以退回票款。

取消后，订票信息处于“已取消”状态；

由以上分析得出客户预订机票时订单的全部状态：

完成预定、已支付、已出票、已使用、已取消；

测试设计方法分析（状态迁移法）：

a).状态迁移图：

b).测试路径（状态迁移树）：

由状态迁移图得出的测试路径：

(1).A->B->E；

(2).A->B->C->E；

(3).A->B->C->D。

用例设计（输入部分）：

(1).完成预定->已支付->已取消；

(2).完成预定->已支付->已出票->已取消；

(3).完成预定->已支付->已出票->已使用；

6.流程分析法（场景设计法）

场景划分：

1）基本流（有效流、正确流）

模拟用户正确的业务操作流程就是基本流

2）备选流（无效流、错误流）

模拟用户错误的操作流程就是备选流

适用场景：

业务比较复杂的软件系统都适合使用场景法，场景法是基于软件业务的测试方法，测试人员把自己当成最终用户，尽可能真实的模拟用户在使用此软件的操作情形

重点模拟两类操作：

用户正确操作的业务过程—验证软件的业务功能是否正确实现

模拟用户错误操作的情形—验证软件的异常处理能力（健壮性）

测试思路：

场景法是模拟用户操作软件时的各种情景，主要用于测试软件的业务逻辑和流程。当拿到一个测试任务是，我们并不先关注某个文本框的等价类等是否满足要求，而是先关注它的主要功能和业务流程是否正确实现，这就需要场景法来完成测试。当业务流程测试没有问题，也就是软件的主要功能没有问题时，我们再去关注控件的等价类、边界值等细节测试。（先整体后细节）

例：

在线购物系统

我们都在当当网或china-pub华章网上书店都订购过书籍，整个订购过程为：用户登录到网站后，进行书籍的选择，当选好自己心仪的书籍后进行订购，这时把所需图书放进购物车，等进行结帐的时候，用户需要登录自己注册的帐号，登录成功后，进行结帐并生成订单，整个购物过程结束。

那么我们通过以上的描述，从中确定哪是基本流，哪些是备选流：

根据基本流和备选流来确定场景：

我们来设计用例

对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。

下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。

本例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

我们看到以上表中，是把每个场景成立的条件进行了分析，基本上已经明确了测试用例的数量，现在只要把真实数据填充上，那么整个测试用例就完成了。

声明：本文部分内容可能来源或整理自网络，如有侵权，请联系删除