测试用例设计白皮书--判定表驱动分析方法

方法简介

定义

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

判定表的优点

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

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

“阅读指南”判定表

 

 

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

重读

 

 

 

 

    

 

 

继续

 

 

 

 

 

    

 

跳下一章

 

 

 

 

 

 

休息

    

 

 

 

 

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

如下图所示

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

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

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

4)动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。

规则及规则合并

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

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

规则及规则合并举例

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

 

判定表的建立步骤(根据软件规格说明)

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

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

3)填入条件项。

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

5)简化.合并相似规则(相同动作)。

实战演习

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

解答:

①确定规则的个数:这里有 3 个条件,每个条件有两个取值,故应有 2*2*2=8 种规则。

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

③填入条件项。可从最后 1 行条件项开始,逐行向上填满。如第三行是: Y N Y N Y N Y N,第二行是: Y Y N N Y Y N N 等等。

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

 

1

2

3

4

5

6

7

8

条件

功率大于 50 马力吗?

Y

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

初始判定表

⑤化简。合并相似规则后得到图。

 

 

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),画出简化后的决策表。

案例分析如下:

1) month 变量的有效等价类:

M1: {month=4,6,9,11}

M2: {month=1,3,5,7,8,10}

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

2)day 变量的有效等价类:

D1:{1≤day≤26}

D2: {day=27}

D3: {day=28}

D4: {day=29}

D5: {day=30}

D6: {day=31}

3)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. 当条件 1 和条件 2 满足,并且条件 3 和条件 4 不满足,或者当条件 1、3 和条件 4 满足时,要执行操作 1。
  2. 在任一个条件都不满足时,要执行操作 2。
  3. 在条件 1 不满足,而条件 4 被满足时,要执行操作 3。 根据规格说明得到如下判定表:

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

 

2)判定表的优点和缺点

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

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

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

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

③规则的排列顺序不会也不影响执行哪些操作。 ④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。

⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。

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

发表评论

电子邮件地址不会被公开。 必填项已用*标注