测试用例设计方法——等价类划分法、边界值分析法、场景法、判定表、因果图、错误推测法和正交试验法

一、等价类划分

二、边界值分析法

三、场景法

四、判定表

五、因果图

六、错误推测法

七、正交试验法

---

一、等价类划分

定义：依据需求将输入划分成若干个等价类，从等价类中选定一个测试用例，如果该用例通过，则表明整个等价类通过。

适用范围：适用于有无限多种输入。

目的：使用较少的测试用例尽可能多的将功能覆盖。

有效等价类：有意义的输入构成的集合，对需求规格说明书来说是合法的。

无效等价类：不满足需求的输入。

例如：学生成绩录入系统，分数X为0到100的整数。

有效等价类：0≤X≤100（50）

无效等价类：X≤0（-5），X≥100（200）

如果没有整数要求，还要考虑小数，非数字（字母，汉字，特殊字符）和空值。

但只按照等价类划分还不够，还要考虑边界值。

二、边界值分析法

边界值分析法是对等价类划分法的补充，一般从等价类的边界寻找错误。

边界值分析法的基本思路：

正好等于边界值，刚好小于边界值，刚好大于边界值作为测试数据。

特殊：0/空是特殊的值，在考虑边界值的时候也要考虑这个特殊值。

边界值思想的体现：网上购物，库存12。

数量=11：下单成功；数量=12：下单成功；数量=13：下单失败，并给出提示。

例如：学生成绩录入系统，分数X为0到100的整数。

上边界：99，100，101

下边界：-1，0，1

所以等价类+边界值的取值范围为：-5，-1，0，1，50，99，100，101，200

因此可分成两个用例：有效输入：0，1，50，99，100；无效输入：-5，-1，101，200。

再例如：微信红包，最小0.01，最大200。

等价类+边界值的取值范围：-100.00，0，0.01，0.02，50.00，199.99，200，200.01，300.00。

三、场景法

基于用户场景梳理业务逻辑，再挑选合适的方法设计测试用例，尽可能真实全部的模拟用户操作。

场景法主要基于：

1、业务需求层面：对所测软件的重要功能、业务逻辑（系统要干什么、怎么去实现这个过程的）和行业背景进行深入理解。

2、技术层面需求：基于等价类划分

有效等价类：模拟用户正确操作；无效等价类：模拟用户错误的操作；

3、核心概念

基本流（正确流，有效流）：模拟用户正确的操作流程。

备选流（错误流，无效流）：模拟用户错误的操作流程。

举个例子，比如银行ATM取款

基本流：正确插入银行卡，点击取款，输入正确的密码，输入正确的金额，确认，退卡。

备选流1：输入错误的密码

备选流2：输入超过余额的金额

备选流3：卡插反了

备选流4：退卡

再根据每个场景来设计测试用例。

四、判定表

1、定义

分析和表述若干输入条件下，被测对象针对这些输入做出相应反应的一种工具。

2、适用范围

遇到复杂业务逻辑时可用该表理清逻辑关系。

3、重要概念

条件（输入）：条件桩：需求规格说明书定义的被测对象的所有输入；条件项：针对条件桩可能输入的被测对象的真假值。

动作（输出）：动作桩：针对条件，被测对象可能采取的所有操作；动作项：针对动作桩，被测对象相应的可能取值。

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

4、判定表应用步骤

（1）理解需求，确定条件桩和动作桩；

（2）设计生成判定表；

（3）填写动作项；

（4）根据判定表中输出结果的表现，进行判定表合并，简化判定表。（规则：如果输出相同，在对应输入中，有且只有一个条件的取值对动作桩不产生任何影响的可合并）

比如：订购单的检查（订购单：客户在公司订货后，开具的证明，有日期限制）

如果金额超过500元，又未过期，则发出批准单和提货单；

如果金额超过500元，但又过期了，则不发批准单；

如果金额低于500元，则不论是否过期都发出批准单和提货单；

在过期的情况下还需要发出通知单。

判定表分析：

（1）确定条件桩和动作桩

条件桩	条件项
订购金额是否大于500元	1：金额大于500元 0：金额小于等于500元
订购单是否过期	1：过期 0：未过期
动作桩	动作项
发出批准单	X：表示发出批准单
发出提货单	X：表示发出提货单
发出通知单	X：表示发出通知单

（2）设计生成判定表

条件桩	条件项
订购金额是否大于500元	1	1	0	0
订购单是否过期	1	0	1	0
动作桩	动作项
发出批准单	X		X	X
发出提货单	X		X	X
发出通知单				X

 

（3）简化判定表

条件桩	条件项
订购金额是否大于500元	——	1	0
订购单是否过期	1	0	0
动作桩	动作项
发出批准单	X		X
发出提货单	X		X
发出通知单			X

 

判定表的一列就是一个用例。

再比如，小张的老婆给小张一个任务，让他去一个软件上挑选合适的房子，给了如下四个条件：
1.学区房 2.地铁口 3.三室两厅两卫4.主卧朝南
必须满足三室两厅两卫，其余三个条件里只要满足两个就可以买，否则不买。

可以试试练习一下。

五、因果图（Cause-Effect Graph）

是一种描述输入条件的组合以及每种组合对应的输出的图形化工具。

1、因果图的基本图形符号

         

（a）恒等。若原因出现，则结果出现；若原因不出现，则结果不出现。

（b）非。若原因出现，则结果不出现；若原因不出现，则结果出现。

（c）或。若几个原因中有一个出现，则结果出现；若几个原因均不出现，则结果不出现。

（d）与。若几个原因都出现，则结果才出现；若几个原因中有一个不出现，则结果不出现。

2、因果图中的约束条件

从原因方面考虑主要有四种约束条件：

（a）E（互斥、排他）：a，b两个原因不会同时出现，最多只有一个出现。

（b）I（包含、或）：a，b，c三个原因至少有一个出现。

（c）O（唯一）：a，b两个原因必须有一个出现，且仅有一个出现。

（d）R（需求）：a出现时b一定出现。

从结果方面考虑主要有一种约束条件：

（e）M（屏蔽）：a出现时，b必定不出现；a不出现时，b则不确定。

3、利用因果图设计测试用例的步骤：

（1）分析需求规格说明书中哪些是原因，哪些是结果。（原因是指输入条件或输入条件的等价类，结果是指输出条件，给每一个原因和结果赋一个标识符）

（2）确定原因与原因，原因与结果之间的关系，画出因果图。

（3）由于某些要求，一些原因与原因之间，原因与结果之间的组合不能出现。对于这些特殊情况，在因果图中用记号表明约束或限制条件。

（4）将因果图转化为判定表。

（5）根据判定表的每一列设计测试用例。

因果图法设计测试用例举例：

有一个单价为五角硬币的饮料自动售货机软件，对其采用因果图法设计测试用例，需求如下（不考虑其他特殊情况）：

（1）若售货机没有零钱找，则一个现实“零钱找完”的红灯亮，以提醒顾客在此情况下不要投入一元硬币，否则此红灯不亮；

（2）顾客投入五角硬币，然后按下“橙汁”或“啤酒”按钮，则相应的饮料被送出；

（3）顾客投入一元硬币并按下“橙汁”或“啤酒”按钮后，若售货机没有零钱找，则显示“零钱找完”的红灯亮，一元硬币被退出，且无饮料送出；若有零钱找，则五角硬币退出且饮料被送出。

①列出原因和结果

列出原因			中间			列出结果
编号	原因		编号	中间节点		编号	结果
1	售货机有零钱找		11	投入一元硬币，并按饮料按钮		21	“零钱找完”红灯亮
2	投入一元硬币		12	按“啤酒”或“橙汁”按钮		22	退出一元硬币
3	投入五角硬币		13	退还五角零钱且售货机有零钱找		23	退出五角硬币
4	按“橙汁”按钮		14	钱已付清		24	送出“橙汁”
5	按“啤酒”按钮					25	送出“啤酒”

②画出因果图

③列出判定表

由因果图得到的判定表（0表示其代表的状态不出现，1表示其代表的状态出现）
序号			1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32
原因	1	售货机有零钱找	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
	2	投入一元硬币	1	1	1	1	1	1	1	1	0	0	0	0	0	0	0	0	1	1	1	1	1	1	1	1	0	0	0	0	0	0	0	0
	3	投入五角硬币	1	1	1	1	0	0	0	0	1	1	1	1	0	0	0	0	1	1	1	1	0	0	0	0	1	1	1	1	0	0	0	0
	4	按“橙汁”按钮	1	1	0	0	1	1	0	0	1	1	0	0	1	1	0	0	1	1	0	0	1	1	0	0	1	1	0	0	1	1	0	0
	5	按“啤酒”按钮	1	0	1	0	1	0	1	0	1	0	1	0	1	0	1	0	1	0	1	0	1	0	1	0	1	0	1	0	1	0	1	0
中间节点	11	投入一元硬币，并按饮料按钮						1	1			0	0			0	0							0	0			0	0			0	0
	12	按“啤酒”或“橙汁”按钮						1	1			1	1			1	1							1	1			1	1			1	1
	13	退还五角零钱且售货机有零钱找						1	1			0	0			0	0							0	0			0	0			0	0
	14	钱已付清						1	1			1	1			0	0							0	0			1	1			0	0
结果	21	“零钱找完”红灯亮						0	0			0	0			0	0							1	1			0	0			0	0
	22	退出一元硬币						0	0			0	0			0	0							1	1			1	1			1	1
	23	退出五角硬币						1	1			0	0			0	0							0	0			0	0			0	0
	24	送出“橙汁”						1	0			1	0			0	0							0	0			1	0			0	0
	25	送出“啤酒”						0	1			0	1			0	0							0	0			0	1			0	0

④优化判定表

六、错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

28原则：80%的问题出在20%的模块

基本思想：列举程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。

基本要素：1、对开发的开发习惯很熟悉；2、对同类型项目业务非常熟悉。

七、正交试验法

正交试验法是研究多因素、多水平的一种试验法，它是利用正交表来对试验进行设计，通过少数的试验替代全面试验根据正交表的正交性从全面试验中挑选适量的、有代表性的点进行试验，这些有代表性的点具备“均匀分散，整齐可比”的特点。

例如，某系统会员的功能表：

功能	普通会员	中级会员	高级会员
功能1	*	*	*
功能2	*	*	*
功能3	*	*	*
功能4	*	*	*
功能5	*	*	*
功能6	*	*	*
功能7	*	*	*
功能8	*	*	*
功能9	*	*	*
功能10		*	*
功能11		*	*
功能12		*	*
功能13			*
功能14			*

对于功能1—功能9，可以用正交试验法进行测试用例的设计：

功能	普通会员	中级会员	高级会员
功能1	*
功能2	*
功能3	*
功能4		*
功能5		*
功能6		*
功能7			*
功能8			*
功能9			*

功能	普通会员	中级会员	高级会员
功能1	*
功能2		*
功能3			*
功能4	*
功能5		*
功能6			*
功能7	*
功能8		*
功能9			*

以上两种方式都满足了“均匀分散，整齐可比”的特点。

总结：关于测试用例的设计，一般先按照场景法进行梳理，再加上等价类+边界值，基本可以完成大部分的用例设计；如果输入和输出很多的情况，可以用判定表理清逻辑关系；如果判定表不行，就先用因果图分析，再用判定表整理；如果遇到有功能大部分相似，但要进行区分的情况，可以利用正交试验法“均匀分布，整齐可比”的特点进行设计；最后再用凭借直觉和经验用错误推测法查漏补缺。