一、等价类划分

二、边界值分析法

三、场景法

四、判定表

五、因果图

六、错误推测法

七、正交试验法

---

一、等价类划分

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

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

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

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

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

例如：学生成绩录入系统，分数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			*

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

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

黑盒测试

不考虑程序内部的结构与特性，只根据程序功能或程序的外部特性设计测试用例。
最常见的是：边界值 等价类 错误推测法 场景法 因果图法 判定表组成法 正交实验设计

黑盒测试主要发现的错误

• 功能不正确或遗漏
• 界面错误
• 数据库访问错误
• 性能错误
• 初始化和终止错误

测试步骤

为什么要设计测试用例

• 良好的测试用例可以缩短实施测试时间
• 确保测试的系统性、全面性
• 提高测试的可复用性

黑盒测试用例设计方法

等价类划分法

把程序的所有可能的输入数据划分为若干个子集，每一子集代表性数据在测试中的作用等价于这一子集的其他值，每一个子集就是一个等价类。
等价类需要考虑有效等价类和无效等价类

等价类划分法设计步骤

1. 划分等价类
2. 确定测试用例

: 举例一：成绩等级

输入不同的成绩会得出不同的成绩等级，通过需求可知，程序的所有可能输入数据可划分为4个子集，每一个子集就是一个等价类。我们通过选择每个等价类中的一个数据来代表该等价类的所有数据，若代表数据可输出预期结果，则该等价类测试通过，反之则该等价类测试不通过。
有效等价类：0—100
无效等价类：小于0、大于100、空数据、字符串

以下是举例一等价类划分结果：

举例二：Windows文件命名规则

有效等价类：文件名不包含\ / : * ? " <> | 字符的的、文件名长度在1-255个字符之间的
无效等价类：文件名包含\ / : * ? " <> | 字符的的、文件名长度小于1（即为空字符）的、文件名字符长度大于255个的

以下是举例二等价类划分结果：

举例三：判断三角形类别


以下是举例三等价类划分结果：

边界值法

长期测试经验表明：大量错误发生在输入或输出范围的边界上，而不是发生在输入输出范围内部。因此，对各种边界设计测试用例，能取得良好的效果。

举例一：成绩等级判定

在使用等价类划分法对等价类进行测试后，还要将边界值也设计到测试用例中，尽可能使测试全面。下面我们队上述的例子一的测试用例通过加入边界值法进行完善。
以下是完善后的测试用例：

判定表驱动法

• 判定表是分析和表达较为复杂逻辑条件下软件状态和行为的有效工具。
• 用它可以设计出完整的测试用例集合，将复杂问题的各种可能情况列出，使测试内容变得简单明了二避免遗漏。
  

判定表设计步骤：

1. 确定规则数，条件数为n，规则个数=$$2^n$$
2. 列出所有条件桩和动作桩
3. 填入条件项
4. 填入动作项
5. 简化判定表，合并相似规则

举例一




举例二

=====================================================================

    github 源码同步：https://github.com/Thinkgamer/Machine-Learning-With-Python

一：非二元属性的关联规则挖掘

二：关联规则的评价

支持度和置信度 

项集支持度：一个项集出现的次数与数据集所有事物数的百分比称为项集的支持度

eg：support(A->B)=support_count(A并B) / N

项集置信度（confidence）：数据集中同时包含A，B的百分比

eg：confidence(A->B) = support_count(A并B) / support_count(A)

相关性分析 

辛普森悖论