功能测试1教学文稿.docx
- 文档编号:11476463
- 上传时间:2023-03-01
- 格式:DOCX
- 页数:13
- 大小:23.70KB
功能测试1教学文稿.docx
《功能测试1教学文稿.docx》由会员分享,可在线阅读,更多相关《功能测试1教学文稿.docx(13页珍藏版)》请在冰豆网上搜索。
功能测试1教学文稿
功能测试1
功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。
常用的测试方法如下:
1.页面链接检查:
每一个链接是否都有对应的页面,并且页面之间切换正确。
2.相关性检查:
删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确。
3.检查按钮的功能是否正确:
如update,cancel,delete,save等功能是否正确。
4.字符串长度检查:
输入超出需求所说明的字符串长度的内容,看系统是否检查字符串长度,会不会出错.
5.字符类型检查:
在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
6.标点符号检查:
输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
7.中文字符处理:
在可以输入中文的系统输入中文,看会否出现乱码或出错.
8.检查带出信息的完整性:
在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致
9.信息重复:
在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
10.检查删除功能:
在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.
11.检查添加和修改是否一致:
检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
12.检查修改重名:
修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.
13.重复提交表单:
一条已经成功提交的纪录,back后再提交,看看系统是否做了处理。
14.检查多次使用back键的情况:
在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.
15.search检查:
在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.
16.输入信息位置:
注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.
17.上传下载文件检查:
上传下载文件的功能是否实现,上传文件是否能打开。
对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。
18.必填项检查:
应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加*
19.快捷键检查:
是否支持常用快捷键,如Ctrl+CCtrl+VBackspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。
20.回车键检查:
在输入结束后直接按回车键,看系统处理如何,会否报错.
软件功能特征测试是国际化软件测试最先开始并且贯穿于整个软件开发过程的测试类型,目的是从软件的各个侧面进行质量保证,确保软件的特征功能符合软件的设计需求和功能规格说明。
在执行特征功能测试前,应该对国际化软件提供的软件特征功能以及这些功能的重要性进行风险分析,以便确定测试过程中的测试成本。
1、测试输入
国际化软件的特征功能测试的输入内容包括:
软件功能规格说明;
软件需求;
软件的性能目标;
软件的布署场景(DeploymentScenario)。
2、测试过程
软件特征功能测试的过程如下图所示:
软件测试计划是指导软件测试的主要文档,指出测试的内容、测试的起止日期、测试过程、测试方法、测试用例的优先级和测试的其他详细内容,在软件设计、编码和测试期间,经常需要更新测试计划,特别是更改软件的需求后,需要及时更新软件测试计划。
设计评审(Designreview)确保软件的设计阶段包含了全部的布署场景和软件需求,遵循了软件的性能、安全性、国际化和可维护性的要求。
实现编码评审确保软件的代码正确和遵守规范,符合软件国际化的需要。
软件的白盒测试也称为“结构测试”,是对软件的代码进行审查,找出引起软件功能缺陷的编码错误。
软件的白盒测试也称为“功能测试”,是从用户使用的角度运行软件,执行全部的终端用户场景的测试用例,发现软件与设计需求和用户需求不一致的缺陷。
3、测试过程分析
创建测试计划
测试计划文档中主要的内容是用于测试软件的测试用例,涵盖了设计评审、代码评审、配置、布署测试和负载测试的各个方面,确保软件的全部特征功能和使用场景都进行了测试。
测试文档包括详细测试计划文档和详细测试用例文档。
详细测试计划文档按照“高、中、低”的顺序列出了测试用例的优先级,对测试用例中的使用场景和需要测试的特征进行了简要描述。
根据测试用例的重要性和对期望的目标和需求的全面影响,为每一个测试用例指定测试执行的优先级。
详细测试用例文档与详细测试计划文档相对应,描述了详细测试计划文档列出的需要执行的每个测试用例的执行步骤,以及测试所需要的数据,给出了测试的期望结果。
需要强调的是详细测试计划文档和详细测试用例文档不是一成不变的,相反,这两个文档的内容要在软件开发生命周期的全过程不断更新。
例如,当软件的功能规格说明、软件的需求更改后,或者需要添加更多的测试输入时,需要及时更新文档。
另外,当修改了测试用例的优先级,或者添加了使用场景或功能测试用例时,也需要及时更新这两个文档。
设计评审
从软件测试的视角看,设计评审非常重要,通过全面评审软件设计内容,可以在软件开发的早期发现一些潜在与性能和安全性有关的缺陷。
如果这些缺陷在编面阶段才被发现,则修正缺陷耗费的时间将比设计阶段修改缺陷大得多。
详细而言,设计评审有助于确保下列问题:
软件设计符合功能规格说明和软件需求的全部内容;
确保软件设计符合全部性能目标;
软件设计考虑了应用程序在不同的布署场景时的全部安全性;
软件设计遵守了程序耦合和内聚、一致性、通讯、类设计、异常管理、资源管理、缓冲区等的代码编写格式要求,以便开发人员可以方便地扩展和定制软件。
软件设计遵守了国际化和本地化有关的指导准则。
此外,软件设计评审还要确保软件能够正确处理可能的安全攻击、性能优化和内存泄漏的问题。
实现编码评审
在实现编码评审阶段,从详细测试计划文档中执行测试用例,对软件的代码进行审阅,这是软件单元测试的重要步骤。
通过代码评审,可以在软件开发的早期发现问题。
具体地,实现代码评审有助于确保下列问题:
软件代码遵守了软件需求文档的要求;
软件的类命名、变量、方法名等代码元素遵守了命名规范;
软件代码在合适位置包含了有助于其他开发人员正确理解的注释语句;
软件代码可以正确处理与性能、扩展性、安全性有关的问题;
软件代码对异常管理和内存分配有关的资源管理能正确处理;
软件代码考虑了软件国际化和本地化有关的问题;
软件不包含冗余的从来不被调用的代码。
此外,实现代码评审还要确保软件能够正确处理边界条件、特殊输入、可能的安全攻击、性能优化、内存泄漏和线程安全等问题。
执行白盒测试
白盒测试执行详细测试计划中与白盒测试有关的测试用例,通过分析软件代码的内部工作方式和程序逻辑结构,寻找软件存在的缺陷。
分析源程序编码,确定测试不公API和测试代码路径所需要的输入数据,并且更新测试计划。
白盒测试包括以下内容:
剖析应用程序在运行时某些特殊代码的行为特征,包括代码覆盖、内存分配、竞争和死锁(Deadlock)问题;
跟踪代码路径分析与关键性能的相关的时间占用,对于基于Web的应用程序,还需要监视请求的执行时间;
测试程序的内部分支路径,确保每个路径正确处理数据,返回期望的输出,而不会引起功能损失或不一致;
测试不同的循环和条件语句,例如简单循环、嵌套循环,关系表达式、简单条件、符合条件、布尔表达式,保证代码组建的精度要求;
安全性测试。
如果软件某段代码在目标布署环境存在安全访问为题,应该分析对应的处理安全性的代码,避免程序向攻击者暴露敏感信息。
执行黑盒测试
黑盒测试执行详细测试计划中与黑盒测试有关的测试用例,黑河测试不需要测试者了解程序的内部结构,而主要模拟终端用户的操作方式。
您可能感兴趣的文章
常用的功能测试方法
功能测试中故障模型的建立
常用的网站功能测试方法
功能测试中故障模型的建立
黑盒测试(Black-boxTesting,又称为功能测试或数据驱动测试)是把测试对象看作一个黑盒子。
利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。
采用黑盒技术设计测试用例的方法有:
等价类划分、边界值分析、错误推测、因果图和综合策略。
黑盒测试注重于测试软件的功能性需求,也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。
黑盒测试并不是白盒测试的替代品,而是用于辅助白盒测试发现其他类型的错误。
黑盒测试试图发现以下类型的错误:
1)功能错误或遗漏;
2)界面错误;
3)数据结构或外部数据库访问错误;
4)性能错误;
5)初始化和终止错误。
一、黑盒测试的测试用例设计方法
·等价类划分方法
·边界值分析方法
·错误推测方法
·因果图方法
·判定表驱动分析方法
·正交实验设计方法
·功能图分析方法
等价类划分:
是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.
1)划分等价类:
等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:
测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:
有效等价类和无效等价类.
有效等价类:
是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.
无效等价类:
与有效等价类的定义恰巧相反.
设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.
2)划分等价类的方法:
下面给出六条确定等价类的原则.
①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.
③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.
④在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.
⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则).
⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.
3)设计测试用例:
在确立了等价类后,可建立等价类表,列出所有划分出的等价类:
输入条件有效等价类无效等价类
然后从划分出的等价类中按以下三个原则设计测试用例:
①为每一个等价类规定一个唯一的编号.
②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.
③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.
边界值分析法
边界值分析方法是对等价类划分方法的补充.
(1)边界值分析方法的考虑:
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
(2)基于边界值分析方法选择测试用例的原则:
1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.
2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.
3)根据规格说明的每个输出条件,使用前面的原则1).
4)根据规格说明的每个输出条件,应用前面的原则2).
5)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.
6)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.
7)分析规格说明,找出其它可能的边界条件.
错误推测法
错误推测法:
基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.
错误推测方法的基本思想:
列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例.例如,在单元测试时曾列出的许多在模块中常见的错误.以前产品测试中曾经发现的错误等,这些就是经验的总结.还有,输入数据和输出数据为0的情况.输入表格为空格或输入表格只有一行.这些都是容易发生错误的情况.可选择这些情况下的例子作为测试用例.
因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等.考虑输入条件之间的相互组合,可能会产生一些新的情况.但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多.因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例.这就需要利用因果图(逻辑模型).
故障模型是软件测试的基础,也是一个判断测试方法是否成熟的重要标志。
在测试的过程中,要确保每一个目标状态都被测试,那么测试必须是系统的;为了最终定位软件缺陷,所以测试必须是集中的;测试需要使用大量的测试用例和重复性测试,因此测试必须是自动的。
若要满足上述三个测试条件,我们必须建立故障模型。
故障模型是将测试人员的经验和直觉尽量归纳和固化,使得可以重复使用。
测试人员通过理解软件在做什么,来猜测可能出错的地方,并应用故障模型有目的地使它暴露缺陷。
它具有一定的形式和足够的信息对错误进行预测,因此对测试人员来说,构造一个准确的故障模型,是选择测试策略、设计测试用例和测试执行的基础。
在建立故障模型时,希望故障模型在框架上是通用的,但是建立具体的故障模型时一定要针对具体的软件类型、应用环境、甚至开发工具才有意义。
一个成熟的故障模型必须具备下列条件:
1)该模型是符合实际的:
大多数系统中存在的故障都可以用该模型来表示;
2)模型下的故障个数是可容忍的:
模型下的故障个数一般和系统的规模是成线性关系;
3)模型下的故障是可以测试的:
存在一个算法,利用该算法可以检测模型中的每一个故障。
本文将从软件的功能和技术特点出发,如软件的输入、输出、数据以及处理等,分析在软件功能测试过程中,我们通常应建立的故障模型及按照故障模型所提供的缺陷类型寻找尽量多的缺陷。
2.输入型故障模型
主要是对用户的各种输入进行建模,因为用户的输入是无法预期的,可能的组合状态也是千变万化。
软件功能除了能让正确的输入得到正确的输出之外,还必须对非法和不合逻辑的输入进行处理,防止因数据异常造成不可挽回的错误。
典型的建模方法有:
1)使用非法数据:
从输入数据的类型、长度、边界值等方面考虑,测试软件是否允许不正确的输入进入系统并进行处理,是否有错误处理代码,代码是否正确。
2)使用默认值输入:
检测软件中所使用的变量是否初始化,是否将非法数据默认为合法边界内的某个合理值。
3)使用特殊字:
检测软件是否正确处理了特殊字符和数据类型。
4)使用使缓冲区溢出的合法输入:
输入超过允许的最大长度的数据,检测软件是否检查字符串/缓冲区的边界。
5)使用可能产生错误的合法输入组合:
测试多个输入值的组合,确认这些值的组合是否会互相影响而引起软件失效。
6)重复输入相同的合法输入序列:
检测软件是否考虑了循环处理的边界。
3.输出型故障模型
软件的输出通常是最直观也是用户最关注的,输出型故障模型就是从软件输出角度出发,分析造成故障的可能原因。
例如通过一个正确的输入在不同情况下产生不同输出的情况可以对输入和输出的关系进行进一步验证;可采用列举等方法,强制软件产生不符合业务背景知识的无效的输出,从而进行处理,规避不必要的错误;强制修改输出的属性、查看输出结果,测试初始化代码和修改代码是否同步;检查用户界面刷新情况,在不同的操作下测试界面刷新时间是否正确、界面刷新区域计算是否正确。
在大多数的软件中,功能输出的正确与否直接决定了软件实现的好坏,输出型故障模型所覆盖的故障也占有相当大的比例。
因此,我们在测试过程中应建立这种故障模型,从故障结果进行分析,判断造成故障的影响因素。
4.计算型故障模型
对于部分软件程序,常需要进行大量的计算,因此该模型应该尽可能包括关于计算方面的各种错误。
包括变量的定义与使用方面的错误;数据的冗余;数组变量的越界错误;数据类型不匹配的错误;还有数据操作方面错误,包括函数调用参数传递错误、赋值语句错误等。
在建立计算型故障模型的时候,要定义数据并且对这些数据执行各种故障操作,尽可能使模型比较完善。
体现在功能层面上,可以使用非法的操作数和操作符组合来验证计算要求的合法性、强制使计算结果溢出考虑数据结构存储的正确性、同时对数据进行操作检测数据共享性等方法来建立故障模型。
5.流程型故障模型
这是一种程序控制流的故障模型,是对在程序中同样占很大比例的循环结构和分支结构建立的模型。
循环故障主要包括永不循环故障和死循环故障,这主要是由循环条件错误引起的。
循环条件的错误中包括变量错误和运算符错误,在未执行循环之前,循环变量的初值设置出错以致永不循环;进入循环以后,循环变量的值不作修改以致发生死循环。
而分支故障则包括判定条件故障和谓词结构故障,由于判定条件的出错或者变量初值设置错误而导致不执行分支结构;对于进入了分支结构的执行,可能因为谓词的错误而提前退出分支结构。
由此可知,流程型故障模型很可能是由一串连续的故障所组成的。
因此在软件功能测试中,我们可以通过判断软件流程是否正确执行、功能分支是否覆盖全面、循环操作是否正常结束等方法来检测软件流程的正确性。
6.资源型故障模型
资源型故障模型是在文件系统超载、系统介质忙或不可用、介质损坏等情况下,运行被测程序进行测试。
此类故障模型的建立通常需要辅助测试工具进行环境的模拟。
当磁盘负荷到达一定程度或可用物理资源十分有限时,系统进程十分容易进入“死锁”状态或出现不可恢复的错误。
产生死锁的根本原因在于系统提供的资源个数少于并发进程所要求的该类资源数。
显然,由于资源有限,不可能为所有要求资源的进程无限制地提供资源。
但是,可以采用适当的方法,以达到消除或规避“死锁”的目的。
因此判断软件在何种操作下会导致“死锁”以及软件对介质损坏的纠错能力也就变得极其重要。
所以我们应该建立这种故障模型,并给出相应的测试用例。
7.结论
故障模型的建立对于故障定位、故障分析以及生成相应的测试用例是非常有用的。
本文在前人研究的基础上,仅仅从软件功能层面出发,提出了五种常用的故障模型。
而在实际的软件测试工程中,由于软件故障原因的多样性,还有很多故障模型有待于进一步细化和探讨。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 功能 测试 教学 文稿