还剩27页未读,继续阅读
本资源只提供10页预览,全部文档请下载后查看!喜欢就下载吧,查找使用更方便
文本内容:
常见问题解答目录TOC\o1-3\h\z\uTestbed使用过程中问题解析31.如何处理中文?32.如何尽快入门介绍tutorial33.__的问题文字竖排、输入许可、软件狗驱动44.用户许可无效“ControlFileConfiguration”45.试用版不要更改日期46.嵌入式系统软件的测试bit__p插装47.Testbed的bit__p插装技术58.单元测试的策略先黑盒再白盒59.如何测试unix平台的软件610.能否测试汇编软件?611.软件工程中软件测试的应用软件生命期的各个阶段需要画图)612.介绍三种单元测试模式713.介绍编码规则检查MISRA714.白盒测试815.临时软件狗过期更新问题,读不出序列号816.为何Testbed软件的主菜单的Configure下没有命令ResetCompilerOptions?917.网络狗的本地使用,如何设置918.有些朋友会问,你们的产品TESTBED和国外同类测试产品相比,优势在哪?919.VC行命令cl的包含选项/I不支持带空格的路径1020.testbed系统测试报指定的编译工具和实际编译工具不匹配的现象1021.类中引用类的错误1022.在C++单元测试中,当前测试事例无法引用前一个测试事例的对象1122.给vc++程序做单元测试时,TBrun分析不出正确的函数原型1123.在什么情况下才对函数打桩?1124.在vxworks环境下做单元测试1125.在vxworks环境下用软件方式作系统测试1226.关于做白盒测试,生成的报告时非常的慢,甚至导致假死现象(28所测评中心)1327.__testbed后,没有配置当前编译环境就做单元测试,build通不过(在28所测评中心)1328.通过samba服务配置单元测试环境支持Unix上的源程序单元测试(在28所3部已做过)1329.在对c51单片机作单元测试时,输出的浮点数都变成了1430.testbed静态分析报错1531.在Testbed界面,或弹出的对话框中,常常有英文显示不全的现象,操作起来很乏1532.在静态分析8086汇编程序前,注意事项
1533.使用dsp3x和仿真器注意事项
1534.做mri68K的单元测试注意事项
1635.8051单片机作系统测试,程序没运行,覆盖率就达100%
1636.如何测试Unix平台的软件
1737.嵌入式系统软件的测试
1738.关于UTYPE类型网络软件__作步骤
1839.基于DSP系列(2xx)的系统测试步骤及注意事项
1840.使用Testbed和RTinsight测试PC104平台的程序步骤及注意事项
1841.基于8051a__的系统测试步骤及注意事项
2042.基于VxWorks系统用纯软件方式做系统覆盖率测试步骤及注意事项
2043.Testbed报告生成太慢
2144.RTview覆盖率报告中的问题
2245.关于switch的参数强制转换为int型
2346.Tic3x汇编语言单元测试地址映射映射问题
2447.Tic3x汇编语言单元测试覆盖率显示异常
2548.TBRun使用SAMBA服务测试linux的c++程序,出现了编译链接不过去
2549.对8052系列cpu进行系统覆盖率分析的注意事项
2650.80196汇编语言注意事项
2651.Dsp5409注意事项
2652.Testbed选择分析文件时出错
2753.RTinsightPC104写地址注意事项2854.CodeVision的C程序内嵌汇编的静态分析2855.80C32汇编Keil编译的问题2856.8031系列汇编系统测试2857.LDRATestbed有选择进行分析2858.LDRATestbed分析的文件的名字2959.TiCCS中的多段编译2960.8031A__Testbed插装出错2961.x86A__Testbed静态分析出错2962.x86A__宏展开29Testbed使用过程中问题解析1.如何处理中文?问在代码中出现的中文字符(包括字符串和注释),在格式化代码(ReformattedCode)中变成空格,这就导致插装的程序在运行时无法显示中文,比如一些按钮、菜单,非常不方便答从c/c++Testbed
7.07开始能够处理中文,方法如下编辑%Testbed%\c\cvals.dat和%Testbed%\cpp\cppvals.dat:修改:1660SinglelinecommentflagSLCMTFforkanjiandchinachars.为:1661SinglelinecommentflagSLCMTFforkanjiandchinachars.还要修改:1820Flagforchineseorkanjicharsinstrings为:1821Flagforchineseorkanjicharsinstrings2.如何尽快入门介绍tutorial问Testbed如何入门?想看手册,却发现手册就有800多页,而且是英文答Testbed比较庞大学习使用它其实有很好的教材,已经随Testbed__了从开始菜单中打开Testbed程序组,会发现有几个Tutorial文档,这就是LDRA公司编写的入门教材Testbed的教材有c_c++LDRATestbedTutorial--SingleFilec_c++LDRATestbedTutorial--Setc_c++LDRATestbedTutorial--MSVCScribbleTBrun的教程有包含在TBrun的手册中这些教程手把手的带领读者分析示例,一步一步地完成测试流程,如何处理常见问题教程中大部分篇幅中都配有操作示意图,容易理解只要花上几天工夫学习教程,边做边学,就能基本掌握Testbed相应的中文资料为
03.LDRA_Testbed中文__指南
1.
2.doc
05.LDRA_Testbed中文使用指南
1.
1.doc
08.LDRA_TBrun中文使用指南
1.
2.doc3.__的问题文字竖排、输入许可、软件狗驱动问在Windows98/Me上__Testbed,运行时发现窗口中的字符变成竖排答这是Windows98/Me字体的一个bug,替换为正确的字体文件即可操作用%Testbed%\Riched
32.dll替换%Windows%\System\Riched
32.dll4.用户许可无效“ControlFileConfiguration”问__完Testbed后运行,弹出一个对话框“ControlFileConfiguration”,不能继续运行答这说明用户许可无效需要输入正确的许可信息许可信息在随软件而来的一张纸上,把上面的信息对照对话框输入,注意大小写和空格敏感,这样就可以使用了另外,输入的许可信息存放在%Testbed%\Testbed.ctl中,可以拷贝这个文件作为备份,下次__的时候直接把这个文件拷贝过来就可以了,不需要再输入这些许可信息了5.试用版不要更改日期问我__了试用版Testbed,___不能修改系统日期?答__时Testbed记录下了当时的日期,并开始计时,以保证一个月内许可有效如果用户修改了系统日期,与Testbed计算的日期不符,误差在一天以上,它就会注销现在的许可,你必须重新申请许可6.嵌入式系统软件的测试bitmap插装存储空间、运行时间的限制bitmap插装RTinsight的使用创景移植了多种__环境传统的测试软件覆盖的方法是,在源代码中插装(instrument)路径记录代码,然后编译执行之,执行的过程中,插装代码把路径执行历史写入到本地文件中,然后对这个执行历史文件进行分析,得到执行的覆盖率对于一般运行在通用平台软件,比如Windows、Unix等,这样的方法可以满足要求在嵌入式系统的软件测试中,常常难以奏效如何获得覆盖率信息成为一个难题因为嵌入式系统的硬件存储空间小,软件实时性要求高,遇到的问题是这样的第一,插装之后的代码编译后目标文件体积变大,甚至超过系统中的内存空间,无法下载执行第二,插装的代码在执行中要记录执行历史信息,这就影响了其他部分的执行时效,经常会影响系统功能的实现;第三,在嵌入式系统中,往往没有文件系统,比如51单片机系统,执行历史文件无从生成借助Testbed的接口开放、bitmap插装等技术,我们已经在实践中解决了以上问题采用bitmap插装技术(可以参考《Testbed的bitmap插装技术》)减小目标文件的体积,并且把向文件中输出执行历史改为向指定内存端口(地址)输出,这样就把操作文件的大量代码变成了一条简单的写端口指令,更加减小了目标文件的大小,执行速度更快没有了文件,那么我们如何获得执行历史呢?RTmonitor正是这样一种硬件装置,它能够捕捉、存储真实目标机上指定端口(地址)的输出,主机可以从RTmonitor中随时取出执行历史进行动态分析,得到执行的覆盖信息从而__的解决了嵌入式系统的测试问题7.Testbed的bitmap插装技术----------------------------------------------------------------经过静态分析,确定了代码中的分支点,并且每个分支点都有统一的编号插装就是在所有分支点上部署“探头”——插装代码,当执行到这个点时,探头就输出这个编号到文件中从这个文件中,我们就可以得到执行历史信息,从而计算出代码的覆盖率然而,这样的方__造成历史文件体积庞大,频繁的读写文件也会影响软件的执行效率bitmap插装能够解决这些问题bitmap对应于常见的位图技术,在历史文件中,用一个位代表一个分支点,0代表这个点没有执行过,1代表已经执行了,这样历史文件的最小体积就相当于分支点个数/8个字节而且在执行过程中,是在内存中开辟一个数组记录分支点信息,程序结束时才写入文件的,这就大大提高了执行效率采用bitmap技术,可以获得语句覆盖、分支覆盖和MC/DC覆盖8.单元测试的策略先黑盒再白盒黑盒测试是以用户的观点,从输入数据与输出数据的对应关系出发进行测试的,也就是根据程序外部特性进行的测试它完全不涉及到程序的内部结构很明显,如果外部特性本身有问题或规格说明的规定有误,用黑盒测试方法是发现不了的另一方面,白盒测试完全与之相反,它只根据程序的内部结构进行测试,而不考虑外部特性如果程序结构本身有问题,比如说程序逻辑有错误,或是有遗漏那是无法发现的单元测试需要把黑盒测试和白盒测试结合起来为了首先保证程序的正确性,需要先进行黑盒测试,不做覆盖率分析之后对黑盒测试的用例做回归测试,得出现有覆盖率,这就节省了大量的动态分析实践,这时大部分代码往往已经得到了执行对剩余没有执行过的部分,设计白盒的测试用例,达到要求的覆盖率指标9.如何测试unix平台的软件Testbed对Unix平台的软件测试有独到的解决虽然,Testbed有运行于Unix上的版本,但是比起Windows平台的版本,界面和操作要逊色很多采用Free软件Samba——通过它Windows客户机可以把Unix主机当作自己的硬盘来访问,我们可以在Windows上运行Testbed/TBrun分析测试Unix平台的软件,而实际的编译、执行依然在Unix平台上运行具体方法是这样的要分析的源代码仍然存放在Unix主机上,只需要通过Samba把存放目录映射成为Windows客户机的一个硬盘,这是我们就可以把源代码当作本地的文件一样分析了而需要编译、执行代码时,通过r执行Unix主机上的编译、执行指令即可Testbed已经把这种配置集成到了TBrun系统中,只需要在__过程中配置一些参数,你就可以轻松在熟悉的Windows上测试你的Unix软件了10.能否测试汇编软件?汇编语言仍然是软件__的一支重要力量,尤其是在实时性强的嵌入式系统中遗憾的事,市场上的大部分测试工具都不支持汇编语言LDRA的Testbed可能是唯一的能够的是汇编语言代码的工具了值得一提的是,它支持多个家族的汇编包括了几种主要__平台Intel的x
86、PowerPC、Motorola的68K、DSP等等,还有51单片机的汇编而且通过采用RTmonitor,我们能够顺利完成这些平台的动态测试在众多客户的实践中,已经证明了这一点11.软件工程中软件测试的应用软件生命期的各个阶段需要画图)为了说明软件测试策略,可以把软件工程过程表达成一个螺旋(如图
3.3)首先,系统工程为软件__规定了任务,从而把它与硬件要完成的任务明确的划分开接着便是进行软件需求分析,决定被__软件功能、性能、限制调剂并确定该软件项目完成后的确认准则沿着螺线向内旋转,将进入软件设计和代码编写阶段从而使得软件__工作从抽象逐步走向具体化软件测试工作也可从这一螺旋线上体现出来在螺线的核心点针对每个单元的源代码,进行单元测试在各单元测试完成以后,沿螺旋线外前进,开始针对软件整体构造和设计的集成测试然后是检验软件选全能否得到满足的确认测试,最后,来到螺线的最外层,把软件和系统的其他部分协调起来,当作一个整体,完成系统测试这样,沿着螺旋线,从内向外,逐步扩展了测试的范围软件测试并不是孤立的、静态的行为,而是伴随着软件生命期的各个阶段从早期就需要引入软件测试,在各个阶段进行目标的检验,可以保证软件的质量以上用螺旋线表明的测试过程,按四个步骤进行,即单元测试、集成测试、确认测试和系统测试图2表示了测试的4个步骤开始时分别完成每个单元测试任务,以确保每个模块能正常工作单元测试大量的采用了白盒测试方法,尽可能发现模块内部的程序差错然后,把已经测试过的模块组装起来,进行集成测试其目的在于检验与软件设计相关的程序结构问题这是较多地采用黑盒测试方法来设计测试用例完成集成测试以后,要对__工作初期制定的确认准则进行检验确认测试是检验所__的软件能否满足所有功能和性能需求的最后手段,通常采用黑盒测试方法完成确认测试以后,给出的应该是合格的软件产品,但为检验它能否与系统的其他部分(如硬件、数据库和操作人员)协调工作,需要进行系统测试严格的说,系统测试已经超出了软件工程的范围(摘自郑人杰著《计算机软件测试技术》)12.介绍三种单元测试模式从Testbed进入TBrun作单元测试,会发现有三种方法进入TBrun TBrun-TestHarnessGenerator-IntegrateUnitsTBrun-TestHarnessGenerator-IsolateUnitsTBrun-TestHarnessGenerator-UnitTest这三种模式的差异在于对分析代码中各个单元的隔离程度所谓隔离,就是不与其他部分发生__,在源代码中的__就是调用关系IntegrateUnits适合于集成测试,各个单元之间没有隔离,你指定一个被测单元A,测试驱动执行时,A会调用真实的下层单元,那么这时测试的实际上是一个部件UnitTest对应于单元测试,各个单元之间全部隔离,你指定一个被测单元A,测试驱动执行时,A所调用的下层单元必须用桩函数来代替,这是测试的只是A单元本身,不与其他代码发生__IsolateUnits是LDRA新近推出的一种模式,它介于IntegrateUnits和UnitTest之间你可以灵活的选择哪些单元要被隔离,而不是i中的全部放开或者U中的全部隔离它很好的实现了一种测试策略自底向上增式测试增式测试是集成测试的一种方法它的集成是逐步实现的,集成测试也是逐步完成的,也可以说它把单元测试与集成测试结合起来进行自底向上增式测试表示逐步集成和逐步测试的工作是按调用图(CALLGRAPH)的层次自下而上进行的13.介绍编码规则检查MISRA----------------------------------------------------------------C语言的强大在于它的灵活,正如一枚硬币的两面,它的灵活也会导致软件容易出错、不易维护等等毛病在经历漫长、痛苦的调试之后,往往会发现原因可能非常简单比如,早年探测火星所运用的运载火箭因控制程序中错写逗号而__在软件维护中,去阅读前辈们所写的代码是一件令人头疼的事情,庞大、复杂的函数,各式各样的编程风格……让人如读天书正是如此,人们总结了很多容易引起错误的用法,逐渐的积累、发展成一套的编码规则,在编写代码的早期就予以检查,有效的提高了软件质量比如有一条规则,禁止在条件判断语句中比较两个浮点数是否相等,因为浮点数都是有一定精度的,相等的几率几乎为零,那么这个条件不能满足汽车工业界是最早注意到这些问题的,1998年,国际发动机工业软件可靠性协会MISRA发展并且应用了一套成熟的编码规则——“汽车软件C语言使用指南”,这份标准的产生在自动化行业记得地推动了使用“安全的C”进行编程,这份标准在汽车行业被广泛接受,同时他也被其他行业所广泛借鉴介绍软件覆盖----------------------------------------------------------------14.白盒测试白盒测试又称结构测试或基于程序的测试采用这一测试方法,测试者可以看到被测的源程序,他可用以分析程序的内部构造,并且根据其内部构造设计测试用例我们可以据此设计出大量的测试用例,甚至可以无休止的测试下去但是,我们如何衡量测试到何种程度,是否还需要测试下去?有位软件__这样说“不充分的测试是不可取的,但是过分的测试更是一种罪过”为了减少测试的盲目性,引入了测试覆盖率它要求对某些程序的结构特性做到一定程度的覆盖,或者说基于覆盖的测试,引导我们朝着提高覆盖率的方向努力,从而找出那些已被忽视的程序错误最为常见的程序结构覆盖是语句覆盖(StatementCoverage)它要求被测程序的每一可执行语句在若干次测试中尽可能都检验过这是最弱的逻辑覆盖准则进一步则要求程序中所有判定的两个分支尽可能得到检验,即分支覆盖或判定覆盖(Branch/DecisionCoverage)当判定式含有多个条件时,可以要求每个软件的取值均得到检验,即条件覆盖(BranchConditionCoverage)在同时考虑条件的组合值及判定结果的检验时,我们又有判定/条件覆盖(BranchConditionCombinationCoverage)还有MC/DC覆盖、路径覆盖、LCSAJ覆盖等等这些覆盖的级别由低到高,达到这些覆盖的难度也越来越大现在大部分行业只要求语句覆盖和分支覆盖15.临时软件狗过期更新问题,读不出序列号每个软件狗上都有序列号,表示几号狗从1到16号软件狗都对应一个读取序列号的USAFE*.exe软件17号以后的软件狗统一使用FieldExUtil.exe读取序列号可能问题1.是否成功__该临时狗的驱动程序集成在Testbed__软件中 2.换一台计算机再试16.为何Testbed软件的主菜单的Configure下没有命令ResetCompilerOptions?在testbed.ini中的[C/C++LDRATestbed]下,添加ADD_COMPILER_CONFIG=TRUE17.网络狗的本地使用,如何设置在testbed.ini中的[C/C++LDRATestbed]下,添加LOCAL_NETC_DONGLE=TRUE;NETBIOS_FIRST=TRUENETC_TCP_IP=FALSENETC_DEPT_NAME=LDRANET18.有些朋友会问,你们的产品TESTBED和国外同类测试产品相比,优势在哪?答我总结了以下几点优势,可能别的测试软件也涉及到一些雷同的功能当然,还有很多的功能没写出来,因为可能这种产品有,那种又没有首先,在静态软件的质量分析方面,数据流分析和信息流分析技术中文报告含中文帮助的编码规则集其次从动态覆盖率分析LCSAJ覆盖率分析MC/DC测试计划断言分析再次C/C++的单元测试测试驱动自动生成,桩模块自动生成测试数据生成小精灵GUI集成环境最后支持的语言和平台技术支持工程师很专业19.VC行命令cl的包含选项/I不支持带空格的路径方法1用软件将带空格的路径转换成短路径(推荐)方法2手工改为不带空格的路径(不推荐)方法3/I+空格+“路径”(没试过)20.testbed系统测试报指定的编译工具和实际编译工具不匹配的现象方法运行TESTBED的主菜单Configure/ResetCompilerOptions设置编译环境的正确路径21.类中引用类的错误对vc++工程的一个cpp程序做单元测试,选中一个类的构造函数创建测试用例,生成的驱动程序无法连接通过,由于该类中使用了外部定义的另一个类,该测试驱动程序找不到那个类的析构函数的定义方法建一个system__分析,包含当前分析文件和另一个被引用的类的cpp文件22.在C++单元测试中,当前测试事例无法引用前一个测试事例的对象给vc++程序的一个类的方法做单元测试时,步骤1,先给一个类的构造函数创建一个测试事例1,并做单元测试步骤2,并选中测试事例1创建的对象,再给该类的另一方法创建测试事例2驱动程序无法编译,原因是事例2的类方法无法与事例1的创建的对象关联起来方法做单元测试时,必须要包含用户头文件分析22.给vc++程序做单元测试时,TBrun分析不出正确的函数原型如,std::vecterSimEvent*In____igen__Re__iver::Re__ive…方法改为usingnamespa__std;vecterSimEvent*In____igen__Re__iver::Re__ive…再分析,分析的函数原型正确,但返回类型不正确,变为vecter了再改方法1修改源程序(不推荐)方法2手工修改驱动程序返回类型成vecterSimEvent*23.在什么情况下才对函数打桩?
1.被测软件对外设访问,而单元测试时对外设存取不现实;
2.被测软件所调用的子程序尚未编写(比如采用TOP-DOWN__模式);
3.被测软件所调用的子程序尚未被测试
4.需采用隔离测试策略24.在vxworks环境下做单元测试1.启动vxworks的simulator环境.2.若是白盒测试,则插桩如下25.在vxworks环境下用软件方式作系统测试1.首先要在testbed中创建system的set方式分析2.若有main函数,则改名tbmain.3.插桩模式如下26.关于做白盒测试,生成的报告时非常的慢,甚至导致假死现象(28所测评中心)原因当用户被测试的程序过大(如,一个.c程序上万行),做白盒测试生成覆盖率报告时,将会为每一行生成详细的覆盖率信息,如执行次数,覆盖率统计等等,报告也会非常的庞大解决办法用户编写的源程序不应过长,最控制在2000行以内,若过长,则应改成多个.c源程序27.__testbed后,没有配置当前编译环境就做单元测试,build通不过(在28所测评中心)原因在做单元测试以前,没有设置正确的编译环境解决首先应该从testbed得主菜单的Configure下的ResetCompilerOptions去设置正确的编译器包括路径,再做单元测试,就没问题了28.通过samba服务配置单元测试环境支持Unix上的源程序单元测试(在28所3部已做过)请参考testbed的英文__手册62页,另外注意a.在66页的中的RootDiver应输入登陆用户名所在的路径(如用户名是dz在unix上的路径是/home/dd/pc-10下,则应该输入/home/dd/pc-10b.在69页,用户一定要指定在unix上,所使用的编译连接命令及其相关的选项29.在对c51单片机作单元测试时,输出的浮点数都变成了解决若程序中存在有浮点数,则连接时,应采用支持浮点的库文件c51fpl.lib,所以在使用TBConfig配置c51的单元测试时,要选择支持浮点的编译连接声称目标代码30.testbed静态分析报错可能原因
1.本身源代码编译有错,先编译通过
2.从testbed报错的对话框中,察看报错行数,进一步确认
3.查看格式化代码出错的行数,即在哪一行中止了
4.在源代码中通过屏蔽的方法去定位错误如在语句中statements1前后必须加上{},否则,可能分析报错IfAStatements1;ElseStatements2;31.在Testbed界面,或弹出的对话框中,常常有英文显示不全的现象,操作起来很乏请参考单文件或多文件用户操作手册32.在静态分析8086汇编程序前,注意事项1.程序的源代码应大写,否则被误认为是外部函数2.最好将所有的子过程,尤其是中断服务子程序,用XXXPROCNEAR和XXXENDP封装起来,否则会被认成是主函数__IN的一部分
33.使用dsp3x和仿真器注意事项1.并口模式(EPP或BiDirectional或ECP)+端口地址0X378(别的地址可能不同)
2.仿真器有一个跳线必须选择MPSD,同时仿真器与目标板的连接使用MPSD接口3.仿真器与目标板的接线应与J1端对齐4.CodeComposer设置,应sdgo3x..drv驱动程序5.给仿真器和目标板通电后,使用SDConfig.exe复位,再启动CodeComposer6.cs编译设置应选目标板C32或C3X,再编译7.注意在连接目标代码时,使用的cmd文件中的memory分配,最好先参考相关的目标板的文档,否则,无__确下载到目标板
34.做mri68K的单元测试注意事项
1.__mri68k编译器后,在使用编译命令前,在系统环境变量中添加XRAY__STER=C:\mri68k\__STER
2.系统path中如果指向了其它的编译器,可能会和mri的编译器冲突,现象是编译后没有任何提示信息也生成不了o__文件;解决:备份系统path所有的路径到文件中,再清除与操作系统不相干的别的路径
3.目前tbconfig配置的驱动模板中没有在H和S前面加ldra,spliter切割的时候结果不对;
4.如果被测试函数有返回的时候,在程序中会有输出%%,在其它环境下输出的结果为 %,这里输出结果为%%,这样是不对的,可以考虑在驱动模板中加个宏定义#define%%%让输出结果为%
5.编译器放的目录不要有空格,目录也不要超过8个字符,(否则-I参数指向的include路径找不到)最好就是把整个目录放到根目录下就好
6.include包含文件的形势应用“”而不是否则,便以后找不到当前头文件
35.8051单片机作系统测试,程序没运行,覆盖率就达100%原因1可能是PRGRD、PR__S和GND接线错,改GND线接地原因2可能是M51映像文件不对,问题解决原因3由于rtinsight是采用地址比较模式的方式作系统测试,所以在用rtinsight监控以前,确保程序目标代码已下载到存储器原因4可能RTinsight处于运行状态下,下载的目标代码因为rtinsight使用的地址比较模式测的8051汇编的系统覆盖率,这样,她认为全执行了改为在运行前,下载目标代码,再运行
36.如何测试Unix平台的软件Testbed对Unix平台的软件测试有独到的解决虽然Testbed有运行于Unix上的版本,但Windows平台的版本也能测试Unix程序采用Free软件Samba——通过它Windows客户机可以把Unix主机上的文件当作自己的本地文件来访问,我们可以在Windows上运行Testbed/TBrun分析测试Unix平台的软件,而实际的编译、执行依然在Unix平台上运行具体方法是这样的要分析的源代码仍然存放在Unix主机上,只需要通过Samba把存放目录映射成为Windows客户机的一个硬盘,这是我们就可以把源代码当作本地的文件一样分析了而需要编译、执行代码时,通过r执行Unix主机上的编译、执行指令即可Testbed已经把这种配置集成到了TBrun系统中,只需要在__过程中配置一些参数,你就可以轻松在熟悉的Windows上测试你的Unix软件了
37.嵌入式系统软件的测试一般的测试软件覆盖的原理是,在源代码中插装(instrument)路径记录代码,然后编译执行之,执行的过程中,插装代码把路径执行历史写入到本地文件中,然后对这个执行历史文件进行分析,得到执行的覆盖率对于一般运行在通用平台上的软件,比如Windows、Unix等,这样的方法可以满足要求而在嵌入式系统的软件测试中,常常难以奏效如何获得覆盖率信息成为一个难题因为嵌入式系统的硬件存储空间小,软件实时性要求高,遇到的问题是这样的第一,插装之后的代码编译后目标文件体积变大,甚至超过系统中的内存空间,无法下载执行第二,由于插装的代码在执行中要记录执行历史信息,这就影响了其他部分的执行时效,甚至会影响系统功能的实现;第三,在嵌入式系统中,往往没有文件系统,比如51单片机系统,执行历史文件无从生成借助Testbed开放的接口、bit__p插装等技术,我们已经在实践中解决了以上问题采用bit__p插装技术(可以参考《Testbed的bit__p插装技术》)减小目标文件的体积,并且把向文件中输出执行历史改为向指定内存端口(地址)输出,这样就把操作文件的大量代码变成了一条简单的写端口指令,更加减小了目标文件的大小,执行速度更快没有了文件,那么我们如何获得执行历史呢?RTmonitor正是这样一种硬件装置,它能够捕捉、存储真实目标机上指定端口(地址)的输出,主机可以从RTmonitor中随时取出执行历史进行动态分析,得到执行的覆盖信息从而__的解决了嵌入式系统的测试问题
38.关于UTYPE类型网络软件__作步骤
1.__U__驱动
2.启动SuperpronetServer
3.设置SNET_SERVER_ID,即按Superpronet网络狗模式启动服务
4.LDRATestbed
7.
3.2的网络狗本地使用SNET_SERVER_ID=RNBO_SN_DRIVER
5.保持网络处于连接状态
39.基于DSP系列(2xx)的系统测试步骤及注意事项目的用Rtinsight测试运行在dsp2xx上程序的覆盖率软件资源TestbedRtviewCodecomposer程序事例,指令插装模板和support.c程序硬件资源RtinsightTMS320C240目标板,DSPi__仿真器操作步骤
1.插装事例程序
2.连接主机、DSPi__和目标板
3.配置Codecomposer目标运行环境(并口0x
378、驱动sdgo2xx.dvr),并reset复位
4.编译连接__装的事例、support.c和cmd文件
5.正确连接Rtinsight、隔离板和目标板
6.启动Rtview,连接Rtinsight,建立工程启动分析
7.通过Codecomposer调试运行__装过的目标程序注意事项
1.选择testbed\rtinsight\rt_CINSTR.DATsupport.c
2.在Codecomposer中cmd文件
3.若步骤2后,连接不上目标,可能错误(并口地址不错,没有reset位(使用dsp复位软件)、线路、目标板问题
40.使用Testbed和RTinsight测试PC104平台的程序步骤及注意事项目的面向PC104目标板的覆盖率分析软件资源testbedrtview事例程序,插装模板,bc编译环境硬件资源PC104板子,Rtinsight隔离板,转接板,2根数据带操作步骤1.用Testbed插装被测试事例必须选择静态分析,复杂度分析和指令的插装选项用Testbed\Rtinsight目录下的相应指令插装模板在dos编译环境中最好使用短的插装文件名前缀同时在插装配置对话框中选用bit__p和historyinonefile选项.2.编译__装的事例修改插装模板的支持文件support.c,为了向特定地址或端口写特征值(例如在bc环境用pokeSegmentoffseteigenvalue;或outport端口地址,eigenvalue)添加Mi__odNum和FixedBranchNum宏定义Mi__odNum=Minz__ileidFixedBranchNum=1024或value=__x__qbranches3.检测RTView和Rtinsight间的软硬件连接用COMx串口读和设置Rtinsight的ip地址,使得与主机在同一个子网内(并重启动ip生效)用网线连接主机和Rtinsight,设置具体的分析4.检测Rtinsight和PC104目标板间的软硬件连接连接好隔离板,转接板和目标板间的数据线注意问题电源线一定不能接错,高低16位数据线不能反接启动目标板,是否能正常启动若启动正常将__装过的程序执行文件,拷贝到目标板5.使用RTView分析事例创建工程通过ip连接配置具体的分析覆盖率分析注意事项转接板的写方式(写内存和I/O)决定了指令插装模板的中的对特征值的写函数形式和地址类型性能分析过程1Rtview指定指令插装模板来插装源文件2用编译器编译连接__装的源文件生成执行文件exe3拷贝执行文件到目标板,并在目标板执行4从Rtview中选择性能分析测试
41.基于8051a__的系统测试步骤及注意事项目的用Rtinsight测试运行在8051上汇编程序的覆盖率,性能分析软件资源Testbed8031a__RtviewCodeCruiser(带编译器)程序事例,指令插装模板硬件资源RtinsightEasyProbe8052Fplus仿真器8051目标板操作步骤1.修改程序,给程序加注函数出入口标注(详细参考)2.事例程序选择8051a__的指令插装模板3.连接主机、仿真器和8052F目标板4.配置目标,连接方式,启动CodeCruiser,建立工程,编译连接__装过的事例程序5.连接主机,Rtinsight,隔离板和仿真器6.启动Rtview,建立工程做覆盖率和性能分析注意事项
1.选择RTview给定的汇编指令插装模板
2.__装的文件被正确编译后,会产生omf目标文件,和m51符号表映射文件
3.若步骤4不能启动,则检查配置信息是否正确,目标电源是否开,串口线是否连好
4.所有连接完毕后,在做事例的覆盖率时,覆盖率始终没有变法(一直为零),可能错误隔离板和仿真器间的数据线高低位没对齐编译连接的程序不是__装过的事例程序隔离板的PRG_RD和PRG_CS没有正确连接
42.基于VxWorks系统用纯软件方式做系统覆盖率测试步骤及注意事项目的熟悉面向tornado__环境的系统测试软件资源testbedtornado事例程序,面向Vxworks的插装模板硬件资源(无)操作步骤1.Tbconfig配置平台环境(编译器的路径、指定插装模板和驱动模板)2.Testbed插装__装的文件中不能有函数__in,若有,应改为别的函数名(___)3.Tornado编译,连接__装的文件用Tornado创建工程后,应加入文件tb__in.c与指令插装模板在同一目录下和别的__装的文件一起编译连接4.在Vxworks的模拟环境中,搜集产生的历史文件到history.exh启动VxWorks模拟器dowload目标文件在shell中运行相关的函数(tbinit),用get_history历史数据5.用Testbed对history.exh数据做系统测试分析注意插装的选项应选择bit__p和historyinonefile选项测试中,要熟悉__装的文件结构和tb__in的结构如何获取死循环的数据
43.Testbed报告生成太慢有时在静态分析和单元测试的时候生成报告慢,也可以在testbed的报告生成配置的地方,将不需要的报告去掉不生成
44.RTview覆盖率报告中的问题3022MOVA@R0Executed3123CJNEA#55HRAMERRExecuted3224INCR0Executed3325CJNER0#80HLOPExecuted3426AJMPCLRRAMExecuted3627RAMERR:Unexecuted3728LJMPCONTExecuted针对非8031的情况(RTinsight端口赋值方式)我们的RTview的报告主要是根据格式化后的代码给出的,这些工作都是基于Testbed的分析结果的基础上,而我们对testbed数据的理解并不十分全面,所以有个别地方会不对,这种情况软件这边处理起来会比较麻烦,因为这些情况大多比较特殊,需要软件额外特殊处理因此在我们的RTview里面添加了一个将测试数据转换为exh的功能(ExporttoEXH),将数据导出用testbed来分析(如果是set模式转换为history.exh如果是单个文件转换为xxx.exh,xxx为文件名),只要RTinsight采集的数据没有问题,用testbed分析的结果一般就不会有问题,而且testbed的报告比较规范一些,还有察看动态调用关系图和控制流图也比较直观而对于80313022MOVA@R0Executed3123CJNEA#55HRAMERRExecuted3224INCR0Executed3325CJNER0#80HLOPExecuted3426AJMPCLRRAMExecuted3627RAMERR:Unexecuted3728LJMPCONTExecuted是37行已经执行了没有把36行统计进去(如果是这个错误的话应该是RTview处理上考虑的情况不完善);还是37行本没有执行而被认为执行了,从后面分支覆盖的结果看,似乎是37行没有执行而将其认为执行了,不知道你认为的错误是这个吗?如果是后面这个错误的话,可能是下面的原因造成的8031系统测试需要在连续的调用以及ret之间添加nop指令,因为系统取指是16位的,而这些指令是8位的,这样cpu取值的时候会把后面指令的前面部分读取出来,但cpu不会运行,而RTinsight这边就会认为该指令已被读取运行,这样可能会造成测试结果出错,这个在RTinsight使用指南里有写源代码插桩首先对要分析的源代码进行格式处理,具体可以参考Testbed关于汇编语言分析的说明;在做好最基本的处理后,还需要在程序中RET和RETI的后面加上一条NOP指令,添加的原因是cpu在进行RET等进行取指执行的时候,由于指令补足的原因,会将其后面的半个字节的指令带出,如果不添加NOP的话,可能会造成后面分析的结果误判比较保险的做法是在连续的call之间也要加nop,还有就是插装模版改为llddM_N:nop
45.关于switch的参数强制转换为int型类似于这样的代码段 插装后变为{…… {……UnsignedlongI; switchintI:Switchi: {{ …… Case1: } Break; } Case2: Break; 将i的类型强制转化为int型,这可能导致原来long Default: 型数据重复 Break; } }关于switch的一点资料这是因为switch-case尽量(注意这两个字)使用跳转表(学过汇编的人应当知道吧),所以
1.既然使用的是跳转表,那么比较的只可能是整形数(现在明白___switch只能判断整数了吧?)
2.为了能够转化为跳转表,那么case值就应当尽量集中(现在明白___有些文章建议这么做了吧?)
3.如果不能转化为跳转表,那么降为if-else(大部分编译器这么做),或者使用HashTable
46.Tic3x汇编语言单元测试地址映射映射问题ccs设置为c3xsimulatorcmd文件如下MEMORY{SRAMT:org=0x0000c0len=0x02f40SRAMD:org=0x003000len=0x02000RAM0:org=0x87fe00len=0x100RAM1:org=0x87ff00len=0x100}SECTIONS{.text:{}SRAMT.data:{}SRAMD.stack:{}SRAMD.bss:{}SRAMD}如果照用户手册所写的在setting窗口里按照如下设置会提示 Illegalcom__ndcausesimulatorstop!如附件中的__所示而采用默认的内存地址映射就没有问题是不是不需要进行地址映射原因Dspc3x的地址__p中Locations0h–03Fhconsistofinterruptvectortrapvectorandreservedlocationsallofwhichareac__ssedovertheexternalmemoryport这块是cpu分配的,我们的那个demo的cmd里面没有涉及这部分地址,如果在tbrun的sim里面setting的时候也不设置这部分地址的话,在函数运行到ret指令要返回的时候sim访问到这部分地址空间就会出错,把这部分空间在sim中加上就可以了,cmd这么写也可以用,只是作为Sim的话,相当于我们需要把cpu默认的内部的一些地址给初始话了才可以;这个手册里面没有具体写,加上demo的cmd也刚好没有包括那部分地址,所以出了问题,将demo的cmd改一下,如MEMORY{ SRAMT:org=0x00000len=0x03000 SRAMD:org=0x003000len=0x02000 RAM0 :org=0x87fe00len=0x100 RAM1 :org=0x87ff00len=0x100}SECTIONS{ .text :{}SRAMT .data :{}SRAMD .stack :{}SRAMD .bss :{}SRAMD}
47.Tic3x汇编语言单元测试覆盖率显示异常察看工程文件stp没有条是信息由于汇编在编译时,没有加入调试选项–g
48.TBRun使用SAMBA服务测试linux的c++程序,出现了编译链接不过去原因是编译链接选项不正确导致的解决方法首先,指导他们工程师,把testbed软件生成的驱动程序,在linux上编译成可执行程序其次,在window上,通过telnet方式在测试一下该编译链接命令的正确性接着,拆分该编译、链接命令选项,保留先前的顺序最后,在linux下,编辑ldra_tbrun_cpp文件,加入相关的命令选项
49.对8052系列cpu进行系统覆盖率分析的注意事项在做8051以上cpu的系统覆盖率测试和性能分析时,由于程序是直接固化在cpu内部的存储器中,cpu取指令的时候在cpu外部总线上不会产生相应的__,这种情况需要通过仿真器代替真实cpu下载程序仿真器中的设定要注意选择cpu的类型(波特率无影响,19200);存储器映射要根据目标系统的实际情况选择程序区和数据区采用overlay(仿真器内)或者target(目标机)模式,这个会影响到性能分析的时间准确性一定要先下载程序,再开始RTView软件监控,否则程序没运行,覆盖率就会直接达到100%建立RTView工程时,应该使用keil51生成的m51文件,其他编译器生成的m51文件会导致覆盖率分析异常
50.80196汇编语言注意事项80196汇编语言系统覆盖率测试代码前需加上csegat2080h(否则编译不通过)csegat2018hdcb0fh(将ccr.1至1,使能16位,buswidth接高电平);插桩模版注意保护用到的寄存器(没有段的概念);80196Testbed静态分析,循环跳转前必须存在一基本块,否则数据流图和数据流分析会出现异常
51.Dsp5409注意事项Dsp5409的单元测试cmd文件编写需注意page0和page1其实是一段连续的内存,不能有重叠,否则编译虽然通过,但是执行会有异常;必须加上-c和cinitsection定义(globalvariables);链接o__文件直接跟在lnk500后;注意volatileimportinti的用法,不是通常意义上的变量;单元测试时并不能实时测试目标总线上的数据,所以目标机测试并没有太大的意义
52.Testbed选择分析文件时出错在用testbed打开被分析文件时报如下的错误这是由于testbed要为每个被分析的文件根据其所在目录和文件名算一个唯一的id号,报上面这种错误,是由于被分析的文件的目录名加上文件名更好算出的id号是非法的,这一般是由于一些特殊的中文组合造成的;在出现这种问题后,再打开其它任何文件都会报同样的错误,这是因为用来保持文件id号的staticid.dat文件的格式已经被破坏了;解决问题的办法是,首先将引起问题的被分析文件的名字或者目录改变一下;然后打开Testbed\Permdir目录下的staticid.dat文件,应当可以看到最后一行的数据和前面的明显有不同,如将最后一行异常数据删除既可;如果不是很清楚这种对文件的操作,可以采用另一种办法就是,将Testbed\Permdir目录和Testbed\cfg_backup都删除,但是这样您以前分析过的一些文件的id记录也就都没有了;
53.RTinsightPC104写地址注意事项DOS高端内存管理要加上,否则在往PC104端口写数据的时候,高端地址会受影响54.CodeVision的C程序内嵌汇编的静态分析C语言内嵌汇编写法为#a__的写法,Testbed分析报错;通过修改cvals.dat,在其中安照a__的序号加入#a__这个关键字就可以了55.80C32汇编Keil编译的问题Keil里默认不识别32扩展的资源的特殊寄存器,将REG
52.H中的定义拷贝到文件开头;新版本的定义Testbed不识别^符号,老本版的Keil中的定义没问题;在keil的中加头问题要写小写的include;56.8031系列汇编系统测试因为其P0是复用的,所以地址线我们要接到EEPROM上,如果是片内的就使用仿真器;在P0作为中断使用时,PSEN也会有些问题,所以要使用EEPROM上的OE(输出使能);覆盖率分析的时候,RET,RETI,以及所有的跳转的后面最好都加上NOP;如果使用仿真器的话,要先下载好代码,再让RTInsight处于监控状态,并且不能使用单步断点等操作;57.LDRATestbed有选择进行分析通过加/*LDRA_NO____YSIS*/和/*LDRA_____YSIS*/来实现在Testbed进行静态分析时不分析两处注释之间的部分;在TestbedUser__nual的387页;58.LDRATestbed分析的文件的名字被分析文件不能为sw,否则生成的swzz__zz就和Testbed本来定义的用来处理switch的函数同名了;59.TiCCS中的多段编译.text1:{a.o__.text}SRAM060.8031A__Testbed插装出错程序中如果有PUBLIC__IN而且在后面的程序中__IN是系统主程序的入口的话,那么Testbed在静态分析的时候会在SEGMENT的基础上再分析出一个__IN的主函数,这会导致Testbed在进行插装的时候在__IN的结束处出现错误61.x86A__Testbed静态分析出错程序中如果有函数名或者变量名和Testbed默认的关键字,如ABS,testbed不会报错,但是其实结果是有问题的,在Rtview导入的时候会报错,或者显示的内容不对62.x86A__宏展开ML*.a__*.a__如果程序中有宏,一定首先展开后再作后面的工作。