阿里软件测试工程师推荐|测试用例设计方法——判定表法
判定表(Decision table)是另一种表达逻辑判断的工具。与结构化语言和判断树相比,判断表的优点是能把所有条件组合充分地表达出来;其缺点是判定表的建立过程较繁杂,且表达方式不如前两种简便。判定表在用于知识表达中,有许多其他方式所达不到的作用
判定表法定义
判定表是分析和表达逻辑条件下执行不同操作的情况的工具。
判定表的4个组成部分
判定表通常有以下四个部分组成:
1)条件桩(Condition Stub):在左上部,列出了问题的所有条件。通常认为列出的条件的次序无关紧要。
2)动作桩(Action Stub):在左下部,列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3)条件项(Condition Entry):在右上部,列出针对它左列条件的取值。在所有可能情况下的真假值。
4)动作项(Action Entry):在右下部,列出在条件项的各种取值情况下应该采取的动作。
判定表法设计测试用例步骤以及案例讲解
判定表的建立步骤:
1)确定规则的个数.假如有n个条件。每个条件有两个取值(0,1),故有2的n次方种规则。
2)列出所有的条件桩和动作桩。
3)填入条件项。
4)填入动作项。得到初始判定表。
5)简化、合并相似规则(相同动作)。
案例:
判定表也称我决策表,能表示输入条件的组合,以及与每一输入组合对应的动作组合。与因果图法相似判定表法主要侧重输入条件之间的逻辑关系。
1.判定表主要包含以下五部分:
条件桩:列出所有可能的条件
条件项:列出所有的条件取值组合
动作桩:列出所有可能的操作
条件项:列出在每一种条件取值组合的情况下,执行动作桩中的哪些动作。
规则:一种条件取值组合与其对应的动作组合(即判定表中贯穿条件项和动作项的一列)构成判定表的一个规则。条件组合的数目就是规则的数目。
2.建立判定表可遵循的步骤
1)列出条件桩和动作桩
2)确定规则的个数,用来为规则编号。
若有n个原因,且每个原因的可取值为0或者1,那么将会有2n个规则。
3)完成所有条件项的填写。
4)完成所有的动作项的填写。(得到初始判定表)
5)合并相似规则,用以对初始判断表进行简化。
有两个或者多条规则具有相同的动作,并且条件项之间存在极为相似的关系就可以进行合并。
3.实例
问题描述: “……对于功率大于50马力的机器,并且维修记录不全或已运行10年以上的机器,应给予优先的维修处理……”
条件桩:
C1:功率大于50马力吗?
C2:维修记录不全吗?
C3:运行超过10年吗?
动作桩:
A1:进行优先处理
A2:作其他处理
生成判断表:
简化判定表:
1,2合并,5,7合并,6,8合并
判定表是分析和表达多种输入条件下系统执行不同动作的工具,它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确
判定表法设计用例的步骤
• 确定规则的个数。如这里有3个条件,每个条件有两个取值,故应有2*2*2=8种规则
• 列出所有的条件桩和动作桩
• 填入条件项
• 填入动作桩和动作顶
• 化简,合并相似规则
• 将每条规则转化为用例
判定表的合并
化简工作是以合并相似规则为目标的。如果表中有两条或多条规则具有相同的动作,并且其条件项之间存在极为相似的关系,我们便可以将其合并
判定表的优缺点
• 优点:它能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏
• 缺点:合并存在漏测的风险。一个显然易见的原因是,虽然某个输入条件在输出接口上是无关的,但是在软件设计上,内部针对这个条件走了不同的程序分支
因果图是一种挑选高效测试用例以检查组合输入条件的系统方法,因果图法是基于这样的一种思想:一些程序的功能可以用判定表(或称决策表)的形式来表示,并根据输入条件的组合情况规定相应的操作。
因果图法的定义
�是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。
采用因果图法设计测试用例的步骤:
(1)根据程序规格说明书描述,分析并确定因(输入条件)和果(输出结果或程序状态的改变),画出因果图。
(2)将得到的因果图转换为判定表。
(3)为判定表中每一列所表示的情况设计一个测试用例。
使用因果图法的优点:
(1)考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系。
(2)能够帮助测试人员按照一定的步骤,高效率的开发测试用例。
(3)因果图法是将自然语言规格说明转化成形式语言规格说明的一种严格的方法,可以指出规格说明存在的不完整性和二义性。
判定表(DT-Decision Table)是分析和表达多逻辑条件下执行不同操作的情况的工具。
1)条件桩(Condition Stub):列出问题得所有条件。通常认为列出的条件次序无关紧要。
2)动作桩(Action Stub):列出问题规定可能采取的操作。这些操作的排列顺序没有约束。
3)条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。
4)动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。
5)规则(Rules):任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。判定表中列出多少组条件取值,也就有多少条规则。
1)列出条件桩和动作桩
2)确定规则的个数,用来为规则编号:若有n个原因,且每个原因的可取值为0或者1,那么将会有2 n 个规则。
3)完成所有条件项的填写。
4)完成所有的动作项的填写:得到初始判定表
5)合并化简:有两个或者多条规则具有相同的动作,并且条件项之间存在极为相似的关系就可以进行合并。
问题描述: “对于功率大于50马力的机器且维修记录不全,或者已运行10年以上的机器,应给予优先的维修处理”
条件桩:
C1:功率大于50马力吗?
C2:维修记录不全吗?
C3:运行超过10年吗?
动作桩:
A1:进行优先处理
A2:作其他处理
生成判断表:条件3个->规则2³个
简化判定表:
1,2合并,5,7合并,6,8合并
得到的测试用例:
1)功率大于50马力且维修记录不全,无论运行是否超过10年:优先处理
2)功率大于50马力但维修记录齐全,运行超过10年:优先处理
3)功率大于50马力但维修记录齐全,运行未超过10年:其他处理
4)功率不大于50马力,无论维修记录是否齐全,只要运行超过10年:优先处理
5)功率不大于50马力,无论维修记录是否齐全,只要运行未超过10年:其他处理
I. 优点:它能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题。
II. 缺点:不能表达重复执行的动作,例如循环结构。合并存在漏测的风险。一个显然易见的原因是,虽然某个输入条件在输出接口上是无关的,但是在软件设计上,内部针对这个条件走了不同的程序分支(因分析内部业务流程而定);输入和输出的逻辑关系,明确的用判定表,不是很明了的用因果图然后使用判定表。
①规格说明以判定表形式给出,或很容易转换成判定表。
②条件的排列顺序不会也不影响执行哪些操作。
③规则的排列顺序不会也不影响执行哪些操作。
④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。
⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。
这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表,同样可以借以设计测试用例,只不过尚需增加其它的测试用例罢了。
1、因果图是一种辅助工具,它适用于检查程序输入条件的各种组合情况步骤。通过分析软件规格说明描述中的因果关系(输入与输出的因果关系) 找出原因与结果、原因与原因之间的对应关系;
2、在因果图上标记约束或限制条件,把因果图转化为判定表,将判定表中的每一列拿出来设计测试用例。
3、画因果图非常麻烦,影响测试效率,可以直接写判定表,进而编写测试用例。
什么叫判定表法?
就是指把所有的输入条件、所有可能采取的动作按表格列出来,每一种条件和动作的组合构成一条规则,也即一条用例。
判定表法当中有几个概念,条件桩,动作桩,条件项,动作项。先分别介绍一下,
条件桩:列出所有的输入条件,顺序不重要
动作桩:列出问题规定的所有可能采取的动作,顺序不重要
条件项:列出各个条件所有可能的取值
动作项:列出所有可能采取的动作
这里条件桩和动作桩组成表格的行,条件项和动作项组成表格的列,这样组合成的表格即是依据判定表法得出的一张原始用例集合。
不过到此为此并没有结束
条件和动作之间可能存在直接或间接的约束关系
1、利用约束关系剔除部分用例
比如条件和动作的某些组合是互斥的、不合法或不可能发生的,所以需要将这些组合从原始用例集合中剔除。
2、利用约束关系合并部分用例
比如说当匹配某个条件时,不管其他条件是否匹配,可能采取的动作都是一致的,此时就可以合并其他条件跟这个匹配条件的组合,保留一条。
优点:
1、从最完整的用例集合,到最后的用例集,保证是最少且有效的。
2、适合输入条件和动作组合不是很多的情况。
缺点:
如果输入条件和动作组合特别庞大时,判定表法实施起来难度比较大,几乎无法使用。
个人觉得,判定表法的几个概念也较难理解,其实判定表法很简单,就是把所有输入项的可能值和可能输入的动作做个完全遍历的组合集,然后把组合集中不合法的、冗余的组合项给剔除,最后得到的就是有效且最少的测试用例组合。