测试用例设计白皮书-判定表
3.2.3 判定表
步 骤
3、 填入条件项、动作项 4、简化决策表 5、根据决策表设计测试用例
课堂练习 打印机打印文件问题
问题描述:
打印机是否能打印出来正确的内容,有多个因
素影响,包括驱动程序、纸张、墨粉等。
假定:优先警告缺纸,然后警告没有墨粉,最后警 告驱动程序不对。
请你使用判定表方法设计测试用例。
课堂练习
判定表
什么是判定表?
判定表也称决策表,是分析和表达多逻辑条件下执
行不同操作的情况的工具。
决策表能够将复杂的问题按照各种可能的情况全部 列举出来,简明并避免遗漏,设计出完整的测试用 例集合。
判定表实例——“阅读指南”决策表
规则 选项 你觉得疲倦吗? 问 题 你对内容感兴趣吗? 书中内容使你胡涂吗? 请回到本章开头重读 建 议 1 Y Y Y 2 Y Y N 3 Y N Y 4 Y N N 5 N Y Y √ 6 N Y N 7 N N Y 8 N N N
建 议
规则合并实例——“阅读指南”决策 表
规则 选项 你觉得疲倦吗?
1 Y — —
5 N Y Y √
6 N Y N √
7 N N —
问 题
你对内容感兴趣吗? 书中内容使你胡涂吗? 请回到本章开头重读 继续读下去 跳到下一章去读 停止阅读,请休息
建 议
√ √
决策表的建立步骤
1、列出所有的条件桩和动作桩 2、 确定规则的个数
决策表的简化主要包含两个方面:规则合并与规则包含
(1)规则合并
如果两条或多条规则的动作项相同,条件项只有一项不同,则 可以将该项合并,合并后的条件项用符号“-”表示,说明执行 的动作与该条件的取值无关,称为无关条件。
测试用例设计--判定表
测试⽤例设计--判定表1、为什么⽤判定表设计测试⽤例?等价类⽅法详细的考虑了需求输⼊域,但对于输⼊域与输⼊域存在关联时⽆法覆盖,(⽐如等价类划分设计测试⽤例时,设计⼀条新的测试⽤例,使其仅覆盖⼀个⽆效等价类,直⾄所有的⽆效等价类完全被覆盖,没有考虑⽆效等价类与⽆效等价类的组合情况)。
所以需要⼀种能考虑输⼊域间的互相关系设计⽅法来考虑业务描述性的测试需求。
2、什么是判定表?判断表是分析喝表达若⼲输⼊条件下,被测对象根据输⼊作出不同响应的⼯具,适⽤于业务逻辑关系和多种条件组合情况。
判定表的结构条件桩:被测对象的所有输⼊条件项:针对条件桩可能输⼊的真假值动作桩:针对条件桩被测对象可能采取的所有动作动作项:针对动作桩,被测对象响应可能结果取值3、怎么⽤判定表设计测试⽤例?步骤:⼀、列出所有的条件和动作⼆、根据提取出来的条件桩和动作桩,设计判定表确定规则的个数(假如有n个条件,每个条件有2个取值(0、1),就可以产⽣2的n次⽅种规则)三、填写判定表四、简化判定表(合并判定表是牺牲测试充分性,混乱业务逻辑为代价。
8条以内的规则不建议合并)五、抽取测试⽤例(简化判定表后,可抽取判定表中的每⼀条规则作为测试⽤例,判定表得到的是测试规则,不是最终的测试⽤例。
规则不能验证功能点正确性,仅验证业务规则的正确性)4、判定表设计测试⽤例的优缺点?优点:判定表充分考虑了输⼊域之间的组合情况,每条规则覆盖了多条输⼊条件,考虑输⼊的约束关系,降低了漏测的风险。
同时利⽤判定表可推断出需求规格本⾝的逻辑性,反向证明了需求的正确。
缺点:当输⼊项过多时,规则数以2的n次⽅剧增,判定表会⾮常庞⼤,采⽤判定表合并时会造成逻辑缺失,业务混乱错误的情况。
5、判断表设计测试⽤例的例⼦⽰列⼀:停机或⽋费不允许主被叫步骤⼀:列出所有的条件和动作条件:停机/⽋费动作:主被叫步骤⼆:确定规则数有3个条件,每个条件有2个取值,故有8个规则步骤三:填写判定表步骤四:只有4条规则不合并,8条以下的规则不建议合并步骤五:规则抽取:(1)⽤户不停机不⽋费,可进⾏主被叫(2)⽤户不停机⽋费,不允许主被叫(3)⽤户停机不⽋费,不允许主被叫(4)⽤户停机⽋费,不允许住被叫。
判定表例子
• 从判定表得到的测试用例
判定表例子
• 三角形问题的判定表(假设a,b,c都是范围内正数)
测试用例设计
• • 语句覆盖的测试用例(1个)
– – [(2,0,4),(2,0,3)] 覆盖ace
判定/分支覆盖的测试用例(2个)
方案1:[(2,0,4),(2,0,3)] 覆盖ace [(1,1,1),(1,1,1)] 覆盖abd – 方案2:[(2,1,1),(2,1,2)] 覆盖abe [(3,0,3),(3,1,1)] 覆盖acd 问题:如果将x>1错写成x<1,以上判定/分支覆盖测试用例 时发 现不了的(需让判断2中的两条件分别为假、真)。
测试数据期望结果覆盖范围200306输入有效等价类123月在112之间一个范例cont为每一个无效等价类至少设计一个测试用例测试数据期望结果覆盖范围003may输入无效等价类420035输入无效等价类52003005输入无效等价类6200105输入无效等价类7200905输入无效等价类8200300输入无效等价类9200313输入无效等价类10报表日期边界值分析法测试用输入条件测试用例说明测试数据期望结果选取理由报表日期类型及长度1个数字字符显示出错仅有1个合法字符6个数字字符200305输入有效类型及长度均有效5个数字字符20035显示出错比有效长度少17个数字字符2003005显示出错比有效长度多1有1个非数字字符20035显示出错只有1个非法字符全是非数字字符may显示出错6个非法字符年份范围年份为2003年200305输入有效最小年份年份为2008年200805输入有效最大年份年份为2002年200205显示出错刚好小于最小年份年份位2009年200905显示出错刚好大于最大年份月份范围月份为1月200301输入有效最小月份月份为12月200312输入有效最大月份月份为0200300显示出错刚好小于最小月份月份为13200313显示出错刚好大于最大月份
测试用例设计--判定表
测试⽤例设计--判定表1.定义判定表通常由四部分组成,如上图:条件桩:它列出决定⼀组条件的对象;条件项:它列出各种可能的条件组合;动作桩:它列出所有的操作;动作项:它列出在对应的条件组合下的动作。
2.应⽤的范围在多个条件多个动作,并且每个条件的取值只有两种的情况下,我们就可以采⽤判定表⽅法。
3.步骤 1)识别条件和动作 2)⽣成判定表 3)简化判定表4.案例订购单的检查。
如果⾦额超过500元,⼜未过期,则发出批准单和提货单;如果⾦额超过500元,但过期了,则不发批准单;如果⾦额低于500元,则不论是否过期都发出批准单和提货单,在过期的情况下还需要发出通知单。
判定表分析过程 1)识别条件和动作条件桩条件项1:⾦额>500元订购⾦额是否⼤于500元0:⾦额<=500元1:订单未过期订购单是否过期0:订单过期动作桩动作项发出批准单X:表⽰发出批准单发出提货单X:表⽰发出提货单发出通知单X:发出通知单 2)⽣成判定表条件桩条件项订购⾦额是否⼤于500元1100订购单是否过期1010发出批准单X X X发出提货单X X X发出通知单X 3)简化判定表在很多情况下,⼀个判定表写出来以后,是很复杂的,我们需要对其进⾏简化。
如果表中有两条或者多条规则具有相同的动作,并且其条件项之间存在极为相似的关系,我们就可以将其合并。
条件桩条件项订购⾦额是否⼤于500元--10订购单是否过期100发出批准单X X发出提货单X X发出通知单X 这⾥引⼊⼀个概念,规则,以上判定表⾥,右部的每⼀列(条件项和对应的动作项)都是⼀条规则。
以上判定表⾥每⼀条规则都可以转化为测试⽤例。
测试用例确认表.pdf
测试用例确认表
编号:序号:04
项目名称XX项目负责人XX
评审人员部门职务或职称评审人员部门职务或职称XX XX XX XX XX XX
XX XX XX XX XX XX
评审内容:“□”内打“√”
表不同意
表评审通过,“?”表有建议或疑问,“X”
1.是否能按照测试计划时间完成用例编写?是□否
2.用例是否按照公司定义的模板进行编写?是□否
3.测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述?是□否
4.每个测试用例是否都阐述预期结果和评估该结果的方法?是□否
5.业务流程中最长的流程用例是否覆盖?是□否
6.测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述?是□否存在问题及改进建议:
无
评审结论:
测试用例可用
领导意见:
无
确认人:XX 日期:XX 客户意见:
同意测试用例设计
确认人:XX 日期:XX
制表单位:XX有限公司。
判定表通常由四个部分组成条件桩C...
功能测试及性能测试技术白皮书一、软件测试的概念软件测试定义:在软件投入运行前对软件前对软件需求分析、软件设计规格说明和软件编码进行的查错(包括代码执行活动和人工活动)。
也可以说,软件测试是为了发现错误而执行程序的过程。
或者说,软件测试是根据软件开发各个阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果),并利用这些测试用例去运行程序,以发现程序的错误,这是在软件投入运行前,对软件需求分析、软件设计规格说明和软件编码的最终复审,是软件质量保证的关键步骤。
二、软件测试的前提软件的可测试性:是一个计算机程序能够被测试的容易程度软件可测试性表:可操作性――运行的越好,被测试的效率越高可观察性――所看见的,就是所测试的可控制性――对软件的控制越好,测试越能够被自动执行与优化可分解性――通过控制测试范围,能够更好的分解问题,执行更灵巧的再测试简单性――需要测试的内容越少,测试的速度越快稳定性――改变越少,对测试的破坏越小易理解性――得到的信息越多,进行的测试越灵巧三、软件测试的目的G len Myers在他的软件测试著作中就软件测试的目的提出下列观点。
(1)测试是一个为了寻找错误而运行程序的过程。
(2)一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例。
(3)一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。
正确认识测试的目的是十分重要的,只有这样,才能设计出最能暴露错误的测试方案。
测试的目的应从用户角度出发,通过软件测试暴露软件中潜在的错误和缺陷,而不应从软件开发者的角度出发,希望测试成为表明软件产品不存在错误,验证软件已正确实现用户的要求的过程。
否则,开发者测试时会选择不易测试出错误和缺陷的用例,这与上述测试目的相违背。
测试的目标是能够以耗费最少时间与最小工作量找出软件系统中潜在的各种错误与缺陷。
另外,应该认识到:测试只能证明程序中错误的存在,但不能证明程序中没有错误。
实践黑盒测试之判定表案例
X
XXXBiblioteka XXXXXX
X
X
此月是12月
此月是2月
续……
此年是闰年
11 12 13 14 15 16 17 18 19 20 21 22
c1:月份在 M3 M3 M3 M3 M3 M4 M4 M4 M4 M4 M4 M4
c2:日期在 D1 D2 D3 D4 D5 D1 D2 D2 D3 D3 D4 D5
不可能 不可能
第三次尝试(关注日期和月份)
M1={月份:每月有30天} M2={月份:每月有31天,12月除外} M3={月份:此月是12月} M4={月份:此月是2月} D1={日期:1≤日期≤ 27} D2={日期:日期=28} D3={日期:日期=29} D4={日期:日期=30} D5={日期:日期=31} Y1={年:年是闰年} Y2={年:年不是闰年}
1~3
45
6~9
10
M1
M1 M1
M2
M2
D1,D2,D3 D4 D5 D1,D2,D3,D4 D5
—
——
—
—
X
X
X
X
X
X
X
续……
11~14 15 16 17 18 19 20 21,22
c1:月份在
M3
M3 M4 M4 M4 M4 M4 M4
c2:日期在 D1,D2,D3,D4 D5 D1 D2 D2 D3 D3 D4,D5
(1)条件桩
C1:a,b,c构成三角形? C2:a = b? C3:a = c? C4:b = c?
(2)规则数
共有四个条件,每个条件的取值为“是”或
“否”,因此有24= 16条规则。
(完整word版)测试用例设计
举例1、保险费率计算(按照输入域划分等价类的例子):✓某保险公司承担人寿保险,该公司保费计算方式为:保费=投保额*保险率,保险率依点数不同而有别,10点以上(含10点)费率为0.6%,10点以下费率为0.1% ✓点数的计算是年龄、性别、婚姻、抚养人数所得的点数的总和✓输入:年龄、性别、婚姻、抚养人数✓输出:保险率输入数据说明:解答:第一步:输入和输出变量确认✓输入:年龄、性别、婚姻、抚养人数✓输出:保险率✓等价类划分原则:按照输入变量来确认等价类(有效等价类和无效等价类)第二步:等价类划分第三步:设计测试用例1、设计测试用例,尽可能的覆盖尚未覆盖的有效等价类。
➢(1)(8)(10)(12)➢(2)(9)(11)(13)➢(3)(8)(10)(14)2、设计测试用例,使得每一个新设计的测试用例只包含一个无效等价类,其他的选择有效等价类。
➢(4)(8)(10)(12)➢(5)(9)(11)(13)➢(6)(8)(10)(14)➢(7)(8)(10)(14)➢(1)(8)(10)(15)➢(2)(9)(11)(16)➢(3)(8)(10)(16)说明:在设计无效部分的测试用例的时候,有效等价类部分,可以任意选择。
思考:若使用边界值法可以增加哪些用例?是否可以用判定表方法设计测试用例?举例2(因果图法设计测试用例):某电力公司有A、B、C、D四类收费标准,其规定如下图用电类别用电额度用电期间收费类型居民用电<100度/月——A类>=100度/月B类动力用电<10000度/月非高峰期B类>=10000度/月非高峰期C类<10000度/月高峰期C类>=10000度/月高峰期D类第一步:分析题目,列出原因和结果,并编号;输入条件(原因)输出动作(结果)1:居民用电A:A类计费2:动力用电B:B类计费3:<100度/月C:C类计费4:<10000度/月D:D类计费5:用电高峰期第二步:画出因果图,所有原因结点在左边,所有结果结点在右边,并建立四个中间结点,表示处理的中间状态第三步:把因果图转换为判定表;第四步:为判定表每一列设计一个测试用例;一、程序如下:Int A.B;Double X;if (A > 1 && B == 0)X = X/A;if (A == 2 || X > 1)X = X + 1;cout<<A<<B<<X;要求:1、画出程序流程图;2、分别使用语句覆盖、判定覆盖、条件覆盖、条件组合覆盖方式设计测试用例;3、在TD上编写出测试用例二、有一个员工管理系统,现对其录入模块进行测试。
判定表设计用例案例
判定表设计用例案例
# 场景一:正常购买。
用户:普通乔。
操作:投入硬币,选择商品,按下购买按钮。
预期结果:售货机吐出商品,找零(如果有的话)。
测试用例:
1. 乔投入5块钱,买了一瓶3块钱的可乐,机器应该吐出可乐和2块钱的零钱。
2. 乔投入10块钱,买了一包5块钱的薯片,机器应该吐出薯片和5块钱的零钱。
# 场景二:找零不足。
用户:小气李。
操作:投入硬币,选择商品,按下购买按钮。
预期结果:售货机吐出商品,但由于找零不足,应该显示“找零不足”并退还硬币。
测试用例:
1. 小气李投入1块钱,想买一瓶2块钱的矿泉水,机器应该退还1块钱,并显示“找零不足”。
2. 小气李投入3块钱,想买一瓶2块钱的可乐,机器应该吐出可乐,但因为找零不足,不退还1块钱。
# 场景三:商品缺货。
用户:贪心赵。
操作:投入硬币,选择一个已经售罄的商品,按下购买按钮。
预期结果:售货机显示“商品缺货”,并退还硬币。
测试用例:
1. 贪心赵投入5块钱,选择了一个已经卖完的巧克力棒,机器应该退还5块钱,并显示“商品缺货”。
2. 贪心赵投入10块钱,选择了一个还有库存的饮料,机器应该正常吐出饮料和找零。
# 场景四:机器故障。
用户:倒霉钱。
操作:投入硬币,选择商品,按下购买按钮。
预期结果:售货机显示“机器故障”,并退还所有硬币。
测试用例:
1. 倒霉钱投入5块钱,机器突然卡住,应该退还5块钱,并显示“机器故障”。
2. 倒霉钱投入10块钱,机器正常工作,应该吐出商品和找零。
简述判定表法设计用例步骤
简述判定表法设计用例步骤判定表法是一种用于设计测试用例的有效方法,它可以帮助测试人员针对复杂的业务规则设计出全面的测试用例。
本文将介绍判定表法的基本步骤,以及如何应用该方法来设计测试用例。
下面是本店铺为大家精心编写的4篇《简述判定表法设计用例步骤》,供大家借鉴与参考,希望对大家有所帮助。
《简述判定表法设计用例步骤》篇1一、判定表法的基本步骤判定表法是一种用于设计测试用例的方法,它通常分为以下几个步骤:1. 识别条件和动作测试人员需要先了解业务规则,识别出所有可能的条件和动作。
条件是指影响业务规则执行的因素,动作是指在条件满足时需要执行的操作。
2. 生成判定表根据识别出的条件和动作,测试人员可以生成一个判定表。
判定表通常由四个部分组成,即条件桩、条件项、动作桩和动作项。
条件桩列出决定一组条件的对象,条件项列出各种可能的条件组合,动作桩列出所有的操作,动作项列出在对应的条件组合下的动作。
3. 简化判定表在生成判定表后,测试人员需要对其进行简化。
如果表中有两条或多条规则具有相同的动作,并且其条件项之间存在极为相似的关系,我们就可以将其合并。
4. 转化为测试用例每一条规则都可以转化为测试用例。
测试人员可以根据判定表中的规则,设计出对应的测试用例,以覆盖所有的业务规则。
二、应用判定表法设计用例的案例以一个交易所的手续费计算规则为例,根据交易金额和每股价格和股数的关系,手续费分为三种情况:1. 如果交易金额少于 1000 元,则基本手续费为交易金额的8.4%;2. 如果交易总金额在 1000 元~10000 元之间,则基本手续费为交易金额的 5%,再加 34 元;3. 如果金额超过 10000 元,则基本手续费为交易金额的 4% 加上 134 元。
当每股售价低于 14 元时,附加手续费为基本手续费的 5%,除非买进、卖出的股数不是 100 的倍数,在这种情况下附加手续费的9%。
当每股售价在 14 元到 25 元之间时,附加手续费为基本手续费的某个百分比。
判定表ppt课件
判定表可以用于快速定位系统中的故障和问题。
故障分类
根据故障现象和影响范围,判定表可以对故障进 行分类和优先级排序。
解决方案
判定表可以提供针对不同故障的解决方案和实施 步骤。
04
判定表的实际案例
企业决策分析案例
总结词
通过判定表,企业决策者可以更加清晰地分 析各种因素,制定出科学合理的决策。
与规则引擎比较
表达方式
规则引擎通常以自然语言或编程语言的形式描述规则,而判定表 则通过表格形式直观地展示条件与动作的关系。
执行效率
规则引擎的执行效率通常较高,因为规则被直接嵌入到程序中。相 比之下,判定表需要逐条解析和执行。
灵活性
规则引擎更加灵活,可以随时修改和添加规则,而判定表在表格结 构确定后,更改相对不便。
06
判定表的发展趋势与未来 展望
判定表在人工智能领域的应用
决策支持
01
判定表可应用于构建决策支持系统,帮助用户理解和解决复杂
的决策问题。
知识推理
02
判定表可以用于表示和推理领域知识,提高人工智能系统的可
解释性和可靠性。
自动化流程
03
判定表可以用于自动化流程管理,通过逻辑推理和条件判断实
现流程的自动化执行。
与状态图比较
1 2
状态表示
状态图展示了一个系统或对象的状态转换过程, 而判定表更侧重于条件与动作的对应关系。
复杂性
状态图能够描述复杂的交互过程和状态转换,判 定表则更简单直接,不涉及复杂的交互过程。
3
适用场景
状态图适用于描述系统的状态转换和行为流程, 判定表则适用于描述基于条件的决策或行为选择 。
判定表的未来研究方向
测试用例设计白皮书
测试用例设计白皮书--测试用例基本概念Author: Vince 来源:文斯测试技术研究中心目录1. 概述2. 测试用例基本概念2.1. 测试用例的定义2.2. 测试用例的特征2.3. 测试用例组成元素2.4. 测试用例设计原则3. 测试用例设计方法3.1. 等价类划分方法3.2. 边界值分析方法3.3. 错误推测方法3.4. 因果图方法3.5. 判定表驱动分析方法3.6. 正交实验设计方法3.7. 功能图分析方法3.8. 场景设计方发4. 测试用例设计综合策略1.概述Grenford J. Myers在《The Art of Software Testing》一书中提出:一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试,由此可见测试用例设计工作在整个测试过程中的地位,我们不能只凭借一些主观或直观的想法来设计测试用例,应该要以一些比较成熟的测试用例设计方法为指导,再加上设计人员个人的经验积累来设计测试用例,二者相结合应该是非常完美的组合。
本文所介绍的测试用例设计方法对于测试设计人员将是一个很好的方法指导,当然看完本文也未必能设计出好的测试用例,有了好的方法作为指导后需要更多的实践经验加以巩固和提炼。
只有将测试设计思想与丰富的实践经验相融合才能设计出高质量的测试用例,相信你行!本文描述的范围:测试用例基本概念、测试用例设计方法、测试用例设计综合策略。
关键词:测试用例、等价类划分、边界值分析、错误推测、因果图、判定表驱动分析、正交实验、功能图分析、场景设计读者对象:测试设计人员、测试人员参考文献:1. 《计算机软件测试技术》郑人杰2. 《The Art of Software Testing》 Grenford J. Myers2.测试用例基本概念2.1.测试用例的定义测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。
测试用例是执行的最小实体。
简单地说,测试用例就是设计一个场景,使软件程序在这种场景下,必须能够正常运行并且达到程序所设计的执行结果。
测试用例评审表
4. 5. 评审结 论
评审组 签字
日期
审核人 签字 1.评审结果在对应项中画“√” 。 2.如果该项为不通过应在评审说明中详细描述问题。 3.通过的判定准则是没有“不通过”的评审结果。
日期
备注
项目状态初次评审修改将选中打产应与测试方案和测试计划的内容相一致测试用例应覆盖测试方案和测试计划中的全部测试内容测试用例应模拟典型的具有代表性的用户应用通过不通过评审组签字日期审核人签字日期备注1
测 试 用 例 评 审 表
项目 状态 产品名称 用例数量 评审表 序号 1. 2. 3. 评审内容 测试用例应按规定格式编写 测试用例应与测试方案和测 试计划的内容相一致 测试用例应覆盖测试方案和 测试计划中的全部测试内容 测试用例应模拟典型的、具有 代表性的用户应用 测试用例应包括异常处理流 程 通过 不通过 评审结果 通过 不通过 评审说明 初次评审 修改 (将选中□打√) 版 本 号
测试用例设计白皮书边界值分析方法
测试用例设计白皮书--边界值分析方法一.方法简介1.定义:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。
通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
2.与等价划分的区别1)边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。
2)边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。
3.边界值分析方法的考虑:长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。
因此针对各种边界情况设计测试用例,可以查出更多的错误。
使用边界值分析方法设计测试用例,首先应确定边界情况。
通常输入和输出等价类的边界,就是应着重测试的边界情况。
应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。
4.常见的边界值1)对16-bit 的整数而言32767 和-32768 是边界2)屏幕上光标在最左上、最右下位置3)报表的第一行和最后一行4)数组元素的第一个和最后一个5)循环的第0 次、第1 次和倒数第2 次、最后一次5.边界值分析1)边界值分析使用与等价类划分法相同的划分,只是边界值分析假定错误更多地存在于划分的边界上,因此在等价类的边界上以及两侧的情况设计测试用例。
例:测试计算平方根的函数--输入:实数--输出:实数--规格说明:当输入一个0或比0大的数的时候,返回其正平方根;当输入一个小于0的数时,显示错误信息"平方根非法-输入值小于0"并返回0;库函数Print-Line可以用来输出错误信息。
2)等价类划分:I.可以考虑作出如下划分:a、输入(i)<0 和(ii)>=0b、输出(a)>=0 和(b) ErrorII.测试用例有两个:a、输入4,输出2。
对应于(ii) 和(a) 。
b、输入-10,输出0和错误提示。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
1)条件桩(Condition Stub):列出了问题得所有条件。
通常认为列出的条件的次序无关紧要。
2)动作桩(Action Stub):列出了问题规定可能采取的操作。
这些操作的排列顺序没有约束。
3)条件项(Condition Entry):列出针对它左列条件的取值。
在所有可能情况下的真假值。
4)动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。
5.规则及规则合并
1)规则:任何一个条件组合的特定取值及其相应要执行的操作称为规则。
在判定表中贯穿条件项和动
作项的一列就是一条规则。
显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。
2)化简:就是规则合并有两条或多条规则具有相同的动作,并且其条件项之间存在着极为相似的关系。
6.规则及规则合并举例
1)如下图左端,两规则动作项一样,条件项类似,在1、2条件项分别取Y、N时,无论条件3取何
值,都执行同一操作。
即要执行的动作与条件3无关。
于是可合并。
“-”表示与取值无关。
2)与上类似,下图中,无关条件项“-”可包含其他条件项取值,具有相同动作的规则可合并。
二.实战演习
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等等。
④填入动作桩和动作顶。
这样便得到形如图的初始判定表。
初始判定表
⑤化简。
合并相似规则后得到图。
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)一些软件的功能需求可用判定表表达得非常清楚,在检验程序的功能时判定表也就成为一个不错的
工具。
如果一个软件的规格说明指出:
I.当条件1和条件2满足,并且条件3和条件4不满足,或者当条件1、3和条件4满足时,要执行
操作1。
II.在任一个条件都不满足时,要执行操作2。
III.在条件1不满足,而条件4被满足时,要执行操作3。
根据规格说明得到如下判定表:
这里,判定表只给出了16种规则中的8种。
事实上,除这8条以外的一些规则是指当不能满足指定的条件,执行3种操作时,要执行1个默许的操作。
在没必要时,判定表通常可略去这些规则。
但如果用判定表来设计测试用例,就必须列出这些默许规则(如下表)。
默许的规则
2)判定表的优点和缺点
I.优点:它能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏。
II.缺点:不能表达重复执行的动作,例如循环结构。
3)B. Beizer 指出了适合使用判定表设计测试用例的条件:
①规格说明以判定表形式给出,或很容易转换成判定表。
②条件的排列顺序不会也不影响执行哪些操作。
③规则的排列顺序不会也不影响执行哪些操作。
④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。
⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。
B. Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。
其实对
于某些不满足这几条的判定表,同样可以借以设计测试用例,只不过尚需增加其它的测试用例罢了。