集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。 集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。 集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说，在集成测试之前，单元测试应该已经完成，集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要，因为如果不经过单元测试，那么集成测试的效果将会受到很大影响，并且会大幅增加软件单元代码纠错的代价。 集成测试是单元测试的逻辑扩展。在现实方案中，集成是指多个单元的聚合，许多单元组合成模块，而这些模块又聚合成程序的更大部分，如分系统或系统。集成测试采用的方法是测试软件单元的组合能否正常工作，以及与其他组的模块能否集成起来工作。最后，还要测试构成系统的所有模块组合能否正常工作。集成测试所持的主要标准是《软件概要设计规格说明》，任何不符合该说明的程序模块行为都应该加以记载并上报。 所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式，具体的开发工作总得从一个一个的软件单元做起，软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成，总是会出现一些常见问题，工程实践中，几乎不存在软件单元组装过程中不出任何问题的情况。从图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进行版本控制。 步骤三: 测试人员和开发人员负责编写对应程序代码的测试脚本。 步骤四: 设置自动化集成测试工具，每隔一段时间对配置管理库的新添加的代码进行自动化的集成测试，并将测试报告汇报给开发人员和测试人员。       步骤五: 测试人员监督代码开发人员及时关闭不合格项。       按照步骤三至步骤五不断循环，直至形成最终软件产品。       方案点评: 该测试方案能在开发过程中及时发现代码错误，能直观地看到开发团队的有效工程进度。在此方案中，开发维护源代码与开发维护软件测试包被赋予了同等的重要性，这对有效防止错误、及时纠正错误都很有帮助。该方案的缺点在于测试包有时候可能不能暴露深层次的编码错误和图形界面错误。       以上我们介绍了几种常见的集成测试方案，一般来讲，在现代复杂软件项目集成测试过程中，通常采用核心系统先行集成测试和高频集成测试相结合的方式进行，自底向上的集成测试方案在采用传统瀑布式开发模式的软件项目集成过程中较为常见。读者应该结合项目的实际工程环境及各测试方案适用的范围进行合理的选型。

根据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）活动步骤  集成测试用例设计 集成测试程设计 集成测试代码设计（如果需要）  集成测试脚本（如果需要）  集成测试工具（如果需要）
5）输出  集成测试用例 集成测试规程 集成测试代码 集成测试脚本 集成测试工具
6）出口条件  测试用例和测试规程通过编码阶段基线评审

执行阶段
1）时间安排 单元测试已经完成后就可以开始执行集成测试了
2）输入     需求规格说明书 概要设计  集成测试计划  集成高度设计  集成测试例 集成测试规程  集成测试代码（如果有）  集成测试脚本 集成测试工具 详细设计  代码  单元测试报告  
3）入口条件 单元测试阶段已经通过基线化评审
4）活动步 骤 执行集成测试用例 回归集成测试用例  撰写集成测试报告  
5）输出  集成测试报告
6）出口条件  集成测试报告通过集成测试阶段基线评审

目的：
    ●  按照项目定义的测试过程进行测试。由独立于软件开发者的测试组制定测试计划和测试用例，提交测试报告。
角色与职责：
    ●  项目软件经理（开发负责人）：负责审批测试计划；评审测试用例；将欲测试的内容集成到测试环境。
    ●  测试人员：负责完成测试用例设计、集成测试环境搭建、执行集成测试、验证问题、撰写测试报告。
    ●  开发人员：负责及时修复测试出的问题。

进入准则： 
    ●  项目已启动。
    ●  需求文档已通过评审
输入：
    ●  需求文档
结束准则：
    ●  通过集成测试。
输出： 
    ●  已通过集成测试的代码及软件
    ●  测试用例
    ●  问题记录
    ●  测试报告
主要活动：
1  测试人员在项目启动后编制测试计划，其中可包括集成测试计划，在集成测试时进行细化或变更。测试计划应经过相关人
   员（项目经理、SQA、需求人员等）评审。集成测试分为单元（也叫组装）集成测试和系统集成测试两个阶段。
   
2  单元（组装）集成测试（与开发同步进行，指对开发出的程序单元集成到系统中进行的测试）：
    ●  测试人员依照测试计划进行测试设计，编写测试用例和测试脚本（可选）。测试设计的结果要经过评审。
    ●  测试人员在开发负责人协助下搭建独立的测试环境（该环境能够运行代码程序）。
    ●  开发负责人将已通过单元测试的程序单元提交集成到测试环境中。
    ●  测试人员执行单元集成测试，测试出的问题登记到项目BUG库中，见《开发项目缺陷库使用说明》。
    ●  开发人员根据项目BUG库中的登记，及时修复程序问题。非最终状态问题的每种状态存活周期不超过5个工作日。
    ●  测试人员验证问题。
    ●  测试人员按照项目测试计划，分阶段出具《测试周报》。
    ●  重复上面1-7步直到子系统模块单元全部通过《测试计划》中定义的单元集成测试通过标准。
    单元（组装）集成测试通过标准：
        ◇ 相关测试用例执行完毕。
        ◇ 单元（组装）集成测试发现的严重问题（一二级）90%得到正确修改；一般问题（三级）70%得到修改。
        
3 系统集成测试（指对已编译的Build进行的测试）：
    ●  测试人员依照测试计划进行测试设计，编写测试用例和测试脚本（可选）。测试设计的结果要经过评审。
    ●  测试人员在开发负责人协助下搭建独立的测试环境。
    ●  开发负责人依照计划将已经过编译构建的Build提交集成到测试环境中。
    ●  测试人员执行系统集成测试，测试出的问题登记到项目BUG库中，见《开发项目缺陷库使用说明》。
    ●  开发人员根据项目BUG库中的登记，及时修复程序问题。非最终状态问题的每种状态存活周期不超过5个工作日。
    ●  测试人员验证问题。
    ●  测试人员按照项目测试计划，分阶段出具《Build测试报告》。
    ●  重复上面1-7步直到子系统模块单元全部通过《测试计划》中定义的系统集成测试通过标准。
    系统集成测试通过标准：
        ◇ 所有测试用例执行完毕。
        ◇ 系统集成测试发现的严重问题（一二级）90%得到正确修改；一般问题（三级）70%得到修改。
        ◇ 问题库中的问题都为最终状态（最后一个Build的问题除外）。
        
4 测试人员分析总结集成测试活动，编制《集成测试报告》。

5 测试人员填写《需求列表》中的需求覆盖表，以便于跟踪和验证。
过程裁剪说明：
◆ 已配备了专职测试人员的项目需按该过程执行。
◆ 未在公司立项的项目集成测试可参照该过程执行

可以思考以下内容并用集成测试计划的模板写下来：

1、确定集成测试对象

2、确定集成测试策略

3、确定集成测试验收标准

4、确定集成测试挂起和恢复条件

5、估计集成测试工作量

6、估计集成测试所需资源

7、进行集成测试任务划分（包括任务名、责任人、 输入和输出、风险及应对措施、进度安排等）

集成测试过程

根据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）活动步骤 集成测试用例设计 集成测试程设计 集成测试代码设计（如果需要） 集成测试脚本（如果需要） 集成测试工具（如果需要）

5）输出 集成测试用例 集成测试规程 集成测试代码 集成测试脚本 集成测试工具

6）出口条件 测试用例和测试规程通过编码阶段基线评审

执行阶段

1）时间安排 单元测试已经完成后就可以开始执行集成测试了

2）输入 需求规格说明书 概要设计 集成测试计划 集成高度设计 集成测试例 集成测试规程 集成测试代码（如果有） 集成测试脚本 集成测试工具 详细设计 代码 单元测试报告

3）入口条件 单元测试阶段已经通过基线化评审

4）活动步 骤 执行集成测试用例 回归集成测试用例 撰写集成测试报告 

5）输出 集成测试报告

6）出口条件 集成测试报告通过集成测试阶段基线评审 

 

    对于集成测试，初学者往往比较模糊，到底怎么测？是不是把两个模块连在一起，然后采用单元测试的技术，测试这个更大的模块？

　　我们都知道，集成测试关注的是模块之间的接口。那么可以将“接口”作为切入点。纵观模块之间的接口，我们可以归纳为以下几种类型，下面一一介绍一下。

　　1、通信协议：两个模块之间通信采用的是标准的或者自定义的（网络）协议；
　　协议中即包含数据部分，又包含控制部分；有些实现将数据与控制分离，如FTP；而大部分实现将数据与控制通过一条链路来传递，往往通过不同的消息包进行分离。

　　2、调用关系：模块A调用模块B，实际上是由模块A向模块B发出了一条控制指令，这里数据传递体现的不是很明显，往往体现为参数与返回值，它们可以认为是控制的副本。

　　3、文件、数据库、队列、第三方中间件等：表现的主要是数据的传递，其中的控制体现的不明显。

　　4、共享资源：比如共享一段“存储区域”，其中涉及的关键资源主要是“锁”了；这样的两个模块在运行时往往分布到不同的进程或者线程中，表现为对资源的竞争，以及数据的共享。

　　5、同步：一个模块的运行需要另外一个模块的触发，双方往往存在“信号”等通知机制，也可以理解为一种特殊的控制方式。

　　OK，现在切入点有了，我们可以将被测系统归类（以上的分类），找出其中的数据接口与控制接口。

　　接下来的做法与一般的测试思路没有什么不同。
　　首先，将数据接口与控制接口分解——需要传递哪些数据？存在哪些控制指令？
　　然后，找出数据与指令中的变数所在；如数据（协议包）中的字段的取值，指令的参数变化等；
　　接下来，将变数划分等价类，找出每类的代表，就是我们的测试数据了——我们的目标是：让每类数据流与控制流均通过接口一次，从而实现接口测试的完全性；
　　最后，就是考虑如何生成这些测试数据了。往往需要对应到集成后“大模块”的输入与输出。

　　谈了很多，上面的内容更多的关注了实现。下面我们要考虑另外一个侧面——业务。
　　模块之间的联系（接口）往往是为了体现业务上的关联。大家都知道，关联本身也是有很多属性的。如关联点（每个模块）都存在一个角色，关联有多重性（multiplicity）——即模块A在运行时可能对应多个模块B的实例。

　　我们找到了测试的另外一个切入点，模块的集成能否准确体现业务上的关联？各个模块是否具备其角色的全部属性和接口，模块之间的关联关系如何打破？关联的多重性是否有效？

　　当然，集成测试不会太关心业务或者需求，那是系统测试的事了。但此时想想，往往能够得到意外的收获。

太多的关注功能，往往忽略其他。有时我们不得不考虑接口的性能，尤其对于系统关键接口。接口的性能测试越早进行越好。如果等到系统测试时做，可能接口外面封装了太多的代码，影响性能问题的精确定位。

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

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

可以以多种方式进行集成测试，而下面是三种常见的类别：

由上而下的集成测试方法要求首先测试和集成最高级别的模块。这种高级别的逻辑和数据流可以在过程的早期阶段测试。有助于最大限度地减少对驱动程序的需求。但是，对存根（stub）的需求使测试管理变得复杂，低级别的使用工具在开发周期中相对较晚的阶段测试。由上而下的集成测试的另一个缺点是必能很好的支持有限功能的早期发布。

由下而上的方法要求首先测试和集成最低级别的单元。这些单元常被称为使用工具模块。通过使用这种方法，使用工具模块在开发过程的早期阶段测试，最大限度第减少了对存根（stub）的需求。但是，不利的方面是对却动程序的需求使测试管理变得复杂，高级别的逻辑和数据流在晚期测试。与由上而下的方法一样，有下而上的方法也不能很好地支持有限功能的早期开发。

第三种方法（有时也称为伞状方法）要求测试沿功能性测试和控制流路径进行。首先，函数的输入以上面的讨论的由下而上的模式集成。然后，每个函数的输入以由上而下的方式集成。这种方法的主要优点是对有限公能的早期发布的支持程度。它也有助于最大限度地减少对存根（stub）和驱动程序的需求。但是，这种方法的潜在缺点非常明显，因为它的系统性可能比其他两种方法，会导致对回归测试的更大需求。

集成测试计划书

作者：不详　　　　文章来源：网络

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的提交，集成部经理通知测试设计人员和测试人员，对相应文档进行修改; （bug状态RESOLVED，决定设置为INVALID）; 7.3 对于目前无法修改的,将这个bug放到下一轮次进行修改；（bug状态RESOLVED，决定设置为REMIND） 8. 开发人员接到发过来的bug立刻修改;（bug状态RESOLVED，决定设置为FIXED） 9. 测试人员接到bugzilla发过来的错误更改信息，应该逐项复测，填写新的测试报告（测试报告必须覆盖上一次中所有REOPENED的测试用例）； 10. 如果复测有问题返回第六步（bug状态REOPENED） 11. 否则关闭这项BUG（bug状态CLOSED） 12. 本轮测试中测试用例中有95%一次性通过测试,结束测试任务； 13. 本轮测试中发现的错误有98%经过修改并且通过再次测试（即bug状态CLOSED），返回第五步进行新的一轮测试； 14. 测试任务结束后书写测试总结报告； 15. 正规测试结束进入非正规测试，首先是ALPHA测试，请公司里其他非技术人员以用户角色使用系统。发现bug通知测试人员，测试人员以正规流程处理bug事件； 16. 然后是BETA测试，请用户代表进行测试。发现bug通知测试人员，测试人员以正规流程处理bug事件。 几点说明： 测试回归计划为三次； 测试用例应该写得比较详尽，步骤一定要标明清楚（应该包括：编号，测试描述，前置条件，测试步骤以及测试希望结果）； 对于测试人员觉得应该进行的测试项目，测试人员应该报告测试设计人员，完善和健全测试用例； 测试报告与测试用例分开，测试报告标明测试用例序号以及是否通过Y/N； 对于集成部经理无法决定的上交项目负责人决定； 性能测试中的疲劳性测试可以结合在功能测试部分，即测试期间不关闭机器； 性能测试中的大容量数据测试放在测试后部分轮次（第二步，只需要进行一次） 6 测试通过标准 测试结果与测试用例中期望的结果一致，测试通过，否则标明测试未通过。 6.1测试结果审批过程 6.1.1测试回归申请结束 测试人员提出申请这轮测试结束，提交集成部经理； 集成部经理召集本组人员开会讨论； 讨论通过，进行下一轮测试，并且部署下一轮测试的注意事项，流程等内容； 如果发现这轮测试目前还存在问题没有解决，延期下一轮测试时间，讨论下一步工作应该如何进行。 6.1.2测试结果申请结束 测试人员提出申请测试结束，提交集成部经理； 集成部经理召集本组人员开会讨论； 1. 讨论通过，结束测试任务； 2. 如果发现目前测试还存在问题没有解决，延期测试结束时间，并且讨论下一步工作应该如何进行。 7 测试挂起和恢复条件 7.1挂起条件 进入第一轮测试，测试人员大体了解一下产品情况，如果在一小时之内发现５个以上（含５个）操作性错误，或者３个以上（含３个）功能性错误，退回测试组测试； 遇到有项目优先级更高的集成测试任务； 遇到有项目优先级更高的集成任务； 在测试复测过程中发现产品无法运行下去； 人员，设备不足。 7.2恢复条件 符合进入集成测试条件（一小时之内发现５个以下（不含５个）操作性错误，或者３个以下（不含３个）功能性错误）； 项目优先级更高的集成测试任务暂告完成； 项目优先级更高的集成任务暂告完成； 复测过程中产品可以运行下去； 人员，设备到位。 8应提供的测试文件 测试计划书 测试用例 测试报告 测试总结 9测试任务 制定审核测试计划 制定和审核测试用例 进行测试活动 书写测试报告 10测试环境需求 10.1硬件需求 *********** 10.2软件需求 ************ 10.3测试工具 ************* 10.4测试需要的条件 ************** 10.4.1需要的文档 用户手册 应用手册 安装说明 10.4.2需要完成的任务 程序员本人测试 测试组完成测试 11角色和职责 集成（测试）经理：控制并完成测试任务和测试过程，决定测试人员提交上来的bug是否需要修改； 测试设计人员：书写集成测试用例； 测试人员：按照测试用例进行测试活动； 开发人员：MHP程序bug修改； 用户代表：进行BETA测试。 12 人员和培训 集成测试经理有责任对测试相关人员进行测试流程，规章制度培训； 测试设计人员有责任对测试人员进行测试操作培训 13 测试进度 测试工作 进度(人＊工作日) 测试计划 8 测试设计 60 测试执行总共进度 30 每次回归进度 10 测试报告 ２ 14风险及应急计划 设备不到位:加紧设备购买; 人员不到位 人员请假：请假人员回来加班或赶紧测试进度／申请调配新的人员； 人员离职：调配新的人员； 人员调配到其他部门或项目：调配新的人员； 开发人员开发频频出错：通知开发部门，商量策略； 其他原因的测试工作频频被挂起或者挂起后迟迟恢复不了：加班或延期 15审批 集成部经理 技术部经理 姓名： 姓名： 日期： 日期：

 

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

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

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

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

        
　　

　　所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式，具体的开发工作总得从一个一个的软件单元做起，软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成，总是会出现一些常见问题，工程实践中，几乎不存在软件单元组装过程中不出任何问题的情况。从图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进行版本控制。

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

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

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

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

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

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