3-1 软件生命周期中的测试_图文.ppt.

*
案例分析
“School项目”应该采用什么生存期模型？
*
学生成绩管理主要包括数据维护、成绩查询和成绩统计等三大功能模块。其中数据维护应实现班级、学生、课程和课程成绩等信息的录入、修改和删除等功能；成绩查询包括按学生查询其所有课程的成绩、按课程查询所有学生的成绩、按课程和班级查询所有学生的成绩；成绩统计包括按学生统计学分、平均成绩、班级名次和不及格课程门数，按课程统计学生平均成绩、及格率、优良率（80及以上为优良）。
*
本章要点
一、生存期模型定义 二、常用生存期模型 瀑布 V模型 原型 增量 螺旋式 快速应用开发 渐近式阶段 三、案例分析
*
V模型
接收测试
集成测试
系统测试
项目规化
需求分析
总体设计
详细设计
编码和调试
集成测试
单元测试
*
V模型模型适合的项目
项目的需求在项目开始前很明确 解决方案在项目开始前也很明确 对系统的性能安全很严格的项目 类似的项目如： 航天飞机等 公司的财务系统
项目规划
项目规划
*
产品阶段1设计
阶段目标： 设计公共控制系统功能模块 输入： 系统设计文件 数据库结构定义 过程： 详细设计 输出： 详细设计文件 时间计划： 2001/1/15-2001/2/15（暂定）
*
其它模型
其他 例如:Code and fix 自定义
*
常用生存期模型
瀑布Waterfall V模型V-shaped 原型Prototyping 增量Incremental 螺旋式Spiral 快速应用开发RAD 渐近式阶段
*
本章要点
一、生存期模型定义 二、常用生存期模型 瀑布 V模型 原型 增量 螺旋式 快速应用开发 渐近式阶段 三、案例分析

二、测试阶段概述
5、系统测试概述 ： 基本过程： 1、 软件项目立项，软件项目负责人将项目启动情况通报给测试组长，测试组长 指定测试工程师对该项目进行系统测试跟进和执行。 2、 测试工程师首先参与前期的需求分析活动、前景评审、业务培训、SRS评审。 目的是了解系统业务及范围、了解软件需求及范围，验证需求可测性。并将所有收集 到的测试需求汇总并输出到《测试需求管理表》中。 3、 测试工程师根据测试需求定义测试策略，并进行工作量估计。 4、 测试工程师根据测试需求制定测试策略和方法；系统测试工程师参与项目计 划和SDP评审，依据项目计划（或周计划）,编制《系统测试计划》。 5、 测试组长周期性地根据事业部项目的测试情况，进行总体测试工作量估计 并进行测试任务分派。 6、 测试工程师组织《系统测试计划》评审，测试组长根据评审意见审批《系 统测试计划》。 7、 测试工程师根据《系统测试计划》中的测试环境要求搭建测试环境。特别 技术要求的需要项目组及其它相关职能部门的配合。
二、测试阶段概述
5、系统测试概述 ：
特点： 尽可能使测试的环境与最终目标的环境相同。 当产品需求和系统设计文档完成之后，系统测试小组就可以提 前开始制定测试计划和设计测试用例，而不必等到“实现与测试” 阶段结束。这样可以提高系统测试的效率。 系统测试过程中发现的 所有缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消 除缺陷（改错）。 测试方法： 要验证的功能需求和非功能需求。 非功能包括：健壮性测试、性能测试、用户界面测试 、安全 性 、安装与反安装测试等。 测试用例设计依赖: 风险评估 需求规格说明的
二、测试阶段概述
5、系统测试概述 ： 基本过程： 8、 测试工程师检查测试设计入口条件；根据《用例规约》、《补充 规约》、《界面原型》、《词汇表》进行测试用例设计。 9、 测试工程师组织《系统测试用例》评审，测试组长根据评审意见 审批《系统测试用例》。 10、 测试工程师定义系统测试用例执行过程，并更新《系统测试用 例》。 11、 测试工程师检查测试执行入口条件，从受控库获取测试版本，执 行系统测试并记录 测试结果。 12、 系统测试进入产品稳定期，由测试工程师召开缺陷评审会议；测 试工程师对整个系统测试过程进行总结和评价，形成《软件缺陷清单》、 《系统测试评估摘要》《系统测试总结报告》，并将系统测试过程的文档 报送给项目组和测试组长。测试组长每月初或（事件驱动）汇总、整编上 月的《产品质量简报》，报送给事业部总经理和项目办。 13、 如果根据系统测试结果，产品得以批准通过，系统测试工程师卸 载被测软件，进行环境初始化，系统测试结束，转入验收测试阶段；否则 视批示意见进行。

8
3.1.2 生命周期测试的主要任务
测试准入/准出条件
• 测试准入条件
− 测试合同（或项目计划）； − 软件测试所需的各种文档； − 所提交的被测软件受控； − 软件源代码正确通过编译或汇编； − 最好从一开始就介入到被测软件
的开发周期
• 测试准出条件
− 按要求完成了合同（或项目计划）所 规定的软件测试任务
−这些测试是从项目建议到运营全过程中贯穿应用交付
• HP ALM是一个以任务为导向的系统，可在应用交付过程中支持各参与方，并 与主要开发工具相整合
−该方案实现了团队内和不同团队间的工作流程自动化，强化并加速了应用生命周期管 理和各阶段的测试
54
3.3 HP ALM对生命周期软件测试 的支持
ALM 能够帮助我们组织和管理应用程序生命周期管理过程的所有阶段
一些错误 • 编写必要的培训材料 • 同用户进行接触 • 对有关的人员进行培训
47
工作重点
• 测试 • 培训
3.3 HP ALM对生命周期软件测试的 支持
53
3.3 HP ALM对生命周期软件测试的支持
惠普应用生命周期管理(HP ALM)是业界首款集成的、跨技术和流程、可 拓展的平台
• 使IT人员能够管理应用生命周期，并基于应用生命周期进行测试活动
28
3.2.4 测试阶段
在全生命周期软件测试方法中，由于在需求、设计、编码阶段都进行了测试， 因此测试阶段的问题相对传统的软件测试中的问题要少一些
在测试阶段要进行第三方的正式确认测试，检验所开发的系统是否能按照用户 提出的要求运行
在测试阶段要使得用户能成功地安装一个新的应用系统来进行测试
31
3.2.4 测试阶段
32

一般将项目、结束项目
Page 2
1.软件项目生命周期的概念
对于典型的IT软件项目，项目的生命周期可以从不同 的角度认识。 从项目承担方看：项目是从接到合同正式开始的， 到完成规定工作结束； 从客户的角度看：项目是从确认有需求开始，到 使用项目的成果实现商务目标结束。
系统测试
⑥系统测试：测试系统的各部分是否满足需求。
Page 7
（2）改进的纯瀑布模型--生鱼片模型
“生鱼片模型”，是将模型中的连续的各阶段
软件概念
相互有较大幅度的重叠。
需求分析
例如，在需求分析完成之前可以
初步设计
进行初步设计和详细设计。
详细设计
主要优点：
编码和调试
在项目比较小且定义得很好时，
系统测试
可以有效地减少文档的产生。是
比较有效的模型。
主要缺点：
①因为阶段重叠，里程碑非常不明确，很难精确地进行过程跟踪；
②并行地执行活动可能导致无效的沟通、错误的想法以及低下的效率。
Page 8
（2）改进的纯瀑布模型--具有子系统的瀑布模型
初步设计中将系统分成几个逻辑上相对独立的子系统，每一个子系统都
采用相对独立的
软件概念
①软件概念：用户提出对软件的开发与初步需求； ②需求分析：开发者与用户交流，确定
需求分析
系统的目标、服务与约束；
③初步设计：将用户需求分解
④详细设计：
初步设计
成硬件与软件需求，并建立
将初步设计的整体
系统的整体结构模型；
结构继续分解为可实施
详细设计
编码的小模块，并完成
流程图；
编码和调试
⑤编码和调试：选择合适的计算机语言，完 成详细设计中的各个模块的编码并调试；

件问题报告”和“软件修改报告”
二、软件的维护
• 可维护性：可理解性、可测试性、可修改性 • 改正性维护 • 适应性维护 • 完善性维护 • 预防性维护
三、软件的退役
软件生存周期的几种模型
• 一、瀑布模型 • 二、原型模型 • 三、迭代式模型 • 四、其他几种模型
• 螺旋模型 • 智能模型 • 喷泉模型 • 增量原型
开始 结束
初步需求 分析
快速设计
开发产品
建造原型
对原型加工
用户评估原 型（新需求）
谢谢观赏！
• 运行环境约束：运行环境（硬件、系统平台） 的要求
• 工具：需求规格说明语言、数据流图、数据字 典、状态图
• 通信瓶颈：用户 vs 开发人员 • 分析方法：结构化分析、面向对象分析
• 软件的开发
一、概要设计（总体设计）
• 划分功能模块 • 定义各功能模块的接口 • 设计全局数据结构（数据库） • 制定测试计划 • 设计原则：自顶向下、逐步求精、抽象、模块
•
了解软件开发的全过程 对照目前学习进行比较思考
—张昊哲
1
什么是生命周期？
生命周期（Life Cycle）的概念应用很广泛，特别是 在政治、经济、环境、技术，社会等诸多领域经常出现， 其基本涵义可以通俗地理解为“从摇篮到坟墓”的整个过程。
人的生命周期是什么样的？ 出生、婴儿、儿童、青年、中年、老年.....
进度安排
二、需求分析：
• 解决“做什么(What to do)”，阶段性标志： 软件需求规格说明(Software Requirements
Specification，SRS)
• 既是软件开发依据，也是软件验收标准 • 功能需求：软件必须完成的功能 • 性能需求：安全性、可靠性、可维护性、精度

可行性论证包括经济可行性、技术可行性、操作 可行性、法律可行性等。
需求分析
1) 需求分析的任务
需求分析的任务是确定待开发的软件系统 “做什么，不做什么”。不考虑“怎样做”
具体任务包括确定软件系统的功能需求、性 能需求和运行环境约束，编制软件需求规格 说明书、软件系统的验收测试准则和初步的 用户手册。
检 验 的 模 块 按 照 某 种 选 定 的 策 略 逐 步 进 行 组 装 和 据统计，软件维护人员为了分析和理解原软件系统所花费的工作量约占整个维护工作量的60%以上。
β测试（针对产品软件） 软件设计是对实现软件的结构、系统的数据、系统组件间的接口以及所用的算法进行描述。
测试。 2）单元测试：每编写出一个程序模块的源程序，调试通过后，即对该模块进行测试，这称为单元测试。
维护
✓ 任务: 通过各种维护活动使软件系统持久地满足用
户的需求。
✓ 每项维护活动实质上都是一次压缩和简化了的软
件定义和软件开发过程。都要经历提出维护要求、 分析维护要求、提出维护方案、审批维护方案、 确定维护计划、修改软件设计、修改程序、测试 程序、评审、验收等步骤。
✓ 维护活动一般可以分程四类： v改正性维护
编码与单元测试
2）单元测试：每编写出一个程序模块的源程 序，调试通过后，即对该模块进行测试，这 称为单元测试。
3）实现阶段的成果：
✓ 按一定规则存储在一定载体上的通过
单元测试的各功能模块的集合；
✓ 详细的单元测试报告等文档。
测试
▪ 测试阶段解决的主要问题是“通过怎样的测
试（及相应的调试），使软件系统达到用户 的预期要求。”
需求分析
2）需求分析的实现途径
软件系统需求一般由用户提出。系统分析员和开 发人员在需求分析阶段必须与用户反复讨论、协 商，充分交流信息，并用某种方法和工具构建软 件系统的逻辑模型。为了使开发方与用户对待开 发软件系统达成一致的理解，必须建立相应的需 求文档。有时对大型、复杂的软件系统的主要功 能、接口、人机界面等还要进行模拟或建造原型， 以便向用户和开发方展示待开发软件系统的主要 特征。确定软件需求的过程有时需要反复多次， 最终得到用户和开发者的确认。

分析和设计；
在开发生命周期中，测试人员在文档初稿阶段就应该参与文档的评 审；
THANKS
需求分析 设计 编码 测试 交付1
需求分析 设计 编码 测试 交付2
需求分析 设计 编码 测试 交付3
4. 迭代-增量开发模型
快速应用开发（RAD）
第二章 软件生命周期中的测试
统一软件开发过程（RUP）
Validation (确认) : You do the right thing.
统一螺软件旋开模发过型程：（R以UP原） 型为基础 而功确能沿认 驱测动螺试开线的发内F旋D容D转（随F着e、a测tu每r试e-级D转r别iv一e的n D不圈e断ve都提lop高m而en增t）加；
实际上每个测试都包括确认测试和验证测试这两个方面。而确认 测试的内容随着测试级别的不断提高而增加
4. 迭代-增量开发模型
迭代-增量模型是先构造基本的系统，然后经过接下来的开发对系统不 断细化，精炼，使系统越来越完善。
常见的模型： 原型模型 增量模型 螺旋模型 快速应用开发（RAD） 统一软件开发过程（RUP） 敏捷开发
第二章 软件生命周期中的测试
—— 软件开发模型
主讲人：丁慧
1.软件开发和测试的关系 2.瀑布模型 3.V模型 4.迭代-增量开发模型 5.生命周期模型中的测试
1. 软件开发和测试的关系
开发： 分析 设计
实现
测试： 尽早开始测试 测试计划 测试设计 测试实现
运行： 交付
运行
不同的开发生命周期模型需要对应不同的测试阶段、测试活动和测试方法
4. 迭代-增量开发模型
原型模型：
在形成一组基本需求之后，通过快速分析方法构造出待建的原型版本， 然后根据顾客在使用原型的过程中提出的意见对原型进行修改，从而得到原 型的更新版本，这一过程重复进行，直至得到满足顾客需求的系统。

效地,可控地计划安排,确保实现项目地既定目标; 执行过程——协调人力与其它资源,并执行计划; 控制过程——通过监督与检测过程确保项目目标地实现,必要时
采取一些纠正措施; 收尾过程——取得项目或阶段地正式认可,并且有序地结束该项
目或阶段。 软件项目管理涉与9个知识领域：包含整体管理,范围管理,时
软件测试
（二）软件测试Biblioteka 型本章要点 软件开发地基本过程与其内容 软件测试基本流程
软件开发地基本过程
无论软件开发过程地组织形式如何变化, 软件开发所包含地核心工作并没有改变, 仍然是需求分析,设计,编码与测试,此 外还有为了保证开发过程顺利实施地软 件项目管理,配置管理,质量保证,验证 与确认支持活动。合理计划并执行这些 活动,才能保障软件开发地成功。
The End
MSF过程模型
2000年微软公司在其解决方案框架 （MSF）中提出了自己地应用开发过程 模型。该模型综合了瀑布模型与螺旋模 型地优点。
敏捷开发过程模型
敏捷开发是一种以人为核心,迭代,循序渐 进地开发方法。在敏捷开发中,软件项目 地构建被切分成多个子项目,各个子项目 地成果都通过测试,具备集成与可运行地 特征。换言之,就是把一个大项目分为多 个相互联系,但也可独立运行地小项目,并 分别完成,在此过程中软件一直处于可使 用状态。
上程序内部结构地复杂性,要彻底地测试一个 程序是不可能地。我们只能执行有限个测试用 例,并求尽可能多地发现一些错误。能尽可能 多地发现错误地测试用例被称为“高产地”。
软件测试地组织
独立测试组（IndependentTest Group,ITG）地作用是为了避免开发人 员进行测试所引发地固有问题,独立测 试可以消除利益冲突。

ISTQB Training - FL
9
/ 11 October 2010 / HP-EDS INTERNAL
练习
场景 软件需求较稳定，软件开发团队计划用三个月的时间进行需求 分析、四个月的时间进行系统设计、四个月的时间进行编码， 所有活动将采用阶段式完成方式进行 软件需求信息不足，项目组计划采取先设计部分原型系统，以 便与客户进行交流来确认下一步的开发需求与系统改进 由于项目规模较大，开发过程中，项目组希望开发组进行多次 发布，并进行已完成模块的集成，从而验证系统进展情况，以 便做出适当的调整 可采用的测试模型
软件生命周期中的测试
11 October 2010
ISTQB Tber 2010 / HP-EDS INTERNAL
课程目标
完成本章节后，你将掌握如下知识：
认识到典型的软件开发模型，了解针对典型软件开发模型的各个阶段所对应的软件测 试，以及四种软件测试模型
ISTQB Training - FL
15
/ 11 October 2010 / HP-EDS INTERNAL
集成测试
• 定义
– 集成测试(Integration Testing)是对组件之间的接口进行测试，以及测试一个系统内不同部分的相互 作用，比如操作系统、文件系统、硬件或系统之间的接口。根据集成的粒度可分为，组件集成 （Component Integration）、系统集成（System Integration）
– 优点:容易集成，不需要额外的驱动模块(Drivers) – 缺点:底层模块要到最后才能被集成
• 自下而上（Bottom-Up Integration） – 定义:The test starts with the elementary system components that do not call further components, except for functions of the operating system. Larger subsystems are assembled from the tested components and then these integrated parts are tested.