软件测试—十三章集成测试

集成测试是为了在集成时测试模块/组件，以验证它们是否按预期工作，即测试单独工作的模块在集成时没有问题。

在使用黑盒测试技术测试大型应用程序时，涉及多个彼此紧密耦合的模块的组合。我们可以应用集成测试技术概念来测试这些类型的场景。

什么是集成测试？

集成测试的含义非常简单- 将单元测试模块逐个集成/组合，并将行为测试为组合单元。

该测试的主要功能或目标是测试单元/模块之间的接口。

我们通常在“单元测试”之后进行集成测试。一旦创建并测试了所有单个单元，我们就开始组合这些“单元测试”模块并开始进行集成测试。

该测试的主要功能或目标是测试单元/模块之间的接口。

首先单独测试各个模块。模块经过单元测试后，逐个集成，直到所有模块都集成在一起，检查组合行为，验证需求是否正确实现。

在这里我们应该理解，集成测试不会在周期结束时发生，而是与开发同时进行。因此，在大多数情况下，所有模块实际上都无法测试，这就是测试不存在的东西的挑战！

为何进行集成测试

我们认为集成测试很复杂，需要一些开发和逻辑技能。确实如此！那么将这个测试集成到我们的测试策略中的目的是什么？

以下是一些原因：

在现实世界中，当开发应用程序时，它被分解为更小的模块，并且为每个开发人员分配1个模块。一个开发人员实现的逻辑与另一个开发人员完全不同，因此检查开发人员实现的逻辑是否符合预期并根据规定的标准呈现正确的值变得很重要。
很多时候，当数据从一个模块移动到另一个模块时，数据的面或结构会发生变化。附加或删除某些值，这会导致后续模块出现问题。
模块还与某些第三方工具或API进行交互，这些工具或API也需要进行测试，以确保该API /工具接受的数据是正确的，并且生成的响应也是预期的。
测试中一个非常常见的问题 - 频繁更改需求！:)许多时间开发人员在没有单元测试的情况下部署更改。当时集成测试变得很重要。

好处

这种测试有几个优点，下面列出的很少的一部分。

此测试可确保集成模块/组件正常工作。
一旦要测试的模块可用，就可以开始集成测试。它不需要完成其他模块以进行测试，因为Stubs和Drivers可以用于相同的操作。
它检测与接口相关的错误。

挑战

下面列出的是集成测试中涉及的一些挑战。

集成测试意味着测试两个或多个集成系统，以确保系统正常工作。不仅应该测试集成链接，还应该考虑环境进行详尽的测试，以确保集成系统正常工作。
管理集成测试变得复杂，因为它涉及的因素很少，如数据库，平台，环境等。
在将任何新系统与遗留系统集成时，需要进行大量的更改和测试工作。在集成任何两个遗留系统时也是如此。
如果在任何一个系统中进行任何更改都不确定，那么两个不同公司开发的两个不同系统的集成对于其中一个系统如何影响另一个系统是一个巨大的挑战。
为了最大限度地减少开发系统时的影响，应该考虑很少的事情，例如可能与其他系统集成等。

测试关注的重点

一个模块虽然能够单独工作，但并不能保证连接起来也能正常工作，程序在某些局部反应不出来的问题，在全局上可能暴漏出来，影响功能的实现，因此集成测试应当考虑两大（5）个问题：
1、模块间的接口（接口的覆盖率）
（1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失。
（2）全局数据结构是否有问题，会不会被异常修改。
2、集成后的功能（参数的传递）
（1）各个子功能组合起来，能否达到预期要求的父功能。
（2）一个模块的功能是否会对另一个模块的功能产生不利的影响。
（3）单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

集成测试的三个级别

由于集成的力度不同，一般可以把集成测试划分为三个级别：
1、模块内集成测试。
2、子系统内集成测试。
3、子系统间集成测试。

集成测试的模式

非渐增测试：先分别测试每个模块，再把所有模块按设计要求一次全部组装起来所要的系统，然后进行整体测试。非渐增式测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。非渐增式的方法如：大爆炸集成。
渐增测试：逐个把未经测试的模块组装到已经过测试的模块上去进行集成测试，每加入一个新模块进行一次测试，重复此过程直至程序组装完成。渐增式测试有以下组装方法：自顶向下和自底向上。
两者的区别是：
1、非渐增式方法是把单元测试和集成测试分成两个不同的阶段，前一阶段完成模块的单元测试，后一阶段完成集成测试。而渐增式测试则是把单元测试和集成测试结合在一起，同时完成。
2、非渐增式需要更多的工作量，因为每个模块都需要驱动模块和桩模块，而渐增式利用已测试过的模块作为驱动模块或桩模块，因此工作量少。
3、渐增式可以较早地发现接口间的错误，非渐增式到最后组装的时候才发现。
4、渐增式有利于拍错，发生错误往往和最近新加入的模块有关，而非渐增式发现接口错误推迟到最后，很难判断是哪一部分接口出错。
5、渐增式比较彻底，已测试的模块和新的模块在测试。
6、非渐增式开始可并行测试所有模块，能充分利用人力，对测试大型软件很有意义。

集成测试的策略

下面给出了一种测试集成及其优缺点。

集成测试策略最主要的有三种：
1、大爆炸集成（Big Bang Integration）。
2、自顶向下集成（Top-Down Integration）。
3、自底向上集成（Bottom-up Integration）。
基于以上三种测试策略，又提出了以下五种集成测试策略，它们都是在上面的三种主要测试策略的基础上进行综合，改进而成的。
1、三明治集成（Sandwich Integration）。
2、基干集成（Backbone Integration）。
3、分层集成（Layers Integration）。
4、基于功能的集成（Function-Based Integration）。
5、基于进度的集成（Schedule-Based Integration）

大爆炸方法：

（1）概念：大爆炸集成（Big Bang Integration）是属于非渐增式集成（Non-Incremental Integration）的一种方法，也叫一次性组装货整体拼装。该集成把所有组件一次性集合到被测系统中，不考虑组件之间的相互依赖性或者可能存在的风险。
（2）目的：在最短的时间内把系统组装起来，并且通过最少的测试来验证整个系统。
（3）策略：在大爆炸这种集成方法中，首先需要对每个模块进行单元测试，然后把所有单元组装到一起进行测试，最终得到要求的软件系统。
（4）优点：
*在有利的情况下，大爆炸集成可以迅速完成集成测试，并且只要极少数的驱动单元和桩单元（如果需要的话）。
*需要的测试用例最少。
*方法比较简单。
*可以并行开展，对人力、物力的资源利用率较高。
（5）缺点：
*这种在单元测试的基础上，将所有组件一次性进行组装，不考虑组件之间的依赖性，虽然简单，但是由于程序中不可避免的存在模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不大。
*在发现错误的时候，问题定位和修改都比较困难。
*即使被测系统能够被一次性集成，但还是会有很多接口问题可以躲过集成测试而进入到系统测试。
（6）适用范围：
*一个维护性项目（或者功能增强型项目），以前的产品已经很稳定，并且新增的项目只有少数几个组件被增加或者修改。
*被测系统比较小，并且它的每个组件都进行了充分的单元测试。

补充：
Big bang方法一次性集成了所有模块，即它不会逐个集成模块。它会在集成后验证系统是否按预期工作。如果在完全集成的模块中检测到任何问题，则很难找出导致该问题的模块。
大爆炸方法是一个耗时的过程，找到一个自身有缺陷的模块，因为这需要时间，一旦检测到缺陷，修复相同的方法会花费很高，因为在后期检测到缺陷。

大爆炸方法的优点：

这对于小型系统来说是一种很好的方法。

大爆炸方法的缺点：

很难检测出导致问题的模块。
Big Bang方法需要所有模块一起进行测试，这反过来会导致更少的测试时间，因为设计，开发，集成将占用大部分时间。
测试仅在一次进行，因此不会孤立地进行关键模块测试。

自顶向下集成

（1）概念：自顶向下集成（Top-Down Integration）采用了和设计一样的顺序进行测试，它在第一时间内对系统的控制接口进行验证，其中顶层的组件具有控制的责任，首先测试顶层的组件，然后逐步测试处于底层的组件，这种集成方式可以采用深度优先策略和广度优先策略。
（2）目的：从顶层开始控制，采用和设计一样的思路对系统进行测试，以验证系统的接口稳定性。
（3）策略：
*以主模块为所测模块兼驱动模块，所有直属于主模块下的下属模块全部用桩单元代替，对主模块进行测试。
*采用深度优先（Depth-First）或者广度优先（Breath-First）的策略，用实际模块替换相应桩模块，再用桩模块代替它们的直接下属模块，与已经测试的模块组成新的子系统或者系统。
（4）优点：
*自顶向下这种集成方式，在测试过程中较早的验证了主要的控制和判断点，如果主要控制有问题，尽早发现它能够减少以后的返工，所以这是十分必要的。
*如果采用深度优先的策略，就可以首先实现和验证一个完整的软件功能，可以先对逻辑输入的分支进行组装和测试，检查和客服潜藏的错误和缺陷，验证功能的正确性，为之后对主要加工分支的组装和测试提供了保证。
*功能的可行性较早得到了证实。
*最多只需要一个驱动模块，减少了驱动模块的费用开支，也减轻了后期对驱动模块的维护。
*由于该方法和设计的思路是一样的，所以可以和设计并行开展，如果目标环境或者设计需要改变，这种方式也可以灵活的适应。
*支持故障隔离。例如：A模块测试正常，但是假如B模块之后，出现问题，那么可以确定，要么就是B模块有问题，要么就是A模块和B模块之间的接口有问题。
（5）缺点：
*桩在每个测试中都必须提供，所以桩的开发和维护是该策略的最大成本。
*底层组件中的一个无法预计的需要可能会导致许多顶层组件的修改，这破坏了部分先前构造的测试包。
*底层组件行为的验证被推迟了。
*随着底层模块的不断增加，系统越来越复杂，导致底层模块的测试肯那个不够充分，尤其是那些被重用的模块。
（6）适用范围：
*产品控制结构比较清晰和稳定。
*产品的高层借口比较稳定，底层变化比较频繁。
*产品的控制模块可能存在技术风险，需要较早被验证。
*希望尽早能够看到产品的系统功能行为。

自底向上集成

（1）概念：自底向上集成（Bottom-up Integration）方式是从程序模块结构的最底层的模块开始组装和测试，因为模块是自底向上进行测试的，对于一个给定层次的模块，它的子模块已经组装并测试完成，所以不再需要桩模块。需要从子模块中得到的信息可以直接运行子模块得到。
（2）目的：从具有最小依赖性的底层组件开始按照依赖关系树的结构，逐层向上集成，以验证整个系统的稳定性。
（3）策略：
*起始于系统的最底层模块，也可以把多个子模块合并到一起进行测试。
*使用驱动模块对选定的模块进行测试。
*用实际模块代替驱动模块，与它已经测试过的子模块组装成为一个更大的模块组进行测试。
*重复上面的步骤，直到系统最顶层模块加入到已测系统中。
（4）优点：
*允许对底层模块行为的早期验证。
*在工作的最初可以采用并行进行集成，比自顶向下的测试效率高。
*由于驱动模块是额外编写的，而不是实际的模块，所以对实际被测模块的可测试性要求比自顶向下的测试策略要小。
*减少了桩模块的工作量。
*故障隔离。
（5）缺点：
*驱动模块的开发工作量比较大。
*对高层的验证被推迟到最后，设计上的错误不能尽早的被发现，尤其对于那些控制机构在整个体系中比较关键的产品。
*随着集成到了顶层，整个系统将变得越来越复杂，并且对于底层的一些异常很难覆盖。
（6）适用范围：
*采用契约式开发（Design by Contract）的产品。
*底层接口比较稳定的产品。
*高层接口变化比较频繁的产品。
*底层模块较早被完成的产品。

三明治集成

由于自顶向下集成策略和自底向上集成策略都有各自的缺点，所以就出现了一种结合这两种测试策略的集成方式，即：三明治集成。
（1）概念：三明治集成（Sandwich Integration）有时也被称为混合式集成，三明治集成就是把系统划分为三层，中间一层为目标层，测试的时候，对目标层上面的一层使用自顶向下的集成策略，对目标层下面的一层使用自底向上的集成策略，最后测试在目标层会合。
（2）目的：综合自顶向下的集成测试策略和自底向上的集成测试策略的优点。
（3）策略:
*首先对目标层上面的一层采用自顶向下的测试策略，对主模块A进行测试，对A调用的子模块（目标层）用桩单元代替。
*其次对目标层下面的一层采用自底向上的测试策略。
*最后将三层集成在一起。
（4）优点：集合了自顶向下和自底向上的两种集成策略的优点。
（5）缺点：中间层在被集成前测试不充分。
（6）适用范围：大部分软件开发项目都可以使用这种集成策略。

基干集成

1）概念：在很多系统中，尤其在嵌入式系统中，一般可以划分成两个部分：内核部分（基干部分）和外围应用部分，这两部分经常会被不同的项目组并发开发。
（2）目的：结合自顶向下，自底向上和大爆炸集成的元素，以验证紧密耦合的子系统间的互操作性。
（3）策略:
*对基干中的每个模块进行单独的充分的测试，必要时使用驱动和桩。
*对基干中所有的模块进行大爆炸集成，形成基干子系统，并使用一个驱动模块检查经过大爆炸的基干。
*对应用的控制子系统进行自顶向下的集成。
*把基干和控制子系统进行集成，重新构造控制子系统。
*对个应用子系统采用自底向上的集成策略。
*集成基干子系统，控制子系统和各应用子系统形成整个系统。
（4）优点：具有三明治集成的优点，更适合于大型复杂项目的集成。
（5）缺点：
*必须对系统的结构和相互依存性进行仔细的分析。
*必须开发桩和驱动模块，并且由于被测系统的复杂性导致这些模块开发工作量的加大，可以通过复用技术在一定程度上降低成本。
*由于局部采用了大爆炸的策略，所以有些接口可能测试不完整。
（6）适用范围：适合大型复杂的项目
*具有多层协议的嵌入式系统。
*操作系统产品

分层集成

（1）概念：分层模型在通讯系统中很常见，分层集成就是针对这个特点使用的一种集成。
（2）目的：通过增量式集成的方法验证一个具有层次性体系结构的应用系统的稳定性和互操作性。
（3）策略：
*划分系统的层次。
*确定每个层次内部的集成策略，该策略可以使用大爆炸集成，自顶向下集成，自底向上集成和三明治集成中的任何一种策略，一般对于顶层可能还有第二层的内部采用自顶向下的集成策略；对于中间采用自底向上的集成策略，对于底层主要采用进行单独测试。
*确定层次间的集成策略，该策略可以使用大爆炸集成，自顶向下集成，自底向上集成和三明治集成中的任何一种策略。
（4）优缺点：因为每个层次间和层次内部采用的策略不同，所以优缺点也就是和它采用的测试策略相对应。
（5）适用范围:有明显线性层次关系的产品系统。

基于功能的集成

（1）概念：在开发过程中，尽早的看到系统主要功能的实现，对于谈对来说也是很有必要的，基于功能的集成是从功能角度出发，按照功能的关键程度对模块的集成顺序进行组织。
（2）目的：采用增值的方法，尽早的验证系统关键功能。
（3）策略：
*确定功能的优先级别。
*分析优先级别最高的功能路径，把该路径上的所有模块集成到一起，必要时使用桩模块和单元模块。
*增加一个关键功能，继续上面一个步骤，直到所有模块都被集成到被测系统中。
（4）优点：
*采用该方法，可以尽快的看到关键功能的实现，并验证关键功能的正确性。
*由于该方法在验证某个功能的时候，可能会加入多个模块，因此在进度上，比自顶向下和自底向上还有三明治的集成策略要快一点。
*接口的覆盖使用的测试用例比较少。
*可以减少驱动模块的开发
（5）缺点：
*对于复杂的系统，功能之间的相互关联性可能是错综复杂并难以分析的。
*对有些接口的测试不充分，会丢失许多接口错误。
*一些初始的集成需要使用桩模块。
*可能会有比较大的冗余测试。
（6）适用范围：
*关键功能具有较大风险的产品。
*技术探索性的项目，其功能的实现远比质量更关键。
*对于功能的实现没有把握的产品。

基于进度的测试

（1）概念：进度压力在我们实际的工作中，每个软件开发项目都会遇到，。
为了完成进度，有可能会牺牲质量，基于进度的集成就是在兼顾质量和进度两者之间寻找了一个均衡点。
（2）目的：尽可能早的进行集成测试，提高开发与集成的并行性，有效的缩短进度。
（3）策略：这个集成的策略就是把最早可获得的代码拿来激励进行集成，必要的时候开发桩模块和驱动模块，子啊最大程度上保持与开发的并行性，从而缩短了项目集成的时间。
（4）优点：
*具有比较高的并行度。
*有效缩短项目开发的进度。
（5）缺点：
*可能最早拿到的模块之间缺乏整体性，只能进行独立的集成，导致许多接口必须等到后期才能验证，但此时系统可能已经很复杂，往往无法发现有效的接口问题。
*桩模块和驱动模块的工作量可能会变得很庞大。
*由于进度的原因，模块可能很不稳定且会不断变动，导致测试的重复和浪费。
（6）适用范围：进度优先级高于质量的项目。

集成测试策略

集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：
1、是采用何种系统组装方法来进行组装测试；
2、组装测试过程中连接各个模块的顺序；
3、模块代码编制和测试进度是否与组装测试的顺序一致
4、测试过程中是否需要专门的硬件设备；
解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应测试应安排在这些设备能够投入使用之时，并需要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。
单元测试后，有必要进行集成测试，发现并排除在模块连接中可能发生的上述问题，最终构成要求的软件子系统或系统。对子系统，集成测试也叫部件测试。
任何合理地组织集成测试，即选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号和测试的次序、生成测试用例和调试的费用。通常，有两种不同的组装方式：一次性组装方式和增值式组装方式。

集成测试完成标准

怎样判定集成测试过程完成了，可按以下几个方面检查：
1、成功地执行了测试计划中规定的所有集成测试；
2、修正了所发现的错误；
3、测试结果通过了专门小组的评审。
集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。
在完成预定的组装测试工作之后，测试小组应负责对测试结果进行整理、分析，

集成测试步骤：

准备集成测试计划。
准备集成测试场景和测试用例。
准备测试自动化脚本。
执行测试用例。
报告缺陷。
跟踪并重新测试缺陷。
重新测试和测试一直持续到集成测试完成。

集成测试过程
　　根据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、出口条件集成测试报告通过集成测试阶段基线评审。

测试集成方法

从根本上说，有两种方法可以进行测试集成：

1、自下而上的方法
2、自上而下的方法。
让我们考虑用下图来表述该测试方法：

自下而上的方法：

自下而上的测试，从应用程序的最低或最里面的单位开始，逐渐向上移动。集成测试从最低模块开始，逐步向应用程序的上层模块发展。这种集成一直持续到所有模块都集成在一起，整个应用程序作为一个单元进行测试。

在这种情况下，模块B1C1，B1C2和B2C1，B2C2是经过单元测试的最低模块。模块B1和B2尚未开发。模块B1和B2的功能是调用模块B1C1，B1C2和B2C1，B2C2。由于B1和B2还没有开发，我们需要一些程序或“刺激器”来调用B1C1，B1C2和B2C1，B2C2模块。这些刺激计划称为驱动程序。

简单来说，DRIVERS是虚拟程序，用于在调用函数不存在的情况下调用最低模块的函数。自底向上技术要求模块驱动程序将测试用例输入提供给被测模块的接口。

这种方法的优点是，如果在程序的最低单元存在重大故障，则更容易检测到它，并且可以采取纠正措施。

缺点是在最后一个模块被集成和测试之前，主程序实际上不存在。因此，只会在最后检测到更高级别的设计缺陷。

自上而下的方法：

该技术从最顶层的模块开始，逐渐向较低的模块发展。只有顶层模块是单独进行单元测试的。在此之后，下层模块逐个集成。重复该过程，直到所有模块都被集成和测试。

在我们的图中，测试从模块A开始，下层模块B1和B2逐个集成。现在，较低的模块B1和B2实际上不可用于集成。因此，为了测试最顶层的模块A，我们开发了“ STUBS ”。

“Stubs”可以称为代码片段，它接受来自顶层模块的输入/请求并返回结果/响应。这样，尽管模块较低，但是不存在，我们能够测试顶层模块。

在实际情况中，存根的行为并不像看起来那么简单。在这个复杂模块和体系结构的时代，被调用模块大多数时候都涉及复杂的业务逻辑，如连接数据库。因此，创建Stubs变得像真实模块一样复杂和耗时。在某些情况下，Stub模块可能会比受激模块更大。

Stub和驱动程序都是虚拟代码，用于测试“不存在”模块。它们触发函数/方法并返回响应，并将其与预期行为进行比较

让我们总结一下Stubs和Driver之间的一些区别：

唯一的变化是这个世界的常数，所以我们有另一种称为“ 三明治测试 ”的方法，它结合了自上而下和自下而上方法的特征。当我们测试像操作系统这样的大型程序时，我们必须拥有一些更有效的技术并增强信心。三明治测试在这里起着非常重要的作用，其中，自上而下和自下而上的测试同时开始。

集成从中间层开始，同时向上和向下移动。在我们的图中，我们的测试将从B1和B2开始，其中一个臂将测试上部模块A，另一个臂将测试下部模块B1C1，B1C2和B2C1，B2C2。

由于这两种方法同时开始，这种技术有点复杂，需要更多的人以及特定的技能组合，从而增加了成本。

GUI应用程序集成测试

现在让我们谈谈我们如何暗示黑盒技术中的集成测试。

我们都知道Web应用程序是一个多层应用程序。我们有一个可供用户看到的前端，我们有一个中间层，它有业务逻辑，我们有一些更多的中间层做一些验证，集成一些第三方API等，然后我们有后层，这是数据库。

集成测试示例：

我们来看看下面的例子：

我是一家广告公司的老板，我在不同的网站上发布广告。在本月底，我想看看有多少人看过我的广告以及有多少人点击了我的广告。我需要显示我的广告的报告，并相应地向我的客户收取费用。

GenNext软件为我和以下开发了这个产品的架构：

UI - 用户界面模块，对最终用户可见，其中给出了所有输入。
BL - 是业务逻辑模块，具有所有计算和业务特定方法。
VAL - 是Validation模块，它具有输入正确性的所有验证。
CNT - 具有所有静态内容的内容模块，特定于用户输入的输入。这些内容显示在报告中。
EN - 是Engine模块，该模块读取来自BL，VAL和CNT模块的所有数据，并提取SQL查询并将其触发到数据库。
Scheduler- 是否根据用户选择（每月，每季度，每半年和每年）安排所有报告的模块
DB - 是数据库。
现在，在看过整个Web应用程序的体系结构后，作为一个单元，在这种情况下，集成测试将关注模块之间的数据流。

这里的问题是：

1.BL，VAL和CNT模块如何读取和解释在UI模块中输入的数据？
2.BL，VAL和CNT模块是否从UI接收正确的数据？
3.BL，VAL和CNT的数据以哪种格式传输到EN模块？
4.EN如何读取数据并提取查询？
5.查询是否正确提取？
6.调度程序是否获得了正确的报告数据？
7.EN收到的结果集是否正确并且符合预期？
8.EN是否能够将响应发送回BL，VAL和CNT模块？
9.UI模块是否能够读取数据并将其适当地显示到界面？
在现实世界中，数据通信以XML格式完成。因此，无论用户在UI中输入什么数据，它都会转换为XML格式。

在我们的场景中，在UI模块中输入的数据被转换为XML文件，该文件由3个模块BL，VAL和CNT解释。EN模块读取由3个模块生成的结果XML文件，并从中提取SQL并查询到数据库中。EN模块还接收结果集并将其转换为XML文件并将其返回到UI模块，该模块以用户可读的形式转换结果并显示它。

在中间，我们有调度程序模块，它从EN模块接收结果集，创建和调度报告。

那么整合测试的确在哪里？

那么，测试信息/数据是否正确流动将是您的集成测试，在这种情况下将验证XML文件。XML文件是否正确生成？他们有正确的数据吗？数据是否正确地从一个模块传输到另一个模块？所有这些都将作为集成测试的一部分进行测试。

尝试生成或获取XML文件并更新标记并检查行为。这与测试人员通常所做的常规测试非常不同，但这将为测试人员的知识和对应用程序的理解增加价值。

其他几个样本测试条件可能如下：

菜单选项是否生成正确的窗口？
窗户是否能够调用被测窗口？
对于每个窗口，标识应用程序应允许的窗口的函数调用。
识别从窗口到应用程序应允许的其他功能的所有调用
识别可逆调用：关闭被调用窗口应返回调用窗口。
识别不可逆转的呼叫：在出现被叫窗口之前调用窗口关闭。
测试执行对另一个窗口的调用的不同方式，例如 - 菜单，按钮，关键字。

启动集成测试的步骤

了解应用程序的体系结构。
确定模块
了解每个模块的功能
了解数据如何从一个模块传输到另一个模块。
了解数据如何输入和接收到系统中（应用程序的入口点和出口点）
隔离应用程序以满足您的测试需求。
确定并创建测试条件
一次采取一个条件并记下测试用例。

集成测试的进入/退出标准

进入标准

集成测试计划文档已签署并批准。
已经准备好集成测试用例。
测试数据已创建。
开发的模块/组件的单元测试已完成。
所有关键和高优先级缺陷都已关闭。
测试环境设置为集成。

退出标准

所有集成测试用例都已执行。
没有关键和优先级P1和P2缺陷被打开。
测试报告已经准备好了。

集成测试用例

集成测试案例主要关注模块之间的接口，集成链接，模块之间的数据传输，作为已经过单元测试的模块/组件，即功能和其他测试方面已经涵盖。

因此，主要思想是测试集成时两个工作模块的集成是否按预期工作。

对于示例集成Linkedin应用程序的测试用例包括：

验证登录页面和主页之间的接口链接，即当用户输入凭证并记录时，应将其定向到主页。
验证主页和配置文件页面之间的接口链接，即配置文件页面应该打开。
验证网络页面和连接页面之间的接口链接，即单击网络邀请页面上的接受按钮，一旦点击，就会在连接页面中显示接受的邀请。
验证通知页面之间的界面链接并说出恭喜按钮，即单击说恭喜按钮应指向新的消息窗口。
可以为此特定站点编写许多集成测试用例。以上四点只是了解测试中包含哪些Integration测试用例的一个示例

集成是白盒还是黑盒技术？

集成测试技术可以在黑盒子和白盒技术中统计。黑盒技术是测试人员不需要任何系统内部知识的地方，即不需要编码知识，而白盒技术需要应用程序的内部知识。

现在，在执行集成测试时，它可能包括测试两个集成Web服务，这些服务将从数据库中获取数据并根据需要提供数据，这意味着可以使用白盒测试技术进行测试，而可以测试在网站中集成新功能使用黑匣子技术。

因此，集成测试不是黑盒子或白盒技术。

集成测试工具

有几种工具可用于此测试。

以下是工具列表：

Rational Integration Tester
TESSY
Protractor
Steam

系统集成测试

系统集成测试用于测试完整的集成系统。
在集成组件之前，模块或组件在单元测试中单独测试。
一旦测试了所有模块，就可以通过集成所有模块来完成系统集成测试，并对整个系统进行测试。

集成测试和系统测试之间的区别

集成测试是一种测试，其中集成了一个或两个经过单元测试的模块进行测试和验证，以验证集成模块是否按预期工作。
系统测试是对整个系统进行测试的测试，即所有模块/组件都集成在一起，以验证系统是否按预期工作，并且由于集成模块而不会出现问题。

结论

这是关于集成测试及其在白盒和黑盒技术中的实现。希望我们用相关的例子清楚地解释它。

测试集成是测试周期的一个重要部分，因为它可以在集成两个或多个模块时更容易找到缺陷，以便在第一步中将所有模块集成在一起。

它有助于在早期发现缺陷，从而节省了工作量和成本。它确保集成模块按预期正常工作。