爱华网决策表是分析和表达多逻辑条件下执行不同操作的情况的工具。在程序设计发展的初期，决策表就已被用作编写程序的辅助工具了。它可以把复杂的逻辑关系和多种条件组合的情况表达得比较明确。
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次方条规则)。有多种方法可以解决这个问题---使用扩展项决策表、代数化简表，将大表“分解”为小表，查找条件项的重复模式。
③与其他技术一样，迭代会有所帮助。第一次标识的条件和动作可能不那么令人满意。把第一次得到的结果作为铺路石，逐渐改进，直到得到满意的决策表。
