嵌入式软件语句覆盖率测试插桩技术

合集下载

基于多维度覆盖率的嵌入式软件测试分析方法

基于多维度覆盖率的嵌入式软件测试分析方法

基于多维度覆盖率的嵌入式软件测试分析方法软件程序规模与复杂程度的增长增加了软件应用的不确定性。

为有效保证软件质量,软件测试逐渐成为软件研发中成本最高的项目。

软件测试能力、测试效率及测试特点的动态跟踪与定量分析,以及软件测试的持续优化成为目前软件研发中最为迫切需要解决的问题。

目前软件测试的研究侧重于如何开展测试过程组织、具体测试方法等,测试评价主要围绕软件缺陷报告、缺陷跟踪与测试进度评价等方面,缺少对软件的动态跟踪及在线评价。

导致软件测试中经常出现测试过程按照测试计划开展,但由于测试用例较大导致测试执行有效性缺失的问题,很难在测试过程中发现测试软件薄弱点。

根据这一问题,提出基于多维度覆盖率的嵌入式软件测试分析方法。

多维度覆盖率的度量方法主要以各种覆盖率分别统计,充分度量测试软件,满足测试充分性原则的同时,综合利用多维度测试覆盖率动态变化特征,对测试方法与测试用例效果及薄弱点进行动态跟踪。

多维度覆盖指标以分支覆盖、条件覆盖、语句覆盖及c-use覆盖等十余种测试覆盖度量为指标,根据测试覆盖的不同,从多角度反映软件测试条件。

利用多维度覆盖率做出软件测试,试图从多方面阐述软件应用情况。

1 基于多维度覆盖率的嵌入式软件测试分析方法1.1 软件测试多维度覆盖率软件测试覆盖率作为度量软件测试程度的主要手段,其计算公式为覆盖率(1)式中:item为测试因子实例数。

根据式(1),若要对item覆盖情况进行计算,为从不同角度度量软件测试的充分程度,提出多维度测试覆盖指标,用以表示度量测试充分程度[7]。

根据覆盖率指标,提取其特征属性与度量参数,设覆盖率维度为m,则有m 种测试覆盖率[8]。

由于测试成本与时间的限制,软件测试通常无法达到全覆盖率,根据软件安全关键等级、测试覆盖率难易程度、测试阶段以及开发方法等[9],在软件测试中,当执行完第n item个测试用例后,为表现实际测试覆盖率所达到的期望值,当前满意度可表示为Sat j(m)=(C j(m)/C j)×100%.(2)式中:C j为软件测试覆盖率;C j(m)为当前测试覆盖率C j的当前值,且j=1,…,m。

嵌入式软件覆盖率测试的研究与应用

嵌入式软件覆盖率测试的研究与应用

嵌入式软件覆盖率测试的研究与应用作者:孙陇平来源:《现代电子技术》2014年第18期摘要:覆盖率测试是检验软件测试完整性、充分性的重要方式,这里介绍了覆盖率测试基础理论、覆盖率的测试类型、覆盖率测试工作流程、比较了覆盖率测试工具Bullseye Coverage、LDRA TestBed。

并通过LDRA Testbed测试工具对被测软件程序插装,分析插装程序输出的结果得到语句覆盖率、分支覆盖率等数据,以达到对软件问题的查找和对测试充分性、全面性的验证。

同时给出了Turbo C开发环境下DOS操作系统的嵌入式软件,利用LDRA Testbed进行覆盖率分析和通过查看未覆盖的代码定位软件问题、测试用例覆盖情况的详细步骤。

关键词:嵌入式软件;覆盖率测试; LDRA Testbed;测试方法中图分类号: TN911⁃34 文献标识码: A 文章编号: 1004⁃373X(2014)18⁃0067⁃03Research and application of embedded software coverage rate testingSUN Long⁃ping(Jiangsu Automation Research Institute, Lianyungang 222061, China)Abstract: Coverage testing is an important method to check software integrity and adequacy. This article introduces cover testing theories, testing methods, testing process and compares testing tools, Bullseye Coverage and LDRA TestBed Use testing tool,LDRA Testbed, to instrument tested program, analyze the output of instumentation software to get the data of Statement coverage and branch coverage, and find out the software int question, to check coverage testing adequacy and comprehensiveness. At the same time, it provides the following steps:Embedded software, which running under Turbo developement environment and DOS system, use LDRA Testbed to analyze software coverage, through viewing the code of uncovered prograss to position software problem and check testcase coverage.Keywords: embedded software; coverage rate testing; LDRA Testbed; testing method随着嵌入式设备在越来越多的领域中得到使用,与之相依附的嵌入式软件也得到了快速的发展。

飞行控制软件测试中的插桩技术

飞行控制软件测试中的插桩技术

2009年5月第35卷第5期北京航空航天大学学报Journal of Beijing University of Aer onautics and A str onautics M ay 2009Vol .35 No 15 收稿日期:2008208210 基金项目:国家自然科学基金资助项目(60633010) 作者简介:李跃飞(1984-),男,山西太原人,硕士生,yuefei_17@.飞行控制软件测试中的插桩技术李跃飞 郭君红 白成刚 蔡开元(北京航空航天大学自动化科学与电气工程学院,北京100191) 摘 要:插桩技术是软件测试中常用的关键技术之一.插桩技术应用在飞行控制软件测试中所遇到的一个严重的问题是其带来的额外开销将导致原程序的实时性下降甚至软件的失效.针对该问题,提出了一种基于布尔型存储数组的新的插桩方法.与传统方法相比,该方法优化了插桩的内容,降低了插桩对程序实时性的影响.搭建了一个仿真测试平台并以某型飞行控制软件为实验对象验证了该方法的有效性.实验结果表明该方法大大减少了插桩后程序的运行时间,保证了飞控软件的实时性要求.关 键 词:插桩;软件测试;飞行控制软件;实时性中图分类号:TP 311文献标识码:A 文章编号:100125965(2009)0520580204I n stru m en t a ti on i n fli ght 2con trol software testi n gL i Yuefei Guo Junhong Bai Chenggang Cai Kaiyuan(School of Aut omati on Science and Electrical Engineering,Beijing University of Aer onautics and A str onautics,Beijing 100191,China )Ab s trac t:I nstrumentati on is one of the i m portant techniques in the s oft w are testing .W hen instru menta 2ti on was app lied in the flight 2contr ol s oft w are testing,the real 2ti m e perfor mance of the original s oft w are be 2comes bad even lead t o failure of the s oft w are,due t o the extra s pending on the instrumentati ons .I n vie w of this p r oble m ,a ne w instru mentati on method which is based on the BOOL array used t o st orage the code inf or 2mati on was p resented .Co mpared with traditi onal methods,this ne w method not only op ti m izes the instrumen 2tati on contents but als o reduces the real 2ti m e influence of the instru mentati on on the original s oft w are .A si m u 2lati on test p latf or m was been set up and a certain type of flight contr ol s oft w are was used as the test object .Then,p lenty of ex peri m ents have been done t o de monstrate the effect of the ne w instru mentati on method .The result show that the method greatly reduces the run ti m e of the instru mented p r ogra m which t o ensure the real 2ti m e require ments of the flight 2contr ol s oft w are .Key wo rd s:instrumentati on;s oft w are testing;flight 2contr ol s oft w are;real 2ti m e 飞行控制软件(下文简称飞控软件)是飞行控制系统中最重要的部分之一,飞控软件的质量直接影响着飞机运行的安全和性能.对飞控软件进行严格的测试是保证其质量的必要手段.白盒测试是基于程序源代码级的测试,可以发现在黑盒测试中无法测出的逻辑问题.因此,目前在军工软件、航天航空软件、工业控制软件等具有高可靠性要求的软件领域都需要使用白盒测试的方法对软件进行完整详细的测试.覆盖率和性能是衡量软件质量的重要指标,也是白盒测试的主要内容[1].而程序插桩是实现覆盖率测试的一种重要方法.通过插桩对程序进行动态测试,可以获得程序的覆盖率、运行剖面等信息.插桩技术应用在一些结构简单的规模较小的软件的测试过程中对软件运行的性能的影响不大,但是当面临复杂的软件或恶劣的测试环境时,插桩技术对软件性能的影响将尤为突出[2].程序插桩应用在飞行控制系统这类实时性要求比较高的嵌入式软件测试中一个严重的问题是,由于程序插桩带来的额外开销将增加程序的运行时间,降低程序的实时性,甚至造成系统的失效.其实这个问题不只存在于实时系统中,对于普通软件来说,如果程序规模较大,逻辑复杂,它的插桩点必然很多,导致对软件性能的影响也是无法忍受的,只不过对于实时软件来说,影响要更严重一些.如何降低插桩对原程序运行造成的影响是一个很有意义的问题.目前国内外的一些研究人员已经在做这方面的研究与实验,也提出了一些优化插桩过程的方法,例如文献[3]提出的在可以良好分割的程序的插桩过程中使用探针优化器的方法;文献[4]中提出的在利用支配树的方法分析程序结构的基础上进行插桩优化的方法;文献[5]中提出的动态插桩技术.这些研究的对象都是普通软件,并没有考虑到飞控软件所具有的嵌入式特性和较强的信息交互的特点.本文首先分析了飞控软件的特点,介绍了程序插桩的基本概念.并针对飞控软件所具有的强实时性要求以及飞行控制系统资源相对短缺的特点,研究一种在测试飞控软件时适用的插桩方法.提出了一种基于布尔型信息存储数组的插桩方法,有效的降低了由于程序插桩对原程序的执行效率的影响.并通过进行实验对比的方式验证了该方法的可行性.1 飞行控制软件的特点分析飞行控制软件是典型的嵌入式实时软件,其具体的特性如下:1.1 实时性所谓实时性,即必须满足时间约束的特性.软件的实时性并不是要求处理速度特别的快,关键是准时和及时.对实时性软件而言,其正确性不仅由系统的功能和行为特性决定,还依赖于系统的时间特性.与普通软件相比,时间特性是决定实时软件质量的关键.而飞行控制系统是一个典型的硬实时系统,即处理请求的时间约束异常关键,只要没有满足时间的约束条件就认为系统是失败的.因此飞行控制系统对时间特性的要求很高. 1.2 嵌入特性嵌入式软件系统的一个突出特点在于嵌入式软件的开发环境和运行环境是不一致的.另外,一般的嵌入式系统还都存在资源短缺的问题.正是由于这些原因,给嵌入式软件的测试带来了很多问题.因为即使在宿主机环境下测试再充分,也不能说明在目标机环境下该软件运行不出问题.因而,嵌入式软件还面临着目标环境的测试[6].1.3 复杂性飞行控制软件作为飞行控制系统的核心,在强调安全性的同时,软件中存在大量错误处理与应用级的容错特性,使软件的复杂程度大大提高,其可测性也随之大大降低.软件的容错机制主要出现在例外事件处理、状态恢复、数据的边界值与意外数据处理等部分,在一般的测试过程中很少被执行.很多系统软件缺陷或硬件故障、操作失误等都被软件的大量容错机制所掩盖,导致测试过程中软件缺陷的传播、作用均难以跟踪定位.因此在对飞行控制软件的测试过程中进行覆盖测试是必不可少的.1.4 时序性飞控软件对系统的控制有很强的时序性.是有限状态机系统,即当前的输出控制不仅与当前的输入有关,而且和过去的输入和状态有关.在这样的情况下,系统的实时性达不到要求的话就可能导致一些严重的事故.2 插桩技术程序插桩(p r ogra m instrumentati on),由文献[7]于1978年首次提出.简单的说,插桩方法是借助向被测程序中插入操作来实现测试目的的方法.常常要在程序中插入一些打印语句,其目的在于,希望执行程序时,打印出测试者最为关心的信息.通过这些信息进一步了解执行过程中程序的一些动态特性[7].例如,程序的实际执行路径,特定变量在特定时刻的取值等.程序插桩技术能够按照用户的要求,获取程序的各种信息,称为测试工作的有效手段.在整个这个过程中,插桩的过程是静态的,而数据的收集过程是动态的.基于插桩的动态测试主要有以下3步:①对程序进行静态分析,找出相应的插桩点并插入适当的桩函数;②编译执行插桩后的程序,输出预期的动态测试数据;③对运行时得到的动态数据进行分析计算,例如程序的覆盖率等.程序插桩在实践中的应用非常广泛,主要可以应用在以下这些方面:测试覆盖率和测试用例的有效性度量;断言检测;数据流异常检测;内存使用错误检测;路径智能分解.插桩的关键技术包括确定要获取的信息内容、具体的插桩点位置、桩函数的设计和捕获数据的编码与解码.在软件工程的测试中有一颇为实用的覆盖准则,即当语句覆盖率100%,分支覆盖率≥85%时,认为测试是理想的,软件错误可查出近90%,日本日立公司185 第5期 李跃飞等:飞行控制软件测试中的插桩技术和美国空军均采用此标准.程序插桩是一个联系静态分析与动态测试的关键纽带,在软件测试中占有非常重要的地位.因此,程序插桩在飞控软件这类高可靠性的软件测试过程中是必不可少的.3 飞控软件测试的插桩方法对源程序进行程序插桩必然会对程序的运行造成一定的影响.首先,添加桩程序造成了代码膨胀,增大了执行程序的规模,插桩程序的运行本身有一定的时间消耗;同时插桩程序捕获的数据信息要存入缓存区,对系统的内存也进行了一些消耗,也会影响到系统的性能.这些因素直接导致了程序运行时间的增长.而实时性是实时软件的最重要的特征,对实时软件进行插桩测试则很可能导致软件的失效,那么这样的测试是失败的.所以如何降低程序插桩导致的源程序执行效率的影响,研究一种在实时软件测试中适用的插桩方法是必要的.降低插桩对程序性能的影响,主要可以从以下两个方面着手:优化插桩点的个数;优化桩函数的内容.文献[3-5]中的所提出的方法均是对插桩点的位置和数量进行优化,而本文提出一种在对航天嵌入式软件这一类信息交互量比较大的实时软件进行软件测试时适用的插桩方法.主要是通过对插桩内容的优化来降低插桩对程序执行效率的影响.在飞行控制软件的仿真测试中,主要采用的是Host2Target的测试模式.其中主机(Host)上包括主控平台和信号仿真平台,目标机(Target)上则是飞行控制软件的运行平台.主控平台主要进行测试运行管理、数据分配以及测试后的评估工作.考虑到目标机环境紧凑、资源紧张而主机上资源相对丰富的特点.优化插桩过程的主导思想是尽量减少在目标机上的额外开销,把覆盖率的计算等转移到主机上进行计算.首先,分别在被测的飞控软件和主控程序中声明并初始化两个信息存储数组,其中飞控软件中的数组为布尔型,主控程序中的数组为整形.在飞控软件源程序中插桩点添加信息存储数组中相应元素的赋值语句.并在主控程序中添加整形存储数组的更新函数、程序动态分析和覆盖率的计算等函数.然后在每次信息传送出去后重新初始化该数组.运行程序进行动态测试将得到程序的动态信息,对该数据进行分析并计算程序的实时覆盖率显示直到程序运行结束.整个过程如图1所示.图1 改进后的插桩方法传统的插桩方法都是在插桩点插入事先写好的桩函数,而本方法将插入的是简单的布尔型变量的赋值语句,它不仅本身的运行时间很短,而且还减少了由于函数调用带来的开销.另外,本方法声明的存储数组是布尔型的,与整形数组相比减少了75%的内存占用.当程序规模比较大,插桩点很多的时候,本方法对内存的节省将会降低由于插桩带来的对系统性能的影响.同时,由于存储数组的内容也是要通过网络协议进行传输,使用布尔型存储数组的话可以减少传送的数据量,避免出现因为传送的信息量过大出现的时延现象而导致系统出错.最后,对布尔数组的重新初始化语句放在了控制指令传送语句后面,由于信息传送有一定的时间消耗,因此数组的再次初始化过程将不会对源程序的执行效率产生影响.4 实验对比在这一部分中,将对上一部分提出的插桩方法进行验证评估.4.1 实验内容实验对象为某型飞机的控制软件.在某型飞机的飞行控制软件系统飞行仿真过程中,控制律的程序和全量方程的计算分别运行在目标机的Vx Works操作系统和宿主机的W indows操作系统中.它们之间的相互联系在于控制律程序根据宿主机传来的状态信息产生控制指令,然后把控制指令传送到宿主机,最后经全量方程的计算得出飞行过程中的状态信息,该系统的一个周期为50m s,由这个过程可看出该系统是一个交互性很强的系统.该实验过程中目标机于宿主机之间的285北京航空航天大学学报 2009年 通信采用网络套接字的方式实现.实验平台见图2.图2 仿真实验平台首先,采用上一部分内容所述的插桩方法对控制律程序以及宿主机中的主控程序进行修改.在主控程序中添加一个整型的信息存储数组H [i ],设初值为0;在控制律程序中声明一个布尔型的信息数组T [i ],并设初值为false .其中,H [i]和T [i ]维数相同,均为插桩点的个数;然后修改由目标机向宿主机传送数据的套接字的内容,使其包含目标机存储数组,并在主机程序中添加信息存储数组的更新以及各种覆盖率的运算程序.f or (i =0;i <count;i ++){ H [i ]=H [i ]+T [i ]; if (H [i ]!=0) Coverlines +=L [i ];}CoverageRate =Coverlines/T OT ALL I N ES 将修改后的控制律程序重新编译并下载到Vx Works 操作系统的目标机中运行,主机控制界面将得到覆盖率的实时变化曲线以及各模块的执行次数等动态数据.4.2 实验结果通过3组实验的数据来进行对比、验证本文提出的插桩方法应用在飞行控制软件的测试过程中的时效性.第1组运行的是没有经过插桩的程序;第2组是使用传统插桩方法对源程序进行插桩后的程序;第3组按照前一部分内容对源程序进行插桩后的程序.在主控程序的开始和结束的部分添加获取时间的函数,记录程序运行的总时间.同时,为了更好的体现在实时性上的优势,在试验过程中将注释掉控制程序中的休眠语句,不是50m s 发送一次数据,而是算完以后立刻发送数据.每组实验进行了20轮.试验结果见表1.从上述试验结果可知,使用了本文所提出的插桩方法进行测试的程序运行时间与用传统插桩方法进行测试的程序的运行时间相比,由于程序插桩导致的运行时间的额外开销降低了21.2%.这说明了本文所提出的插桩方法在降低对程序实时性影响的方面是有效的.另外,由于飞控软件的实时性要求,在程序运行过程中某一次运算的超时就将导致实时性的失效.从试验所得的数据可以看出,在一共20轮的实验中,使用本文插桩方法的程序的运行时间标准差相对较小,说明该方法产生的开销相对稳定,出现上述问题的几率较小.这也就从另一方面说明该插桩方法比传统方法更适用于飞控软件的测试过程中.表1 试验数据插桩类型平均运行时间/m s标准差无插桩程序177877.9572.9411传统插桩方法179813.2606.8614本文插桩方法179402.6344.34145 结 论本文首先分析了飞行控制软件所具有的特点,介绍了插桩技术的基本理论和基本方法.然后指出了插桩应用在飞控软件测试中所面临的实时性方面的问题,针对飞控软件的信息交互量比较大的特点,在Host 2Target 仿真测试模式下,提出了一种新的插桩方法,优化了插桩过程,进而降低插桩给源程序带来的实时性方面的影响.最后通过具体的仿真实验验证了该方法的有效性.当然,本文对插桩过程的优化尚需进一步的研究,本文只是在优化插桩内容方面做了一些工作,今后可以在优化插桩数量方面做进一步的研究.参考文献(References )[1]Chen Ts ong Yueh,Kuo Fei Ching,RobertM.On the statisticalp r operties of testing effectiveness measures[J ].Journal of Sys 2te m s and Soft w are,2006,79(5):591-601[2]A rnold M,Ryder B G .A fra mework for reducing the cost of in 2strumented code[J ].Ac m Sigp lan Notices,2001,36(5):168-179[3]Pr obert R L.Op ti m al inserti on of s oft w are p r obes in well 2deli m i 2ted p r ogra m s[J ].I EEE Transacti ons on Soft w are Engineering,1981,8(1):34-42[4]Agrawal H.Dom inat ors,super bl ocks and p r ogra m coverage[C ]//Princi p les of Pr ogra mm ing Languages .Portland:Acm Press,1994:25-34[5]TikirM,Hollings worth J.Efficient instrumentati on f or code cov 2erage testing [J ].Acm Sigs oft Soft w are Engineering Note,2002,27(4):86-96[6]孙昌爱,靳若明,刘超,等.实时嵌入式软件的测试技术[J ].小型微型计算机系统,2000,21(9):920-924Sun Changai,Jin Ruom ing,L iu Chao,et al .Test technol ogy of real 2ti m e and e mbedded s oft w are [J ].M ini 2M icr o Syste m,2000,21(9):920-924(in Chinese )[7]Huang J C .Detecti on of data fl ow anomaly thr ough p r ogra m in 2strumentati on[J ].I EEE Transacti ons on Soft w are Engineering,1979,SE5(3):226-236385 第5期 李跃飞等:飞行控制软件测试中的插桩技术。

通用嵌入式测试平台技术研究

通用嵌入式测试平台技术研究

科技与创新┃Science and Technology&Innovation ·108·2023年第21期文章编号:2095-6835(2023)21-0108-03通用嵌入式测试平台技术研究范义杰1,赵昶宇2(1.陆装驻天津地区军代室,天津300240;2.天津津航计算技术研究所,天津300308)摘要:为了快速构建嵌入式系统的测试平台,并提高嵌入式系统测试平台的通用性、可维护性和可扩展性,提出一种嵌入式系统分层结构的测试平台,将测试平台分为GUI(Graphical User Interface,图形用户接口)层、XML(Extensible Markup Language,可扩展标记语言)层和通信层,利用XML脚本技术的平台及编程语言无关性,建立了嵌入式系统的通用测试平台,提高了嵌入式系统的测试效率和测试准确率。

该方法已在某地面监控设备中得到应用和验证,不仅降低了开发成本,而且提高了代码的通用性和重用率。

关键词:嵌入式系统;软件测试;配置文件;XML脚本技术中图分类号:TP311.52文献标志码:A DOI:10.15913/ki.kjycx.2023.21.032随着当下信息化技术的飞速发展和进步,嵌入式系统的种类日益增多,嵌入式设备的复杂程度也在不断地增长。

由于嵌入式软件一般具有内存空间不够富裕、实时性要求较高、研发专用的测试工具价格昂贵以及与硬件密切相关等特性,目前大多数嵌入式系统都根据本系统中的硬件配置定制专门的测试工具和平台。

这样一来,就会出现不同硬件的嵌入式设备需要开发不同的测试平台,导致测试成本和人力资源的极大浪费。

为快速构建嵌入式系统的测试平台,并提高嵌入式系统测试平台的通用性、可维护性和可扩展性,本文提出一种嵌入式系统分层结构的测试平台,将测试平台分为GUI层、XML层和通信层,利用XML脚本技术的平台及编程语言无关性,建立了嵌入式系统的通用测试平台,提高了嵌入式系统的测试效率和测试准确率。

嵌入式软件覆盖测试

嵌入式软件覆盖测试

嵌入式软件覆盖测试罗西;殷静;王川【摘要】当前,嵌入式软件的应用越来越广泛,人们对嵌入式软件的质量要求也不断提高.通过覆盖测试可以有效验证嵌入式软件测试过程中的功能完好性以及软件存在的相关问题.在进行覆盖测试时,需要借助一定的工具来完成,避免人工作业出现工作量大的问题.通常覆盖测试使用的辅助工具为LDRA Testbed,这种测试工具可以对软件的动态覆盖信息进行有效获取,从而提高软件测试的覆盖率.【期刊名称】《数字技术与应用》【年(卷),期】2017(000)008【总页数】3页(P142-144)【关键词】嵌入式系统;软件测试;覆盖测试【作者】罗西;殷静;王川【作者单位】中国电子科技集团公司第三十二研究所,上海201808;中国电子科技集团公司第三十二研究所,上海201808;中国电子科技集团公司第三十二研究所,上海201808【正文语种】中文【中图分类】TP311.53对软件进行测试时,测试软件的完备性是表征软件质量的重要方面。

所谓测试的完备性不仅包括对任务书和需求规格中的性能和功能进行覆盖,还应该涉及到软件代码的全部语句和所有分支。

其中,覆盖测试就是对软件代码覆盖情况测试的一种有效方式。

这种测试方式在嵌入式软件测试工作中,可以有效避免代码未执行造成的软件问题。

1.1 覆盖测试概念通常也可以把覆盖测试称作逻辑测试。

这种测试方式需要对测试代码本身进行访问,同时对代码进行插桩处理,再根据程序的内部结构完成案例的测试工作。

从原理上将,覆盖测试是一种白盒测试手段。

覆盖测试通常会在软件测试的早期阶段进行,也就是单元测试过程中。

覆盖测试的过程中就是将软件程序的所有代码执行的过程,并且还应该有效覆盖程序的语句以及分支结构,尽量在测试过程中发现隐藏的软件缺陷,从而保证软件的质量。

覆盖测试的基本准则是要求测试用例要尽可能多的覆盖程序的内部逻辑结构,并发现其中存在的错误和问题。

为保证测试工作的充分性和全面性,必要时应该进行补充测试,保证测试效果。

gcc 覆盖率原理

gcc 覆盖率原理

gcc 覆盖率原理GCC 覆盖率原理什么是覆盖率测试?覆盖率测试是一种用于衡量软件测试质量的度量指标,用于测量测试过程中涉及到的代码行、分支、函数和语句的执行情况。

覆盖率测试可以帮助开发人员了解测试的覆盖程度,发现代码中的潜在问题和漏洞。

GCC 的基本原理GCC(GNU Compiler Collection)是一套开源的编译器工具集,覆盖率测试是其中的一个功能。

GCC 的覆盖率测试原理主要包括两个步骤:插桩和收集。

插桩插桩是在源代码中注入一些代码或指令,用于记录程序运行时每个代码块是否被执行过。

GCC 使用特殊的编译选项来进行插桩,这些选项会在编译过程中自动将插桩代码添加到可执行文件中。

收集收集是在程序运行过程中,通过执行插桩代码来收集程序的执行信息。

GCC 使用一些技术手段来收集这些信息,比如在插桩代码中使用计数器来统计代码块的执行次数。

收集的信息可以保存在内存中,也可以保存到文件中供后续分析使用。

使用 GCC 进行覆盖率测试使用 GCC 进行覆盖率测试的基本步骤如下:1.首先,需要在编译选项中添加覆盖率测试的相关选项。

比如,可以使用-fprofile-arcs选项来启用代码块的执行计数器,使用-ftest-coverage选项来启用覆盖率计数器。

2.编译和链接源代码时,使用上述的编译选项来开启覆盖率测试。

3.运行可执行文件,执行覆盖率测试。

4.测试结束后,GCC 会生成一些覆盖率测试的报告或日志文件,包含了代码块的执行情况和覆盖率信息。

覆盖率测试的局限性虽然覆盖率测试是一种有效的测试手段,但仍然存在一些局限性:•覆盖率测试只能检测到代码是否被执行过,无法检测代码执行的正确性。

•覆盖率测试只能检测到已知的代码路径,无法检测到未知路径或未预料到的错误情况。

•覆盖率测试需要运行大量的测试用例才能得到较准确的结果,执行时间可能较长。

总结GCC 的覆盖率测试功能是一种有用的测试工具,可以帮助开发人员了解代码的测试覆盖程度,找出潜在问题和漏洞。

基本路径覆盖测试探针插桩技术研究

基本路径覆盖测试探针插桩技术研究

0 引 言
目前 国 内外 市 场 上 的嵌 入 式 系 统 主 要 采 用 软 硬 件 结 合 的 工 具 测 试 “ 该 类 工 具 从 软 件 部 分 来 说 , 然 是 用 传 统 的 插 桩 , 依
个 判 断和 多 个 循 环 , 能 的路 径 数 目将 会 急 剧 增 长 , 到 天 文 可 达 数字 。 。为 了解 决 这 一 问 题 , 要 制 定 一个 有 效 的 、 销 较 小 需 开 的覆 盖 准 则 对 B F bokcnrl o r h进 行 优 化 处 理 。 C G(l ot w ga ) c of l p 定 义 1 块 控 制 流 图 B F F=N E E t , xt F F n— C G()( , , n yE i: (u c r ) t n为 被 测 函数 集 , i) o N是 程序 块 集 , 基 本 块 和 节 点块 ( 件 判 分 条
t t g ( a pi z t n i rsa c e . T e rb r h t th me f nt l ai ein d a dte i r ue MS e i Z p t o t ai ) s ee rh d h o eai mei a tet iai t n i d s e , n nds i t E sn h mi o p t c i oi i z o s g h tb d
tsi g a d t eman e a c r . e t n i tn n ewo k n h Ke r s p t o e a et si g p o r m sr m e tto ; me s g u u ; CF y wo d : ah c v r g e t ; r g a i t n n u n ai n s a eq e e G; e e d d s f r mb d e o t wa e

嵌入式软件测试技术研究

嵌入式软件测试技术研究

嵌入式软件测试技术研究摘要:随着嵌入式软件结构的日益复杂,嵌入式软件的测试也越来越重要。

在对嵌入式软件的特点以及嵌入式软件测试环境和策略分析的基础上,对嵌入式软件基本测试方法进行了研究。

关键词:嵌入式软件;软件测试技术;静态测试;动态测试0引言随着信息技术的不断发展,与硬件发展日益稳定相比,软件故障却日益突出,因此软件测试的重要性已经越来越被人们所重视。

嵌入式软件有着开发工具昂贵、内存较小、实时性要求较高、CPU种类繁多、I/O通道较少等特点,为此,嵌入式软件的测试也与一般PC 应用软件的测试有很大的差异。

1嵌入式软件测试概述1.1嵌入式软件特点分析嵌入式软件测试的主要目的在于验证软件的可靠性,与通常的PC应用软件相比,嵌入式软件的测试有如下几个特点:①嵌入式软件是针对在特定硬件环境下开发的,其运行和测试也需要依据特定的硬件环境;②实施性要求较高,除了要求有正确的输出结果以外,还需要考虑是否能够在规定的时间内得到运行结果。

1.2嵌入式软件测试环境分析一般采用交叉开发环境来搭建嵌入式软件的测试环境。

例如单元测试、集成测试等可以在PC机上完成的测试,通常都在PC机上进行测试,从而可以避免硬件环境的影响,提高测试效率。

在后期的集成测试中,需要在具体的嵌入式软件硬件环境中,搭建交叉测试环境来完成嵌入式软件的测试。

交叉测试环境的搭建需要注意以下几个方面的内容:(1)主机与目标机之间的通信问题。

可以通过以太网或者串口进行主机与目标机之间的物理连接,主机与目标机之间的数据格式可以预先进行定义。

(2)主机对目标机的测试控制。

主要包括主机如何向目标机发送测试用例,如何跟踪目标机的测试,查看是否正常进行。

(3)目标机测试结果的反馈。

通常运行嵌入式系统的目标机没有视频显示等便利的测试结果输出端口,因此目标机上的异常、错误信息和正常响应信息等测试结果都需要返回到主机上进行显示和输出。

在嵌入式软件测试环境的搭建过程中,需要测试嵌入式系统与已建设备是否协调,硬件设备电气特征是否正常,以及主机与目标机之间的物理信道是否通畅等,从而保证测试结果不受到嵌入式软件以外其它因素的影响。

最新-嵌入式软件的覆盖测试 精品

最新-嵌入式软件的覆盖测试 精品

嵌入式软件的覆盖测试
摘要覆盖测试是验证软件功能结构正确性以及查找问题的非常重要的方法和手段,它要借助一定的工具才能取得较好的效果,满足软件在质量和时间上的双重要求纯粹的人工测试工作量大、不方便、周期长。

如何利用好这方面比较成熟的工具,对其机理的研究及适应性改造是很重要。

本文着重描述这类工具的工作机理,以及对嵌入式软件测试的特殊要求,并以对自主知识产权嵌入式操作系统的测试为例进行说明。

关键词嵌入式操作系统覆盖测试软件测试工具
1概述
软件测试是很广的概念。

从其贯穿软件生命周期全过程来看,测试可分为模块测试、集成测试、系统测试等阶段。

测试还可分为静态检查和动态运行测试两大类。

在动态运行测试中,又可有基于程序结构的白盒测试或称为覆盖测试和基于功能的黑盒测试。

测试不仅关注程序的功能,还有性有测试、强度测试等等。

要达到比较好的测试效果,除了要有周全的测试计划、可控的测试过程、测试人员丰富的经验外,还需要借助一些行之有效的辅助工具,尤其在当今软件规模日益庞大、测试工作量成倍增加的情况下。

对应上述的测试分类情况,测试工具可划分为支持对程序源代码进行静态规则检查和质量评估的静态分析工具、支持对程序单元进行动态覆盖测试的工具、对软件系统的整体运行性能进行测试的工具。

另外,还有一些特殊用途的或专用工具,如协议测试仪、内存检测工具等。

这些工具都有较为成熟的商业化产品,也可通过自行开发的方式获得。

本文具体讨论了对一类特殊的系统软件——嵌入式实时操作系统——进行覆盖测试的情况。

内容涉及对这类软件特性的研究、测试的难点和特点、对现有测试工具的适应性改造和测试实例说明。

2软件覆盖测试。

嵌入式软件测试技术

嵌入式软件测试技术

Software Development Life Cycle (t)
• 在目标板上开发 • 以太网连接 • 费用低
• 在目标板上开发和测试 • 实时性能测试 • 产品质量保证
Slide 11
整理ppt
Copyright McCabe & Associates 1998
嵌入式在线测试的特点:实时,在线,精确
高集成硬件工具 纯软件测试工具 硬件辅助软件测试工具 软件测试+逻辑触发+跟踪分析
软件打点方式(主机+目标机)
比较便宜
对目标系统影响小(1-15%) 不影响目标系统(0%)
可在CACHE打开下工作
不占用目标系统资源
软件打点技术
对目标系统影响大(超过资源如CPU 时间 强大的覆盖率分析
标记就是对物理地址的写信号, 可以被硬件的被动探头检测到。
Slide 17
整理ppt
Copyright McCabe & Associates 1998
附录1:源代码
void {
}Slide 18
draw_fork ( int n , tL_or_R forkSide )
int offset = 0;
Slide 5
整理ppt
Copyright McCabe & Associates 1998
我们早已认识到软件测试重要性 但对于嵌入式软件测试新的困难又出现了!
❖ 软件的测试不如硬件板卡测试普 遍
❖ 测试工作缺乏可度量的管理手段 ❖ 软件的功能性测试不够完善,需
要新的方法的补充。 ❖ 嵌入式系统代码量日益增多,测
交付或乱成一团。 ❖ 更多的电路板,更多的软件,更加复杂!

Testbed常见问题解答

Testbed常见问题解答

常见问题解答目录Testbed使用过程中问题解析 (3)1.如何处理中文? (3)2.如何尽快入门:介绍tutorial (3)3.安装的问题:文字竖排、输入许可、软件狗驱动 (4)4.用户许可无效“Control File Configuration” (4)5.试用版不要更改日期 (4)6.嵌入式系统软件的测试(bitmap插装) (4)7.Testbed的bitmap插装技术 (5)8.单元测试的策略:先黑盒再白盒 (5)9.如何测试unix平台的软件 (6)10.能否测试汇编软件? (6)11.软件工程中软件测试的应用:软件生命期的各个阶段(需要画图) (6)12.介绍三种单元测试模式 (7)13.介绍编码规则检查:MISRA (7)14.白盒测试 (8)15.临时软件狗过期更新问题,读不出序列号。

(8)16.为何Testbed软件的主菜单的Configure下没有命令Reset Compiler Options? (9)17.网络狗的本地使用,如何设置: (9)18.有些朋友会问,你们的产品TESTBED和国外同类测试产品相比,优势在哪? (9)19.VC行命令cl的包含选项/I不支持带空格的路径。

(10)20.testbed系统测试报指定的编译工具和实际编译工具不匹配的现象。

(10)21.类中引用类的错误 (10)22.在C++单元测试中,当前测试事例无法引用前一个测试事例的对象 (11)22.给vc++程序做单元测试时,TBrun分析不出正确的函数原型。

(11)23.在什么情况下才对函数打桩? (11)24.在vxworks环境下做单元测试 (11)25.在vxworks环境下用软件方式作系统测试 (12)26.关于做白盒测试,生成的报告时非常的慢,甚至导致假死现象(28所测评中心)。

.. 13 27.安装testbed后,没有配置当前编译环境就做单元测试,build通不过。

测量嵌入式软件的代码覆盖率

测量嵌入式软件的代码覆盖率

面。

这意味着嵌入式设备的质量非常重要——无论是从安全角度还是从功能安全角度。

对于安全可靠的嵌入式设备,测试是质量保证不可或缺的一部分。

安全关键型软件开发标准对测试方法和测试覆盖率设定了精确要求,这并非没有道理。

通常,应用程序越关键,对代码覆盖率的要求就越高。

最重要的代码覆盖率级别是:语句覆盖率确定测试执行了哪些指令。

可以检测死代码以及尚未创建合适测试的指令。

分支覆盖记录是否所有程序分支都经过测试。

这是应放在测试中的最低要求。

可以通过合理的努力来实现分支覆盖。

MC/DC(Modified CondiTIon/Decision Coverage)是标准要求的最高级别,而且相当复杂。

为了尽量减少测试工作,使用复合条件的所有原子条件。

对于每个原子条件,测试一个测试用例对,导致复合条件的整体结果发生变化,但只有所考虑的原子条件的真值发生变化。

这里其他原子条件的真值必须保持不变。

由于代码检测,代码大小增加为了测量软件的哪些部分已经过测试,使用了代码覆盖分析器。

大多数覆盖分析器的工作原理相同:它们在将代码传递给编译器之前对其进行检测。

这意味着他们将计数器添加到代码中,以计算相关代码部分是否已被执行。

这些计数器通常存储为全局数组。

这种检测的副作用是代码变得更加庞大。

这会给 RAM 和 ROM 带来额外的负载。

该过程如图1 所示:代码覆盖率分析器 Testwell CTC++ 将计数器添加到源代码(“仪器”)。

有关计数器的信息存储在名为“符号数据”的文件中。

在测试期间(图右侧),执行次数被计算并存储在“数据文件”中。

在过程结束时,TestwellCTC++ 的“报告生成器”将“符号数据”和“数据文件”中的信息结合起来生成“覆盖报告”。

覆盖率分析的副作用是更高的内存消耗(通过比较没有和有仪器的所需内存显示在底部)。

点击查看完整大小的图片(来源:Verifysoft Technology)即使是用C 语言编写的一个小的While 条件也可以通过这种方式显着增长。

基于LDRA的嵌入式软件覆盖率测试方法

基于LDRA的嵌入式软件覆盖率测试方法

基于LDRA的嵌入式软件覆盖率测试方法作者:刘春裕,王蕾来源:《电脑知识与技术》2009年第34期摘要:基于实时嵌入式软件的测试经验,针对实时嵌入式软件特点,研究了基于LDRA的嵌入式软件覆盖率测试方法,分析了程序插装BITMAP技术应注意的问题,提出了单文件和多文件两种方式的覆盖率测试方法。

对于嵌入式软件测试,具有实际参考价值。

关键词:程序插装;覆盖率测试;覆盖率分析;BITMAP技术中图分类号:TP391文献标识码:A文章编号:1009-3044(2009)34-9843-03Test of Procedure Cover Based on the LDRA For Embedded SoftwareLIU Chun-yu, WANG Lei(Software Test Center of CSBI, Lianyungang 222006, China)Abstract: On the basis of researching software testing technology and the principle of software instrument, aim at characteristic of real-time embedded system, this thesis researched test of procedure cover based on the LDRA for embedded software. Analyzed the technology of BITMAP for procedure instrument.Raise the single file testing method and the multi file testing method of procedure cover.Key words: procedure instrument; test of procedure cover; coverage analyse; BITMAP1 研究嵌入式软件覆盖率测试的背景与原因软件测试是提高软件质量的一个重要手段,据统计,国外软件开发机构40%的工作量花在软件测试上,软件开发费用的近1/2用于软件测试。

C语言嵌入式软件插桩及动态测试覆盖率信息提取方法[发明专利]

C语言嵌入式软件插桩及动态测试覆盖率信息提取方法[发明专利]

(10)申请公布号 CN 102419731 A(43)申请公布日 2012.04.18C N 102419731 A*CN102419731A*(21)申请号 201110412481.3(22)申请日 2011.12.08G06F 11/36(2006.01)(71)申请人北京控制工程研究所地址100080 北京市2729信箱(72)发明人侯成杰 董燕 郝伟 吴瑾 郭华王翼山(74)专利代理机构中国航天科技专利中心11009代理人安丽(54)发明名称C 语言嵌入式软件插桩及动态测试覆盖率信息提取方法(57)摘要C 语言嵌入式软件插桩及动态测试覆盖率信息提取方法,把C 语言程序看做一个由各分支点组成的数组,每一个分支点对应数组中的一个元素,每个元素定义为两种状态,“1”表示执行过,“0”表示未执行过。

然后将数组定义在专用存储区。

随后在C 语言程序各分支点处,增加向定义在专用存储区的分支点信息数组输出该分支点是否被执行信息的操作代码。

执行增加操作代码以后的C 语言程序,执行完毕后从专用存储区提取分支点信息数组,根据分支点信息数组中各元素的状态即可确定C 语言程序中各分支点的执行情况,由此得到C 语言程序的动态测试覆盖率。

本发明方法具有代码膨胀率小,分支点信息所占存储空间小,覆盖率信息提取方便的特点。

(51)Int.Cl.(19)中华人民共和国国家知识产权局(12)发明专利申请权利要求书 1 页 说明书 4 页 附图 1 页1.C语言嵌入式软件插桩及动态测试覆盖率信息提取方法,其特征在于步骤如下:(1)把C语言程序看做一个由各分支点组成的数组,每一个分支点均对应数组中的一个元素,并把数组中每个元素定义为两种状态,“1”表示执行过,“0”表示未执行过;其中数组的维数与分支点的数量相同,分支点为C语言程序的各种逻辑分支的第一条语句;(2)将数组定义在专用存储区进行存储;(3)在C语言程序各分支点处,增加向定义在专用存储区的分支点信息数组输出该分支点是否被执行信息的操作代码;所述分支点是否被执行信息的操作代码内容为向分支点信息数组中该分支点对应的bit位执行“或”1的操作;(4)在C语言程序main函数的第一条语句处增加对数组进行初始化的操作代码;(5)执行增加操作代码以后的C语言程序,执行完毕后从专用存储区提取分支点信息数组,根据分支点信息数组中各元素的状态即可确定C语言程序中各分支点的执行情况,由此得到C语言程序的动态测试覆盖率。

用于覆盖测试的代码插桩程序设计与实现

用于覆盖测试的代码插桩程序设计与实现

用于覆盖测试的代码插桩程序设计与实现郭锐;李博;彭宝新【摘要】设计了一种用于覆盖测试的代码插桩器.重点介绍了一种高效的词法语法分析方法:通过所读入的左右大括号是否匹配把整个代码分为函数内部和外部,根据这两部分感兴趣的关键字不同建立不同的DFA状态转换表,使每个词素能够用最少的状态转换次数判断出是否为所关注的关键字,减少状态转移的时间复杂度.使用已生成的状态转换表,消除了建立DFA的时间开销.描述了状态转换表的生成过程,插桩器的实现过程以及运行结果.【期刊名称】《科学技术与工程》【年(卷),期】2013(013)030【总页数】6页(P9072-9077)【关键词】覆盖测试;代码插桩;词法语法分析【作者】郭锐;李博;彭宝新【作者单位】中北大学电子与计算机科学技术学院,太原030051;中北大学电子与计算机科学技术学院,太原030051;中北大学电子与计算机科学技术学院,太原030051【正文语种】中文【中图分类】TP311.11软件测试是保证软件质量和可靠性的重要手段。

其中覆盖测试就是监控软件代码覆盖率的一种有效的测试方法[1]。

覆盖测试通常分为三步:①对源程序进行代码插桩;②编译插桩后的代码,并运行生成的可执行文件;③获取并分析插入的信息[2]。

由此可见,代码插桩贯穿覆盖测试的始终,是实现覆盖测试的关键步骤,其原理是根据程序流程结构在程序中的特征点,即函数入口、出口和程序分支插桩代码,然后编译执行,同时记录历史数据[3]。

因此在源程序中如何正确找出函数入口、出口和程序分支的位置又是插桩程序的重中之重。

找出函数入口、出口、分支位置是通过词法语法分析程序实现的[4]。

通常,词法语法分析程序需要找出关键字、标示符、常数、运算符等信息,形成符号表,并分析变量定义、赋值、运算等过程形成语法树[5]。

但在插桩程序中,词法语法分析程序只需找出正确的插桩位置,并不一定会用到上述的所有信息,例如变量赋值,初始化等信息对识别函数入口、出口、分支位置几乎没有帮助。

嵌入式软件的覆盖测试

嵌入式软件的覆盖测试

嵌入式软件的覆盖测试摘要:覆盖测试是验证软件功能结构正确性以及查找问题的非常重要的方法和手段,它要借助一定的工具才能取得较好的效果,满足软件在质量和时间上的双重要求。

如何利用好这方面比较成熟的工具,对其机理的研究及适应性改造是很重要。

本文着重描述这类工具的工作机理,以及对嵌入式软件测试的特殊要求,并以对自主知识产权嵌入式操作系统的测试为例进行说明。

关键词:嵌入式操作系统覆盖测试软件测试工具1 概述软件测试是很广的概念。

从其贯穿软件生命周期全过程来看,测试可分为模块测试、集成测试、系统测试等阶段。

测试还可分为静态检查和动态运行测试两大类。

在动态运行测试中,又可有基于程序结构的白盒测试和基于功能的黑盒测试。

测试不仅关注程序的功能,还有性有测试、强度测试等等。

要达到比较好的测试效果,除了要有周全的测试计划、可控的测试过程、测试人员丰富的经验外,还需要借助一些行之有效的辅助工具,尤其在当今软件规模日益庞大、测试工作量成倍增加的情况下。

对应上述的测试分类情况,测试工具可划分为:支持对程序源代码进行静态规则检查和质量评估的静态分析工具、支持对程序单元进行动态覆盖测试的工具、对软件系统的整体运行性能进行测试的工具。

另外,还有一些特殊用途的或专用工具,如协议测试仪、内存检测工具等。

这些工具都有较为成熟的商业化产品,也可通过自行开发的方式获得。

本文具体讨论了对一类特殊的系统软件——嵌入式实时操作系统——进行覆盖测试的情况。

内容涉及对这类软件特性的研究、测试的难点和特点、对现有测试工具的适应性改造和测试实例说明。

2 软件覆盖测试覆盖是一种白盒测试方法,测试人员必须拥有程序的规格说明和程序清单,以程序的内部结构为基础,来设计测试案例。

其基本准则是则测试案例来尽可能多地覆盖程序的内部逻辑结构,发现其中的错误和问题。

所以,覆盖测试一般应用在软件测试的早期,即单元测试阶段。

覆盖的几种方法或策略如表1所列。

表1 几种典型的覆盖策略覆盖策略定义语句覆盖在制定测试案例时,使程序中的每个语句都至少执行1次。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
( 西安邮电学院 计算机学院, 西安 710061 ) ( sunhongl.i app le@ 163. com )
摘 要: 针对基于宿主机的嵌入式软件测试, 提出一种单元测试中通用的语句覆盖率测试方法, 通过插桩技术, 采用 向源代码插桩实现语句覆盖率测试。设计了测试代码的实现 算法, 通过测试代码可以自动完成向被测代码插 桩。这些 方法被成功地应用到笔者所在项目组开发的嵌入式软件仿真测试平台 ARM test上。利用这些方法, 在嵌入式硬件系统 未完成开发之前, 可通过宿主机环境和仿真环境及时发现嵌入式软件开发初期的一些不足并加以完善。
收稿日期: 2010- 03- 31; 修回日期: 2010- 05- 26。 基金项目: 陕西省自然科学基础研究计划项目 ( SJ08 ZT14) ; 西安市科技计划项目 ( CXY 08017 ( 1) ) 。 作者简介: 孙红利 ( 1984- ) , 女, 陕西延安人, 硕士研究生, 主要研究 方向: 嵌入式 系统、嵌入 式软件测 试; 王忠民 ( 1967- ), 男, 陕西蒲 城 人, 教授, 博士, CCF会员, 主要研究方向: 嵌入式系统、智能机器人; 王文浪 ( 1964- ) , 男, 陕西渭南人, 高级实验师, 主要研究方向: 嵌入式 软件 测试。
1)在第一个函数体之前插入一些初始化语句及 桩函数; 2) for、do、do wh ile、do until等循环语句处; 3) if、else if、e lse及 end if等条件语句各分支处; 4)输入输出语句之前; 5)函数调用语句之前; 6) return语句之前; 7) goto 语句之前。 1. 2. 2 桩函数的设计 插桩操作插入的 桩函数首先要是由与被测试程序相同的
在整个测试实现 过程中向源程序的插桩处于至关重要的 地位, 下面就本文所用的插桩原理与规则做详细说明。 1. 1 程序插桩的思想
程序插桩是借助 向被测程序中插入操作来实现测试目的 的方法, 是软件白盒测试中 的一种 基本的 测试手 段 [ 3]。 通过 插桩, 可以进一步 了 解程 序执 行过 程中 的一 些动 态特 性 [ 4]。 本系统采用的插桩技 术在动态测试之前根据测试人员所选的 测试方式选择不同的 插桩程 序完成 对源程序 的自动 插桩, 插 入已经设计好的桩函 数, 在 动态测 试阶段 通过运 行插桩 后的 程序可以获得所需要的程序运 行信息。例如在单元测试的语 句覆盖率测试中通过 运行插桩后程序可以获得可执行语句中 所执行到行的行号及该行的执 行情况。本文所述的插桩技术 支持如下的覆盖率测 试信息 [ 5]:
语句覆盖率 = 运 行的语句数 /总的可执行语句数 1 00%
具体的插桩实现 如图 2所示。
图 2 插桩实现流程 1. 2 程序插桩的规则 1. 2. 1 插桩点的选择
插桩是通过在所选的插桩 点插入桩函数实现的。其中插 桩点的选择是插桩 技术必 须考虑 的关键 问题。一般 情况下, 插桩点位置的选择应 该满足在能够充分采集到所需信息的情 况下使得代码的膨 胀率最 小, 对 程序的 影响最 小。本文所 述 测试方法, 在被测程序所有的可执行语句中选择插桩点, 对于 一些声明语句及左右大括号等 都不进行插桩。由于插桩是在 保持源程序逻辑完整 性和可 执行性 的情况下 进行, 所以 实际 测试过程通常在下面 一些部位插桩:
步骤 1 构造初始 化函 数 In it( )及 桩 函数 Stub( ), 为 后 面向被测试程序插桩做准备。
S tub 函数体中包含下列的语句: L ineN um = ch aL ine; ExeT im e[ chaL ine]++ ; L ine[ chaLin e] = L in eN um << 16 |ExeT im e[ chaLin e]; 相当于一个计数器的功能, 当程序每执行到一处时, 该 点 的执行次数将会加 1。 Init( )中包 含对 L ineNum、chaL ine、ExeT ime [ ] 等 Stub( ) 函数体中出现变量的初 始化, 以保证 插桩后 的文件 可以正 确 运行。其中的数组 L ine [ ]是 由一 个整 型数 和一 个整 型数 组 合并而成的, L ineN um 表示 执行 到行的 行号, Ex eT im e [ ] 存 放 该行的执行次数。 此处的初始化语句和桩函数在插桩过程中都要 被插入被 测试程序中。 步骤 2 打开被测程序, 对被 测程序进行 初次扫描 , 在 扫 描过 程 中 按 行 读 取 源 程 序, 统 计 被 测 试 程 序 的 总 行 数 Z lineN um 及被测试程 序中 所有 函数 名 的个 数 fuc, 并且 找 到 m ain函数体及其 下一个函数体中函数 名出现 的位置, 将其 分 别记为 Lm ain和 LNm a in, 为后面向 m a in函数体插桩做准备。 在读 取 过 程 中用 语 句 ZL ineN um + + !记 录 总行 数; 用 Lm ain = ZL ineN um; ! 和 LNm a in = ZL ineNum; ! 分 别 记 录 m ain函数体及其 下一个函数体中函数 名具体 所在行的 行号, 下面的语句则实现 m a in函数体中函数名具体位置的记录。 fgets( bu,f 1024, fp ); ZL ineN um ++ ; if ( ( index( "( ", buf)! = - 1)&& ( id entf( buf) )&&
在程序插桩中除了要考虑插桩规则中所述的前 两个问题
外, 插桩 位置的确定也是一 个至关 重要的 问题。通常 针对 不 同的语句格式插桩位置 会有所 不同, 所有的 插桩位 置选择 都 必须建立在确保插桩后的程序可以正确运行的基础 上。
2 算法设计
针对基于宿主机的嵌 入式软 件测试, 单元 测试中 的语 句 覆盖率测试算法描述如下。
第 10期
孙 红利等: 嵌入式软件语句覆盖率测试插桩技术
2 73 9
ห้องสมุดไป่ตู้
享内存作为数据的中 转站, 其交互机制如图 1所示。至此, 就 建立了一个完整的 仿真平 台。对该平 台进行 完善, 添加各 种 测试类型, 最终实现一个适合于嵌入式软件的仿真测试环境。
通过仿真测试环 境实现在只有宿主机环境的情况下完成 对嵌入式软件全面、有效的测试, 解决了 在测试过程中由于宿 主机和目标机的交联使用所出 现的数据信息传输问题。在测 试实现过程中, 首先对被测代码进行插桩, 运行插桩后文件获 得的桩信息经过桩信 息分析 器可计 算出覆盖 率, 并最终 通过 仿真平台完成流水灯 等外设的模拟工作。
本文在对现 有的 测试 方法 和插 桩技 术的 总结 分 析基 础 上, 改进了传统的测试方式, 采用向源代 码插桩的插桩方式提 出了一种通用的嵌入 式软件 语句覆 盖率测试 方法, 实现 在没 有目标机的环 境下 通过 测试 代码 自动 完成 对嵌 入式 软件 高 效、准 确的 测试, 克 服了 传统 手工 测试 效率 低、效果 差的 缺
关键词: 嵌入式软件; 宿主机环境; 程序插桩; 语句覆盖; 单元测试; 仿真测试 中图分类号: T P311. 56 文献标志码: A
Instrum entation technology for embedded softw are statem ent coverage testing
SUN H ong li, WANG Zhong m in, WANG W en lang
点; 由于 源代码中包括全部 的语法、语义 信息, 对源代 码的 分 析能够达到最高的准确度。
1 嵌入式软件测试插桩原理规则
利用嵌入式软件仿真测试环境对嵌入式软件进 行测试是 目前国内外公认的一种有效的测试方法。本文针对嵌入式 软 件, 提出 了一种基于宿主机的测试模型, 如图 1所示。
图 1 基于宿主机的嵌入式软件测试模型 在实际应用中, 嵌入式软 件的运行 离不开 具体的 外围 设 备。因此, 在宿主 机环境下, 还必须对已有的外设以及即将 出 现的外设进行仿真。利用软件模拟中断机制, 实现 ARM 内核 与模拟外设之间的数据 交互共 享, 将 每个外 设对应 建立的 共
K ey word s: embedded softw are; host based env ironm ent; code instrum entation; statem ent coverag e; un it test; em ulating and testing
0 引言
随着嵌入式设备 在越来越 多的领 域中得 到使用, 如何 对 日益复杂的嵌入式软 件进行快速有效的测试已经成为目前的 一大热点问题。从国 内外现状 来看, 对嵌 入式软件 测试的 研 究, 大多着重 关 注 嵌 入式 软 件 的 调试 工 作, 即 D ebugg ing 阶 段, 而鲜见系统的、全面的测试 技术探讨。随着嵌入式软件质 量保证要求的提高, 对嵌入 式软件 的测试 显然已 经不能 停留 于仅仅通过调试就可以了, 必然需要有更加全面的、系统化的 测试技术支持 [ 1]。传统的嵌 入式软 件测试 一般采用 手工的、 插桩目标代码的方 式。由于目 标代码 中语法、语义 信息不 完 整, 有时会造成对错误的分析定位不够准确; 采用手工的方式 进行, 效率低、效果差, 存在 漏洞和 隐患 [ 2] 。同时 由于嵌 入式 软件需要采用交叉开 发的方 式, 嵌 入式软 件测试 也存在 同样 的问题, 而语句覆盖率测试是软件测试最基本的方法, 因此在 开发初期, 实现在没有目标 机的环 境下自 动完成 对嵌入 式软 件的语句覆盖测试是 非常必要的。
语言编写而成的, 满足源代码函数的语法规则, 并且是能够 编 译通过的。另外, 在设计桩函数时, 要考虑的一个重要问题 就 是经过插桩操作, 要获得程 序执行 过程中 的哪些 信息。其 中 测试类型不同所设计的桩函数也可能不同。本文所设计的 桩 函数 stub( ) 是专门针对单元测 试的语 句覆盖 率测试的 , 通 过 所设计的桩函数可以采集到所执行行的行号和本行 所执行的 次数以及代码执行过程 中的覆 盖率情 况, 在 必要时 也可以 统 计出行执行的时间。在第 3章算法描述中对桩函数做了具 体 的描述。 1. 2. 3 插桩位置的确定
相关文档
最新文档