听课笔记2:因果图与决策表
对于独立的输入数据,边界值法和等价类法简单有效,覆盖也很全面,但是对于有联系的输入来说上面两种方法明显不能很好的反映输入间的相互关系,或者说约束。
因果图
顾名思义,因果图是将说明书中提到的输入和结果直接表示成图像,直观的反映了程序所需的一个因果关系。
因果图需要将各种可能的输入和输出分别列出,用0或者1表示在一次操作中该条件是否存在,通过规定的符号来表示各种条件之间和条件与结果之间的对应关系。
因果图基本的符号有1)恒等2)非 3)或4)且;约束的表示有EIORM五种,分别表示exclusive, inclusive, only, require, mask.
通过因果图设计测试用例一般要经历5个步骤,分别是:
-
列出输入输出,即condition, effecting
-
根据说明画出因果图
-
画出决策表
-
化简决策表
-
设计测试用例
这就是通过因果图设计测试用例的方法。
自动售货机的例子
-
原因与结果
原因: c1,投入1元5角
c2,投入2元
c3,按可乐
c4,按雪碧
c5,按红茶
结果: e1,弹可乐
e3,弹雪碧
e3,弹红茶
e4,找5角
根据上面的决策表,可以看出,有10,11,13,18,19,21这六个有效测试用例,其他的测试用例都是无效的。可以看出,即使条件和结果并不是很复杂,也会有很多规则的出现。在不考虑约束的情况下,如果有n个原因就会有2^n中规则,即使考虑了约束,也不会减少很多。
在具体情况下,为了防止三个按钮被同时按下的情况,可以把这个功能做到硬件的设计上,比如给每种饮料编号,每次只能输入一个数字,这就解决刚才的问题,而且还利于饮料种类的扩展。
决策表
对于输入条件很多,约束关系也比较复杂的时候,话因果图比较困难,不如直接话决策表并化简。需要单独指出的是,决策表并不是因果图的辅助工具,相反,决策表是早就使用的设计黑盒测试用例的最为严格的工具。
决策表主要考虑4个部分:条件桩,条件项;动作桩,动作项。某某桩指的就是可能发生的项目,某某项是值具体在一次测试用例中可能出现的情况。
规则 选项 | 1 | 2 | 3 | …… | |
条件 | C1 | c11 | c12 | c12 | …… |
C2 | c21 | c22 | c23 | …… | |
C3 | c31 | c32 | c33 | …… | |
动作 | A1 | a11 | a12 | a13 | …… |
A2 | a21 | a21 | a31 | …… |
画决策表的关键是准确的分清各条件项。在简单的例子中,条件项一般用布尔值就可以表示,但是在在更多的时候,需要对输入项做合适的区分,比如在判断下一天的日期时,如果条件桩定为输入年份,输入月份,输入日期,那输入项就要做合适的区间划分,比如输入月份一处就能分为有30天的月份,有31天的月份(除12月),2月,12月(因为输入可能会是当年的最后一天)。
另外,在简化决策表的时候,一般是通过把动作项目相同的规则合并,于是会出现无关项。然后可以对化简后的规则做出对应的测试用例。如果按照决策表来实现功能的话,简化后的测试用例能够证明程序可用;但是如果实现功能时候没有按照决策表来实现的话,漏掉对与无关项的测试可能会造成问题。所以可以放心的使用决策表的时候,需要知道编写程序的思路,这点又不想是黑盒测试。
工作量
工作量主要体现在设计测试和实现测试用例两方面。
设计测试的工作量:边界值分析 < 等价类分析 < 决策表
实现测试用例的工作量(也是测试用例的数量):边界值分析 > 等价类分析 > 决策表
在实践中,需要对于实际情况进行平衡,达到两个方面的平衡。