判定表是分析和表达多种输入条件下系统执行不同动作的工具。将复杂的逻辑关系和多种条件组合的情况表达的清晰明了。判定表通常由四个部分组成：

　　1.条件桩：列出系统的所有输入；

　　2.动作桩：列出系统可能采取的操作；

　　3.条件项：列出针对对应条件桩的的取值（即在所有可能情况下的取值）；

　　4.动作项：列出针对对应动作桩的取值情况下应该采取的动作。

　　动作项和条件项放一起看，指出了在条件项的各种取值情况下应该采取的动作，在判定表中贯穿条件项和动作项的一列就是一条规则，可以针对每个合法输入组合的规则设计用例进行测试。

　　判定表可以简化，简化是以合并相似规则为目标的。若表中有两条或多条规则具有相同的动作，且其条件项之间存在极为相似的关系，就可以将其合并。但是，合并也存在漏测的风险，即程序对于某个条件有不同的分支，而我们却错误的将其合并，导致某条或某些路径没有被测试覆盖，造成漏测（条件类似且动作相同的路径，在程序内部可能有不同的分支，简化会丧失对某些程序分支的覆盖）。

　　判定表法主要针对功能需求中的处理过程，处理过程越复杂，越有必要使用判定表法。

　　例子：

　　一、需求：吃饭的抉择

　　1吃自助，点了一份鱼香肉丝饭，并且没有吃饱；然后，买个黄桥烧饼。

　　2吃自助，点了一份鱼香肉丝饭，并且吃得很饱；然后又点了一份回去做宵夜。

　　3吃自助，点了一份意大利面，并且没有吃饱；然后，买个老婆饼回去吃。

　　4吃自助，点了一份意大利面，并且吃得很饱；然后，回家睡觉。

　　5吃快餐，点了一份鱼香肉丝饭，并且没有吃饱；然后，回家睡觉。

　　6吃快餐，点了一份鱼香肉丝饭，并且吃得很饱；然后，买个黄桥烧饼。

　　7吃快餐，点了一份意大利面，并且没有吃饱；然后，买个汉堡。

　　8吃快餐，点了一份意大利面，并且吃得很饱；然后，买个老婆饼。

　　二、分析

　　1、测试需求分析

　　条件：中餐还是西餐、鱼香肉丝饭还是意大利面、吃饱还是没饱。

　　结果：买黄桥烧饼、又点一份回去宵夜、买老婆饼、回家睡觉、买个汉堡。

　　2、用例设计方法分析（判定表组合分析）

　　1)列出条件和结果；

　　2）计算条件组合的数量；

　　3）组合条件；

　　4）根据每种组合得出结果。

　　详细如图1所示。由于只有八条路径，比较简单，所以并未考虑合并判定表。合并判定表的原则：结果（动作项）相同，条件相似（次要条件有一个不同）。但是被合并的条件，可能执行的路径不同，但结果相同。即有程序分支被漏测的风险（可以与流程图法结合考虑，预防漏测）。

　　图1

　　3、用例设计（输入部分）

　　略

　　三、用例详细

　　用例编号：T-01

　　用例标题：吃饭的抉择

　　步骤名称：

　　1.自助+鱼香肉丝饭+吃饱；

　　2.自助+鱼香肉丝饭+没饱；

　　3.其他处理路径组合如上描述。

　　步骤描述：

　　1.根据系统具体而定；

　　2.略（若只是自己写用例自己执行，可以写的略些。）

　　预期结果：

　　1.略

　　总结：

　　判定表法主要针对功能需求中的处理过程，处理过程越是复杂，就越有必要使用判定表法。判定表法充分考虑了输入条件间的组合，对组合情况覆盖充分，且可得出每个组合的预期输出。其实，做测试需求分析的目的也就是得出完整的测试用例。重测试需求分析，轻测试执行过程。

　　判定表法不足：当被测试特性输入较多时，会造成判定表的规模很庞大。当输入条件间的约束条件不能有效区分输入是否需要进行组合测试时，有可能产生冗余。需手工剔除冗余用例。

版权声明：本文出自 guo_gf 的51Testing软件测试博客：http://www.51testing.com/?539729

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。