（计算机科学与技术专业论文）j2ee应用自动化单元测试框架研究.pdf

j 2 e e 应用自动化单元测试框架研究 摘要 近些年来，由于软件规模的不断增大，传统的手工测试己严重影 响了软件的发展。它不但需要投入大量的人力、物力和时间，最终还 是由于测试的工作量太大，而无法保证软件测试的充分性，从而无法 有效保证软件的质量。正是由于上述原因，推动了软件测试工具的发 展。国内外大量的软件厂商，以及些开源组织和个人，目前已经开 发了成百上千各种各样的软件测试工具，广泛应用到软件产品的生产 活动中。 在软件测试中，单元测试只是其中的一种，但单元测试却是所有 测试中非常重要的一种。，依赖于单元测试，并且单元测试也是， 实践中的关键一项。因为x p 全面拥抱需求变化，在没有完整的设计 情况下就开始编码【2 】。为了应付开发过程中或者项目递交后客户对功 能的改变，如果没有单元测试作铺垫，编码和后续维护中出现的b u g 可以淹没整个项目组。 对基于j 2 e e 平台的应用程序进行单元测试是众所周知的难题。 j 2 e e 程序代码先要部署到服务器容器中，运行时代码在容器中由容器 支持、控制和运行。程序代码不能脱离容器单独运行，运行结果必须 由容器发给客户端才能得到。 本论文正是基于上述出发点，对在软件测试过程中应用最多且最 重要的单元测试进行研究，并结合目前开源自动化单元测试框架，给 出了对j 2 e e 应用项目进行单元测试的解决方案。本文最后将单元测 试的解决方案结合各种测试策略，为一个基于s n u t s 的j 2 e e 应用项 目编写单元测试用例，从而证明了用开源单元测试框架对j 2 e e 应用 进行单元测试的可行性和必要性。使用开源测试框架的组合来进行单 元测试，不但能够成功运用在j 2 e e 应用中，同样还可以运用到其它 j a v a 项目的测试中。 关键词软件测试单元测试j 2 e e j u m ts t r u m i r e s e a r c ho fa u t o m 蜘cu n i tt e s t i n g f r a m 哐w o r kf o rj 2 e ea p p l i c a t l o n i nr e c e n ty e a r s w i t ht h ei n c r e m e n to f t h es i z eo f s o f t w a r ei n d u s t r y , t h et r a d i t i o n a l m a n u a lt e s t i n gm e t h o dh a sb l o c k e dt h ed e v e l o p m e n to ft h es o f t w a r ep r o j e c t m a n u a l t e s t i n gn e e d sl a r g en u m b e ro f t e s t e r 、r e s o u 玎瑚a n dt i m e f i n a l l y , b e c a m eo f t h eh u g e w o r k l o a d , al o to ft e s t i n gw o r kc o u l dn o tb ee x e c u t e d d u et ot h er e o na b o v e , t e s t i n gt o o l sg r o w su p m a n ys o f t w a r ec o m p a n i e sd o m e s t i ca n do v c r $ c a qo fm a n y 0 p e l ls o u r c og r o u pa n di n d i v i d u a l sh a v ed e v e l o p e dm a n ya u t o m a t i ct e s t i n gt o o l s ，a n d h a v eb e e nu s e dw i d e l yi nt h ep r o c e s so f s o r w a r ed e v e l o p m e n t i nt h es o f t w a r et e s t i n gf i e l d ，u n i tt e s t i n gi sj u s to n et y p e , b u tt h em o s ti r a p o r t a n t t y p e x pm e t h o d o l o g yi sd e p e n d e n to nu n i tt e s t i n ga n du n i tt e s t i n gi s t h em o s t i m p o r t a n tp r a c t i c ei nx p b e c a u s ex pm e t h o d o l o g ys u p p o r tr e q u i r e m e n tc h a n g i n ga n d b e g i nc o d i n gb e f o r e t h ew h o l ed e s i g nc o m p l e t e d i no r d e rt o d e a lw i t ht h e r e q u i r e m e n tc h a n g i n gd u r i n g t h ep r o c e s so fd e v e l o p m e n to ra f t e rt h ep r o j e c t s u b m i t t i n g , i f n ou n i tt e s t i n g , t h en u m b e ro f b u g si nm a i n t c n a n c 结c o u l db ev a s t n e s s i ti sw e l lk n o wt h a td o i n gu n i tt e s t i n gf o rj 2 e ea p p l i c a t i o ni sad i f f i c u l tp r o b l e m j 2 e ep r o g r a m sh a v et od e p l o yt ot h es e r v e rc o n t a i n e rf i r s tt h e nt h ec o n t a i n e rn l 地t h e p r o g r a m sa n ds e n d st h er e s u l tt oc l i e n t t h ep r o g r a mc o u l dn o tb er u na n dg o tr e s u l t w i t h o u tc o n t a i n e r t h i sp a p e ri sb a s e do nt h ep o i i l ta b o v e ，d ot h er e s e a r c ho ru n i tt e s t i n ga n dg i v e na t e s t i n gr e s o l u t i o nu s i n go p e ns o u r c eu n i tt e s t i n gf i a m e w o r ko nj 2 e ea p p l i c a t i o n s f i n a l l y , d ou n i tt e s t i n gf o ras t r u t sj 2 e ea p p l i c a t i o nu s i n gt h es o l u t i o na n dt h et e s t i n g s t r a t e g yt op r o v et h ef e a s i b i l i t ya n dn e c e s s a r yo fa u t o m a t i cu n i tt e s t i n go l lj 2 e e a p p l i c a t i o m d o i n g u n i tt e s t i n gw i t ho p e ns o u i c ef r a m e w o r k , i tc o u l dn o to n l yb eu s e d i nj 2 e ea p p l i c a t i o n sb u ta l s ou s e di no t h e rj a v aa p p l i c a t i o nt e s t i n g k e yw o r d s $ o f i w a r et e a r i n g ，u n i tt e s t i n g ，j 2 e e ， j u n i t , s t r u m 独创性( 或创新性) 声明 本人声明所呈交的论文是本人在导师指导下进行的研究工作及取得的研究 成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不 包含其他人已经发表或撰写过的研究成果，也不包含为获得北京邮电大学或其他 教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任 何贡献均已在论文中作了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切相关责任。 本人签名：丞蜩姐 日期：! ! 竺兰 关于论文使用授权的说明 学位论文作者完全了解北京邮电大学有关保留和使用学位论文的规定。即： 研究生在校攻读学位期间论文工作的知识产权单位属北京邮电大学。学校有权保 留并向国家有关部门或机构送交论文的复印件和磁盘，允许学位论文被查阅和借 阅；学校可以公布学位论文的全部或部分内容，可以允许采用影印、缩印或其它 复制手段保存、汇编学位论文。( 保密的学位论文在解密后遵守此规定) 保密论文注释：本学位论文属于保密在一年解密后适用本授权书。非保密论 文注释：本学位论文不属于保密范围，适用本授权书。 本人签名：塑蜩丑 新铭：豫舟一 日期：丝! 竺! 日期： 北京邮电大学硕士论文 1 1 课题研究背景和意义 第一章绪论 近几年来，软件测试工作受到越来越多的关注，国外软件测试行业已经发展 了很多年，进入相对成熟的阶段，国内的很多软件企业也开始认识到了软件测试 在质量保证过程中极其重要的地位，并投入一定的人力专门负责软件测试。 软件测试按不同的标准可以划分为很多种类，如：黑盒测试，白盒测试，功 能测试，性能测试等。按照传统软件工程中的测试理论来实践，测试工作是一项 繁杂劳动，不仅需要针对各个功能编写测试用例，同时要不断运行测试用例来保 证系统在不同开发阶段的质量。为了减少人力上的投入，加快测试时间，软件测 试正在向着自动化的方向发展。很多大公司都引入了各种自动化测试工具，比如 m e r c u r y 公司的l o a d r u n n e r 、w i n r u n n e r 、t e s t d i r e c t o r ；r a t i o n a l 公司的r a t i o n a l r e q u i s i t e p r o ，r a t i o n a lf u n c t i o n a lt e s t e r ，c l e a r c a s e 等等。这些工具中有功能测试 工具，性能测试工具，也有测试过程管理工具。但是这些工具价格昂贵，并不适 合中小型企业，而且g u i 自动测试工具( 例如：w i n r u n n e r ) 效果不佳是众所周 知的，只有确实无法分离界面和实现，或者作为辅助手段时，才有必要存在。 目前中小型企业在进行项目的开发过程中，更多的测试工作是安排专门的软 件测试人员根据项目的需求编写测试用例，然后用手工的方法进行黑盒测试。这 种测试方法，技术要求不高，但是工作量非常大，浪费时间。测试人员找出了问 题，反映到开发人员处需要时间，开发人员还要根据错误现象回忆自己的设计过 程，从而定位错误。经常发生错误定位不准确的情况，浪费了开发人员的时间。 可见无论是采用黑盒自动化测试工具，还是手工测试方法，都不能有效保证 软件质量。 针对软件行业的这种现状，出现了( e x t r e m ep r o g r a m m i n g ) 极限编程， 敏捷测试等方法论，以及t d d ( t e s t d r i v e nd e v e l o p m e n t ) 测试驱动开发原则。 这些方法论都提出把软件测试的角色加重，尤其是单元测试。 著名的测试专家b o r i sb e i z e r 博士认为：“软件开发历史上最臭名昭著的错误 都是单元错误即通过适当的单元测试可以发现的错误。”他引证了v o y a g e r 的错误( 将探测器发送到太阳) 、a t & t 和d c s 的错误( 曾造成美国三分之一的 电话瘫痪) 以及i n t d 奔腾芯片错误，都能够通过全面的单元测试排除掉【2 2 1 。单 元测试能够极大的改善软件质量，它是在最容易和成本最低的阶段帮助程序员检 北京邮电大学硕士论文 测和纠正错误。 首先，单元测试最接近错误，它能够有效的检测在应用级测试中很难找到的 错误。类一级的测试提供了一种更有效的发现错误的方法。单独测试一个与其它 对象分离的类时，由于更接近错误，找到潜在的错误就会变得容易得多。 其次，单元测试简化错误检测的另一个方面是防止错误繁衍出更多的错误。 避免了总是要穿过重重迷雾去寻找一个简单的错误。因为错误之间是有相互作用 的，如果代码中遗留了一个错误，它可能会导致更多的错误。因此，如果系统延 迟到以后的开发阶段才去测试，可能不得不去纠正更多的错误，花费更多的时间 去发现和改正每个错误，并且要修改更多的代码。如果刚开发完一个类的时候测 试，发现和纠正一个错误就会容易得多，并且错误繁衍的机会也会降到最低限度。 结果是极大的减少了调试时间和成本。 开源组织目前开发了各种单元测试框架，最著名的有x u n i t 系列( 基于j u n i t 测试框架扩展出的适用于其它各种语言的测试框架) ，以及基于x u n i t 框架扩展 出的其它自动化测试框架。以j 2 e e 组件单元测试这一方向为例，主要测试框架 就有j u n i t ，m o c ko b j e c t s ，c a c t u s 和h t t p u n i t 等；分析覆盖率的工具有l o g i s c o p e ， t r u e c o v e r a g e p u r e c o v e r a g e 等；性能测试工具有j m e t e r 等；负载测试工具有 j u n i t p e r f 等；已经产品化的自动化单元测试工具有j 2 e e t e s t e r ，r a t i o n a l q u a l i t y a r c h i t e c t ，r a t i o n a l p u r i f y p l u s 等等。这些测试框架和工具为全面和高效率地执行 面向对象测试奠定了基础，也体现了面向对象软件测试技术有了很大的发展。这 些单元测试框架使得单元测试自动化成为可能。对基于j a v a 开发的软件来说， u n i t 框架已经成为了进行单元测试的事实标准。 开发人员单元测试的质量直接关系了整个软件系统的质量。对于软件开发人 员来说，有一个良好的单元测试方法和工具，开发人员就有足够的信心不断地重 构，而且不必担心重构后回归测试的复杂性问题。各种开源测试框架，无疑是中 小企业开发人员进行单元测试的首选。应用开源测试框架，并实现每日构建，符 合了t d d 原则，不仅能够帮助开发者及时准确地发现和减少软件中潜在的缺陷 和错误，降低软件成本，减少维护代价，同时每日生成自动化测试报告，方便了 项目经理进行管理，大大提高了开发效率，并保证产品质量。 j 2 e e 是最近新兴的企业级应用构架，j 2 e e 程序的测试难是众所周知的，对 于j 2 e e 应用的单元测试要求更高的技术水平。j 2 e e 是基于组件的，面向对象的 j 2 e e 组件的单元测试包含对j s p ，s e r v l e t ，j a v a b e a n ，e j b ，数据库等组件的测试， 这些组件都是在服务器端的容器里面运行。最常用的j u n i t 单元测试框架并没有 像其它j 2 e e 组件那样被设计成在容器内执行，这给测试带来了一些问题和难点。 对于普通的j s p ，s e r v l e t 用u n i t 来测试就已经不是那么方便了。不仅要掌握更多 2 北京邮电大学硕士论文 的测试工具，还要合理运用各种测试策略才能真正快速、有效地进行单元测试。 而目前对j 2 e e 应用进行单元测试的资料很少，或是例子很简单，几乎没有对应 于大型项目的成型单元测试解决方案。对j 2 e e 组件单元测试的实施的经验非常 缺乏，因此很有必要围绕实际项目中j 2 e e 组件单元测试进行研究和探讨。 本课题正是对各种开源单元测试框架进行研究，提出通用的j 2 e e 组件单元 测试解决方案，并结合构建工具实现测试的自动化。可以预见，本课题的研究不 但可以更加快速有效的对j 2 e e 组件进行单元测试，而且有利于项目进行重构、 回归测试以及项目采用极限编程方法论，将会具有广阔的应用前景，产生显著的 经济效益和社会效益。 1 2 论文的主要工作 本论文的思路是针对目前开源自动化单元测试框架进行研究，给出对j 2 e e 应用项目进行单元测试自动化的解决方案。最后将单元测试自动化的解决方案结 合各种测试策略，为一个基于s t r u t s 的j 2 e e 应用项目编写单元测试用例，并实 现每日构建，证明了对j 2 e e 应用进行单元测试的可行性和必要性。主要的工作 包括如下几个方面： 1 分析在x p ( e x t r e m ep r o g r a m m i n g ) 过程中被广泛使用的单元测试框架 j u n i t 工作原理及其使用基础，分析比较基于j u n i t 的扩展测试框架：容器测试工 具c a c t u s 、数据库测试工具d b u n i t 、s t r u t s 框架测试工具s t r u t s t e s t c a s e 等。 2 单元测试策略的研究，包括：s t u b 、m o c ko b j m 、i n - c o n t a i n e rt e s t i n g 。仅 仅知道单元测试工具工作原理以及如何把他们用在简单的例子上，这些是远远不 够的，当我们要用它来真正测试一个项目时候需要发展一套测试策略，把各个功 能分离出来从而孤立的测试它们。 3 构建工具的研究。分析比较a n t ，m a v e n , c r u i s e c o n t r o l 等构建工具，制 定适合项目的构建文件。 4 针对以上技术的研究，提出利用开源工具实现的j 2 e e 应用自动化单元测 试解决方案，为基于s t r u t s 的j 2 e e 应用项目系统编写单元测试用例，并实现对 所有测试用例的每日构建。 北京邮电大学硕士论文 2 1 极限编程 第二章极限编程与软件测试 二十世纪九十年代末，一些软件工程专家提出了“敏捷软件工程( a 舀l e s o f t w a r ee n g i n t z r i n g ) ”的概念，将其开发方法称之为“敏捷软件开发( a g i l e s o l i w a r ed e v e l o p m e n t ) ”敏捷开发过程的方法很多，主要有：s c r u m ，c r y s t a l ， 特征驱动软件开发( f e a t u r ed r i v e nd e v e l o p m e n t ，简称f d d ) ，自适应软件开发 ( a d a p t i v es o f t w a r ed e v e l o p m e n t ，简称a s d ) ，以及最重要的极限编程( e x t r e m e p r o g r a m m i n g 简称x p ) 。极限编程是于1 9 9 8 年由s m a l l t a l k 社群中的大师级人物 k e n t b e c k 首先倡导的。x p 是敏捷开发过程中最敏捷的一种软件开发过程，由四 种价值观和一组实践方法来定义。与传统的软件开发方法不同，x p 摒弃了大多 数重量型过程中的中间产物( 诸如干特图、状态报告，以及需求文档等) 来提高 软件开发速度。由于x p 的迭代特性使得其能够在开发过程中对需求的变化有很 好的适应性，从而x p 的目标便是：在最短的时间内将较为模糊、变化较大的用 户需求转化为符合用户要求的软件产品。 极限编程将一些实践证明最为行之有效的方法有机的融合在了一起，并且将 其提升到了理论的高度，从而促进软件领域的开发。在极限编程中处于核心地位 的测试驱动开发( t d d ) 以测试作为开发过程的中心，以测试先行和重构 ( r e f a c t o r i n g ) 作为核心思想，对软件开发提出了一种崭新的思路。这种高效的 软件开发过程在降低软件开发的难度、解决软件开发危机以及保证软件质量等方 面具有的优势使得它们在近几年逐步流行起来。 极限编程基于4 个关键价值：沟通、简单、反馈和勇气。 极限编程基于5 条原则：快速反馈、简单假设、增量改变、包容变化和质保 工作。极限编程包括1 2 个实践领域：计划的制定、小版本、简单设计、测试、 持续整合、重构、配对编程、代码共享、每周只工作4 0 小时、现场客户、隐喻 和编码标准。 当采用极限编程后，首先关心的领域便是测试。编写系统需要的测试开始， 这些测试针对那些对系统进行功能添加，重构或者修复错误的代码。关键是在采 用极限编程前把自动测试慢慢地加入编写的代码中，并且总在新的代码开发完成 后使用自动测试。不要编写针对系统中不存在的代码的测试。稍后，开始整合测 试，需要自动化的构建，测试和整合过程。 4 北京邮电大学硕士论文 2 2 测试驱动开发 x p 中对测试驱动开发是这样定义的：测试驱动( t e s td r i v e nd e v e l o p m e n t ) ， 在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都可以通 过。x p 中有两种测试：单元测试和功能测试。程序员要经常编写单元测试用例， 而且应该将单元测试尽量自动化，并提供测试成功或失败的明确结果。在每一个 迭代版本推出后，应该让用户协助提出功能测试用例。 传统的测试方法是设计了一个应用程序，然后创建几个测试来验证我们的设 计。这些测试帮助改善了最初的设计，很快，当设计实现的时候有经验的程序员 都会同时想到如何测试这个类。在这种方法论下，越来越多的开发者从利于测试 的设计跃迁到测试驱动开发。 测试驱动开发( t d d ) 的两个核心思想如下： 首先是测试先行的思想。 测试主要针对单元( 最小的可测试软件元素) 实施测试。它所测试的内容包 括内部结构( 如逻辑和数据流) 以及单元的功能和可以观测的行为。测试先行一 改传统开发模式的单元测试在编写代码之后进行，而将单元测试的编写移至编写 正式代码之前。以这样的思路进行软件开发，可以产生以下影响： ( 1 ) 程序中的每一项功能都有测试来验证操作的正确性。这个测试可以给以 后的开发提供支援。无论何时因疏忽破坏了某些已有的功能，它就会告诉开发人 员。开发人员可以向程序中增加功能，或者更改程序结构，而不用担心在这个过 程中会破坏重要的东西。测试告诉开发人员程序仍然具有正确的行为。这样，开 发人员就可以更自由地对程序进行改进。 ( 2 ) 测试先行可以迫使开发人员使用不同的观察点。开发人员必须从程序调 用者的有利视角去观察将要编写的程序。这样，开发人员就会在关注程序功能的 同时，直接关注它的接口。通过测试先行，就可以设计出便于调用的软件。 ( 3 ) 通过测试先行，开发人员就迫使自己把程序设计为可测试的。把程序设 计为易于调用和可以测试的，是非常重要的。为了成为易于调用和可以测试的， 程序必须和它的周边环境解藕。这样，测试先行迫使开发人员解除软件中的藕合。 测试先行的另一个重要效果，是测试可以作为一种无价的文档形式。如果想 知道如何调用一个函数或者创建一个对象，会有一个测试予以展示。测试就像一 套范例，它帮助其他程序员了解如何使用代码，这份文档是可编译、可运行的。 因此，测试驱动开发的精髓在于：将测试方案设计工作提前，在编写代码之前先 做这一项工作，从测试的角度来验证设计，推导设计。同时将测试方案当作行为 的准绳，有效地利用其检验代码编写的每一步，实时验证其正确性，实现软件开 发过程的“小步快走”。 其次是重构的思想。 5 北京邮电大学硕士论文 重构就是在不改变外部行为的条件下对现有工作代码进行修改的过程。换言 之，就是对如何做而不是做什么进行修改。重构的目的就是改善内部结构。 重构在两个方面与测试驱动开发密切相关： ( 1 ) 采用尽可能简单的方法来让测试获得通过，之后通过重构来对代码进行 整理，大部分工作是消除那些为使测试通过而引入的重复代码。 ( 2 ) 如果采用测试驱动开发方法来开发软件的话，那么就有了由测试所构成 的可以让开发人员放手进行重构的安全网。在三神情况下要进行重构： 首先，当存在重复的时候。 第二，当觉得代码或代码所表达的意图不清楚的时候，代码是最重要的可交 付的内容。因此，代码必须尽可能地清晰和易于理解。采用测试驱动开发能够帮 助开发人员清晰地表达自己的意图，因为在编写代码的时候，开发人员强迫自己 考虑类的接口而不是实现。开发人员有机会站在使用这个类的用户的立场上来判 定什么才是最有意义的，而不是陷入具体的实现细节中去。 第三，当代码中存在不尽如人意的各种特征的时候。比如：类的尺寸过大、 方法过长等。重构是一小步一小步进行的。这样开发人员就能够尽可能早地在引 入错误的时候知道这一切。通过采用短小的步骤，开发人员就能知道某一问题究 竟是具体由什么导致的，那就是开发人员最近一步的工作所导致的。开发人员必 须恢复到正确的代码，然后重新尝试这一步的重构工作。 2 3 开发周期与测试 对于测试，x p 要求体现出测试先行( t e s tf i r s t ) 的特点，这也是测试驱动开 发方式的核心所在。开发人员在编写代码之前和开发过程中设计单元测试代码 客户在确定功能之后就进行功能测试的设计。 典型的开发周期如图2 一l 所示。 | b u i l da l l ，一圄 = 习r 翮 p r e 山- ) p r 惭o d u m c t 0 n j i i 一懋a c c e 璐p t a 滁n c e 8 9 整龃蛐豳蝴函甾幽越山土础淘墨互墨墨= 盘皇= = 墨墨一 6 紫踹鼍 北京邮电大学硕士论文 开发平台就是编码的场所。它包含开发者的工作站。它的一个重要的功 能是提交或c h e c ki n ，这样的提交一天中会有几次，提交到公共源代码控制管理 ( s c m ) 工具( c v s 、v s s 等等) 。 集成平台吝个平台的目的是集成各个不同部分来构建应用程序( 不同的 部分可能由不同的团队开发) 并且确保它们在一起可以协调地工作。这一步是很 有价值的，因为通常能在这里发现问题。因为它很重要，所以通常希望它能自动 执行，称为持续集成。 验收平台压力测试平台取决于项目预算，这可以是一个或两个平台。压 力测试平台在加载以后执行应用程序，并验证它是正确的( 从尺寸和响应时间来 看) 。验收平台就是项目的客户验收整个系统并签字的场所。 成品( 前) 平台成品前平台是成品前最后的测试地。它不是必需的，很 小或非关键性的项目没有它也行。 在开发平台上，执行逻辑单元测试( 这些测试是能脱离环境进行的) 。这些 测试执行的非常快，通常从i d e 来执行它们以验证对代码所做的任何改动没有 损坏其他部分。在提交代码到公共源代码控制管理工具之前，也可以通过自动构 造来执行它们。也应该执行集成单元测试，但是，这通常需要花更多的时间，因 为我们需要建立一部分环境( 数据库，应用程序服务器等等) 。在实践中，我们 将会执行的只是所有集成单元测试的一个子集，包含所有你编写的新的集成单元 测试。 集成平台通常会自动运行构造过程，生成包，配置应用程序并且执行单元测 试和功能测试。通常，只是所有功能测试的一个子集在集成平台下运行，因为相 对于目标平台，它只是一个简单的平台，缺少一些元素( 例如：它可能缺少访问 某一个外部系统的连接) 。所有类型的单元测试都应该在集成平台下运行( 逻辑 单元测试、集成单元测试、功能单元测试) 。 在验收平台压力平台上，将执行和集成平台相同的测试。此外，你还要运行 压力测试和负荷测试。验收平台同最终的运行平台非常相似，并且能够执行更多 的功能测试。 2 4 测试的种类 如图2 - - 2 所示，勾画出软件测试的五种类型n 。位于最外面的软件测试在整 个范围中是最广的，最里面的软件测试在范围上是最小的。从最里面的方框移到 最外面的方框时，软件测试需要进行更多的功能性测试，也需要构建应用程序的 更多部分。 7 北京邮电大学硕士论文 图2 2 软件测试五种类型【l 】 单元测试单元测试主要关注的是从内部测试代码( 白盒测试) ，这种行 为不可避免的和编写代码相互联系并且同时发生。单元测试能够确保应用程序在 一开始就处在测试中。 单元测试分为三种，如图2 3 所示：逻辑单元测试( 检查代码逻辑性，针 对单个方法) ，集成单元测试( 真实环境下两个组件相互交互的测试) ，功能单元 测试( 确认输入- 响应) 。 图2 3 单元测试三种类型 严格地说，功能单元测试不是纯粹的单元测试，也不是纯粹的功能测试。它 们相对于纯粹的单元测试而言更多地依赖外部环境。但是它们不像纯粹的测试那 样检查完整的工作流。例如：s t r u t s t e s t c a s e 框架，它提供运行s t r u t s 配置的功能 单元测试。这些测试告诉开发者控制器正在调用相应的a c t i o n ，并且指向预期的 页面，但是不保证这个页面被正确地显示。 北京邮电大学硕士论文 集成测试一单个的单元测试是一个很重要的质量控制手段，但是当几个不 同的工作单元合并到一个工作流中的时候，组件之间就会相互影响，这就是进行 集成测试。 通常集成测试包括测试对象如何交互( 实例化多个对象，然后一个对象调用 另一个对象的方法) ，服务如何交互( 应用程序布署到容器，同时连接到数据库 等外部资源) ，子系统如何交互。 正如同更多的交通事故发生在十字路口，单元发生相互影响的结点也是软件 事故的多发区。理想情况下，集成测试应该在单元被编码前就定义好。可以针对 测试来编码，这能够极大地增加程序员写出行为良好的对象的能力。 功能测试一功能测试检查在公共a p i 的边界处的代码。通常情况下，这等 于测试应用程序用例。 功能测试通常和集成测试结合在一块的，来测试框架结构、图形用户界面和 子系统。 压力负荷测试一应用程序的功能能够正确执行是很重要的，但是当多个用 户同时执行时效果又会如何呢? 大多数压力测试检验应用程序能否在短时间内 响应用户的大量请求。通常，这是由一些特定的软件来执行。比如，j m c t e r 能够 自动地发送设定好的请求以及跟踪应用程序的响应时间。 压力测试通常在一个单独的环境中执行。这种测试环境往往具有比典型的开 发环境更多的控制。它必须跟运行的环境尽量相似。如果两个环境很不一样的话， 测试也就没有意义了。 其它类型的性能测试可以在开发环境下执行。p r o f i l e r 能够在应用程序中寻找 瓶颈，程序开发者能够尽量进行优化。网上有很多p r o f i l e r 供下载使用。 从测试的角度看，用p r o f i l e r 能够让你先知先觉，帮助在真正的测试之前就 发现一些潜在的问题。首先证明一个特定的瓶颈存在，然后证明这个瓶颈已经被 消除。 验收测试一验收测试是所有其它测试的超集。通常从功能和性能开始，它 要确保应用程序已经满足了用户提出的任何要求。验收测试通常由用户或用户的 代理人来进行。 9 北京邮电大学硕士论文 第三章相关开源技术研究 自动化测试框架( a u t o m a t e dt e s t i n gf r a m e w o r k ) 就是可以自动对代码进行 单元测试的框架。在传统的软件开发流程中，需求、设计、编码和测试都有各自 独立的阶段，阶段之间不可回溯，如果时间允许，可以尽可能的随心所欲的测试， 传统软件测试方法对单元测试自动化不是很重视。但是新的软件开发流程中引入 了迭代开发的概念，并且项目迭代周期短，对代码要进行频繁的重构，这就要求 单元级测试必需能够自动、简便、高效的运行，否则重构就是不现实的。 自动化测试框架，它应该简单到实现人员或者测试人员按一个按钮就能完成 所有的测试工作，并且输出清晰的测试结果。所以，还有必要以某种方式把测试 用例( t c s t c a s e ) 组织成一个测试包( t e s t s u i t e ) ，然后才能很方便的自动运行它 们。自动化测试框架应该支持简单操作，向测试包中加入新的测试用例( 加多少 都可以) ，而且不影响测试包的正常运行。自动化测试框架应该支持测试包的随 意组合，也就是说一个测试包可以包含其它的测试包。 开源社区中开源测试框架越来越多，主流的单元测试框架有j u n i t 、c a c t u s 、 h t t p u n i t 、j m e t c r 、j u n i t p c r f 等，针对s t r u t s 项目的单元测试框架有s t r u t s t e s t c a s e 。 下面就对它们进行分析。 3 1d u n i t 单元测试框架 j u n i t 是一个优秀的单元级测试框架，更严格地说，kj n i t 是用于单元级测试 的开放式框架，它包含以下特征： 使用断言方法，判断期望值和实际值差异，返回b o o l e a n 值。 测试驱动设备使用共同的初始化变量或者实例。 测试包结构便于组织和集成运行。 运行图形交互模式和文本交互模式。 u n i t 由6 个包组成，分别为j u n i t a w t u i 、j u n i t s w i n g u i 、j u n i t t c x t u i 、 j u n i t e x t e n s i o n s 、j u n i t f r a m e w o r k 、j u n i t n l n n c r 其中前三个包中包含了u n i t 运行时的入口程序以及运行结果显示界面，它 们对于，u 血使用者来说基本是透明的。j u n i t r u n n e r 包中包含了支持单元测试运 行的一些基础类以及自己的类加载器，它对于u n i t 使用者来说是完全透明的。 接下来的两个包是和使用f u n k 进行单元测试紧密联系在一起的。其中 i u n i t f r a m e w o r k 包含有编写一般t o n i t 单元测试类必须使用到的1 u n i t 类；而 i u n i t e x t e n s i o n s 则是对f r a m e w o r k 包在功能上的一些必要扩展以及为更多的功能 t o 北京邮电大学硕士论文 扩展留下的接口。 j u n i t 核心类框图如图3 1 所示： 囤3 1j o n i t 核心类框图 a s s e r t 类提供了j u n i t 使用的一整套的断言，这套断言都被t e s t c a s e 继承下 来，a s s e r t 也就变成了透明的。a s s e r t 包含很多方法，但是核心方法只有8 个： a s s e r t t r u e ，a s s e t t f a l s e ，a s s e r t e q u a l s ，a s s e r t n o t n u l l ，a s s e r t n u l l ，a s s e r t s a m e ， a s s e r t n o t s a m e 、f a i l 。其它方法都是核心方法的变种，最终都会调用这八个核心 方法。 t e s t 接口是为了统一t e s t c a s e 和t e s t s u i t e 的类型。t e s t c a s e t e s t s u i t e ，t e s t r t t l l n e r 之间的关系是：t e s tr u n l l e r 负责启动t e s t s u i t e ；t e s t s u i t e 可以运行一个或 多个t e s t c a s e s ，t e s t s u i t e 里面还可以加入其它的t e s t s u i t e ，因为t e s t c a s e 和 t e s t s u i t e 都继承了t e s t 接口；最后t e s t c a s e 里面提供了运行单元测试类的方法。 如果我们没有编写自已的t e s t s u i t e ，j u n i t 框架会为我们自动生成一个t e s t s u i t e 并自动添加和执行所有的t e s t c a s e s 。 t e s t r e s u l t 故名思意就是提供存放测试结果的地方，但是在j u n i t 中它还带 有一点控制器的功能。所有的t e s t s u i t e 都对应一个t e s t r e s u l t ，t e s t r e s u l t 负责 收集t e s t c a s e 的执行结果，t e s tr u n n e r 使用t e s t r e s u l t 来报告测试结果。 j u n i t 附带的几个t e s ti l l r t n e r 都是继承自b a s e t e s t r u n n e r 类，可以在编写的自 己的t e s tr u n n e r 时继承这个类。例如：c a c t u s 框架就是继承了这个类创建了自已 北京邮电大学硕士论文 的s e r v l e t q e s t r u n n e r 类，从而可以从浏览器中运行自已的测试用例。 t e s t l i s t e m e r 接口和t e s t r u n n e r 类一样，可以访问t e s t r e s u l t 对象报告测试结 果。t e s t r u n n e r 类实现了1 b t l i s t 接口，其它j u n i t 扩展也实现了t 豁t l i s t e n e r 。 t e s t c a s e 是常规测试中实际接触的部分。它包括f i x t u r e ( 运行一个或多个测 试所需的公用资源或数据集合) 和单元测试代码两部分。t e s t c a s e 通过s e t u p o 和t e a r d o w n 0 方法来自动创建和销毁f i x t u r e 。t e s t c a s e 会在运行每个测试之前调 用s e t u p o ，并且在每个测试完成之后调用t e a r d o w n 0 ，把不止一个测试方法放入 同一个t e s t c a s e 的重要理由就是可以共享f i x t u r e 代码。 j u n i t 的流行并不完全在于其功能的强大和简单易用，当前软件市场有很多 其它的测试工具如j t e s t 、j p r o b l e 等更加符合传统软工测试理论，并且这些工具 还提供了对单元级测试、功能级测试、集成测试的一系列的支持。传统软件工程 中测试理论和测试工具最关心的问题是程序的正确性( 执行) ，所以它们非常讲 究测试覆盖率，目的在于寻找代码中存在的b u g ，这样，它们的测试对象就被 限定为己存在代码，表现为下列执行步骤： 编写代码( 体现设计或者声明公共的接口) 。 编写单元测试代码。 运行测试。 u n i t 不仅仅只满足于验证程序的正确性或者表现为一种b u g 发现工具，它 所派生的测试代码是为了验证被测试代码的实现是否符合预定设计而存在，已经 成为一种指导设计的行为。j u m t 体现重构( r c f a c t o r i n g ) ，它的意义在下列执行 步骤中体现： 编写单元级测试代码( 体现设计或者声明公共的接口) 编写代码通过单元级测试( 测试设计) 重构的运用 重新运行测试( 不产生b u g ，不破坏原设计，不断调整编写代码) 显然j u n i t 的测试和传统软件工程中的单元测试是一个相互颠倒的过程。 每当软件变化并推出个测试版本，回归测试都需要重新进行，而且回归测 试库的测试用例也随软件功能的增加而增多。而且回归测试存在于测试每一个阶 段，被全面测试的项目中每一个类至少有一个测试类相对应，如果不能实现自动 化的回归测试，回归测试就有可能无法及时地反馈测试结果，而且频繁而重复的 手动测试还会浪费大量的资源。当回归测试自动化之后，它就可以尽可能的与软 件变化过程保持同步。一旦软件版本发生了新的改变，无需测试人员的干预，回 归测试就可以自动完成，并及时反馈结果。 上述这些要求和问题也正是j u n i t 所能实现和解决的。当然前提是要遵循 1 2 北京邮电大学硕士论文 j u n i t 的编写规范，并且结合适当的构建工具，以此来实现单元测试自动化。 3 2s t r u t s t e s t c a s e 单元测试框架 一个具有良好系统架构的j 2 e e 应用程序至少有三层组成，即表现层，商业 层和系统集成层( 包括数据存取以及和其他系统集成) 目前，s t r u t s 是应用比较 广泛，实现m v c 模式的一种技术。s t r u t sa c t i o n 主要用来完成一些简单的数据 校验、转换，以及流程转发控制。因此在对整个应用程序进行测试时，同时也要 测试s t r u t sa c t i o n 。 测试s t r u t s a c t i o n 相对测试简单的j a v a b e a n 是比较困难，因为s t r u t s 是运行 在w e b 服务器中，因此要测试s t r u t s a c t i o n 就必须发布应用程序然后才能测试。 想象一下，对于一个拥有上千个j s