黑盒测试设计方法-判定表法回顾
判定表是分析和表达多种输入条件下系统执行不同动作的工具。将复杂的逻辑关系和多种条件组合的情况表达的清晰明了。判定表通常由四个部分组成：
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]
