（计算机应用技术专业论文）在企业级应用中的软件测试过程与实践.pdf

摘要 软件测试是软件开发的一个重要环节，成为实现软件质量控制过程中的关键工作日 益受到人们的重视。软件测试工作的性质和要求使得测试工作的自动化和规范程度越来越 高。在各个重视软件质量的企业，软件测试工作的执行力度也逐渐增加，并从盲目无序的 自发行为转向受质量约束的规范化、标准化过程。从实践得知规范化、标准化程度越高， 软件测试的效率越高，对质量提升的影响程度越大。 国内外针对规范化、标准化软件测试有相当多的专著、理论、技术。但是任何一个开 发组织都有其特定的开发方式、习惯和环境，照搬照抄某些理论或技术并不能达到良好的 效果。同时，开发组织开发成熟度的区别也决定了在理论的指导下，还必须找到最适合本 组织的实践方式。如何在开发组织中将理论结合实践，找到效果最好、投入合适的测试方 法、过程和技术，是每个发展中的开发组织亟临的重要问题。 在这样的背景下，作者在一个中等规模的开发组织运作的个企业级系统集成软件开 发项目中，参与了一次理论指导实践完善软件测试过程的工作，并将这次测试过程的理论 基础、实践方式以及成果、结论作一总结。在这个过程中，最大的困难是根据环境找到理 论的最佳实践方式，并在各种限制因素之间寻求最佳的平衡。 本文记录了一个完整的软件测试过程，包括它依托的理论依据、每个阶段的主要实践 形式、以及遇到的主要问题、困难和解决的方式。 本文主要贡献在于： 1 、总结在这个项目中开发组织是如何将依据的测试理论落实到最适合自己的实践的， 为遇到类似问题的开发组织提供参考。 2 、记录这个项目测试工作的全过程，包括执行的细节，为软件测试组织提供已被证明 有效的成功经验。 3 、顺利完成了项目的测试工作，达到了预期的效果，实现了测试的目标，保障了软件 的质量。 关键词：软件测试测试计划测试设计测试用例缺陷测试评估性能测试 a b s t r a c t a ni m p o r t a n tl i n ki nt h es o f t w a r ed e v e l o p m e n t s o f t w a r et e s t i n gi sb e c o m i n gt h e k e yc o m p o n e n to fa c h i e v i n gs o f t w a r eq u a l i t yc o n t r o l l i n ga n di sa t t r a c t i n gm o r ea n d m o r ea t t e n t i o nd a yb yd a y t h en a t u r ea n dr e q u i r e m e n t so fs o f t w a r et e s t i n gl e a d t oh i g h e ra n dh i g h e rt e s t i n ga u t o m a t i o na n ds t a n d a r d i z a t i o n i nt h o s ee n t e r p r i s e s t h a ta t t a c hi m p o r t a n c et os o f t w a r eq u a l i t y ，t h ee x e c u t i o no fs o f t w a r et e s t i n gi s g r a d u a l l ye n h a n c e da n dc h a n g e df r o mt h eb l i n ds p o n t a n e o u sa c t i v i t yi n t ot h e s t a n d a r d i z e dp r o c e s s i ti sk n o w nf r o mt h ep r a c t i c et h a tt h eh i g h e rt h e s t a n d a r d i z a t i o n ，t h eh i g h e rt h ee f f i c i e n c yo fs o f t w a r et e s t i n ga n d t h eg r e a t e r i m p a c to ni m p r o v i n gq u a l i t y t h e r ea r eq u i t eal o to ft r e a t i s e s ，t h e o r i e sa n dt e c h n o l o g yo ns t a n d a r d i z e ds o f t w a r e t e s t i n gb o t ha th o m ea n da b r o a d h o w e v e r ，a n yd e v e l o p m e n to r g a n i z a t i o nh a si t so w n w a yo fd e v e l o p i n g ，h a b i ta n de n v i r o n m e n t ，t h e r e f o r e ，t oc o p yi n d i s c r i m i n a t e l ys o m e t h e o r i e so rt e c h n o l o g yw o n ta c h i e v eg o o dr e s u l t s m e a n w h i l e ，t h ed i f f e r e n td e g r e e s o fm a t u r i t yo ft h ed e v e l o p i n go r g a n i z a t i o n sd e t e r m i n et h a tu n d e rt h eg u i d e l i n eo f t h et h e o r y ，t h e ym u s tf i n dam o s ts u i t a b l ew a yt op r a c t i c ei t h o wt oi n t e g r a t e t h e o r ya n dp r a t t i c ea n df i n dt h em o s te f f e c t i v ea n ds u i t a b l et e s t i n gw a y ，p r o c e s s a n dt e c h n o l o g yi so fm a j o rc o n c e r nt oe v e r yd e v e l o p i n go r g a n i z a t i o n u n d e rt h i sb a c k g r o u n d ，t h ea u t h o r ，i na ne n t e r p r i s el e v e ls y s t e mi n t e g r a t e d s o f t w a r ed e v e l o p m e n tp r o j e c tr u nb yam e d i u m s c a l ed e v e l o p m e n to r g a n i z a t i o n ， p a r t i c i p a t e di nt h ew o r kt op e r f e c tt h ep r o c e s so fs o f t w a r et e s t i n ga n ds u m m a r i z e d t h et h e o r e t i c a lb a s i s ，p r a c t i c a lw a y ，r e s u l t sa n dc o n c l u s i o n so f t h i st e s t i n g p r o c e s s d u r i n gt h ep r o c e s s ，t h em o s td i f f i c u l tt h i n gi st of i n dt h eb e s tp r a c t i c a l w a ya c c o r d i n gt ot h ee n v i r o n m e n ta n dt of i n dt h eb a l a n c ea m o n gt h ev a r i o u sl i m i t i n g f a c t o r s t h i sa r t i c l er e c o r d sac o m p l e t ep r o c e s so fs o f t w a r et e s t i n g ，i e ，t h et h e o r e t i c a l b a s i s ，m a j o rp r a c t i c a lw a y si ne a c hp h a s e ，m a i np r o b l e m s ，d i f f i c u l t i e sa n dt h ew a y s t os e t t l et h e m i t sm aj o rc o n t r i b u t i o n1 i e si n ： 1 s u m m a r i z i n gh o wt h ed e v e l o p m e n to r g a n i z a t i o ni n t e g r a t e dt h e o r ya n dp r a c t i c e a n dp r o v i d e dr e f e r e n c ef o rl a t e rd e v e l o p m e n to r g a n i z a t i o nt h a tm a yc o n f r o n t s i m il a rp r o b l e m s 2 r e c o r d i n gt h ew h o l ep r o c e s so ft h et e s t i n gp r o j e c ti n c l u d i n gt h ed e t a i l so f e x e c u t i o na n dp r o v i d i n gt h et e s t i n go r g a n i z a t i o nw i t hs u c c e s s f u le x p e r i e n c e p r o v e de f f e c ti v e 3 s u c c e s s f u l l ya c c o m p l i s h i n gt h et e s t i n g ，a c h i e v i n gt h ee x p e c t e de f f e c t ， r e a l i z i n gt h et e s t i n gg o a la n ds a f e g u a r d i n gt h eq u a l i t yo fs o f t w a r e k e y w o r d s ：s o f t w a r et e s t i n g ，s o f t w a r ep l a n n i n g ，s o f t w a r ed e s i g n i n g ，t e s t i n gs a m p l e ， d e f e c t ，t e s t i n ge v a l u a t i o n ，p e r f o r m a n c et e s t i n g 3 第一章引言 企业应用越来越多的采用b s 架构，这代表了一种趋势，即企业应用越来越趋向大型、 分布式、瘦客户端的发展方向。越来越复杂的业务需求，带来了越来越繁复的设计需求， 如企业实施0 a 的需求。这种需求带来的是规模越来越大的软件系统、越来越大型的网络和 越来越高的设计标准。j 2 e e 标准就是面向这类需求的。对于一个大型的企业级应用，软件 的测试已经成为一项独立的技术与过程，与软件开发技术和过程一样的复杂和重要。在这 种大环境下，用合适的软件测试过程方法指导质量控制工作用先进的软件测试技术提高 测试质量，已经成为影响软件系统性能、生命力的关键因素之一。 软件工程学、测试过程与技术等领域有非常多的理论指导，也有很多国内外的模型可 以借鉴。但是任何一个开发组织都有其特定的开发方式、习惯和环境。 从开发过程模型来讲，不论是经典的瀑布型、螺旋型开发模式，还是微软提出的更适 合中小型项目的m s f ( m i c r o s o f ts o l u t i o nf r a m e w o r k ) 的过程模型，都不可能直接将书 本提供的理论应用到实际工作中，必须根据组织的开发方式进行调整、裁减或改造。对应 的测试过程模型也一样，既需要选择合适的测试过程模型与开发模型相适应，又必须对理 论进行调整、裁减或改造。 从开发习惯或技术来讲，不同的组织有不同的倾向。对于使用u m l ( u n i f i e dm i d e l i n g l a n g u a g e ) 语言和面向对象分析设计方法的开发组织或项目，比较适合面向对象的测试技 术，并且使用r u p ( r a t i o n a lu n i f i e dp r o c e s s ) 的思想对开发过程和测试过程进行指导； 而对于习惯基于产品进行二次开发和集成的开发组织，它的开发过程和测试过程可能结合 得很紧密，并且特别关注集成测试。 对于开发组织所处得环境来讲，某些公司机构具备完善的组织结构，项目按照矩阵型 组织结构开展，公司机构中所有开发组织的开发模式都类似，开发组织可以得到专门的测 试和质量保证部门的强大支持，对测试过程和技术的改进有专门的组织负责；某些公司机 构按照项目型组织结构运作，项目间有很大不同，每个项目必须根据自身的特点度身定制 最合适的测试过程和技术。 因此照搬照抄某些理论或技术并不能达到良好的效果。同时，开发组织开发成熟度的 区别也决定了在理论的指导下，还必须找到最适合本组织的实践方式。如何在开发组织中 6 将理论结合实践，找到效果最好、投入合适的测试方法、过程和技术，是每个发展中的开 发组织面临的重要问题。但是如何根据应用自身的特点台理的设计符舍实际情况的测试过 程并执行则是一个实践问题。开发组织面临的问题主要有： 1 、决定采用何种理论作为指导 2 、如何根据开发组织环境和开发项目的特点，对软件过程的方法论进行裁减和本地 化，以保证成功 3 、如何设计测试过程实施的方案，以使得测试理论得到成功的实践，达到测试的效果 这些问题并不是简单的是与否的问题，开发组织必须在实践中不断积累经验，在各种 因素间找到最佳的平衡，才能找到最合适的测试过程和技术。 带着找到上述问题的最佳实践的目的，本文的作者参与了一个中等规模的开发组织运 作的大型企业级软件开发与集成项目的测试过程。作者与测试组织一起，研究了大量的国 内外测试理论，研究了开发组织采用的开发模式，包括过程模型、团队模型以及使用的开 发模式，在这些理论的指导下设计了一套被证明有效的测试过程和模式，选取了合适的测 试技术和工具，并对测试的效果进行了总结。经过这次成功实践，项目的测试达n t 较好 的效果，既保证了测试过程的质量，覆盖了项目需要的质量控制范畴又提高t n 试效率， 使测试工作有条不紊，最后也使用了一些新的测试技术，这些技术对于量化测试结果、简 化沟通与评估软件质量起了很积极的作用。 本文的内容就是说明这一成果。将涉及以下内容：对项目依据的软件测试思想的简介 和概括；对软件测试过程的总结：以及在上海移动工程项目管理平台这一企业级j 2 e e ( j a v a 2e n t e r p r i s ee d i t i o n ) 应用中的实践。 1 1 项目背景和测试工作概述 上海移动工程项目管理平台的建设是为了实现以下目的：规划上海移动每年数十亿投 资规模的固定资产投资项目；固化固定资产建设项目( 工程项目) 的管理流程并建设电子 化办公平台；采集、分析工程项目建设过程中的基础数据实现可视化项目管理；对数据进 行智能分析以实现预测分析。 软件平台的主要功能模块有：计划管理、项目管理、采购管理、工程项目、设计任务 管理、综合管理、系统管理、协作中心等。 这个项目的测试工作涵盖以下范畴 测试过程管理： 计划：制订测试计划和策略，定义测试过程和输入输出，制订测试策略，定义测试标 准和交付工件。 实施：定义测试技术、工具、资源、用例库；实施测试过程；交付测试成果。 控制：控制测试过程与交付工件，通过配置管理管理基线和变更。 收尾：在各里程碑交付里程碑工件，在项目完成后交付管理性收尾文件和技术性收尾 文件。 1 2 本次测试工作的目标 在上海移动工程项目管理平台这个项目中，作者与测试组织一起参与了测试的全过程。 在项目前期测试团队制订了这样的目标： l 、引入规范的测试过程理论，以提升项目中测试工作的整体效果 2 、根据项目和项目环境、组织的特点，裁减、优化与改造理论中的测试过程，设计一 套适合组织的测试过程和技术 3 、引入t e s t d i r e c t o r 等测试平台工具，提高测试效率 1 3 论文的结构 本文共分五章，第一章引言，主要介绍研究工作的背景，所面临的问题，以及概述本 文的内容和作用；第二章软件测试理论简介，简单介绍了项目测试工作的理论依据：第三 章项目测试过程设计，论述项目中如何设计适合项目的测试过程；第四章测试执行与实践， 论述在执行测试过程中实践中的各种具体的工件、技术；第五章总结与展望，包括对成 果的分析、实践的总结以及后续工作展望等内容。 8 第二章软件测试理论简介 本章内容是对软件测试理论的简介。这些理论是这个项目整个测试过程的理论依据。 本章将首先介绍软件测试与软件开发的关系，来说明软件测试对软件开发所起的重要作用： 第二分析软件测试的实际执行效率状况，说明国内软件测试领域面临的问题和环境；第三论 述了测试工作的目的，这是本项目测试工作的指导方针；第四论述了软件钡试的原则，这 是项目中各种测试规约制订的依据之一：第五论述了软件测试的对象，这是根据v 模型等 软件测试过程模型制订的，是项目测试内容的指导依据之一；最后论述了软件测试的各过 程和阶段，这是项目测试工作设计测试过程的基础。 2 1 软件测试与软件开发的关系 e d w a r dk i t 在他的畅销书“s o r w a r et e s t i n gi nt h er e a lw o r l d ：i m p r o v i n gt h ep r o c e s s ( 1 9 9 5 s b n ：0 2 0 1 8 7 7 5 6 2 ) ”中将整个软件开发历史分为三个阶段： 第一个阶段是6 0 年代及其以前，那时软件规模都8 1 l d , 、复杂程度低，软件开发的过程 随意。开发人员的d e b u g 过程被认为是唯一的测试活动。其实这并不是现代意义上的软件 测试，当然一阶段也还没有专门测试人员的出现。 第二个阶段是7 0 年代，这个阶段开发的软件仍然不复杂，但人们已开始思考开发流程 问题，并提出“软件t 程s o r w a r ee n g i n e e r i n g ”的概念。但是这一阶段人们对软件测试的理 解仅限于基本的功能验证和b u g 搜寻，而且测试活动仅出现在整个软件开发流程的后期， 虽然测试由专门的测试人员来承担，但测试人员都是行业和软件专业的入门新手。 第三个阶段是8 0 年代及其以后，软件和i t 行业进入了大发展。软件趋向大型化。与之 相应，人们为软件开发设计了各种复杂而精密的流程和管理方法( l 坝i c m m 和m s f ) ，并 将“质量”的概念融入其中。软件测试已有了行业标准( i e e e a n s i ) ，它再也不是一个一 次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试已成为一 个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。 在这一历史发展过程中，最值得注意的是测试与开发流程融合的趋势。人们对这种融 合也许并不陌生。b e 如测试活动的早期展开让测试人员参与用户需求的验证，参加功能设 计和实施设计的审核。再比如测试人员与开发人员的密切合作，随着开发进展而逐步实施 9 单元测试、模块功能测试和系统整合测试。的确这些都是测试与开发融合的表现形式，而 且初期的融合也只反映在这个层次上。9 0 年代以后，软件的规模和复杂程度迅速提高，这 种形式上的融合也迅速走向更深层次，更具实际意义。具体地说这种融合就是整个软件开 发活动对测试的依赖性。传统上认为，只有软件的质量控制依赖于测试，但是现代软件开 发的实践证明，不仅软件的质量控制依赖于测试，开发本身离开测试也将无法推进，项目 管理离开了测试也从根本上失去了依据。 现代软件开发，特别是大型软件开发通常会遇到以下二个问题： l 、如何能够展开大规模团队，群体齐头并进，而同时保持开发的有序性。从而有效 利用资源，缩短开发周期。 2 、 对于小型简单的软件，这个问题也存在，但不突出，而且容易解决。但对于复杂 的大型企业级软件的开发，这个问题常常会成为难以逾越的障碍。 通常大型项目的功能丰富，但架构、层次也会相当复杂。稳妥的开发方式是，一次投 入少量的人员，逐层开发，逐层稳定。但这种方式显然资源利用率低，开发周期长，不能 满足现代软件和i t 行业高速发展、瞬息万变的需要。因此大型项目需要大型团队。在微软， 产品开发团队( 主要包括开发、测试和项目管理) 一般都有百人以上规模，有些产品甚至 上几千人( w i n d o w s 2 0 0 0 的开发部门曾有3 0 0 0 多人) 。这样大规模的人力资源作用在一个 动态的，内部相互联系的系统中，若没有有效的协同，其混乱是不可避免的。试想，有两 个开发人员，分别在开发两个不同的功能模块，其相互有依赖关系。为了相互协调，他们 可以随时进行当面讨论。如果这种关系发生在五个开发人员和五个功能模块之间，这种协 调就只能通过定期的会议来进行。而一个大型项目，会有许许多多这样地关系，而且很多 时候这种关系有着不确定性和不可预见性。当一个开发人员编写一段新的代码或对已有代 码进行改动和调整时，他( 或她) 常常无法确定，或无法完全确定究竟有哪些相关的模块 会受到影响以及在什么情况下这种影响会带来什么结果。因为系统的复杂性已远远超出 了人的逻辑思维、技能和经验所能力及的范畴。因此这种传统的协调手段是远不能满足需 要的。现在这种协调是通过测试来实现的。 2 2 软件测试的实际执行效率状况分析 随着计算机硬件成本的不断下降，软件在整个计算机系统的成本中占有越来越高的比 i o 例，规模不断扩大，软件设计的复杂程度也不断提高，开发中出现错误或缺陷的机会越来 越多同时市场对软件质量重要性的认识逐渐增强，如何提高软件质量也就成了整个计算机 软件行业的重大课题。 根据i e e e a n s i 标准，软件测试的定义是：”使用为发现错误所选择的输入和状态的组 合而执行代码的过程“。这就非常明确地提出了软件测试是以发现错误，检验是否满足需求 为目标。软件测试在软件生命周期中占有非常突出的重要地位，是保证软件质量的重要手 段。根据b o e h m t ，软件开发总成本中，用在测试上的开销要占4 0 到5 0 。软件测 试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误，以提高软件的 质量。 统计表明，开发较大规模的软件，即使富有经验的程序员，也难免在编码中发生错误， 何况，有写错误在设计甚至分析阶段早已埋下祸根，无论是早期潜伏下来的错误或编码中 新引入的错误，若不及时排除，轻者降低软件的可靠性，重者导致整个系统的失败。为防 患于未然，强调软件测试的重要性是必要的。美国著名软件质量分析师贺越明向大家介绍 了国外的情况：在软件业较发达的国家，软件测试不仅早已成为软件开发的一个有机组成 部分，而且，在整个软件开发的系统工程中占据着相当大的比重。以美国的软件开发和生 产的平均资金投入为例，通常是：“需求分析”和“规划确定”各占百分之三，c 设计，占百分 之五，“编程”占百分之七，“测试”占百分之十五，“投产和维护”占百分之六十七。测试在 软件开发中的地位，由此可见一般。 与此相应，软件测试已成为软件产业中的一个独特市场。在美国硅谷地区，凡是软件 开发企业或是设有软件开发部门的公司，都有专门的软件测试单位，其中软件测试人员的 数量相当于软件开发工程师的四分之三，有些甚至达到相差无几的程度。在这些公司或部 门中，负责软件测试的质量保证经理的职位与软件开发的主管往往是平级的，而软件测试 人员的职衔通常是“软件质量分析师”，他们是专门的“找问题专家”，对软件开发的质量负 有极大的责任。但是在国内，很多软件企业的测试和开发人员之比在1 ：5 甚至更低。有关 产业专家指出，在软件企业中，对开发人员和测试人员的需求，在数量上应该达到一个非 常接近的配置，但从我国目前的现状看，结构失衡的现象比较普遍。 国内软件项目过程不规范，导致重视编码和轻视测试的现象，对于软件测试的重要性、 测试方法和流程等还存在很多错误的认识。不少软件企业的软件开发模式仍然处在无序开 发的不规范状态，与软件编程比较，软件测试的地位和作用，还没有真正受到重视，对于 很多人( 甚至是软件项目组的技术人员) 还存在对软件测试的认识误区，进一步影响了软 件测试活动的开展和真正提高软件测试质量。这对于产业的健康发展来说，无疑是一个较 为严重的桎梏。 2 3 测试工作的目的 基于不同的立场，存在着两种完全不同的测试目的： 从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是 否可接受该产品。 从软件开发者的角度出发，则希望澳口试成为表明软件产品中不存在错误的过程，验证 该软件已正确地实现了用户的要求，确立人们对软件质量的信心。 m y e r s 描述的软件测试目的为： l 、测试是程序的执行过程，目的在于发现错误。 2 、一个好的测试用例在于能发现至今未发现的错误。 3 、一个成功的测试是发现了至今未发现的错误的测试。 换言之，测试的目的是想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺 陷。如果我们成功地实施了测试，我们就能够发现软件中的错误，测试的附带收获是它能 够证明软件的功能和性能与需求说明相符合，实施测试收集到的测试结果数据为可靠性分 析提供了依据。测试不能表明软件中不存在错误，它只能说明软件中存在错误。 2 4 软件测试的原则 1 、应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。 2 、测试用例应由测试输入数据和对应的预期输出结果这两部分组成。 3 、程序员应避免检查自己的程序。 4 、在设计测试用例时，应包括合理的输入条件和不合理的输入条件。 5 、充分注意测试中的群集现象。 6 、经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。 7 、严格执行测试计划，排除测试的随意性。 8 、应当对每一个测试结果做全面检查。 9 、妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。 2 5 软件测试的对象 软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。需求分 析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要 设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。 2 。6 软件测试的过程、阶段 一个软件从开始计划起，到废弃不用止，称为软件生存周期。一般来说，软件生存周 期包括计划、开发、运行三个时期，每一时期又可分为若干更小的阶段。计划时期的主要 任务是分析用户要求，分析新系统的主要目标以及开发该系统的可行性。开发时期要完成 设计和实现两大任务具体。具体分为需求分析、概要设计、详细设计、编码、测试。其中 编码和测试是软件开发期的最后两个阶段。运行时期是软件生存周期的晟后一个时期，软 件人员在这一时期的工作，主要是做好软件维护。 当设计工作完成以后，就应该着手测试的准备工作了，一般来讲，由一位对整个系统 设计熟悉的设计人员编写测试计划，明确测试的内容和测试通过的准则，设计完整合理的 测试用例，以便系统实现后进行全面测试。 在实现组将所开发的程序经验证后，提交测试组，由测试负责人组织测试，测试一般 可按下列方式进行： ( 1 ) 首先，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在 设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划， 设计测试用例，作好测试前的准备工作。 ( 2 ) 为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元测试、集成 测试、验收测试和系统测试。 ( 3 ) 代码会审： 代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。会审小组由 组长，2 3 名程序设计和测试人员及程序员组成。会审小组在充分阅读待审程序文本、控 制流程图及有关要求、规范等文件基础上，召开代码会审会，程序员逐句讲解程序的逻辑， 并展开热烈的讨论甚至争议，以揭示错误的关键所在。实践表明，程序员在讲解过程中能 发现许多自己原来没有发现的错误，而讨论和争议则进一步促使了问题的暴露。例如，对 某个局部性小问题修改方法的讨论可能发现与之有牵连的甚至能涉及到模块的功说明、 模块间接口和系统总结构的大问题，导致对需求定义的重定义、重设计验证，大大改善了 软件的质量。 ( 4 ) 单元测试： 单元测试集中在检查软件设计的最小单位一模块上，通过测试发现实现该模块的实际功 能与定义该模块的功能说明不符合的情况，以及编码的错误。由于模块规模小、功能单一、 逻辑简单，测试人员有可能通过模块说明书和源程序，清楚地了解该模块的i o 条件和模块 的逻辑结构，采用结构测试( 白盒法) 的用例，尽可能达到彻底测试，然后辅之以功能测 试( 黑盒法) 的用例，使之对任何合理和不合理的输入都能鉴别和响应。高可靠性的模块 是组成可靠系统的坚实基础。 单元测试任务包括：1 模块接口测试：2 模块局部数据结构测试；3 模块边界条件测 试；4 模块中所有独立执行通路测试：5 模块的各条错误处理通路测试。 ( 5 ) 集成测试： 集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关 的问题。如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造 成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差 可能积累到不能接受的程度；全程数据结构可能有错误等。 ( 6 ) 验收测试： 验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后 已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接 着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用 户所合理期待的那样。 ( 7 ) 系统测试： 将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在 实际运行环境下进行一系列的测试。 经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束， 经验收后，将软件提交用户。 2 6 1 测试方法分析 2 6 1 1 单元测试 因为在为模块设计程序用例时，可以直接参考模块的源程序。所以单元测试的策略， 总是把白盒法和黑盒法结合运用。具体做法有两种： 1 、先仿照上述步骤用黑盒法提出一组基本的测试用例，然后用白盒法作验证。如果发 现用黑盒法产生的测试用例未能满足所需的覆盖标准，就用白盒法增补新的测试用例来满 足它们。覆盖的标准应该根据模块的具体隋况确定。对可靠性要求较高的模块，通常要满 足条件组合覆盖或路径覆盖标准。 2 、先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒 法进行补充。 2 6 1 2 集成测试 集成测试及其后的测试阶段，一般采用黑盒方法。 1 、黑盒测试 黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试 来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完 全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序 功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正 确的输出信息，并且保持外部信息( 如数据库或文件) 的完整性。黑盒测试方法主要有等 1 5 价类划分、边值分析、因一果图、错误推测等，主要用于软件确认测试。“黑盒”法着眼于 程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷 举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所 有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那 些不合法但是可能的输入进行测试。 黑盒测试用例设计包括： 1 1 等价类划分：划分等价类一确立测试用例一设计用例 2 ) 边界值分析：通过分析，考虑如何确立边界情况 3 1 错误推测法：靠经验和直觉来推测程序中可能存在的各种错误，从而有针对性地 编写用例。可以列举出可能的错误和可能发生错误的地方，然后选择用例。 4 1 因果图：通过画因果图，在图上标明约束和限制，转换成判定表，然后设计测试 用例。这适合于检查程序输入条件的各种组合情况。 5 ) 功能图f d ：通过形式化地表示程序的功能说明并机械地生成功能图的测试用例。 2 、白盒测试 白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来 检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序， 检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主 要方法有逻辑驱动、基路测试等，主要用于软件验证。 “白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路 径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手， 得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有 错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。 第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现 不了一些与数据相关的错误。 白盒测试用例设计包括： 1 6 1 1 逻辑覆盖，以程序内在逻辑结构为基础的测试，包括以下5 种类型： 语句覆盖：每一条可执行语句至少覆盖一次； 判定覆盖( 分支覆盖) ：设计若干个测试用例，运行所测程序，使程序中每个判断的 取真分支和取假分支至少执行一次； 条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的 每个可能取值至少执行一次： 判定条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条 件的所有可能取值至少执行一次，并且每个可能的判断结果也至少执行一次； 条件组合测试：设计足够多的测试用例，运行所测程序，使程序中每个判断的所有可 能的条件取值至少执行一次； 路径测试：设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径。 2 1 基本路径测试 在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集 合，从而设计测试用例。包括以下5 个方面： 程序的控制流图：描述程序控制流的一种图示方法。 程序环境复杂性：m c c a b e 复杂性度量。从程序的环路复杂性可导出程序基本路径集合 中的独立路径条数，这是确定程序中每个可执行语句至少执行依次所必须的测试用例数目 的上界。 导出测试用例 准备测试用例，确保基本路径集中的每一条路径的执行 图形矩阵：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定 一个基本路径集。 2 6 1 3 系统测试 计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系统中其它 1 7 成分集成在一起，此时需要进行一系列系统集成和确认测试。对这些测试的详细讨论已超 出软件工程的范围，这些测试也不可能仅由软件开发人员完成。在系统测试之前，软件工 程师应完成下列工作： 1 、为测试软件系统的输入信息设计出错处理通路： 2 、设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统 测试提供经验和帮助； 3 、参与系统测试的规划和设计，保证软件测试的合理性。 系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都 能正常工作并完成所赋予的任务。下面简单讨论几类系统测试。 l 、恢复测试 恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误 并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快 恢复。对于自动恢复需验证重新初始化( r e i n i t i a l i z a t i o n ) 、检查点( c h e c k p o i n t i n g m e c h a n i s m s ) 、数据恢复( d a t ar e c o v e r y ) 和重新启动( r e s t a r t ) 等机制的正确性；对于人 工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。 2 、安全测试 安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者， 采用各种办法试图突破防线。例如，想方设法截取或破译口令：专门定做软件破坏系 统的保护机制；故意导致系统失败，企图趁恢复之机非法进入：试图通过浏览非保密 数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源没有不可进入的系统。 因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者 已无利可图。 3 、强度测试 强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置 下运行。例如，当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用 例；定量地增长数据输入率，检查输入子功能的反映能力；运行需要最大存储空间( 或 其他资源) 的测试用例；运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用 例，等等。 4 、性能测试 对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求， 虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实 环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时 与强度测试相结合，经常需要其他软硬件的配套支持 2 6 1 4 验收测试 事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错 误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不 解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。 验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数 周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能 由每个用户验收，此时多采用称为a 、b 测试的过程，以期发现那些似乎只有最终用户才 能发现的问题。 2 6 1 5a 测试与b 测试筒述 a 测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品( 称为a 版本) 进行测试，试图发现错误并修正。a 测试的关键在于尽可能逼真地模拟实际运行环 境和用户对软件产品的操作并尽最大努力涵盏所有可能的用户操作方式。经过a 测试调 整的软件产品称为d 版本。紧随其后的p 测试是指软件开发公司组织各方面的典型用户在 日常工作中实际使用b 版本，并要求用户报告异常情况、提出批评意见。然后软件开发公 司再对b 版本进行改错和完善。 1 9 第三章项目测试过程设计 本章介绍了在项目中测试和开发团队是如何根据理论设计最符合项目和开发组织实际 情况的测试过程的。项目启动后，测试组织和开发组织一起研讨了大量理论知识，并对以 前的成功或失败经验进行总结。为了更好的实现测试目标，我们对项目的测试过程进行了 设计。测试过程设计是基于理论依据、结合实际情况对测试标准化、规范化过程进行裁减、 优化和改良的工作，是从理论落实到实践的关键步骤。通过这一工作，测试组织形成了新 的测试规范，并被应用到项目中对后面的测试执行进行了有效的指导。 整个测试工作按照执行过程被分为测试计划、测试设计、测试执行、测试评测与总结 四个过程组；这些过程组在整个项目生命周期中是迭代迸行的。本章将分为四个小节论述 每个过程组，包括测试组织定义这个过程组的理论依据，以及团队是如何协作来制订过程 组的内容、策略的。在第四章测试执行与实践中，将更细化的描述具体执行过程中的具体 情况。 按照标准化的过程思想，并参考了r u p 的过程管理理念，我们将每个测试过程组的内 容定义为：输入、工具和技术、输出三部分内容。同时根据测试团队模型定义的各种角色， 确定了驱动每个过程组的特定俺色。最后，在定义输入、输出时，确定了作为标准工件的 各类文档模板、规范或规约。 3 1 项目管理系统的测试前准备 上海移动工程项目管理系统建设项目是一个软件开发与集成项目，它的软件是一套基 于j 2 e e 架构技术的企业级应用软件，包含四层架构，使用w e b s h a r e 作为应用服务器中间 件，o r a c l e 作为数据库服务器。作为一个运营商级的软件，系统对性能的要求比较高，同 时系统深入企业业务、业务逻辑复杂的特点，也决定了系统备功能点对数据准确性、操作 准确性有较高的要求。同时，系统的硬件部分采用了两台i b m 小型机，应用服务器采用 a c t i v e s t a n d b y ( 活动一待命) 的热各机制，数据库服务器做l o a d b a l a n c e ( 负载均衡) 。 同时采用磁带库进行数据备份。这样的硬件架构也决定了系统集成测试的要求比较高。 软件开发团队确定了开发模式采用基于r u p 的迭代开发，第一阶段主要任务是使用 o o a ( o b j e c t - o r i e n t e da n a l y s i s ) 、o o d ( o b j e c t - o r i e n t e dd e s i g h n ) 等技术对系统进行分 析与建模，并完成系统基本模块以进行集成；第二阶段主要任务是按照多版本发布计划， 渐进交付软件功能。测试团队对这一的开发模式进行了分析，得出了如下结论： 1 、整个开发模式