测试用例设计白皮书-判定表

合集下载

3.2.3 判定表

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

测试用例确认表.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...

判定表通常由四个部分组成条件桩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版)测试用例设计

(完整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. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 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个必要条件的目的是为了使操作的执行完全依赖于条件的组合。

其实对
于某些不满足这几条的判定表,同样可以借以设计测试用例,只不过尚需增加其它的测试用例罢了。

相关文档
最新文档