第2章 软件测试模型

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
优点:思路简单, 通常可能是开发者的“突发奇想” 缺点:开发过程是非工程化的,随意性大 关于测试:有的较简单,有的则非常困难
2、边写边改法
采用边写边改法的软件开发通常只是有了比较粗略 的想法就开始进行简单的设计、然后进行较长的反 复编写、测试与修复这样一个循环的过程。在认为 无法更精细的描述软件产品要求时,就发布产品。
标准软件测试过程
基本特性:
(1)计划性: 任务 人员 设备 时间 相关... (2)平行性: 开发 编码 || 测试 再测试 (3)完整性: 计划 大纲 用例 ... (4)重用性: 测试 再测试 回归测试 升级 多平台… (5)可重复性: 用例 大纲 再现Bugs (6)周期性:测试周期 回归 更新 (7)可管理性: 测试组织 完整的计划 良好的准备工作
2.4 软件测试过程模型
V模型
在V模型中,描述了一些不同的测试级别,并说明了 这些级别所对应的生命周期中不同的阶段,清楚地 描述了这些测试阶段和开发过程期间的对应关系。
用户
软件产品
需 求 分 评审 析
需求获取 需求定义 需求分析
评审 需求分析书
概要设计
可交付软件 评审 系统测试 已确认软件 评审 确认测试
如图6,首先对每一个程序模块进行单元测试,消除 程序模块内部在逻辑上和功能上的错误和缺陷。再 对照软件设计进行集成测试,检测和排除子系统 (或系统)结构上的错误。随后再对照需求,进行 确认测试。最后从系统全体出发,运行系统,看是 否满足要求。
2、软件测试与开发的并行关系
需求评审
详细设计
编码
单元测试
评审 概要设计书
已集成软件 评审
必详需细在设计编码工作结束后集才成测能试 进行测试!
评审 详细设计书
已测试模块 评审
编码
单元测试
程序
图8 V模型示意图
测试W模型
◦ 由于各种原因,开发的每一个环节都可能产生错 误,如果坚持各个阶段的技术评审,就能够尽早发 现和预防错误。
◦ 图9为软件开发与测试的W 模型,形象地说明了软
◦ 3、软件测试要尽早准备, 尽早执行。 ◦ 4、软件测试根据被测物的不同是分层次的. 不同
层次的测试活动可以是按照某个次序先后进行的, 但也可能是反复的。
测试准备
测试就绪点
测试执行
测试流程
其他流程
图10 H模型示意图
软件测试的完整模型
项目规划
产品发布
项目需求分析 项目概要分析 项目详细分析
测试需求分析 系统测试计划 集成测试计划 单元测试计划
5、RUP
RUP即Rational统一过程模型,是一种强 调迭代开发、持续集成的软件开发过程 模型。
RUP流程图
图4 RUP模型
初始阶段(inception):目标是为系统建立商业 案例和确定项目的边界。
细化阶段(elaboration):目标是分析问题领域 ,建立健全的体系结构基础,编制项目计划 ,淘汰项目中最高风险的元素。
◦ 不成熟的开发组织将产生一个非产品化、 混乱的、屡受搓折的环境中产生低质量的 不另人满意的结果
成熟组织中的测试过程
测试有自己的周期,和开发生命周期并 行
在一个成熟的开发组织中,测试组可以 并能够集中精力在内部流程改进上
测试流程的有效改革将会成为促进不成 熟组织改进开发流程的催化剂
软件测试流程的质量决定测试是否成功
ISTQB定义的软件测试过程模型
Preparation Specification Execution Completion
P
S
P&C
Plan & Control
E
C
测试阶段
软件测试过程可被分成五个阶段:
The planning and control phase-计划和控制阶段 The preparation phase-准备阶段 The specification phase-规范阶段 The execution phase-测试执行阶段 The completion phase-完成阶段
允许个人根据自身情况适当调整工作 为组织提供了一个一致的工作框架
2.2 软件开发模型
1、大棒开发法
源于能量爆发创造宇宙,万物都由能量和物质积聚 而成的理论,但如果不是遵循某种正确的排列和组 合,形成的将不是预先期望的事物。大棒模式与上 述理论一样:一大堆能量(这里指开发软件所需的 人力和物力)放在一起,巨大的能量进行释放,通 常的结果可能是产生了优秀的软件产品或成为一堆 “废品”(不成功的软件)。
2.3 软件开发与测试的关系
软件测试的生命周期 测试与开发各阶段的关系 软件开发与测试模型
软件测试的生命周期
软件测试的生命周期(software testing life cycle)分为几个阶段(如图5所 示 )。
◦ 前三个阶段就是引入程序错误阶段; ◦ 后三个阶段就是清除程序错误的阶段。
优点:
◦ 可以在项目前期考虑对已经存在的软件进行重用; ◦ 在软件产品开发过程中考虑了软件质量目标; ◦ 关注于缺陷预防,并能够尽早发现缺陷; ◦ 更好地控制项目活动的资源和相关成本。
缺点:
◦ 过分依赖风险评估; ◦ 过于灵活的开发过程不适合开发者与客户之间有
明确的合同约定; ◦ 模型本身的文档化和推广需要较大工作量。
需求规格说明
引 入
设计
错 误
编码
在软件测试生命周期的每个阶段都要完成
一些确定的任务:
1. 在执行每个阶段的任务时,可以采用行之 有效的结构分析设计技术和适当的辅助工具;
2. 在结束每个阶段的任务时,都进行严格的技 术审查和管理复审。
3. 最后提交最终软件配置的一个或几个成分 (文档或程序)。
测试
缺陷分类
增量迭代模型
螺旋模型 RUP 敏捷开发
4、螺旋模式法
螺旋模式是瀑布模式与边写边改演化模式相结合, 并加入风险评估所建立的软件开发模式。
每一螺旋(开发阶段)包括5个步骤:①确定目标, 选择方案和限制条件。 ②对方案风险进行评估,并 能解决风险。 ③进行本阶段的开发和测试。 ④计 划下一阶段。 ⑤确定进入下阶段的方法。
第2章 测试过程
2.1 如何定义过程?
过程是指为了达到给定目的而执行的实践的集 合;它可能包括工具、方法、资料和/或人。
过程是指为了达到给定目的而执行的一系列活 动的有序集。
软件过程是指软件产品或软件系统从产 生、投入使用到被淘汰的全过程。
需求:包括问题分析和需求分析; 设计:包括概要设计和详细设计; 实现:把设计结果转换为可执行的程序代码; 测试:包括单元测试、集成测试和确认测试; 维护:是对投入运行的软件进行修改,使软件系统
即使到了开发后期,也允许需求变更; 交付时间越短越好 开发人员和业务人员协同工作; 围绕个人构建项目; 提倡面对面交谈; 能够工作的软件是首要的进度度量标准; 提倡可持续的开发速度; 简单是根本; 不断关注优秀的技能和好的设计 最好的构架、需求和设计出自于自组织的团队; 每隔一定时间就进行工作总结和调整。
编码阶段:由开发人员进行自己负责部分的测试代 码。在项目较大时,由专人进行编码阶段的测试任 务。
测试阶段(单元、集成、系统测试):依据测试代 码进行测试,并提交相应的测试状态报告和测试结 束报告。
2.5 测试组织中的测试过程
不成熟组织ቤተ መጻሕፍቲ ባይዱ的测试过程
◦ 测试没有自己的周期,和开发生命周期串 行
◦ 测试组和一个不成熟的开发组织一起工作 ,将感到非常痛苦
能适应外界环境变化、实现功能扩充和质量改善。
为什么要定义软件过程?
有助于以一种有序的方式选择过程 了解工作目标和内容,明确每个任务完成标

◦ 借助已经建立的过程定义,软件专业人员能够更 好地理解自身应该完成什么工作,了解可以指望 合作人员做什么,明确自己应为合作人员提供什 么。这样,软件专业人员就可以将精力放在完成 自己份内的工作上。
构建阶段(construction):目标是将所有涉及 的构件和应用程序功能被开发并集成为产品 ,并详尽测试所有的功能。
产品化阶段(transition):目标是将软件产品交 付给用户群体。
1
迭代式开发
2
管理需求
3
基于组件的体系结构
4
可视化建模
5
验证软件质量
6
控制软件变更
6 、敏捷开发
最优先要做的是通过尽早地、持续地交付有价值的软件来使客 户满意;
优点:易于理解;调研开发的阶段性;强调早期计 划及需求调查;确定何时能够交付产品及何时进行 评审与测试。
缺点:需求调查分析只进行一次,不能适应需求变 化;顺序的开发流程,使得开发中的经验教训不能 反馈到该项目的开发中去;不能反映出软件开发过 程的反复与迭代性;没有包含任何类型的风险评估; 开发中出现的问题直到开发后期才能够显露,因此 失去及早纠正的机会。
系统测试 集成测试 单元测试
代码编写
测试代码编写
图11 软件测试与开发的完整模型
测试在开发阶段的作用:
项目规划阶段:负责从单元测试到系统测试的整个 测试阶段的监控。
需求分析阶段:确定测试需求分析、系统测试计划 的制定,评审后成为管理项目。
详细设计和概要设计阶段:确保集成测试计划和单 元测试计划完成。
概要设计评审
设计走查
编码走查
需求分析
概要设计
*
*
*
……
*
*
…… 各子模块
*
*
*
有效性测试
集成测试
* 项目阶段任务的里程碑
*
测试计划 测试过程 测试评审
图7 软件测试与软件开发的并行性
在软件的需求得到确认并通过评审后, 概要设计工作和测试计划制定设计工作 就要并行进行。如果系统模块已经建立, 对各个模块的详细设计、编码、单元测 试等工作又可并行。待每个模块完成后, 可以进行集成测试、系统测试。并行流 程如图7所示。
缺陷分离
缺陷排除
修复
修复错误
图5 软件测试生命周期
软件测试与开发的关系
1、软件测试与开发的顺序关系
软 需求规格说明 件
开 设计



编码
软 确认测试 件 测
集成测试
试 过 程 单元测试
图6 软件测试与开发的顺序关系
软件开发过程是一个自顶向下,逐步细化的过程, 首先在软件计划阶段定义了软件的作用域,然后进 行软件需求分析,建立软件的数据域、功能和性能 需求、约束和一些有效性准则。接着进入软件开发, 首先是软件设计,然后再把设计用某种程序设计语 言转换成程序代码。而测试过程则是依相反的顺序 安排的自底向上,逐步集成的过程,低一级测试为 上一级测试准备条件。此外还有两者平行地进行测 试。
缺点:
◦ 为串行结构,需等上一阶段活动结束后才 能开展下一活动。
测试H模型
与前两种模型相比,H模型充分地体现了测 试过程。如图10所示的H 模型揭示了:
◦ 1、软件测试不仅仅指测试的执行, 还包括很多其 他的活动。
◦ 2、软件测试是一个独立的流程, 贯穿产品的整个 开发周期, 与其它流程并发进行。
优点:能够较为迅速的展现成果,适合需要快速制 作而且用完就扔的小项目,如示范程序、演示程序 等。
缺点:其编码和测试可能将是长期的循环往复的过 程。
一个软件生命周期包括:制定计划、 需求分析、软件设计、程序编码、软 件测试、软件运行、软件维护、软件 停用等8个阶段。
3、瀑布法
瀑布模式是将软件生命周期 的各项活动,规定为按 照固定顺序相连的若干个阶段性工作,形如瀑布流 水,最终得到软件产品。
计划与控制阶段
它是整个测试过程中最重要的阶段,为实现可管理 且高质量的测试过程提供基础 。
本阶段的主要工作内容: (1)拟定测试计划 (2)论证那些使开发过程难于管理和控制的因素 (3)明确软件产品的最重要部分 (风险评估)
准备阶段
开始本阶段的前提条件: —完成测试计划的拟定。 —需求规格说明书(第一版)的确定。
件测试与开发的这种同步性。
需求分析 需求测试
安装
验收测试
概要设计 测试设计
构建系统
系统测试
每个开发活动后都可以执行
详细设计相应测的试明规测格说试! 构建软件
集成测试
编码
单元测试
图9 W模型示意图
优点:
◦ 测试贯穿于整个软件开发生命周期; ◦ 测试对象不仅仅是程序,还包括需求和设
计规格说明等; ◦ 测试与开发同步; ◦ 可以尽早、全面发现问题。
本阶段的主要工作内容: —对需求规格说明书的仔细研究。 —将要测试的产品分解成可独立测试的单元。 —为每个测试单元确定采用的测试技术。 —为测试的下一个阶段及其活动制定计划。
规范阶段
本阶段的主要工作内容: —编写测试大纲/测试用例,测试脚本 —搭建测试环境 (测试数据库,软件环境,硬件环境)
相关文档
最新文档