测试周期和模型笔记

1、软件测试周期和测试模型目标：了解软件生命周期及常见开发模型掌握常见测试模型的原理及基本概念了解测试模型的使用内容提要：第一节：软件生命周期软件危机软件工程简介软件生命周期简介软件生命周期的主要阶段第二节：软件开发模型软件开发模型简介瀑布模型渐进原型模型螺旋模型RUP软件开发过程第三节：软件测试模型软件测试模型简介V模型W模型H模型其他测试模型测试模型的使用第一节危机 实例（回顾）爱国者导弹防御系统，1991千年虫问题首都机场离港电脑系统，2002英特尔奔腾浮点除法软件缺陷，1994（证券交易所、航空公司等等熊猫烧香，黑色星期五）危机 统计数据1997年，美国公司花在软件项目上的经费为￥2500

2、亿到￥3000亿（为什么80%的时间都用在修改错误和返工上了呢？）危机 表现开发预算 再突破开发进度 拖再拖软件产品质量不可靠软件难以维护用户对“已完成的”软件系统不满意软件工程 提出消除软件危机的途径 技术措施（方法和工具） 组织管理措施软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科1968年NATO学术会议上提出软件工程的概念软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理软件工程 基本目标降低软件开发和生产的成本达到要求的软件功能获得较好的软件性能需要较低的软件维护费用开发的软件易于重用能按时完成开发工作，及时交

3、付使用软件工程 一般视图定义阶段：做什么开发阶段：如何做支持阶段：变化软件工程 软件生命周期生命周期 人的生命周期：婴儿、幼儿、儿童、少年、软件生命周期软件从用户需求开始，经过开发、交付使用，在使用中不断增补修订，直到退役的全过程软件定义软件开发软件支持问题定义可行性分析需求分析概要设计详细设计编 码测 试软件发布软件运行维护或退役软件生命周期的主要阶段软件需求分析软件实现软件集成软件验收交付软件维护系统分析与软件定义系统分析与软件定义主要工作分析系统要求和使用环境拟定软件任务书和明确软件验收方法确定软件关键程度等级完成标志制定软件研制任务书主要质量控制手段评审软件研制任务书拟定软件质量保证大

4、纲开始问题定义可行性研究可行否终止项目的建议项目实施的计划停止转开发期软件需求分析主要工作确定软件的功能、性能和接口要求，编写需求规格说明制定软件可靠性、安全型设计准则拟定软件的系统测试计划完成标志提交软件需求规格说明提交项目开发计划主要质量控制手段评审软件需求规格说明制定软件质量保证大纲实施计划，并选定适当的规范软件设计主要工作进行软件概要设计和详细设计对关键、重要的软件进行可靠性、安全性分析拟定软件的集成测试计划完成标志提交软件概要设计说明提交软件详细设计说明主要质量控制手段评审软件概要设计和详细设计说明软件配置管理软件实现主要工作编写程序对程序进行代码复审、静态分析和单元测试编写软件使用

5、说明完成标志提交源程序提交程序单元测试规程、用例和报告提交软件使用说明（初稿）主要质量控制手段源程序的代码复审、静态分析和单元测试软件配置管理软件集成主要工作进行软件的集成与测试完成软件使用说明的编制完成标志提交通过测试的软件系统提交软件集成测试和系统测试分析报告提交软件使用说明主要质量控制手段对软件集成测试和系统测试的计划、规程、用例和报告进行评审，对测试过程进行监控软件配置管理软件验收交付主要工作进行软件的验收测试和审计组织软件的交付完成标志通过验收测试主要质量控制手段对软件验收测试和交付过程进行监控和审核第二节软件开发生命周期模型 概念主要功能确定项目计划、需求分析、设计、实现、测试或其

6、它相关活动的次序，使得这些活动能够有序的进行作用借助已有的经验一致的工作框架专心自己的工作考虑因素由于软件项目各不相同，所需的模型也有差异缺乏通用模型时，组织或项目必须定义满足特定需求的模型用于给定项目时，必须考虑人员经验水平、产品当前状态和可用的工具和设施软件开发生命周期模型 类别瀑布模型渐进原型模型螺旋模型RUP软件开发过程瀑布模型 优缺点优点严格、应用广泛、提供了模板缺点实际的项目很少按照该模型给定的顺序进行软件运行版本要等到开发周期的晚期才能得到，如有重大问题，后果是灾难性的客户常常难以给出所有需求，但瀑布模型却要求如此，缺乏适应需求变化的灵活性瀑布模型可能会导致过多的文档，更新文档成

7、为一项专门的工作因等待造成“阻塞”瀑布模型 使用时机存在一个稳定的产品定义对一个定义得很好的版本进行维护将一个产品移植到一个新的平台上很容易理解但很复杂质量需求高于成本和进度需求开发队伍实力不强技术力量比较薄弱缺乏足够的工程经验需求不稳定的风险1987年美国国防部的关于军用软件的研究报告中指出“作用复杂的硬件系统，最困难的是搞清软件任务的需求”，“没有技术和方法建立详细的需求，对于需求的错误判断严重的影响效率、费用和进度”“我们相信，没有在真实的操作环境下测试并对需求反复迭代，用户无论怎样努力和聪明，也不可能说清操作需求”美国国防部的报告对软件界产生深刻的影响，加速了从顺序到迭代方法的发展渐进

8、原型模型 特征渐进原型模型是为确定需求而提出的一种机制开发者和用户共同定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域，然后快速设计出原型，原型重点实现软件中那些用户可见部分（输入方式、输出格式）。原型由用户评估并进一步细化待开发的软件需求。逐步调整原型使其满足用户的要求，同时也是开发者对将要做的事情有更好的理解通过原型确定正确的软件需求后，进一步进行系统的设计与实现渐进原型模型 图示计划需求分析原型开发原型评价最终系统设计最终系统实现渐进原型模型 使用时机用户定义了软件的一组一般型目标，但无法确定详细的输入、处理和输出需求开发者不能确定算法的有效性、操作系统的适应性、人机交互的

9、形式渐进原型模型 风险管理不切实际的进度和预算项目可控性降低缺乏最终用户或客户的反馈产品性能不佳不切实际的性能期望设计不佳可维护性差目标偏移原型开发阶段效率低下渐进原型模型 如何成功在开始就决定要开发的原型是要保留的还是要丢弃的，并确保管理者和开发者都明确明确客户的期望与项目进度、预算及产品性能之间的关系控制客户与原型间的交流，减少对项目的影响使用有经验的开发人员在每个阶段使用代码质量检查表，确保原型系统的质量和可维护性尽早考虑产品的性能螺旋模型 特征螺旋模型是一种以风险为导向的生命周期模型，主要基础是迭代式的风险评估。把一个软件项目分解成若干个小项目，每个项目都表示一个或者多个风险因素，直到

10、所有主要风险因素都被确认为止在螺旋模型中，软件开发是一系列的增量发布，这些增量可能是文档化的模型或快速实现的原型，也可能是软件产品的部分实现，随着迭代的进行更完善的版本逐渐产生螺旋模型 迭代步骤确定目标、方案和约束条件识别并解决风险评价备选方案开发本次迭代可共交付的内容，并检查其正确性如果需要，规划下一个迭代过程，开始新的迭代过程螺旋模型 图示P33截取图螺旋模型 优缺点优点：风险管理过程灵活性缺点：使用该模型需要具有相当丰富的风险评估经验和专门知识目前，国内软件公司还未能及时掌握和运用，有待进一步积累经验RUP是什么（Rational Unified Process）RUPRational公

11、司的改进过程的规范给出了最完善的团队建设解决方案它又是文档化的软件工程产品，所有RUP的实施细节及方法导引均以Web文档的方式集成在一张光盘上，由Rational公司开发、维护并销售RUP又是一套软件工程方法的框架，各个组织可根据自身的实际情况，以及项目规模对RUP进行裁剪和修改，以制定出合乎需要的软件工程过程与统一建模语言（Unified Model Language，以下简称UML）的良好集成、多种CASE工具的支持、不断的升级与维护、迅速得到业界广泛的认同，越来越多的组织以它作为软件开发模型框架截图P39如所示：时间维从组织管理的角度描述整个软件开发生命周期，是RUP的动态组成部分。它可

12、进一步描述为周期（Cycle）、阶段（phase）、迭代（Iteration）。核心工作流从技术角度描述RUP的静态组成部分，它可进一步描述为行为（activities）、工作流（workflow）、产品（artifact）、工人（worker）RUP是采用Usecase的概念RUP采用迭代的思想把系统的风险分布在四个阶段，风险越大的迭代越要放在靠前的阶段做理解和掌握RUP需要一个相对较长的过程课堂练习软件生命周期模型主要解决什么问题？有哪几种常见的生命周期模型，其优缺点是什么？测试过程在模型中有哪些体现呢？第三节在软件开发几十年的实践过程中，人们总结了很多的开发模型，对软件开发过程具有很好的

13、指导作用开发模型中没有充分强调测试的价值，也没有给测试以足够的重视，利用这些模型无法很好地指导测试实践显然软件测试也需要测试模型去指导实践非常可喜的是软件测试专家通过测试实践总结出了很多的测试模型软件测试V模型 概述V模型是最具有代表意义的测试由Paul Rook在20世纪80年代后期提出在英国国家计算中心文献中发布，旨在改进软件开发的效率和效果在传统的开发模型中，认为测试只是收尾工作，而不是主要的过程，V模型的推出就是对此种认识的改进软件测试V模型 图示P45软件测试V模型 应用V模型是软件开发瀑布模型的变种明确地标明了测试过程中存在的不同级别清楚地描述了测试阶段和开发过程各阶段的对应关系测

14、试策略既包括低层测试又包括高层测试指出：单元和集成测试应当验证程序设计；系统测试应当验证系统设计；确认测试和验收测试应当验证软件需求说明书软件测试V模型 局限性容易使人理解为测试是软件开发的最后阶段需求分析阶段隐藏的问题一直是后期的验收测试才被发现软件测试W模型 建立V模型的局限性没有明确地说明早期的测试不能体现“尽早地和不断地进行软件测试”的原则在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE std 1012-1998软件验证和确认（V&V）的原则软件测试W模型 图示P52软件测

15、试W模型 应用W模型由Evolutif公司提出是V模型自然而然的发展强调测试伴随着整个软件开发周期测试对象不仅仅是程序，需求、功能和设计同样要测试测试与开发同步进行，有利于尽早发现问题，改进项目内部的质量，显著减少测试时间，加快项目进度软件测试W模型 局限性W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动软件开发和测试保持一种线性的前后关系，就无法支持迭代、自发性以及变更调整对于很多文档需要事后补充，或者根本没有文档的做法下，开发人员和测试人员都面临同样的困惑软件测试H模型-建立V模型和W模型均存在一引动不妥之处把软件开发视为需求、设计、编码等一系列串行的活动相应的测试之间也

16、不存在严格的次序关系各层次之间的测试也存在反复触发、迭代和增量关系V模型和W模型都没有良好地体现测试流程的完整性为了解决以上问题，专家提出了H模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来软件测试H模型 图示P56软件测试H模型 应用示意图仅演示了某个层次上的测试“微循环”概括的说，H模型提示了：只要测试条件成熟，测试准备活动完成，测试执行活动就可以进行软件测试不仅仅指测试的执行，还包括很多其他的活动软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行软件测试要尽早准备，尽早执行软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的软件测试X模型 图示P58软件测试X模型 概述X模型的基本思想是由Marick提出的X模型是对V模型的改进X模型左边描述的是针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序，然后再对这些可执行程序进行测试已通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分多根并行的曲线表示变更可以在各个部分发生X模型还定位了探索性测试软件测试前置测试模型 图示P60软件测试前置测试模型 概述前置测试模型是由Robin F.Goldsmith等人提出前置测试模型体现了以下