集成测试讲解
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第三章 集成测试
3.1基本概念 3.2集成测试目的 3.3集成测试层次 3.4集成测试方法 3.5集成静态测试 3.6集成策略 3.7集成测试流程 3.8案例分析
1
3.1基本概念
定义
集成测试又称组装测试、联合测试、子系统测 试或部件测试。集成测试是在单元测试的基础 上，将所有模块按照设计要求（如根据结构图） 组装成子系统或系统进行的测试活动。 单元测试完成后便进入集成测试阶段。
集成测试的依据是需求规格说明书、概要 设计及详细设计说明书。
9
3.5集成静态测试
测试内容
主要测试概要设计同需求的一致性，以及概要 设计的合理性。
测试方法
采用同行评审的形式是审查或小组评审
ቤተ መጻሕፍቲ ባይዱ
概要设计是将软件需求转换为软件的系统 体系结构、程序界面和数据结构的过程， 及开发语言和工具的选择。因此概要设计 的测试主要从这几个方面进行。
测试A
S4
加入B
S4
加入C
A
A
A
B
C
D
B
C
D
B
C
D
S4
S5
E
S5
E
F 22
加入D
加入E
加入F
自顶向下（Top Down Testing）
步骤：
对主控模块进行测试，测试时用存根程序代替所有直 接附属于主控模块的模块 根据选定的结合策略（深度优先或宽度优先），每次 用一个实际模块代替一个存根程序（新结合进来的模 块往往又需要新的存根程序） 在结合下一个模块的同时进行测试 为了保证加入模块没有引进新的错误，可能需要进行 回归测试（即，全部或部分地重复以前做过的测试） 从第2步开始不断地重复进行上述过程，直至完成。
10
3.5.1系统体系结构设计测试
体系结构的“4+1”视图描述 用例视图 :用例视图定义系统的外部行为，是最终用户、分 析人员和测试人员所关注的。用例视图定义了系统的功能， 是描述系统设计和构建的其它视图的基础，即用例驱动。 逻辑视图 :逻辑视图描述逻辑结构，该逻辑结构支持用例视 图描述的功能，它描述了问题空间中的概念以及实现系统 功能的机制，如类（抽象类）、包、子系统等，因而是编 程人员最关心的。 实现视图 :实现描述用于组建系统的物理组件，如可执行文 件、DLL、.java文件、.cpp文件代码和数据库等系统程序 员所看到的软件产物，是和配置管理以及系统集成相关的 信息。 进程视图 :进程视图描述将系统分解为过程和任务，以及这 些并发元素之间的通信与同步。 部署视图 :描述系统的物理网络布局及程序分布，是系统工 程师和网络工程师所感兴趣的。 11
4
3.2集成测试目的
在把各个模块连接起来的时侯，穿越模块接口的数据是否 会丢失； 一个模块的功能是否会对另一个模块的功能产生不利的影 响； 各个子功能组合起来，能否达到预期要求的父功能； 全局数据结构是否有问题； 单个模块的误差累积起来，是否会放大，从而达到不能接 受的程度。 在单元测试的同时可进行集成测试，发现并排除在模块连 接中可能出现的问题，最终构成要求的软件系统。
3.5.2数据结构设计测试
数据结构设计确定软件涉及的文件系统的结构以 及数据库的模式、子模式，进行数据完整性和安 全性的设计。它包括：
确定输入、输出文件的详细的数据结构； 结合算法设计，确定算法所必须的逻辑数据结构及操 作； 内部模块之间的接口数据格式设计 数据库设计合理性。具体数据库设计合理性见数据库 相关专业书籍。
5
3.3集成测试的层次
子系统内集成测试(模块) 子系统间集成测试 (可执行程序)
6
3.3集成测试的层次
模块与子系统的区别 例子
配用电监测与管理系统由很多个子系统组成， 如通讯子系统、数据采集子系统、报警服务子 系统、前置机应用子系统等。 而每个子系统又由多个功能模块组成，如数据 采集子系统由档案参数模块、任务处理模块、 规约解析模块等组成
17
3.6.2增值式策略
这种集成方式又称渐增式组装。首先对一个个模 块进行模块测试，然后将这些模块逐步组装成较 大的系统，在组装的过程中边连接边测试，以发 现连接过程中产生的问题。通过增值逐步组装成 为要求的软件系统。 相对非增值式策略，可以较早发现模块间的接口 错误；发现问题也易于定位。它的缺点是测试周 期比较长，可以同时投入的人力物力受限。
32
3.7.1制定集成测试计划
集成测试计划的内容有：
确定集成测试对象和测试范围； 确定集成测试阶段性时间进度； 确定测试角色和分工； 考虑外部技术支援的力度和深度，以及相关培 训安排； 初步考虑测试环境和所需资源； 集成测试活动风险分析和应对； 定义测试完成标准；
33
3.7.2集成测试分析和设计
20
自顶向下（Top Down Testing） —深度优先
A A A S1 S2 S3 B S2 S3 B S2 S3
测试A
S4
加入B
E
加入E
A
A
A
B
C
S3
B
C
D
B
C
D
E
S5
E
S5
E
F
加入C
加入D
加入F
21
自顶向下（Top Down Testing） —宽度优先
A A A
S1 S2 S3 B S2 S3 B C S3
首先单独测试每一层。对于顶层而言，需要构造桩；对于底层， 需要构造驱动；对于中间层，需要构造驱动和桩。 执行层次的自顶向下集成。结果测试包/驱动器应该被设计为可复 用/可重运行于随后的集成。 在接下来的一层中使用自顶向下的方法。去掉第二层的桩并实现 接口。扩充控制测试包以达到所有新实现的构件再运行测试。 每层的接口通过以后，去掉所有桩并实现到下一层的接口。
7
3.3集成测试的层次
TCP通讯模块 规约过滤模块 档案参数 模块 任务处理模块 规约解析模块 通讯日志, 文件输出
数据库输出模块 数据库接口
8
3.4集成测试方法
静态测试
概要设计的测试
动态测试
黑盒测试 ，但有时候需了解内部细节并结合白 盒测试，所以更多的资料将黑盒和白盒相结合 的测试称为灰盒测试 。
29
3.6.6分层集成策略
分层模型在通信系统中是很常见的。分层集成就是针对这 个特点使用的一种集成策略。系统的层次划分可以通过逻 辑的或物理的手段进行。在逻辑上，一般通过功能把系统 划分成不同层次的功能单元，功能单元内部具有较高的耦 合性，相互之间的关系具有线性层次关系。 层次集成可能是自顶向下或自底向上的。一个自顶向下的 方法采用下列步骤：
26
3.6.3混合增值式策略
对软件结构中较上层，使用的是“自顶向 下”法；对软件结构中较下层，使用的是 “自底向上”法，两者相结合
27
3.6.4基于事件（消息）集成策略
从验证消息路径的正确性出发，渐增式把系统集成在一起， 从而验证系统的稳定性。，面向对象系统中，每个功能路 径对应于一系列事件，可以将对应于系统的一个输入或者 是事件所需要的类集成到一起，然后分别进行测试。 测试的步骤如下： 从系统的外部看，分析系统可能输入消息集。 选取一条消息，根据序列图或协作图中的事件交互关 系，将相关类集成在一起进行测试。 选取下一条消息，根据序列图或协作图中的事件交互 关系，将相关类集成在一起进行测试。直到所有类都 被集成到系统中。 主要测试依据是序列图或协作图
30
3.7集成测试流程
集成测试计 划 软件体系结 构初步分 析 关键特性分 析 工作量估计 集成测试分 析与设计 集成测试对 象分析 集成策略选 择 集成测试工 具选择和 设计 集成测试代 码设计 集成测试用 例设计
31
集成测试实 现 集成测试工 具开发 集成测试代 码开发 集成测试用 例开发
集成测试执 行 建立集成测 试环境 执行集成测 试 测试结果记 录
14
概要设计检查单
例子
15
3.6集成策略
集成策略就是在测试对象分析的基础上， 描述软件模块集成（组装）的方式、方法。 集成的基本策略比较多，分类比较复杂， 但不管怎样分，所以分类分类方法都可以 归结为非增值式和增值式两大类，其余的 很多方法都是在此基础上的细分。
16
3.6.1非增值式策略
25
3.6.2增值式策略
自顶向下和自底向上法的比较
“自顶向下”法的主要优点：不需要测试驱动 程序，能够在测试阶段的早期实现并验证系统 的主要功能，而且能在早期发现上层模块的接 口错误。 “自顶向下”法的主要缺点：需要存根程序， 可能遇到与此相联系的测试困难，低层关键模 块中的错误发现较晚，而且用这种方法在早期 不能充分展开人力。 “自底向上”法的优缺点与“自顶向下”法刚 好相反。
18
3.6.2增值式策略
增值方式有两种方式：
自顶向下（Top Down Testing） 自底向上（Bottom Up Testing）
19
自顶向下（Top Down Testing）
从主控模块（“主程序”）开始，沿着 软件的控制层次向下移动，从而逐渐把 各个模块结合起来。 这种测试方法不需要驱动模块 。 在组装过程中，可以使用深度优先的策 略，或宽度优先的策略。
23
自底向上（Bottom Up Testing）
这种组装的方式是从程序模块结构的最底 层的模块开始组装和测试。
24
自底向上（Bottom Up Testing）
具体策略是：
把低层模块组合成实现某个特定的软件子功能 的族。 写一个驱动程序（用于测试的控制程序），协 调测试数据的输入和输出。 对由模块组成的子功能族进行测试。 去掉驱动程序，沿软件结构自下向上移动，把 子功能族组合起来形成更大的子功能族。 循环(2)-(4)步
数据结构设计测试主要依据以上标准。
12
3.5.3程序界面设计测试
目前流行的界面风格有三种方式：多窗体、 单窗体以及资源管理器风格，无论那种风 格，以下规则是应该被重视的。
规则
13
3.5.4开发语言和工具选择
与当前主流技术一致性； 与公司目前掌握技术一致性； 对客户业务满足性
集成测试评 估 集成测试数 据分析 集成测试评 估
资源安排 进度安排
3.7.1制定集成测试计划
集成测试计划应在概要设计阶段完成，一 般情况下，概要设计结束并完成评审后一 个星期，集成测试计划应完成。 集成测试计划的输入有（制定依据）：
需求规格说明书； 概要设计说明书； 产品开发计划书
先分别测试每个模块，再把所有模块按 设计要求放在一起结合成所要的程序。 优点 ：一是方法简单，二是允许多个测 试人员并行工作，对人力、物力资源利 用率较高。 缺点：必须为每个模块准备相应的驱动 模块和辅助桩模块，故测试成本较高； 其次，一旦集成后的系统包含多种错误， 难以对错误定位和纠正。
2
3.1.1集成测试与单元测试的区别
测试对象有所区别; 集成测试关注的是模块间的接口，接口之 间的数据传递关系，单元组合后是否实现 预计的功能。 集成测试组装的对象比单元测试的对象级 别要高。
3
3.1.2集成测试与系统测试的区别
系统测试对象是整个系统以及与系统交互的硬件和软件平 台。系统测试更多程度上是站在用户的角度上对系统做功 能性的验证，同时还对系统进行一些非功能性的验证，包 括系统测试测试、压力测试、安全性测试、恢复性测试等。 系统测试的依据来自用户的需求规格说明书和行业的已成 文的或事实上的标准。 集成测试所测试的对象是模块间的接口，其目的是要找出 在模块接口上面，包括整体体系结构上的问题。其测试的 依据来自系统的高层设计（架构设计或概要设计）。 软件的集成测试工作最好由不属于该软件开发组的软件设 计人员承担，以提高集成测试的效果。
28
3.6.5基于使用集成策略
针对面向对象系统，通过类之间的使用关系来集成系统， 从而验证系统的稳定性。在一个面向对象系统中，存在一 些独立的类和一些相互耦合的类。基于使用的集成从分析 类之间的依赖关系或包含关系出发，通过最小依赖关系/ 包含关系的类开始集成，逐步扩大有相互关系的类，最后 集成到整个系统。通过该集成方法，可以验证类之间接口 的正确性。 测试步骤如下： 划分类之间耦合关系； 测试独立的类； 逐步增加具有依赖或包含关系的类（既使用独立类的 类），直到构造完整个系统。 主要测试依据是类关系图。
3.1基本概念 3.2集成测试目的 3.3集成测试层次 3.4集成测试方法 3.5集成静态测试 3.6集成策略 3.7集成测试流程 3.8案例分析
1
3.1基本概念
定义
集成测试又称组装测试、联合测试、子系统测 试或部件测试。集成测试是在单元测试的基础 上，将所有模块按照设计要求（如根据结构图） 组装成子系统或系统进行的测试活动。 单元测试完成后便进入集成测试阶段。
集成测试的依据是需求规格说明书、概要 设计及详细设计说明书。
9
3.5集成静态测试
测试内容
主要测试概要设计同需求的一致性，以及概要 设计的合理性。
测试方法
采用同行评审的形式是审查或小组评审
ቤተ መጻሕፍቲ ባይዱ
概要设计是将软件需求转换为软件的系统 体系结构、程序界面和数据结构的过程， 及开发语言和工具的选择。因此概要设计 的测试主要从这几个方面进行。
测试A
S4
加入B
S4
加入C
A
A
A
B
C
D
B
C
D
B
C
D
S4
S5
E
S5
E
F 22
加入D
加入E
加入F
自顶向下（Top Down Testing）
步骤：
对主控模块进行测试，测试时用存根程序代替所有直 接附属于主控模块的模块 根据选定的结合策略（深度优先或宽度优先），每次 用一个实际模块代替一个存根程序（新结合进来的模 块往往又需要新的存根程序） 在结合下一个模块的同时进行测试 为了保证加入模块没有引进新的错误，可能需要进行 回归测试（即，全部或部分地重复以前做过的测试） 从第2步开始不断地重复进行上述过程，直至完成。
10
3.5.1系统体系结构设计测试
体系结构的“4+1”视图描述 用例视图 :用例视图定义系统的外部行为，是最终用户、分 析人员和测试人员所关注的。用例视图定义了系统的功能， 是描述系统设计和构建的其它视图的基础，即用例驱动。 逻辑视图 :逻辑视图描述逻辑结构，该逻辑结构支持用例视 图描述的功能，它描述了问题空间中的概念以及实现系统 功能的机制，如类（抽象类）、包、子系统等，因而是编 程人员最关心的。 实现视图 :实现描述用于组建系统的物理组件，如可执行文 件、DLL、.java文件、.cpp文件代码和数据库等系统程序 员所看到的软件产物，是和配置管理以及系统集成相关的 信息。 进程视图 :进程视图描述将系统分解为过程和任务，以及这 些并发元素之间的通信与同步。 部署视图 :描述系统的物理网络布局及程序分布，是系统工 程师和网络工程师所感兴趣的。 11
4
3.2集成测试目的
在把各个模块连接起来的时侯，穿越模块接口的数据是否 会丢失； 一个模块的功能是否会对另一个模块的功能产生不利的影 响； 各个子功能组合起来，能否达到预期要求的父功能； 全局数据结构是否有问题； 单个模块的误差累积起来，是否会放大，从而达到不能接 受的程度。 在单元测试的同时可进行集成测试，发现并排除在模块连 接中可能出现的问题，最终构成要求的软件系统。
3.5.2数据结构设计测试
数据结构设计确定软件涉及的文件系统的结构以 及数据库的模式、子模式，进行数据完整性和安 全性的设计。它包括：
确定输入、输出文件的详细的数据结构； 结合算法设计，确定算法所必须的逻辑数据结构及操 作； 内部模块之间的接口数据格式设计 数据库设计合理性。具体数据库设计合理性见数据库 相关专业书籍。
5
3.3集成测试的层次
子系统内集成测试(模块) 子系统间集成测试 (可执行程序)
6
3.3集成测试的层次
模块与子系统的区别 例子
配用电监测与管理系统由很多个子系统组成， 如通讯子系统、数据采集子系统、报警服务子 系统、前置机应用子系统等。 而每个子系统又由多个功能模块组成，如数据 采集子系统由档案参数模块、任务处理模块、 规约解析模块等组成
17
3.6.2增值式策略
这种集成方式又称渐增式组装。首先对一个个模 块进行模块测试，然后将这些模块逐步组装成较 大的系统，在组装的过程中边连接边测试，以发 现连接过程中产生的问题。通过增值逐步组装成 为要求的软件系统。 相对非增值式策略，可以较早发现模块间的接口 错误；发现问题也易于定位。它的缺点是测试周 期比较长，可以同时投入的人力物力受限。
32
3.7.1制定集成测试计划
集成测试计划的内容有：
确定集成测试对象和测试范围； 确定集成测试阶段性时间进度； 确定测试角色和分工； 考虑外部技术支援的力度和深度，以及相关培 训安排； 初步考虑测试环境和所需资源； 集成测试活动风险分析和应对； 定义测试完成标准；
33
3.7.2集成测试分析和设计
20
自顶向下（Top Down Testing） —深度优先
A A A S1 S2 S3 B S2 S3 B S2 S3
测试A
S4
加入B
E
加入E
A
A
A
B
C
S3
B
C
D
B
C
D
E
S5
E
S5
E
F
加入C
加入D
加入F
21
自顶向下（Top Down Testing） —宽度优先
A A A
S1 S2 S3 B S2 S3 B C S3
首先单独测试每一层。对于顶层而言，需要构造桩；对于底层， 需要构造驱动；对于中间层，需要构造驱动和桩。 执行层次的自顶向下集成。结果测试包/驱动器应该被设计为可复 用/可重运行于随后的集成。 在接下来的一层中使用自顶向下的方法。去掉第二层的桩并实现 接口。扩充控制测试包以达到所有新实现的构件再运行测试。 每层的接口通过以后，去掉所有桩并实现到下一层的接口。
7
3.3集成测试的层次
TCP通讯模块 规约过滤模块 档案参数 模块 任务处理模块 规约解析模块 通讯日志, 文件输出
数据库输出模块 数据库接口
8
3.4集成测试方法
静态测试
概要设计的测试
动态测试
黑盒测试 ，但有时候需了解内部细节并结合白 盒测试，所以更多的资料将黑盒和白盒相结合 的测试称为灰盒测试 。
29
3.6.6分层集成策略
分层模型在通信系统中是很常见的。分层集成就是针对这 个特点使用的一种集成策略。系统的层次划分可以通过逻 辑的或物理的手段进行。在逻辑上，一般通过功能把系统 划分成不同层次的功能单元，功能单元内部具有较高的耦 合性，相互之间的关系具有线性层次关系。 层次集成可能是自顶向下或自底向上的。一个自顶向下的 方法采用下列步骤：
26
3.6.3混合增值式策略
对软件结构中较上层，使用的是“自顶向 下”法；对软件结构中较下层，使用的是 “自底向上”法，两者相结合
27
3.6.4基于事件（消息）集成策略
从验证消息路径的正确性出发，渐增式把系统集成在一起， 从而验证系统的稳定性。，面向对象系统中，每个功能路 径对应于一系列事件，可以将对应于系统的一个输入或者 是事件所需要的类集成到一起，然后分别进行测试。 测试的步骤如下： 从系统的外部看，分析系统可能输入消息集。 选取一条消息，根据序列图或协作图中的事件交互关 系，将相关类集成在一起进行测试。 选取下一条消息，根据序列图或协作图中的事件交互 关系，将相关类集成在一起进行测试。直到所有类都 被集成到系统中。 主要测试依据是序列图或协作图
30
3.7集成测试流程
集成测试计 划 软件体系结 构初步分 析 关键特性分 析 工作量估计 集成测试分 析与设计 集成测试对 象分析 集成策略选 择 集成测试工 具选择和 设计 集成测试代 码设计 集成测试用 例设计
31
集成测试实 现 集成测试工 具开发 集成测试代 码开发 集成测试用 例开发
集成测试执 行 建立集成测 试环境 执行集成测 试 测试结果记 录
14
概要设计检查单
例子
15
3.6集成策略
集成策略就是在测试对象分析的基础上， 描述软件模块集成（组装）的方式、方法。 集成的基本策略比较多，分类比较复杂， 但不管怎样分，所以分类分类方法都可以 归结为非增值式和增值式两大类，其余的 很多方法都是在此基础上的细分。
16
3.6.1非增值式策略
25
3.6.2增值式策略
自顶向下和自底向上法的比较
“自顶向下”法的主要优点：不需要测试驱动 程序，能够在测试阶段的早期实现并验证系统 的主要功能，而且能在早期发现上层模块的接 口错误。 “自顶向下”法的主要缺点：需要存根程序， 可能遇到与此相联系的测试困难，低层关键模 块中的错误发现较晚，而且用这种方法在早期 不能充分展开人力。 “自底向上”法的优缺点与“自顶向下”法刚 好相反。
18
3.6.2增值式策略
增值方式有两种方式：
自顶向下（Top Down Testing） 自底向上（Bottom Up Testing）
19
自顶向下（Top Down Testing）
从主控模块（“主程序”）开始，沿着 软件的控制层次向下移动，从而逐渐把 各个模块结合起来。 这种测试方法不需要驱动模块 。 在组装过程中，可以使用深度优先的策 略，或宽度优先的策略。
23
自底向上（Bottom Up Testing）
这种组装的方式是从程序模块结构的最底 层的模块开始组装和测试。
24
自底向上（Bottom Up Testing）
具体策略是：
把低层模块组合成实现某个特定的软件子功能 的族。 写一个驱动程序（用于测试的控制程序），协 调测试数据的输入和输出。 对由模块组成的子功能族进行测试。 去掉驱动程序，沿软件结构自下向上移动，把 子功能族组合起来形成更大的子功能族。 循环(2)-(4)步
数据结构设计测试主要依据以上标准。
12
3.5.3程序界面设计测试
目前流行的界面风格有三种方式：多窗体、 单窗体以及资源管理器风格，无论那种风 格，以下规则是应该被重视的。
规则
13
3.5.4开发语言和工具选择
与当前主流技术一致性； 与公司目前掌握技术一致性； 对客户业务满足性
集成测试评 估 集成测试数 据分析 集成测试评 估
资源安排 进度安排
3.7.1制定集成测试计划
集成测试计划应在概要设计阶段完成，一 般情况下，概要设计结束并完成评审后一 个星期，集成测试计划应完成。 集成测试计划的输入有（制定依据）：
需求规格说明书； 概要设计说明书； 产品开发计划书
先分别测试每个模块，再把所有模块按 设计要求放在一起结合成所要的程序。 优点 ：一是方法简单，二是允许多个测 试人员并行工作，对人力、物力资源利 用率较高。 缺点：必须为每个模块准备相应的驱动 模块和辅助桩模块，故测试成本较高； 其次，一旦集成后的系统包含多种错误， 难以对错误定位和纠正。
2
3.1.1集成测试与单元测试的区别
测试对象有所区别; 集成测试关注的是模块间的接口，接口之 间的数据传递关系，单元组合后是否实现 预计的功能。 集成测试组装的对象比单元测试的对象级 别要高。
3
3.1.2集成测试与系统测试的区别
系统测试对象是整个系统以及与系统交互的硬件和软件平 台。系统测试更多程度上是站在用户的角度上对系统做功 能性的验证，同时还对系统进行一些非功能性的验证，包 括系统测试测试、压力测试、安全性测试、恢复性测试等。 系统测试的依据来自用户的需求规格说明书和行业的已成 文的或事实上的标准。 集成测试所测试的对象是模块间的接口，其目的是要找出 在模块接口上面，包括整体体系结构上的问题。其测试的 依据来自系统的高层设计（架构设计或概要设计）。 软件的集成测试工作最好由不属于该软件开发组的软件设 计人员承担，以提高集成测试的效果。
28
3.6.5基于使用集成策略
针对面向对象系统，通过类之间的使用关系来集成系统， 从而验证系统的稳定性。在一个面向对象系统中，存在一 些独立的类和一些相互耦合的类。基于使用的集成从分析 类之间的依赖关系或包含关系出发，通过最小依赖关系/ 包含关系的类开始集成，逐步扩大有相互关系的类，最后 集成到整个系统。通过该集成方法，可以验证类之间接口 的正确性。 测试步骤如下： 划分类之间耦合关系； 测试独立的类； 逐步增加具有依赖或包含关系的类（既使用独立类的 类），直到构造完整个系统。 主要测试依据是类关系图。