测试用例设计方法
等价类划分
弱一般等价类
遵循单缺陷原则,要求用例覆盖每一个变量的一种取值即可,取值为有效值。
弱健壮等价类
在弱一般等价类的基础上,增加取值为无效值的情况。
对于有效输入,使用每个有效值类的一个值
对于无效输入,测试用例将拥有一个无效值,并保持其余的值是有效的。
强一般等价类
遵循多缺陷原则,要求用例覆盖每个变量的每种取值之间的迪卡尔乘积,即所有变量所有取值的所有组合,取值为有效值
覆盖所有的等价类
有可能的输入组合中的一个
强健壮等价类
在强一般等价类的基础上,增加取值为无效值的情况。
“健壮”考虑无效值,所有等价类都有考虑
“强”多缺陷假设
三角形
覆盖有效等价类的测试用例:
a b c 覆盖等价类号码
3 4 5 (1)--(7)
4 4 5 (1)--(7),(8)
4 5 5 (1)--(7),(9)
5 4 5 (1)--(7),(10)
4 4 4 (1)--(7),(11)
覆盖无效等价类的测试用例:
档案管理系统
,要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月,并规定日期由6位数字字符组成,前4位表示年,后2位表示月。现用等价类划分法设计测试用例,来测试程序的”日期检查功能”。
第一步
输入等价类 | 有效等价类 | 无效等价类 |
---|---|---|
日期的类型及长度 | ①6位数字字符 | ②有非数字字符 ③少于6位数字字符 ④多于6位数字字符 |
年份范围 | ⑤在1990~2049之间 | ⑥小于1990 ⑦大于2049 |
月份范围 | ⑧在01~12之间 | ⑨等于00 ⑩大于12 |
第二步
设计测试用例,以便覆盖所有的有效等价类在表中列出了3个有效等价类,编号分别为①、⑤、⑧,设计的测试用例如下:
测试数据 期望结果 覆盖的有效等价类
200211 输入有效 ①、⑤、⑧
第三步
为每一个无效等价类设计一个测试用例,设计结果如下:
测试数据 期望结果 覆盖的无效等价类
95June 无效输入 ②
20036 无效输入 ③
2001006 无效输入 ④
198912 无效输入 ⑥
205001 无效输入 ⑦
200100 无效输入 ⑨
200113 无效输入 ⑩
NextDate
函数包含三个变量:month、 day 和 year ,函数的输出为输入日期后一天的日期。 例如,输入为 2006年3月 7日,则函数的输出为 2006年3月8日。要求输入变量 month 、 day 和 year 均为整数值,并且满足下列条件:
①1≤month≤12
②1≤day≤31
③1920≤year≤2050
1)有效等价类为:
M1={月份:1≤月份≤12} D1={日期:1≤日期≤31} Y1={年:1812≤年≤2012}
2)若条件 ①~ ③中任何一个条件失效,则NextDate 函数都会产生一个输出,指明相应的变量超出取值范围,比如 “month 的值不在 1-12 范围当中 ” 。显然还存在着大量的 year 、 month 、 day 的无效组合, NextDate 函数将这些组合作统一的输出: ” 无效输入日期 ” 。
其无效等价类为:
M2={月份:月份<1} M3={月份:月份>12} D2={日期:日期<1} D3={日期:日期>31} Y2={年:年<1812} Y3={年:年>2012}
弱一般等价类测试用例
月份 日期 年 预期输出
6 15 1912 1912年6月16日
强一般等价类测试用例同弱一般等价类测试用例 注:弱–有单缺陷假设;健壮–考虑了无效值
(一)弱健壮等价类测试
用例ID 月份 日期 年 预期输出
WR1 6 15 1912 1912年6月16日
WR2 -1 15 1912 月份不在1~12中
WR3 13 15 1912 月份不在1~12中
WR4 6 -1 1912 日期不在1~31中
WR5 6 32 1912 日期不在1~31中
WR6 6 15 1811 年份不在1812~2012中
WR7 6 15 2013 年份不在1812~2012中
(二)强健壮等价类测试
用例ID 月份 日期 年 预期输出
SR1 -1 15 1912 月份不在1~12中
SR2 6 -1 1912 日期不在1~31中
SR3 6 15 1811 年份不在1812~2012中
SR4 -1 -1 1912 两个无效一个有效
SR5 6 -1 1811 两个无效一个有效
SR6 -1 15 1811 两个无效一个有效
SR7 -1 -1 1811 三个无效
佣金问题
等价类测试用例,它是根据佣金函数的输出值域定义等价类,来改进测试用例集合。 输出销售额≤1000元 佣金10% 1000<销售额≤1800 佣金=100+(销售额-1000)*15% 销售额>1800 佣金=220+(销售额-1800)*20%
佣金问题等价类测试用例,它是根据佣金函数的输出值域定义等价类,来改进测试用例集合。
输出销售额≤1000元 佣金10%
1000<销售额≤1800 佣金=100+(销售额-1000)*15%
销售额>1800 佣金=220+(销售额-1800)*20%
输入条件 | 有效等价类 | id | 无效等价类 | id | |
3个非负整数 | 非负整数 | 1 | 非整数 | x非整数 | 6 |
y非整数 | 7 | ||||
z非整数 | 8 | ||||
负数 | x为负 | 9 | |||
y为负 | 10 | ||||
z为负 | 11 | ||||
三个数 | 2 | 少于3 | 12 | ||
多于3 | 13 | ||||
机枪数范围 | -1<x<71 | 3 | x<=-1 | 14 | |
x>=71 | 15 | ||||
枪托数范围 | -1<y<81 | 4 | y<=-1 | 16 | |
y>=81 | 17 | ||||
枪管数范围 | -1<z<91 | 5 | z<=-1 | 18 | |
z>=91 | 19 | ||||
销售额 | 0-1000 | 20 | <0 | 23 | |
1001-1800 | 21 | ||||
>1800 | 22 |
有效等价类
测试用例 枪机(45) 枪托(30) 枪管(25) 销售额 佣金
1 5 5 5 500 50
2 15 15 15 1500 175
3 25 25 25 2500 360
根据输出域选择输入值,使落在输出域等价类内,可以结合弱健壮测试用例结合。
边界值
佣金问题分三个部分:输入数据部分,用来处理数据有效性(与三角形和档案系统管理中的一样);销售额计算;佣金计算。由于题目要求,根据佣金函数的输出值定义等价类,所以可以省略输入数据有效性部分。测试用例设计如下:
测试用例 | 枪机(45) | 枪托(30) | 枪管(25) | 销售额 | 佣金 | 备注 |
1 | 1 | 1 | 1 | 100 | 10 | 最小值 |
2 | 1 | 1 | 2 | 125 | 12.5 | 略大于最小值 |
3 | 1 | 2 | 1 | 130 | 13 | 略大于最小值 |
4 | 2 | 1 | 1 | 145 | 14.5 | 略大于最小值 |
5 | 5 | 5 | 5 | 500 | 50 | 中点 |
6 | 10 | 10 | 9 | 975 | 97.5 | 略小于边界值 |
7 | 10 | 10 | 10 | 1000 | 100 | 边界值 |
8 | 10 | 10 | 11 | 1025 | 103.75 | 略高于边界值 |
9 | 14 | 14 | 14 | 1400 | 160 | 中点 |
10 | 18 | 18 | 17 | 1775 | 216.25 | 略低于边界值 |
11 | 18 | 18 | 18 | 1800 | 220 | 边界值 |
12 | 18 | 18 | 19 | 1825 | 225 | 略高于边界值 |
13 | 48 | 48 | 48 | 4800 | 820 | 中点 |
14 | 69 | 80 | 90 | 7755 | 1411 | 略低于边界值 |
15 | 70 | 80 | 89 | 7775 | 1415 | 略低于边界值 |
16 | 70 | 80 | 90 | 7800 | 1420 | 输出最大值 |
此外还可以选取更接近于边界值得测试用例,比如:
测试用例 | 枪机 | 枪托 | 枪管 | 销售额 | 佣金 | 备注 |
1 | 10 | 11 | 9 | 1005 | 100.75 | 略高于边界值 |
2 | 18 | 17 | 19 | 1795 | 219.25 | 略低于边界值 |
3 | 18 | 19 | 17 | 1805 | 221 | 略高于边界值 |
边界值分析方法:
一.方法简介 1.定义:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
2.与等价划分的区别 1)边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。 2)边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。
3.边界值分析方法的考虑: 长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。 使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。
4.常见的边界值 1)对16-bit 的整数而言 32767 和 -32768 是边界 2)屏幕上光标在最左上、最右下位置 3)报表的第一行和最后一行 4)数组元素的第一个和最后一个 5)循环的第 0 次、第 1 次和倒数第2 次、最后一次
内部边界值条件主要有下面几种:
数值的边界值检验:计算机是基于二进制进行工作的,因此,软件的任何数值运算都有一定的范围限制。
在这里插入图片描述
字符的边界值检验:在计算机软件中,字符也是很重要的表示元素,其中ASCII和Unicode是常见的编码方式。如下列出了一些常用字符对应的ASCII码值。
在这里插入图片描述
其它边界值检验:在不同的行业应用领域,依据硬件和软件的标准不同而具有各自特定的边界值。如下列出部分手机相关的边界值:
成绩报告问题
现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示,所有记录分为3组:
在这里插入图片描述
1)标题:这一组只有一个记录,其内容为输出成绩报告的名字。
2)试卷各题标准答案记录:每个记录均在第80个字符处标以数字”2″。该组的第一个记录的第1至第3个字符为题目编号(取值为1一999)。第10至第59个字符给出第1至第50题的答案(每个合法字符表示一个答案)。该组的第2,第3……个记录相应为第51至第100,第101至第150,…题的答案。
3)每个学生的答卷描述:该组中每个记录的第80个字符均为数字”3″。每个学生的答卷在若干个记录中给出。如甲的首记录第1至第9字符给出学生姓名及学号,第10至第59字符列出的是甲所做的第1至第50题的答案。若试题数超过50,则第2,第3……纪录分别给出他的第51至第100,第101至第150……题的解答。然后是学生乙的答卷记录。
4)学生人数不超过200,试题数不超过999。
5)程序的输出有4个报告:
a)按学号排列的成绩单,列出每个学生的成绩、名次。
b)按学生成绩排序的成绩单。
c)平均分数及标准偏差的报告。
d)试题分析报告。按试题号排序,列出各题学生答对的百分比。
输出条件及相应的测试用例表。
三角形问题
的边界值分析测试用例 在三角形问题描述中,除了要求边长是整数外,没有给出其它的限制条件。在此,我们将三角形每边边长的取范围值设值为[1, 100] 。
NextDate函数
的边界值分析测试用例 在NextDate函数中,隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31,并设定变量year的取值范围为1912≤year≤2050 。
错误推断法
概念
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。
错误推断法的应用
基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。 1.例如, 输入数据和输出数据为0的情况;输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
2、例如,测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况: 1)输入的线性表为空表; 2)表中只含有一个元素; 3)输入表中所有元素已排好序; 4)输入表已按逆序排好; 5)输入表中部分或全部元素相同。
3.例如,测试手机终端的通话功能,可以设计各种通话失败的情况来补充测试用例: 1)无SIM 卡插入时进行呼出(非紧急呼叫) 2)插入已欠费SIM卡进行呼出 3)射频器件损坏或无信号区域插入有效SIM卡呼出 4)网络正常,插入有效SIM卡,呼出无效号码(如1、888、333333、不输入任何号码等) 5)网络正常,插入有效SIM卡,使用“快速拨号”功能呼出设置无效号码的数字
成绩报告
前面例子中成绩报告的程序,采用错误推测法还可补充设计一些测试用例:
1)程序是否把空格作为回答
2)在回答记录中混有标准答案记录
3)除了标题记录外,还有一些的记录最后一个字符即不是2也不是3
4)有两个学生的学号相同
5)试题数是负数
因果图法
概念
因果图法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。
等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。
1)因果关系:
2)约束
输入状态相互之间还可能存在某些依赖关系,称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。
在这里插入图片描述
- 输入条件的约束有以下4类:
E约束(异):a和b中至多有一个可能为1,即a和b不能同时为1。 I约束(或):a、b和c中至少有一个必须是1,即 a、b 和c不能同时为0。 O约束(唯一);a和b必须有一个,且仅有1个为1。 R约束(要求):a是1时,b必须是1,即不可能a是1时b是0。
采用因果图法设计测试用例的步骤:
- 1)分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。
- 2)分析软件规格说明描述中的语义,找出原因与结果之间, 原因与原因之间对应的关系,根据这些关系,画出因果图。
- 3)由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现,为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。
- 4)把因果图转换为判定表。
- 5)把判定表的每一列拿出来作为依据,设计测试用例。
某软件规格说明书
1.某软件规格说明书包含这样的要求:第一列字符必须是A或B,第二列字符必须是一个数字,在此情况下进行文件的修改,但如果第一列字符不正确,则给出信息L;如果第二列字符不是数字,则给出信息M。 解答: 1)根据题意,原因和结果如下: 原因: 1——第一列字符是A; 2——第一列字符是B; 3——第二列字符是一数字。 结果: 21——修改文件; 22 ——给出信息L; 23——给出信息M。 2)其对应的因果图如下: 11为中间节点;考虑到原因1和原因2不可能同时为1,因此在因果图上施加E约束。
在这里插入图片描述
3)根据因果图建立判定表。
5角钱的饮料的自动售货机
有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下:若投入5角钱或1元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出来。若售货机没有零钱找,则一个显示〖零钱找完〗的红灯亮,这时在投入1元硬币并押下按钮后,饮料不送出来而且1元硬币也退出来;若有零钱找,则显示〖零钱找完〗的红灯灭,在送出饮料的同时退还5角硬币。
1)分析这一段说明,列出原因和结果
原因:
1——售货机有零钱找
2——投入1元硬币
3——投入5角硬币
4——押下橙汁按钮
5——.押下啤酒按钮
结果:
21——售货机〖零钱找完〗灯亮
22——退还1元硬币
23——退还5角硬币
24——送出橙汁饮料
25——送出啤酒饮料
2)画出因果图,如图所示。所有原因结点列在左边,所有结果结点列在右边。建立中间结点,表示处理的中间状态。中间结点: 11—— 投入1元硬币且押下饮料按钮 12——押下〖橙汁〗或〖啤酒〗的按钮 13——应当找5角零钱并且售货机有零钱找 14——钱已付清
3)转换成判定表:
4)在判定表中,阴影部分表示因违反约束条件的不可能出现的情况,删去。第16列与第32列因什么动作也没做,也删去。最后可根据剩下的16列作为确定测试用例的依据。
判定表驱动法
概念
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
判定表驱动法
1.判定表的优点
能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。
在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题。
2.判定表通常由四个部分组成如下图所示。
1)条件桩(Condition Stub):列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2)动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3)条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。
4)动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。
3.规则及规则合并
1)规则:任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。 2)化简:就是规则合并有两条或多条规则具有相同的动作,并且其条件项之间存在着极为相似的关系。
4 规则及规则合并举例
1)如下图左端,两规则动作项一样,条件项类似,在1、2条件项分别取Y、N时,无论条件3取何值,都执行同一操作。即要执行的动作与条件3无关。于是可合并。“-”表示与取值无关。
在这里插入图片描述
2)与上类似,下图中,无关条件项“-”可包含其他条件项取值,具有相同动作的规则可合并。
5.判定表的建立步骤:
(根据软件规格说明)
1)确定规则的个数.假如有n个条件。每个条件有两个取值(0,1),故有2n种规则。 2)列出所有的条件桩和动作桩。 3)填入条件项。 4)填入动作项。等到初始判定表。 5)简化.合并相似规则(相同动作)。
7判定表的优点和缺点
- 优点:它能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏。
- 缺点:不能表达重复执行的动作,例如循环结构。
B. Beizer 指出了适合使用判定表设计测试用例的条件:
- 规格说明以判定表形式给出,或很容易转换成判定表。
- 条件的排列顺序不会也不影响执行哪些操作。
- 规则的排列顺序不会也不影响执行哪些操作。
- 每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。
- 如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。
- B. Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表,同样可以借以设计测试用例,只不过尚需增加其它的测试用例罢了。
“阅读指南”判定表
化简后的读书指南判定表
1.问题要求:”……对功率大于50马力的机器、维修记录不全或已运行10年以上的机器,应给予优先的维修处理……” 。这里假定,“维修记录不全”和“优先维修处理”均已在别处有更严格的定义 。请建立判定表。 解答: 1)确定规则的个数:这里有3个条件,每个条件有两个取值,故应有222=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? | 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 | |
动作桩 | 优先处理? | y | y | y | n | y | n | y | n |
其他 | y | y | y |
5)化简,合并相似规则后得到图。
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不是闰年} 考虑各种有效的输入情况,程序中可能采取的操作有以下六种: a1: day+2 a2: day=2 a3: day=1 a4: month+1 a5: month=1 a6: year+1
正交试验法
概念
依据Galois理论,从大量的(实验)数据(测试例)中挑选适量的,有代表性的点(例),从而合理地安排实验(测试)的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法方法等.
正交试验法
利用因果图来设计测试用例时, 作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人,给软件测试带来沉重的负担,为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。 利用正交实验设计测试用例的步骤: 1.提取功能说明,构造因子–状态表 把影响实验指标的条件称为因子.而影响实验因子的条件叫因子的状态.利用正交实验设计方法来设计测试用例时,首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素,把他们当作因子,而把各个因子的取值当作状态.对软件需求规格说明中的功能要求进行划分,把整体的概要性的功能要求进行层层分解与展开,分解成具体的有相对独立性的基本的功能要求.这样就可以把被测试软件中所有的因子都确定下来,并为确定个因子的权值提供参考的依据.确定因子与状态是设计测试用例的关键.因此要求尽可能全面的正确的确定取值,以确保测试用例的设计作到完整与有效。 2.加权筛选,生成因素分析表 对因子与状态的选择可按其重要程度分别加权.可根据各个因子及状态的作用大小,出现频率的大小以及测试的需要,确定权值的大小。 3.利用正交表构造测试数据集 正交表的推导依据Galois理论(这里省略,需要时可查数理统计方面的教材)。 利用正交实验设计方法设计测试用例,比使用等价类划分,边界值分析,因果图等方法有以下优点:节省测试工作工时;可控制生成的测试用例数量;测试用例具有一定的覆盖率。
功能图法
概念
功能图由状态迁移图和布尔函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置(或时间),而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能.例,一个简化的自动出纳机ATM的功能图。
功能图法的应用
1.功能图介绍 一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序或转移的次序.
静态说明描述了输入条件与输出条件之间的对应关系.对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能图的测试用例.
功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态.逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定.测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成.功能图方法其实是是一种黑盒白盒混合用例设计方法。
(功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中 的内容.逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法.该方法要求测试人员对程序的逻辑结构有清楚的了解.由于覆盖测试的目标不同,逻辑覆盖可分为:语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖及路径覆盖.下面我们指的逻辑覆盖和路径是功能或系统水平上的,以区别与白盒测试中的程序内部的.)
2.测试用例生成方法 从功能图生成测试用例,得到的测试用例数是可接受的. 问题的关键的是如何从状态迁移图中选取测试用例. 若用节点代替状态,用弧线代替迁移,则状态迁移图就可转化成一个程序的控制流程图形式.问题就转化为程序的路径测试问题(如白盒测试)问题了。
3.测试用例生成规则 为了把状态迁移(测试路径)的测试用例与逻辑模型(局部测试用例)的测试用例组合起来,从功能图生成实用的测试用例,须定义下面的规则.在一个结构化的状态迁移(SST)中,定义三种形式的循环:顺序,选择和重复.但分辨一个状态迁移中的所有循环是有困难的.(其表示图形省略)。
4.从功能图生成测试用例的过程 1)生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测试用例由原因值(输入数据)组合与对应的结果值(输出数据或状态)构成。 2)测试路径生成:利用上面的规则(三种)生成从初始状态到最后状态的测试路径。 3)测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合。 5.测试用例的合成算法:采用条件构造树。
场景法
概念
现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。
场景法的应用
基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1和3);也可能起源于另一个备选流(如备选流2),或者终止用例而不再重新加入到某个流(如备选流2和4)。
在这里插入图片描述
实例
- 例子描述 下图所示是ATM例子的流程示意图。
在这里插入图片描述
2.场景设计:下表所示是生成的场景。
3.用例设计 对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。
4.数据设计 一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。 测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据,如表3-10所示。