黑盒测试用例设计模式-判定表(上)

黑盒测试用例设计模式-判定表(上)

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

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

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.略（自己写用例自己执行，可略写。）

预期结果：

         略

总结：

        判定表法主要针对功能需求中的处理过程，处理过程越是复杂，就越有必要使用判定表法。判定表法充分考虑了输入条件间的

组合，对组合情况覆盖充分，且可得出每个组合的预期输出。其实，做测试需求分析的目的也就是得出完整的测试用例集。

        判定表法不足：当被测试特性输入较多时，会造成判定表的规模很庞大。当输入条件间的约束条件不能有效区分输入是否需要

进行组合测试时，有可能产生冗余。需手工剔除冗余用例。

注：

        用例设计要考虑三个层次的问题：策略、模式、方法。黑盒测试就是一种策略，判定表即是一种模式，也是一种方法。

怎样才叫精通测试用例设计？  实践是检验真理的唯一标准。理论也是来源于实践的，特别是在工程领域。懂得理论而没有实践的，其实还是不懂嘛。反而不如

有一定实践经验的人更接近真理。有大量实践经验，而又善于总结的，才可能成为专家。