（计算机科学与技术专业论文）软件测试过程的研究与应用.pdf

摘要 软件过程，是指软件的整个生命周期，包括需求获取，需求分析，设计，实 现，测试，发布和维护等一系列软件开发活动。软件过程模型是过程的一种抽象 表现形式，它从理论的角度对过程的各个方面进行描述。在软件开发中大约有 3 0 到4 0 的软件活动与测试相关，但是在传统的软件过程模型里，测试往往只 作为一个阶段放在软件开发的后期，并且被认为是一种事后行为，结果导致很多 需求和设计的缺陷累积到项目的末端，一方面造成修改成本的急剧膨胀，另外 一方面严重影响软件的发布日期。 本文充分分析了当前几种典型的软件测试模型及其特点，结合e g o 项目的 实际情况，对原有的测试模型进行了相应的改进。为了充分发挥软件测试在质量 保证中的作用，本文主要从下面三个方面改进软件测试过程，提高软件测试效率， 缩短软件测试周期： 1 软件过程方面：充分重视静态测试，让测试人员从一开始就介入开发， 尽早熟悉客户需求，熟悉系统功能：同时制定测试计划和设计测试用例， 使测试人员和开发人员并行工作，尽可能早的发现软件缺陷。 2 人员组织方面：彻底打破开发人员和测试人员分离的现状，开发人员和 测试人员“结对工作”，充分发挥各自技术和产品经验的优势，相互审 查对方的工作，尽可能早的发现解决系统和测试方面的缺陷，既提高软 件软件开发的质量又提高测试的质量。 3 自动化测试框架的使用：提高软件用例的执行效率，解决由于早期介入 开发，测试用例大规模的回归运行引起的问题。 通过理论分析和实际项目e g oa p i 的结果表明，基于以上三点软件测试过 程的改进能够很好的提高软件测试的效率，缩短软件周期，保证软件质量，降低 软件成本。 关键字：软件过程，软件测试过程，质量保证，自动化测试 a b s t r a c t s o f t w a r ep r o c e s sc o v e r st h ew h o l el i f e c y c l eo fs o f t w a r ed e v e l o p m e n t ， i n c l u d i n gv a r i o u s s o f t w a r e d e v e l o p m e n t a c t i v i t i e sl i k e r e q u i r e m e n tg a t h e r i n g ， r e q u i r e m e n ta n a l y s i s ，d e s i g n ，i m p l e m e n t a t i o n ，t e s t i n g ，r e l e a s ea n dm a i n t e n a n c e t h e s o f t w a r ep r o c e s sm o d e li sg e n e r a l l ya c c e p t e da sas i m p l i f i e d d e s c r i p t i o no ft h e s o f t w a r ep r o c e s s ，w h i c hi d e n t i f i e se a c hs t a g eo ft h ep r o c e s sf r o mat h e o r e t i c a lp o i n to f v i e w i ns o f t w a r ed e v e l o p m e n t ，a b o u tt h i r t yt of o r t yp e r c e n to ft h ea c t i v i t i e sa r et i g h t l y r e l e v a n tw i t hs o f t w a r et e s t i n g h o w e v e r , i ti so n l yc o n s i d e r e da st h ef i n a lp h a s eo f s o f t w a r ed e v e l o p m e n tp r o c e s si nt h et r a d i t i o n a ld e v e l o p m e n tm o d e l s ，a n da sk i n do f a c t i o n sa f t e rd e v e l o p m e n tb ym i s t a k e w i t ht h ei n c r e a s i n gf o c u so ns o f t w a r eq u a l i t y , e x p e l so n s o f t w a r et e s t i n gh a v eg e n e r a t e ds e v e r a lt e s t i n gm o d e l sb a s e do nt h e c o n c e p to fd e v e l o p m e n tm o d e l t h e s em o d e l sa b s t r a c t t h ea c t i v i t i e so ft e s t i n g p r o c e s s ，c o l l a b o r a t ew i t ht h ed e v e l o p m e n tp r o c e s sa n da r eg e n e r a l l yr e g a r d e da s i m p o r t a n tr e f e r e n c e sf o rt e s t i n gp r o c e s sm a n a g e m e n t f o rc o n t r o l l i n gt h es o f t w a r eq u a l i t yb ys o f t w a r et e s t i n g ，t h i sp a p e ra n a l y z e st h e e x i s t i n gs o f t w a r et e s t i n gm o d e l se x i s t i n gt e s t i n gp r o c e s sa c c o r d i n gt ot h ep r a c t i c eo f p r o j e c t s a n dt oe n h a n c et h et e s t i n ge f f i c i e n c ya n da v o i dd e l a y i n gt h er e l e a s ed a t eb y d o i n gf o l l o w i n gw o r k s ： 1 t a k ea h e a do ft h et e s t i n gp r o c e s sw h i l es t a r t i n gt h ep r o j e c t t h eq aw i l lb e f a m i l i a rw i t ht h ec u s t o m e r sr e q u i r e m e n ta n dt h ed e v e l o p e r sd e s i g na n dw i l l p r e p a r et h et e s t i n gp l a na n dt h et e s t i n gc a s e sa se a r l ya sp o s s i b l e i nt h i sw a y q ac a ns t a r tt oe x e c u t et h et e s t i n gc a s e sw h i l ed e v e l o p e rd e l i v e r i n gt h e c o d e 2 f r o n t e n dq a f r o n t e n dq aw i l lm a k eq aa n dd e v e l o p e rw o r k e dt o g e t h e r a n dw i l ls h a r et h e i rp r o d u c tt e c h n i c a lk n o w l e d g ea n de x p e r i e n c e t h e yc a n c o m m u n i c a t ei nam o r ee f f i c i e n c yw a ya n dr e v i e wa n o t h e ro n e sw o r k i n t h i sw a yt h e yc a nh u n tt h eb u g se x i s t e di nb o t hd e v e l o p e r sw o r ka n dt h e q a sw o r ki na ne a r l i e rs t a g e 3 ，u s i n ga u t o m a t i o nt e s t i n gf r a m e w o r k t h i sc a ne x e c u t et h et e s t i n gc a s e s m o r ee f f i c i e n c y , a n dh a n d l et h el a r g en u m b e ro fr e g r e s s i o nc a s e s w i t ha n a l y z i n gi nt h e o r ya n de x p e r i m e n t a l i z i n gi ne g oa p ip r o j e c t ，t h ep r e t e s t p r o c e s sm o d e lc a nc o m p l e t e l yf i n i s ht h et e s t i n gi na ne f f e c t i v ea n de f f i c i e n c yw a y a n d m a k es u r et od e l i v e rag o o ds y s t e mt ot h ec u s t o m e r k e yw o r d s ：s o f t w a r ep r o c e s s ，s o f t w a r et e s t i n gp r o c e s s ，q u a l i t ya s s u r a n c e ， a u t o m a t i o nt e s t i n g l i 西北工业犬学硕士学位论文第一章绪论 1 1 研究背景 第一章绪论 s y m p h o n y 2 x 系统是p 公司为实时金融服务计算而设计的网格计算解决方 案。由于初次涉足金融产品市场，初期对产品需求缺乏一定的经验，并且与客户 沟通不够充分。在开发过程中，导致开发计划不断推迟。同时迫于市场压力，为 了能够尽量早点发布产品，又压缩了测试周期，使产品质量存在隐患。 产品发布后，由于软件质量不理想，在使用过程中发现许多缺陷，给技术支 持部门带来极大的压力。尤其是随着时间推移，新功能的加入，以及一些缺陷的 纠正又触发了新的缺陷，使软件维护成本成指数级急剧飙升。为了维护产品市场， 有利于产品的进一步扩展，公司最后不得不决定重新组织人员，开发新版本 s y m p h o n y 3 x 在过去3 0 年里，国内建立了很多不同规模的工厂，公司。这些工厂和公司 需要信息系统来支持仓库，生产计划，订单和财务等运作，因此，很多企业内部 建立了小的开发队伍，或是成立了很多小的软件公司，为中小型工厂提供系统解 决方案。这些软件队伍显示了一些共同的特点“： 1 软件开发队伍规模比较小 2 大部分的程序员没有经验 3 他们没有接受良好的软件工程培训，对软件测试不重视。 当前程序正确性证明没有突破性进展的情况下，软件质量的评估。1 ，软件系 统存在的问题和缺陷的查找。1 ，主要是通过软件测试来进行的。但是很多软件开 发项目中并没有对软件测试给予应有的地位和重视，甚至压缩软件测试的周期， 从而使软件质量没法有效保证，结果导致软件成本无法控制。 随着社会的进步，市场的快速变化，对软件开发提出了更高的要求。市场需 求的变化要求软件交付周期越来越短；市场的竞争又要求软件团队在控制软件成 本的基础上，保证软件的质量。 面对软件过程周期的缩短，传统的线性的“开发一) 测试”模型已经难以适 应市场的变化。为了应对这些变化，本论文探讨了新的软件过程模型，通过改进 测试过程，来缩短整个软件周期，提高软件质量，控制软件成本。 西北t 业大学硕十学位论文 第一章绪论 1 2 相关技术和发展现状 随着软件技术的不断发展，软件质量问题越来越为人们所关注。软件测试作 为保证软件质量的一种重要手段，在软件的生命周期里具有十分重要的地位。在 传统的软件开发中，软件测试被认为是一种事后行为，测试活动往往在代码提交 之后才开始。据研究发现，由于需求和设计带来的软件缺陷占所有软件缺陷的 7 0 以上，而由编程带来的缺陷不到加。在软件开发过程的各个阶段产生的缺 陷随着阶段的进展而产生积累与放大效应。因此，许多团队开始重视测试过程的 改进，在项目开发的早期开始，对项目中的需求，设计，代码进行全过程的测试。 和软件开发过程类似，软件测试过程也包括测试计划，测试分析，测试设计 和开发，测试执行，测试报告与结果分析等阶段。在软件项目中，如何有效地将 测试过程与开发过程相结合，在有限的时间内提交合格的软件产品，是决定软件 项目能否成功的关键。 1 3 研究内容 论文结合e g o 开发模型的特点，在充分分析软件过程模型的基础上，制定 适合的软件测试过程，并在实践中检验其有效性和正确性。 为了减少项目风险，提高软件测试的效率和质量，作者引入了测试过程模型 的概念。在对现有的软件测试过程模型进行了分析和研究上，结合项目开发的实 际情况，综合各个模型的优点，改进了测试过程模型，并在e g o 项目的测试过 程中进行了实践。改进的模型应用全过程的测试理念，加强了代码交付之前文档 审查，测试计划和设计等工作，并对测试过程和测试结果的度量和分析做了一定 的研究。 新的测试过程模型打破传统软件开发过程中，开发与测试相互分离的现状， 改进测试过程。将质量保证引入软件测试，在开发测试流程和时间段上，将测试 提前，使开发人员和测试人员的工作能够并行进行，相互合作。测试人员利用自 身的客户产品经验，审查开发人员的需求和设计，尽可能早的发现缺陷，帮助开 发人员开发出高质量的代码。开发人员则利用自身的技术优势帮助测试人员设计 完整的，可扩展的测试计划，测试用例。这样在开发阶段就完成高质量的系统代 码和测试用例，减少了变更成本，提高开发和测试效率。 所以本论文主要研究工作有： 1 详细分析软件测试和软件测试过程 2 西北工业大学硕十学位论文第一章绪论 2 对软件测试过程模型的分析与改进 3 迭代开发模式中测试过程的实现 4 改进的测试过程在e g o “1 ( e n t e r p r i s e dg r i do r c h e s t r a t o r ) a p i 中的实践， 并检验对软件测试效率和软件质量的有效性 1 4 组织结构 本文在深入分析软件测试技术和软件测试过程模型，根据实际的开发过程制 定相应的测试过程，并通过实现实际项目e g oa p i 的测试检验新模型对提高软 件质量的有效性和提高软件测试效率的可行性： 第一章绪论 第二章软件测试概念，介绍了软件测试定义的变迁，详细阐述了软件测试 周期。 第三章软件测试过程，详细阐述几种典型的软件测试模型，分析他们的优 缺点，并提出实际测试过程中的软件测试过程改进。 第四章基于增量迭代模型的测试过程设计，阐述了统一测试模型的特点， 改进迭代模式中测试过程的实现与特点。 第五章改进的测试过程在e g o a p i 项目中的实践。用改进的测试过程模型 指导e g oa p i 项目中测试人员的组织和流程的安排，设计并实现了 一个面向分布式系统的测试自动化框架，来管理和提高测试用例盼 执行。 第六章总结，总结了本文的主要工作和取得的成果，并指出模型需要改进 的地方。 3 西北t 业大学硕士学位论文第二章软件测试概念 第二章软件测试概念 2 1 测试的基本概念 关于测试的定义经历了几个阶段，如表2 - 1 所示。 表2 - 1 测试的定义 时间作者定义 1 9 7 9g l e n f o r dm y e r s测试是为发现错误而执行的一个程序或者系统的 过程 1 9 8 3b i l lh e t z e l测试是评价一个程序或者系统的属性为目标的任 何一种活动，测试是对软件质量的度量。 2 0 0 2r i c kd g r a i g测试是指为了度量和提高被测试软件的质量，对 s t c f a ne j a s k i e l测试进行工程设计，使用和维护的并发生命周期 过程。 m y e r s1 9 7 9 年对测试的定义主要是程序测试，发生在软件开发周期的末期， 其主要日的是发现错误。实践也证明，这种观点的确能发现很多错误，因为很多 需求，设计阶段的缺陷一直推迟到最后才发现，结果导致软件变更成本急剧飙升， 软件质量也不理想。 随着软件工程的实践，1 9 8 3 年b i l lh c t z c l d c 的测试定义已经不局限于寻找错 误，定义测试是软件质量的度量，通过软件测试来评测软件的功能和性能指标。 g r a i g 和j a k i c l 最近的定义更是加入了软件质量保证的思想，并且认为软件 测试本身就是一个系统的过程。在测试中不仅要对被评测软件进行测试，同时对 测试本身也有很高的要求，包括测试的效率，效能，质量成本等。 软件质量保证面向整个软件开发过程，参照一定的质量标准，目标和各项软 件流程，规范来管理和监督公司的质量，同时对过程进行改进。 现在我们认为软件测试不等于程序测试，它贯穿于软件定义和开发的整个生 命周期，是软件质量保证的重要手段，需求规格说明，概要设计规格说明，详细 设计规格说明，源程序都是软件测试的对象。1 。研究资料表明，在传统的软件开 发中花在测试的时间占到约软件开发总时间的4 0 ，如图2 1 ： 4 西北工业大学硕士学付论文第二章软件测试概念 汛n 输j 2f 绝j i f 图2 - 1 传统过程中测试占用整个周期的时间 测试周期过长的原因主要是在软件单元测试和集成测试阶段，大量缺陷的修 改和反复，以及测试效率的低下造成的，所以在实际项目中，我们要根据开发过 程的特点，严格管理软件测试的过程，提高软件测试效率，保证软件质量。 2 2 软件测试分类 从测试实施的途径来分，软件测试主要有静态测试和动态测试。 2 2 1 静态测试 静态测试依据事先定义的属性，标准和规范对相关产品进行检查。在软件开 发的过程中，静态测试通常在系统还没有实现前进行，如需求测试，设计审查， 测试策略走查，测试用例审核，代码审核等。静态测试能使软件缺陷在开发的早 期被发现，从而节省在实现后阶段里修复缺陷的时间和开销。本论文中的静态测 试指广义的静态测试，包括质量保h 正( o u a l i t y a s s u r a n c e ) q a 所有的静态验证和确认 技术，即走查( w a l k t h r o u g h ) ，检查( i n s p e c t i o n ) ，评审( r e v i e w ) 和审计( a u d i t ) 。详 细的走查，审查技术请参考文献。 静态测试的一种途径是评审，主要目的是评估项目进展、资源分配、技术充 分性以及是否与规约一致。在这种分类中i e e e1 0 2 8 描述的方法包括技术评审和 5 西北工业大学硕十学位论文 第二章软件测试溉念 管理评审。技术评审的目的是评估规约与项目计划的一致性，以确保变更过程的 完整性。管理评审并不是将检测和排除缺陷作为主要目标，而是为了确定项目进 展在项目级别上引入纠正措施以及确保资源的适当分配。 2 。2 2 动态测试 动态测试通过执行程序来验证系统的功能是否与需求一致。动态测试需要一 个可执行的系统，因此动态测试通常在编码开始之后开始。 从动态测试的类型来看，动态测试分为2 种：黑盒测试和白盒测试。 i 黑盒测试又称为功能测试或数据驱动测试，把系统看成一个黑盒子，不 考虑程序的内在逻辑，只根据需求规格说明书的要求来检查程序的功能 是否符合它的功能说明。 2 白盒测试又称为结构测试和逻辑驱动测试，允许测试人员对程序内部逻 辑结构及有关信息来设计和选择测试用例。对程序的逻辑路径进行测 试。 动态测试按测试阶段可以分为： 1 单元测试 单元测试是对软件中的基本组成单位进行的测试，如一个模块，一个过 程等等。它是软件动态测试的最基本部分，也是最重要的部分之一，其 目的是检验软件基本单位的正确性。一个软件单元的正确性是相对于该 单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元 测试的主要方法有控制流测试，数据流测试，排错测试，分域测试等等。 2 集成测试 集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软 件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其它 软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系 统是否正确，各组成部分是否合拍。集成测试的主要策略有自顶向下和 自底向上两种。 3 系统测试 系统测试是对已经集成好的软件系统进行的彻底的测试，以验证软件系 统的正确性和性能是否满足其规约所指定的要求。检查软件的行为和输 出是否正确并非一项简单的任务，它被称为测试“先知者问题”。因此， 6 西北工业大学硕十学位论文 第二章软件测试概念 系统测试应该按照测试计划进行，其输入，输出和其他动态运行行为应 该与软件规约进行对比。软件系统测试方法很多，主要有功能测试，性 能测试，压力测试，长寿命测试，量测性测试，可靠性测试等。在系统 钡试中，不仅需要对系统的功能进行测试，还要对非功能属性进行测试， 系统的非功能属性主要有性能，可用性，安全性，兼容性，恢复性等等。 非功能测试的生命周期和功能测试一样，贯穿于软件开发的整个过程。 与功能性测试相比，非功能性测试需求是相当难确定的，像可用性，可 维护性这样的需求相对比较主观，不是很容易测试。而且大多数的非功 能性软件缺陷和设计有关，修复的代价相对较高，因此，需要将非功能 性测试在软件测试过程中适当提前准备，而不是到用户验证时才迸行。 4 验收测试 验收测试旨在向客户证明该软件系统满足客户的需求。它的测试数据通 常是系统测试的测试数据的子集。所不同的是，验收测试常常有客户代 表在场，这是软件在投入之前的最后测试。 5 回归测试 回归测试是在软件维护阶段，对软件进行修改之后进行的援i 试。其目的 是检验对软件进行修改是否正确。这里修改的正确性有两重含义：一是 所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境 等等：二是不影响软件其他功能的正确性。 静态测试和动态测试并不是可相互替代的方法，这两种方法都有其长处，静 态测试可以在早期进行应用，可以应用到生命周期早期的制品中，而动态测试只 能在执行完整的代码对应用。这使得静态测试比动态测试具有更大的功效。这是 因为，从根本上说，用一种方法发现的所有缺陷的比例以及能够使用这种方法的 阶段是这种方法功效的决定因素。另外，从发现的缺陷百分率以及标识和排除缺 陷所需要的时阔这样的度量来看，静态检查总是优于测试的，如表2 - 2 。 表2 - 2i b m 检查和测试的效率统计结果 测试检查 发现错误率3 5 6 5 占用资源( 时间人力) 8 0 2 0 百分比 效率o 3 5 0 8 0 - - - 0 4 40 6 5 0 2 0 = 3 ，2 5 相对效率 1 7 4 7 西北工业大学硕十学位论文 第二章软件测试概念 2 3 软件测试周期 如同软件生命周期，我们也可以将软件测试阶段按照生命周期的方法去分类 为：计划阶段，设计阶段，测试执行阶段，结果评估阶段。 1 测试计划阶段：这是产品测试概念定义的阶段，制定一个高级别的测试 计划即测试大纲，工作主要是管理人员在做，然后让测试组员进入某些 活动，包含的工作是： 1 ) 制定测试的目标，质量参数，b e t a 测试的验收标准等。 2 ) 制定各个阶段进行评审的时间，对上一阶段的情况进行分析和总结， 讨论测试覆盖率，某些测试用例，人员组织等。 3 ) 制定项目的跟踪。比如一些跟踪文档，每周提交的周报。例如在周 报里面包含着本周新写多少个问题，解决了多少个问题，有多少问 题是无效的，运行了多少个测试用例，通过率是多少等。制定详细 项目计划表。包括每个阶段的具体时间了，需要的人数了，需要的 资源了等等。 4 ) 复检产品定义文档。主要是重新对设计文档进行阅读，对现在开发 的产品进行检验，防止出现误差。并且对一些设计提出用户角度的 观点等等。这个应该不用所有测试人员参与。生成的应该是设计文 档的一个修改和一个会议记录之类的文档。 5 ) 制定错误报告的流程，制定错误报告的类型，制定软件可接受标准， 制定错误的优先级别。一般分为紧急，一般，较高的级别。用来给 开发人员参考，那些需要先修改哪些可以推迟。 6 ) 设立一个数据库将手工测试和自动测试用例放到一起管理。输入应 该包括编号，关键字用于记录每个测试用例在不同软件版本时的情 况。 2 测试设计阶段：分为测试需求分析阶段和测试用例设计阶段。 1 ) 测试需求分析阶段。这个阶段的工作主要是从客户和开发小组得到 相关文档，进行分析和总结。根据得到的信息，去创建测试的框架 和文档。并不是要所有的文档工作都在本阶段内完成。包括的主要 工作是：根据设计说明书来划分需要测试的功能区域，每个区域内 要测试的元素和功能逻辑；制定测试用例格式，就是制定一系列的 g 西北工业大学硕士学位论文 第二章软件测试概念 文档格式。对于u i ，功能，性能，自动化测试脚本等应该都有不同 的格式规范，然后给出测试优先级别，这样优先级别低，对系统影 响小，一般都比较稳定的一些测试用例就可以减少测试频率和周期 次数。最好给每个测试用例估计一个时间，这样便于统计和管理人 力资源；制定测试轮次和时间线，根据写好的测试用例估计的时间， 按照对系统的不同测试点来制定测试轮次。然后每个轮次之间有个 时间点。例如在刚刚收到产品时，做的都是简单的功能的验证测试。 这时候可以设置一个测试目标，选择一批测试用例。然后在测试目 标达到后( 比如，测试用例通过率达到8 5 ) 就可以进行复杂的功 能测试。这个就可以称之为一个轮次。是以测试用例走完一遍为测 试轮次的。当然也可以设置，一周或一个月为一个轮次。因此我们 看到，这个实际上考验的是一个领导者制定计划和管理执行计划的 能力。好的管理人员就能够制定有效的针对具体系统不同的计划， 而不是一成不变，老是用一套方法。根据功能验证矩阵书写测试用 例。测试用例书写的标准就是满足需要，而不是硬套模板。将用户 需求中的设定测试数据和测试用例链接。有些用户，需要你对某些 特殊的数据结构或者数据类型等等进行测试，这时候就需要将那些 数据独立出来，以便能够复用。标示出能够使用自动工具的测试用 例。这样，在人力资源较少的时候，或者需要快速回归的时候就可 以使用自动工具了。有些测试用例是直接就写成测试脚本使用测试 工具测试的。有些是事先写为手工测试测试用例，可以通过使用已 有的自动测试脚本快速的编制成自动测试用例的。毕竟手工测试和 自动测试各有利弊。对于自动化测试组来说，这个时候就要做一些 基本的工作了。像一些公用的文件和一些基础的公共函数和方法。 制定出要进行压力测试和性能测试的区域。并书写测试用例。根据 已经完成的测试用例，开始制定测试轮次中包括的测试用例，总轮 次，测试时间等等。不断的复查文档，防止出现偏差。这个工作可 以有一个固定周期，比如一个月内有几次，分别查看那些文档等等。 检查测试环境。包括软件，硬件，人力等等。 2 ) 测试用例设计阶段。本阶段是完成测试用例的最后阶段，这些文档 大部分都是在分析阶段形成了大体的组织结构和大纲的文档，像测 试用例之类的都有了一些基本的描述，本阶段主要的工作就是完成 这些文档的最终书写。在本阶段后，基本上测试计划，测试时间表， 9 西北工业大学硕士学位论文 第二章软件测试概念 测试数据，各种相关文档都应该处于完成阶段。当然，仍然可以通 过设计的危机处理机制进行更新。但是特别要指出的是，不是全部 测试用例并能够在本阶段完成。由于新功能的添加，具体功能的实 现方法，修改功能等因素，测试用例只能不断的更新。1 ) 根据具体的 变化重新调整测试计划。2 ) 根据计划的调整，调整各个测试轮次的 内容和时间。3 ) 根据变化调整功能设置。4 ) 确认已有的测试用例 和测试数据仍然有效。5 ) 继续书写已经设定的测试用例和添加新的 测试用例。一个测试用例，在本文中在上个阶段书写的时候可能只 有一个简单的描述，具体的测试步骤需要后面填写。有的时候，有 些测试用例事先没有考虑到，有些是重复的，所以需要删改。5 ) 设 置风险评估标准。通过设置风险评估，可以有效的帮助我们灵活的 调整计划。比如，某个测试轮次是需要5 0 个小时完成，而我们风险 评估标准将这类测试设定的时间应该设置为1 5 0 ，也就是说，在计 划中应该填写7 5 小时为实际设定完成时间。6 ) 最终完成各个测试轮 次的设置。在本阶段结束后，除非有其他的特殊情况，通过预先设 ， 置的危机处理方法处理外，不再修改。7 ) 完成测试计划。最后评估 支持开发人员进行单元测试的可行性。有些项目，需要测试人员去 帮助开发人员进行单元测试。 3 测试执行阶段：本阶段是在开发人员编码的同时，最终完成系统预先设 置的各种测试用例，对产品进行实现设定的各种测试。 1 ) 完成单元测试，完成所有的手工测试用例。随着系统不断开发，在 拿到一个完整的软件版本之后，基本上手工测试用例都能够完成书 写。实际项目中，单元测试用例的书写要有一定的标准，以便于后 面自动化框架的管理。 2 ) 完成自动测试工具的开发。这个阶段可以设计编写一些专用的自动 测试工具。 3 ) 完成一些系统测试用例。比如压力测试用例，性能测试用例等。 4 ) 重新复检功能表，审查测试用例的覆盖率。 5 ) 完成自动测试用例。 6 ) 反复测试：这个阶段就是最费时间的阶段了。按照实现制定好的计 划，利用各种资源，工具，依循实现书写的测试用例对系统进行一 轮轮的测试，直到代码冻结阶段。本阶段也包含了不断设置的回归 测试。 1 ) 第一轮测试。2 ) 发现缺陷，并提交报告。3 ) 开发人员解决 1 0 西北 ：业大学硕士学位论文第二章软件测试概念 后的缺陷验证4 ) 修正测试用例5 ) 添加新的测试用例6 ) 第二轮测试 7 ) 第三轮测试 。 n 最后的测试。本阶段是代码冻结后的测试阶段。这个时候需要进行 的是最后的验证测试。本轮主要是完成最终的性能，压力，文档测 试和u i 等测试过程，开始形成系统说明书和用户手册。 以上测试 就是最终的功能测试，这个时候一般不在去修改主要的源代码，只 是对外观和界面的错误进行修复。只是对现有的一些问题进行跟踪 和管理，最后准备发布版本。 4 测试结果评估：本阶段是对整个项目进行总结的阶段。主要是书写一些 最终的报告。例如，错误分析报告，包括一共有多少个，有效率是多少， 分布情况如何等等。这个阶段主要是将好的经验总结下来，对不足进行 思考，为下个项目做准备的总结的阶段。 从上面的叙述来说，这些阶段并不完全的各自独立的阶段。划分的主要依据 是根据主要的工作目标而来。各个阶段不但相互影响，而且有时候时间上还会彼 此交叉和颠倒。但是，最大的好处就是能够让测试人员更好的理解各项工作的目 标和作用。而不是独立的去写测试用例，却不管为什么 2 4 小结 在传统的软件开发中，软件测试被认为是一种事后行为，测试活动往往在代 码提交之后才开始。据研究发现，由于需求和设计带来的软件缺陷占所有缺陷的 7 0 以上，这样在软件开发早期阶段的缺陷就会积累到后期，结果导致修改成本 剧增。因此，测试应该在项目开发的早期开始，对项目中的需求，设计，代码进 行全程的测试。 本章回顾了测试定义的变迁，详细说明了软件测试的周期，为测试过程的设 计提供基础。 西北丁业人学硕十学付论文 第二章软件测试过陧 第三章软件测试过程 3 1 软件测试过程概述 软件测试过程是用于定义软件测试的流程和方法，将软件测试周期中各个阶 段映射到对应的开发阶段。众所周知，开发过程的质量决定了软件的质量，同样 的，测试过程的质量将直接影响测试结果的准确性和有效性。软件测试过程和软 件开发过程一样，都遵循软件工程原理，遵循管理学原理”。 一个软件测试过程模型的内容应包括，在测试过程中应考虑哪些问题，如对 测试进行计划，测试要达到什么目标，什么时候开始，在测试中要用到哪些信息 资源。好的测试模型的应用，能使测试活动在软件开发中变得更有效。 软件开发的几十年中，随着开发过程的不断发展，开发理论的日趋成熟，软 件测试专家通过实践总结出了许多很好的测试过程模型。这些模型将测试活动进 行了抽象，并与开发活动有机的进行了结合，是测试过程管理的重要参考依据。 3 2 软件测试过程模型介绍 3 2 1v 测试模型 v 模型最早是由p a u l r o o k 在2o 世纪80 年代后期提出的，旨在改进软件 开发的效率和效果。v 模型反映出了测试活动与分析设计活动的关系。在图3 - l 中，从左到右描述了基本的开发过程和测试行为，非常明确的标注了澳0 试过程 中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶 段的对应关系。 v 模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求； 系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试 确定软件的实现是否满足用户需要或合同的要求。但v 模型存在一定的局限性， 它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动， 而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。 1 2 两北工业大学硕士学位论文 第二章软件测试过程 3 2 2 w 测试模型 图3 - i 软件测试v 模型 w 模型由e v o l u t i f 公司公司提出，相对于v 模型，w 模型增加了软件各开 发阶段中应同步进行的验证和确认活动。如图3 - 2 所示，w 模型由两个v 字型 模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。 图3 - 2 软件测试* 模型 w 模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程 西北丁业大学硕士学位论文第二章软件测试过程 序，需求、设计等同样要测试，也就是说，测试与开发足同步进行的。w 模型 有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到 对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有 利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试 时间，加快项目进度。 但w 模型也存在局限性。在w 模型中，需求、设计、编码等活动被视为串 行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束， 才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件 开发复杂多变的情况，w 模型并不能解除测试管理面临着的困惑。 3 2 - 3h 测试模型 v 模型和w 模型均存在一些不妥之处。如前所述，它们都把软件的开发视 为需求、设计、编码等一系列串行的活动，而事实上，这些活动在大部分时间内 是可以交叉进行的，所以，相应的测试之间也不存在严格的次序关系。同时，各 层次的测试( 单元测试、集成测试、系统测试等) 也存在反复触发、迭代的关系。 为了解决以上问题，有专家提出了h 模型。它将测试活动完全独立出来， 形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来， 如图3 3 所示。 到试就绪点p 图3 3 软件测试h 模型 测试琉程v 萁蚀流徨( 如设计流稷 这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。 图中标注的其他流程可以是任意的开发流程。例如，设计流程或编码流程。也就 是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以( 或者 说需要) 进行了。 h 模型揭示了一个原理：软件测试是一个独立的流程，贯穿产品整个生命周 1 4 西北工业大学硕士学位论文 第三章软件测凌过程 期，与其他流程并发地进行。h 模型指出软件测试要尽早准备，尽早执行。不同 的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试 达到准备就绪点，测试执行活动就可以开展。 3 3 几种测试过程模型分析 前面介绍的测试过程模型中，v 模型强调了在整个项目开发中需要经历的不 同的测试级别，但忽视了测试的对象不应该仅仅是程序。而w 模型在这一点上 进行了补充，明确指出应该对需求、设计进行测试。但是v 模型和w 模型都没 有将一个完整的测试过程抽象出来，成为一个独立的流程，这并不适合当前软件 开发中广泛应用的迭代模型。h 模型则明确指出测试的独立性，也就是说只要测 试条件成熟了，就可以开展测试。 我们在2 3 节详细论述了软件测试周期及其各个阶段的主要工作。但是在实 际软件项目中由于各种原因，比如人员变化，软件变更等，软件测试并不是按照 理想的计划进行的，而是时刻充满着改变。 为了使测试过程的管理更加有效和便捷我们对测试过程模型的改进集中在 以下三个方面：开发人员与测试人员的关系，独立测试与自动化框架的使用。 1 开发与测试的协作：当前软件测试过程模型都集中在软件测试阶段的划 分，但是在实际测试工作中，开发人员和测试人员有各自的技术优势， 所以他们之间共享资源和直接沟通可以大大提高开发测试的效率。基于 此软件过程模型应该考虑团队内的积极协作。 2 独立测试：w 模型是根据软件开发过程的各个阶段建立的模型，h 模型 提出了独立测试的模型，但是却只突出单个的流程，没有全局的概念。 所以我们可以考虑结合软件测试周期的各个阶段进行建模。 3 自动化框架的使用。确切说自动化框架属于测试用例设计范畴，但是在 软件执行流程的角度看，自动化框架属于测试准备工作的最后阶段，为 了充分提高测试效率，我们应该将自动化框架的开发也在测试过程中考 虑。理想的情况是，在恰当的时机，我们完成自动化框架，完成测试用 例，然后直接用框架来运行，管理，维护测试用例。 3 4 小结 本章首先介绍了软件测试过程的发展，接着介绍了近几年成功的测试过程模 型，最后在分析他们的优缺点的基础上，进行改进并提出一组核心工作流来管理 和指导软件测试。 两北- i = 业大学硕士学位论文第四章基丁二迭代增量模犁的测试过程设计 第四章基于增量迭代模型的测试过程设计 e g o 项目开发选用了增量迭代模型，其中的测试管理过程并不成熟。本章 结合迭代开发过程的特点，完善适合增量迭代模型的软件测试过程。并提出独立 的测试管理模型，有力的管理和指导测试。 4 1 迭代开发的特点 采用极端的瀑布型开发方法意味着你要以严格的顺序来完成一系列的项目 阶段：需求分析、设计、实现，集成然后是测试。当软件项目中出现的问题解是 困难的并且解决问题是昂贵的时，你可能会推迟测试直到项目周期的末端：这些 问题也能够严重的威胁软件发布的期限并且使主要的团队成员在某些开发环带 上是空闲的。 相比较而言，迭代开发方法包括了一系列的增量的步骤或者迭代。每一个迭 代都包括一些或者很多的开发活动( 需求、分析、设计、实现等等) 。每一个透 代也有一系列良好定义的目标并生成最终系统的部分工作实现。每个后续的迭代 都建立在前一个迭代的基础上以使系统得到发展和细化，直到最终产品完成。如 图4 1 。 需柬 客户需求 惫计划 初始彩嚏穆 计划 图4 - 1 迭代开发流程 早期的迭代着重于需求、分析和设计；后期的迭代着重于实现和测试。 1 6 西北工业大学硕士学位论文第四章基于迭代增阜模犁的测试过稃设计 迭代开发过程允许需求的变化。需求的变化和“进一步的蔓延技术和客户驱 动的特性的累加一直是项目中导致麻烦、延期交付、令客户不满意和使开发人员 泄气的主要原因。为了解决这些问题，使用迭代开发方法的团队应该在项目开发 的几周里就关注生成和演示可执行的软件，这样就强制了需求的检查并可以帮助 减少需求从而反映系统的本质。 结合迭代开发的优点，我们可以用增量迭代开发方法，将项目分解成为两个 或者更多的部分，有时这些部分被称为阶段或者时期，在各个小的部分或阶段运 用迭代开发： 1 这种改良可以帮助简化集成、使测试人员更早的进行测试工作和提供更 旱的项目状态的观测。 2 这种方法也将代码分解成易于管理的片断，并最小化成存根或驱动程序 形式的、被测试需要的代码集成。 3 此外这种方法允许你原型化你认为有风险的或者有难度的部分，并且使 用来自每一个阶段的反馈修改你的设计。 由此可见，将测试提前到软件开发过程中去是完全可行的，此外更可以发挥 测试人员丰富的产品经验，帮助开发人员审查需求和设计，进一步保证软件质量。 4 2 测试模型的改进 4 2 1 原有模型的不足 实际开发过程中，迭代增量开发对软件开发的各个阶段进行了概括的定义， 但是从软件测试的角度出发，该模型测试活动并不完整，尤其是迭代开发每个阶 段周期相对比较短，每个阶段测试过程都会不断的改进，已有的测试模型不能适 应测试过程的快速的变化。所以我们给出测试过程模型的改进来指导测试过程的 快速变化。 4 2 2 统一测试过程模型 由于迭代增量开发模型在管理测试过程上的不足之处，我们认为有必要根 据项目的各个阶段为测试活动定义一个独立的模型，这种独立的测试模型能够使 测试过程的管理更有效与便捷。 1 7 西北工业大学硕士学位论文第四章基于迭代增量模型的测试过程设计 为了比较每个阶段测试的不同，我们选择一组核心的测试工作流。 统一测试模型选择了五个软件测试核心的工作流，分别为测试计划，测试设 计，静态测试，动态测试和测试评估。将软件测试周期中的主要括动与开发阶段 在二维空间中表示出来。这个图形没有区分开发人员与测试人员，下面我们通过 一张辅助的表阐述该模型中人员与活动间的关系。 图4 - 2 统一测试模型 以软件过程的阶段为轴，可以清晰的得出，每一个阶段对应的测试类型有。 1 需求分析：测试计划制定，测试用