测试用例设计—判定表
判定表(Decision table)是另一种表达逻辑判断的工具。与结构化语言和判断树相比，判断表的优点是能把所有条件组合充分地表达出来；其缺点是判定表的建立过程较烦杂，且表达方式不如前两种简便。判定表在用于知识表达中，有许多其他方式所达不到的作用。定义
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
组成部分
判定表通常有以下四个部分组成：
1) 条件桩（Condition Stub）：在左上部，列出了问题的所有条件。通常认为列出的条件的次序无关紧要。
2) 动作桩（Action Stub）：在左下部，列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3) 条件项（Condition Entry）：在右上部，列出针对它左列条件的取值。在所有可能情况下的真假值。
4) 动作项（Action Entry）：在右下部，列出在条件项的各种取值情况下应该采取的动作。
判定表的建立
判定表的建立步骤：
1) 确定规则的个数。
假如有n个条件。每个条件有两个取值（0,1）,故有2的n次方种规则。
2) 列出所有的条件桩和动作桩。
3) 填入条件项。
4) 填入动作项。得到初始判定表。
5) 简化.合并相似规则（相同动作）。
合并判定表是牺牲测试充分性，混乱业务逻辑为代价。8条以内不建议合并。
6) 抽取测试用例。
简化判定表后，可抽取其每一条规则作为测试用例，判定表得到的是测试规则，不是最终的测试用例。规则不能验证功能点的正确性，仅验证业务规则的正确性。
判定表的优点：
能够将复杂的问题按照各种可能的情况全部列举出来，充分考虑了输入域之间的组合情况，每条规则覆盖了多条输入条件，考虑输入的约束关系，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。
判定表的缺点：
当输入项过多时，规则数以2的n次方剧增，判定表会非常庞大，采用判定表合并时会造成逻辑缺失，业务混乱错误的情况。
判定表本质上就是做一个全组合
页:
[1]
