软件集成测试指导方案

1、集成测试操作指导书1、简介1.1集成测试的关键目标由于集成测试所处层次、检验对象与单元测试、系统测试有着很大的差异,其操作方法与检验标准也有所不同.首先,集成测试必须是可重复的.在产品的生命周期中软件维护贯穿始终,不停的修改代码成为必然,仅考虑一次操作的集成测试是一种低效劳动,而且集成测试处于系统的中间层次与单元测试与系统测试不同,需要编写一系列测试代码,操作难度也较大,所以构造可重复的集成测试过程是保证低投入高产出的前提.其次,集成测试必须是标准的操作.代码千差万别,有简单的有复杂的、有标准性好的与标准性差的,如何保证不同的代码有相同的测试效果.测试者的素质也千差万别,有经验的与没经验的,水

2、平强的与水平弱的,测试效果大不一样.要保证集成测试是可操作的、可推广的,需要解决这些问题.另外,集成测试还需是可度量的.不可度量的测试往往意味着失控,质量与进度得不到保证,尤其对于集成测试,有一定难度,执行起来差异很大,更需要对测试效果进行度量.在提供覆盖分析的测试中,我们可以直观的看到哪些代码覆盖到了,哪些代码没覆盖到,再有针对的设计测试用例,这种白盒的方法,有力保证了高效测试.以上三点是集成测试首先要解决的问题,也是集成测试的关键目标,如下：关键目标1:构造可重复的集成测试过程关键目标2:定义标准的集成测试操作关键目标3:度量集成测试效果1.2达成关键目标的对策1.2.1 构造可重复的集成

3、测试过程构造可重复的测试过程依赖自动测试工具,使用自开工具是一种手段,目标是构造可重复过程,在达成此目标的前提下,是否使用工具视具体情况,所以使用自开工具很重要,但非必须.一个理想的集成测试工具应具备以下特征：1、用标准的格式下称脚本记录测试用例,测试执行在脚本限制下进行.2、能方便的维护测试用例.要标识测试用例,能方便的扩充、修改用例.3、支持测试过程治理,包括起停限制,测试过程记录,执行中的异常处理.4、支持测试结果自动分析.基于消息处理的被测系统中,测试驱动可以简化,构造出驱动消息放到指定队列.自动测试结果分析首先要截取程序变量,然后发送到测试治理模块在脚本限制下完成比拟.1.2.1定义

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

5、的集成测试只关注接口的正确性,而不关注函数过程执行的正确性.函数内执行过程的正确性应该属于单元测试范畴,集成测试再关注这个意味着重复,工作量也异常庞大,最终也导致集成测试可操作性差,且失去重点.只关注接口的另一个好处理是：考察点清楚,截取变量的值便可实现自动测试,否那么,基于过程的测试最终因函数过程千差万异,而使自动测试无法实现.另外,代码经常在变,而接口相对稳定,基于接口的测试保证较好的可继承性.还有,脱离千差万别的过程,使得整个测试不过分的依赖于测试者的个人素质,该操作是易用易推广的.基于接口的集成测试是标准的测试,而非调试.之所以要把集成测试与调试严格区分,一方面是由于调试过程不是标准的

6、,随机因素很多,批量的测试实现不了,测试结果无法自动比拟,可重复的过程也不能实现；另一方面,调试效果因人而异,调试方法并非可拷贝的.1.2.3度量集成测试效果量化测试效果一方面为了限制质量,另一方面是为了改良,在集成测试中后者更为重要.集成测试方法是黑盒的,只关注输入输出,假设没有指标度量,测试程度无从了解,测试质量就失控了.所以,作为一条规那么,集成测试需要提供覆盖指标.在覆盖分析中能直观的看到哪些代码未被覆盖,可以有针对性的再作测试,这样的集成测试过程是可改良的过程,保证了测试效率.2、入口准那么集成测试的入口准那么已在?DP0070软件集成测试过程?中定义,下面描述几项重要规那么.集成测

7、试首先要求被测对象具备根本的稳定性,联调要通过,否那么集成测试将无法做起.另外,环境物料应有充分的保证,这在集成测试前几个月就得准备.在软件设计阶段应同步编写集成测试方案,定义各个组件的集成级别,考虑各功能模块的集成方法.这点很重要,集成测试需要一系列条件,应该事先考虑好集成策略,桩模块如何搭建,驱动模块如何设计,测试代码与源代码如何接口,特殊情况还需考虑外来的数据驱动如何实现,比方：板内集成测试时,被测对象赖以启动的配置数据如何得到,板间或子系统集成时考虑的因素将更多.集成测试方案不仅要规划被测内容,也要标识各子项的轻重缓急、重要程度,用以指导后继的测试设计与测试操作.做完集成测试方案后,需

8、要与产品设计相结合,同步开展可测性设计,预留集成测试接口,开始设计、实现测试代码.如果此项工作未同步开展,后期编码完成了才考虑集成测试的接口,满足不了需求再去修改设计将给系统带来很大伤害.具备一定素质的测试人员也是集成测试的一项重要入口准那么,根据经验,集成测试中是否具备一定技术水平、有无集成测试经验,对最终的测试效果影响很大.进行集成测试的操作者最好是被测对象的正规检视者方案、设计与代码审查.3、关键活动精心整理本节描述集成测试过程的关键活动包括：制定集成测试方案集成测试风险分析集成测试方案设计集成测试工具设计和调研集成测试接口分析与测试用例设计集成测试操作集成测试报告评审3.1 制定集成测

9、试方案集成测试方案应在设计阶段完成,一般情况下,概要设计结束时,集成测试方案也应完成.集成测试方案规划了今后的集成测试内容、测试方法以及可测性接口,以后所有集成测试均在该方案的框架下进行,所有,制定一份完善的集成测试方案非常重要.制定集成测试方案之前需要进行充分的调研,调研的主要内容包括：1调研集成测试内容,确定哪些功能模块需要进行集成测试2关键模块的集成策略拟定3关键模块的集成测试接口与驱动条件分析4依据集成策略需要进行的测试设计与工具调研、开发5集成测试进度方案精心整理6集成测试需要的环境物料考虑3.1.1 调研集成测试内容调研集成测试内容,应在软件总体测试方案的框架下,综合考虑单元测试、

10、性能测试、系统测试的工作安排.以下提供一般性的建议：A、考虑集成的层次,在函数的调用与被调用关系中,集成测试对象应尽量选取上层,过于底层测试的往往会产生低效劳动.B、考虑软件的层次,集成测试不应测试单元测试测过的内容,系统测试能测到的内容,应定义低优先级,典型的如MPU板的业务处理,处理单板的应用层,系统测试即能覆盖大局部语句,在一般情况下不必作为集成测试内容.C、考虑软件复杂度,越复杂的也越容易出错,也越需要进行集成测试.D、考虑被测模块的重要性,在系统中处于核心位置或关键地置,即使复杂度不高,也需作重点测试.确定集成测试对象,还需分配该项的测试的集成级别,集成级别用于标识任务的重要程度,标

11、识集成级别为后继工作提供指导.E、权衡投入产出,在有限资源条件下选取恰当的测试集.特别是某些被集成子对象之间互不相干时,不应作为测试内容.比方：网接续与板内其它功能进行集成测试时,查看控存也是一项应用层功能,但该业务不修改业务状态,也不作备份,对其它应用层功能除了性能不再有其它影响,这时集成测试时就可以不考虑该项功能.F、考虑可测性,此项考虑的优先级应低于测试需求,难测的工程应尽可能去测,在可测试性上多下功夫.精心整理3.1.2 关键模块的集成策略拟定集成策略可分三类：一是自下而上式,被测试对象从底层一级一级往上叠加,集成测试也一级一级的进行,这种做法的好处是不需编写桩函数,构造出的环境较真实

12、,是最常用的一种方法.二是自上而下式,顶层是真实的驱动,桩函数需自己编写,这种方法适用于上层设计较复杂而下层较为清楚简单的场合.第三类是介于上两者之间,被测对象的上层驱动与底层桩函数都需自己构造,这种应用较为少见.如果对系统进行集成,对被测对象的特性紧密相关,如何集成是方法,目的是要以最小的投入获得最正确的效益,应尽可能保证系统的真实性的前提下减少测试代码编写.3.1.3 关键模块的集成测试接口与驱动条件分析集成测试接口应选择在具有明显层次性的地方,这样的接口通常是清楚的,接口清楚使得测试驱动与结果监测变得简捷,这对集成测试构造有着莫大的好处.集成测试应具备清楚的层次性,但这种层次不宜过多,以

13、CC08机的单板为例,集成的层次应限制在34层为宜,如：链路处理、传输层、板内关键业务的相互关系、同一业务的多板多个子系统间集成.分析集成测试接口主要考虑几点：A.驱动集成测试需要具备哪些接口条件,如：需要下发哪些驱动命令,命令怎么发下去,变量值怎么报上来.精心整理B.兼容性考虑,尽可能少的破坏系统原有结构,且有良好的可扩展性.C监测试点需要具备一定的稳定性,由于集成测试不只测试一次,易变的接口对重复测试不利.1.1.4 依据集成策略需要进行的测试设计与工具调研、开发集成策略与测试接口分析清楚后,应考虑如何进行测试设计,另外还得考虑是否已有适宜的测试工具,未有工具应考虑调研后外购或自行开发.此

14、项工作需在设计阶段考虑清楚,由于测试工具与集成对象接口,如果要做集成测试了才考虑这些,被测对象未必有适宜的接口预留,如果再去修改程序麻烦就大了.如何进行测试设计与工具调研、开发,详见3.4小节内容.1.1.5 集成测试进度方案制定集成测试进度方案考虑以下情况：A.考虑集成测试被测试对象数量,即工作量B.关键模块进度安排应多留时间,宁可牺牲不重要模块的测试也不要牺牲重要模块的测试质量.C考虑集成测试难度与风险,难度大风险高的模块应多预留时间D.考虑测试者的整体技术水平E考虑测试工具调研或开发的时间F.给集成测试设计预留出足够的时间G.结合开发方案,要有一定的风险估计1.1.6 集成测试需要的环境

15、物料考虑测试物料与怎么测有关,制定集成测试方案后测试思路清楚了,相关的物料方案需要做出来,由于申购物料需要时间,物料需在集成测试启动前到位.3.2 集成测试风险分析集成测试需要较多的条件才能开展,具有较高的风险,所以在启动集成测试前要做充分的风险分析.主要考虑以下方面：A、代码是否具有足够的稳定性,接口是否具有根本的稳定性.B、集成测试方案在现有人力物力条件下是否可行.C、集成测试是否支持重复测试,不支持重复测试的集成方案应严格受控.D、集成测试方法是否基于接口.E、是否采用覆盖工具,工具的使用效果如何.F、测试者是否具备一定的技术水平,是否已有集成测试经验.G、测试中是否有足够的技术支援风险

16、分析报告需经过专家评审,一般情况下风险分析与集成测试方案一同递交评审,评审结论还要有跟踪解决.3.3 集成测试方案设计集成测试方案要实现集成测试的3个关键目标,即：实现可重复测试、基于接口测试、以覆盖指标衡量测试质量,集成测试方案围绕这三个目标来构造.一个典型的集成测试系统,如图1所示,测试治理系统位于被测系统之外的独立系统,它与被测单板通过网口或串口或其它通道联接,测试用例治理模块主要完成测试用例设计与维护,测试过程限制模块通过脚本完成测试过程限制.测试治理系统下发测试驱动命令,发送到被测单板的驱动模块,再由驱动模块驱动被测系统精心整理正常运行,运行结果的采集也通过驱动模块完成,采集的结果发

17、送到测试治理系统用于判断测试结果是否正确.图1采集运行结果需要设置监测点,监测点数量多少要视被测对象的接口特性,接口简单的,监测点就少,反之监测点多.一般情况下,一个监测点就是一个全局变量或一个消息,我们不建议把局部变量作为监测点,由于局部变量在函数内定义,也只在函数内生效,监测局部变量是单元测试的范畴,止匕外,要监测局部变量需修改被测试系统,这不是我们所希望的,我们应尽可能保证被测系统的真实性.对消息的监测,往往需要修改接收消息函数,我们需要捕获特定队列、特定特性的消息,实现起来较为容易.由于监测的对象是变量或消息,测试结果比拟相对简单不象系统测试,监测对象是GUI界面或一段文字输出或特定设

18、备特定动作,集成测试的自动化还是比拟容易实现的.被测代码还需要插装以支持覆盖率统计,这局部工作最好用商用工具实现.覆盖指标中我们主要关心两项：语句覆盖与分支覆盖.路径覆盖与数据流覆盖因测试难度较大,一般情况下可不作要求.进行覆盖测试还需注意插装对代码运行效率的影响,缺少硬件支持打点取样的系统在插装前与插装后的运行效率能有数倍或数十倍的差异,这一点需注意,对运行效率有要求的被测系统,插装范围应有所限制.对运行效率有严格要求的系统,应采用硬件支持打点取样的工具,如CodeTEST制定集成测试方案需要审核被测系统的真实性,由于驱动模块、桩函数设计,驱动命令发送与监测点捕获都需修改程序,修改前后可能会

19、给被测对象带来差异,尤其是参加被测代码,调度方式可能会产生改变,规划集成测试方案时需对这些差异进行祥细的评估,否那么,差异过大的测试最终可能导致无效的劳动.精心整理制定集成测试方案还需对测试范围界定,集成是某一层次的集成,处于被测对象下层与上层的代码测不到,需明确的作出说明或评估,为更上一层的集成测试或系统测试提供效劳.集成测试应考虑为性能测试提供方便,某些情况下,集成测试的构造与性能测试是相同的,采用不同的脚本即能完成这两项测试.3.4 集成测试工具设计和调研根据上述测试框架,集成测试有两类测试工具需考虑,一类是驱动被测系统以及截取结果分析的工具,另一类是覆盖率测试工具.第一类工具因被测试系

20、统是千变万化的,驱动模块、桩函数和监测点的捕获没有现成的商用工具可用,但后台的测试治理系统只要接口兼容性好,多数情况可重用.值得一提的是,利用商用脚本语言如TCL构造驱动模块与桩函数能提升测试效率第二类工具我们有许多商用工具可调研,覆盖工具应用不同的被测系统有不同的选择,我们应优先调研商用工具,如没有适宜的才考虑开发.调研覆盖工具需关注工具的易用性与健壮性,因插装打点过程较复杂,还依赖特定的语法分析器,许多商用工具较难用或不稳定.3.5 集成测试接口分析与测试用例设计测试用例设计是开展集成测试的根底,而测试接口分析是测试用例设计的根底.我们以接口特性考察被测对象,接口特性又从需求分析派生,所以

21、接口分析时,我们要关注接口特性对需求描述的符合度,即,我们把所分析的接口特性叠加就能较完整的表达需求或该需求的某一i子项.精心整理接口分析需要罗列我们关心的接口,给出程序中对应的变量名,然后考虑如何驱动或监测.如表1所示：表1:接口分析表样例类别属性对应受量驱动或监测试方法表1中类别用来概括一种接口,如网接续集成测试中,应用层发起连网、拆网命令,这是一个接口类,假设链路层已仿真掉,对被测系统链路接口也是一个接口类.表1中属性是指一个接口类下的各种属性,如网接续接口下有：连网申请、拆网申请、成功或失败指示,控存值等属性,这些属性在程序中都有对应变量,这些变量是我们用以驱动测试或监测运行状态的对象.驱动或监测方法用来描述测试中如何使用该变量,如对于连网申请,我们可以在模拟一个时隙申请的消息放到指定队列,时隙是否申请成功,我们可以观察标识控存的变量.分析完接口特性,我们就对如何驱动被测对象与如何捕获动行结果有着清楚熟悉,这时可以开始设计测试用例了.测试用例应以标准的脚本描述,设计时应充分考虑用例的可扩展性,并考虑将来接口的可能变化.至于如何设计完善的测试用例不在本文描述之列,但提供覆盖分析的测