（计算机科学与技术专业论文）rest架构应用软件测试系统的研究与实现.pdf

北京邮电大学硕士毕业论文 r e s t 架构应用软件测试系统的研究与实现 r e s t 架构应用软件测试系统的研究与实现 摘要 r e s t 架构风格是全新的针对网络应用的开发风格，是当今世界一 个成功的互联网超媒体分布式系统架构。近年来，r e s t 架构应用软 件的使用日益广泛，特别是在企业的内容协作应用中，r e s t 架构应 用软件以其特有的性质获得了人们的青睐。同时，人们对其质量也提 出了更高的要求。 软件测试作为软件生命周期的一个重要阶段，是保障软件质量的 有效手段。软件测试问题的研究越来越引起人们的重视。传统的网络 测试技术集中在网络的u i ( 用户界面) 层，不易发现深层次的软件 错误且效率低下。由于r e s t 架构软件对外提供统一规范的接口，因 此对r e s t 架构应用软件的测试可以集中在a p i 接口层，再引入先进 的自动化测试技术，可以大大提高r e s t 的架构应用软件的开发效率。 本文首先介绍了软件测试技术的发展，其中包括软件测试的基本 概念、软件测试模型、自动化测试以及当前广为应用的j u n i t 自动化 测试框架；其次分析了r e s t 架构应用软件的特点，并在此基础上提 炼出r e s t 架构应用软件的公共测试点、测试方法和验证点；最后， 设计并实现了套r e s t 架构应用软件测试系统。 关键词： r e s t 软件测试自动化测试h t t p a t o m i i i r e s e a r c ha n di m p l e m e n t a 0 no ft e s ts y s t e m f o rr e s tf r a m e w o r kb a s e da p p l i ( 硝l t l 0 n a b s t r a c t r e s ts t y l e ，w h i c hi san e wf r a m e w o r kf o r t h ed e v e l o p m e n to f n e t w o r ks o f t w a r e ，i st h em o s ts u c c e s s f u li n t e r n e td i s t r i b u t e dh y p e r m e d i a s y s t e ma r c h i t e c t u r ei nt h ew o r l d i nr e c e n ty e a r s ，t h es o f t w a r eb a s e do n r e s tf r a m e w o r kh a sb e e nu s e di n c r e a s i n g l y , e s p e c i a l l yi nt h ee n t e r p r i s e s f o rc o n t e n tc o l l a b o r a t i o nb yv i r t u eo fi t sn a t u r e m e a n w h i l e ，t h eu s e r sa l s o r e q u i r e dh i g hq u a l i t yo f t h i sk i n do fs o f t w a r e a sa n i m p o r t a n tp h a s ei ns o f t w a r el i f e c y c l e ，s o f t w a r et e s t i n g i s e f f e c t i v et oe n s u r es o f t w a r eq u a l i t y , a n dt h es o f t w a r ed e v e l o p e r sa r e p a y i n gm o r e a n dm o r ea t t e n t i o nt os o f t w a r et e s t i n ga tp r e s e n t t r a d i t i o n a l t e s t i n gt e c h n o l o g yf o rn e t w o r ks o f t w a r e f o c u s e do nt h eu i ( u s e ri n t e r f a c e ) l a y e r , w h i c hi sd i f f i c u l tt of i n dt h ed e e ps o f t w a r eb u g sa n di n e f f i c i e n t s i n c et h es o f t w a r eb a s e do nr e s tf r a m e w o r kp r o v i d e sas t a n d a r d i z e d i n t e r f a c e ，t h et e s t i n gt e c h n o l o g yf o r i ts h o u l df o c u so na p ii n t e r f a c el a y e r , a n di n t r o d u c et h ea d v a n c e da u t o m a t i o nt e s t i n gt e c h n o l o g y , a sar e s u l t ， t h i s t e c h n o l o g yc a ne n h a n c et h ee f f i c i e n c y o fd e v e l o p m e n tf o rt h e s o f t w a r eb a s e do nr e s tf r a m e w o r k i nt h i sp a p e r , t h ec u r r e n ts o f t w a r et e s t i n gt e c h n o l o g yi sr e v i e w e d ， i v 北京邮电大学硕士毕业论文r e , s t 架构应用软件测试系统的研究与实现 i n c l u d i n gt h eb a s i ct e s t i n gc o n c e p t i o n ，t e s t i n gm o d e l ，a u t o m a t i o nt e s t i n g a n dj u n i tt e s t i n gf r a m e w o r k ；t h e nw ea n a l y z et h ef e a t u r eo fr e s t s o f t w a r e ，a n do nt h eb a s i co fi tw eg e tt h ec o m m o nt e s t i n gp o i n t s ，t e s t i n g m e t h o d sa n dv e r i f i c a t i o np o i n t s ；a tl a s t ，w ed e s i g nar e s ts o f t w a r e t e s t i n gs y s t e ma n dp u ti ti n t op r a c t i c e k e yw o r d s ：r e s t , s o f t w a r et e s t i n g ，a u t o m a t i o nt e s t i n g ，a t r p ， m m v 北京邮电大学硕士毕业论文 r e s t 架构应用软件测试系统的研究与实现 独创性( 或创新性) 声明 本人声明所呈交的论文是本人在导师指导下进行的研究工作及取得的研究 成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不 包含其他人已经发表或撰写过的研究成果，也不包含为获得北京邮电大学或其他 教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任 何贡献均已在论文中作了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切相关责任。 本人签名：j 名蓉枉日期：一 关于论文使用授权的说明 学位论文作者完全了解北京邮电大学有关保留和使用学位论文的规定，即： 研究生在校攻读学位期间论文工作的知识产权单位属北京邮电大学。学校有权保 留并向国家有关部门或机构送交论文的复印件和磁盘，允许学位论文被查阅和借 阅；学校可以公布学位论文的全部或部分内容，可以允许采用影印、缩印或其它 复制手段保存、汇编学位论文。( 保密的学位论文在解密后遵守此规定) 本学位论文不属于保密范围，适用本授权书。 本人签名： 导师签名： 北京邮电大学硕士毕业论文r e s t 架构应用软件测试系统的研究与实现 1 1课题背景 1 1 1r e s t 架构的广泛应用 第一章概论 从早期静态的w e b 文档，到当今世界无所不在的动态w e b 应用，尽管w e b 技术 已经出现了1 8 年，但目前在开发w e b 应用中所采用的方法却还是不令人十分满意。 一方面，w e b 应用的性能，虽然随着网络速度的提升而有所提高，但是在现有网 络基础设施不变的前提下，如何有效提升w e b 应用性能仍然是困扰人们的一个难 题。另一方面，现有w e b 应用可伸缩性较差，所能支持的最大用户数往往有限。 一般都通过使用集群系统来提升可支持的用户数。然而，使用集群的副作用是， 用户会话必须在各个集群之间保持同步，从而又降低了系统的性能。因此，集群 的规模必将受到限制，支持的用户数量也将得不到提升。这也是为什么很多w e b 应用往往只能支持有限用户并发访问的原因。 因此，迫切需要一种能够解决这些问题的方法。2 0 0 0 年，r o yt h o m a sf i e l d i n g 博士提出了基于分布式超媒体应用的架构风格r e s t ( r e p r e s e n t a t i o n a ls t a t e t r a n s f e r ) 。r e s t 最早被用来指导设计h t t p 和u r l 标准，同时，由于r e s t 是一组适 用于分布式超媒体系统的架构风格，因此也用来指导基于分布式超媒体系统的应 用。把r e s t 架构用于w e b 应用，是近年来的研究热点。从r e s t 被提出之后，很多 人就开始使用r e s t 指导w e b 应用的开发n 1 。 一种思维方式可以影响软件行业的发展。事实证明，r e s t 架构是当今世界上 一个成功的互联网的超媒体分布式系统。它让人们真正理解我们的网络协议 h t t p 本来面貌。而且，从目前的趋势来看，它正在成为网络服务的主流技术， 同时也正在改变网络软件开发的思维方式。越来越多的软件开发人员投入到 r e s t 架构软件的研发和应用中，基于r e s t 架构的网络应用软件必然会犹如雨后 春笋，层出不穷。 l 艺京邮电大学琰毕鼓论文 r e s t 絮构应用软终测试系统憝研究等实璎 1 1 ，2 软件测试的必要性 软件是少有的一种无法根除自身缺陷旦允许公开合法出售的产品。人们明知 软件肯定存在缺陷，但权衡利弊之后仍然购买之，甚至法律对此也网开一面。如 软件厂商对其产品通常会做如下公示：“对本软件的任何修改恕不一一通知，当 然负责任的软件厂商会定期不定期的发放软件补丁。 软件的缺陷难以根除，僵软件的质量是可以改进的。加强软件测试是控制和 提高软件质量的一个行之有效的办法。任何一个软件产品的成功发布都离不舞软 件测试的保证。软件工程的总目标是充分利用有限的人力和物力资源，高效率、 高质量地完成软件开发项目。不足的测试势必使软件带着更多未搦露的隐藏错误 投入运行，这将意味着更大的危险让用户承担。软件测试是程序过程，目的是尽 可能发现并改正被测试软件中的错误，提高软件的可靠性。它是软件生命周期中 一项非常重要且非常复杂的工作，对软件可靠性保证具有极其重要的意义弪1 。 1 。2r e s t 架构软件测试技术现状 目前很多公司采用传统的网络应用软件测试技术对r e s t 架构软件进行测试， 这种测试技术主要针对网络软件的u i ( u s e ri n t e r f a c e ，耀产界面) 层，由测 试人员根据经验编写测试用例，测试方式以手动测试为主。通常情况下这静测试 方式并不能够保证完全覆盖到底层的所有接口，不易发现软件深层次的逻辑问 题，在发现问题时不易进行准确定位，繁琐和重复的手动测试也会降低网络应用 软件的开发效率，导致网络应用软件的测试完备性和测试充分性不高，软件的性 能得不到很好的保证。 这种效率低下、存在翡显缺陷的软件不当测试会造成以下后采： 重软件失败 软件测试的不充分、不科学会造成较为严重的软件缺陷，从菰使德软件发布 失败，给制造商带来严重的信誉和经济损失； 2 增加软件开发成本 传统上，识别和纠正软件缺陷会花费开发过程一半以上的成本，测试会占到 开发入力成本的3 0 到9 0 。越早发现软件缺陷，越能更多的降低成本； 2 北京邮电大学硕士毕业论文r e s t 架构应用软件测试系统的研究与实现 3 市场推广滞后 软件产品投放市场滞后的直接影响是丧失了机会。众所周知，软件产品的利 润率通常遵守暴利一高额利润一一一般利润一微利亏损这样的曲线变 化。投放时间晚，不仅丧失了赚“大钱的机会，而且对原有的类似的产品线也 会构成威胁。这种损失难以估量口1 。 因此，需要一套高效正确的软件测试工具对r e s t 架构软件进行测试，通常 情况下，这种测试工具对软件的影响体现在如下几个方面： 1 改进的测试工具会导致“质量鸿沟变窄。所谓质量鸿沟是指最终用户 能接受的软件质量水平的波动范围； 2 改进的测试工具有助于提高软件质量，从而减少售后服务( 发现并纠正 软件故障) 的成本，并不断推动软件质量的持续提高； 3 改进的测试工具需要消耗的测试资源和其他成本会减少。 1 3课题研究目标 由于r e s t 架构应用软件具有共同的特征，对外提供统一规范的接口，因此 本课题的研究目标是对其进行有针对性的研究，将测试重点深入到网络软件的接 口层，采用先进的自动化测试技术，设计出一套功能完备、效率较高、针对性较 强的r e s t 架构软件测试系统。这套系统的实现必将会大大提高r e s t 架构软件的 开发效率，从而进一步推动r e s t 架构软件的应用和发展，满足巨大的市场需求。 1 4本文的结构 本文首先介绍了软件测试技术的发展，其中包括软件测试的基本概念、软件 测试模型、自动化测试以及当前广为应用的j u n i t 自动化测试框架；其次分析了 r e s t 架构风格的特点，并在此基础上提炼出r e s t 架构软件的公共测试点、测试 方法和验证点；最后，设计并实现了一套r e s t 架构软件测试系统，对各个组成 模块进行了详细的介绍。 具体来说，各章的组成结构如下： 第一章概论，提出了本论文课题研究的背景、现状、目标和内容，通过对 相关测试技术现状的分析，阐述r e s t 架构软件测试系统的必要性； 3 j 艺寨郎耄大学殒士毕堑论文r e s t 絮携瘦矮软转测试系统的磺究与实瑗 第二章软件测试技术的发展，介绍了软件测试的相关概念、软件测试的模 型和当前流行的j u n i t 自动化测试框架； 第三章r e s t 架构应用软馋测试技术的研究，介绍了r e s t 架构的特点，并在 此基础上总结归纳出对r e s t 架构软件的测试原理和测试方法； 第四章r e s t 架构应用软件测试系统的实现，在第三章理论阐述的基础上设 计和实现了一套行之有效的r e s t 架构软件测试系统，包括系统架构、测试流程、 功能模块和自动化测试技术的引用； 第五章结论，对本论文中所阐述的内容以及研究的过程进行了总结，谈了 作者在研究过程中的收获，也阐骧了研究过程中的体会，最焉提出了对顼舀今后 研究工作的设想。 4 北京邮电大学硕士毕业论文r e s t 架构应用软件测试系统的研究与实现 第二章软件测试技术的发展 2 1 软件测试的相关概念 2 1 1 软件测试定义 1 9 8 3 年i e e e 对软件测试的定义为：软件测试( s o f t w a r et e s t i n g ) 是使用人 工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的 需求或是弄清预期结果与实际结果之间的差别。软件测试的两个基本职责：验证 和确认。验证( v e r i f i c a t i o n ) 是保证开发过程中某一具体阶段的产品与该阶段和 迁移阶段的需求一致。确认( v a l i d a t i o n ) 是保证最终得到的产品满足系统需求。 现代的软件开发工程是将整个软件开发过程明确的划分为几个阶段，将复杂 问题具体按阶段加以解决。经验证明，软件的质量不仅是体现在程序的正确性上， 它和编码以前所做的需求分析、软件设计密切相关。因此，为了保证软件的质量， 我们应该着眼于整个软件生存期，特别是着眼于编码以前的各开发阶段的工作。 这样，软件测试的概念和实施范围必须扩充，应该包括在整个开发各阶段的复查、 评估和检测。由此，广义的软件测试实际是由确认、验证、测试三个方面组成。 具体说来，确认是评估将要开发的软件产品是否是正确无误、可行和有价值的。 验证是检测软件开发的每个阶段、每个步骤的结果是否正确无误，是否与软件开 发各阶段的要求或期望的结果相一致。测试与狭隘的测试概念统一，通常是经过 单元测试、集成测试、系统测试三个环节。 在整个软件生存期，确认、验证、测试分别有其侧重的阶段。确认主要体现 在计划阶段、需求分析阶段，也会出现在测试阶段；验证主要体现在设计阶段和 编码阶段；测试主要体现在编码阶段和测试阶段。事实上，确认、验证、测试是 相辅相成的。确认无疑会产生验证和测试的标准，而验证和测试通常又会帮助完 成一些确认，特别是在系统测试阶段。 面向对象技术是一种全新的软件开发技术，正逐渐代替被广泛使用的面向过 程开发方法，被看成是解决软件危机的新兴技术。面向对象技术产生更好的系统 结构，更规范的编程风格，极大的优化了数据使用的安全性，提高了程序代码的 5 l 艺寨郎毫大学矮士毕鼗论文r e s t 架鞠应嚣软件测试系统的婿究与实现 重用，一些入就此认为面向对象技术开发出的程序无需进行测试。应该看到，尽 管面向对象技术的基本思想保证了软件应该有更高的质量，假实际情况却并非如 此，因为无论采震什么样的编程技术，编程人员鲶错误都是不可避免的，磊且由 于面向对象技术开发的软件代码重用率高，更需要严格测试，避免错误的繁衍。 因此，软件测试并没有因面向对象编程的兴起而丧失掉它的重要性h 1 。 2 2 软件测试内容 软件测试主要工作内容是验证( v e r i f i c a t i o n ) 和确认( v a l i d a t i o n ) ，下面分 别给出其概念。 验证( v e r i f i c a t i o n ) 是保证软件正确地实现了一些特定功能的一系列活动， 即保证软件徽了你所凝望的事情o ot h er i g h tt h i n g ) 。 l 。确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的要求 的过程； 2 程序正确性的形式证明，即采用形式理论证明程序符号设计规约规定的 过程； 3 评审、审查、测试、检查、审计等各类活动，或对某些项处理、服务或 文件等是否和规定的需求相一致进行判断和提出报告。 确认( v a l i d a t i o n ) 是一系列的活动和过程，露的是想证实在一个给定的外 部环境中软传的逻辑_ 芷确性。即保证软件以正确的方式来做了这个事件( d oi t r i g h t ) 。 1 静态确认：不在计算机上实际执行程序，通过人工或程序分析来证明软 件的正确性； 2 动态确认：通过执行程序傲分析，测试程序的动态行为，以证实软件是 否存在问题。 软件测试的对象不仅仅是程序，软件测试应该包括整个软件开发麓闻各个阶 段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测 试的主要对象还是源程序。 6 北京邮电大学硕士毕业论文r e s t 架构应用软件测试系统的研究与实现 2 1 3 软件测试的分类 从不同的角度出发，软件测试可以划分为不同的分类。 从是否关心软件内部结构和具体实现的角度划分： a 白盒测试 b 黑盒测试 从是否执行程序的角度： a 静态测试 b 动态测试 从软件开发的过程按阶段划分有： a 单元测试 b 集成测试 c 确认测试 d 验收测试 e 系统测试 下面给出按照测试内容分类得出的几个基本概念： a 功能测试：测试软件产品是否与需求符合，并准确的实现各个需求，主 要采取黑盒测试方法； b 性能测试：测试软件产品是否满足性能要求，如响应时间、吞吐率、处 理精度等，对实时系统、嵌入式系统等尤为重要； c 可靠性测试：测试软件产品是否满足可靠性要求，可靠性指在规定的时 间间隔内和条件下，软件产品正确运行的概率，测试内容还包括可用性和易用性； d 标准符合性测试：测试软件产品是否符合相应的标准，如国家标准，特 殊行业的行业标准等； e 互操作性测试：测试软件产品在不同平台、不同环境下的互操作能力， 主要应用于分布式系统中和网络环境下； f 安全性测试：测试软件产品有无安全漏洞； g 强度测试：测试软件产品在非正常情况下，系统的运行能力。 软件测试的分类并不是绝对的，从不同角度的分类并不矛盾，例如同- - n 试 技术可以应用在不同阶段的测试中，本文中将依据一般软件产品的开发过程对各 7 j 艺寨咚电大学矮七肇夔论文 r e s t 絮掏应用软律测试系统既研究与实现 种测试做较为详细的介绍。 2 。2 软件测试模型 软件开发产业发展了几十年中形成了很多经典的开发模型瑟1 ，比如瀑布模型、 螺旋模型等，僵在这些模型中测试没有褥到充分的重视，测试的价值没有被充分 强调，与软件测试在实际的开发过程中所占的比重和地位极不相符。近年来，人 们逐步认识到这些不足，提出了些新的模型，如v 模型、w 模型等，已经把测 试放到了一个相当重要的位置上。 2 2 v 楱墼 v 模型最早由已故的p a u lr o o k 在8 0 年代后期提出。v 模型被包含在英国国 家计算中心文献中发布，旨在改进软件开发的效率和效果。v 模型在欧洲尤其是 英国被接受，并被认为是瀑布模型的替代品，￥模型最早提出测试并不楚一个事 霜弥李 行为，两是一个与开发过程同样重要的过程。这是它最大的积极意义所在， 直到现在，v 模型仍然被大多数软件开发公司作为开发过程的依据。、f 模型描述 了一些不同的测试级别，并说明了这些级别所对应的生命周期的不同阶段，如图 2 一l 所示： 爨2 - i - ￥模型 左边下降的是开发过程各个阶段，与此相对应的是右边上升的部分，即各测 试过程的各个阶段，左边每个开发活动都有右边的测试活动相对应。因此，v 模 型主要向我们传递了如下信息：需求、功能、设计和编码的开发活动随时间而进 行，而相应的测试活动，即针对需求、功能、设计和编码的测试，其开展的次序 8 北京邮电大学硕士毕业论文r e s t 架构应用软件测试系统的研究与实现 则正好相反。换而言之，代码最后被开发，而相应的单元测试首先被执行；需求 则最早开发，但相应的验收测试到最后进行。v 模型揭示了软件测试活动分层和 分阶段的本质特性。v 模型非常明确地标明了测试过程中存在的不同级别，并且 清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系： 1 单元测试的主要目的是针对编码过程中可能存在的各种错误，例如用户 输入验证过程中的边界值的错误； 2 集成测试主要目的是针对详细设计中可能存在的问题，尤其是检查各单 元与其它程序部分之间的接口上可能存在的错误； 3 系统测试主要针对概要设计，检查了系统作为一个整体是否有效地得到 运行，例如在产品设置中是否达到了预期的高性能； 4 验收测试通常由业务专家或用户进行，以确认产品能否真正符合用户业 务上的需求。 在不同的开发阶段，会出现不同类型的缺陷和错误，所以需要不同的测试技 术和方法来发现这些缺陷。 v 模型揭示了软件测试活动分层和分阶段的本质特性，但也存在一些问题， 比如容易让人形成“测试是开发之后的一个阶段，“测试的对象就是程序 之类 的误解。由于v 模型把系统开发过程划分为具有固定边界的不同阶段，这使得人 们很难跨过这些边界来采集测试所需要的信息。有些测试应该执行得更早些，有 些测试则需要延后进行。例如，需求或者设计阶段的错误往往需要到最后验收测 试才被发现，这样修改的代价就会很大。又比如，单元测试中需要设计桩模块和 驱动模块，这需要付额外的成本，或者因为条件不具备，根本就无法开发，而且 有可能掩盖了一些潜在的缺陷，所以在实际应用中有时候并不是当单元开发完成 后就执行单元测试，当模块从被组装在一起后就执行集成测试，往往需要推迟一 些阶段的测试。不仅如此，v 模型也阻碍了从系统描述的不同阶段中取得信息进 行综合。所以，一些改进过的软件测试模型被提了出来1 。 2 2 2w 模型 w 模型也叫双v 模型，是对v 模型的改进，它由e v o l u t i f 公司提出，针对v 模型让人觉得“测试是开发之后的一个阶段”，“测试的对象就是程序 的问题， 9 北哀邮电大学磺士毕鼗论文p e s t 架构应震软传测试系统豹磷究与实现 w 模型强调需求、功能和设计同样要测试，测试的对象不仅仅是程序，软件测试 应该贯穿整个开发周期之中，只要褶应的开发活动完成，就可以开始执行测试。 可以说，测试与开发是同步进行的，从而有利于尽早的发现闻题。以需求为例， 需求分析一完成，我们就可以对需求进行测试，丽不必等到最后才进行针对需求 的验收测试。 w 模型如图2 - 2 所示： 豳2 - 2w 模型 鬻模型，尽管改善了￥模型的一些闯题，但不管￥模型还是鬻模型，适用于 那些需求非常明确、已经文档化了的项目，开发人员和测试人员都需要严格定义 需求和设计来开展工作。但在实际的开发过程中，开发过程中因为需求变化等不 可避免的原因，开发人员并没有按照文档来工作，也就是说文档没有及时更新。 这些情况下，v 模型和w 模型在实施起来就很困难。此外，无论是v 模型，还是 w 模型，都把软件的开发视为需求、设计、编码等等一系列的串行活动。而事实 上，虽然这些活动之闯存在着互褶牵割的关系，但在大部分酎闻，它们是互相独 立的，是可以并发进行的。虽然软件开发期望有清晰的需求、设计和编码等阶段， 健实践告诉我们，严格的阶段之分只是一种理想状况。n 。 2 2 3x 模型 x 模型也是为了解决v 模型的种种问题，而由r o b i nf g o l d s m i t h 和b r a i n m a r i c k 提出的替代模型基础上提出的。他们认为v 模型和w 模型最大的问题体 现在以下几个方面： 1 忽略了这样的事实情况，即软件开发是由一系列的交接所组成，每一次 交接内容都改交了前一次交接的行为； 2 依赖于开发文档的存在，及文档的精确性、完备性，并且没有对时间进 1 0 北京邮电大学硕士毕业论文 r e s t 架构应用软件测试系统的研究与实现 行限制； 3 认定一种测试的设计是依据某一个单独的文档，而不包括根据其前后阶 段的文档的修改而作相应修改； 4 认定这些依赖于某个单独文档的测试一定要在一起。 x 模型如图2 - 3 所示： 图2 - 3x 模型 x 模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试， 右上半部分显示此后将进行频繁的交接，通过集成最终合成为可执行的程序，这 些可执行程序还需要进行测试。已通过集成测试的成品可以进行确认并提交给用 户，也可以作为更大规模和范围内集成的一部分。多条并行的曲线表示变更可以 在各个部分发生。x 模型还定位了探索性测试，这是不进行事先计划的特殊类型 的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件 错误姆1 。 总的来说，x 模型和下面的h 模型有很多共同之处，它们都是为了解决v 模 型中理想化的一些东西，比如开发阶段之间有严格的界限、忽视了需求变化往往 导致开发过程变化的情况、认为测试可以依据已经写好的精确的文档来进行、没 有明确测试执行前应该进行的测试设计等准备阶段，而且x 模型包含了探索性测 试这一软件测试前沿理论，这也是亮点之一。 2 2 4h 模型 在一般情况下，当客户在看到软件最终产品之前是无法判断其是否是所希望 麓寨邮电大学联士肇鼗论文r e s t 絮掇瘟霜软侮溅试系统懿研究与实现 的软件产品，一塑他看到最终产晶时才发现与自己的期望相差甚远。究其原因： 王用户的需求表述不清，由于用户自身的局限或对业务理解不同使用户表 述模糊； 2 。用户需求的多变性，随着开发进程的推进，用户对所建应用系统理解的 不断深入，对原来模糊的需求有了新的认识或者有了新的需求； 3 由于用户对计算机领域知识的缺乏导致提出的需求不能实现或代价极 大，往往需要变更需求。 因此，用户需求的不确定性和易变性是客观存在的，是不可避免的。需求的 变纯就导致实际情况串设计、开发、编码等各个阶段经常要反复交叉进行，正如 前文所述，y 模型和霉模型把软件开发的各个阶段划分的过于严格，那是一种理 论上的理想状态，实际上在真实的开发过程中并没有那么严格的界限，往往是各 个阶段交叉进行，不仅如此，而且在开发的过程中各不同层次之间的测试如单元 测试、集成测试和系统测试除了存在时间上的先后关系之外，还存在着触发、反 复、迭代和增量关系。另外，v 模型和w 模型都没能很好的表示测试流程的完整 性。测试流程可以大致分为两类活动，一类是测试准备活动，包括测试需求分析、 测试计划、测试分析、测试编码、测试验证等等，另一类是测试执行活动，包括 测试运行、测试报告、测试分析等等。虽然，w 模型将测试从开发中分离了出来， 但仍旧将测试视为一个个游离的活动，丽不是个系统化的流程。h 模型就是为 解决这些缺陷而产生的。 h 模型如图2 - 4 所示： 图2 - 4h 模型图 h 模型表明软件测试不仅仅指测试的执行过程本身，还应该包括测试需求分 析、测试计划、测试分析、测试编码、测试验证等测试的准备活动。软件测试是 北京邮电大学硕士毕业论文r e s t 架构应用软件测试系统的研究与实现 一个独立的流程，应该贯穿软件开发的整个周期，可以与其它流程并发的进行。 当某个测试准备就绪时，软件测试即从准备阶段进入到测试执行阶段。而这个过 程是反复执行的，当需要测试时，就应该进行测试，h 模型兼顾效率和灵活性， 可以被应用到各种规模和各种类型的软件产品开发中p 1 。 2 3 自动化测试 随着软件产业的不断发展，产品越来越复杂，竞争越来越激烈，人们总是要 求产品在最短的时间内使用最少的资源来完成，有统计数字表明，百分之九十以 上的软件产品推迟了交货日期，大部分的开发人员在开发周期的后期不得不取消 一些功能以赶上最后期限。作为保障软件质量最重要的环节，软件测试也同样面 对时间压力，而软件测试是对创造力和智力非常有挑战性的任务。测试一个大型 软件需要的技术要求可能要超过设计这个程序。软件在它发行之前应当通过彻底 的测试，以保证它的可靠性和功能性。不幸的是，一方面，迫于时间和市场压力， 测试工作可能根本就没有充分进行；另一方面，面对越来越大型化和复杂化的软 件产品，测试工程师靠自己的力量往往无能为力。一般的说，仅仅依靠测试人员 自身的力量，软件在发行前仅有5 0 的源程序被测试过。在差不多有一半源代码 没有被测试的情况下，大量的故障( b u g ) 随软件一道被发行出去。在这种情况下， 软件的质量、性能和功能不可能得到保障。面对这些问题，自动化测试应运而生。 自动化测试就是希望能够通过自动化测试工具或其他手段，按照测试工程师的预 定计划进行自动的测试，目的是减轻手工测试的劳动量，从而达到提高软件质量 的目的n 们。自动化测试的好处有t 1 方便进行回归测试 产品发现错误以后的改动，代码变了，但要求的功能并没有变，测试用例也 不必改变，自动化测试就可以很方便地进行回归测试，另外，自动化测试适用于 产品型的软件，每次发布一个新的版本，其中大部分功能和界面都和上一个版本 相似或完全相同，这部分功能特别适合于自动化测试，从而可以让测试达到测试 每个特征的需求。 2 速度快，效率高 一般来说，软件产品的发布周期很短，而在测试期间是每天都可能要发布一 1 3 北家郎邀大学矮士毕业论文r e s t 絮构应震软俘测试系统懿研究与实现 个版本供测试人员测试，一个系统的功能点有几千个上万个，入工测试是一项非 常耗时和繁琐的工作，这样妊然会使测试效率低下，自动化测试很好地解决这个 阆题，完全计算机自动执行的测试瘸本速度快，效率高。 3 。测试一致性和重复性 自动化测试执行依据的是测试脚本，而测试脚本是可以保存的，可以保证每 次自动化测试运行的脚本是相同的，所以每次执行的测试具有一致性，使错误和 执行过程具有可重现性，这一点人是很难做到的。自动化测试的一致性，很容易 发现被测软件的任何改变。 4 更好的利用资源 自动化测试熊够按计划完全自动的盘计算机运行，两测试人员是需要吃饭睡 觉的，不可能2 4 小时直工作，自动化测试完全可以在周末和晚上执行测试， 这样充分的利用了时间和机器的资源，也避免了开发和测试之间的等待。 5 增加软件信任度 人总是会出错的，每一个测试人员都有自己特殊的经历和技术背景，有自己 的一些操作习惯和先入为主的观念，而这就导致不是所有的测试都是可信的，而 且有时测试会把一些新的错误带入软件产晶之中。自动化测试则会在很大程度上 避免这些阌题1 。当然自动化测试也不是无所不簏的，很多情况下并不是适合选 择自动化测试，人们对自动化测试的理解也存在许多误区，认为自动化测试能完 成一切工作，从测试计划到测试执行，都不需要人工干预，常见的错误认识总结 如下： 1 期望自动化测试能完全取代手工测试 工具毕竟是工具，出现一些需要思考、体验、界面美观方面的测试时，工具 就起不到褶应的作用。焉且在自动化测试实施的各个阶段也需要入的参与，在某 些阶段，比如分析测试结果等，自动化工具只能提供数据，结果肯定是需要测试 人员来确定的。 2 期望自动测试发现大量新缺陷 同样不能期望自动化测试去发现更多新的缺陷，不能测试的新缺陷越多，自 动化测试失败的几率就越大。发现更多的新缺陷对于软件测试来说是主要目的。 测试专家j a m e sb a c h 总结出，8 5 的缺陷靠手工发现，而自动化测试只能发现 1 4 北京邮电大学硕士毕业论文 r e s t 架构应用软件测试系统的研究与实现 1 5 的缺陷。自动化测试能够很好的发现老缺陷。 3 期望自动化测试可以适应于所有的测试 目前，没有一个单一的测试工具能够支持所有的操作系统，也没有任何一个 测试工具能够与所有的程序语言兼容，因此，不能期望自动化测试能够适用于所 有的环节。 4 期望测试能够马上减轻测试工作，加快测试进度 引入自动化测试主要的目的之一是减轻测试的工作量，提高测试的工作效 率，但是，经验表明，自动化测试的引进并不能马上减轻工作量，因为，人工测 试并不能被完全取代，而测试人员存在对自动化工具的学习和熟悉问题，所以， 在刚开始引入的时期，甚至有可能加大工作量，延缓测试工作的进度。 5 期望达到百分之百的测试覆盖率 即使采用自动化测试，也不能测试每一项功能，每一个语句，因为，对一个 比较复杂的软件产品来说，它的输入情况或语句的排列组合情况非常复杂，不可 能完全覆盖所有可能情况。当然，这仍然是自动化测试的强项之一，但不能期望 自动化测试能覆盖所有情况n 。 自动化测试的实施大概分为以下几个阶段： 1 确定采用自动化测试 2 自动化测试工具的选择和获取 3 自动化测试的设计开发 4 自动化测试的执行 5 自动化测试的评审 首先，在确定是否引入自动化测试时应该认识到自动化测试不是适合所有的 公司、所有的项目。几种常见的种类总结如下： 1 定制型项目 为客户订制的项目。客户有固定的需求的订制项目，因为功能的特殊性，所 以不适合用自动化测试。 2 项目周期很短的项目 项目周期很短、测试周期很短，就不必花精力去投资自动化测试，好不容易 建立起的测试脚本，不能得到重复的利用是浪费时间。 熬家邮毫大学磺士毕业论文r e s t 榘构痰震软转测试系统酶磅究与实现 3 业务规则复杂的对象 业务规则复杂的对象，有很多的逻辑关系、运算关系，自动化工具就很难达 到测试要求，如采强行使用自动纯测试_ 工具，往往需要投入更多的时闻和精力， 德不偿失。 4 抽象性测试 比如出于人的感觉方面的测试，很难有严格的测试标准，如界面的外观、声 音的体验、易用性的测试，显然自动化测试无用武之地，只能由人来测试。 5 测试很少运行的情况 测试很少运行，对自动纯测试就是一种浪费。自动纯测试就是不厌其烦的、 反反复复的运行才有效率。 6 。软件质量还不稳定 软件不稳定，则会由于这些不稳定因素导致自动化测试失败。只有当软件达 到相对的稳定，没有界面性严重错误和中断错误时能开始自动化测试。 相反，有一些项目就特别适合采用自动化测试，那么什么样的情况适合自动 化测试? 我们总结如下： 圭产品型顼嚣 产品型的项凳，每个项爨只改进少量的功能，但每个顼爨必须反反复复的测 试那些没有改动过的功能。这部分测试完全可以让自动化测试来承担，同时可以 把新加入的功能的测试也慢慢地加入到自动化测试当中。 这些项目一般采用增量式开发、持续集成，由于这种开发模式是频繁的发布 新版本进行测试，也就需要自动化测试来频繁的测试，以便把入从重复测试中解 脱出来测试新的功能。 2 能够自动编译、叁动发毒的系统 要麓够完全实现自动化测试，必须熊够具有自动化编译，自动化发布系统进 行测试的功能。当然，不能达到这个要求也可以在手动情况下进行自动化测试。 3 需要频繁运行测试的项目 自动化测试最喜欢多次重复的测试，这样的测试对它来说从不会失败。比如 要向系统输入大量的相似数据来测试压力和报表。自动化测试的强项能够很好的 确保你是否弓| 入了新的缺陷，老的缺陷是否修改过来了。如采在一个项西中需要 1 6 北京邮电大学硕士毕业论文r e s t 架构应用软件测试系统的研究与实现 频繁的运行测试，测试周期按天算，就能最大限度的利用测试脚本，提高工作效 率。在确定引入自动化测试后，项目面临的问题，就是如何来选择适合自己的自 动化测试工具了。 在什么地方应该采用自动化测试工具经历了一个由简单到复杂的发展过程， 最早的测试工具仅有捕捉回放，基本不具备自动测试的功能，后来在捕捉重放的 基础上加上脚本，能力有了提高，但需要较强的专业知识和经验，再后来测试工 具开始采用数据驱动，把测试脚本与测试数据分离存储，现在的测试工具往往采 用框架结构和数据驱动。相应的我们也可以看出软件测试自动化的五个级别： 级别1 ：捕获和回放 这是使用自动化测试的最低的级别，同时这并不是自动化测试最有用的使用 方式。自动化的测试脚本能够被自动的生成，而不需要有任何的编程知识，但当 需求和应用发生变化时相应的测试脚本也必须被重新录制。 级别2 ：捕获、编辑和回放 在这个级别中，使用自动化的测试工具来捕获想要测试的功能。将测试脚本 中的任何固定的测试数据，比如名字、密码等等，从测试脚本的代码中完全删除， 并将它们转换成为变量。测试脚本开始变得更加的完善和灵活，并且可以大大的 减少脚本的数量和维护的工作，但需要一定的编程知识。频繁的变化可能会引起 复杂的改动，并且变更和维护几乎是不可能的，能够使用这种技术通过快速的编 制一些测试脚本以检验你的想法来探索你的预定的测试设计。 级别3 ：编程和回放 能够使用自动化测试并构建不同的回归测试。使用已有的自动化测试用例， 可以进行测试脚本的设计、编码，这将开始搭建起测试和开发之间的桥梁，如果 没有对测试自动化工具的适当的培训，测试人员将不具备到达这个级别的能力。 在自动化测试工具中的所有测试功能都必须被很好的理解，而且要掌握测试脚本 语言的知识。在项目的早期就可以开始自动化的测试。你能够在项目的早期就开 始进行测试脚本的设计。与开发人员交流并调查他们认为可能会存在问题的区 域。确保了开发人员关注在获得能够被测试的方案上。要求测试人员具有很好的 软件技能，包括设计、开发等。 级别4 ：数据驱动的测试 1 7 北京邮电大学硕士毕业论文r e s t 架构应用软件测试系统的研究与实现 能够根据被测试系统的变化快速创建一个测试脚本的测试功能库，这是自动 化测试一个专业的测试级别。要利用测试工具提供的所有的测试功能，需要拥有 一个强大的测试框架，使得维护的成本相对是比较低的。在测试中会使用到大量 真实的数据。软件开发的技能是基础，并且需要访问相关的测试数据。该级别要 求一些非常良好的测试数据。一个测试人员必须要花费一些时间来识别在哪里收 集数据和收集哪些数据。 级别5 ：使用动作词的测试自动化 这是自动化测试的最高级别。测试用例的设计被从测试工具中分离了出来， 能够使测试工具从外部的来源，比如e x c e l 表或者数据库中执行测试用例。当在 e x c e l 表中创建测试用例的时候，放置使用包括被使用的特定动作词语的一些类 型的模板。执行的过程是从e x c e l 表中读取测试用例，并将测试用例转换成为测 试工具能够理解的形式，然后使用不同的测试功能来执行测试。这个级别要求有 一个具有高技能测试人员的团队，这些测试人员能够将测试工具的非常深层次的 知识与他们具备的较深的编程能力结合起来n 3 1 。 测试工具按照测试的不同阶段可以大概分为以下这几类： 1 测试设计工具有助于准备测试输入或测试数据，逻辑设计工具涉及到说 明、接口或代码逻辑，有时候也称为测试用例生成器，从说明中抽取数据的工具 就是逻辑设计工具；物理设计工具操作已有的数据或产生测试数据，如可以随机 从数据库中抽取记录的工具就是物理设计工具：静态分析工具分析代码而不执行 代码，这种工具可以计算出代码的各项度量指标：测试执行与比较工具可使测试 自动进行，然后将测试输出结果与期望输出进行比较，如捕获回放工具，市场上 的很多g u i 自动测试工具都属于这一类，它允许工程师创建( 录制) 、修改、并运 行( 回放) 自动测试； 2 动态分析工具评估正在运行的系统，例如检测内存泄漏的工具； 3 调试工具不是真正的测试工具，但在测试中经常用于完成隔离