(计算机软件与理论专业论文)手机功能自动化测试工具的研究与实现.pdf_第1页
(计算机软件与理论专业论文)手机功能自动化测试工具的研究与实现.pdf_第2页
(计算机软件与理论专业论文)手机功能自动化测试工具的研究与实现.pdf_第3页
(计算机软件与理论专业论文)手机功能自动化测试工具的研究与实现.pdf_第4页
(计算机软件与理论专业论文)手机功能自动化测试工具的研究与实现.pdf_第5页
已阅读5页,还剩76页未读 继续免费阅读

(计算机软件与理论专业论文)手机功能自动化测试工具的研究与实现.pdf.pdf 免费下载

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

摘要 摘要 软件测试是伴随着软件的产生而产生的,有了软件的生产和运行就必然有软 件测试。软件测试作为保证软件质量和可靠性的关键技术,正日益受到广泛的重 视。随着软件工程规模越来越大,开发效率越来越高,客户对软件的质量要求越 来越高,测试的工作量也越来越大。由于很多工程人工测试的工作量太大,同时 还需要额外的时间来培i ) l l 澳l l 试人员,测试工作管理人员急切的需要一个能简单操 作的测试工具来自动完成应用程序的功能性测试。在这些条件下,自动化测试应 运而生。而功能性自动化测试则是需求量最大的自动化测试项目之一。 随着手机使用越来越普及,人们对手机质量要求逐渐提高,手机更新换代的 速度越来越快。手机生产商对手机自动化测试工具的需求越来越紧迫。本文将根 据这些技术的发展而展开讨论。 本文首先介绍了软件测试的基本理论,包括软件测试的产生、发展,软件测试 的原则和策略、测试的过程模型以及对软件错误的定义和分级控制等等;同时, 介绍了软件功能测试的常用技术黑盒测试的主要测试用例设计技术;然后对 自动化测试的关键技术进行了分析说明,包括脚本的编写,执行原理,以及测试 结果的表示形式等,对手机的自动化测试方式与普通的人工软件测试方式作了比 较和分析。 而后,设计并实现了手机用功能自动化测试工具。该工具能够人工、半人工或 全自动的生成测试脚本,并具有用户权限分级、灵活的参数设置、断点控制、配 置管理等特点;还可以自动生成、执行测试计划,最终自动生成测试结果以及测 试日志并进行存储;最后论文对一些常用情况进行了示例及总结。 关键词:软件测试,测试用例,自动化测试,测试脚本 a b s t r a c t 。 jn e 鲥撕a r et e s tw a st h ec e n a j n o c c u 玎e da 矗e rs o f t w a r e d e v e l o p m e n l n c s 竺! = ? 伦c h n 0 1 9 9 y ,a s t h ek c yt e c h n o l o g yt 。e n s u r c t h es 0 f t w a e q u a l i t y a n d 二:1 a m l y ,b e c 0 啪e s m o r ca n dm 。r ei m p o r t a n l w h i l et h es o f 晰a r e p r 0 1 j e c l q l - b e c 0 咖e s ? 昭旺t h e q u a l i t y r e q u 渤e n t s 疗0 md i e , i t sb e c o m e sh i d e r ,t h e 蚴c u j t 0 fl e s t d e c o m e s ? 1 9 9 e l f 研s h o n e no f h u m a n e s o u r c e s ,t h el a c ko f t r a i n i n gt i m e ,w en e e dl h e a u 0 m a e d l c s i o o l h e l pu st of i n i s hl h ef b n c t j 0 i l a lt e s t a u l o m a t i c a l l y u n d e rl b j s s i t u a t i o n , 1 h e a u l 咖a f e dl e s tt 0 0 lo c c u l t e d b dl h e 如n c t i o n a l a u t o m a t e dt e s ti s0 n e0 f 1 em o s l j m p o r t a n tt e s tp 0 j e c t s 舢l j l em m a n dm 眦p o p u l a ru s eo f m o b i l e ,p e o p l eb e c o m ef o c u s 明t b eq u a 脚 o ft h e m b u t t h ea p p e a r a n c e0 f t h 啪n e n e e do fa u t o m a t e dt e s t 咖l 。fm 。b i l cb e 二咖三 a o s o l u t e l yn e 汹a n ”k p a p e rw a sj u s l sb a s e do nt h e s et h e o f i e s n ? 。o f 甜l 啦e p a p e r 如r o d u c e dt h eb a s j “h e o 珂o f s o r w a r ct e s t i n i i l c l u d i n gt j l e 篡:l 玎e d 、d e v e l 叩洒岛龇p r i n c i p l e a n ds 胁l e g yo fs o f t w a r et e s t i n t h e t e s tm o d 孟o f t e s t j n gp r o c e s s ;m e a nw h i l e , i ti n t r o d u c e dt h eb a s j c l e s lt e c h n 0 1 0 9 y s u c h 弱b l a c kb o x t e s t , w h i t e b o xt e s ta n ds 0 伽t h e n ,t h e p a p e a n a l y z e dt h ek e yt e c h n o l o g y0 f 卸? 射e d 伧巩i 1 1 d u d 汤g e d i tt c s ts c r i p t 、e x e c u t et e s t s 喇p ta l l dl h er c c o 柑i n g 二t e s t r e s u j t ,c 0 瑚p 撕n gl h ed j f f e r e n tb e 觚e e nm o b i l ea u t o m a t e d t e s t 卸dt r a d j t j 咖a lm 。a n u a l l y a tl a s t d 湖印如di m p l e m e n t t h em o b i l ef u n c l i o n a l a u l o m a t e dl e s t t 0 0 1 n i s 柳a 他c 卸? 卸u a l h a l f m a n u a l o ra u r o r a a t i c a i l yg e n e r a l el e s l 刚p t ,s u p p c n u s e r c l a s s i f i e d , 柚dh a s 玎c x j b j e p a r a m e t e rs e t t i n g 、b f e a k p o i n l s e l l j n g 、c 0 i 基g l l 髓t i 鲫 m a ? g e m e n t 如n 嘶0 n s 1 l a l s 0c a n a u t o m a t e de x e c u t e t j l et e s t p l a n ,柚dg e n e r a t e 。t h et e s t ? s u l t :n d t e s t1 0 9 r 肋y ,s o m ec x a m p l e sa r c g i v e nt oe x p 】a i l ls 。m ec 0 m m 。nu o f k e y 删s :s o 脚a 他l e s t i n g ,l e s tc a s c ,a u l o m a e s t ,t e s t 卿 豇 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的研 究成果。据我所知,除了文中特别加以标注和致谢的地方外,论文中不包含其他 人已经发表或撰写过的研究成果,也不包含为获得电子科技大学或其它教育机构 的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均 已在论文中作了明确的说明并表示谢意。 签名:j 盘要l 日期:夕年占月j 日 关于论文使用授权的说明 本学位论文作者完全了解电子科技大学有关保留、使用学位论文 的规定,有权保留并向国家有关部门或机构送交论文的复印件和磁盘, 允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文的全 部或部分内容编入有关数据库进行检索,可以采用影印、缩印或扫描 等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后应遵守此规定) 签名:j 垃导师签名:至堕氢、 日期:呻年z 月 第一章引言 1 1 研究背景 第一章引言 软件测试是伴随着软件的产生而产生的,有了软件生产和运行就必然有软件 测试。 软件测试是软件开发过程中一个至关重要的环节,是直接影响软件的质量, 保证软件可靠性的重要方法之一,怎样及时地发现软件开发过程中的错误,是软 件测试要的工作任务。正因为如此,测试阶段占用的时间、花费的人力资源和资 金成本占软件开发的比重很大。近期一份美国国家标准技术所( n i s t ) 的报告表示, 正是由于软件的失效导致每年美国经济损失5 9 9 亿美元。从软件开发当前的技术 发展程度而言,我们无法让软件完全避免错误发生,因此该报告同时指出,如果 进行有效的软件测试,每年将可以减少2 2 0 亿美元的因软件失效而引起的开销n 叫羽。 在早期的软件开发过程中,测试的含义比较狭窄,将测试等同于“调试”,目 的是纠正软件中已经知道的故障,常常由开发人员自己完成这份工作。对测试的 投入极少,测试工作的介入也较晚,常常是等到形成代码,产品已经基本完成时 才进行测试。这个时期的软件测试,还不是我们今天严格意义的“测试 工作。 直到1 9 5 7 年,软件测试才开始与调试区别开来,成为一种发现软件缺陷的活 动。1 9 7 9 年,软件测试领域的第一本最重要的专著、g l e nf b r dm y e r s 的软件测 试的艺术( t h ea r to fs o f t w a r et e s t i n g ) 对软件测试下的定义是:“测试是为发现 错误而执行的一个程序或者系统过程一。该专著的问世是一个重要的里程碑,它 把软件测试从传统的“调试 思维中解放出来。 2 0 世纪8 0 年代早期,对软件“质量 的品质要求提上重要日程,带来软件测 试定义也发生了改变。测试不再单纯仅是一个发现错误的过程,它已经掺柔进了 软件质量评价的内容。这时,软件开发人员和测试人员开始坐在一起共同探讨软 件工程和测试问题。b i l lh e t z e l 在1 9 8 3 年软件测试完全指南( c o m p l e t eg u i d eo f s o f t w a r e t e s t i n g ) 一书中提出:“测试是以评价一个程序或者系统属性为目标的任 何一种活动,测试是对软件质量的度量。m y e r s 和h e r z e l 奠定了以后软件测试 的重要地位,他们对软件测试的定义至今仍然被引用。 进入2 0 世纪9 0 年代,软件测试工具终于盛行起来。人们普遍意识到测试工具 电子科技大学硕士学位论文 不仅是有用的,而且要对今天的软件系统进行充分的测试,工具是必不可少的。 2 0 0 2 年,r i c k 和s t e f a n 在系统的软件测试( s y s t e m a t i cs o f t w a r et e s t i n g ) 一书 中对软件测试进一步定义为:“测试是为了度量和提高被测软件的质量,对测试软 件进行工程设计、实施和维护的整个生命周期过程 。 从五十年代以来,一代代前辈专家学者们为软件测试研究的理论化和体系化 的努力及作出的巨大贡献和影响n 习。是本人从事本课题研究的重要理论基础和前 提。 1 2 国内外现状旧 目前在软件比较发达的欧美国家,软件钡4 试已经发展成为一个独立的产业,主 要体现在以下几个方面: 1 软件测试在软件公司中占有重要的地位。一个典型的开发项目组中测试工 程师可能比编码工程师多的多,并且花费在测试上的时间要比花费在编码上的时 间多的多。 2 软件测试理论研究蓬勃发展,每年举办各种各样的测试技术年会,发表了 大量的软件测试研究论文,引领软件测试理论研究的国际潮流。 3 软件测试市场繁荣。美国有一些专业公司开发软件测试标准与测试工具, m i 、c o m p u w a r e 、w a c a b e 、r a t i o n a l 等都是著名的软件测试工具提供商,它们出 品的测试工具已经占领了国际市场。 目前在国际上,软件测试及测试管理相关领域的工具开发己经成为软件产业 中的一个独特市场,软件测试管理的理论已经逐步形成和完善,测试管理工具的 开发和使用己经相当普遍。国外的很多知名公司已经开发出比较成熟稳定的测试 管理产品。目前国际上比较有代表性的软件测试管理工具主要有: r a i d s 。m i c r o s o f t 公司的r a i d s 是专注于软件缺陷管理的工具。 r a t i o n a l t e s t m a n a g e r 。i b m 公司的t e s t m a n a g e r 提供了一个软件测试管理的核 心平台,提供开放、可扩展的测试管理。 r a t i o n a l f u n c t i o n a l t e s t e r 。同样由i b m 公司开发。对j a v a 、w e b 和基于v s n e t w i n f o r m 的应用程序进行高级自动化功能测试。 t e s t d i r c c t o r 。m e r c u r yi n t e r a c t i v e ( m i ) 公司的t e s t d i r e c t o r 是业界第一个基于 w e b 的测试管理工具,它能够帮助客户对软件测试过程的每一个阶段进行组织和 管理。包括测试需求定义、测试计划、测试执行和缺陷跟踪。 2 第一章引言 q a d i r e c t o r 。c o m p u w a r e 公司的q a d i r e c t o r 管理工具主要支持自动化测试, 在新的6 0 版本中项目组人员还可以发布需求并与测试管理资产同步进行。嘲 但是这些工具都不太适用于嵌入式自动化测试。嵌入式测试由于待测系统平 台的多样性,很难有一种自动化测试工具能直接使用,常常需要针对待测系统软 件平台进行二次开发,这就需要提供测试工具的公司进行专门的人员培训,甚至 较长时间的定制开发,对人力资源和费用要求都比较大。因此,适用于嵌入式测 试的自动化测试工具并不多,而适用于手机的基于功能性的自动化测试工具在市 场上则更加的稀少。 目前在手机自动化测试方面较专业的公司为t e s t q u e s t 。它是一家移动设备和 应用软件自动化测试和管理解决方案提供商,提供了一种自动测试平台名字叫做 c o u n t d o w n 。这是一个终极化的适用非常广泛的自动测试系统的平台。c o u n t d o w n 的自动测试系统是一个模块化的设计,它包括开发工具,叫做t e s t d e s i g n e r ,和运 行测试的工具t e s t r u n n e r ,与测试管理的工具。t e s t o u e s t 可以根据不同客户的不 同需要,分别安装在不同的地点。它为客户定制测试平台,采用分布式的管理开 发方式。c o u n t d o w n 测试平台功能完善,但是和上面介绍的大多数主流测试工具 一样,它也具有下述这些局限性: 1 易用度较低,系统过于复杂庞大,测试人员需要经过长时间的培训、花费 大量的时间、公司需承担高昂的培训费用才能掌握系统的大多数功能。 2 对权限角色管理支持不够,增加了系统管理人员的工作量。 3 测试用例的版本控制较差,不能很好的对测试用例版本进行安全有效的管 理维护。 4 一般常用的自动化测试工具并没有提供对基本功能和系统功能测试用例 的自动化生成模块,需要人工对这些测试用例进行编辑。 5 再加上这些工具主要提供英文版本,本地化程度不够,同时价格比较昂贵, 不利于在国内众多中小型软件企业中普及应用。 在我国,软件测试技术的研究起步于八十年代,它主要是随着软件工程的研究 而逐步发展起来的。由于起步较晚,无论是在软件测试理论研究还是在测试实践 上,与国际先进水平相比相差较大。这种差别主要从三个方面表现得最为明显: 一是对软件产品化测试的技术研究贫乏,二是从业人员较少,三是测试服务没有 足够的规模。但也应看到,随着我国软件产业的蓬勃发展以及对软件质量的重视, 软件测试也越来越被人们所看重,软件测试正在逐步成为一个新兴的产业,我国 软件测试的“春天 正在到来,一个真正意义上的“测试时代一正在向我们走来。 3 电子科技大学硕士学位论文 1 3 论文的主要工作 1 对软件测试技术进行分析和概括。 2 对软件的自动化测试和手机的自动化测试进行分析,提出了手机自动化测 试的特殊性。 3 本人参与了自动化测试工具开发项目全部的设计与开发过程,深入系统地 研究了自动化工具架构、基本功能的确定、测试计划的自动生成、测试结果输出 等等技术。分析了现有自动化测试工具的特点,结合项目的需求,设计并实现了 手机自动化测试工具,搭建部署了一套自动化测试平台。 1 4 论文的章节安排 论文一共分为七章。 第一章,引言。介绍软件测试的背景,分析国内外软件测试的发展情况,简述 论文的主要工作。 第二章,软件测试相关概念。介绍软件测试的概念,软件测试的过程模型以及 对软件错误的定义与分级。 第三章,软件测试技术的研究。介绍测试用例的设计方法。 第四章,功能自动化测试关键技术分析。为了更好的设计手机自动化测试工具, 对常见的自动化测试原理和步骤进行了详细的分析。 第五章,手机功能自动化测试工具设计与实现。分析、设计与实现一个基于手 机功能测试的自动化测试工具。 第六章,手机功能自动化测试工具的应用。对自动化工具的常用领域和常用模 块进行说明。 第七章,结论。对本文的工作进行总结,并对下一步工作进行展望。 4 第二章软件测试相关概念 第二章软件测试相关概念 2 1 软件测试的目的圆 早期的软件定义指出软件测试的目的是寻找错误,并且尽最大的可能找出更多 的错误。 g r e n f o r dj m y e r s 就软件测试目的提出了以下观点。 1 测试是程序的执行过程,目的在于发现错误。 2 一个好的测试用例在于能发现至今未发现的错误。 3 一个成功的测试是发现了至今未发现的错误的测试。 而b i l lh e t z e l 提出了以下观点: 测试目的不仅仅是为了发现软件缺陷与错误,而且更能够对软件质量进行度 量和评估,以提高软件的质量。 通过他们的启示和测试工作的发展,现在我们可以归纳软件测试的目的有以 下几点: 1 以最少的人力、物力和时间资源找出最多的软件错误。 2 通过发现错误和修正错误来规避潜在的软件风险。 3 找出软件中潜在的各种错误和缺陷,通过修正错误和缺陷来提高软件质 量。 4 评价和度量软件的质量。验证软件满足需求的程度。 5 向开发人员、用户提供测试结果,错误和缺陷的数量,对测试结果进行整 理和分析,帮助开发人员和用户更好的了解软件的开发进程。 6 进行验收测试以保证用户使用软件的正确性。树立用户对软件的信心。 2 2 软件测试的原则 1 所有的软件测试都应该基于用户需求。 所有的软件测试都应该与用户的需求说明书结合起来,测试人员应当从需求 说明书中寻找客户需求和软件应该实现的功能。尽可能多的找出软件不符合需求 说明书规定内容的错误。 5 电子科技大学硕士学位论文 2 应当尽早地和不断地进行软件测试。 测试介入的越早对开发就越有利。由于软件的开发是连续不断的进行的,在 软件的各个生命周期都可能出现错误,因此软件测试要从软件的需求阶段就开始 介入,尽可能早的发现问题。 3 开发人员应避免检查自己的程序。 由于思维定向开发人员总是很难在自己的程序代码中发现自己的错误或者基 于心里因素他们倾向于认为自己所开发的程序没有错误。因此,为了达到软件测 试的目的和要求,应该尽可能让第三方介入进行软件测试。第三方测试能够很好 的以专业化跟光进行测试。第三方的选择可以包括非测试模块的开发人员、独立 的测试组、独立的测试机构等等。 4 测试需要适时终止 测试也是有成本的,越是到测试后期,可能要投入大量的时间和资源才能发 现少量的非致命性错误,测试所付出的代价太大。因此需要有根据的管理人员根 据项目进度和错误的发现曲线适时的停止测试。 5 充分注意测试中的群集现象。 应当对错误的高发模块进行重点测试,通常发现错误较多的模块残存错误也 很多。开发人员在修改错误较多的模块时可能会引入更多的错误,并且这些错误 可能由类似的操作引起,群集于某一个程序段,因此应该投入更多的资源进行测 试。 2 3 软件测试的分类7 。锄 2 3 1 按照开发阶段划分 按照开发阶段划分软件测试可以分为:单元测试、集成测试、系统测试、确认 测试和验收测试。 1 单元测试 单元测试的目的在于检查每个程序单元能否正确实现详细设计说明书中的模 块设计要求,发现各程序段内部可能存在的各种错误。单元测试需要从程序的内 部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。 2 集成测试 单元测试完成之后就应该进行集成测试。 6 第二章软件测试相关概念 集成测试的目的是根据概要设计的要求检验软件上下模块的接口关系,再逐 步集成整个系统。 根据待测软件系统的大小可以选择不同的集成策略。对于较小的系统来说不 必选择累积型测试,只需要一次性的将所有模块集成在一起整体进行测试,这种 方式通常称为b i gb a n gt e s t i n g 。 对于规模较大的待测系统来说就需要选择合适的累积型策略了,因为对于大 型系统再想使用一次性整体测试的话测试效果会非常差。某个底层模块的错误可 能会引发整个系统的崩溃,导致测试无法继续下去。累积型的集成测试策略主要 有以下几种: ( 1 ) 自顶向下( t o pd o w ni n t e g r a t i o n ) ( 2 ) 自底向上( b o t t o mu pi n t e g r a t i o n ) ( 3 ) 层次集成( s a n d w i c hi n t e g r a t i o n ) ( 4 ) 临界模块优先( c r i t i c a lm o d u l e sf i r s t ) 3 确认测试 确认测试的目的是检测软件是否满足软件需求说明书中规定的要求,是否实 现用户要求的软件功能。 4 系统测试 系统测试包括系统的功能测试、性能测试以及压力测试等。按照需求说明书 对每个功能的实现正确与否进行测试。 5 验收测试 验收测试一般由客户实施,客户依照项目合同的条款对整个系统进行测试。 判定系统是否满足要求,是否决定接收。 2 3 2 按照测试实施组织划分 根据实施组织的不同软件测试可以分为a 测试、用户测试( 测试) 和第三 方测试。 1 口测试 口测试通常由开发方和没有开发经验的用户一起执行。口测试的关键是尽最 大程度的模拟软件的真实工作环境,让真实的用户对软件进行操作口测试由开 发人员协助普通用户在开发环境进行,它没有确定的测试用例,完全由用户按照 自己的使用习惯对软件进行操作。 7 电子科技大学硕士学位论文 2 用户测试 用户测试通常也称卢测试。卢测试在软件已经正常发布后进行,由真正的用 户进行使用,卢测试的参与用户在遇到软件发生错误的时候会被要求向开发公司 发送错误报告,错误报告包括出错记录、用户的软硬件环境信息等等。软件开发 公司对这些信息进行收集和分析,然后再次对软件进行修改。 3 第三方测试 第三方测试通常也称为独立测试。第三方测试由非开发方的专业机构进行, 对软件品质进行独立的测试盒认证。第三方测试一般在软件的真实运行环境中进 行,由第三方机构模拟用户操作软件,对软件的质量进行评估最后将测试结果交 付开发方和用户。 2 3 3 按照测试技术划分 根据是否源程序可见,软件测试按照测试技术可以划分为白盒、黑盒和灰盒 测试。下面将对这三类测试进行简单介绍。 1 黑盒测试 黑盒测试也叫做功能测试,黑盒测试方法把测试对象看成一个完全的黑盒子, 只考虑程序的外部表现而完全不关心程序的内部实现、接口关系和逻辑结构。黑 盒测试在软件的u i 上进行,完全依照需求说明书来实施测试。由于黑盒测试主要 关注软件的功能实现,所以称为功能测试。系统的功能测试通常使用黑盒测试技 术,第三章将会对黑盒测试技术进行较为详细的介绍。 黑盒测试的目的在于试图寻找下列几类错误: ( 1 ) 错误的或者是遗漏的功能 ( u i 错误 ( 3 ) 数据库接口错误 ( 4 ) 性能缺陷 ( 5 ) 初始化错误 2 白盒测试 白盒测试也叫做逻辑驱动测试或者结构测试。与黑盒测试相比,白盒测试关 注的是盒子中的内容。它主要关注程序的实现过程,逻辑原理,接口实现,参数 定义等等。白盒测试按照逻辑驱动,对软件的实现路径进行检查,找出所有结构 及路径中的错误。 8 第二章软件测试相关概念 自盒测试的方法通常有代码检测、静态结构分析、覆盖法、基本路径测试、 符号测试、z 路径测试等等。 白盒测试期望能够达到这样的测试覆盖度: ( 1 ) 覆盖所有的独立路径; ( 2 ) 覆盖所有的逻辑判断; ( 3 ) 覆盖所有的循环和内部结构。 3 灰盒测试 灰盒测试时介于白盒测试与黑盒测试之间的测试。灰盒测试同时关注软件的 外部表现和内部实现。灰盒测试主要是对于白盒测试的补充。当一个程序内部出 现问题时外部输出可能是正确的,面对这种情况就需要进行灰盒测试来提高测试 效率。 根据是否运行程序可见,软件测试按照测试技术又可以划分为静态测试和动 态测试。下面对这两类测试进行简单介绍。 1 静态测试技术 静态测试顾名思义是指不运行源程序所进行的测试。它由人工或内存泄漏等 自动化测试工具进行测试。静态测试主要对源程序的语义语法、结构过程、接口 实现等进行静态分析,包括走查、需求确认等等方式。 2 动态测试技术 动态测试就是通过运行软件、对运行结果进行检测来进行测试。动态测试是 最常用的测试技术。 软件测试技术的分类与软件开发过程紧密相关,在测试的不同阶段使用不同 的测试技术。例如文档和源程序的开发可以应用走查的方法;单元测试可应用白 盒测试方法;集成测试应用灰盒测试方法;而系统测试和验收测试则应用黑盒测 试方法。 2 4 软件测试过程模型嘲伽 在软件开发几十年的实践过程中,软件测试专家通过测试实践总结出了很多 很好的测试模型。在这些测试模型中也都把开发过程进行了很好的总结,体现了 测试与开发的相互结合,下面对主要的模型做简单的介绍。 9 电子科技大学硕士学位论文 2 4 1v 模型 v 模型是最具有代表意义的测试模型,如图2 1 所示。v 模型最早是由p a u l r o o k 在2 0 世纪8 0 年代后期提出的,v 模型在英国国家计算机中心文献中发布, 旨在改进软件开发的效率和效果。v 模型中的过程从左到右,描述了基本的开发 过程和测试行为。 在传统的开发模型( 比如瀑布模型) 中,人们通常把测试过程作为在开发工 作全部完成之后的一个阶段。尽管测试工作有时会占用整个项目周期一半的时间, 但是有人仍然认为测试只是一个收尾工作,而不是主要过程。v 模型的推出就是 对这种认识的改进。 v 模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清 楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。 图2 1 软件测试v 模型 在v 模型中,单元测试最初由开发人员执行,验证代码的正确性。 集成测试根据详细设计说明书验证模块的集成是否正确。 系统测试验证软件的功能是否达到概要设计的要求。 验收测试由第三方测试机构或者客户以真实的运行环境模拟用户操作,确定 是否接收软件。 1 0 第二章软件测试相关概念 v 模型存在一定的局限性,它容易使人将测试理解为是软件开发的最后一个 阶段,很有可能需求分析阶段隐藏的问题一直到后期的验收测试才被发现,此时 再对错误进行修改投入会非常的巨大,甚至影响整个系统的交付。 2 4 2w 模型 v 模型的局限性在于没有体现“尽早地和不断地进行软件测试”原则。一种新 的测试模型在v 模型中增加了对应软件各开发阶段应同步进行的测试,这就是w 模型,因为开发是“v 模型,对应的测试阶段也应该是“v 模型。w 模型如图 2 2 所示。 w 模型由w v o l u t i f 公司提出。它主张测试应该在软件的这个开发周期中与开 发并行。测试的对象不应该仅仅是程序,还包括需求和设计。测试与开发同步进 行,能够更早的发现问题。 图2 - 2 软件测试w 模型 w 模型也是有局限性的。w 模型和v 模型都把软件的开发和测试定义为一种 线性的前后关系,当上一阶段结束并且有明显标志时,才能开始下一阶段的测试 工作。 电子科技大学硕士学位论文 2 4 3h 模型 2 4 1 和2 4 2 中所介绍的v 模型和w 模型均存在一些局限性。它们都把软件 的开发视为需求、设计、编码等一系列串行的活动。 事实上,这些活动常常是可以交叉进行的,相应的测试之间不应该存在严格 的先后关系和触发要求。同时,这些活动间的相互关系还应该是反复触发、迭代 的。为了将软件测试活动完全独立出来,有专家提出了h 模型。h 模型将测试活 动描述为一个完全独立的流程,如图2 3 所示。 ,;7 :二 ,_ 1 1 :l 黼程蝴勰y l l ”“”。1 3 “”“1 0 l i_-_l-_-_-_-_-_-, 图2 - 3 软件测试h 模型 图2 3 演示的是在软件开发某一个阶段的测试过程。在整个软件开发中,这样 的循环可以多次出现。不管目前软件开发处于什么阶段,只要测试的准备条件完 成,测试就可以开始了。 h 模型充分强调了软件测试的独立性,体现了软件测试要尽早准备,尽快执 行的原理。测试活动可以根据需要反复、迭代的执行,不受开发过程的影响。只 要到达了测试就绪点,就可以开始测试。 2 4 4x 模型 由于v 模型表现出测试无法引导项目的全部过程的缺陷,引起了一些对于v 模型的质疑。m a r i c k 曾提出过一些观点和意见,他担心人们盲目的按照v 模型进 行测试活动会导致不切实际的做法。根据这些想法,m a r i c k 在引用了经过v 模型 的基础上重新组织设计提出了“x 模型 。x 模型提出了一种新的测试活动 探索性测试。x 模型如图2 - 4 所示。 1 2 第二章软件测试相关概念 x 通常代表未知,而m a r i c k 也认为他的观点并不足以支撑一个模型的完整描 述,但其中已经有一个模型所需要的一些主要内容,其中也包括了像探索性测试 ( e x p l o r a t o r yt e s t i n g ) 这样的亮点。 2 4 5 前置测试模型 图2 - 4 软件测试x 模型 前置测试模型是由r o b i nf g o l d s m i t h 和他的伙伴们提出的,它是一个将测试 和开发紧密结合的模型,该模型提供非常详细的测试模式,可以使项目加快速度。 前置测试模型如图2 5 所示。 前置测试模型体现了以下特点: 1 测试和开发相结合。 前置测试模型标识了项目生命周期从开始到结束之间所有的关键行为,完全 将开发和测试的活动周期整合在了一起。 前置测试模型对这些关键行为进行了描述,评价行为在项目周期中的价值。 关键行为是否被正确的执行会影响到项目是否成功。前置测试模型提出了可行性 报告、业务需求说明、文档设计、非正式走查等新的测试理念,坚持由业务指导 来完成软件的测试活动。 2 对每一个结果进行测试。 1 3 电子科技大学硕士学位论文 图2 5 前置测试模型 开发过程的每一个阶段都会有一个开发结果。必须针对每一个开发结果进行 测试。除了源代码,还需要对各种设计文档、需求文档、开发、测试计划进行测 试。在图中的椭圆形表示了一些要测试的对象,比如可行性报告、业务需求说明, 以及系统设计文档等。 3 在项目设计阶段对测试进行计划和设计。 盲目匆忙的投入到测试活动中会影响整个系统的测试结果。如果在项目开始 之后立即进入测试阶段,没有任何的测试根据,这将会影响测试的执行效果,很 多原本不满足需求的缺陷可能无法被找到。 因此我们需要在项目的设计阶段就启用测试设计。测试的计划和设计需要设 计人员耐心的参阅需求说明书进行分析,并且对每个测试任务应该就绪和完成的 时间有一个大体的规划。 4 测试和开发结合。 前置测试将测试执行和开发结合在一起,并在开发阶段采用“编码一测试 编码一测试 的方式。 1 4 第二章软件测试相关概念 同w 模型的原则相似,前置测试模型也强调当一段程序开发完成之后,就应 该立刻进行测试。同样,我们还可以根据x 模型,在每一段程序开发完成之后都 进行完整的测试活动,包括单元测试、集成测试、系统测试等等。在测试执行的 过程中可能另外又有一些程序片段被开发完成,相应的测试活动又可以在这些程 序片段上与开发交叉展开。 5 验收测试和技术测试保持相互独立。 验收测试和技术测试应该保持相互独立,前置测试模型甚至提倡验收测试和 技术测试完全按照两条不同的测试线路来实施,这样就像为项目施加了双重保险 一样,对设计和程序代码都进行测试。 技术测试应该一直同开发相结合,甚至可以反复的交替进行开发和测试,而 验收测试同样可以与开发阶段相结合,以保证开发的每一个阶段都能够严格按照 需求设计来执行。 前面介绍的几种测试模型对我们在工程项目中实施测试具有很重要的指导作 用。但每一个测试模型都有自己的局限性,并不都是完美的。 v 模型首先将测试活动进行了分级,而且与开发的阶段一一对应。v 模型提 出了测试在不同的阶段有各自的定义和目的。测试并不是开发的附属品,不能在 开发完成之后才进行测试活动。 w 模型是对v 模型的补充和延伸,它考虑到了v 模型所提出的测试活动中并 没有考虑到除了源程序之外,一些开发计划书、需求分析计划书也需要被测试到, 因此w 模型对v 模型进行了扩展,他将测试活动提前到开发的设计阶段,伴随着 开发的整个阶段。 但是w 模型和v 模型都没有将测试看做一个独立的流程,测试的每一个阶段 仍然依附于开发的各个阶段。因此又有人提出了软件测试的h 模型。h 模型将测 试过程分解为不断的微小循环过程,在开发的各个阶段这些微小循环都存在,并 且根据项目需要不断进行更新和迭代。 但是,h 模型提供的仅仅是将测试活动看做一个独立流程的一种测试思路, 并没有对细节进行描述。因此,之后的x 模型以及前置测试模型对h 模型进行了 细节上的描述。x 模型提醒人们不要按部就班的按照模型执行测试工作,它提出 了探索性测试这种新的测试方式,探索性测试是没有计划的特殊测试,它常常能 够取得不错的测试效果,帮助测试人员找出一些意料之外的错误。而前置测试模 型则仔细为人们设想了在项目运行过程中所出现的多种问题,针对这些问题提出 了项目应该要执行的关键行为。 1 5 电子科技大学硕士学位论文 2 5 软件失效分类与管理 2 5 1 相关定义 目前对软件测试测试的定义通常有以下几种: 1 错误( e 1 1 r o o 人类会犯错误。很接近的一个同义词是过错( m i s t a k e ) 。人们在编代码时会出现 过错,我们把这种过错叫做b u g 。错误可能会扩散,需求错误在设计期间有可能被 放大,在编写代码时还会进一步扩大。 2 缺陷( f a u l t ) 缺陷是错误的结果。更精确地说,缺陷是错误的表现,而表现是表示的模式, 例如叙述性文字、数据流框图、层次结构图、源代码等。与缺陷很接近的两个同 义词是“缺点( d e f e c t ) 以及“程序错误 。缺陷可能很难捕获。当设计人员出现遗 漏错误时,所导致的缺陷会是遗漏本来应该在表现中提供的内容。这种情况说明 需要对定义做进一步的细化,借用教堂常用的一个词,我们可以把缺陷分为过错 缺陷和遗漏缺陷。如果把某些信息输入到不正确的表示中,就是过错缺陷;如果 没有输入正确信息,就是遗漏缺陷。在这两类缺陷中,遗漏缺陷更难检测和解决。 3 失效( f a i l u r e ) 当缺陷执行时会发生失效。有两点需要解释:一是失效只出现在可执行的表 现中,通常是源代码,或更确切地说是被装载的目标代码;二是这种定义只与过 错缺陷有关。该如何处理遗漏缺陷对应的失效呢? 把这个问题再向前推进一步: 应该怎样处理在执行中从来不发生,或可能在相当长时间内没有发生的缺陷呢? 米开朗基罗( m i c h a e l a n g e l o ) 病毒就是这种缺陷的一个例子。这种病毒只有到米开朗 基罗3 月6 日的生e t j j b 天才会发作。评审可以通过发现缺陷避免很多失效的发生。 事实上,有效的评审可以找出遗漏缺陷。 4 事故( i n c i d e n t ) 当出现失效时,可能会也可能不会呈现给用户( 或客户或测试人员) 事故说 明出现了与失效类似的情况,警告用户注意所出现的失效。 2 5 2 缺陷与错误严重性和优先级 软件存在的缺陷与错误会带来软件失败的风险,重要软件故障与失效会导致 1 6 第二章软件测试相关概念 重大经济损失与灾难。在报告软件缺陷时,一般要讲明如何处置它们。测试员要 对软件缺陷分类,以简明而要的方式指出其影响,以及修改的优先次序。 1 错误的严重级表示软件缺陷所造成的危害的恶劣程度,严重级分类为: s 级:违反国家安全或者人生安全。 a 级:系统崩溃或者数据损坏。 b 级:功能错误 c 级:u l 错误或者重现率很低的错误。 2 优先级表示修复缺陷的重要程度与次序,优先级分类如下j 最高优先级:立即修复,停止进一步测试。 次高优先级:必须修复,但可以不在这个版本上修复。 中等优先级:如果没有特殊的原因应该修复。 最低等优先级:可能会修复,但是也允许发布。 2 5 3 软件错误跟踪管理 软件测试的主要目的在于发现软件存在的错误( b u g ) ,如何处理测试中发现的 错误,将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误,才能 消除软件错误,保证要发布的软件符合需求设计的目标。在实际的软件测试过程 中,每个b u g 都要经过测试、确认、修复、验证等的管理过程,这是软件测试的 重要环节珀渺3 7 1 1 错误跟踪管理 为了正确地跟踪每个软件错误的处理过程,通常将软件测试发现的每个错误 作为一条记录输入指定的错误跟踪管理系统。 目前已有的错误跟踪管理软件包括c o m p u w a r e 公司的t r a c k r e c o r d 软件, m o z i l l a 公司的b u z i l l a 等。作为一个错误跟踪管理系统,需要正确记录错误信息和 错误处理信息的全部内容。比如一条b u g 记录信息主要包括以下几项内容: ( 1 ) 软件版本号 ( 2 ) 测试人 ( 3 ) 错误概述 ( 4 ) 测试时间 ( 5 ) 错误的重现率 ( 6 ) 发现错误的类型 1 7 电子科技大学硕士学位论文 ( 7 ) 错误的严重等级 ( 8 ) 复现错误的详细步骤 ( 9 ) 必要的附件,如截图,资源文件等 而对b u g 的处理信息主要包括以下内容: ( 1 ) 处理者姓名 ( 2 ) 处理时问 ( 3 ) 错误的产生原因 ( 4 ) 处理步骤 ( 5 ) 错误当前的状态 2 软件错误的状态 软件错误的主要状态包括以下几种: ( 1 ) s u b m i t :新提交的b u g ( 2 ) a s s i g n :已经分发给开发人员处理的b u g ( 3 ) f i x e d :开发人员已经完成修正,等待测试人员验证 ( 4 ) d u p l i c a t e :提交的b u g 与之前的有重复 ( 5 ) r e j e c t :拒绝修改b u g ( 6 ) p o s t p o n e :延期修复 仍c l o s e :b u g 已被修复 ( 8 ) r e o p e n :未被修复b u g 3 错误管理流程 错误管理的参与人应该有项目经理,开发人员和测试人员,对错误的管理流 程必须严格执行,否则很难有效的对项目进行管理,以及对开发、测试人员的绩 效进行评定。错误 图2 - 6 错误管理流程图 1 8 第二章软件测试相关概念 2 6 软件的功能测试 软件的功能测试是在规定的一段时间内运行软件系统的所有功能,以验证这 个软件系统有无严重错误。它属于系统测试里非常重要的一部分,主要应用黑盒 测试技术进行测试,关于黑盒测试技术方法的详细介绍将在第三章进行介绍。 2 7 本章小结 测试的目的,是想以最少的人力、物力和时间找出软件中潜在的各种错误和 缺陷,通过修正各种错误和缺陷提高软件质量,回避软件发布后由于潜在的软件 缺陷和错误造成的隐患所带来的商业风险。 本章介绍了软件测试的相关概念,包括软件测试的目的、原则、分类,详细 分析了软件测试的5 种过程模型,介绍了软件的错误跟踪管理机制。 1 9 电子科技大学硕士学位论文 第三章软件黑盒测试技术的研究 软件的系统功能测试主要使用的就是黑盒测试技术,下面将对黑盒测试技术 的主要测试用例设计方法进行介绍和分析。 3 1 测试用例的设计 软件测试初学者可能认为拿到软件后应该立刻进行测试,并期待能够马上找 出软件的所有缺陷,这种想法就如同走路不稳的小孩急于开始跑步一样。软件测 试是一个工程,我们需要从工程项目的角度去认识它,在实施具体测试之前,测 试人员需要明白测试的目的是什么,以及如何实施测试。这就需要通过制定测试 用例来实现。 所谓的测试用例的制定就是利用科学方法对软件测试的行为活动进行组织和 归纳。其目的就是为了将软件测试的行为转换为可度量、可管理的模式。这也是 为了迸一步让管理层对测试的实施过程进行更准确的把握。这种可管理模式的具 体行为就是设计测试用例,从整体数量上量化和把握测试的实施过程以及执行程 度。 总之,测试用例就是对待测软件的使用情况进行模拟设计。假设待测软件在 这种情况下,必须能够运行正常并且达到测试用

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论