集成测试的组成以及流程

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

      集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。

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

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

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

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

      集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。使用黑盒测试方法测试集成的功能。并且对以前的集成进行回归测试。

一、集成测试过程

二、单元测试工作内容及其流程

三、集成测试需求获取

      集成测试需求所确定的是对某一集成工作版本的测试的内容，即测试的具体对象。集成测试需求主要来源于设计模型（DESign Model）和集成构件计划（Integration Build Plan）。集成测试着重于集成版本的外部接口的行为。因此，测试需求须具有可观测、可测评性。

      1． 集成工作版本应分析其类协作与消息序列，从而找出该工作版本的外部接口。

      2． 由集成工作版本的外部接口确定集成测试用例。

3． 测试用例应覆盖工作版本每一外部接口的所有消息流序列。

     注意：一个外部接口和测试用例的关系是多对多，部分集成工作版本的测试需求可映射到系统测试需求，因此对这些集成测试用例可采用重用系统测试用例技术。

四、集成测试工作机制

      软件集成测试工作由产品评测部担任。需要项目组相关角色配合完成。如图示：

      软件评测部：

      软件项目组：

      集成测试工作内容及其流程工作流程：

五、集成测试产生的工件清单

      1、 软件集成测试计划
      2、 集成测试用例
      3、 测试过程
      4、 测试脚本
      5、 测试日志
      6、 测试评估摘要

六、集成测试常用方案选型

      集成测试的实施方案有很多种，如自底向上集成测试、自顶向下集成测试、BIg-Bang集成测试、三明治集成测试、核心集成测试、分层集成测试、基于使用的集成测试等。在此，笔者将重点讨论其中一些经实践检验和一些证实有效的集成测试方案。

      ·自底向上集成测试

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

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

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

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

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

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

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

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

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

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

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

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

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

      ·高频集成测试

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

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

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

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

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

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

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

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

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

以上我们介绍了几种常见的集成测试方案，一般来讲，在现代复杂软件项目集成测试过程中，通常采用核心系统先行集成测试和高频集成测试相结合的方式进行，自底向上的集成测试方案在采用传统瀑布式开发模式的软件项目集成过程中较为常见。读者应该结合项目的实际工程环境及各测试方案适用的范围进行合理的选型。

附：集成测试计划书 模版

原创作者：jerry
转载请注明：来自SAwin系统分析之窗
最后修改时间：2005-4-27

1引言
1.1编写目的
本文是描述****集成测试的大纲文章，主要描述如何进行集成测试活动？如何控制集成测试活动？集成测试活动的流程以及集成测试活动的工作安排。本文主要的读者对象是项目负责人，集成部门经理，集成测试设计师。
1.2背景
项目名称：***集成测试
项目相关对象：******************
1.3定义
**********：********************
1.4参考资料
《*********》
2测试项目
本测试主要为***系统的集成测试，目前***的版本为2.0,测试是***的最终集成测试，是建立在开发组程序员开发完毕自己的测试以及开发组测试的基础之上
3 被测特性
3.1操作性测试
主要测试操作是否正确，有无误差？分为两部分：
3.1.1返回测试
由主界面逐级进入最终界面，按EXIT键逐级返回，检查返回时候屏幕聚焦是否正确
比如：
1. 进入“系统设置”
2. 进入“频道搜索”
3. 进入“自动频道搜索”
4. 按EXIT键返回，检查当前聚焦是否为“频道搜索”
5. 按EXIT键返回，检查当前聚焦是否为“系统设置”
3.1.2进入测试
由主界面逐级进入最终界面，按MENU键返回主界面，再次进入，检查是否聚焦正确
比如：
1. 进入“系统设置”
2. 进入“频道搜索”
3. 进入“自动频道搜索”
4. 按MENU键返回主界面
5. 当前聚焦是否为“系统设置”
6. 进入“系统设置”，当前聚焦是否为“频道搜索”
3.2功能测试
测试机顶盒中每个应用的功能是否正确
3.3性能测试
3.3.1疲劳性测试
测试连续开机1个月不关机器，每3天去运行一次应用。看系统的稳定性
3.3.2大容量数据测试
前段***数据库表中含有大量数据，测试***功能
4 不被测特性
5 测试方法
1. 书写测试计划
2. 审核测试计划，未通过返回第一步
3. 书写测试用例；
4. 审核测试用例，未通过返回第三步
5. 测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上；（测试报告必须覆盖所有测试用例）
6. 测试过程中发现bug，将bug填写在bugzilla上发给集成部经理；（bug状态NEW）
7. 集成部经理接到bugzilla发过来的bug
7.1 对于明显的并且可以立刻解决的bug，将bug发给开发人员；（bug状态ASSIGNED）;
7.2 对于不是bug 查看(825) 评论(0) 收藏 分享 管理

然后从划分出的等价类中按以下三个原则设计测试用例:

      ①为每一个等价类规定一个唯一的编号.

      ②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.

      ③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.

边界值分析法

      边界值分析方法是对等价类划分方法的补充.

（1）边界值分析方法的考虑:

      长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

（2）基于边界值分析方法选择测试用例的原则:

      1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.

      2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.

      3）根据规格说明的每个输出条件,使用前面的原则1）.

      4）根据规格说明的每个输出条件,应用前面的原则2）.

      5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.

      6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.

      7）分析规格说明,找出其它可能的边界条件.

错误推测法

      错误推测法: 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

      错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

因果图方法

      前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.

      因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

      利用因果图生成测试用例的基本步骤:

      (1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.

(2) 分析软件规格说明描述中的语义.找出原因与结果之间 查看(629) 评论(0) 收藏 分享 管理

缺陷管理

软件存在缺陷，但是如何有效的管理缺陷是软件能不能正常提交的一个保障，这里引入缺陷管理的一些概念和方法。

1，概念

• 缺陷生命周期

缺陷管理需要遵循一个流程，也就是缺陷的生命周期。粗略的划分，缺陷的生存周期可以分为这么一些阶段，

缺陷汇报（submitted）

缺陷确认（accepted）（TobeCorrected）

缺陷修改（Corrected）

缺陷修改确认（Validated）

不是问题（not a problem）

此外，有一些附加状态，比如，暂不修改（derogation），继承（inherit）

• 缺陷级别

缺陷级别也是个很重要的概念，同时存在两种级别，一种是从测试人员角度定义的级别，另一种是从开发人员角度定义的级别，两种级别在大多数时候都是一致的。简单来讲，缺陷级别可以分为以下几种：

非常低（very low）

低 (low)

重要(important)

非常重要(severe)

同时，由于产品的决策或者设计问题，有的缺陷也会以一种建议的方式出现，这个时候，也许所汇报的缺陷根本就不是缺陷，而更多的是对于产品能够更加友好的一种建议。

2，缺陷在项目和产品当中的管理异同

由于项目和产品在用户影响方面的差异，缺陷也会在其中表现出一些不同的地方，比如说，在产品当中，用户友好性差一点，可以被当成一种建议来做，但是在项目当中，这个就成为了一种缺陷，有的时候甚至是很严重的缺陷。那么总体来讲，有那么一些不同。

• 级别定义不同
• 确认方式不同（产品修改确认需要的是一个官方的发布版本，但是项目的确认方式也许就是一个补丁）
• 修改方式不同（项目的缺陷无沦巨细，都是需要在提交给用户之前修改的，但是产品的缺陷却可以延迟到下一个版本）
• 缺陷转换（缺陷是可以由项目转换到产品，然后由产品统一控制，管理的，因为项目组的侧重点和产品组的侧重点是不一样的，很多问题在项目当中出现，但是项目组没有能力修改，那么就需要产品组予以帮助）

3，却陷管理工具

缺陷需要管理，但是如果单纯的靠纸和笔进行管理，显然是不能够满足需要的，简单来讲，却陷管理工具至少能够满足以下特点，

• 以项目为基础的管理方式
• 严格的用户权限管理（不同的角色应该具备不同的权限）
• Email通知机制（当状态改变以后，相关人员能够被通知到）
• 从不同的维度进行缺陷的统计
• 全方位的缺陷查询
• 项目缺陷级别可定义
• 软件模块定义

现在，有很多业界比较认可的缺陷管理工具，包括Test Director, ClearQuest等等，免费的工具有Bugzilla也很好。不妨下载一个使用版本来玩玩。：）

4，却陷统计报表

缺陷报表之所以重要是因为，报表能够为我们提供事后统计，而定期的报表也能够为我们提供项目管理的支持，我们能够根据缺陷的汇报以及分布情况来判断当前的项目进度情况，什么模块出现的缺陷最多。在项目完结的时候，缺陷报告也能够为我们提供当前的软件测试是不是已经达到了要求，是不是可以提交给客户。

一般情况下，我们会根据以下几种情况来定义缺陷情况，

·         缺陷分布情况：这里对于各种不同状态的缺陷的一个快照

图1

·         各种级别的缺陷的分布情况

图2

·         缺陷发展的趋势

图3

在项目完结的时候生成上面的图形，如果发现还存在打开状态的缺陷，就需要做出决策，这样的缺陷需要关闭吗？还是在下一个版本当中修改或者别的解释。总之，在提交软件产品的时候，是不能存在一个开启状态的缺陷存在的。

4，汇报缺陷的一些建议

缺陷汇报是缺陷制造者和缺陷发现者之间沟通的桥梁，所以，缺陷必须被描述清楚，这里，有几点建议，

·         详细描述操作步骤

·         粘贴日志信息作为附件

·         对于界面测试，需要把错误界面捕捉下来，作为附件粘贴上

·         错误修改确认的时候，需要把软件版本号加上

·         测试数据描述

·         测试先决条件描述