第五章 软件测试过程

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
际测试结果之间的差异 (2)填写软件问题报告 (3)确定造成这些差异的原因:
产品有缺陷?规格说明书有缺陷? 测试环境和测试下属部件有缺陷?测试用例设计不合理? 测试报告——与管理层进行沟通的方式 已测试部分占产品多大的百分比?还有什么工作要做? 找到了多少个问题或不足?测试的发展趋势如何? 测试可以结束了吗? 样例:SCM测试报告1,测试报告2,测试报告3
完成阶段
本阶段的主要工作内容: —选择和保留测试大纲、测试用例、测试结果、测试工具。 —提交最终报告。 收尾工作的意义和重要性: —产品如果升级或功能变更,或维护,只要对保留下来的 相关
测试数只要作相应调整,就能够进行新的测试。
样例:测试报告—合格品报告
5.2 单元测试
7.2.1 单元测试的主要任务 7.2.2 单元测试的执行过程
其他集成策略(3)
分层集成:对于类似通信系统中,可以把系统按照功能划分为不同 功能层次的子系统(例如:MVC等N层架构或中间件、DLL等), 可以采用分层集成。
分层集成的策略就是: (1)划分系统的层次; (2)划分层次内部的集成策略:一般对顶层和第二层内部采用自顶
向下的集成策略;对中间层采用自底向上的集成策略;对底层采用 单独测试。 (3)层次间的集成可以采用自顶向下、自底向上、大爆炸或三明治 集成中的任何一种。
A
B
C
集成测试内容
集成测试主要考虑以下内容: 在把各个模块连接起来时,穿越模块接口的数据是否会丢失? 各个子功能组合起来,能否达到预期要求的父功能。 一个模块的功能功能是否会对另一个模块的功能产生不利影响。 全局数据结构是否有问题,会不会被异常修改? 单个模块的误差积累起来,是否会放大,从而达到不可接受的程度?
集成测试策略
5.3.1 大爆炸集成 (非增量式) 5.3.2 自顶向下集成 5.3.3 自底向上集成 5.3.4 三明治集成 5.3.5 修改的三明治集成 5.3.6 基干集成 5.3.7 分成集成
5.3.8 基于功能的集成 5.3.9 高频集成 5.3.10 基于进度的集成 5.3.11 基于风险的集成 5.3.12 基于事件(消息)的集成 5.3.13 基于使用的集成
实例 按照广度优先方式进行集成测试
实例 按照深度优先方式进行集成测试
自底向上增量式测试
自底向上增量式测试表示逐步集成和逐步测试的工作是按结构图自 下而上进行的,即从程序模块结构的最底层模块开始集成和测试。
由于是从最底层开始集成,对于一个给定层次的模块,它的子模块 (包括子模块的所有下属模块)已经集成并测试完成,所以不再需 要使用桩模块进行辅助测试。在模块的测试过程中需要从子模块得 到的信息可以直接运行子模块得到。 实例 采用自底向上增量式测试方法进行集成测试
7.3.1 大爆炸集成测试
大爆炸集成测试是采用一步到位的方法来构造测试,也叫非增量式测试: ——对所有模块进行个别的单元测试后,按照程序结构图将各模块连接 起来,把连接后的程序当作一个整体进行测试。 实例 采用非增量式测试方法进行集成测试
非增量式测试的缺点: ——当一次集成的模块较多时,非增量式测试容易出现混乱,因为测试 时可能发现了许多故障,为每一个故障定位和纠正非常困难,并且在修 正一个故障的同时,可能又引入了新的故障,新旧故障混杂,很难判定 出错的具体原因和位置。
集成测试:对已测试过的模块进行组装,进行集成测试。目的在于 检验与软件设计相关的程序结构问题。
确认(有效性)测试:是检验所开发的软件能否满足所有功能和性 能需求的最后手段。
系统测试:检验软件产品能否与系统的其他部分(比如,硬件、数 据库及操作人员)协调工作。
验收(用户)测试:检验软件产品质量的最后一道工序。主要突出 用户的作用,同时软件开发人员也应有一定程度的参与。
planned and prepared task
测试阶段
测试过程的三个主要的测试活动(计划、准备和实施) 可被 分成五个阶段: The planning and control phase-计划和控制阶段 The preparation phase-准备阶段 The specification phase-规范阶段 The execution phase-实施执行阶段 The completion phase-完成(收尾)阶段
5.3.2 增量式测试
增量式测试的集成是逐步实现的: ——逐次将未曾集成测试的模块和已经集成测试的模块(或子 系统)结合成程序包,再将这些模块集成为较大系统,在集成 的过程中边连接边测试,以发现连接过程中产生的问题。
按照不同的实施次序,增量式集成测试又可以分为三种不同的 方法: (1)自顶向下增量式测试 (2)自底向上增量式测试 (3)混合增量式测试
一个实用软件测试过程
一种简单实用的软件测试过程模型 POCERM。 测试过程中必需的基本测试活动及其产生的结果: 拟定软件测试计划 (Plans) 编制软件测试大纲 (Outlines) 设计和生成测试用例 (test Case generation) 实施测试 (Execution) 生成软件测试报告 (software testing Reports)
本阶段的主要工作内容: —编写测试大纲/测试用例,测试脚本 —搭建测试环境 (测试数据库,软件环境,硬件环境)
测试用例描述的内容: —输入 —执行过程 —预期输出 样例:SCM测试用例设计
实施执行阶段
根据测试大纲/测试用例/测试脚本进行测试 (1)根据测试大纲/测试用例进行测试,找出预期的测试结果和实
测试的五个阶段
Preparation Specification
Execution
Completion
P
S
P&C
E
C
Plan & Control
计划与控制阶段
它是整个测试过程中最重要的阶段,为实现可管理且高质量 的测试过程提供基础 。
本阶段的主要工作内容: (1)拟定测试计划 (2)论证那些使开发过程难于管理和控制的因素 (3)明确软件产品的最重要部分 (风险评估)
驱动模块和桩模块都是额外的开销,虽然在单元测试中必须编写, 但并不需要作为最终的产品提供给用户。
单元测试的执行过程(续)
被测模块、驱动模块和桩模块共同构成了一个如下图所示的单元 测试的测试环境:
驱动模块
测试结果
测试用例
被测模块
桩模块1
桩模块2
桩模块3
桩模块… 桩模块n
5.3 集成测试
ห้องสมุดไป่ตู้
集成测试:也叫组装测试、联合测试、子系统测试或 部件测试。是在单元测试的基础上,将所有模块按照 概要设计要求(如类结构图或功能结构图等)组装成 子系统或系统。
混合增量式测试
混合增量式测试是把自顶向下测试和自底向上测试这两种方式结合起来 进行集成和测试。这样可以兼具两者的优点,而摒弃其缺点。
常见的三种混合增量式测试方式: (1)衍变的自顶向下的增量式测试:基本思想是强化对输入/输出模块和
引入新算法模块的测试,并自底向上集成为功能相对完整且相对独立的 子系统,然后由主模块开始自顶向下进行增量式测试。 (2)自底向上-自顶向下的增量式测试:首先对含读操作的子系统自底向 上直至根节点模块进行集成和测试,然后对含写操作的子系统做自顶向 下的集成与测试。 (3)三明治增量式测试:把系统分为3层,中间一层为目标层。测试的时 候,对目标层上面的一层使用自顶向下的集成策略,对目标层下面的一 层使用时用自顶向上的集成策略,最后在目标层进行会合。
广度优先方式的集成: ——首先沿着水平方向,把每一层中所有直接隶属于上一层的模 块集成起来,直到底层。
自顶向下增量式测试(续)
集成测试的整个过程由3个步骤完成: (1)主控模块作为测试驱动器。 (2)根据集成的方式(深度或广度),下层的桩模块一次一次地被 替换为真正的模块。 (3)在每个模块被集成时,都必须进行单元测试。 重复第2步,直到整个系统被测试完成。
自顶向下增量式测试
自顶向下增量式测试表示逐步集成和逐步测试是按照结构图自上 而下进行的,即模块集成的顺序是首先集成主控模块(主程序), 然后依照控制层次结构向下进行集成。从属于主控模块的按深度 优先方式(纵向)或者广度优先方式(横向)集成到结构中去。
深度优先方式的集成: ——首先集成在结构中的一个主控路径下的所有模块,主控路径 的选择是任意的。
高频集成:在迭代式开发中,最初只是一个最低功能限度的集成, 然后新代码加入,按照固定的频率(例如按每隔多少天,或模块增 加)进行增量测试。高频集成要求:测试包和代码并行开发;始终 维护是最新版本,必须使用配置管理工具。
其他集成策略(2)
基干集成:在很多系统中,尤其是嵌入式系统中,一般分为2部分: 内核部分(基干)和外部应用部分。这两部分通常是不同的人开发。
基干集成的策略就是: (1)对基干中的每个模块进行单独、充分的测试,必要时用驱动和
桩; (2)对基干中所有的模块进行大爆炸集成; (3)对应用控制子系统进行自顶向下集成; (4)把基干和控制子系统进行集成,重新构造子系统; (5)对应用部分采用自底向上集成策略。
其他集成策略(4)
基于功能的集成:按照功能角度,按照功能的关键程 度对模块的集成顺序进行组织,有利于提高团队士气。
基于功能的集成的策略就是: (1)确定功能的优先级别; (2)分析优先级最高的功能路径,把该路径上的所有
模块集成到一起,必要时使用驱动和桩。 (3)增加关键路径,重复集成。
其他集成策略(4)
在单元测试时,如果模块不是独立的程序,需要设置一些辅助测 试模块。辅助测试模块有两种:
(1)驱动模块(Drive) 用来模拟被测试模块的上一级模块,相当于被 测模块的主程序。它接收数据,将相关数据传送给被测模块,启 动被测模块,并打印出相应的结果。
(2)桩模块(Stub) 用来模拟被测模块工作过程中所调用的模块。它 们一般只进行很少的数据处理。
7.2.1 单元测试的主要任务
单元测试针对每个程序的模块,主要测试5个方面的问题: ——模块接口、局部数据结构、边界条件、独立的路径和错误处理。
出错处理
模块接口
局部数据结构
边界条件
模块
路径测试
7.2.2 单元测试的执行过程
何时进行单元测试?单元测试常常是和代码编写工作同时进行的, 在完成了程序编写、复查和语法正确性验证后,就应进行单元测 试用例设计。
软件问题报告SPR (Software Problem Report) 测试结果报告 (test result Reports)
一个实用软件测试过程(续)
基本特性: (1)计划性: 任务 人员 设备 时间 相关... (2)平行性: 开发 编码 || 测试 再测试 (3)完整性: 计划+大纲+用例+SPRs+... (4)重用性: 测试 再测试 回归测试 升级 多平台… (5)可重复性: SPRs 用例 大纲 再现Bugs (6)周期性: test cycles, regression, update (7)可管理性: well structured and organized QE group + well
第五章 软件测试过程
5.1 软件测试的过程 5.2 单元测试 5.3 集成测试 5.4 确认测试 5.5 系统测试 5.6 验收测试 5.7 测试后的调试
本章教学目标
理解软件测试的过程 明确单元测试的主要任务和过程 明确集成测试的方法和确认测试的准则 明确系统测试的八个领域测试要点 明确验收测试的主要内容和相关配置
5.1 软件测试过程
被测模块 单元 测试 …
被测模块 单元 测试 …
被测模块 单元 测试
设计信息
集成 测试
集成 测试
单元 软件需求
其它元素
用户信息 其它元素
确认 测试
*
系统 测试
*
验收 交付用户 测试
*
* 这三个测试可能交叉与前后互换
图2-2 软件测试的过程流程
软件测试过程(续)
单元测试:针对每个单元的测试, 以确保每个模块能正常工作为 目标。
样例:SCM测试计划
准备阶段
开始本阶段的前提条件: —完成测试计划的拟定。 —需求规格说明书(第一版)的确定。
本阶段的主要工作内容: —对需求规格说明书的仔细研究。 —将要测试的产品分解成可独立测试的单元。 —为每个测试单元确定采用的测试技术。 —为测试的下一个阶段及其活动制定计划。
规范阶段
相关文档
最新文档