1、度量集成测试效果1.2 达成关键目标的对策1.2.1 构造可重复的集成测试过程构造可重复的测试过程依赖自动测试工具，使用自开工具是一种手段，目标是构造可重复过程，在达成此目标的前提下，是否使用工具视具体情况，所以使用自开工具很重要，但非必须。一个理想的集成测试工具应具备以下特征：1、用规的格式下称脚本记录测试用例，测试执行在脚本控制下进展。2、能方便的维护测试用例。要标识测试用例，能方便的扩大、修改用例。3、支持测试过程管理，包括起停控制，测试过程记录，执行中的异常处理。4、支持测试结果自动分析。基于消息处理的被测系统中，测试驱动可以简化，构造出驱动消息放到指定队列。自动测试结果分析首先要截取
2、程序变量，然后发送到测试管理模块在脚本控制下完成比拟。1.2.1 定义规的集成测试操作集成测试是对设计进展验证，设计有明确的层次性，一般而言，在函数调用被调用构造中，顶层局部对应于概要设计，底层局部对应于详细设计。相对应的集成测试也有明确的层次性，设计时怎么细化下去的，集成就怎么合回来，设计是怎么个粗略程度，集成时也该这么个粗略程度。明确这一点对定义集成测试操作有重要意义，实际上这也是V模式的一个核心思想，单元测试对应于编码，集成测试对应于设计，系统测试对应于功能与需求，测试过程就是正向开发的逆向验证过程，各阶段的测试对象对应于相应开发阶段所要分析的对象。规的集成测试必须是基于接口的，因为程序
3、设计是根据接口一层一层细化，集成时也只需考察接口。基于接口的集成测试只关注接口的正确性，而不关注函数过程执行的正确性。函数执行过程的正确性应该属于单元测试畴，集成测试再关注这个意味着重复，工作量也异常庞大，最终也导致集成测试可操作性差，且失去重点。只关注接口的另一个好处理是：考察点清晰，截取变量的值便可实现自动测试，否那么，基于过程的测试最终因函数过程千差万异，而使自动测试无法实现。另外，代码经常在变，而接口相对稳定，基于接口的测试保证较好的可继承性。还有，脱离千差万别的过程，使得整个测试不过分的依赖于测试者的个人素质，该操作是易用易推广的。基于接口的集成测试是规的测试，而非调试。之所以要把集
4、成测试与调试严格区分，一方面是因为调试过程不是规的，随机因素很多，批量的测试实现不了，测试结果无法自动比拟，可重复的过程也不能实现；另一方面，调试效果因人而异，调试方法并非可拷贝的。1.2.3 度量集成测试效果量化测试效果一方面为了控制质量，另一方面是为了改良，在集成测试中后者更为重要。集成测试方法是黑盒的，只关注输入输出，假设没有指标度量，测试程度无从了解，测试质量就失控了。所以，作为一条规那么，集成测试需要提供覆盖指标。在覆盖分析中能直观的看到哪些代码未被覆盖，可以有针对性的再作测试，这样的集成测试过程是可改良的过程，保证了测试效率。2、入口准那么集成测试的入口准那么已在?DP0070-软
5、件集成测试过程?中定义，下面描述几项重要规那么。集成测试首先要求被测对象具备根本的稳定性，联调要通过，否那么集成测试将无法做起。另外，环境物料应有充分的保障，这在集成测试前几个月就得准备。在软件设计阶段应同步编写集成测试方案，定义各个组件的集成级别，考虑各功能模块的集成方法。这点很重要，集成测试需要一系列条件，应该事先考虑好集成策略，桩模块如何搭建，驱动模块如何设计，测试代码与源代码如何接口，特殊情况还需考虑外来的数据驱动如何实现，比方：板集成测试时，被测对象赖以启动的配置数据如何得到，板间或子系统集成时考虑的因素将更多。集成测试方案不仅要规划被测容，也要标识各子项的轻重缓急、重要程度，用以指
6、导后继的测试设计与测试操作。做完集成测试方案后，需要与产品设计相结合，同步开展可测性设计，预留集成测试接口，开场设计、实现测试代码。如果此项工作未同步开展，后期编码完成了才考虑集成测试的接口，满足不了需求再去修改设计将给系统带来很大伤害。具备一定素质的测试人员也是集成测试的一项重要入口准那么，按照经历，集成测试中是否具备一定技术能力、有无集成测试经历，对最终的测试效果影响很大。进展集成测试的操作者最好是被测对象的正规检视者方案、设计与代码审查。3、关键活动本节描述集成测试过程的关键活动包括：制定集成测试方案集成测试风险分析集成测试方案设计集成测试工具设计和调研集成测试接口分析与测试用例设计集成
7、测试操作集成测试报告评审3.1 制定集成测试方案集成测试方案应在设计阶段完成，一般情况下，概要设计完毕时，集成测试方案也应完成。集成测试方案规划了今后的集成测试容、测试方法以及可测性接口，以后所有集成测试均在该方案的框架下进展，所有，制定一份完善的集成测试方案非常重要。制定集成测试方案之前需要进展充分的调研，调研的主要容包括：1调研集成测试容，确定哪些功能模块需要进展集成测试2关键模块的集成策略拟定3关键模块的集成测试接口与驱动条件分析4依据集成策略需要进展的测试设计与工具调研、开发5集成测试进度方案6集成测试需要的环境物料考虑3.1.1 调研集成测试容调研集成测试容，应在软件总体测试方案的框
8、架下，综合考虑单元测试、性能测试、系统测试的工作安排。以下提供一般性的建议：A、考虑集成的层次，在函数的调用与被调用关系中，集成测试对象应尽量选取上层，过于底层测试的往往会产生低效劳动。B、考虑软件的层次，集成测试不应测试单元测试测过的容，系统测试能测到的容，应定义低优先级，典型的如 MPU 板的业务处理，处理单板的应用层，系统测试即能覆盖大局部语句，在一般情况下不必作为集成测试容。C、考虑软件复杂度，越复杂的也越容易出错，也越需要进展集成测试。D、考虑被测模块的重要性，在系统中处于核心位置或关键地置，即使复杂度不高，也需作重点测试。确定集成测试对象，还需分配该项的测试的集成级别，集成级别用于
9、标识任务的重要程度，标识集成级别为后继工作提供指导。E、权衡投入产出，在有限资源条件下选取恰当的测试集。特别是某些被集成子对象之间互不相干时，不应作为测试容。比方：网接续与板其它功能进展集成测试时，查看控存也是一项应用层功能，但该业务不修改业务状态，也不作备份，对其它应用层功能除了性能不再有其它影响，这时集成测试时就可以不考虑该项功能。F、考虑可测性，此项考虑的优先级应低于测试需求，难测的工程应尽可能去测，在可测试性上多下功夫。3.1.2 关键模块的集成策略拟定集成策略可分三类：一是自下而上式，被测试对象从底层一级一级往上叠加，集成测试也一级一级的进展，这种做法的好处是不需编写桩函数，构造出的
10、环境较真实，是最常用的一种方法。二是自上而下式，顶层是真实的驱动，桩函数需自己编写，这种方法适用于上层设计较复杂而下层较为清晰简单的场合。第三类是介于上两者之间，被测对象的上层驱动与底层桩函数都需自己构造，这种应用较为少见。如果对系统进展集成，对被测对象的特性严密相关，如何集成是方法，目的是要以最小的投入获得最正确的效益，应尽可能保证系统的真实性的前提下减少测试代码编写。3.1.3 关键模块的集成测试接口与驱动条件分析集成测试接口应选择在具有明显层次性的地方，这样的接口通常是清晰的，接口清晰使得测试驱动与结果监测变得简捷，这对集成测试构造有着莫大的好处。集成测试应具备清晰的层次性，但这种层次不
11、宜过多，以CC08机的单板为例，集成的层次应控制在34层为宜，如：链路处理、传输层、板关键业务的相互关系、同一业务的多板多个子系统间集成。分析集成测试接口主要考虑几点：A. 驱动集成测试需要具备哪些接口条件，如：需要下发哪些驱动命令，命令怎么发下去，变量值怎么报上来。B. 兼容性考虑，尽可能少的破坏系统原有构造，且有良好的可扩展性。C. 监测试点需要具备一定的稳定性，因为集成测试不只测试一次，易变的接口对重复测试不利。3.1.4 依据集成策略需要进展的测试设计与工具调研、开发集成策略与测试接口分析清楚后，应考虑如何进展测试设计，另外还得考虑是否已有适宜的测试工具，未有工具应考虑调研后外购或自行
12、开发。此项工作需在设计阶段考虑清楚，因为测试工具与集成对象接口，如果要做集成测试了才考虑这些，被测对象未必有适宜的接口预留，如果再去修改程序麻烦就大了。如何进展测试设计与工具调研、开发，详见3.4 小节容。3.1.5 集成测试进度方案制定集成测试进度方案考虑以下情况：A. 考虑集成测试被测试对象数量，即工作量B. 关键模块进度安排应多留时间，宁可牺牲不重要模块的测试也不要牺牲重要模块的测试质量。C. 考虑集成测试难度与风险，难度大风险高的模块应多预留时间D. 考虑测试者的整体技术水平E. 考虑测试工具调研或开发的时间F. 给集成测试设计预留出足够的时间G. 结合开发方案，要有一定的风险估计3.
13、1.6 集成测试需要的环境物料考虑测试物料与怎么测有关，制定集成测试方案后测试思路清晰了，相关的物料方案需要做出来，因为申购物料需要时间，物料需在集成测试启动前到位。3.2 集成测试风险分析集成测试需要较多的条件才能开展，具有较高的风险，所以在启动集成测试前要做充分的风险分析。主要考虑以下方面：A、代码是否具有足够的稳定性，接口是否具有根本的稳定性。B、集成测试方案在现有人力物力条件下是否可行。C、集成测试是否支持重复测试，不支持重复测试的集成方案应严格受控。D、集成测试方法是否基于接口。E、是否采用覆盖工具，工具的使用效果如何。F、测试者是否具备一定的技术水平，是否已有集成测试经历。G、测试
14、中是否有足够的技术支援风险分析报告需经过专家评审，一般情况下风险分析与集成测试方案一同递交评审，评审结论还要有跟踪解决。3.3 集成测试方案设计集成测试方案要实现集成测试的3个关键目标，即：实现可重复测试、基于接口测试、以覆盖指标衡量测试质量，集成测试方案围绕这三个目标来构造。一个典型的集成测试系统，如图1所示，测试管理系统位于被测系统之外的独立系统，它与被测单板通过网口或串口或其它通道联接，测试用例管理模块主要完成测试用例设计与维护，测试过程控制模块通过脚本完成测试过程控制。测试管理系统下发测试驱动命令，发送到被测单板的驱动模块，再由驱动模块驱动被测系统正常运行，运行结果的采集也通过驱动模块
15、完成，采集的结果发送到测试管理系统用于判断测试结果是否正确。图 1集成测试系统例如采集运行结果需要设置监测点，监测点数量多少要视被测对象的接口特性，接口简单的，监测点就少，反之监测点多。一般情况下，一个监测点就是一个全局变量或一个消息，我们不建议把局部变量作为监测点，因为局部变量在函数定义，也只在函数生效，监测局部变量是单元测试的畴，此外，要监测局部变量需修改被测试系统，这不是我们所希望的，我们应尽可能保证被测系统的真实性。对消息的监测，往往需要修改接收消息函数，我们需要捕获特定队列、特定特性的消息，实现起来较为容易。因为监测的对象是变量或消息，测试结果比拟相对简单不象系统测试，监测对象是GU
16、I界面或一段文字输出或特定设备特定动作，集成测试的自动化还是比拟容易实现的。被测代码还需要插装以支持覆盖率统计，这局部工作最好用商用工具实现。覆盖指标中我们主要关心两项：语句覆盖与分支覆盖。路径覆盖与数据流覆盖因测试难度较大，一般情况下可不作要求。进展覆盖测试还需注意插装对代码运行效率的影响，缺少硬件支持打点取样的系统在插装前与插装后的运行效率能有数倍或数十倍的差异，这一点需注意，对运行效率有要求的被测系统，插装围应有所控制。对运行效率有严格要求的系统，应采用硬件支持打点取样的工具，如CodeTEST。制定集成测试方案需要审核被测系统的真实性，因为驱动模块、桩函数设计，驱动命令发送与监测点捕获
17、都需修改程序，修改前后可能会给被测对象带来差异，尤其是参加被测代码，调度方式可能会产生改变，规划集成测试方案时需对这些差异进展祥细的评估，否那么，差异过大的测试最终可能导致无效的劳动。制定集成测试方案还需对测试围界定，集成是某一层次的集成，处于被测对象下层与上层的代码测不到，需明确的作出说明或评估，为更上一层的集成测试或系统测试提供效劳。集成测试应考虑为性能测试提供方便，某些情况下，集成测试的构造与性能测试是一样的，采用不同的脚本即能完成这两项测试。3.4 集成测试工具设计和调研根据上述测试框架，集成测试有两类测试工具需考虑，一类是驱动被测系统以及截取结果分析的工具，另一类是覆盖率测试工具。第
18、一类工具因被测试系统是千变万化的，驱动模块、桩函数和监测点的捕获没有现成的商用工具可用，但后台的测试管理系统只要接口兼容性好，多数情况可重用。值得一提的是，利用商用脚本语言如 TCL构造驱动模块与桩函数能提高测试效率。第二类工具我们有许多商用工具可调研，覆盖工具应用不同的被测系统有不同的选择，我们应优先调研商用工具，如没有适宜的才考虑开发。调研覆盖工具需关注工具的易用性与强健性，因插装打点过程较复杂，还依赖特定的语法分析器，许多商用工具较难用或不稳定。3.5 集成测试接口分析与测试用例设计测试用例设计是开展集成测试的根底，而测试接口分析是测试用例设计的根底。我们以接口特性考察被测对象，接口特性
19、又从需求分析派生，所以接口分析时，我们要关注接口特性对需求描述的符合度，即，我们把所分析的接口特性叠加就能较完整的表达需求或该需求的某一子项。接口分析需要罗列我们关心的接口，给出程序中对应的变量名，然后考虑如何驱动或监测。如表1所示：表1：接口分析表样例类别属性对应变量驱动或监测试方法表1中类别用来概括一种接口，如网接续集成测试中，应用层发起连网、拆网命令，这是一个接口类，假设链路层已仿真掉，对被测系统链路接口也是一个接口类。表1中属性是指一个接口类下的各种属性，如网接续接口下有：连网申请、拆网申请、成功或失败指示，控存值等属性，这些属性在程序中都有对应变量，这些变量是我们用以驱动测试或监测运
20、行状态的对象。驱动或监测方法用来描述测试中如何使用该变量，如对于连网申请，我们可以在模拟一个时隙申请的消息放到指定队列，时隙是否申请成功，我们可以观察标识控存的变量。分析完接口特性，我们就对如何驱动被测对象与如何捕获动行结果有着清晰认识，这时可以开场设计测试用例了。测试用例应以规的脚本描述，设计时应充分考虑用例的可扩展性，并考虑将来接口的可能变化。至于如何设计完善的测试用例不在本文描述之列，但提供覆盖分析的测试对测试用例设计有直接的指导，哪个分支没覆盖到，就针对的设计用例让它覆盖到。3.6 集成测试操作集成测试的主要工作量应在测试代码编写以及测试用例设计与调试上，实际的集成测试操作应占很小一局
21、部时间，因为测试过程是自动执行的。因为集成测试发现问题后定位是直接的，更改流程应支持较快的版本更新，因为覆盖率的上升最终取决于正确执行测试用例后的结果，而且，某种情况下，程序中有不可达代码，需删除该代码才能提高覆盖率。集成测试不能象系统测试那样一个版本完毕才出下一版本，是因为集成测试是对局部功能集成，版本基线较少受之影响，此外，不象系统测试，集成测试主要过程不在测试操作，不提高版本更新频度将影响测试效率。集成测试也并非全部完成测试代码或用例设计才可以上手操作，实际上能让局部测试用例转起来，测试操作就可以开场了，测试代码编写、测试用例设计、测试操作可以并行着做。实际上，不停的调试测试用例同时就是
22、一个测试过程，而且这局部时间占整个操作过程的大局部。因为插装过程较为繁琐，调试时我们可不必插装代码。与其它测试类似，集成测试需要随时记录异常情况，定期汇报总结以期改良。3.7 集成测试报告评审集成测试报告评审是对整个测试过程进展审核，对测试结果的正确性、测试覆盖率作评价，此外，评审还对集成测试执行过程、方案完成情况以及集成测试方案、方案等进展确认。需要确认的容参见?集成测试报告评审CheckList?。4、方法和工具 TCL 语言，参考相关工具说明。 LogiScope ，参考相关工具说明。 CodeTEST ，参考相关工具说明。 HindSight ，参考相关工具说明。5、出口准那么完成集成测试报告通过集成测试报告评审完成?集成测试任务总结报告?
