（管理科学与工程专业论文）信息系统开发中的自动化测试应用研究.pdf

摘 软件测试是软件系统工程的一部分， 要 是一系列可以事先计划并且可以系统地 进行管理的活动，测试活动应该从产品项目立项就开始，并且随着开发活动的进 程而逐步进行。同时软件测试也是软件开发的重要环节和保证软件质量的关键步 骤，其目的是以最少的时间和人力找出软件中潜伏的各种错误和缺陷。 软件测试作为一个产业出现于8 0 年代末期，然而，我国很多软件公司对软件 测试仍然没有充分的认识。我国与其他软件产业发达国家的差距主要体现在测试 意识、测试理论的研究、大型测试工具软件的开发以及从业人员数量等方面，其 中测试意识上的差距又尤为突出。规范而高效的软件测试，是提高国内软件开发 整体质量水准的重要方法，也是使中国最终成为一个先进的软件大国的基石。 本文首先总结了软件铡试理论的发展现状，对信息系统开发过程进行了分析， 在研究自动化测试方法及工具、面向对象信息系统开发方法的基础上，指出了面 向对象信息系统开发过程中测试方面的不足，分析了信息系统开发测试方法的特 点。通过对自动化测试框架，即3 u n i t 单元测试框架及其两个扩展框架m o c ko b j e c t s 和c a c t u s 深入细致的研究，比较得出了三个单元测试框架的优缺点，综合性地提 出了信息系统中自动化测试框架和相应的实施方案。该测试框架更好的解决了信 息系统开发中单元测试的难点，实现了面向对象信息系统测试的自动化和测试过 程的可重复性。通过实际项目中的应用，证明了该方案的实用价值和可行性。 本文的内容融合了软件测试理论知识与笔者的实践经验，相信本论文的研究 对于更快速有效地实施信息系统开发自动化测试具有一定的理论意义和参考价 值。 关键词：软件测试；自动化测试；信息系统开发；d u n l t a s t u d yo nt h ea p p l i c a t i o no fa u t o m a t i ct e s ti ni n f o r m a t i o n s y s t e m a b s e r a o t s o f t w a r et e s t i n gi sap a r to fs o f t w a r es y s t e me n g i n e e r i n g ，a n di sas e r i e so fp l a n e d a n dm a n a g e da c t i v i t i e s t e s t i n ga c t i v i t ys h o u l db e g i na tt h eb e g i n n i n go ft h ep r o j e c t ， a n dg ow i t ht h ed e v e l o p i n ga c t i v i t y a tt h es a m et i m et h es o f t w a r et e s t i n gi st h e i m p o r t a n tp r o c e d u r eo fs o f t w a r ed e v e l o p m e n t ，a n di ta i m sa tf i n d i n go u ta l lk i n d so f e r r o r sa n df a u l t sw i t ht h el e a s tt i m ea n dl a b o r s o f t w a r et e s t i n ge m e r g e da sak i n do fi n d u s t r ya tt h ee n do f1 9 8 0 s ，b u tm a n y s o f t w a r ec o m p a n i e si nc h i n ad on o tu n d e r s t a n dt h ei m p o r t a n c eo fi t t h ed e f e c t i o no f s o f t w a r et e s t i n gi n0 1 1 1 c o u n t r yi n c l u d e st e s t i n gc o n s c i o u s n e s s ，t h es t u d yo ft e s t i n g t h e o r y ，t h ed e v e l o p m e n to fl a r g et e s t i n gt o o l s ，a n da m o u n to ft e s t i n gw o r k e r s t h e d i f f e r e n c eo f t e s t i n gc o n s c i o u s n e s si sv e r yn o t a b l e p l a n e da n de f f i c i e n ts o f t w a r et e s t i n g i st h ei m p o r t a n tm e t h o dt op r o m o t et h el e v e lo fs o f t w a r ed e v e l o p m e n ti no u rc o u n t r y ， a n dab a s e m e n tf o ro u rc o u n t r yt og r o wu pa n db e c o m ea g r e a ts o f t w a r ec o u n t r y t h i st e x ts u m m a r i z e dt h et h e o r i e so ft h es o f t w a r et e s t i n gi nt h ep a s t ，a n a l y s i st h e p r o c e s so fi n f o r m a t i o ns y s t e md e v e l o p m e n t ，i nt h eb a s eo fs t u d y i n gt h et e c h n o l o g ya n d t o o l so fa u t o m a t i cs o f t w a r et e s t i n ga n do r i e n t - o h j e c tp r o c e s so fd e v e l o p i n gi n f o r m a t i o n s y s t e m ，p o i n t e do u tt of a c et ot h eo b j e c ti n f o r m a t i o ns y s t e md e v e l o p m e n tp r o c e s si nt h e s h o r t a g eo f t h et e s t ，a n a l y z e dt h ei n f o r m a t i o ns y s t e md e v e l o p m e n tt e s tc h a r a c t e r i s t i c so f m e t h o d b yi n t r o d u c i n ga n da n a l y z i n gt of a c et ot h et h e o r i e so ft h ea u t o m a t i cs o f t w a r e t e s t i n ga n d t h ec o n t e n t sa n dt h ec h a r a c t e r i s t i c so f t h et e c h n i q u ea n dm o d u l eo f j 2 e e ，p u t f o r w a r dt h ei n f o r m a t i o ns y s t e mt ot e s tt h ef r a m ei nt h ea n t o m a f i c t h i st e x tp a s s e st h e r e s e a r c ht ot h ea u t o m a t i o nt e s t st h ef r a m e ，n a m e l yt h ej u n i tu n i tt e s tf r a m ea n di tt h e d u a le x p a n dt h ef r a m em o c ko b j e c t sa n dc a c t u s e st h o r o u g h i yt h ed e l i c a c y ，c o m p a r i s o n t h r e eu n i t st e s tt h em e r i ta n ds h o r t c o m i n go ft h ef r a m e ，c o m p r e h e n s i v eg r o u n dp u t f o r w a r dt h ei n f o r m a t i o ns y s t e md e v e l o p m e n tt h ea u t o m a t i o nt e s to fi m p l e m e n tp r o j e c t t h ef r a m e b e u e rr e s o l v e dt h ed i f f i c u l t yo ft h eu n i tt e s t i n gi nt h ed e v e l o p m e n to f i n f o r m a t i o n s y s t e m ，a n di m p l e m e n t e dt h ea u t o m a t i ct e s t i n go fo b j e c t o r i e n t e d i n f o r m a t i o ns y s t e mt e s t i n ga n dt h er e u s eo ft e s t i n gp r o c e d u r e b ya p p l i c a t i o ni na c t u a l p r o j e c t ，p r o v e dt h ev a l u ea n df e a s i b i l 时o f t h ei m p l e m e n tp r o j e c t c o m b i n et h et h e o r i e so fs o f t w a r et e s t i n ga n dt h ea u t h o r sp r a c t i c e s ，t h ep a p e r w o u l db em e a n i n g f u la n dc a l lp r o v i d eau s e f u lr e f e r e n c ef o r i m p l e m e n t i n gj 2 e e c o m p o n e n t su n i tt e s tm o r eq u i c k l ya n de f f i c i e n t l y k e yw o r d s ：s o f t w a r et e s t i n g ；a u t o m a t i ct e s t ；i n f o r m a t i o ns y s t e md e v e l o p m e n t j u n i t 大连海事大学学位论文原创性声明和使用授权说明 原刨性声明 本人郑重声明：本论文是在导师的指导下，独立进行研究工作所取得的成果， 撰写成博士，硕士学位论文 ! 信息丕统珏筮生的自动也测达廛周硒塞：。除论文 中已经注明引用的内容外，对论文的研究做出重要贡献的个人和集体，均已在文 中以明确方式标明。本论文中不包含任何未加明确注明的其他个人或集体已经公 开发表或未公开发表的成果。 本声明的法律责任由本入承担。 论文作者签名：劲镝氏撕年了月盯日 学位论文版权使用授权书 本学位论文作者及指导教师完全了解“大连海事大学研究生学位论文提交、 版权使用管理办法”，同意大连海事大学保留并向国家有关部门或机构送交学位论 文的复印件和电子版，允许论文被查阅和借阅。本人授权大连海事大学可以将本 学位论文的全部或部分内容编入有关数据库进行检索，也可采用影印、缩印或扫 描等复制手段保存和汇编学位论文。 保密口，在年解密后适用本授权书。 论文作者签名：鹫局氏导师签名：? 髻彩彩 日期：w f 年；月呵刍 第1 章绪论 1 1 软件测试的意义及现状 软件测试是软件系统工程的一部分，是一系列可以事先计划并且可以系统地 进行管理的活动，测试活动应该从产品项目立项就开始，并且随着开发活动的进 程而逐步进行【1 。软件测试也是软件开发的重要环节和保证软件质量的关键步骤， 其目的是以最少的时间和人力找出软件中潜伏的各种错误和缺陷。 软件测试作为一个产业出现于8 0 年代末期，然而，我国很多软件公司对软件 测试仍然没有充分的认识。通常意义上讲，一个成熟软件的运行寿命至少有1 0 年 以上。而软件寿命的长短，则更多地取决于软件开发质量的好坏。软件开发是一 个循序渐进的过程，每开发一步，都应当由相应的测试方法进行测试。根据 i e e e a n s i 标准，软件测试的定义是【2 】：“使用为发现错误所选择的输入和状态的 组合而执行代码的过程”，这明确指出软件测试目标是发现软件错误、检验软件是 否满足需求。软件测试在软件生命周期中占有非常突出的重要地位，是保证软件 质量的重要手段。规范而高效的软件测试，是提高国内软件开发整体质量水准的 重要方法，也是使中国最终成为个先进的软件大国的基石。 软件测试的管理和技术在全球的发展是不平衡的，在软件产业发达的国家， 软件测试已经成为新兴产业。典型的软件开发项目都拥有一个独立的测试团队， 测试人员的数量有的可以达到一个开发人员配备两个测试人员。软件测试工作量 往往占软件开发总工作量的4 0 以上。而在软件开发的总成本中，用在测试上的 开销要占3 0 到5 0 。在测试团队中拥有自己的测试经理，作用和开发团队中的 项目经理一样，负责测试小组的管理工作以保证测试工作保质保量的完成。例如： 编写测试计划、制定测试方案、协调测试人员和开发团队的关系等。 我国与其他软件产业发达国家的差距主要体现在测试意识、测试理论的研究、 大型测试工具软件的开发以及从业人员数量等方面，其中测试意识上的差距又尤 为突出。很多软件公司中测试工作都是由开发人员兼做，或者有少量测试人员， 月薪比开发人员也要低很多，对测试工作的重视程度远不及发达国家。另外，对 测试工作的不重视必然带来对软件测试管理的研究投入不够，在测试理论和方法 上还不尽完善，没有适合中国软件的测试理论、方法、工具，总是照搬国外的理 论用在我们的测试工作中，使用英文原版的测试工具，这些也都造成了我们和先 进国家之间的差距。面对软件的规模越来越大，应用的复杂度和集成性越来越高， 各种新的软件开发技术不断应用，那么如何提供高效、完备的测试，已经成为我 国软件测试行业面临的巨大挑战。 1 2 本课题的研究背景 由于开发环境以及软件复杂度等多种原因。最早的软件开发人员并没有意识 到软件开发还需要测试这个重要的环节。在2 0 世纪6 0 年代，通用硬件几乎没有， 程序员们主要在大型主机、小型机和专用计算机上编写代码，软件只是根据具体 应用而编写程序，强调的主要是编程技巧，因此对软件的开发也没有什么系统化 措旅f 3 】。软件测试最多只是程序员在编写代码结束后的由自己进行的一种验证正确 性的活动，那时没有专门的测试理论和技能，没有测试流程规范，更没有专职测 试工程师，往往把调试和测试混为一谈，程序员在系统开发过程中都是根据自己 的经验进行猜测和验证。 2 0 世纪6 0 年代中期到7 0 年代中期，小型计算机在众多的领域得到了应用， 计算机系统也从单用户发展成多用户以及计算机网络，并且出现了实时系统和数 据库管理系统。随着软件开发技术的不断进步，人们逐渐感觉到软件测试对保障 软件质量来说是一项至关重要的环节。这个阶段开发的软件仍然不复杂，但人们 已开始思考开发流程问题，并提出“软件工程s o f t w a r ee n g i n e e r i n g ”的概念。2 0 世纪7 0 年代，测试理论和测试技术开始进入创立、发展和探索阶段。1 9 7 2 年，b i l l h e t z e l 博士在n o r t hc a r o l i n a 大学举行了第一次以软件测试为主题的正式学术会 议，标志着软件测试理论和技术开始成为业界的研究对象。此后，各种软件测试 理论有如雨后春笋般出现，各种相关的学术会议不断举行。1 9 7 9 年g l e n f o r dm y e r s 出版了他的大作t h e a r to f s o f t w a r et e s t i n g ) ) 。这本书总结了众多的测试经典方法 并第一次提出了软件测试的目的在于证伪，而非证真，也就是说测试就是为了发 现错误，这是测试观念的一次突破。 2 0 世纪8 0 年代开始，随着p c 和w i n d o w s 操作系统的诞生，计算机开始进入 p c 时代。与此相应的是，以微软为代表的新一代软件公司开发了大量基于p c 机 的应用软件。软件的规模成指数级增长，超过几百万行甚至几千万行代码的软件 开始出现。软件已经逐步成为项产业，软件种类和规模的增长对软件测试工作 提出了更加严格的要求。为适应这一要求，软件企业开始成立q a ( 质量保证) 或 s q a ( 软件质量保证) 部门来保证软件产品的质量，再后来，q a 的职能转变为流 程监控，而软件测试则从中分离出来成为独立的岗位，在软件项目中设置专职的 测试人员成为一种共识。这个时期，测试技术和理论相应地也有了质的飞跃，业 界开始形成了一些公认的测试经典理论，构成了现有的软件测试理论的基本框架。 从2 0 世纪9 0 年代中期开始，随着互联网的普及，我们进入了网络时代，全 球数以万计的计算机用户被网络连接在一起，相应的计算机软件也迅速从单机或 局域网模式向网络模式迁移。基于i n t e m e t 的分布式计算技术被广泛应用在各种类 型的软件中，这使得软件本身变得比以往任何时代都要复杂。在网络时代，软件 测试耍解决更多的技术和理论难题，人们必须仔细研究远程测试、负载平衡测试 等以往很少关注的领域，软件铡试开始从单纯的技术环节演变为一个需要完整的 理论体系和系统的系统工程，从而真正成为一门专深的科学领域。 从广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。 如：设计评审、系统测试。从狭义上讲 4 】，铡试是对软件产品质量的检验和评价。 它一方面检查软件产品质量中存在的质量问题，同时对产品质量进行客观的评价。 1 3 本文研究内容 1 3 1 本文研究目标 在对软件测试理论及自动化测试方法、工具分析和总结的基础上，将现有的 自动化软件测试方法和工具应用到信息系统开发的整个过程中去，解决信息系统 开发中的自动化测试问题，特别是面向对象的信息系统开发，进而能够更全面的 对软件进行测试，用自动化测试替代手工测试，减轻编码人员及测试人员的工作 量，增加编码人员的测试信心，提高软件开发的效率与软件的质量。增加软件的 可复用性。 1 3 1 本文主要研究内容 在研究软件测试和面向对象信息系统软件开发的有关理论及现有测试技术的 基础上给出信息系统开发中自动化测试框架，对组合框架，即当前主流的单元 测试框架j u r t i t 及其扩展框架m o c ko b j e c t s 和c a c t u s 的特点、实现方法和工作原 理进行研究，并分析比较这三者的优缺点。在遵循组件测试思想的前提下，对j 2 e e 组件单元测试进行研究，重点关注容器对j 2 e e 组件测试的影响。针对不同类型的 j 2 e e 组件，探讨如何合理使用测试框架进行单元测试以及解决因j 2 e e 组件与容 器交互而带来的单元测试难点。针对j 2 e e 组件的单元测试给出具体的实施方案， 并在实际项目中得到应用。 1 4 本文组织结构 本文章节及内容的安排如下： 第一章：绪论。概述软件测试的意义及现状，分析本课题的研究背景，并对 本文的研究目标和研究内容进行了概括给出了本文的组织结构。 第二章：软件测试理论与信息系统开发。对软件测试的相关概念进行探讨， 总结了软件测试技术理论中流行的几个测试模型，重点介绍了自动化测试技术， 并对信息系统中软件测试方法和技术进行探讨。 第三章：自动化测试技术。介绍了d u n i t 单元测试框架的特点、系统结构、 设计模式以及自动化执行过程，对m o c ko b j e c t s 测试框架以及c a c t u s 测试框架 进行了介绍。 第四章：信息系统自动化测试模型，重点给出了信息系统开发自动化测试模 型，对基于j 2 e e 组件技术的信息系统开发中的单元测试方案和实施进行了论述。 第五章：总结。对本文的研究工作进行了总结，并对本文研究内容进行工作展 第五章：总结。对本文的研究工作进行了总结，并对本文研究内容进行工作展 望。 第2 章软件测试理论与信息系统开发 2 1 软件测试的相关概念 2 1 1 软件测试定义 1 9 8 3 年i e e e 对软件测试的定义为：软件测试( s o t t w a r et e s t i n g ) 是使用人工 或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需 求或是弄清预期结果与实际结果之间的差别。软件测试的两个基本职责：验证和 确认。验证( v e d f i c a f i o n ) 是保证开发过程中某一具体阶段的产品与该阶段和迁移 阶段的需求一致。确认( v a l i d a t i o n ) 是保证最终得到的产品满足系统需求。 现代的软件开发工程是将整个软件开发过程明确的划分为几个阶段，将复杂 问题具体按阶段加以解决。经验证明，软件的质量不仅是体现在程序的正确性上， 它和编码以前所做的需求分析、软件设计密切相关。因此，为了保证软件的质量， 我们应该着眼于整个软件生存期，特别是着眼于编码以前的各开发阶段的工作。 这样，软件测试的概念和实施范围必须扩充，应该包括在整个开发各阶段的复查、 评估和检测翻。由此，广义的软件测试实际是由确认、验证、测试三个方面组成。 具体说来，确认是评估将要开发的软件产品是否是正确无误、可行和有价值的。 验证是检测软件开发的每个阶段、每个步骤的结果是否正确无误，是否与软件开 发各阶段的要求或期望的结果相一致。测试与狭隘的测试概念统一，通常是经过 单元测试、集成测试、系统测试三个环节。 在整个软件生存期，确认、验证、测试分别有其侧重的阶段。确认主要体现 在计划阶段、需求分析阶段、也会出现在测试阶段；验证主要体现在设计阶段和编 码阶段；测试主要体现在编码阶段和测试阶段。事实上，确认、验证、测试是相 辅相成的。确认无疑会产生验证和测试的标准，而验证和测试通常又会帮助完成 一些确认，特别是在系统测试阶段。 面向对象技术是种全新的软件开发技术，正逐渐代替被广泛使用的面向过 程开发方法，被看成是解决软件危机的新兴技术。面向对象技术产生更好的系统 结构，更规范的编程风格，极大的优化了数据使用的安全性，提高了程序代码的 重用，一些人就此认为面向对象技术开发出的程序无需进行测试。应该看到，尽 管面向对象技术的基本思想保证了软件应该有更高的质量，但实际情况却并非如 此，因为无论采用什么样的编程技术，编程人员的错误都是不可避免的，而且由 于面向对象技术开发的软件代码重用率高，更需要严格测试，避免错误的繁衍。 因此，软件测试并没有因面向对象编程的兴起而丧失掉它的重要性。 2 1 2 软件测试内容 软件测试主要工作内容是验证( v e r i f i c a t i o n ) 和确认( v a l i d a t i o n ) 1 6 ，下面分别 给出其概念。 验证( v e r i f i c a t i o n ) 是保证软件正确地实现了一些特定功能的一系列活动，即 保证软件做了你所期望的事情( d ot h er i g h tt h i n g ) 7 1 。 1 确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的 过程； 2 程序正确性的形式证明，即采用形式理论证明程序符号设计规约规定的过 程： 3 评审、审查、测试、检查、审计等各类活动，或对某些项处理、服务或文 件等是否和规定的需求相一致进行判断和提出报告； 确认( v a l i d a t i o n ) 是一系列的活动和过程，目的是想证实在一个给定的外部 环境中软件的逻辑正确性。即保证软件以正确的方式柬做了这个事件( d oi tr i g h t ) 。 1 静态确认，不在计算机上实际执行程序，通过人工或程序分析来证明软件 的正确性； 2 动态确认，通过执行程序做分析，测试程序的动态行为，以证实软件是否 存在问题； 软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期间各 个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软 件测试的主要对象还是源程序。 2 1 3 软件测试的分类 从不同的角度出发，软件测试可以划分为不同的分类。 从是否关心软件内部结构和具体实现的角度划分： a 白盒测试 b 黑盒测试 从是否执行程序的角度： a 静态测试 b 动态测试。 从软件开发的过程按阶段划分有： a 单元测试 b 。集成测试 c 确认测试 d 验收测试 e 系统测试 下而给出按照测试内容分类得出的几个基本概念： a 功能测试，测试软件产品是否与需求符合，并准确的实现各个需求，主要 采取黑盒测试方法； b 性能测试，测试软件产品是否满足性能要求，如相应时间、吞吐量、处理 精度等，对实时系统、嵌入式系统等尤为重要： c 可靠性测试，测试软件产品是否满足可靠性要求，可靠性指在规定的时间 间隔内和条件下，软件产品正确运行的概率，测试内容还包括可用性和易用性： d 标准符合性测试，测试软件产品是否符合相应的标准，如国家标准，特殊 行业的行业标准等： e 互操作性测试，测试软件产品在不同平台、不同环境下的互操作能力，主 要应用于分布式系统中和网络环境下； f 安全性测试，测试软件产品有无安全漏洞； g 强度测试，测试软件产品在非正常情况下，系统的运行能力。 软件测试的分类并不是绝对的，从不同角度的分类并不矛盾，例如同- - n 试 技术可以应用在不同阶段的测试中，本文中将依据一般软件产品的开发过程对各 种测试做较为详细的介绍。 2 2 软件测试模型 软件开发产业发展了几十年中形成了很多经典的开发模型i8 1 ，比如瀑布模型、 螺旋模型等，但在这些模型中测试没有得到充分的重视，测试的价值没有被充分 强调，与软件测试在实际的开发过程中所占的比重和地位极不相符。近年来，人 们逐步认识到这些不足，提出了一些新的模型如v 模型w 模型等，已经把测试放 到了一个相当重要的位置上。 2 2 1v 模型 v 模型最早由己故的p a u lr o o k 在8 0 年代后期提出，v 模型被包含在英国国 家计算中心文献中发布，旨在改进软件开发的效率和效果。v 模型在欧洲尤其是 英国被接受，并被认为是瀑布模型的替代品，v 模型最早提出测试并不是一个事 后弥补行为，而是一个同开发过程同样重要的过程。这是它最大的积极意义所在， 直到现在，v 模型仍然被大多数软件开发公司作为开发过程的依据。v 模型描述 了一些不同的测试级别，并说明了这些级别所对应的生命周期的不同阶段。如模 型图中所示。 图2 1 v 模型 f i g 2 1v m o d e 左边下降的是开发过程各个阶段，与此相对应的是右边上升的部分，即各测 试过程的各个阶段，左边每个开发活动都有右边的测试活动相对应。因此，v 模 型主要向我们传递了如下信息：需求、功能、设计和编码的开发活动随时间而进 行，而相应的测试活动，即针对需求、功能、设计和编码的测试，其开展的次序 则正好相反。换而言之，代码最后被开发，而相应的单元测试首先被执行；需求 则最早开发，但相应的验收测试到最后进行。v 模型揭示了软件测试活动分层和 分阶段的本质特性。v 模型非常明确地标明了测试过程中存在的不同级别，并且 清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系： 1 单元测试的主要目的是针对编码过程中可能存在的各静错误，蜘如用户输 入验证过程中的边界值的错误。 2 集成测试主要目的是针对详细设计中可能存在的问题。尤其是检查各单元 与其它程序部分之间的接口上可能存在的错误。 3 系统测试主要针对概要设计，检查了系统作为一个整体是否有效地得到运 行，例如在产品设置中是否达到了预期的高性能。 4 验收测试通常由业务专家或用户进行，以确认产品能否真正符合用户业务 上的需求； 在不同的开发阶段，会出现不同类型的缺陷和错误，所以需要不同的测试技 术和方法来发现这些缺陷。 v 模型揭示了软件测试活动分层和分阶段的本质特性。但也存在一些问题， 比如容易让入形成“测试是开发之后的一个阶段”，“测试的对象就是程序”之类 的误解 9 1 。由于v 模型把系统开发过程划分为具有固定边界的不同阶段，这使得 人们很难跨过这些边界来采集测试所需要的信息。有些测试应该执行得更早些， 有些测试则需要延后进行。例如，需求或者设计阶段的错误往往需要到最后验收 测试才被发现，这样修改的代价就会很大。又比如，单元测试中需要设计桩模块 和驱动模块，这需要付额外的成本，或者因为条件不具备，根本就无法开发，而 且有可能掩盖了一些潜在的缺陷，所以在实际应用中有时候并不是当单元开发完 成后就执行单元测试，当模块从被组装在一起后就执行集成测试，往往需要推迟 一些阶段的测试。不仅如此，v 模型也阻碍了从系统描述的不同阶段中取得信息 进行综合。所以，一些改进过的软件测试模型被提了出来。 2 2 2w 模型 w 模型也叫双v 模型，是对v 模型的改进，它由e v o l u t i f 公司提出，针对v 模型让人觉得“测试是开发之后的一个阶段”，“测试的对象就是程序”的问题，w 模型强调需求、功能和设计同样要测试，测试的对象不仅仅是程序，软件测试应 该贯穿整个开发周期之中，只要相应的开发活动完成，就可以开始执行测试，可 以说，测试与开发是同步进行的。从而有利于尽早的发现问题。以需求为例，需 求分析一完成，我们就可以对需求进行测试，而不必等到最后才进行针对需求的 验收测试。 w 模型的示意图如下： 图2 2 w 模型 f i g 2 2 w m o d e l w 模型，尽管改善了v 模型的一些问题，但不管v 模型还是w 模型，适用 于那些需求非常明确，已经文档化了的项目，开发人员和测试人员都需要严格定 义好的需求和设计来开展工作，但在实际的开发过程中，开发过程中因为需求变 化等不可避免的原因。开发人员并没有按照文档来工作，也就是说文档没有及时 更新。这些情况下，v 模型和w 模型在实施起来就很困难。此外，无论是v 模型， 还是w 模型，都把软件的开发视为需求、设计、编码等等一系列的串行活动。而 事实上，虽然这些活动之间存在着互相牵制的关系，但在大部分时间，它们是互 相独立的，是可以并发进行的。虽然软件开发期望有清晰的需求、设计和编码等 等阶段，但实践告诉我们，严格的阶段之分只是一种理想状况【1 0 】。 2 2 3x 模型 x 模型也是为了解决v 模型的秘种问题，而由r o b i ne g o l d s m i t h 和b r a i n m a r i c k 提出的替代模型基础上提出的，他们认为v 模型和w 模型最大的问题体现 在以下几个方面： 1 忽略了这样的事实情况，即软件开发是由一系列的交接所组成，每一次交 接内容都改变了前一次交接的行为。 2 依赖于开发文档的存在，及文档的精确性、完备性，并且没有对时间进行 限制。 3 认定一种测试的设计是依据某一个单独的文档，而不包括根据其前后阶段 的文档的修改而作相应修改。 4 认定这些依赖于某个单独文档的测试一定要在一起。 x 模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试， 右上半部分显示此后将进行频繁的交接，通过集成最终合成为可执行的程序、这 些可执行程序还需要进行测试【l l 】。己通过集成测试的成品可以进行确认并提交给 用户，也可以作为更大规模和范围内集成的一部分。多条并行的曲线表示变更可 以在各个部分发生，x 模型还定位了探索性测试。这是不进行事先计划的特殊类 型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软 件错误。 总的来说，x 模型和下面的h 模型有很多共同之处，它们都是为了解决v 模 中理想化的一些东西，比如开发阶段之间有严格的界限，忽视了需求变化往往导 致开发过程变化的情况，认为测试可以依据已经写好的精确的文档来进行，没有 明确测试执行前应该进行的测试设计等准备阶段。并且x 模型包含了探索性测试 这一软件测试前沿理论，也是亮点之一。 2 2 4h 模型 在一般情况下，当客户在看到软件最终产品之前是无法判断其是否是所希望 的软件产品，一旦他看到最终产品时才发现与自己的期望相差甚远。究其原因： 1 用户的需求表述不清，由于用户自身的局限或对业务理解不同使用户表述 模糊； 2 用户需求的多变性，随着开发进程的推进，用户对所建应用系统理解的不 断深入，对原来模糊的需求有了新的认识或者有了新的需求； 3 由于用户对计算机领域知识的缺乏导致提出的需求不能实现或代价极大， 往往需要变更需求； 因此，用户需求的不确定性和易变性是客观存在的，是不可避免的，需求的 变化就导致实际情况中设计、开发、编码等各个阶段经常要反复交叉进行，正如 前文所述。v 模型和w 模型把软件开发的各个阶段划分的过于严格，那是一种理 论上的理想状态，实际上在真实的开发过程中并没有那么严格的界限，往往是各 个阶段交叉进行，不仅如此，而且在开发的过程中各不同层次之间的测试如单元、 集成和系统测试除了存在时间上的先后关系之夕 ，还存在着触发、反复、迭代和 增量关系。另外，v 模型和w 模型都没能很好的表示测试流程的完整性。测试流 程可以大致分为两类活动，一类是测试准备活动，包括测试需求分析、测试计划、 测试分析、测试编码、测试验证等等，另一类是测试执行活动，包括测试运行、 测试报告、测试分析等等。虽然，w 模型将测试从开发中分离了出来，但仍旧将 测试视为一个个游离的活动，而不是一个系统化的流程。h 模型就是为改进这些 缺陷而产生的。 h 模型表明软件测试不仅仅指测试的执行过程本身，还应该包括测试需求分 析、测试计划、测试分析、测试编码、测试验证等测试的准备活动【1 “。 软件测试是个独立的流程，应该贯穿软件开发的整个周期，可以与其它流 程并发的进行。当某个测试准备就绪时，软件测试即从准备阶段进入到测试执行 阶段。而这个过程是反复执行的，当需要测试时，就应该进行测试，h 模型兼顾 效率和灵活性，可以被应用到各种规模和各种类型的软件产品开发中。 2 3 自动化测试 随着软件产业的不断发展，产品越来越复杂，竞争越来越激烈，人们总是要 求产品在最短的时间内使用最少的资源来完成，有统计数字表明，百分之九十以 上的软件产品推迟了交货日期，大部分的开发人员在开发周期的后期不得不取消 一些功能以赶上最后期限【1 3 】。作为保障软件质量最重要的环节，软件测试也同样 面对时间压力，而软件测试是对创造力和智力非常有挑战性的任务。测试一个大 型软件需要的技术要求可能要超过设计这个程序。软件在它发行之前应当逶过彻 底的测试，以保证它的可靠性和功能性，不幸的是，一方面，迫于时间和市场压 力，测试工作可能根本就没有充分进行；另一方面，面对越来越大型化和复杂化的 软件产品，测试工程师靠自己的力量往往无能为力。一般的说，仅仅依靠测试人 员自身的力量，软件在发行前仅有5 0 的源程序被测试过。在差不多有一半源代 码没有被测试的情况下，大量的故障( b u g ) 随软件一道被发行出去。在这种情况 下，软件的质量、性能和功能不可能得到保障。面对这些问题，自动化测试应运 而生。自动化测试就是希望能够通过自动化测试工具或其他手段，按照测试工程 师的预定计划进行自动的测试，目的是减轻手工测试的劳动量，从而达到提高软 件质量的目的。自动化测试的好处： 1 2 1 方便进行回归测试 产品发现错误以后的改动，代码变了，但要求的功能并没有变，所以测试用 例也不必改变，自动化测试就可以很方便地进行回归测试，另外，对于产品型的 软件，每次发布一个新的版本，其中大部分功能和界面都和上一个版本相似或完 全相同，这部分功特别适合于自动化测试，从而可以让测试达到测试每个特征 的需求。 2 速度快，效率高 一般来说，软件产品的发布周期很短，而在测试期间是每天都可能要发布一 个版本供测试人员测试，一个系统的功能点有几千个上万个，人工测试是一项非 常耗时和繁琐的工作，这样必然会使测试效率低下，自动化测试很好地解决这个 问题，完全计算机自动执行的测试脚本速度快，效率高； 3 测试一致性和重复性 自动化测试执行依据的是测试脚本，而测试脚本是可以保存的，所以可以保 证每次自动化测试运行的脚本是相同的，所以每次执行的测试具有一致性，使错 误和执行过程具有可重现性，这一点人是很难做到的，对于自动化测试的一致性， 很容易发现被测软件的任何改变。 4 更好的利用资源 自动化测试能够按计划完全自动的由计算机运行，而测试人员是需要吃饭睡 觉的，不可能2 4 小时一直工作，自动化测试完全可以在周末和晚上执行测试，这 样充分的利用了时间和机器的资源，也避免了开发和测试之间的等待。 5 增加软件信任度 人总是会出错的，每一个测试人员都有自己特殊的经历和技术背景，有自己 的一些操作习惯和先入为主的观念，而这就导致不是所有的测试都是可信的，而 且有时测试会把一些新的错误带入软件产品之中。自动化测试则会在很大程度上 避免这些问题。 当然自动化测试也不是无所不能的，很多情况下并不是适合选择自动化测试， 人们对自动化测试的理解也存在许多误区，认为自动化测试能完成一切工作，从 测试计划到测试执行，都不需要人工干预，常见的错误认识总结如下： 1 期望自动化测试能完全取代手工测试 工具毕竟是工具，出现一些需要思考、体验、界面美观方面的测试时，工具 就起不到相应的作用。而且在自动化测试实施的各个阶段也需要人的参与，在某 些阶段，比如分析测试结果等，自动化工具只能提供数据，结果肯定是需要测试 人员来确定的。 2 期望自动测试发现大量新缺陷 同样不能期望自动化测试去发现更多新的缺陷，不能测试的新缺陷越多，自 动化测试失败的几率就越大。发现更多的新缺陷对于软件测试来说是主要目的。 测试专家j a m e s b a c h 总结出，8 5 的缺陷靠手工发现，而自动化测试只能发现1 5 的缺陷。自动化测试能够很好的发现老缺陷。 3 期望自动化测试可以适应于所有的测试 目前，没有个单一的测试工具能够支持所有的操作系统，也没有任何一个 测试工具能够与所有的程序语言兼容，因此，不能期望自动化测试能够适用于所 有的环节。 4 期望测试能够马上减轻测试工作，加快测试进度 引入自动化测试主要的目的之一是减轻测试的工作量，提高测试的工作效率， 但是，经验表明，自动化测试的引进并不能马上减轻工作量，因为，人工测试并 不能被完全取代，而测试人员存在对自动化工具的学习和熟悉问题，所以，在刚 开始引入的时期，甚至有可能加大工作量，延缓测试工作的进度。 5 期望达到百分之百的测试覆盖率 即使采用自动化测试，也不能测试每一项功能，每一个语句，因为，对一个 比较复杂的软件产品来说，它的输入情况或语句的排列组合情况非常复杂，不可 能完全覆盖所有可能情况。当然，这仍然是自动化测试的强项之一，但不能期望 自动化测试能覆盖所有情况。 自动化测试的实施大概分为以下几个阶段： 1 确定采用自动化测试 2 自动化测试工具的选择和获取 3 自动化测试的设计开发 4 自动化测试的执行 5 自动化测试的评审 首先，在确定是否引入自动化测试时应该认识到自动化测试不是适合所有的 公司、所有的项目。几种常见的种类总结如下： 1 定制型项目 为客户订制的项目。客户有固定的需求的订制项目，因为功能的确定性，所 以不适合用自动化测试。 2 项目周期很短的项目 项目周期很短测试周期很短，就不必花精力去投资自动化测试，好不容易建 立起的测试脚本，不能得到重复的利用是浪费时间。 3 业务规则复杂的对象 业务规则复杂的对象，有很多的逻辑关系、运算关系，自动化工具就很难达 到测试要求，如果强行使用自动化测试工具，往往需要投入更多的时间和精力得 不偿失。 4 抽象性测试 比如出于人的感觉方面的测试，很难有严格的测试标准，如界面的外观、声 音的体验、易用性的测试，显然自动化测试无用武之地，只能由人来测试。 5 测试很少运行的情况 测试很少运行，对自动化测试就是一种浪费。自动化测试就是不厌其烦的、 反反复复的运行才有效率。 6 软件质量还不稳定 软件不稳定，则会由于这些不稳定因素导致自动化测试失败。只有当软件达 到相对的稳定，没有界面性严重错误和中断错误时能开始自动化测试1 1 4 。 相反，有一些项目就特别适合采用自动化测试，那么什么样的情况适合自动 化测试，我们总结如下： 1 产品型项目 产品型的项目，每个项目只改进少量的功能，但每个项目必须反反复复的测 试那些没有改动过的功能。这部分测试完全可以让自动化测试来承担，同时可以 把新加入的功能的测试也慢慢地加入到自动化测试当中。 这些项目一般采用增量式开发、持续集成，由于这种开发模式是频繁的发布 新版本进行测试，也就需要自动化测试来频繁的测试，以便把人从重复测试中解 脱出来测试新的功能。 2 能够自动编译、自动发布的系统 要能够完全实现自动化测试，必须能够具有自动化编译，自动化发布系统进 行测试的功能。当然，不能达到这个要求也可以在手动情况下进行自动化测试。 3 需要频繁运行测试的项目 自动化测试最喜欢多次重复的测试，这样的测试对它来说从不会失败。比如 要向系统输入大量的相似数据来测试压力和报表。自动化测试的强项能够很好的 确保你是否引入了新的缺陷，老的缺陷是否修改过来了。如果在一个项目中需要 频繁的运行测试，测试周期按天算，就能最大限度的利用测