黑盒测试的测试用例设计方法(2)

　　3) 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。

　　4) 把因果图转换为判定表。

　　5) 把判定表的每一列拿出来作为依据，设计测试用例。

　　从因果图生成的测试用例(局部，组合关系下的)包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加。

　　六、判定表驱动分析方法

　　前面因果图方法中已经用到了判定表。判定表(Decision Table)是分析和表达多逻辑条件下执行不同操作的情况下的工具。在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了。由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。

　　判定表通常由四个部分组成。

　　条件桩(Condition Stub)：列出了问题得所有条件。通常认为列出得条件的次序无关紧要。

　　动作桩(Action Stub)：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

　　条件项(Condition Entry)：列出针对它左列条件的取值。在所有可能情况下的真假值。

　　动作项(Action Entry)：列出在条件项的各种取值情况下应该采取的动作。

　　规则：任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。

　　判定表的建立步骤(根据软件规格说明)：

　　1) 确定规则的个数。假如有n个条件，每个条件有两个取值(0，1)，故有n2种规则。

　　2) 列出所有的条件桩和动作桩。

　　3) 填入条件项。

　　4) 填入动作项。等到初始判定表。

　　5) 简化。合并相似规则(相同动作)。

　　Beizer 指出了适合使用判定表设计测试用例的条件：

　　1) 规格说明以判定表形式给出，或很容易转换成判定表。

　　2) 条件的排列顺序不会也不影响执行哪些操作。

　　3) 规则的排列顺序不会也不影响执行哪些操作。

　　4) 每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

　　5) 如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。

原文转自：http://www.ltesting.net