（计算机应用技术专业论文）基于j2ee架构的web应用系统测试方法研究与应用.pdf

基于j 2 e e 架构的w e b 应用系统测试方法研究与应用 摘要 软件测试是计算机发展中的一门重要的学科，虽然目前有很多的测试技术 和测试方法，但还没有完全形成一个统一的行业标准，有很多的测试方法很难 在实践工程中进行应用，而很多测试工具也不能很好的与实际工作结合。同时， 随着i m e r n e t 的日益普及，基于j 2 e e 架构的大型b s 结构的w e b 应用系统越 来越多，如何对这些应用进行测试成为日益迫切的问题。 基于上述情况，本论文全面深入地分析了课题所在的w e b 应用系统一美菱 股份公司供应链管理系统，结合软件工程理论以及系统的实际情况，做出了具 体的测试方案，根据自行设计的测试用例进行了详细的测试并提出了相关的修 改建议，从而在一定程度上保证了系统的运行质量及应用价值。 本文首先介绍了传统软件测试的相关理论，紧接着论述了b s 结构的w e b 测试的基本理论依据和测试方法。通过对美菱股份公司供应链管理系统的结构、 功能的详细分析，结合j u n i t 、h t t p u n i t 两种w e b 测试框架，针对系统的特点 提出了测试方案，并对系统的网上销售子系统各个功能模块进行了全面的校验， 然后分别就单元测试和集成测试设计了测试用例。性能测试上采用了j m e t e r 测 试工具，考查了系统和服务器的承载能力。最后，论文根据测试建议，对美菱 股份公司供应链管理系统做出了相应的调整和优化。 关键词：软件测试、w e b 测试、w e b 应用系统、j 2 e e 架构 a b s t r a c t s o f i w a r et e s t i n gi sa ni m p o r t a n ts u b j e c td u r i n gt h ed e v e l o p m e n to fc o m p u t e r a l t h o u g ht h e r ea r em a n yt e c h n o l o g i e sa n dm e t h o d so ft e s t i n g ，au n i f i e di n d u s t r y s t a n d a r di sn o tc o m p l e t e l yf o r m e d al o to ft e s t i n gm e t h o d sa r ev e r yd i f f i c u l ti n p r a c t i c ef o re n g i n e e r i n ga p p l i c a t i o n s ，w h i l em a n yt e s te q u i p m e n t sa r en o tw o r k i n g p r a c t i c a l l y m e a n w h i l e ，w i t ht h ei n c r e a s i n gp o p u l a r i t yo ft h ei n t e r n e t ，m o r ea n d m o r el a r g ew e ba p p l i c a t i o ns y s t e m sb a s e do nj 2 e ea r c h i t e c t u r eu n d e rb ss t r u c t u r e a r ee m e r g e d h o wt ot e s tt h es y s t e m sb e c o m ea ni n c r e a s i n g l yp r e s s i n gi s s u e b a s e do nt h ea b o v e ，t h i sp a p e rd o e sac o m p r e h e n s i v ea n di n d e p t ha n a l y s i so f aw e ba p p l i c a t i o ns y s t e m s u p p l yc h a i nm a n a g e m e n ts y s t e mo fm e i l i n gc o ， l t d c o m b i n i n gs o f t w a r ee n g i n e e r i n gt h e o r ya n dt h er e a ls i t u a t i o no ft h es y s t e m ， t h i sp a p e rp r e s e n t sas p e c i f i ct e s tp r o g r a m ，a n dd o e sad e t a i l e dt e s t i n ga c c o r d i n gt o s e l f - d e s i g n e dt e s t c a s e s s o m er e l a t e da m e n d m e n t sa r ep r e s e n t e di no r d e rt o g u a r a n t e et h eq u a l i t yo ft h eo p e r a t i n gs y s t e ma n da p p l i c a t i o ni nac e r t a i ne x t e n t t h i sp a p e ri n t r o d u c e st h et r a d i t i o n a ls o f t w a r et e s t i n gt h e o r y , a n dt h e n d i s c u s s e st h et h e o r ya n dm e t h o d so fw e bt e s t i n gu n d e rb ss t r u c t u r e t h r o u g h d e t a i l e df u n c t i o n a la n a l y s i sa n dt h es t r u c t u r eo ft h es y s t e m ，c o m b i n i n gj u n i ta n d h t t p u n i t ，t w ow e bt e s t i n gf r a m e w o r k s ，r e s p o n d i n gc h a r a c t e r i s t i c so ft h es y s t e m ， t h e s y s t e m s o n l i n e m a r k e t i n g f u n c t i o n a l s u b s y s t e mm o d u l e sc o m p r e h e n s i v e c a l i b r a t i o ni sf i n i s h e d t h e nt h i sp a p e rd e s i g n st e s te a s e su s e do nt h eu n i tt e s t i n g a n di n t e g r a t i o nt e s t i n g j m e t e ri su s e dt o i n s p e c tt h es y s t e m sa n d s e r v e r l o a d b e a r i n gc a p a c i t ya st h et o o l so fp e r f o r m a n c et e s t s f i n a l l y , a c c o r d i n gt ot h e r e c o m m e n d a t i o n so fs u p p l yc h a i nm a n a g e m e n ts y s t e mo fm e i l i n gc o ，l t d ，t h i s p a p e rm a k e sac o r r e s p o n d i n ga d j u s t m e n ta n do p t i m i z a t i o n k e yw o r d s ：s o f t w a r et e s t i n g 、w e bt e s t i n g 、w e ba p p l i c a t i o ns y s t e m 、j 2 e e a r c h i t e c t u r e i i 插图目录 图2 - 1 测试信息流程5 图2 - 2 软件测试v 模型。9 图2 3 软件测试前置模型1 0 图2 - 4 两层a s 结构1 2 图2 - 5 三层a s 结构1 2 图2 - 6 四层b s 结构1 2 图3 - 1j 2 e e 的典型三层体系结构2 4 图3 - 2 基于组件的供应链系统的四层结构2 7 图3 3 供应链与企业e r p 系统相接轨2 9 图3 - 4 系统整体框架图2 9 图3 - 5 网上采购系统流程图3 0 图3 6 订单状态跟踪图3 1 图3 9 网上销售系统流程图3 2 图3 - 1 0 销售系统订单管理3 4 图4 1 加密解密算法的测试用例运行5 3 图4 2 获取页面内容测试用例运行5 5 图4 - 3 用户登录测试程序流程图6 0 图4 - 4 已注册用户登录测试6 1 图4 5 包含不合法用户登录测试6 l 图4 6 增加w e b 页面负载信息设置6 3 图4 7 增加定时器6 4 图4 - 8 设置h t t p 测试请求6 4 图4 - 9 增加数据库负载信息设置6 5 图4 一l o 增加j d b c 请求6 5 图4 - 1 1 设置j d b c 请求6 6 图4 1 21 0 0 0 并发用户访问w e b 页面性能测试分析图6 6 图4 - 1 31 0 0 0 并发用户访问数据库性能测试分析图6 7 图4 - 1 45 0 0 并发用户访问数据库性能测试分析图6 7 表格清单 表3 1 系统测试环境与辅助工具3 9 表4 一l 供应链管理系统功能测试校验表格4 0 表4 2j u n i t 单元测试测试环境4 8 表4 3 数据库链接的j a v a b e a n 程序4 8 表4 4 数据连接的测试用例5 0 表4 5 用户密码加密解密程序5 l 表4 6 加密解密算法的测试用例5 2 表4 7 集成测试环境5 3 表4 8 获取页面内容测试用例5 4 表4 9 通过g e t 方法带参数访问页面测试用例5 5 表4 1 0 通过p o s t 方法带参数访问页面测试用例5 6 表4 1 l 页面链接测试用例5 6 表4 1 2 页面表格内容显示测试用例5 7 表4 1 3 页面表格内容测试用例5 8 表4 1 4 销售系统登录页面表单测试用例5 8 表4 1 5 用户登录测试用例6 2 表4 1 6 系统性能测试环境6 3 表5 1 功能测试b u g 和建议列表6 8 表5 2 系统性能测试结果6 9 v l i 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的研究 成果。据我所知，除了文中特别加以标志和致谢的地方外，论文中不包含其他人已经 发表或撰写过的研究成果，也不包含为获得金a 巴工些太堂或其他教育机构的学 位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文 中作了明确的说明并表示谢意。 学位论文作者签字 撕 i辩醐骨绷f o 日 学位论文版权使用授权书 本学位论文作者完全了解金g 巴王些盘堂有关保留、使用学位论文的规定，有 权保留并向国家有关部门或机构送交论文的复印件和磁盘，允许论文被查阅或借阅。 本人授拯金罡王些盍堂可以将学位论文的全部或部分论文内容编入有关数据库 进行检索，可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文者签名：术叁五 签字吼呻6 胪日 工觯位：铎南砖栅侈词 通讯地址： 导师签名汔曝每 签字日期：b 9 年厶月f 。日 电话 邮编 致谢 本论文是在我的导师张维勇教授的悉心指导下完成的。感谢他在我们攻读 研究生学位这三年里为我们提供了良好的学习、科研环境，并把我真正带入计 算机这个五彩缤纷又充满挑战的领域。在论文的研究的各个阶段中，导师都倾 注了大量的心血并提出了许多宝贵的意见，导师严谨的治学态度，一丝不苟的 敬业精神以及平易近人的态度都给我留下了深刻的印象。在我的思想上和生活 上，导师也都给予了无微不至的关怀和支持。在此，我谨以最诚挚的心情向我 的导师张维勇教授表示衷心的感谢! 感谢分布式控制实验室的每一位老师和同学，特别感谢韩江洪老师、张利 老师、张建军老师、王征师兄、程俊师兄、聂丽平师姐、冯琳师姐，还有我朝 夕相处的同学一钱军、俞海、戴丽、许磊、时伟、杜焕军、张芬、任宇等实验 室里的同学，与他们共度的这段学习时光充实而快乐，是我一生中最难忘的回 忆。 感谢研究生十一班的每一位同学，3 年来我们共同创造了轻松、活泼的学 习环境，生活上我们互相关照。衷心希望毕业后我们依然如前，友情永存! 感 谢曹航老师3 年以来给予我的帮助。同时还要非常感谢我的朋友朱薇，没有她 的支持和鼓励，也就没有我今天取得的成绩。在论文顺利完成之际，希望能和 她一起分享其中的喜悦。 在此，我还要特别感谢我的家人，在我忙于学业、研究和准备论文的时候， 是他们给予我最有力的支持。更为重要的是，当我在学习、生活上遇到困难和 挫折时，他们总能在思想和精神上给我以安慰，使我在学业上更努力，生活上 更安定，精神上更坚强。 最后再次衷心地感谢所有关心和帮助过我的老师和同学们! i i i 梅勃 2 0 0 7 年4 月于工大 1 1 课题背景 第一章绪论 近年来，w e b 正以其广泛性、交互性、快捷性和易用性等特点越来越受到 企业和个人的青睐。w 曲应用系统己经变得越来越庞大和复杂，但激烈的商业 竞争使软件开发周期缩短，如何保证w e b 应用的正确性和可靠性成为开发过程 中一个重要的课题。由于w e b 应用具有分布、并发、多用户、异构和平台无关 等特性，因此传统的测试方法已不能胜任对w e b 应用的测试，它的新特性对软 件测试提出了新的要求，而且要比普通程序的测试复杂得多j 。 面对日益庞大、复杂的w e b 应用，如何保证w e b 应用的正确性和可靠性 成为一个重要的课题。尽管软件测试技术已有数十年的发展历史，但w e b 应用 测试却至今没有引起人们足够的重视。另外，w e b 应用通常是分布式的、并发 的、多用户的和异质的，其基础是一种无连接的h t t p 协议，w e b 应用的这些 独特的性质对软件测试提出了新的要求【2 】。因此，我们必须为测试和评估复杂 的基于w 曲的系统提出研究新的方法和技术。 1 2 课题的来源和意义 本课题来源于合肥市科技局基金项目( 合科 2 0 0 5 1 8 号) “美菱股份公司 供应链管理系统”。 随着全球化信息网络和全球化市场形成和技术变革的加速，企业面临着缩 短交货期、提高产品质量、降低成本和改进服务的压力。由于供应链上各节点 企业的分布性，决定了要进行供应链管理，必须利用现代信息技术。通过改造 和集成业务流程，与供应商以及客户建立协同的业务伙伴联盟，从而实施电子 商务，使企业能对最终用户的需求快速反应，从而在竞争中赢得先机。 在这种环境下，对美菱股份有限公司实施供应链管理系统( s u p p l yc h a i n m a n a g e m e n to f m e i l i n gc o ，l t d1 ，以帮助企业解决以上问题。 分析目前供应链管理系统在国内外的应用状况，我们认为要想使得供应链 管理系统得以成功应用，首先应让其根据企业的实际需求定制，更重要的也是 最容易忽略的一点是针对开发的供应链管理系统进行系统的功能测试和性能测 试，以确保系统的运行质量与应用价值。然而，一方面，软件测试还没有完全 形成一个统一的行业标准，有很多的测试方法很难在实践工程中进行应用，很 多测试工具也不能很好的与实际工作结合。另一方面，随着i n t e r n e t 的日益普 及，在供应链管理系统中，基于j 2 e e 架构的大型b s 结构的w e b 应用越来越 多，如何对这些应用进行测试成为日益迫切的问题。 1 3 课题研究的主要内容 “测试”是本课题的主要研究内容，主要涉及到了w e b 应用测试、j u n i t 测试框架、h t t p u n i t 测试框架三种重要的测试技术。在对系统做了详尽的功能 测试之后，由单元测试、集成测试这两个切入点引出了课题的主要测试用例。 j u n i t 和h t t p u n i t 是两种实现测试用例的主要测试框架技术。w e b 应用测试的 性能测试部分采用了典型的压力测试工具j m e t e r 。有关这三种重要的测试技术 将在下面的章节详细描述。 由于国内的w e b 测试才刚刚起步，课题作者将软件测试理论和实践相结 合，在阅读并分析了大量有关软件测试的资料及相关学术论文后，对w e b 应用 的软件测试方法与技术进行了详细的讨论和分析。实践部分运用所掌握的w e b 应用的测试理论和实现机制，以这三种测试技术为基础，结合美菱股份公司供 应链管理系统的实际情况，给出具体的系统测试方案并分别进行了详细的测试、 分析。根据测试建议，对供应链管理系统做出了相应的调整和优化。 1 4 论文的章节安排 本论文内容安排如下： 第一章，绪论。主要介绍了课题的背景、来源以及作者的主要工作。 第二章，w e b 软件测试方法与技术。首先给出了软件测试的必要性、定义 和测试信息流程三个理论点，接着从软件测试方法、策略、模型三个角度给软 件测试做了详细的总结，然后将视角扩展到w e b 软件应用领域，从而引出w e b 软件测试的相关概念，就w e b 体系结构、w e b 测试层次、w e b 测试类型三个方 面对w e b 软件测试技术作了详细的阐述。 第三章，w e b 应用系统测试方案。先用三个小节分别从系统的实现技术、实 现架构以及模块功能三个角度对本课题所研究的供应链管理系统进行全面的介 绍、分析，并针对系统的实际情况做出具体的系统测试方案，具体地描述了测 试方案中要完成的任务、测试环境与工具等。本节对整个测试流程起到了指导 作用。 第四章，w e b 应用系统的测试方案与实施。首先对系统的网上销售子系统的 每个功能模块通过表格的形式，作全面仔细的功能性校验，对未能通过校验的 b u g 均做出相应的记录。为了使本论文更具说服力和规范化，在各章节中出现 的表格以及相关的格式均采用了业界标准模板。然后分别针对单元测试和集成 测试设计了测试用例，并使用j u n i t 和h t t p u n i t 测试框架作了充分的测试。最 后，为了考察系统在大压力和大数据量情况下，应用服务器最大处理能力和系 统响应时间，同时考查不同压力情况下应用服务器处理能力和系统响应时间， 论文使用j m e t e r 工具给系统做了性能测试，并得出性能分析结果。 2 第五章，系统的测试结果和分析。本章根据第四章的测试，以报告的形式 做出了详细分析，找出了系统不完善之处，并根据测试建议作了相应的调整和 优化，使得系统更加健壮、完善。 第六章，总结与展望。最后对系统的整个测试过程做了总结，对于测试中 不尽如人意的地方在不足之处作了说明。展望则整理出没有实现但可以进一步 深究的相关测试内容。 第二章w e b 软件测试方法与技术 2 1 软件测试的必要性 随着现代社会信息技术的飞速发展，软件产品在社会中的各个领域都得到 了广泛的应用，软件与人们的生产和生活息息相关，软件产品的质量自然成为 人们共同关注的焦点。不论软件的生产者还是软件的使用者，都生存在竞争的 环境中，软件质量的好坏都具有极其重要的意义。作为软件生产者的软件开发 商为了占有市场，必须把产品质量作为企业的重要目标之一，以免在激烈的竞 争中被淘汰出局。而作为软件使用者的用户为了保证自己业务的顺利完成，当 然希望选用功能满足要求且质量可靠的软件。质量不佳的软件产品不仅会使开 发商的维护费用和用户的使用成本大幅增加，还可能产生其他的责任风险，造 成公司信誉下降，业务及客户流失，甚至给软件使用者的正常业务带来致命打 击。在一些关键应用中使用质量有问题的软件，还可能造成灾难性的后果。 为了保证软件的质量和可靠性，应力求在分析、设计等各个开发阶段结束 前，对软件进行严格的技术评审。但由于人们能力的局限性，审查不能发现所 有的错误，而且在编码阶段还会引入大量的错误。这些错误和缺陷如果遗留到 软件交付投入运行之时，终将会暴露出来。但到那时，不仅改正这些错误的代 价更高，而且往往造成很恶劣的后果p j 。 软件测试( s o f t w a r et e s t i n g ) 是发现软件中错误和缺陷的主要手段，对于查 找软件缺陷、保证产品质量，提高企业效益具有不可替代的作用，它是软件工 程过程的一个重要阶段，是在软件投入运行前，对软件需求分析、设计和编码 各阶段产品的最终检查，是为了保证软件开发产品的正确性、完全性和一致性， 从而检测软件错误、修正软件错误的过程【4 j 。软件开发的目的是开发出实现用 户需求的高质量、高性能的软件产品，软件测试以检查软件产品内容和功能特 性为核心，是软件质量保证的关键步骤，也是成功实现软件开发目标的重要保 障。 2 2 软件测试的定义 g r e e n f o r dj m y e r s 在t h ea r to fs o f t w a r et e s t i n g 一书中提到 5 1 ： 软件测试是为了发现错误而执行程序的过程； 测试是为了证明程序有错，而不是证明程序无错误； 一个好的测试用例在于它能发现至今未发现的错误； 一个成功的测试是发现了至今未发现的错误的测试。 i e e e 在1 9 8 3 年提出的软件工程标准术语中将软件测试定义为：“使用人工 和自动化手段来运行或测试整个系统的过程，其目的在于检验它是否满足规定 4 的需求或是弄清预期结果与实际结果之间的差别【6 1 。 因此，软件测试不仅是测试程序，它同时也是在软件投入运行前，对软件 需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤1 7 1 。 2 3 测试信息流程 测试信息流程如图2 1 所示，测试过程需要3 类输入【3 】： 回归测试 正确 图2 - 1 测试信息流程 软件配置：包括软件需求规格说明、软件设计规格说明、源代码等。 测试配置：包括测试计划、测试用例、测试驱动程序等。 测试工具：为了提高软件测试效率，可采用测试工具支持测试工作。其 作用就是为测试的实施提供某种服务，以减轻完成测试任务的手工劳 动。例如：测试数据自动生成程序、驱动测试的测试数据库等。 2 4 软件测试的方法 对于软件测试方法，可以从不同的角度加以分类：从是否需要执行被测程 序的角度，可分为静态测试( s t a t i ct e s t i n g ) 和动态测试( d y n a m i ct e s t i n g ) ：从测 试是否针对系统的内部结构和具体实现算法的角度，可分为白盒测试 ( w h i t e b o xt e s t i n g ) ，黑盒测试( b l a c k - b o xt e s t i n g ) 和灰盒测试( g r a y b o xt e s t i n g ) 。 2 4 1 静态测试和动态测试 静态测试的基本特征是在对软件进行分析、检查和测试时不实际运行被测 程序【引。按照进行静态测试的正式程度及其在软件生产质量管理和质量控制中 的作用，可分为工程测试、正式测试、审核测试和检查性测试。静态测试可用 于对各种软件文档的测试，常用于软件开发过程的早期阶段，主要有结构化走 通( w a l k t h r o u g h ) 和f a g a n 检查等方法。 动态测试的基本特征是通过运行软件来检验软件的动态行为和运行结果的 正确性，包括被测程序、测试数据和软件需求规约三个基本要素。根据动态测 试在软件开发过程中所处的阶段及其作用，可分为单元测试、集成测试、系统 测试、验收测试和回归测试，贯穿于整个软件开发过程的各个阶段9 1 。 2 4 2 黑盒测试 黑盒测试又称功能测试( f u n c t i o nt e s t i n g ) 、数据驱动测试( d a t a d r i v e n t e s t i n g ) 或基于规格说明的测试( s p e c i f i c a t i o n b a s e d t e s t i n g ) 。软件的黑盒测试意 味着测试要在软件的接口处进行，也就是说，这种方法是把测试对象看作一个 黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的 需求规格说明书，检查程序的功能是否符合它的功能说明【l 们。因此黑盒测试又 叫做功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误： 是否有不正确或遗漏了的功能； 在接口上，输入能否正确的接受，能否输出正确的结果； 是否有数据结构错误或外部信息( 例如数据文件) 访问错误； 性能上是否能够满足要求； 是否有初始化或终止性错误。 所以，用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出 条件中确定测试数据，来检查程序是否都能产生正确的输出。 有很多黑盒测试的技术，比如说“边界值分析”方法就是一种很有效的黑 盒测试方法，这种方法要求测试用例应该从待测试的部分软件的输入和输出的 边界或紧靠边界的地方产生。另一种方法一“等价类划分”是被广泛应用的一 种正规的方法。“等价类”是指在某个层次的抽象中可被视为相同的一些元素的 集合。“等价类划分”对与黑盒测试来说可以是一个很系统化的方法。对于软件 有很多可能输入的情况，有一种黑盒软件测试技术“因一果图”，这种技术有利 于软件工程师发现那些最容易引起错误的输入的组合。除此之外，基于图的测 试方法、比较测试、错误推测法和功能图等。 2 4 3 白盒测试 白盒测试又称为结构测试( s t r u c t u r et e s t i n g ) 、逻辑驱动测试( l o g i c d r i v e n t e s t i n g ) 或基于程序的测试( p r o g r a m - b a s e dt e s t i n g ) 。它依赖于对程序界的严密检 查，针对特定条件和循环及设计侧试用例，对软件的逻辑路径进行测试。它可 以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经 通过检查【“j 。 白盒测试一般又分为静态测试与动态测试。静态测试不实际运行软件，主 要是对软件的编程格式、结构等方面进行评估，而动态测试需要在实际环境或 实验室模拟环境中实际运行软件，并使用设计的测试用例去探测软件漏洞。其 中的静态测试主要包括代码检查、代码走读、静态结构分析和代码质量度量等。 动态测试主要包括功能确认与接口测试、覆盖率分析和性能瓶颈分析以及内存 6 分析等。 常见的白盒测试法有控制流分析、数据流分析、逻辑覆盖、域测试、符号 测试、路径分析、程序变异等。 2 4 4 灰盒测试 白盒和黑盒这两类测试是从完全不同视角点出发的，是完全对立的。这反 映了事物的两个极端。两种方法各有侧重，不能替代。但是，在现代测试理念 中，这两种测试方法往往不是截然分开的。一般地，在白盒测试中交叉使用黑 盒测试的方法，在黑盒测试中交叉使用白盒测试的方法。 灰盒测试就是这类介于白盒测试和黑盒测试之间的测试。它考虑了用户端、 特定的系统知识和操作系统。它在系统组件的协同性环境中评价应用软件的设 计【1 2 】。灰盒测试方法对有效测试w e b 应用是完整的，因为w e b 应用由大量的 组件( 包括软件和硬件) 组成。这些组件必须在设计系统的环境中测试，以便评 价它们的功能和兼容性。灰盒测试非常适于w e b 应用测试，因为它涉及到高层 设计、环境和互操作性条件等b 3 】。它能发现容易被黑盒测试和白盒测试忽略的 问题，特别是端对端的信息流问题、分布式硬件，软件配置问题以及兼容性问题。 在灰盒测试过程中通常能发现与w e b 系统密切相关的具体环境错误。最常见的 灰盒测试是集成测试。 2 5 软件测试策略 根据所设计的测试用例，利用人工测试和自动测试来对被测软件进行一系 列的测试，并记录日志结果的过程称之为执行测试。软件的测试一般有如下几 种测试策略： 2 5 1 单元测试 单元测试( u n i tt e s t i n g ) 的对象是软件设计的最小单位一模块。单元测试的 依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例， 以便发现模块内部的错误【1 4 】。单元测试多采用白盒测试技术，系统内多个模块 可以并行的进行测试【”】。单元测试任务包括：模块接口测试、模块局部数据结 构测试、模块中所有独立执行通路测试、模块的各条错误处理通路测试、模块 边界条件测试。 2 5 2 集成测试 集成测试( i n t e g r a t e dt e s t i n g ) 也叫做组装测试或联合测试，就是对各部分组 合起来的程序进行测试1 6 1 。通常，在单元测试的基础上，需要将所有模块按照 7 设计要求组装成为系统。 这时需要考虑的问题是： 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失； 一个模块的功能是否会对另一个模块的功能产生不利的影响； 各个子功能组合起来，能否达到预期要求的功能； 全局数据结构是否有问题； 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。 因此在单元测试的同时可进行组装测试，发现并排除在模块连接中可能出 现的问题，最终构成要求的软件系统。 2 5 3 系统测试 系统测试( s y s t e mt e s t i n g ) 是在软件开发完毕后，与系统中其它成分集成在 一起进行的一系列系统集成和确认测试【 】。系统测试应该由若干个不同测试组 成，目的是充分运行系统，验证系统各部件是否都能正常工作并完成所赋予的 任务。常见的系统测试有恢复测试、安全测试、强度测试、性能测试。 2 5 4 验收测试 验收测试( a c c e p t a n c et e s t i n g ) 是在用户现场，由客户执行或者参与执行的 测试，检查产品是否符合客户或最终用户的要求1 7 】。 2 5 5 回归测试 回归测试( r e g r e s s i o nt e s t i n g ) 是在软件修改和变更后进行的测试，用来确定 修改和变更后的软件是否仍然满足所有的要求，一般只是有选择地重复己有的 确认测试，而不开发新的测试1 8 1 。 2 6 软件测试模型 软件测试是软件质量保证的一个重要因素。然而在传统开发过程中，人们 仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段， 即在很多重要开发活动完成后，测试只是收尾工作，而不是主要的过程。随着 软件开发技术的不断发展，以及软件系统的规模和复杂性的不断增加，传统的 软件测试理论和技术已经不能够很好地满足开发组织在产品质量、开发成本以 及研制周期等方面的需求。因此对软件测试模型的研究与应用就显得尤为重要。 2 6 1v 模型 在软件测试方面，v 模型是最广为人知的模型。它最早由p a u lr o o k 在8 0 年代后期提出，目的在于提高软件开发的效率和效果。v 模型宣称测试并不是 一个事后弥补行为，而是一个同开发过程同样重要的过程。v 模型如下图所示： 图2 2 软件测试v 模型 在v 模型中，从右侧开始，就是测试阶段。首先是单元测试，它基于代码 的测试，最初由开发人员执行，以验证其执行程序代码的各个部分是否已达到 了预期的功能要求。集成测试目的是验证2 个或多个单元之间的集成是否正确， 并有针对性地对详细设计中所定义的各单元之间的接口进行检查。系统测试开 始以客户环境模拟系统的运行，以验证系统是否达到了在概要设计中所定义的 功能和性能。最后，当技术部门完成了所有测试工作后，由业务专家或用户进 行验收测试，以确保产品能真正符合用户业务上的需要。 v 模型从需求处理开始，在开发的每一个阶段，都要求测试人员对各开发 阶段中已经得到的内容进行测试，以保证每个环节的结果都能够达到预期的目 标，但它没有规定我们要取得多少内容，这些内容的量没有一个明确的度，完 全依靠测试人员自己决定，所以v 模型很大程度上依靠测试人员 1 9 1 o 2 6 2x 模型 x 模型的特点是从没有被文档化，其内容一开始需要从在v 模型的相关内 容中进行推断。与v 模型相比，x 模型还定位了探索性测试【2 0 i 。这是一种不用 编写测试用例和计划的特殊测试，一般来讲，主要是由有经验的测试人员进行， 这样可以帮助发现测试计划之外的一些错误。同样，x 模型也要求在测试之前 进行测试设计，但是包含了测试设计的步骤，就像使用不同的测试工具所要包 含的步骤一样。然而，一个模型和一个单独的项目计划有所不同，模型不应该 描述每个项目的具体细节，模型应该对项目进行指导和支持。所以x 模型也不 能说是一种真的模型，它也只是针对v 模型的缺陷而提出的改进建议。 9 2 6 3 前置模型 前置测试模型是在上述几种模型的基础上改进后得到的。该测试模型将开 发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关 键行为。测试模型如图2 3 所示： 图2 3 软件测试前置模型 该测试模型体现了以下几个要点【”j ： ( 1 ) 在系统分析阶段进行基于需求的测试和定义验收标准。 每一个交付的开发结果都必须通过适当的方式进行测试。需要测试的内容 除了源程序代码，还包括可行性报告、业务需求说明，以及系统设计文档等。 因此，该测试模型在系统分析阶段包括两项测试计划，首先是编写基于需求的 测试用例。这并不仅仅是为以后提交上来的程序的测试做好初始化准备，也是 为了验证需求是否为可测试的。其次是定义验收标准。在接受交付的系统之前， 用户需要用验收标准来进行验证。验收标准并不仅仅是定义需求，还应在测试 之前进行定义，这将有助于发现错误和被忽略的需求。 ( 2 ) 在设计阶段进行测试计划和测试用例的编写。 该测试模型在设计阶段包括两种主要的测试，即验收测试和技术测试，这 两种类型都需要测试计划。该测试模型的验收测试包含了三种成份：定义基于 需求的测试、定义验收标准以及验收测试用例，其中前两种都与用户需求定义 相联系，在系统分析阶段完成；而验收测试用例是由针对按设计实现的系统来 进行的一些明确操作定义所组成，这些定义包括：如何判断验收标准已经达到， 以及是否基于需求的测试已算成功完成。故验收测试的测试用例则需要在系统 设计阶段完成。 1 0 技术测试主要是针对开发代码的测试，对技术测试最基本的要求是验证代 码的编写和设计的要求是否相一致。技术测试在设计阶段进行计划和设计，并 在开发阶段由技术部门来执行。该模型包括动态的单元测试，集成测试和系统 测试。还增加静态审查、独立的q a 测试以及特别测试。q a 测试通常跟随在 系统测试之后，从技术部门的意见和用户的预期方面出发，进行最后的检查。 特别测试包括负载测试、安全性测试、可用性测试，探索性测试等等，这些测 试不是由业务逻辑和应用来驱动的，能使测试人员在测试计划之外发现更多的 错误。 ( 3 ) 在开发阶段测试执行和开发紧密结合。 该测试模型将测试执行和开发结合在一起，并在开发阶段以“编码一测试 一编码一测试”的方式来体现。也就是说，程序片段一旦编写完成，就会立即 进行测试。在技术测试计划中必须定义好这样的结合。测试的主体方法和结构 应在设计阶段定义完成，并在开发阶段进行补充和升级。最初是针对单独程序 片段所进行的相互分离的编码和测试，此后进行频繁的交接，通过集成最终合 成为可执行的程序。这些可执行程序可以进行封装提交给用户，也可以作为更 大规模和范围内集成的一部分。 ( 4 ) 让验收测试和技术测试保持相互独立 该测试模型提倡验收测试应该独立于技术测试，它们沿循两条不同的路线 来分别地验证系统是否能够如预期的设想进行正常工作。验收测试在开发阶段 ( 编码和代码验证) 的最后一步执行。这样可以提供双重的保险，以保证设计及 程序编码能够符合最终用户的需求。 该模型与原有的软件测试模型相比，有以下优点： 能使缺陷和错误尽可能早地暴露出来。 在不同的测试阶段应用不同的测试技术。 能够将一切有效信息来设计测试用例，尽可能保证了测试的完备性。 减少后期的软件维护成本。 2 7w e b 体系结构 随着w e b 应用的发展，一种新兴的体系结构：b s ( b r o w s e r s e r v e r ) 应运 而生。b i s 体系结构属于分层体系结构，本质上是一种c s ( c t l e n t s e r v e r ) 结 构，是由传统c s 结构发展而来的在w e b 上应用的特例。与w e b 应用发展相对 应，w e b 应用的b s 结构也发展了三个阶段，课题就是b s 结构。在w e b 应用 发展的初期，b s 模式只有两层，即用户浏览器和w e b 服务器，如图2 4 示。 通过浏览器，用户向w e b 服务器发送h t t p 请求，w e b 服务器接收用户端的h t t p 请求，向用户端浏览器返回所请求的页面。此时的w e b 应用都是静态的，w e b 服务器通常不需要什么处理，只是简单地传送所请求的页面。在客户端，用户 的浏览器要对页面中嵌入的j a v a s c r i p t 和v b s c r i p t 脚本进行解释执行。 图2 4 两层b s 结构 随着w e b 技术与数据库技术结合，b s 模式发展成三层，即用户浏览器和 w e b 服务器、数据库服务器，如图2 - 5 示。此时w e b 服务器功能被扩展，能够 处理和执行包含有动态脚本的页面。这些动态脚本实现与数据库连接，提交数 据请求，处理数据库返回数据的功能。数据库服务器处理动态脚本提交的数据 操纵请求，实现对数据库查询、修改、更新等功能，并返回处理结果。数据的 生成和数据的表现两部分都集成在了w e b 服务器端动态页面中，这使得动态页 面变的非常复杂，给w e b 应用测试和维护带来了困难。 图2 - 5 三层b s 结构 随着电子商务的出现，传统的三层结构已经不能满足企业级大规模应用系 统的要求，b s 模式发展成四层，即在原有三层的基础上增加了应用服务器层， 实现复杂的业务处理逻辑【2 2 1 ，如图2 - 6 所示。w e b 服务器将用户发来的请求进 行分析转换，提交给应用服务器，应用服务器调用相应的逻辑处理程序与数据 库交互，然后将逻辑处理结果返回给w e b 服务器。在实际应用中，w e b 应用 结构还会出现更加细致的分层结构，如五层等。b s 具有许多传统c s 体系结 构不具备的优点，又紧密的结合了i n t e r n e t i n t r a n e t 技术，把w e b 应用发展 带入一个崭新时代。 图2 - 6 四层b s 结构 b s 体系结构为w e b 应用测试提供了良好的可测试性机制。这是因为b s 结构采用标准的浏览器作为客户端，为测试提供了一个标准的输出界面，有利 于观察和控制w e b 应用系统的行为。但是由于功能分布在不同的服务器系统上， 不同页面间存在复杂跳转和数据传送。因此，在w e b 应用测试中不仅要测试页 面内的数据流和控制流，也要测试页面间的数据流和控制流，还有数据库操作 测试等，增加了测试难度。 2 8w e b 测试层次 根据被测试对象的不同测试顺序，测试过程被划分为若干层次。传统软件 的构成以模块为单位，开发以模块为基础。按照从局部到整体，从易到难的测 试顺序，传统软件的测试被划分为单元测试、集成测试和系统测试。目前，对 w e b 应用的层次划分尚未达成一致。但普遍认为，w e b 应用同传统测试一样， 也需要系统测试。动态w e b 应用和静态w e b 应用被划分为不同的测试层次。其 中，将动态w e b 应用划分为：模块测试( n o d u l et e s t i n g ) 、集成测试 ( i n t e g r a t i o nt e s t i n g ) 、系统测试( s y s t e mt e s t i n g ) ；将静态w e b 应用划分 为：语法测试( s y n t a c t i ct e s t i n g ) ，安全测试( s e c u r i t yt e s t i n g ) 、服务测试 ( s e r v i c et e s t i n g ) 【2 3 1 。这种划分方法将动态w e b 应用和静态w e b 应用区别开 来，采用了不同的划分标准，没有同w e b 应用构成特点和开发特点结合起来。 因此，不具备良好的可操作性，不能有效地指导测试过程。 从w e b 应用的特征出发，可以将w e b 应用测试层次划分为以下三个层次【2 4 j ： 2 8 1 页