集成测试
集成测试的方法
集成测试的方法一、简介集成测试（Integration Testing）是指用于验证不同模块之间协作的测试技术。
它包括从单个模块开始、把已软件系统中模块逐个集成、测试，最终完成整个系统的验证。
集成测试的重点在于在集成各个模块后的部分系统，对不同模块之间的交互、组合进行检查测试，验证系统整体的可用性。
集成测试主要检验模块之间的接口和功能，通过把模块一个一个集成，并与其它模块进行协作，来检验程序的正确性及其可行性。
二、集成测试的方法1、单元集成测试单元集成测试是指在系统设计的初始阶段，用来测试单个或多个模块之间的接口和功能，并确定它们之间的相互作用。
在这一测试阶段，模块的接口是静态的，而模块的内部功能开发得较为完善。
单元集成测试时所运行的一系列测试可以被看作是一个用来进行集成测试的准备工作，而这些测试任务本身构成一个完整的测试系统，可以在准确度和效率方面对系统表现作出判断。
2、模块集成测试模块集成测试是指在软件系统开发过程中的一种测试方法，它是把系统划分为不同的模块，每个模块都应该依据设计和开发规范进行开发和测试，模块之间也有特定的接口和协作。
模块集成测试的关注点在于模块之间的接口和功能的一致性，是为系统集成测试的准备工作。
3、系统集成测试系统集成测试是指在软件系统开发过程中的最后一种测试方法，它的目的是检查已开发的部件，验证系统的整体功能，确保系统能够按要求运行。
系统集成支持与设计开发活动有关的各种工作，以及在集成过程中引起可能的各种BUG（如参数的不匹配、操作的不一致等）。
测试过程中，发现错误后需要修改错误，这是集成测试的重要一部分内容。
四、优缺点优点：1、集成测试可以检查系统的整体功能，确保系统的稳定性和可靠性。
2、集成测试可以发现可能的Bug，避免严重的系统漏洞。
3、集成测试可以检查各个模块之间的接口和协作，确保系统能够按要求正确运行。
缺点：1、集成测试需要对系统的架构有深入的了解，以及相应的测试环境，这样才能保证测试效果。
简述集成测试的概念
集成测试，也称为集成测试阶段，是软件测试过程中的一个重要阶段，其主要目的是确保在将各个模块组合在一起后，整个系统的功能能够按照预期正常工作。
集成测试是在单元测试之后进行的，其目的是在单元测试的基础上，将各个模块组合在一起进行测试，以验证各个模块之间的接口是否正确，以及模块之间的协作是否正常。
集成测试的主要目标是发现模块接口之间存在的问题，包括数据传递错误、模块间的协作问题、以及系统架构上的问题等。
这些问题可能会在单元测试中被遗漏，因为单元测试主要关注的是单个模块的功能和行为，而集成测试则关注的是模块之间的交互和整个系统的行为。
在进行集成测试时，通常会采用自底向上的方法，即从最小的单元开始，逐步将它们组合在一起，直到整个系统能够正常运行。
在这个过程中，每个模块都需要被集成和测试，以确保它们之间的接口和协作是正确的。
集成测试的另一个重要目标是验证系统架构的正确性。
系统架构是指系统的整体结构、模块之间的交互方式以及数据流动等。
如果系统架构存在问题，那么即使每个模块都经过了单元测试，整个系统也可能无法正常工作。
因此，集成测试是验证系统架构是否正确的重要手段。
在进行集成测试时，通常会采用黑盒测试、灰盒测试和白盒测试等方法。
黑盒测试主要关注输入和输出，而不关注内部实现细节。
灰盒测试则介于黑盒测试和白盒测试之间，既关注输入和输出，又关注内部实现细节。
白盒测试则完全了解内部实现细节，可以根据代码的结构和逻辑进行测试。
总之，集成测试是软件测试过程中的一个重要阶段，其主要目的是确保在将各个模块组合在一起后，整个系统的功能能够按照预期正常工作。
在进行集成测试时，需要采用自底向上的方法，逐步将模块组合在一起进行测试，同时验证系统架构的正确性。
通过集成测试，可以发现模块接口之间存在的问题以及系统架构上的问题，从而确保整个系统的质量和稳定性。
集成测试_软件测试技术
增量式测试的集成是逐步实现的： ——逐次将未曾集成测试的模块和已经集成测试的模块 （或子系统）结合成程序包，再将这些模块集成为较大 系统，在集成的过程中边连接边测试，以发现连接过程 中产生的问题。
2 增量式集成测试
按照不同的实施次序，增量式集成测试又可以分为三种 不同的方法： （1）自顶向下增量式测试 （2）自底向上增量式测试 （3）混合增量式测试
（1）自顶向下增量式测试
集成测试的整个过程由3个步骤完成： （1）主控模块作为测试驱动器。 （2）根据集成的方式（深度或广度），下层的桩模块一次 一次地被替换为真正的模块。 （3）在每个模块被集成时，都必须进行单元测试。 重复第2步，直到整个系统被测试完成。
（1）自顶向下增量式测试（续）
⑴ Top-down testing 第1步：测试顶端模块，用桩 模块(stub)代替 直接附属的下层模块 Stub: to simulate the activity of the component which is not yet tested. M
M1
M2
第3步：去掉Driver，自下而上把子功能 族合成更大的子功能族。
M
M
M M M M M M
M
M M M
注意：两种策略 的优、缺点刚好 互补，但单用其 中任一种都不实 际，通常根据软 件的特点将二者 混用。
实例 采用自底向上增量式测试方法进行集成测试
(3) 混合增殖式测试
衍变的自顶向下的增殖测试
首先对输入／输出模块和引入新 算法模块进行测试; 再自底向上组装成为功能相当完 整且相对独立的子系统; 然后由主模块开始自顶向下进行 增殖测试。
自底向上自顶向下的增殖测试
软件测试(集成测试)
18
深度优先组装方式
19
广度优先组装方式
20
集成环节
（1）以主模块为所测模块兼驱动模块，全部直属于主 模块旳下属模块全部用桩模块对主模块进行测试。
（2）采用深度优先或广度优先旳策略，用实际模块替 代相应桩模块，再用桩替代它们旳直接下属模块， 与已测试旳模块或子系统集成为新旳子系统。
集成
确认
系统
测试
测试
测试
装配好
确认
可运
测试过 旳软件 旳模块
旳软件
行旳 软件
4
什么是集成测试
也叫做组装测试、联合测试、子系统测试和 部件测试。
是在单元测试旳基础上，将全部模块按照概 要设计要求组装成为子系统或系统，进行集 成测试。
5
单元测试、集成测试与系统测试旳差别
对象
目旳
测试根据 测试措施
单元 测试
模块内部 程序错误
消除局部模块逻辑 和功能上旳错误和
缺陷
模块逻辑设计 模块外部阐明
大量采用白 盒测试措施
集成 测试
模块间旳 集成和调 用关系
找出与软件设计有
关旳程序构造，模 块调用关系，模块
程序构造设计
间接口方面旳问题
灰盒测试， 采用较多黑 盒措施构造 测试用例
系统 测试
整个系统， 涉及系统 软硬件等
从具有最小依赖性旳底层组件开始，按照依赖 关系树旳构造，逐层向上集成，以检验系统旳 稳定性。
集成示意图：
27
集成环节
（1）起始于模块依赖关系树旳底层叶子模块，也能 够把两个或多种叶子模块合并到一起进行测试
（2）使用驱动模块对环节１选定旳模块（或模块组） 进行测试
如何进行集成测试
如何进行集成测试随着软件开发的日益复杂化，测试也成为了一个不可忽视的环节。
其中，集成测试是一个非常关键的环节，它可以帮助开发人员和测试人员在整个开发周期中保证软件的稳定性和可靠性。
什么是集成测试集成测试是软件测试的一种方法，它旨在测试多个模块或组件之间的互操作性，包括软件系统的各种部分、子系统或模块。
它涉及到将其他分离的模块或组件集成到一个单独的软件产品中进行测试，以发现相互关联的错误和缺陷。
集成测试可以包括以下几个方面：1. 模块集成测试（Module Integration Testing）：对于已经测试过的模块，对它们进行再次测试，确保它们能够在一个完整的系统中正常运行。
2. 子系统集成测试（Subsystem Integration Testing）：将在模块集成测试中成功测试的模块进行组合，对它们进行集成测试。
此时，测试着重考虑的是模块之间的相互依赖性和兼容性。
3. 系统集成测试（System Integration Testing）：对子系统进行测试，用于测试子系统之间的交互，确保它们能够在一个完整的系统中协同工作。
4. 集成测试（Integration Testing）：将软件的所有部分都集成到一起进行全面测试，评估整个系统的性能和功能。
如何进行集成测试进行集成测试时，要遵循一定的步骤和规范，以下是一些通用的集成测试方法：1. 定义测试策略：首先，需要定义集成测试的范围和测试策略，例如测试的目标是什么、哪些模块需要测试以及测试的时间和地点等。
2. 环境设置：为集成测试设置合适的测试环境，包括硬件和软件等方面。
测试环境应该与实际情况尽量接近，以便发现更多的错误和缺陷。
3. 制定测试用例：设计针对集成测试的测试用例，包括正向测试用例、负向测试用例以及边界测试用例等。
4. 进行测试：执行测试用例，并勾选测试结果。
针对测试中出现的问题，需要记录下来并及时解决。
5. 验证测试结果：根据集成测试的结果，尽量确定系统的稳定性和可靠性。
冒烟测试和集成测试的区别
冒烟测试和集成测试的区别冒烟测试和集成测试是软件测试中常见的两种测试方法，虽然它们都涉及软件系统的测试，但在目的、执行时机、测试范围等方面有着不同的特点。
下面将从多个角度详细探讨冒烟测试和集成测试之间的区别。
目的•冒烟测试：冒烟测试旨在验证软件系统的某个阶段是否达到了最低可接受标准，确保软件系统的基本功能可以正常工作。
冒烟测试主要用于发现严重的缺陷，在软件开发过程的早期阶段执行，以节省时间和资源。
•集成测试：集成测试旨在验证不同模块、组件之间的集成是否正常运作，检验软件系统的整体功能和性能。
集成测试通常在软件开发的中后期阶段执行，侧重于模块之间的交互和接口测试。
执行时机•冒烟测试：冒烟测试在软件开发的早期阶段执行，通常在开发工作完成后的短时间内进行，以验证软件系统的基本功能是否正常。
如果冒烟测试未通过，可能会延迟后续的测试工作和开发工作。
•集成测试：集成测试在软件系统各个模块或组件集成完成后进行，确保各部分之间的接口和交互工作良好。
集成测试可以分为逐步集成、阶段性集成等不同的阶段，以检验整个系统的集成过程和结果。
测试范围•冒烟测试：冒烟测试的测试范围通常较窄，只验证软件系统的基本功能是否可用。
冒烟测试不涉及深入的功能测试和性能测试，重点是确认软件系统是否可以继续进行进一步的测试和开发。
•集成测试：集成测试的测试范围较广，涵盖了整个软件系统的各个组件、模块的集成情况，以及它们之间的交互。
集成测试不仅验证功能的正确性，还包括性能、稳定性、安全性等方面的测试。
结论综上所述，冒烟测试和集成测试虽然都是软件测试过程中重要的环节，但它们在目的、执行时机和测试范围等方面存在明显的区别。
冒烟测试着重于验证基本功能，早期发现严重缺陷；而集成测试则注重整体功能和性能的测试，确认各模块之间的集成是否正确。
在软件测试中，冒烟测试和集成测试的结合使用可以有效地提高软件系统的质量和稳定性。
软件测试-集成测试
• 集成测试又叫组装测试、联合测试、子系统 测试、部件测试
• 一般情况下，简单软件的集成测试设计采用
的都是黑盒测试用例设计的方法。
• 随着软件复杂度的增加，尤其是在大型的应 用软件中，常常会使用把白盒测试与黑盒测 试结合起来进行测试用例设计的方法，所以
们一般只进行很少的数据处理，例如打印入口和反馈，以
便于检验待测模块与其下级模块的接口。
测试用例
驱动模块
测试结果
待测模块
桩模块
桩模块
桩模块
5.2.1 非渐增式集成
• 非渐增式集成方法首先对每个子模块进行 测试（即单元测试），然后将所有模块全 部集成起来一次性进行集成测试。
A
SB
SC
SD
DA
DA
B
• 测试执行结果应当如实的记录。
5.2 集成测试策略
• 由模块组装成程序时有两种方法：
– 非渐增式集成 先分别测试每个模块，再把所有模块按设计要
求放在一起结合成所要的程序。
– 渐增式集成 把下一个要测试的模块同已经测试好的那些模
块结合起来进行测试，测试完以后再把下一个应 该测试的模块结合起来进行测试。
– 集成测试可以服务于架构设计，可以检验设计 中是否存在错误和遗漏
5.1.4 集成测试的层次与原则
1．集成测试的层次 对于传统软件来说，按集成粒度不同，可以把集成 测试分为3个层次，即：
（1）模块间集成测试 （2）子系统内集成测试 （3）子系统间集成测试
2.集成测试的原则
• 所有公共接口必须被测试到； • 关键模块必须进行充分测试； • 集成测试应当按一定层次进行； • 集成测试策略选择应当综合考虑质量、成本和进度三者之间的
什么是集成测试
什么是集成测试？集成测试（Integration Testing）是软件开发过程中的一种测试方法，用于验证多个组件或模块在一起工作时的正确性和一致性。
它的目的是检测和解决组件之间的集成问题，以确保整个系统在集成的环境中能够正常运行。
在软件开发过程中，通常会将系统分解为多个组件或模块，每个组件负责实现特定的功能。
集成测试的主要任务是验证这些组件之间的接口和交互是否正确，以及组件在一起工作时是否符合预期。
集成测试的关键特点包括：1. 组件集成：集成测试关注的是多个组件在一起工作的情况。
这些组件可以是函数、模块、库、服务或子系统等。
集成测试的目标是确保这些组件能够正确地协同工作，完成预期的功能。
2. 接口测试：集成测试重点测试组件之间的接口和数据交换。
它验证数据的传递、参数的传递、函数的调用等，以确保组件之间的通信是正确的和一致的。
3. 依赖管理：集成测试需要考虑组件之间的依赖关系。
组件可能依赖于其他组件的功能或数据，因此在进行集成测试时，需要确保这些依赖被正确地管理和满足。
4. 整体功能验证：集成测试不仅验证组件之间的接口，还验证整体系统的功能。
它测试系统在一起工作时是否能够完成预期的功能，并满足用户需求和规格。
集成测试的策略和方法可以根据具体情况而有所不同。
以下是几种常见的集成测试方法：1. 自上而下（Top-down）：自上而下的集成测试从系统的最高级别开始，逐渐向下测试系统的各个组件。
在这种方法中，可以使用模拟或桩（Stub）来代替下层组件，以便尽早进行测试。
2. 自下而上（Bottom-up）：自下而上的集成测试从系统的最低级别开始，逐渐向上测试系统的各个组件。
在这种方法中，可以使用驱动程序（Driver）来代替上层组件，以便尽早进行测试。
3. 混合方法（Hybrid）：混合方法结合了自上而下和自下而上的思想，从系统的中间层次开始测试。
在这种方法中，可以根据具体情况，选择自上而下或自下而上的策略进行测试。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
实验三集成测试1实验类型：设计性要求：必做学时：62实验内容:在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。
3实验的基本要求：1、要求学生掌握桩模块和驱动模块的开发。
2、发现并排除在单元模块连接中可能发生的问题。
4 实验主要方法1 定义：集成测试，也叫组装测试或联合测试。
在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。
实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。
一些局部反映不出来的问题，在全局上很可能暴露出来。
子系统：子系统是一种模型元素，它具有包（其中可包含其他模型元素）和类（其具有行为）的语义。
子系统的行为由它所包含的类或其他子系统提供。
子系统实现一个或多个接口，这些接口定义子系统可以执行的行为。
使用可以通过多种互补的方法来使用子系统，将系统分为若干个单元，这些单元：可以独立预定、配置或交付可以独立开发（只要接口保持不变）可以在一组分布式计算节点上独立部署可以在不破坏系统其他部分的情况下独立地进行更改此外，子系统还可以：将系统分为若干单元，以提供对关键资源的有限安全保护在设计中代表现有产品或外部系统从类协作中确定子系统如果某个协作中的各个类只是在相互之间进行交互，并且可生成一组定义明确的结果，就应将该协作和它的类封装在一个子系统中。
这一规则同样适用于协作的子集。
可以对协作的任何部分或全部进行封装和简化，这将会使设计更易于理解。
桩模块和驱动模块：软件测试技术的一种，主要用在单元测试阶段。
由于对已开发的单元模块功能和行为测试会涉及到仿真对象的概念，比如说驱动模块和桩模块。
驱动模块是用来模拟被测试模块的上一级模块，相当于被测模块的主程序。
它接收数据，将相关数据传送给被测模块，启用被测模块，并打印出相应的结果。
桩模块（Stub）是指模拟被测试的模块所调用的模块，而不是软件产品的组成的部分。
主模块作为驱动模块,与之直接相连的模块用桩模块代替。
在集成测试前要为被测模块编制一些模拟其下级模块功能的“替身”模块，以代替被测模块的接口，接受或传递被测模块的数据，这些专供测试用的“假”模块称为被测模块的桩模块。
如果被测试的单元模块需要调用其他模块中的功能或者函数（method），我们就应该设计一个和被调用模块名称相同的桩模块（Stub）来模拟被调用模块。
这个桩模块本身不执行任何功能仅在被调用时返回静态值来模拟被调用模块的行为。
举例说明：如果被测试单元中需要调用另一个模块customer的函数getCustomerAddress(customerID: Integer)，这个函数应该查询数据库后返回某一个客户的地址。
我们设计的同名桩模块（Stub）中的同名函数并没有真正对数据库进行查询而仅模拟了这个行为，直接返回了一个静态的地址例如"123 Newton Street"。
桩模块（Stub）的设置使得单元测试的进行成为一个相对独立且简单的过程。
模块连接：传统的单元测试包括了驱动模块（driver）和桩模块（stub）。
驱动模块的目的很单纯，就是为了访问类库的属性和方法，来检测类库的功能是否正确；Normal 0 0 2 false false EN-US KO X-NONE MicrosoftInternetExplorer4 如果被测试模块中的函数是提供给其他函数调用的，在设计测试用例时就应该设计驱动模块（Driver）。
举例来说：驱动模块（Driver）可以通过模拟一系列用户操作行为，比如选择用户界面上的某一个选项或者按下某个按钮等，自动调用被测试模块中的函数。
驱动模块（Driver）设置，使对模块的测试不必与用户界面真正交互。
2 目标：集成测试的目标是按照设计要求使用那些通过单元测试的构件来构造程序结构。
单个模块具有高质量但不足以保证整个系统的质量。
有许多隐蔽的失效是高质量模块间发生非预期交互而产生的。
以下两种测试技术是用于集成测试：1）功能性测试。
使用黑盒测试技术针对被测模块的接口规格说明进行测试。
2）非功能性测试。
对模块的性能或可靠性进行测试。
集成测试另外，集成测试的必要性还在于一些模块虽然能够单独地工作，但并不能保证连接起来也能正常工作。
程序在某些局部反映不出来的问题，有可能在全局上会暴露出来，影响功能的实现。
此外，在某些开发模式中，如迭代式开发，设计和实现是迭代进行的。
在这种情况下，集成测试的意义还在于它能间接地验证概要设计是否具有可行性。
集成测试是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。
它所测试的内容包括单元间的接口以及集成后的功能。
使用黑盒测试方法测试集成的功能。
并且对以前的集成进行回归测试。
3实施：集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。
在制定测试计划时，应考虑如下因素：1、是采用何种系统组装方法来进行组装测试；2、组装测试过程中连接各个模块的顺序；3、模块代码编制和测试进度是否与组装测试的顺序一致4、测试过程中是否需要专门的硬件设备；解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。
例如，若测试需要数字化仪和绘图仪，则相应测试应安排在这些设备能够投入使用之时，并需要为硬件的安装和交付使用保留一段时间，以留下时间余量。
此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。
单元测试后，有必要进行集成测试，发现并排除在模块连接中可能发生的上述问题，最终构成要求的软件子系统或系统。
对子系统，集成测试也叫部件测试。
任何合理地组织集成测试，即选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号和测试的次序、生成测试用例和调试的费用。
通常，有两种不同的组装方式：一次性组装方式和增值式组装方式。
4完成标准怎样判定集成测试过程完成了，可按以下几个方面检查：1、成功地执行了测试计划中规定的所有集成测试；2、修正了所发现的错误；3、测试结果通过了专门小组的评审。
集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。
整个测试活动要在评审人员出席的情况下进行。
在完成预定的组装测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。
测试报告中要记录实际的测试结果、在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。
此外还应提出不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。
5内容集成测试过程根据IEEE标准集成测试划分为4个阶段：计划阶段，设计阶段，实现阶段，执行阶段（实施阶段）计划阶段1）时间安排概要设计完成评审后大约一个星期2）输入需求规格说明书概要设计文档产品开发计划路标3）入口条件概要设计文档已经通过评审4）活动步骤1.定被测试对象和测试范围2.评估集成测试被测试对象的数量及难度，即工作量3.确定角色分工和作任务4.标识出测试各阶段的时间，任务，约束等条件5.考虑一定的风险分析及应急计划 6.考虑和准备集成测试需要的测试工具，测试仪器，环境等资源7.考虑外部技术支援的力度和深度，以及相关培训安排8.定义测试完成标准5）输出集成测试计划6）出口条件集成测试计划通过概要设计阶段基线评审设计阶段1）时间安排详细设计阶段开始2）输入需求规格说明书概要设计集成测试计划3）入口条件概要设计基线通过评审4）活动步骤1.被测对象结构分析2.集成测试模块分析3.集成测试接口分析4.集成测试策略分析5.集成测试工具分析6.集成测试环境分析7.集成测试工作量估计和安排。
5）输出集成测试设计（方案）6.出口条件集成测试设计通过详细设计基线评审。
实现阶段1）时间安排在编码阶段开始后进行2）输入需求规格说明书概要设计集成测试计划集成测试设计3）入口条件详细设计阶段4）活动步骤：1.集成测试用例设计2.集成测试代码设计（如果需要）3.集成测试脚本（如果需要）4.集成测试工具（如果需要）5）输出集成测试用例集成测试规程集成测试代码集成测试脚本集成测试工具6）出口条件测试用例和测试规程通过编码阶段基线评审执行阶段1）时间安排单元测试已经完成后就可以开始执行集成测试了2）输入需求规格说明书概要设计集成测试计划集成高度设计集成测试例集成测试规程集成测试代码（如果有）集成测试脚本集成测试工具详细设计代码单元测试报告3）入口条件单元测试阶段已经通过基线化评审4）活动步骤执行集成测试用例回归集成测试用例撰写集成测试报告5）输出集成测试报告6）出口条件集成测试报告通过集成测试阶段基线评审集成测试过程工作内容单元测试工作内容及其流程需求获取集成测试需求所确定的是对某一集成工作版本的测集成测试试的内容，即测试的具体对象。
集成测试需求主要来源于设计模型（Design Model）和集成构件计划（Integration Build Plan）。
集成测试着重于集成版本的外部接口的行为。
因此，测试需求须具有可观测、可测评性。
1．集成工作版本应分析其类协作与消息序列，从而找出该工作版本的外部接口。
2．由集成工作版本的外部接口确定集成测试用例。
3．测试用例应覆盖工作版本每一外部接口的所有消息流序列。
注意：一个外部接口和测试用例的关系是多对多，部分集成工作版本的测试需求可映射到系统测试需求，因此对这些集成测试用例可采用重用系统测试用例技术。
工件清单1、软件集成测试计划2、集成测试用例3、测试过程4、测试脚本5、测试日志6、测试评估摘要常用方案选型综述集成测试的实施方案有很多种，如自底向上集成测试、自顶向下集成测试、Big-Bang 集成测试、三明治集成测试、核心集成测试、分层集成测试、基于使用的集成测试等。
自顶向下测试自顶向下集成（Top-Down Integration）方式是一个递增的组装软件结构的方法。
从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来。
分两种方法：第一：先深度：按照结构，用一条主控制路径将所有模块组合起来；第二：先宽度：逐层组合所有下属模块，在每一层水平地集成测试沿着移动。
组装过程分以下五个步骤：步骤一：用主控模块作为测试驱动程序，其直接下属模块用承接模块来代替；步骤二：根据所选择的集成测试法（先深度或先宽度），每次用实际模块代替下属的承接模块步骤三：在组合每个实际模块时都要进行测试；步骤四：完成一组测试后再用一个实际模块代替另一个承接模块；步骤五：可以进行回归测试（即重新再做所有的或者部分已做过的测试），以保证不引入新的错误。