Day6 设计用例的方法（因果图、正交表经验测试的三种方法、设计用例方法概括、测试用例设计总结、白盒测试）

一、因果图（了解即可）

1、因果图的作用：对不同的组合情况来设计测试用例，最终用来生成判定表 ！！！

（1）定义：
因果图提供了一个把规格转化为判定表的系统化方法，从该图中可以产生测试数据。其 中，
原因是表示输入条件，结果是对输入执 行的一系列计算后得到的输出
（2）作用：
因果图方法最终生成的就是判定表。它适合于检查软件输入条件的各种组合情况
（3）

a.因果图中的约束 在实际问题中输入状态相互之间、输出状 态相互之间可能存在某些依赖关系，称为“约 束”。对于输入条件的约束有E、I、O、R四种 约束， 对于输出条件的约束只有M约束。 ØE约束(异)：a和b中最多有一个可能为1，即a和b不能 同时 为1。 ØI 约束(或)：a、b、c中至少有一个必须为1，即 a、b、 c不能同时为0。 ØO约束(唯一)：a和b必须有一个且仅有一个为1。 ØR约束(要求)：a是1时，b必须是1，即a为1时，b不能 为0。 ØM约束(强制)：若结果a为1，则结果b强制为0。 b.因果图中的4种基本关系 在因果图的基本符号中，图中的左结点ci 表示输入状态（或称原因），右结点ei表示输出 状态（或称结果）。 ci与ei取值0或1，0表示某 状态不出现，1则表示某状态出现。 Ø恒等：若 c1 是1，则 e1 也为1，否则 e1 为0。 案例1：有钱=====富豪
Ø非：若 c1 是1，则 e1 为0，否则e1为1。 案例2：有钱=====穷人
Ø或：若 c1 或 c2 或 c3 是1，则 e1 为1，否则 e1 为0。 案例3： 有车、 有房、 满足一个有钱人
有存款

Ø与：若 c1 和 c2 都是1，则 e1 为1，否则 e1 为0。 案例4： 有车、 有房、 满足三个是：有钱人 有存款

(4)
因果图转换判定表的方法：
1. 将因果图中的所有条件（因）填入判定表 的条件桩中；
2. 将因果图中的所有动作（果）填入判定表 的动作桩中；
3. 根据因果图确定各个条件组合对应的动作， 并且确定判定表中各个规则的条件项和动 作项， 在需要时优化判定表。

(5)
因果图的步骤：

1.把大的系统规格划分解成可以测试的规格片段
2.分析分解后待测的系统规格，找出哪些是原因，哪些是结果
3.画出因果图 4.把因果图转换成判定表
5.简化判定表
6.用判定表中的每一列生成测试用例 (6)
因果图的优点/缺点
优点：

1. 等价类法尽管各个输入条件可能出错的情况都考虑 到了，但是多个输入条件组合起来出错的情况却被 忽略了

2. 因果图法能够帮助我们按照一定步骤，高效的选择 测试用例，设计多个输入条件组合用例

3. 因果图分析还能为我们指出，程序规格说明描述中 存在什么问题

缺点：

1. 输入条件与输出结果的因果关系，有时难以从软件 需求规格说明书得到
2. 即使得到了这些因果关系，也会因为因果关系复杂 导致因果图非常庞大，测试用例数目及其庞大

================================
案例： 因果图案例：
一个处理单价为5角钱的饮料的自 动售货机。其规格说明如下： 若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币

二、正交表（了解即可）

正交表

1、正交试验

正交试验设计法，是从大量的试验点中挑选

出适量的、有代表性的点，应用依据迦罗瓦

理论导出的“正交表”，合理的安排试验的

一种科学的试验设计方法，

2、正交表常用的术语

指标:通常把判断试验结果优劣的标准叫做试验的指标

因子:所有影响试验指标的条件

水平值:影响试验因子的取值

因子：条件   3（姓名、身份证、手机号）

水平值：2个水平值（填和不填）

2的3次方 8种方法，现在用正交表用4种方法代替

公式：实验数=因子*（水平数-1）+1

4=3*（2-1）+1

实验数是4

映射正交表

2的8次方=256种方法

正交法用 8种方法代替

正交表特点:

1》整齐可比性

在同一张正交表中，每个因素的每个水平出现的次数是完全相同的由于在试验中每个因素的每个水平与其它因素的每个水平参与试验的机率是完全相同的，这就保证在各个水平中最大程度的排除了其它因素水平的干扰。

2》均衡分散性

在同一张正交表中，任意两列(两个因素)的水平搭配(横向形成

的数字对)是完全相同的。这样就保证了试验条件均衡地分散在因素水平的完全组合之中，因而具有很强的代表性，容易得到好的试验条件。

3、用正交表设计测试用例的步骤，

(1)有哪些因素(变量或条件)

(2)每个因素有哪几个水平(变量或条件的取值)

(3)为了满足整齐可比性，选择一个合适的正交表

(4)把变量的值映射到表中(建议第1行是全真或全假)

(5)把每一行的各因素水平的组合做为一个测试用例

加上你认为可疑且没有在表中出现的组

正交的原则:两两组合

三、经验测试三种方法

1、基于经验的测试技术之错误推测法

错误推测法也叫错误猜测法，

就是根据经验猜想，已有的缺陷，测试经验和失败数据等可能有什么问题并依此设计测试用例

2、基于经验的测试技术之异常分析法

系统异常分析法就是针对系统有可能存在的异常操作、软硬件缺陷引起的故障进行分析，依此设计测试用例。主要针对系统的容错能力、故障恢复

能力进行测试。

3、基于经验的测试技术之随机测试

随机测试指的是测试中的所有的输入数据都是随机生成的，其目标是模拟用户的操作。

真实环境中，尤其是软件刚刚发布时，会有成千上万的人在上面乱敲乱试:因此在发布软件前，用模拟用户的随机测试就可能发现其它方式漏掉的软件缺陷。

四、设计用例方法概况：

五、测试用例设计的综合策略总结

1、使用各种测试方法思路:

1.在任何情况下都必须使用边界值分析方法，

经验表明用这种方法设计出测试用例发现程序错误的能力最强;

2.必要时用等价类划分方法补充一些测试用例;

3.用错误推测法再追加一些测试用例(依靠经验):

4.如果程序的功能说明中含有输入条件组合情况，

则可选用因果图/判定表;

5.对业务流程场景清晰的系统，使用场景法贯穿:

6.检查已设计的测试用例的覆盖程度;

7.最后要考虑异常分析，再进行综合使用。

2、个人总结：

1、梳理项目流程：通过场景法测试主流程

例如：注册--登录--搜索商--选择商品--立即购买--支付--收货

2、等价类有效，无效的用例，

例如：姓名（有效名字，无效名字）

3、注册输入的手机号，我可以用边界值设计用例；

例如：手机号11位，（10，11，12）

4、针对组合情况，用判定表，因果图，正交表来设计用例

例如：注册（姓名，手机号，身份证号，验证码）

5、再用状态迁移法设计：状态用例

例如：注册申请状态：（申请成功，申请失败，申请种）

6、再根据经测试方法补充用例

（错误推测法，异常分析法，随机测法）

六、测试用例的设计步骤

1.构造根据设计规格得出的基本功能测试用例

2.边界值测试用例

3.状态转换测试用例

4.错误猜测测试用例

5.异常测试用例

6.其它测试类型测试用例(如性能测试，易用性测试，安全测试等)

七、如何设计好用例：

使用10种测试设计用例方法不断进行分解与合并

七、白盒测试方法（了解即可）

白盒测试（结构测试或者逻辑驱动测试）

（1）定义：白盒测试也叫透明盒测试，检查程序内部结构及路径一是否符合规格说明，二是否符合其代码规范。

（2）白盒测试常见方法：（重点）

a.语句覆盖；

b.判断覆盖（也称“分支覆盖”）；

c. 条件覆盖；

d.判断、条件覆盖；

e.条件组合覆盖；

f.路径覆盖   (分为：z路径和独立路径)

（3）详解白盒测试方法

1、

语句覆盖：

指设计若干个测试用例，使得程序运行时，每个可执行语句至少被执行一次

2、

判断覆盖(分支覆盖)：

指设计若干个测试用例，使得程序运行时，每个判断条

件的真假分支至少被执行一次

3、

条件覆盖：

指设计若干个测试用例，使得程序运行时，每个判断条件中的每个判断式的真、假值至被执行一次

4、判断、条件覆盖：

指设计若干个测试用例，使得程序运行时，每个判断条件中真、假值分支至少被执行一次，且每个判断条件的内部判断式的真、假值至少被执行一次。

5、

条件组合覆盖：

指设计若干个测试用例，使得程序运行时，每个判断条件的内部判断式的各种真假组合都至少被执行一次；是逻辑覆盖测试中“覆盖能力”最强的。

6、

路径覆盖：

旨在保证程序中每一个特定的路径方案都能正常运行。

常见的路径覆盖方法：2种

A:独立路径覆盖

定义：

即覆盖所有的独立路径的测试，所谓独立路径应至少包含一条在其它路径中从未有过的边

B:Z路径覆盖

二、

Z路径覆盖：

是一种将实际项目中复杂的程序减少其循环次数的路径覆盖方法，

即：不考虑循环体实际需要执行多少次，只考虑通过循环体0次和1次这两种情况

Z路径覆盖：

0次循环：直接跳过循环体，从循环体入口直接到出口

1次循环：通过一次循环体即可

备注：

 &&(短路与)， ||(短路或)，

三、

（4）白盒测试方法的优点：

1.深入程序内部，测试粒度较细。

2.是测试用例设计方法的组成部分，也是黑盒测试方法的有力补充。

3.为自动化测试与性能测试奠定基础。

（5）白盒测试方法的缺点：

1.过分关注代码本身，容易偏离SRS实际需求

2.对相应的编程语言要求较高，人力成本较大