北京市导游证培训班:软件测试(14)--黑盒测试案例设计技术--基于决策表的测试

决策表，也叫判定表。在所有的功能性测试方法中，基于决策表的测试方法被认为是最严格的，因为决策表具有逻辑严格性。人们使用两种密切关联的方法：因果图法和决策表格法。与决策表相比，这两种方法使用起来更麻烦，并且全冗余。

决策表是分析和表达多逻辑条件下执行不同操作的情况的工具。在程序设计发展的初期，决策表就已被用作编写程序的辅助工具了。它可以把复杂的逻辑关系和多种条件组合的情况表达得比较明确。

1、决策表的组成

决策表通常由4个部分组成，如下图：

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

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

●条件项(condition entry)：列出针对它所列条件的取值，在所有可能情况下的真假值。

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

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

2、决策表建立

决策表的建立应该根据软件规格说明，步骤如下：

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

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

③输入条件项。

④填入动作项。制定初始决策表。

⑤简化。合并相似规则或者相同动作。

Beizer(《Software Testing Techniques》的作者)指出了适合使用决策表设计测试用例的条件：

①规格说明以决策表的形式给出，或很容易转换成决策表。

②条件的排列顺序不影响执行哪些操作。

③规则的排列顺序不影响执行哪些操作。

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

⑤如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。

下面给出一个实际的决策表的例子：

上面已经讲过，决策表有四个部分：粗竖线的左侧是桩部分；右侧是项。横粗线的上面是条件项，下面是动作项。在上图的决策表中，如果C1、C2和C3都为真，则采取行动a1和a2。如果C1和C2都为真而C3为假，则采取行动a1和a3。在C1为真，C2为假的条件下，规则中的C3项叫做“不关心”项。不关心项有两种解释：条件无关或条件不适用。有时人们用“不适用(n/a)”表示后一种解释。

如果有二叉条件(真/假、是/否、0/1)，则决策表的条件部分是旋转了90°的(命题逻辑)真值表。这种结构能够保证我们考虑了所有可能的条件值组合。如果使用决策表标识测试用例，那么决策表的这种完备性能够保证一种完备的测试。所有条件都是二叉条件的决策表叫做有限项决策表。如果条件可以有多个值，则对应的决策表叫做扩展项决策表。

决策表被设计为说明性的(与命令性相反)，给出的条件没有特别的顺序，而且所选择的行动发生时也没有任何特定顺序。

表示方法

为了使用决策表标识测试用例，我们把条件解释为输入，把动作解释为输出。有时条件最终引用输入的等价类，动作引用被测试软件的主要功能处理部分。这时规则就解释为测试用例。由于决策表可以机械地强制为完备的，因此可以有测试用例的完整集合。

有多种产生决策表的方法对测试人员更有用。一种很有用的风格是增加动作，以显示什么时候规则在逻辑上不可能满足。

在下面给出的决策表中，给出了不关心项和不可能规则使用的例子。正如第一条规则所指示，如果整数a、b和c不构成三角形，则我们根本不关心可能的相等关系。在规则2、3和4中，如果两对整数相等，则根据传递性，第三对整数也一定相等，因此第一条规则的否定项使使这些规则不可能满足。

下表所示决策表给出了有关表示方法的另一种考虑：条件的选择可以大大地扩展决策表的规模。这里将原来的条件(C1：a、b、c构成三角形？)扩展为三角形特性的三个不等式的详细表示。如果有一个不等式不成立，则三个整数就不能构成三角形。我们还可以进一步扩展，因为不等式不成立有两种方式：一条边等于另外两条边的和，或严格大于另外两条边的和。

如果条件引用了等价类，则决策表会有一种典型的外观。下表所示的决策表来自NextDate问题(也是经典的测试问题：NextDate是一个有三个变量，即月、日、年的函数。函数返回输入日期后面的那个日期)：引用了可能的月份变量相互排斥的可能性。由于一个月份就是一个等价类，因此不可能有两项同时为真的规则。不关心项(－)的实际含义是“必须失败”。有些决策表使用者用F!表示这一点。

不关心条目的使用，对完整决策树的识别方式有微妙的影响。对于有限项决策表，如果有ｎ个条件，则必须有２的n次方条规则。如果不关心项实际地表明条件是不相关的，则可以按以下方法统计规则数。没有不关心项的规则统计为1条规则；规则中每出现一个不关心项，则该规则数乘一次2。下表所示决策表的规则条数统计。请注意，规则总数是64(正好是应该得到的规则条数)。

如果将这种简化算法应用于NextDate的有互斥条件的决策表，会得到如下所示的规则条数统计：

应该只有8条规则，所以显然有问题。为了找出问题所在，我们扩展所有三条规则，用可能的T或F代替“－”，如下图所示：

请注意，所有条目都是T的规则有三条：规则1.1、2.1和3.1；条目是T、T、F的规则有两条：规则1.2和2.2。类似地，规则1.3和3.2、2.3和3.3也是一样的。如果去掉这些重复，最后可得到七条规则，缺少的规则是所有条件都是假的规则。这种处理的结果如下表所示，表中还给出了不可能出现的规则。

这种识别(和开发)完备决策表的能力，使我们在解决冗余性和不一致性方面处于很有利的地位。下表给出的决策表是冗余的，因为有3个条件和9条规则。(规则9和规则4相同。)

请注意，规则9的动作项与规则1～4的动作项相同。只要冗余规则中的行为与决策表相应的部分相同，就不会有什么大问题。如果动作项不同，例如下表所示的情况，就会遇到很大的问题。

如果上表所示的决策表被用来处理事务，其中C1是真，C2和C3都是假，则规则4和规则9都适用。我们可以观察到两点：

①规则4和规则9是不一致的。

②决策表是非确定的。

规则4和规则9是不一致的，因为行为集合是不同的。整个决策表是不确定的，因为不能确定是应用规则4还是应用规则9。测试人员的基本原则是在决策表中小心使用不关心动作项。

三角形问题的测试用例

使用上面修改的三角形问题决策表，可得到11个功能性测试用例：3个不可能测试用例，3个测试用例违反三角形性质，1个测试用例可得到等边三角形，1个测试用例可得到不等边三角形，3个测试用例可得到等腰三角形。如果扩展决策表以显示两种违反三角形性质的方式，可以再选三个测试用例(一条边正好等于另外两条边的和)。做到这一点需要一定的判断，否则规则会呈指数级增长。在这种情况下，最终会再得到很多不关心项和不可能的规则。

NextDate函数测试用例

选择NextDate函数，是因为它可以说明输入定义域中的依赖性问题，这使得这个例子成为基于决策表测试的一个完美例子，因为决策表可以突出这种依赖关系。从前面对等价类测试的分析我们知道，等价类分析假设所有的变量都是独立的。如果变量确实是独立的，则使用类的笛卡尔积是有意义的。如果变量之间在输入定义域中存在逻辑依赖关系，则这些依赖关系在笛卡尔积中就会丢失(说抑制可能更确切)。决策表格式通过使用“不可能动作”概念表示条件的不可能组合，使我们能够强调这种依赖关系。下面将对NextDate函数的决策表描述做三次尝试。

第一次尝试

标识合适的条件和动作，假设首先从分析等价类集合开始。

M1 = {月份：每月有30天}； M2 = {月份：每月有31天}；M3 = {月份：此月是2月}

D1 = {日期：1≤日期≤28}；D2 = {日期：日期=29}；D3 = {日期=30}；D4 = {日期=31}

Y1 = {年：年是闰年}；Y2 = {年：年不是闰年}

如果我们希望突出不可能的组合，则可以建立具有以下条件和动作的有限项决策表。(请注意，年变量对应的等价类收缩为下表的一个条件。)

这个决策表会有256条规则，其中很多是不可能的。如果要显示为什么这些规则是不可能的，可将动作修改为：

a1：月份中的天数太多；a2：不能出现在非闰年中；a3：计算NextDate。

第二次尝试

如果我们将注意力集中到NextDate函数的闰年问题上，则可以修改已有的等价类集合。为了说明另一种决策表表示方法，这一次采用扩展项决策表开发，并更仔细地研究动作桩。在构建扩展项决策表时，必须保证等价类构成输入定义域的真划分。如果规则项之间存在“重叠”，则会存在冗余情况，使得多个规则都能够满足。这里，Y2是一组1812～2012之间的年份，并除以4，2000除外。

M1 = {月份：每月有30天}； M2 = {月份：每月有31天}；M3 = {月份：此月是2月}

D1 = {日期：1≤日期≤28}；D2 = {日期：日期=29}；D3 = {日期=30}；D4 = {日期=31}

Y1 = {年：年=2000}；Y2 = {年：年是闰年}；Y3 = {年：年是平年}

从某种意义上说，我们采用的是“灰盒”技术，因为更仔细地研究了NextDate函数。为了产生给定日期的NextDate，能够使用的操作只有五种：日期和月份的增1和复位，年的增1。(我们不允许通过复位年来回退时间。)

这些条件可以产生有对应等价类笛卡尔积的36个规则的决策表(自己可以分析一下)。结合不关心项，可得到下表所示的17条规则的决策表。仍然存在逻辑不可能的规则，但是这个表有助于我们标识测试用例的扩展输出。如果填满这个决策表的动作项，就会发现12月有一些麻烦的问题(规则8)。我们下面解决这些问题。

第三次尝试

通过引入等价类的第三个集合，可以澄清年末问题。这一次可以特别关注日和月，并重新使用第一次尝试的较简单的闰年或非闰年条件，因此2000年没有特别处理。(还可以做第四次尝试，采用第二次尝试的年等价类。)

M1 = {月份：每月有30天}； M2 = {月份：每月有31天，12月除外}；M3 = {月份：此月是12月}；M4 = {月份：此月是2月}

D1 = {日期：1≤日期≤27}；D2 = {日期：日期=28}；D3 = {日期=29}；D4 = {日期=30}；D5 = {日期=31}

Y1 = {年：年是闰年}；Y2 = {年：年不是闰年}

这个等价类的笛卡尔积包含40个元素。所产生的组合规则包含不关心项，如下表所示，可与第二次的36条规则比较。大的测试用例集合是否一定比小的测试用例集合好？这里我们有一个22条规则的决策表，得到的NextDate函数的描述比包含36条规则的决策表更清晰。前5条规则处理有30天的月份，请注意，这里不考虑闰年。接下来两组规则(规则6～10，规则11～15)处理有31天的月份，前5条规则处理12月之外的月份，后5条规则处理12月。不可能规则也在决策表中列出，尽管存在一些高效测试人员可能会有疑问的冗余。10条规则中的8条只是对日期增1。针对这个子功能是否真的需要8条单独的测试用例，可能不需要，但是请注意我们可以通过决策表得到的启发。最后7条规则关注的是2月和闰年。

上表所示的决策表是NextDate函数源代码的基础。这个例子从另一个方面说明测试如何能够很好地改进程序设计。所有决策表分析都应该在NextDate函数的详细设计期间完成。

我们可以使用决策表代数进一步化简这22个测试用例。如果决策表中两个规则的动作集合相同，则一定至少有一个条件能够把两条规则用不关心条目合并。这正体现出决策表等价于用于标识等价类的“相同处理”方针。在某种意义上，我们就是在标识规则的等价类。例如，规则1、2和3涉及有30天的月份日期类D1、D2和D3。类似地，有31天的月份的日期类D1、D2、D3和D4也可以合并，2月的D4和D5也可以合并。所得到的结果如下表所示：

相应的测试用例如下表所示：

总结

与其他测试技术一样，基于决策表的测试对于某些应用程序(例如NextDate函数)很有效，但是对另外一些应用程序就不值得费这么大的事。毫不奇怪，基于决策表所适用的情况都是要发生大量决策(例如三角形问题)，以及在输入变量之间存在重要的逻辑关系的情况(例如NextDate函数)。

①决策表技术适用于具有以下特征的应用程序：

●if-then-else逻辑很突出。

●输入变量之间存在逻辑关系。

●涉及输入变量子集的计算。

●输入与输出之间存在因果关系。

●很高的圈(McCabe)复杂度。(路径测试中会详细讲解)

②决策表不能很好地伸缩(有n个条件的有限项决策表有2的n次方条规则)。有多种方法可以解决这个问题---使用扩展项决策表、代数化简表，将大表“分解”为小表，查找条件项的重复模式。

③与其他技术一样，迭代会有所帮助。第一次标识的条件和动作可能不那么令人满意。把第一次得到的结果作为铺路石，逐渐改进，直到得到满意的决策表。