1)定义:
判定表也称决策表,是分析和表达逻辑条件下执行不同操作的情况下的工具。它能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏,设计出完成的测试用例集合。
2)组成:
1) 条件桩(Condition Stub):列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2) 动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3) 条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。
4) 动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。
3)合并规则:
1) 规则:任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。
2) 化简:就是规则合并有两条或多条规则具有相同的动作,并且其条件项之间存在着极为相似的关系。
4)判定表的建立步骤:
1) 确定规则的个数。假如有n个条件,每个条件有两个取值(0,1),故2的n次方种规则。
2) 列出所有的条件桩和动作桩
3) 填入条件项的取值
4) 填入动作项的取值,得到初始判定表
5) 简化,合并相似规则(相同动作)
例子:打印机是否能打印出来正确的内容,有多个因素影响,包括驱动程序、纸张、墨粉等。(为了简化问题,不考虑中途断电、卡纸等因素的影响)
1)列出条件桩和动作桩
条件桩:
(1) 驱动程序是否正确?
(2) 是否有纸张?
(3) 是否有墨粉?
动作桩:(动作桩有两种:打印内容和不同的错误提示,并且假定:优先警告缺纸,然后警告没有墨粉,最后警告驱动程序不对。)
(1) 打印内容
(2) 提示驱动程序不对
(3) 提示没有纸张
(4) 提示没有墨粉
2)生成初始化的判定表
注:
输入条件项,即上述每个条件的值分别取“是(Y)”和“否(N)”,可以简化表示为1和0。
3)优化的判定表
注:
如果动作结果一样,对于某些因素取“1”或“0”没有影响,即以“—”表示,并合并。
优化的判定表就可以设计测试用例,每一列代表一条测试用例。
判定表的优/缺点:
优点:把复杂的问题按各种可能的情况一一列举,简明而易于理解,也避免遗漏。
缺点:不能表达重复执行的动作,如循环结构。判定表不能很好的伸缩。如有n个条件的判定表有2的n次方个规则。
这里引用测试模板添加需要具体什么条件为例子。
Ø 用例的审核与不审核:
Ø 模板的发布与不发布:
Ø 在模板列表中显示的已发布的测试模板:
Ø 已经审核的用例,并且模板已经发布了,才能显示:
添加的用例模板,还需要在用例列表中,审核对应模块下的用例,发布测试用例模板后,才能在测试模板中添加数据,如果用例没有审核,那么就会有如下的提示:
添加的测试模板,如果产品型号不存在或是研发审批未完成则不能添加成功,如下图所示:
测试用例模板,不仅需要审核对应模块下的用例,还需发布该测试用例模板,才能在测试模板中添加数据。
添加数据时,产品型号是要存在的,并且还需研发审批通过,这里先不考虑用户和客户输入的条件,只考虑产品型号的存在问题,不考虑审批的情况。
1)列出条件桩和动作桩
条件桩:
(1) 测试模板是否审核?
(2) 测试用例模板是否发布?
(3) 产品型号是否存在?
动作桩:(因为提示未审核用例,需要发布才能知道该提示)
(1) 提示用例未审核
(2) 显示测试用例模板
(3) 提示产品型号不存在
(4) 成功添加测试模板
2)生成初始化的判定表
因为是3个条件桩,所以共有2*2*2=8条规则
分析:
1.先确定动作(4)的情况,是1时,所有的条件都需要满足,都是1的时候,其余情况都是0
2.确定条件(2)是1时,动作(2)必须是1----(1.2.5.6),否则都取0--(3.4.7.8)
3.根据业务需求,只要条件(2)不发布,即是0的时候,那么动作(1)和(3)都是0------(3.4.7.8)
4.根据业务需求,只要条件(2)是1,那么条件(1)是1的时候,动作(1)是0
5根据业务需求,只要条件(2)是1,那么条件(3)是1的时候,动作(2)是0
3)优化的判定表
注意:
如果动作(结果)一样,对于某些因素取“1”或“0”没有影响,即以“—”表示,并合并。
把出现一样的结果化简,根据判定表,我们可以得到1、2、5、6都是单一的结果,所以不用化简;3、4、7、8的结果是一样的,可以化简。