黑盒测试之理解Word文件下载.docx
《黑盒测试之理解Word文件下载.docx》由会员分享,可在线阅读,更多相关《黑盒测试之理解Word文件下载.docx(9页珍藏版)》请在冰豆网上搜索。
性能错误;
初始化和终止错误等。
测试方法
概述
从理论上讲,黑盒测试只有采用穷举输入测试,把所有可能的输入都作为测试情况考虑,才能查出程序中所有的错误。
实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但可能的输入进行测试。
这样看来,完全测试是不可能的,所以我们要进行有针对性的测试,通过制定测试案例指导测试的实施,保证软件测试有组织、按步骤,以及有计划地进行。
黑盒测试行为必须能够加以量化,才能真正保证软件质量,而测试用例就是将测试行为具体量化的方法之一。
具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。
等价类划分的办法是把程序的输入域划分成若干部分(子集),然后从每个部分中选取少数代表性数据作为测试用例。
每一类的代表性数据在测试中的作用等价于这一类中的其他值。
该方法是一种重要的,常用的黑盒测试用例设计方法。
划分等价类
1)划分等价类:
等价类是指某个输入域的子集合。
在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:
测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:
有效等价类和无效等价类.
有效等价类:
是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.
无效等价类:
与有效等价类的定义恰巧相反.
设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.
划分等价类准则
2)划分等价类的方法:
下面给出六条确定等价类的原则.
①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.
③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.
④在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.
⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则).
⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.
3)设计测试用例:
在确立了等价类后,可建立等价类表,列出所有划分出的等价类:
输入条件
输入条件有效等价类无效等价类
然后从划分出的等价类中按以下三个原则设计测试用例:
①为每一个等价类规定一个唯一的编号.
②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.
③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止。
边界值分析
边界值分析是通过选择等价类边界的测试用例。
边界值分析法不仅重视输入条件边界,而且也必须考虑输出域边界。
它是对等价类划分方法的补充.
(1)边界值分析方法的考虑:
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
(2)基于边界值分析方法选择测试用例的原则:
1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.
2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.
3)根据规格说明的每个输出条件,使用前面的原则1).
4)根据规格说明的每个输出条件,应用前面的原则2).
5)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.
6)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.
7)分析规格说明,找出其它可能的边界条件.
错误推测法
错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.
错误推测方法的基本思想:
列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例.例如,在单元测试时曾列出的许多在模块中常见的错误.以前产品测试中曾经发现的错误等,这些就是经验的总结.还有,输入数据和输出数据为0的情况.输入表格为空格或输入表格只有一行.这些都是容易发生错误的情况.可选择这些情况下的例子作为测试用例.
因果图法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等.考虑输入条件之间的相互组合,可能会产生一些新的情况.但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多.因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例.这就需要利用因果图(逻辑模型).
因果图方法最终生成的就是判定表.它适合于检查程序输入条件的各种组合情况.
利用因果图生成测试用例的基本步骤
(1)分析软件规格说明描述中,哪些是原因(即输入条件或输入条件的等价类),哪些是结果(即输出条件),并给每个原因和结果赋予一个标识符.
(2)分析软件规格说明描述中的语义.找出原因与结果之间,原因与原因之间对应的关系.根据这些关系,画出因果图.
(3)由于语法或环境限制,有些原因与原因之间,原因与结果之间的组合情况不可能出现.为表明这些特殊情况,在因果图上用一些记号标明约束或限制条件.
(4)把因果图转换为判定表.
(5)把判定表的每一列拿出来作为依据,设计测试用例.
从因果图生成的测试用例(局部,组合关系下的)包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.
前面因果图方法中已经用到了判定表.判定表(DecisionTable)是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.
判定表通常由四个部分组成
条件桩(ConditionStub):
列出了问题得所有条件.通常认为列出得条件的次序无关紧要.
动作桩(ActionStub):
列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.
条件项(ConditionEntry):
列出针对它左列条件的取值.在所有可能情况下的真假值.
动作项(ActionEntry):
列出在条件项的各种取值情况下应该采取的动作.
规则:
任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.
判定表的建立步骤(根据软件规格说明)
①确定规则的个数.假如有n个条件.每个条件有两个取值(0,1),故有2n种规则.
②列出所有的条件桩和动作桩.
③填入条件项.
④填入动作项.等到初始判定表.
⑤简化.合并相似规则(相同动作).
B.Beizer指出了适合使用判定表设计测试用例的条件:
①规格说明以判定表形式给出,或很容易转换成判定表.
②条件的排列顺序不会也不影响执行哪些操作.
③规则的排列顺序不会也不影响执行哪些操作.
④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.
⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.
正交试验设计法
就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法,目的是用最少的测试用例达到最高的测试覆盖率。
流程
测试计划
首先,根据用户需求报告中关于功能要求和性能指标的规格说明书,定义相应的测试需求报告,即制订黑盒测试的最高标准,以后所有的测试工作都将围绕着测试需求来进行,符合测试需求的应用程序即是合格的,反之即是不合格的;
同时,还要适当选择测试内容,合理安排测试人员、测试时间及测试资源等。
测试设计
将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程,并为每个测试过程选择适当的测试用例(测试用例选择的好坏将直接影响到测试结果的有效性)。
测试开发
建立可重复使用的自动测试过程。
测试执行
执行测试开发阶段建立的自动测试过程,并对所发现的缺陷进行跟踪管理。
测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成,测试人员应本着科学负责的态度,一步一个脚印地进行测试。
测试评估
结合量化的测试覆盖域及缺陷跟踪报告,对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。
优点
1.基本上不用人管着,如果程序停止运行了一般就是被测试程序crash了
2.设计完测试用例之后,下来的工作就是爽了,当然更苦闷的是确定crash原因
缺点
1.结果取决于测试用例的设计,测试用例的设计部分来势来源于经验,OUSPG的东西很值得借鉴
2.没有状态转换的概念,目前一些成功的例子基本上都是针对PDU来做的,还做不到针对被测试程序的状态转换来作
3.就没有状态概念的测试来说,寻找和确定造成程序crash的测试例是个麻烦事情,必须把周围可能的测试例单独确认一遍。
而就有状态的测试来说,就更麻烦了,尤其不是一个单独的testcase造成的问题。
这些在堆的问题中表现的更为突出。
黑盒测试(功能测试)工具的选择
如何高效地完成功能测试?
选择一款合适的功能测试工具并培训一支高素质的工具使用队伍无疑是至关重要的。
尽管现阶段存在少数不采用任何功能测试工具,从事功能测试外包项目的软件服务企业。
短期来看,这类企业盈利状况尚可,但长久来看,它们极有可能被自动化