集成测试_集成测试模板 - CSDN
集成测试 订阅
集成测试,也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求(如根据结构图)组装成为子系统或系统,进行集成测试。 [1]  实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题,在全局上很可能暴露出来。 展开全文
集成测试,也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求(如根据结构图)组装成为子系统或系统,进行集成测试。 [1]  实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题,在全局上很可能暴露出来。
信息
常用方案选型
综述 自顶向下测试 自底向上测试
计划书
引言 测试项目 被测特性
概    述
也叫组装测试或联合测试
中文名
集成测试
简    介
集成测试测试组合单元时出现问题
步    骤
集成测试过程 需求工作机制
集成测试简介
[2]  集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它最简单的形式是:把两个已经测试过的单元组合成一个组件,测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合为程序的更大部分。方法是测试片段的组合,并最终扩展成进程,将模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。此外,如果程序由多个进程组成,应该成对测试它们,而不是同时测试所有进程。集成测试测试组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力的测试计划,可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。一个有效的集成测试有助于解决相关的软件与其它系统的兼容性和可操作性的问题。集成测试是在单元测试的基础上,测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说,在集成测试之前,单元测试应该已经完成,集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要,因为如果不经过单元测试,那么集成测试的效果将会受到很大影响,并且会大幅增加软件单元代码纠错的代价。集成测试是单元测试的逻辑扩展。在现实方案中,集成是指多个单元的聚合,许多单元组合成模块,而这些模块又聚合成程序的更大部分,如分系统或系统。集成测试采用的方法是测试软件单元的组合能否正常工作,以及与其他组的模块能否集成起来工作。最后,还要测试构成系统的所有模块组合能否正常工作。集成测试所持的主要标准是《软件概要设计规格说明》,任何不符合该说明的程序模块行为都应该加以记载并上报。所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式,具体的开发工作总得从一个一个的软件单元做起,软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成,总是会出现一些常见问题,工程实践中 ,几乎不存在软件单元组装过程中不出任何问题的情况。从图1可以看出,集成测试需要花费的时间远远超过单元测试,直接从单元测试过渡到系统测试是极不妥当的做法。
收起全文
  • 集成测试

    千次阅读 2018-04-20 17:37:31
    什么是集成测试  集成测试是指在单元测试的基础上,将所有模块按照设计要求组装成为子系统或系统,进行测试。  集成测试最简单的形式是:把两个已经测试过的单元组合成一个组件,测试它们之间的接口。从这...

    什么是集成测试

      集成测试是指在单元测试的基础上,将所有模块按照设计要求组装成为子系统或系统,进行测试。

      集成测试最简单的形式是:把两个已经测试过的单元组合成一个组件,测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合为程序的更大部分。方法是测试片段的组合,并最终扩展成进程,将模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。此外,如果程序由多个进程组成,应该成对测试它们,而不是同时测试所有进程。

      集成测试测试组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力测试计划,可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。一个有效的集成测试有助于解决相关的软件与其它系统的兼容性和可操作性的问题。

      集成测试是在单元测试的基础上,测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说,在集成测试之前,单元测试应该已经完成,集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要,因为如果不经过单元测试,那么集成测试的效果将会受到很大影响,并且会大幅增加软件单元代码纠错的代价。

      集成测试是单元测试的逻辑扩展。在现实方案中,集成是指多个单元的聚合,许多单元组合成模块,而这些模块又聚合成程序的更大部分,如分系统或系统。集成测试采用的方法是测试软件单元的组合能否正常工作,以及与其他组的模块能否集成起来工作。最后,还要测试构成系统的所有模块组合能否正常工作。集成测试所持的主要标准是《软件概要设计规格说明》,任何不符合该说明的程序模块行为都应该加以记载并上报。

      所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式,具体的开发工作总得从一个一个的软件单元做起,软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成,总是会出现一些常见问题,工程实践中,几乎不存在软件单元组装过程中不出任何问题的情况。从表中可以看出,集成测试需要花费的时间远远超过单元测试,直接从单元测试过渡到系统测试是极不妥当的做法。

    活动 输入 输出 参与角色和职责
    制定集成测试计划 设计模型
    设计模型
    集成测试用例
    测试过程
    测试设计员负责设计集成测试用例和测试过程
    实施集成测试 集成测试用例
    测试过程
    工作版本
    测试脚本(可选)
    测试过程(更新)
    测试设计员负责编制测试脚本(可选),更新测试过程。
    驱动程序或稳定桩 设计员负责设计驱动程序和装,实施员负责实施驱动程序和桩
    执行集成测试 测试脚本(可选)
    工作版本
    测试结果 测试员负责执行测试并记录测试结果
    评估集成测试 集成测试计划
    测试结果
    测试评估摘要 测试员负责会同及成员、编码员、设计员等有关人员(具体化)评估此次测试,并生成测试评估摘要。

    集成测试的目标

      集成测试的目标是按照设计要求使用那些通过单元测试的构件来构造程序结构。单个模块具有高质量但不足以保证整个系统的质量。有许多隐蔽的失效是高质量模块间发生非预期交互而产生的。以下两种测试技术是用于集成测试:

      1、功能性测试。使用黑盒测试技术针对被测模块的接口规格说明进行测试。

      2、非功能性测试。对模块的性能或可靠性进行测试。

      另外,集成测试的必要性还在于一些模块虽然能够单独地工作,但并不能保证连接起来也能正常工作。程序在某些局部反映不出来的问题,有可能在全局上会暴露出来,影响功能的实现。此外,在某些开发模式中,如迭代式开发,设计和实现是迭代进行的。在这种情况下,集成测试的意义还在于它能间接地验证概要设计是否具有可行性。

    集成测试应考虑问题

      1、在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;

      2、各个子功能组合起来,能否达到预期要求的父功能;

      3、一个模块的功能是否会对另一个模块的功能产生不利的影响;

      4、全局数据结构是否有问题;

      5、是采用何种系统组装方法来进行组装测试;

      6、组装测试过程中连接各个模块的顺序;

      7、模块代码编制和测试进度是否与组装测试的顺序一致;

      8、测试过程中是否需要专门的硬件设备;

      9、单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。

      因此,单元测试后,有必要进行集成测试,发现并排除在模块连接中可能发生的上述问题,最终构成要求的软件子系统或系统。对子系统,集成测试也叫部件测试。

      任何合理地组织集成测试,即选择什么方式把模块组装起来形成一个可运行的系统,直接影响到模块测试用例的形式、所用测试工具的类型、模块编号和测试的次序、生成测试用例和调试的费用。通常,有两种不同的组装方式:一次性组装方式和增值式组装方式。

    集成测试过程

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

    集成测试的实施方案

      集成测试的实施方案有很多种,如自底向上集成测试、自顶向下集成测试、Big-Bang集成测试、三明治集成测试、核心集成测试、分层集成测试、基于使用的集成测试等。常见的有:

    自顶向下测试

      自顶向下集成(Top-Down Integration)方式是一个递增的组装软件结构的方法。从主控模块(主程序)开始沿控制层向下移动,把模块一一组合起来。分两种方法:

      第一:先深度:按照结构,用一条主控制路径将所有模块组合起来;

      第二:先宽度:逐层组合所有下属模块,在每一层水平地沿着移动。

      组装过程分以下五个步骤:

      步骤一:用主控模块作为测试驱动程序,其直接下属模块用承接模块来代替;

      步骤二:根据所选择的集成测试法(先深度或先宽度),每次用实际模块代替下属的承接模块

      步骤三:在组合每个实际模块时都要进行测试;

      步骤四:完成一组测试后再用一个实际模块代替另一个承接模块;

      步骤五:可以进行回归测试(即重新再做所有的或者部分已做过的测试),以保证不引入新的错误。

    自底向上测试

      自底向上的集成(Bottom-Up Integration)方式是最常使用的方法。其他集成方法都或多或少地继承、吸收了这种集成方式的思想。自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。因为模块是自底向上进行组装的,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)事前已经完成组装并经过测试,所以不再需要编制桩模块(一种能模拟真实模块,给待测模块提供调用接口或数据的测试用软件模块)。自底向上集成测试的步骤大致如下:

      步骤一: 按照概要设计规格说明,明确有哪些被测模块。在熟悉被测模块性质的基础上对被测模块进行分层,在同一层次上的测试可以并行进行,然后排出测试活动的先后关系,制定测试进度计划。图2给出了自底向上的集成测试过程中各测试活动的拓扑关系。利用图论的相关知识,可以排出各活动之间的时间序列关系,处于同一层次的测试活动可以同时进行,而不会相互影响。

      步骤二: 在步骤一的基础上,按时间线序关系,将软件单元集成为模块,并测试在集成过程中出现的问题。这里,可能需要测试人员开发一些驱动模块来驱动集成活动中形成的被测模块。对于比较大的模块,可以先将其中的某几个软件单元集成为子模块,然后再集成为一个较大的模块。

      步骤三: 将各软件模块集成为子系统(或分系统)。检测各自子系统是否能正常工作。同样,可能需要测试人员开发少量的驱动模块来驱动被测子系统。

      步骤四: 将各子系统集成为最终用户系统,测试是否存在各分系统能否在最终用户系统中正常工作。

      方案点评: 自底向上的集成测试方案是工程实践中最常用的测试方法。相关技术也较为成熟。它的优点很明显: 管理方便、测试人员能较好地锁定软件故障所在位置。但它对于某些开发模式不适用,如使用XP开发方法,它会要求测试人员在全部软件单元实现之前完成核心软件部件的集成测试。尽管如此,自底向上的集成测试方法仍不失为一个可供参考的集成测试方案。

    核心系统测试

      核心系统先行集成测试法的思想是先对核心软件部件进行集成测试,在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。每次加入一个外围软件部件都产生一个产品基线,直至最后形成稳定的软件产品。核心系统先行集成测试法对应的集成过程是一个逐渐趋于闭合的螺旋形曲线,代表产品逐步定型的过程。其步骤如下:

      步骤一: 对核心系统中的每个模块进行单独的、充分的测试,必要时使用驱动模块和桩模块;

      步骤二: 对于核心系统中的所有模块一次性集合到被测系统中,解决集成中出现的各类问题。在核心系统规模相对较大的情况下,也可以按照自底向上的步骤,集成核心系统的各组成模块。

      步骤三: 按照各外围软件部件的重要程度以及模块间的相互制约关系,拟定外围软件部件集成到核心系统中的顺序方案。方案经评审以后,即可进行外围软件部件的集成。

      步骤四: 在外围软件部件添加到核心系统以前,外围软件部件应先完成内部的模块级集成测试。

      步骤五: 按顺序不断加入外围软件部件,排除外围软件部件集成中出现的问题,形成最终的用户系统。

      方案点评: 该集成测试方法对于快速软件开发很有效果,适合较复杂系统的集成测试,能保证一些重要的功能和服务的实现。缺点是采用此法的系统一般应能明确区分核心软件部件和外围软件部件,核心软件部件应具有较高的耦合度,外围软件部件内部也应具有较高的耦合度,但各外围软件部件之间应具有较低的耦合度。

    高频集成测试

      高频集成测试是指同步于软件开发过程,每隔一段时间对开发团队的现有代码进行一次集成测试。如某些自动化集成测试工具能实现每日深夜对开发团队的现有代码进行一次集成测试,然后将测试结果发到各开发人员的电子邮箱中。该集成测试方法频繁地将新代码加入到一个已经稳定的基线中,以免集成故障难以发现,同时控制可能出现的基线偏差。使用高频集成测试需要具备一定的条件: 可以持续获得一个稳定的增量,并且该增量内部已被验证没有问题; 大部分有意义的功能增加可以在一个相对稳定的时间间隔(如每个工作日)内获得; 测试包和代码的开发工作必须是并行进行的,并且需要版本控制工具来保证始终维护的是测试脚本和代码的最新版本; 必须借助于使用自动化工具来完成。高频集成一个显著的特点就是集成次数频繁,显然,人工的方法是不胜任的。

      高频集成测试一般采用如下步骤来完成:

      步骤一: 选择集成测试自动化工具。如很多Java项目采用Junit+Ant方案来实现集成测试的自动化,也有一些商业集成测试工具可供选择。

      步骤二: 设置版本控制工具,以确保集成测试自动化工具所获得的版本是最新版本。如使用CVS进行版本控制。

      步骤三: 测试人员和开发人员负责编写对应程序代码的测试脚本。

      步骤四: 设置自动化集成测试工具,每隔一段时间对配置管理库的新添加的代码进行自动化的集成测试,并将测试报告汇报给开发人员和测试人员。

      步骤五: 测试人员监督代码开发人员及时关闭不合格项。

      按照步骤三至步骤五不断循环,直至形成最终软件产品。

      方案点评: 该测试方案能在开发过程中及时发现代码错误,能直观地看到开发团队的有效工程进度。在此方案中,开发维护源代码与开发维护软件测试包被赋予了同等的重要性,这对有效防止错误、及时纠正错误都很有帮助。该方案的缺点在于测试包有时候可能不能暴露深层次的编码错误和图形界面错误。

    文件转载来自:http://wiki.mbalib.com/wiki/%E9%9B%86%E6%88%90%E6%B5%8B%E8%AF%95

    展开全文
  • 软件测试一般分为4个阶段:单元测试、集成测试、系统测试、验收测试。 一、单元测试  单元测试是对软件中的最小可验证单元进行检查和验证。比如对Java中的类和方法的测试。 测试原则:  1、尽可能保证测试...

    软件测试的对象包括软件需求、概要设计、详细设计、软件运行环境、可运行程序和软件源代码等。软件测试包括质量、人员、资源、技术和流程五大要素,以及测试覆盖率和测试效率两个目标。

    软件测试一般分为4个阶段:单元测试、集成测试、系统测试、验收测试。

    一、单元测试 
    单元测试是对软件中的最小可验证单元进行检查和验证。比如对Java中的类和方法的测试。

    测试原则: 
    1、尽可能保证测试用例相互独立(测试用例中不能直接调用其他类的方法,而应在测试用例中重写模拟方法); 
    2、此阶段一般由软件的开发人员来实施,用以检验所开发的代码功能符合自己的设计要求。

    单元测试的好处: 
    1、尽早的发现缺陷; 
    2、利于重构; 
    3、简化集成; 
    4、文档; 
    5、用于设计。

    单元测试的不足: 
    1、不可能覆盖所有的执行路径,所以不可能保证捕捉到所有路径的错误; 
    2、每行代码需要3~5行代码进行单元测试,存在投入与产出的平衡。

    二、集成测试 
    集成测试是在单元测试的基础上,把软件单元按照软件概要设计规格说明的规格要求,组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求。

    集成测试包括BigBang、自顶向下、自底向上、核心系统集成、高频集成。

    三、系统测试 
    将经过集成测试的软件,作为计算机系统的一部分,与系统中其他部分结合起来,在实际运行环境下进行一系列严格有效的测试,以发现软件潜在的问题,保证系统的正常运行。

    集成测试和系统测试之间的比较: 
    1、测试内容:集成测试是测试各个单元模块之间的接口,系统测试是测试整个系统的功能和性能; 
    2、测试角度:集成测试偏重于技术的角度进行测试,系统测试是偏重于业务的角度进行测试。

    四、验收测试 
    也称交付测试,是针对用户需求、业务流程进行的正式的测试,以确定系统是否满足验收标准,由用户、客户或其他授权机构决定是否接受系统。

    验收测试包括alpha测试和beta测试,alpha测试是由开发者进行的软件测试,beta测试是由用户在脱离开发环境下进行的软件测试。

    展开全文
  • 集成测试是为了在集成时测试模块/组件,以验证它们是否按预期工作,即测试单独工作的模块在集成时没有问题。 在使用黑盒测试技术测试大型应用程序时,涉及多个彼此紧密耦合的模块的组合。我们可以应用集成测试技术...

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

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

    什么是集成测试?

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

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

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

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

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

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

    为何进行集成测试

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

    以下是一些原因:

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

    好处

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

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

    挑战

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

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

    为了最大限度地减少开发系统时的影响,应该考虑很少的事情,例如可能与其他系统集成等。

    集成测试的类型

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

    大爆炸方法:

    Big bang方法一次性集成了所有模块,即它不会逐个集成模块。它会在集成后验证系统是否按预期工作。如果在完全集成的模块中检测到任何问题,则很难找出导致该问题的模块。

    大爆炸方法是一个耗时的过程,找到一个自身有缺陷的模块,因为这需要时间,一旦检测到缺陷,修复相同的方法会花费很高,因为在后期检测到缺陷。

    大爆炸方法的优点:

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

    大爆炸方法的缺点:

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

    集成测试步骤:

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

    测试集成方法

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

    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之间的一些区别:

    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的数据以哪种格式传输到EQ模块?
    4. EQ如何读取数据并提取查询?
    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文件并更新标记并检查行为。这与测试人员通常所做的常规测试非常不同,但这将为测试人员的知识和对应用程序的理解增加价值。

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

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

    启动集成测试的步骤

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

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

    进入标准

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

    退出标准:

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

    集成测试用例

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

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

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

    • 验证登录页面和主页之间的接口链接,即当用户输入凭证并记录时,应将其定向到主页。
    • 验证主页和配置文件页面之间的接口链接,即配置文件页面应该打开。
    • 验证网络页面和连接页面之间的接口链接,即单击网络邀请页面上的接受按钮,一旦点击,就会在连接页面中显示接受的邀请。
    • 验证通知页面之间的界面链接并说出恭喜按钮,即单击说恭喜按钮应指向新的消息窗口。

    可以为此特定站点编写许多集成测试用例。以上四点只是了解测试中包含哪些Integration测试用例的一个示例。

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

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

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

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

    集成测试工具

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

    以下是工具列表:

    • Rational Integration Tester
    • TESSY
    • Protractor
    • Steam

    系统集成测试

    系统集成测试用于测试完整的集成系统。

    在集成组件之前,模块或组件在单元测试中单独测试。

    一旦测试了所有模块,就可以通过集成所有模块来完成系统集成测试,并对整个系统进行测试。

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

    集成测试是一种测试,其中集成了一个或两个经过单元测试的模块进行测试和验证,以验证集成模块是否按预期工作。

    系统测试是对整个系统进行测试的测试,即所有模块/组件都集成在一起,以验证系统是否按预期工作,并且由于集成模块而不会出现问题。

    结论

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

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

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

    转载于:https://my.oschina.net/hechunc/blog/3031766

    展开全文
  • 软件测试类型——集成测试

    千次阅读 2018-07-06 10:58:11
    简介 集成测试(Integration Testing),也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求(如根据结构图)组装成为子系统或系统,进行集成测试。 集成测试(也叫组装测试,联合测试)是单元...

    简介

            集成测试(Integration Testing),也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求(如根据结构图)组装成为子系统或系统,进行集成测试。
            集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它最简单的形式是:把两个已经测试过的单元组合成一个组件,测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合为程序的更大部分。方法是测试片段的组合,并最终扩展成进程,将模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。此外,如果程序由多个进程组成,应该成对测试它们,而不是同时测试所有进程。
            集成测试是在单元测试的基础上,测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说,在集成测试之前,单元测试应该已经完成,集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要,因为如果不经过单元测试,那么集成测试的效果将会受到很大影响,并且会大幅增加软件单元代码纠错的代价。
            所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式,具体的开发工作总得从一个一个的软件单元做起,软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成,总是会出现一些常见问题,工程实践中,几乎不存在软件单元组装过程中不出任何问题的情况。从集成测试需要花费的时间远远超过单元测试,直接从单元测试过渡到系统测试是极不妥当的做法。

    测试关注的重点

            一些模块虽然能够单独工作,但并不能保证连接起来也能正常的工作,程序在某些局部反映不出来的问题,在全局上很可能暴漏出来,影响功能的实现,因此集成测试应当考虑两大(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)  

     大爆炸集成(Big Bang Integration)

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

    自顶向下集成(Top-Down Integration)

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

    自底向上集成(Bottom-up Integration)

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

    三明治集成(Sandwich Integration)

            由于自顶向下集成策略和自底向上集成策略都有各自的缺点,所以就出现了一种结合这两种测试策略的集成方式,即:三明治集成。

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

    基干集成(Backbone Integration)

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

    分层集成(Layers Integration)

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

    基于功能的集成(Function-Based Integration)

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

    基于进度的集成(Schedule-Based Integration)

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

    集成测试策略

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

    集成测试完成标准

            怎样判定集成测试过程完成了,可按以下几个方面检查:
            1、成功地执行了测试计划中规定的所有集成测试;
            2、修正了所发现的错误;
            3、测试结果通过了专门小组的评审。
            集成测试应由专门的测试小组来进行,测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。
            在完成预定的组装测试工作之后,测试小组应负责对测试结果进行整理、分析,形成测试报告。测试报告中要记录实际的测试结果、在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出不能解决、还需要管理人员和开发人员注意的一些问题,提供测试评审和最终决策,以提出处理意见。



    展开全文
  • 集成测试怎么做?

    万次阅读 2017-09-18 15:20:15
    集成测试:是在单元测试的基础上,将所有模块按照设计要求组装成子系统或系统进行的测试活动。  2】.集成测试的两种集成模式:非渐增式集成渐增式集成:自顶向下集成,自底向上集成。  3】.对面向过程的系统...
  • 8-1 集成测试

    千次阅读 2019-04-11 15:41:10
    1.什么是集成测试(integration testing) 集成测试就是在单元测试的基础上,将所有已通过单元测试的模块按照概要设计的要求组装为子系统或系统,并进行测试的过程,目的是确保各单元模块组合在一起后能够按既定意图...
  • 单元测试与集成测试

    千次阅读 2019-10-06 22:42:02
    按测试策略和过程,软件测试分为单元测试、集成测试、确认测试和系统测试。 按软件系统工程,测试是软件质量保证的最后的一关。 高质量的程序取决于以下几个方面: 高质量的设计 规范的编码 有效的测试 开发部...
  • 下面,结合CI和CD两种不同软件生产实践,总结一下如何从零开始部署一套web集成测试环境。 1.服务器准备。根据项目和使用的中间件的规模,准备好一个或多个资源配置能够满足要求的服务器,一般选用linux下 centos的...
  • 从系统上来说,软件测试的方法主要包括单元测试,集成测试,系统测试,确认测试。(重点说单元测试和集成测试) 单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否...
  • 方案:软件集成测试工作流程指南

    千次阅读 2018-08-06 11:53:14
    软件集成测试工作流程指南 编者说明:  严格地说,该文档不属于文档模板,它只是一个工作指南。要想更好地完成集成测试工作,你就需要为团队制定一个工作指南。你可以根据该文档,结合实际进行修改。 1. 简介 ...
  • 怎么安排集成测试工作

    千次阅读 2017-11-28 22:36:40
    怎么安排集成测试工作敏捷是没有集成测试环节的,但大部门要求停下新功能开发,做两周的集成测试,所以,这个冲刺我们也没有安排开发任务。以往集成测试怎么搞?按照以往的经验,全员测试,从集成测试开始,每人每天...
  • 系统测试和集成测试的区别

    千次阅读 2017-04-06 11:43:11
    系统测试最主要的就是功能测试,测试软件... 集成测试在系统测试之前,单元测试完成之后系统集成的时候进行测试。 主要是针对程序内部结构进行测试,特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚
  • 软件测试-集成测试方法

    千次阅读 2013-07-18 23:26:31
    我想说起集成测试来大家一定都不陌生,但是如果说起集成测试的具体测试方法大家有几个了解呢,那我来介绍一下有关集成测试的方法,希望对新手有所帮助  集成测试是单元测试的逻辑扩展。它的最简单的形式是:两个...
  • 集成测试的策略详解:

    千次阅读 2019-07-08 08:17:48
    集成测试的基础策略有很多,通常分为两种:非增量式集成测试策略和增量式集成测试策略 第一种:非增量式集成测试策略 非增量式集成测试策略也叫做大爆炸集成、一次性集成; 即在最短的时间内把所有的系统组件一次...
  • 从整体的角度可以分为单元测试、集成测试、系统测试、确认测试。 下面内容来自网络相关资料的整理: 1.单元测试 (1)定义:单元测试(又称为模块测试)是针对程序模块(软件设计的最小单位)来进行正确性检验...
  • 单元测试和集成测试

    千次阅读 2018-01-12 19:47:17
    单元测试  单元测试是在软件开发过程中要进行的最低级别的测试活动,针对软件设计的最小单元——模块。 ...集成测试对象是概要设计规划中的模块及模块间的组合。测试方法不同。单元测试中的主要
  • 集成测试基本内容概述

    万次阅读 2017-07-10 10:27:48
    1、概述若每个模块都经过了严格的单元测试,还需要继承测试吗?人们常常会提出这样的疑问。回答是肯定的,确实需要集成测试。在测试过程中经常遇到的情况是:单元测试中每个模块都能...2、集成测试的定义:集成测试就是
  • 集成测试的分析:

    千次阅读 2019-07-08 08:39:01
    集成测试想要做好,分析工作一定要做好。 更好的分析能够帮助我们更好的设计测试用例,集成测试分析在整个集成测试中占据最关键的地位。 集成测试分析要考虑以下几个方面: 1.体系结构分析 第一个角度:从实际...
  • 非增量式集成与增量式集成测试(自顶向下、自底向上和三明治集成测试) ** 增量式集成 增量式集成测试是逐步集成和逐步测试的方法,把可能出现的错误分散暴露出来,便于找出问题和修改 优点 更早地发现模块间的接口...
1 2 3 4 5 ... 20
收藏数 523,856
精华内容 209,542
关键字:

集成测试