软件测试(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个条件,则必须有2的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次方条规则)。有多种方法可以解决这个问题---使用扩展项决策表、代数化简表,将大表“分解”为小表,查找条件项的重复模式。
软件测试(14)--黑盒测试案例设计技术--基于决策表的测试 黑盒测试和白盒测试

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

  

爱华网本文地址 » http://www.413yy.cn/a/25101011/80851.html

更多阅读

如何通过软件测试妳的内存卡 内存卡测试软件

如何通过软件测试妳的内存卡——简介最近很多人说自己买的便宜的内存卡,用着用着就不能存东西了,或者甚至就不能再读了,也就是所谓的卡烧了,所以结合本人的经验特分享一下。本人以常见的4GB、8GB和16GB的内存卡为例为各位简单介绍一下。

从哪些角度进行手机软件测试? 苹果手机测角度软件

?对于当前背景下的手机软件测试来说,要做好手机软件测试,主要从以下几个角度进行测试:UI测试,功能模块测试,交叉事件测试,容量性测试,用户手册测试等。UI测试用户界面测试指测试用户界面的风格是否满足客户要求,文字是否正确,页

基于误码率的眼图测试 串口误码率测试

摘要:在实时示波器上测量高速数字信号的眼图时,常规的眼图测量方法很难测到10个比特的眼图,力科的ISOBER技术可在实时示波器上快速测量与分析很低误码率时的眼图轮廓,为高速串行信号设计提供了更好的分析与验证方法。本文为笔者于2009年

软件测试工程师薪资调查 软件测试工程师待遇

因修正错误而存在——软件测试工程师所属门派:IT业“假如存在没有任何错误的程序,那么世界也会不复存在。”因错误而存在,因修正错误而存在,这就是软件测试工程师的存在之道。虽然测试不是解决错误的根本举措,但却是必须的手段。软件测试

声明:《软件测试(14)--黑盒测试案例设计技术--基于决策表的测试 黑盒测试和白盒测试》为网友含笑自然分享!如侵犯到您的合法权益请联系我们删除