软件集成测试指导方案

精心整理
集成测试操作指导书
1、简介
1.1集成测试的关键目标
由于集成测试所处层次、检验对象与单元测试、系统测试有着很大的差异，其操
不停
试效果进行度量。

在提供覆盖分析的测试中，我们可以直观的看到哪些代码覆盖到了，哪些代码没覆盖到，再有针对的设计测试用例，这种白盒的方法，有力保证了高效测试。

以上三点是集成测试首先要解决的问题，也是集成测试的关键目标，如下：
关键目标1：构造可重复的集成测试过程
关键目标2：定义规范的集成测试操作
关键目标3：度量集成测试效果
1.2达成关键目标的对策
1.2.1定义规范的集成测试操作
集成测试是对设计进行验证，设计有明确的层次性，一般而言，在函数调用被调用结构中，顶层部分对应于概要设计，底层部分对应于详细设计。

相对应的集成测试也有明确的层次性，设计时怎么细化下去的，集成就怎么合回来，设计是怎
么个粗略程度，集成时也该这么个粗略程度。

明确这一点对定义集成测试操作有重要意义，实际上这也是V模式的一个核心思想，单元测试对应于编码，集成测试对应于设计，系统测试对应于功能与需求，测试过程就是正向开发的逆向验证过程，各阶段的测试对象对应于相应开发阶段所要分析的对象。

规范的集成测试必须是基于接口的，因为程序设计是根据接口一层一层细化，集
1.2.3度量集成测试效果
量化测试效果一方面为了控制质量，另一方面是为了改进，在集成测试中后者更为重要。

集成测试方法是黑盒的，只关注输入输出，若没有指标度量，测试程度无从了解，测试质量就失控了。

所以，作为一条规则，集成测试需要提供覆盖
指标。

在覆盖分析中能直观的看到哪些代码未被覆盖，可以有针对性的再作测试，这样的集成测试过程是可改进的过程，保证了测试效率。

2、入口准则
集成测试的入口准则已在《DP0070-软件集成测试过程》中定义，下面描述几项重要规则。

具备一定素质的测试人员也是集成测试的一项重要入口准则，按照经验，集成测试中是否具备一定技术能力、有无集成测试经验，对最终的测试效果影响很大。

进行集成测试的操作者最好是被测对象的正规检视者（方案、设计与代码审查）。

3、关键活动
本节描述集成测试过程的关键活动包括：
☆制定集成测试计划
☆集成测试风险分析
☆集成测试方案设计
3.1
1）调研集成测试内容，确定哪些功能模块需要进行集成测试2）关键模块的集成策略拟定
3）关键模块的集成测试接口与驱动条件分析
4）依据集成策略需要进行的测试设计与工具调研、开发
5）集成测试进度计划
6）集成测试需要的环境物料考虑
3.1.1调研集成测试内容
调研集成测试内容，应在软件总体测试计划的框架下，综合考虑单元测试、性能测试、系统测试的工作安排。

以下提供一般性的建议：
A、考虑集成的层次，在函数的调用与被调用关系中，集成测试对象应尽量选
功能进行集成测试时，查看控存也是一项应用层功能，但该业务不修改
业务状态，也不作备份，对其它应用层功能除了性能不再有其它影响，
这时集成测试时就可以不考虑该项功能。

F、考虑可测性，此项考虑的优先级应低于测试需求，难测的项目应尽可能去
测，在可测试性上多下功夫。

3.1.2关键模块的集成策略拟定
集成策略可分三类：
一是自下而上式，被测试对象从底层一级一级往上叠加，集成测试也一级一级的进行，这种做法的好处是不需编写桩函数，构造出的环境较真实，是最常用的一种方法。

这
3.1.3
接口
集
成的层次应控制在3~4层为宜，如：链路处理、传输层、板内关键业务的相互关系、同一业务的多板多个子系统间集成。

分析集成测试接口主要考虑几点：
A.驱动集成测试需要具备哪些接口条件，如：需要下发哪些驱动命令，命令怎
么发下去，变量值怎么报上来。

B.兼容性考虑，尽可能少的破坏系统原有结构，且有良好的可扩展性。

C.监测试点需要具备一定的稳定性，因为集成测试不只测试一次，易变的接口
对重复测试不利。

3.1.4依据集成策略需要进行的测试设计与工具调研、开发
集成策略与测试接口分析清楚后，应考虑如何进行测试设计，另外还得考虑是否
3.1.5
F.给集成测试设计预留出足够的时间
G.结合开发计划，要有一定的风险估计
3.1.6集成测试需要的环境物料考虑
测试物料与怎么测有关，制定集成测试计划后测试思路清晰了，相关的物料计划需要做出来，因为申购物料需要时间，物料需在集成测试启动前到位。

3.2集成测试风险分析
集成测试需要较多的条件才能开展，具有较高的风险，所以在启动集成测试前要做充分的风险分析。

主要考虑以下方面：
3.3
一个典型的集成测试系统，如图1所示，测试管理系统位于被测系统之外的独立系统，它与被测单板通过网口（或串口或其它通道）联接，测试用例管理模块主要完成测试用例设计与维护，测试过程控制模块通过脚本完成测试过程控制。

测试管理系统下发测试驱动命令，发送到被测单板的驱动模块，再由驱动模块驱动被测系统
正常运行，运行结果的采集也通过驱动模块完成，采集的结果发送到测试管理系统用于判断测试结果是否正确。

图1
采集运行结果需要设置监测点，监测点数量多少要视被测对象的接口特性，接口简单的，监测点就少，反之监测点多。

一般情况下，一个监测点就是一个全局变量或
制定集成测试方案需要审核被测系统的真实性，因为驱动模块、桩函数设计，驱动命令发送与监测点捕获都需修改程序，修改前后可能会给被测对象带来差异，尤其是加入被测代码，调度方式可能会产生改变，规划集成测试方案时需对这些差异进行祥细的评估，否则，差异过大的测试最终可能导致无效的劳动。

制定集成测试方案还需对测试范围界定，集成是某一层次的集成，处于被测对象下层与上层的代码测不到，需明确的作出说明或评估，为更上一层的集成测试或系统测试提供服务。

集成测试应考虑为性能测试提供方便，某些情况下，集成测试的构造与性能测试是相同的，采用不同的脚本即能完成这两项测试。

3.4
3.5
测试用例设计是开展集成测试的基础，而测试接口分析是测试用例设计的基础。

我们以接口特性考察被测对象，接口特性又从需求分析派生，所以接口分析时，我们要关注接口特性对需求描述的符合度，即，我们把所分析的接口特性叠加就能较完整的表达需求（或该需求的某一子项）。

接口分析需要罗列我们关心的接口，给出程序中对应的变量名，然后考虑如何驱动或监测。

如表1所示：
表1：接口分析表样例
表
1
本文描述之列，但提供覆盖分析的测试对测试用例设计有直接的指导，哪个分支没覆盖到，就针对的设计用例让它覆盖到。

3.6集成测试操作
集成测试的主要工作量应在测试代码编写以及测试用例设计与调试上，实际的集成测试操作应占很小一部分时间，因为测试过程是自动执行的。

因为集成测试发现问题后定位是直接的，更改流程应支持较快的版本更新，因为覆盖率的上升最终取决于正确执行测试用例后的结果，而且，某种情况下，程序中有不可达代码，需删除该代码才能提高覆盖率。

集成测试不能象系统测试那样一个版本结束才出下一版本，是因为集成测试是对局部功能集成，版本基线较少受之影响，此外，不象系统测试，集成测试主要过程不在测试操作，不提高版本更新频度将影
码。

3.7
4
TCL语言，参考相关工具说明。

LogiScope，参考相关工具说明。

CodeTEST，参考相关工具说明。

HindSight，参考相关工具说明。

5、出口准则
完成集成测试报告
通过集成测试报告评审
完成《集成测试任务总结报告》。