黑盒测试用例设计方法-判定表

判定表测试用例设计

判定表理论

判定表是分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。判定表通常由四部分组成：
（1）条件桩：列出系统所有输入，列出的输入次序没有影响
（2）动作桩：列出系统可能采取的操作，这些操作的排列顺序没有约束
（3）条件项：列出针对它输入条件的取值，在所有可能情况下的真假值
（4）动作项：列出在输入项的各种取值情况下应该采取的动作
动作项和条件项指出了在条件项的各种取值情况下应该采取的动作，在判定表中贯穿条件项和动作项的一列就是一条规则，可以针对每个合法输入组合的规则设计测试用例进行测试

判定表设计过程

判定表测试用例的设计步骤如下：
（1）确定规则的个数
根据输入的条件数据计算出规则的个数，如果有N个条件，那么规则一共有2^N个，如N为3，规则数就为8个**（这里的公式很多同学理解有误，这里的2其实是因为我们输入条件只有0或1的真假值，如果我们输入的条件有多种，比如5种，那么这个2就要变成5了）**
（2）列出所有的条件桩和动作桩
条件桩是影响结果的条件（输入的所有条件），动作桩是由于所有条件组合后可能产生的结果（系统对应所有的结果）
（3）填入条件项和动作项
对各条件项进行标识，一般使用1和0标识，当该条件选中时使用1，不选中使用0.需要将条件项中所有条件组合的情况标识出来，根据条件的情况来确定动作项，对动作项进行标识
（4）简化、合并相似规则
简化判定表是将相似规则进行合并，减少测试用例，当然它是以牺牲测试用例充分性为代价的。
例如只有一个输入不同时，输出是一样的，说明输入对输出没有影响，因此将这两列合并为一列，简化合并规则如图：
只有一个输入条件不同，不影响结果

条件桩	条件项	条件项
1	Y	Y
2	N	N
3	Y	N

动作桩	动作项	动作项
1	X	X

合并后：

条件桩	条件项
1	Y
2	N
3	——

动作桩	动作项
1	X

（5）将最后得出的判定表每条规则转化为测试用例
举例：一个收费站功能的要求：根据车牌颜色和是否有ETC进行是否收费的判断；收费的车牌颜色为蓝色和黄色和绿色和黄绿双拼；白色和黑色或其它颜色不收费；
根据以上描述得出输入的条件为两个：车牌颜色和是否安装ETC；
输出的条件（动作桩）有1个：如何收费：原价收费和打折收费和不收费；
第一步：确定规则个数
因为输入条件有两个，每个条件输入都是只有是跟否，那么规则数就是2^2=4；（这里其实已经进行了简化判定表，车牌颜色的输入其实有很多，但是对于是否影响收费结果只要判断是否为收费车牌，所以输入车牌的条件项简化为两种，下面条件桩列出）
第二步：列出所有条件桩和动作桩
得出条件桩1：是否收费车牌：0不收费，1收费
条件桩2：是否安装ETC：0没安装，1安装
得出动作桩有1个：0免费，1原价收费，2打折收费
第三步：填入条件项和动作项
如下表

序号		1	2	3	4
条件	1	0	0	1	1
条件	2	0	1	0	1
动作	1	0	0	1	2

第四步：简化、合并相似规则
从上面可以发现，只要车牌颜色是免费的，是否安装ETC不影响最后是否收费，所以合并之后的判定表如下表：

序号		1	2	3
条件	1	0	1	1
条件	2	——	0	1
动作	1	0	1	2

第五步：将每条规则转化为测试用例
1：输入免费车牌颜色，检查是否收费
2：输入收费车牌，并没有安装ETC，检查是否原价收费
3：输入收费车牌，并安装ETC，检查是否打折收费

判定表的优缺点

使用判定表设计测试用例存在如下优点：
（1）充分考虑了输入条件间的组合，避免遗漏
（2）设计过程种对输入条件间的约束关系进行分析，避免无效用例的出现，提高测试用例的有效性
（3）设计时同时输出每个测试项目的预期结果
使用判定表设计测试用例存在如下缺点：
（1）当被测特性输入较多时，判定表会非常庞大
（2）输入条件之间的约束不能有效区分当前的组合是否合理，会导致产生一些不需要的组合条件
（3）规则合并过程种存在可能漏测的风险，虽然某个输入条件在输出接口上是无关的，但是在软件设计上，内部针对这个条件采取了不同的程序分支（最常见的有PC端商城与APP端的商城，看着逻辑是一样的，但是内部采取了不同的分支处理）

通过判定表发现过的BUG

在一次测试订单生成规则时候，需要根据会员等级，和选择是否自提去收取对应的运费（等级越高下单选择快递配送返回的运费越多），还有一个条件是会员是否购买了运费卡，购买了就免运费。测试过程中使用了判定表设计用例，在测试过程中因为每一个会员等级都会有一条用例，发现开发遗漏了根据等级去返还运费

个人心得

判定表十分适合输入条件有多个，输出结果有多个的需求使用，设计过程中有个要点（对于数学逻辑掌握不好的同学，可以按照步骤一步步设计，对于逻辑掌握好的同学，可以一步到位生成简化后的判定表），虽然判定表十分强大，但是我们的BUG往往在用例之外，比如上述的收费站收费举例，虽然最后简化成了3条用例，但是往往BUG的发现会在（输入免费车牌，同时输入安装了ETC这个用例以外的场景）因为我们的开发可能写的代码是先判断是否安装了ETC，然后安装了就直接算折扣，跳过了车牌校验。那么如何测试到这种情况，由于我们的用例简化后很少，所以测试过程中我们可以进行探索性测试，即思考开发是如何实现该功能的，是否用例上还有遗漏的可能性，进行补充测试。那对于用例多的时候，测试时间被压缩又如何处理？那就要根据用例的优先级，牺牲一定的测试质量，优先保证功能达到上线标准去进行测试了