软件集成测试指导书

集成测试操作指导书

1、简介

1.1 集成测试的关键目标

由于集成测试所处层次、检验对象与单元测试、系统测试有着很大的差异，其操作方法与检验标准也有所不同。

首先，集成测试必须是可重复的。在产品的生命周期中软件维护贯穿始终，不停的修改代码成为必然，仅考虑一次操作的集成测试是一种低效劳动，而且集成测试处于系统的中间层次（与单元测试与系统测试不同），需要编写一系列测试代码，操作难度也较大，所以构造可重复的集成测试过程是保证低投入高产出的前提。

其次，集成测试必须是规范的操作。代码千差万别，有简单的有复杂的、有规范性好的与规范性差的，如何保证不同的代码有相同的测试效果。测试者的素质也千差万别，有经验的与没经验的，能力强的与能力弱的，测试效果大不一样。要保证集成测试是可操作的、可推广的，需要解决这些问题。

另外，集成测试还需是可度量的。不可度量的测试往往意味着失控，质量与进度得不到保证，尤其对于集成测试，有一定难度，执行起来差异很大，更需要对测试效果进行度量。在提供覆盖分析的测试中，我们可以直观的看到哪些代码覆盖到了，哪些代码没覆盖到，再有针对的设计测试用例，这种白盒的方法，有力保证了高效测试。

以上三点是集成测试首先要解决的问题，也是集成测试的关键目标，如下：

关键目标1：构造可重复的集成测试过程 关键目标2：定义规范的集成测试操作 关键目标3：度量集成测试效果

1.2 达成关键目标的对策

1.2.1 构造可重复的集成测试过程

构造可重复的测试过程依赖自动测试工具，使用自动工具是一种手段，目标是构造可重复过程，在达成此目标的前提下，是否使用工具视具体情况，所以使用自动工具很重要，但非必须。一个理想的集成测试工具应具备以下特征：

1、用规范的格式（下称脚本）记录测试用例，测试执行在脚本控制下进行。

2、能方便的维护测试用例。要标识测试用例，能方便的扩充、修改用例。

3、支持测试过程管理，包括起停控制，测试过程记录，执行中的异常处理。

4、支持测试结果自动分析。

基于消息处理的被测系统中，测试驱动可以简化，构造出驱动消息放到指定队列。自动测试结果分析首先要截取程序变量，然后发送到测试管理模块在脚本控制下完成比较。 1.2.1 定义规范的集成测试操作

集成测试是对设计进行验证，设计有明确的层次性，一般而言，在函数调用被调用结构中，顶层部分对应于概要设计，底层部分对应于详细设计。相对应的集成测试也有明确的层次性，设计时怎么细化下去的，集成就怎么合回来，设计是怎么个粗略程度，集成时也该这么个粗略程度。明确这一点对定义集成测试操作有重要意义，实际上这也是V模式的一个核心思想，单元测试对应于编码，集成测试对应于设计，系统测试对应于功能与需求，测试过程就是正向开发的逆向验证过程，各阶段的测试对象对应于相应开发阶段所要分析的对象。

规范的集成测试必须是基于接口的，因为程序设计是根据接口一层一层细化，集成时也只需考察接口。基于接口的集成测试只关注接口的正确性，而不关注函数过程执行的正确性。函数内执行过程的正确性应该属于单元测试范畴，集成测试再关注这个意味着重复，工作量也异常庞大，最终也导致集成测试可操作性差，且失去重点。只关注接口的另一个好处理是：考察点清晰，截取变量的值便可实现自动测试，否则，基于过程的测试最终因函数过程千差万异，而使自动测试无法实现。另外，代码经常在变，而接口相对稳定，基于接口的测试保证较好的可继承性。还有，脱离千差万别的过程，使得整个测试不过分的依赖于测试者的个人素质，该操作是易用易推广的。

基于接口的集成测试是规范的测试，而非调试。之所以要把集成测试与调试严格区分，一方面是因为调试过程不是规范的，随机因素很多，批量的测试实现不了，测试结果无法自动比较，可重复的过程也不能实现；另一方面，调试效果因人而异，调试方法并非可拷贝的。 1.2.3 度量集成测试效果

量化测试效果一方面为了控制质量，另一方面是为了改进，在集成测试中后者更为重要。集成测试方法是黑盒的，只关注输入输出，若没有指标度量，测试程度无从了解，测试质量就失控了。所以，作为一条规则，集成测试需要提供覆盖指标。在覆盖分析中能直观的看到哪些代码未被覆盖，可以有针对性的再作测试，这样的集成测试过程是可改进的过程，保证了测试效率。

2、入口准则

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

集成测试首先要求被测对象具备基本的稳定性，联调要通过，否则集成测试将无法做起。另外，环境物料应有充分的保障，这在集成测试前几个月就得准备。

在软件设计阶段应同步编写集成测试计划，定义各个组件的集成级别，考虑各功能模块的集成方法。这点很重要，集成测试需要一系列条件，应该事先考虑好集成策略，桩模块如何搭建，驱动模块如何设计，测试代码与源代码如何接口，特殊情况还需考虑外来的数据驱动如何实现，比如：板内集成测试时，被测对象赖以启动的配置数据如何得到，板间或子系统集成时考虑的因素将更多。集成测试计划不仅要规划被测内容，也要标识各子项的轻重缓急、重要程度，用以指导后继的测试设计与测试操作。

做完集成测试计划后，需要与产品设计相结合，同步开展可测性设计，预留集成测试接口，开始设计、实现测试代码。如果此项工作未同步开展，后期编码完成了才考虑集成测试的接口，满足不了需求再去修改设计将给系统带来很大伤害。

具备一定素质的测试人员也是集成测试的一项重要入口准则，按照经验，集成测试中是否具备一定技术能力、有无集成测试经验，对最终的测试效果影响很大。进行集成测试的操作者最好是被测对象的正规检视者（方案、设计与代码审查）。

3、关键活动

本节描述集成测试过程的关键活动包括：

☆ 制定集成测试计划 ☆ 集成测试风险分析 ☆ 集成测试方案设计 ☆ 集成测试工具设计和调研

☆ 集成测试接口分析与测试用例设计 ☆ 集成测试操作 ☆ 集成测试报告评审 3.1 制定集成测试计划

集成测试计划应在设计阶段完成，一般情况下，概要设计结束时，集成测试计划也应完成。集成测试计划规划了今后的集成测试内容、测试方法以及可测性接口，以后所有集成测试均在该计划的框架下进行，所有，制定一份完善的集成测试计划非常重要。

制定集成测试计划之前需要进行充分的调研，调研的主要内容包括：

1）调研集成测试内容，确定哪些功能模块需要进行集成测试 2）关键模块的集成策略拟定

3）关键模块的集成测试接口与驱动条件分析

4）依据集成策略需要进行的测试设计与工具调研、开发 5）集成测试进度计划

6）集成测试需要的环境物料考虑 3.1.1 调研集成测试内容

调研集成测试内容，应在软件总体测试计划的框架下，综合考虑单元测试、性能测试、系统测试的工作安排。以下提供一般性的建议： A、 考虑集成的层次，在函数的调用与被调用关系中，集成测试对象应

尽量选取上层，过于底层测试的往往会产生低效劳动。

B、 考虑软件的层次，集成测试不应测试单元测试测过的内容，系统测

试能测到的内容，应定义低优先级，典型的如 MPU 板的业务处理，处理单板的应用层，系统测试即能覆盖大部分语句，在一般情况下不必作为集成测试内容。 C、 考虑软件复杂度，越复杂的也越容易出错，也越需要进行集成测试。 D、 考虑被测模块的重要性，在系统中处于核心位置或关键地置，即使

复杂度不高，也需作重点测试。确定集成测试对象，还需分配该项的测试的集成级别，集成级别用于标识任务的重要程度，标识集成级别为后继工作提供指导。

E、 权衡投入产出，在有限资源条件下选取恰当的测试集。特别是某

些被集成子对象之间互不相干时，不应作为测试内容。比如：网接续与板内其它功能进行集成测试时，查看控存也是一项应用层功能，但该业务不修改业务状态，也不作备份，对其它应用层功能除了性能不再有其它影响，这时集成测试时就可以不考虑该项功能。 F、 考虑可测性，此项考虑的优先级应低于测试需求，难测的项目应尽

可能去测，在可测试性上多下功夫。 3.1.2 关键模块的集成策略拟定 集成策略可分三类：

一是自下而上式，被测试对象从底层一级一级往上叠加，集成测试也一级一级的进行，这种做法的好处是不需编写桩函数，构造出的环境较真实，是最常用的一种方法。

二是自上而下式，顶层是真实的驱动，桩函数需自己编写，这种方法适用于上层设计较复杂而下层较为清晰简单的场合。

第三类是介于上两者之间，被测对象的上层驱动与底层桩函数都需自己构造，这种应用较为少见。

如果对系统进行集成，对被测对象的特性紧密相关，如何集成是方法，目的是要以最小的投入获得最佳的效益，应尽可能保证系统的真实性的前提下减少测试代码编写。

3.1.3 关键模块的集成测试接口与驱动条件分析

集成测试接口应选择在具有明显层次性的地方，这样的接口通常是清晰的，接口清晰使得测试驱动与结果监测变得简捷，这对集成测试构造有着莫大的好处。集成测试应具备清晰的层次性，但这种层次不宜过多，以CC08机的单板为例，集成的层次应控制在3~4层为宜，如：链路处理、传输层、板内关键业务的相互关系、同一业务的多板多个子系统间集成。 分析集成测试接口主要考虑几点：

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

B. 兼容性考虑，尽可能少的破坏系统原有结构，且有良好的可扩展性。 C. 监测试点需要具备一定的稳定性，因为集成测试不只测试一次，易变的接口对重复测试不利。 3.1.4 依据集成策略需要进行的测试设计与工具调研、开发

集成策略与测试接口分析清楚后，应考虑如何进行测试设计，另外还得考虑是否已有合适的测试工具，未有工具应考虑调研后外购或自行开发。此项工作需在设计阶段考虑清楚，因为测试工具与集成对象接口，如果要做集成测试了才考虑这些，被测对象未必有合适的接口预留，如果再去修改程序麻烦就大了。

如何进行测试设计与工具调研、开发，详见3.4 小节内容。 3.1.5 集成测试进度计划

制定集成测试进度计划考虑以下情况：

A. 考虑集成测试被测试对象数量，即工作量 B. 关键模块进度安排应多留时间，宁可牺牲不重要模块的测试也不要牺牲重要模块的测试质量。

C. 考虑集成测试难度与风险，难度大风险高的模块应多预留时间 D. 考虑测试者的整体技术水平

E. 考虑测试工具调研或开发的时间 F. 给集成测试设计预留出足够的时间 G. 结合开发计划，要有一定的风险估计 3.1.6 集成测试需要的环境物料考虑

测试物料与怎么测有关，制定集成测试计划后测试思路清晰了，相关的物料计划需要做出来，因为申购物料需要时间，物料需在集成测试启动前到位。 3.2 集成测试风险分析

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

A、代码是否具有足够的稳定性，接口是否具有基本的稳定性。 B、集成测试方案在现有人力物力条件下是否可行。

C、集成测试是否支持重复测试，不支持重复测试的集成方案应严格受控。

D、集成测试方法是否基于接口。

E、是否采用覆盖工具，工具的使用效果如何。

F、测试者是否具备一定的技术水平，是否已有集成测试经验。 G、测试中是否有足够的技术支援

风险分析报告需经过专家评审，一般情况下风险分析与集成测试方案一同递交评审，评审结论还要有跟踪解决。 3.3 集成测试方案设计

集成测试方案要实现集成测试的3个关键目标，即：实现可重复测试、基于接口测试、以覆盖指标衡量测试质量，集成测试方案围绕这三个目标来构造。

一个典型的集成测试系统，如图1所示，测试管理系统位于被测系统之外的独立系统，它与被测单板通过网口（或串口或其它通道）联接，测试用例管理模块主要完成测试用例设计与维护，测试过程控制模块通过脚本完成测试过程控制。测试管理系统下发测试驱动命令，发送到被测单板的驱动模块，再由驱动模块驱动被测系统正常运行，运行结果的采集也通过驱动模块完成，采集的结果发送到测试管理系统用于判断测试结果是否正确。 图 1 集成测试系统示例 驱动模块测试用例管理模块测试过程控制模块被测系统网口 或桩函数桩函数串口 或其它连接被测单板测试管理系统 采集运行结果需要设置监测点，监测点数量多少要视被测对象的接口特性，接口简单的，监测点就少，反之监测点多。一般情况下，一个监测点就是一个全局变量或一个消息，我们不建议把局部变量作为监测点，因为局部变量在函数内定义，也只在函数内生效，监测局部变量是单元测试的范畴，此外，要监测局部变量需修改被测试系统，这不是我们所希望的，我们应尽可能保证被测系统的真实性。对消息的监测，往往需要修改接收消息函数，我们需要捕获特定队列、特定特性的消息，实现起来较为容易。因为监测的对象是变量或消息，测试结果比较相对简单（不象系统测试，监测对象是GUI界面或一段文字输出或特定设备特定动作），集成测试的自动化还是比较容易实现的。

被测代码还需要插装以支持覆盖率统计，这部分工作最好用商用工具实现。覆盖指标中我们主要关心两项：语句覆盖与分支覆盖。路径覆盖与数据流覆盖因测试难度较大，一般情况下可不作要求。进行覆盖测试还需注意插装对代码运行效率的影响，缺少硬件支持打点取样的系统在插装前与插装后的运行效率能有数倍或数十倍的差异，这一点需注意，对运行效率有要求的被测系统，插装范围应有所控制。对运行效率有严格要求的系统，应采用硬件支持打点取样的工具，如CodeTEST。

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

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

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

根据上述测试框架，集成测试有两类测试工具需考虑，一类是驱动被测系统以及截取结果分析的工具，另一类是覆盖率测试工具。

第一类工具因被测试系统是千变万化的，驱动模块、桩函数和监测点的捕获没有现成的商用工具可用，但后台的测试管理系统只要接口兼容性好，多数情况可重用。值得一提的是，利用商用脚本语言（如 TCL）构造驱动模块与桩函数能提高测试效率。

第二类工具我们有许多商用工具可调研，覆盖工具应用不同的被测系统有不同的选择，我们应优先调研商用工具，如没有合适的才考虑开发。调研覆盖工具需关注工具的易用性与健壮性，因插装打点过程较复杂，还依赖特定的语法分析器，许多商用工具较难用或不稳定。 3.5 集成测试接口分析与测试用例设计

测试用例设计是开展集成测试的基础，而测试接口分析是测试用例设计的基础。我们以接口特性考察被测对象，接口特性又从需求分析派生，所以接口分析时，我们要关注接口特性对需求描述的符合度，即，我们把所分析的接口特性叠加就能较完整的表达需求（或该需求的某一子项）。 接口分析需要罗列我们关心的接口，给出程序中对应的变量名，然后考虑如何驱动或监测。如表1所示： 表1：接口分析表样例 类别 属性 对应变量 驱动或监测试方法 表1中类别用来概括一种接口，如网接续集成测试中，应用层发起连网、拆网命令，这是一个接口类，假设链路层已仿真掉，对被测系统链路接口也是一个接口类。表1中属性是指一个接口类下的各种属性，如网接续接口下有：连网申请、拆网申请、成功或失败指示，控存值等属性，这些属性在程序中都有对应变量，这些变量是我们用以驱动测试或监测运行状态的对象。驱动或监测方法用来描述测试中如何使用该变量，如对于连网申请，我们可以在模拟一个时隙申请的消息放到指定队列，时隙是否申请成功，我们可以察看标识控存的变量。

分析完接口特性，我们就对如何驱动被测对象与如何捕获动行结果有着清晰认识，这时可以开始设计测试用例了。测试用例应以规范的脚本描述，设计时应充分考虑用例的可扩展性，并考虑将来接口的可能变化。至于如何设计完善的测试用例不在本文描述之列，但提供覆盖分析的测试对测试用例设计有直接的指导，哪个分支没覆盖到，就针对的设计用例让它覆盖到。 3.6 集成测试操作

集成测试的主要工作量应在测试代码编写以及测试用例设计与调试上，实际的集成测试操作应占很小一部分时间，因为测试过程是自动执行的。 因为集成测试发现问题后定位是直接的，更改流程应支持较快的版本更新，因为覆盖率的上升最终取决于正确执行测试用例后的结果，而且，某种情况下，程序中有不可达代码，需删除该代码才能提高覆盖率。集成测试不能象系统测试那样一个版本结束才出下一版本，是因为集成测试是对局部功能集成，版本基线较少受之影响，此外，不象系统测试，集成测试主要过程不在测试操作，不提高版本更新频度将影响测试效率。

集成测试也并非全部完成测试代码或用例设计才可以上手操作，实际上能让部分测试用例转起来，测试操作就可以开始了，测试代码编写、测试用例设计、测试操作可以并行着做。实际上，不停的调试测试用例同时就是一个测试过程，而且这部分时间占整个操作过程的大部分。因为插装过程较为繁琐，调试时我们可不必插装代码。

与其它测试类似，集成测试需要随时记录异常情况，定期汇报总结以期改进。

3.7 集成测试报告评审

集成测试报告评审是对整个测试过程进行审核，对测试结果的正确性、测试覆盖率作评价，此外，评审还对集成测试执行过程、计划完成情况以及集成测试方案、方案等进行确认。需要确认的内容参见《集成测试报告评审CheckList》。

4、方法和工具

TCL 语言，参考相关工具说明。 LogiScope ，参考相关工具说明。 CodeTEST ，参考相关工具说明。 HindSight ，参考相关工具说明。

5、出口准则

完成集成测试报告 通过集成测试报告评审

完成《集成测试任务总结报告》

本文来源：https://www.bwwdw.com/article/u6cg.html