黑盒测试用例设计方法&理论结合实际 -> 判定表驱动法

一. 概念

　　判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

---

二. 判定表驱动法的应用

1. 判定表的优点：

   a. 能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。

   b. 在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题

2. 阅读指南”判定表:
   

   		1	2	3	4	5	6	7	8
   问题	觉得疲倦？	Y	Y	Y	Y	N	N	N	N
   	感兴趣吗？	Y	Y	N	N	Y	Y	N	N
   	糊涂吗？	Y	N	Y	N	Y	N	Y	N
   建议	重读					√
   	继续						√
   	跳下一章							√	√
   	休息	√	√	√	√

3. 判定表通常由四个部分组成如下图所示:
   

   1)    条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。

   2)    动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

   3)    条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。

   4)    动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作

4. 规则及规则合并:

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

   2)　　化简：就是规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系

5. 规则及规则合并举例:

   1). 如下图左端，两规则动作项一样，条件项类似，在1、2条件项分别取Y、N时，无论条件3取何值，都执行同一操作。即要执行的动作与条件3无关。于是可合并。“－”表示与取值无关:

   

   2). 与上类似，下图中，无关条件项“－”可包含其他条件项取值，具有相同动作的规则可合并:
   

   3). 化简后的读书指南判定表:

   		1	2	3	4
   问题	你觉得疲倦吗？	-	-	Y	N
   	你对内容感兴趣吗？	Y	Y	N	N
   	书中内容使你胡涂吗？	Y	N	-	-
   建议	请回到本章开头重读	x
   	继续读下去		X
   	跳到下一章去读				x
   	停止阅读，请休息			x

6. 判定表的建立步骤：（根据软件规格说明)

   1)    确定规则的个数.假如有n个条件。每个条件有两个取值（0,1）,故有2n种规则。

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

   3)    填入条件项。

   4)    填入动作项。等到初始判定表。

   5)    简化.合并相似规则（相同动作）

---

三. 实例

1. 1. 问题要求：”……对功率大于50马力的机器、维修记录不全或已运行10年以上的机器，应给予优先的维修处理……”
      这里假定，“维修记录不全”和“优先维修处理”均已在别处有更严格的定义 。请建立判定表

      解答：

      1)    确定规则的个数：这里有3个条件，每个条件有两个取值，故应有2*2*2=8种规则。

      2)　　列出所有的条件茬和动作桩

      

      3)    填入条件项。可从最后1行条件项开始，逐行向上填满。如第三行是： Y N Y N Y N Y N，第二行是： Y Y N N Y Y N N等等。

      4)　 填入动作桩和动作顶。这样便得到形如图的初始判定表

      		1	2	3	4	5	6	7	8
      条件	功率大于50马力吗？	N	Y	Y	Y	N	N	N	N
      	维修记录不全吗？	Y	Y	N	N	Y	Y	N	N
      	运行超过10年吗？	Y	N	Y	N	Y	N	Y	N
      动作	进行优先处理	x	x	X		X		X
      	作其他处理				X		x		x

      5)    化简，合并相似规则后得到图:

      		1	2	3	4	5
      条件	功率大于50马力吗？	Y	Y	Y	N	N
      	维修记录不全吗？	Y	N	N	-	-
      	运行超过10年吗？	-	Y	N	Y	N
      动作	进行优先处理	x	x		X
      	作其他处理			x		x

2. NextData函数的精简决策表

   M1＝{月份， 每月有30天}

   M2＝{月份， 每月有31天}

   M3＝{月份， 2月}                 有29＝512条规则

   D1＝{日期，1～28}                 12月末31日和其它31

   D2＝{日期，29}                    日月份的31日处理不同

   D3＝{日期，30}                    平年2月28日处理不同

   D4＝{日期，31}                    于2月27日

   Y1 ＝{年：年是闰年}

   Y2 ＝{年：年不是闰年}

   改进为：

   M1＝{月份： 每月有30天}

   M2＝{月份： 每月有31天， 12月除外}

   M4＝{月份：12月}

   M3＝{月份： 2月}

   D1＝{日期：1<=日期<=27}

   D2＝{日期：28}

   D3＝{日期：29}

   D4＝{日期：30}

   D5＝{日期：31}

   Y1 ＝{年：年是闰年}

   Y2 ＝{年：年不是闰年}

   输入变量间存在大量逻辑关系的NextData决策表

   

3. 用决策表测试法测试以下程序：该程序有三个输入变量month、day、year（month、day和year均为整数值，并且满足：1≤month≤12和1≤day≤31），分别作为输入日期的月份、日、年份，通过程序可以输出该输入日期在日历上隔一天的日期
   例如，输入为2004年11月29日，则该程序的输出为2000年12月1日

   1)    分析各种输入情况，列出为输入变量month、day、year划分的有效等价类。

   2)    分析程序规格说明，结合以上等价类划分的情况给出问题规定的可能采取的操作（即列出所有的动作桩）。

   3)　　根据（1）和（2），画出简化后的决策表
   案例分析如下:

   • month变量的有效等价类：

   　　M1: {month=4,6,9,11}            M2: {month=1,3,5,7,8,10}

   　　M3: {month=12              }M4: {month=2}

   • day变量的有效等价类：

   　　D1:{1≤day≤26}        D2: {day=27}        D3: {day=28}               D4: {day=29}                    D5: {day=30}           D6: {day=31}

   • year变量的有效等价类：

   　　Y1: {year是闰年}              Y2:  {year不是闰年}

   4)    考虑各种有效的输入情况，程序中可能采取的操作有以下六种：

   　　a1: day+2                 a2: day=2             a3: day=1

   　　a4: month+1                   a5: month=1        a6: year+1

4. 判定表在功能测试中的应用:
   1)　　一些软件的功能需求可用判定表表达得非常清楚，在检验程序的功能时判定表也就成为一个不错的工具。如果一个软件的规格说明指出:
   • 当条件1和条件2满足，并且条件3和条件4不满足，或者当条件1、3和条件4满足时，要执行操作1。
   • 在任一个条件都不满足时，要执行操作2。
   • 在条件1不满足，而条件4被满足时，要执行操作3。 根据规格说明得到如下判定表：
     

     这里，判定表只给出了16种规则中的8种。事实上，除这8条以外的一些规则是指当不能满足指定的条件，执行3种操作时，要执行1个默许的操作。在没必要时，判定表通常可略去这些规则。但如果用判定表来设计测试用例，就必须列出这些默许规则（如下表）

     规则5	规则6	规则7	规则8
     条件1	-	N	Y	Y
     条件2	-	Y	Y	N
     条件3	Y	N	N	N
     条件4	N	N	Y	-
     默许操作	x	x	x	x

   2) 判定表的优点和缺点

   • 优点：它能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。
   • 缺点：不能表达重复执行的动作，例如循环结构

   缺点：不能表达重复执行的动作，例如循环结构

   3）Beizer 指出了适合使用判定表设计测试用例的条件

   Ø 规格说明以判定表形式给出,或很容易转换成判定表。

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

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

   Ø 每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则
   Ø 如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要

   Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表，同样可以借以设计测试用例，只不过尚需增加其它的测试用例罢了