下载

1下载券

加入VIP
  • 专属下载特权
  • 现金文档折扣购买
  • VIP免费专区
  • 千万文档免费下载

上传资料

关闭

关闭

关闭

封号提示

内容

首页 Testbed常见问题解答FAQ1.0

Testbed常见问题解答FAQ1.0.doc

Testbed常见问题解答FAQ1.0

like0831
2011-12-20 0人阅读 举报 0 0 暂无简介

简介:本文档为《Testbed常见问题解答FAQ1.0doc》,可适用于IT/计算机领域

常见问题解答目录Testbed使用过程中问题解析.如何处理中文?.如何尽快入门:介绍tutorial.安装的问题:文字竖排、输入许可、软件狗驱动.用户许可无效“ControlFileConfiguration”.试用版不要更改日期.嵌入式系统软件的测试(bitmap插装).Testbed的bitmap插装技术.单元测试的策略:先黑盒再白盒.如何测试unix平台的软件.能否测试汇编软件?.软件工程中软件测试的应用:软件生命期的各个阶段(需要画图).介绍三种单元测试模式.介绍编码规则检查:MISRA.白盒测试.临时软件狗过期更新问题读不出序列号。.为何Testbed软件的主菜单的Configure下没有命令ResetCompilerOptions?.网络狗的本地使用如何设置:.有些朋友会问你们的产品TESTBED和国外同类测试产品相比优势在哪?.VC行命令cl的包含选项I不支持带空格的路径。.testbed系统测试报指定的编译工具和实际编译工具不匹配的现象。.类中引用类的错误.在C单元测试中当前测试事例无法引用前一个测试事例的对象.给vc程序做单元测试时TBrun分析不出正确的函数原型。.在什么情况下才对函数打桩?.在vxworks环境下做单元测试.在vxworks环境下用软件方式作系统测试.关于做白盒测试生成的报告时非常的慢甚至导致假死现象(所测评中心)。.安装testbed后没有配置当前编译环境就做单元测试build通不过。(在所测评中心).通过samba服务配置单元测试环境支持Unix上的源程序单元测试(在所部已做过).在对c单片机作单元测试时输出的浮点数都变成了.testbed静态分析报错.在Testbed界面或弹出的对话框中常常有英文显示不全的现象操作起来很乏。.在静态分析汇编程序前注意事项使用dspx和仿真器注意事项做mriK的单元测试注意事项单片机作系统测试程序没运行覆盖率就达如何测试Unix平台的软件嵌入式系统软件的测试关于UTYPE类型网络软件狗操作步骤:基于DSP系列(xx)的系统测试步骤及注意事项使用Testbed和RTinsight测试PC平台的程序步骤及注意事项基于asm的系统测试步骤及注意事项基于VxWorks系统用纯软件方式做系统覆盖率测试步骤及注意事项Testbed报告生成太慢RTview覆盖率报告中的问题关于switch的参数强制转换为int型Ticx汇编语言单元测试地址映射映射问题Ticx汇编语言单元测试覆盖率显示异常TBRun使用SAMBA服务测试linux的c程序出现了编译链接不过去。对系列cpu进行系统覆盖率分析的注意事项汇编语言注意事项Dsp注意事项Testbed选择分析文件时出错RTinsightPC写地址注意事项.CodeVision的C程序内嵌汇编的静态分析.C汇编Keil编译的问题.系列汇编系统测试.LDRATestbed有选择进行分析.LDRATestbed分析的文件的名字.TiCCS中的多段编译.ASMTestbed插装出错.xASMTestbed静态分析出错.xASM宏展开Testbed使用过程中问题解析.如何处理中文?问:在代码中出现的中文字符(包括字符串和注释)在格式化代码(ReformattedCode)中变成空格这就导致插装的程序在运行时无法显示中文比如一些按钮、菜单非常不方便。答:从ccTestbed开始能够处理中文方法如下:编辑Testbedccvalsdat和Testbedcppcppvalsdat:修改:SinglelinecommentflagSLCMTFforkanjiandchinachars为:SinglelinecommentflagSLCMTFforkanjiandchinachars还要修改:Flagforchineseorkanjicharsinstrings为:Flagforchineseorkanjicharsinstrings。.如何尽快入门:介绍tutorial问:Testbed如何入门?想看手册却发现手册就有多页而且是英文。答:Testbed比较庞大。学习使用它其实有很好的教材已经随Testbed安装了。从开始菜单中打开Testbed程序组会发现有几个Tutorial文档这就是LDRA公司编写的入门教材。Testbed的教材有:ccLDRATestbedTutorialSingleFileccLDRATestbedTutorialSetccLDRATestbedTutorialMSVCScribbleTBrun的教程有包含在TBrun的手册中。这些教程手把手的带领读者分析示例一步一步地完成测试流程如何处理常见问题。教程中大部分篇幅中都配有操作示意图容易理解。只要花上几天工夫学习教程边做边学就能基本掌握Testbed。相应的中文资料为:LDRATestbed中文安装指南docLDRATestbed中文使用指南docLDRATBrun中文使用指南doc.安装的问题:文字竖排、输入许可、软件狗驱动问:在WindowsMe上安装Testbed运行时发现窗口中的字符变成竖排。答:这是WindowsMe字体的一个bug替换为正确的字体文件即可。操作:用TestbedRicheddll替换WindowsSystemRicheddll。.用户许可无效“ControlFileConfiguration”问:安装完Testbed后运行弹出一个对话框“ControlFileConfiguration”不能继续运行。答:这说明用户许可无效。需要输入正确的许可信息。许可信息在随软件而来的一张纸上把上面的信息对照对话框输入注意大小写和空格敏感这样就可以使用了。另外输入的许可信息存放在TestbedTestbedctl中可以拷贝这个文件作为备份下次安装的时候直接把这个文件拷贝过来就可以了不需要再输入这些许可信息了。.试用版不要更改日期问:我安装了试用版Testbed为什么不能修改系统日期?答:安装时Testbed记录下了当时的日期并开始计时以保证一个月内许可有效。如果用户修改了系统日期与Testbed计算的日期不符误差在一天以上它就会注销现在的许可你必须重新申请许可。.嵌入式系统软件的测试(bitmap插装)存储空间、运行时间的限制bitmap插装RTinsight的使用创景移植了多种开发环境传统的测试软件覆盖的方法是在源代码中插装(instrument)路径记录代码然后编译执行之执行的过程中插装代码把路径执行历史写入到本地文件中然后对这个执行历史文件进行分析得到执行的覆盖率。对于一般运行在通用平台软件比如Windows、Unix等这样的方法可以满足要求。在嵌入式系统的软件测试中常常难以奏效。如何获得覆盖率信息成为一个难题。因为嵌入式系统的硬件存储空间小软件实时性要求高遇到的问题是这样的:第一插装之后的代码编译后目标文件体积变大甚至超过系统中的内存空间无法下载执行。第二插装的代码在执行中要记录执行历史信息这就影响了其他部分的执行时效经常会影响系统功能的实现第三在嵌入式系统中往往没有文件系统比如单片机系统执行历史文件无从生成。借助Testbed的接口开放、bitmap插装等技术我们已经在实践中解决了以上问题。采用bitmap插装技术(可以参考《Testbed的bitmap插装技术》)减小目标文件的体积并且把向文件中输出执行历史改为向指定内存端口(地址)输出这样就把操作文件的大量代码变成了一条简单的写端口指令更加减小了目标文件的大小执行速度更快。没有了文件那么我们如何获得执行历史呢?RTmonitor正是这样一种硬件装置它能够捕捉、存储真实目标机上指定端口(地址)的输出主机可以从RTmonitor中随时取出执行历史进行动态分析得到执行的覆盖信息。从而完美的解决了嵌入式系统的测试问题。.Testbed的bitmap插装技术经过静态分析确定了代码中的分支点并且每个分支点都有统一的编号。插装就是在所有分支点上部署“探头”插装代码当执行到这个点时探头就输出这个编号到文件中。从这个文件中我们就可以得到执行历史信息从而计算出代码的覆盖率。然而这样的方法会造成历史文件体积庞大频繁的读写文件也会影响软件的执行效率。bitmap插装能够解决这些问题。bitmap对应于常见的位图技术在历史文件中用一个位代表一个分支点代表这个点没有执行过代表已经执行了这样历史文件的最小体积就相当于分支点个数个字节。而且在执行过程中是在内存中开辟一个数组记录分支点信息程序结束时才写入文件的这就大大提高了执行效率。采用bitmap技术可以获得语句覆盖、分支覆盖和MCDC覆盖。.单元测试的策略:先黑盒再白盒黑盒测试是以用户的观点从输入数据与输出数据的对应关系出发进行测试的也就是根据程序外部特性进行的测试。它完全不涉及到程序的内部结构。很明显如果外部特性本身有问题或规格说明的规定有误用黑盒测试方法是发现不了的。另一方面白盒测试完全与之相反它只根据程序的内部结构进行测试而不考虑外部特性。如果程序结构本身有问题比如说程序逻辑有错误或是有遗漏。那是无法发现的。单元测试需要把黑盒测试和白盒测试结合起来。为了首先保证程序的正确性需要先进行黑盒测试不做覆盖率分析。之后对黑盒测试的用例做回归测试得出现有覆盖率这就节省了大量的动态分析实践这时大部分代码往往已经得到了执行。对剩余没有执行过的部分设计白盒的测试用例达到要求的覆盖率指标。.如何测试unix平台的软件Testbed对Unix平台的软件测试有独到的解决。虽然Testbed有运行于Unix上的版本但是比起Windows平台的版本界面和操作要逊色很多。采用Free软件Samba通过它Windows客户机可以把Unix主机当作自己的硬盘来访问我们可以在Windows上运行TestbedTBrun分析测试Unix平台的软件而实际的编译、执行依然在Unix平台上运行。具体方法是这样的。要分析的源代码仍然存放在Unix主机上只需要通过Samba把存放目录映射成为Windows客户机的一个硬盘这是我们就可以把源代码当作本地的文件一样分析了。而需要编译、执行代码时通过r执行Unix主机上的编译、执行指令即可。Testbed已经把这种配置集成到了TBrun系统中只需要在安装过程中配置一些参数你就可以轻松在熟悉的Windows上测试你的Unix软件了。.能否测试汇编软件?汇编语言仍然是软件开发的一支重要力量尤其是在实时性强的嵌入式系统中。遗憾的事市场上的大部分测试工具都不支持汇编语言。LDRA的Testbed可能是唯一的能够的是汇编语言代码的工具了。值得一提的是它支持多个家族的汇编。包括了几种主要开发平台:Intel的x、PowerPC、Motorola的K、DSP等等还有单片机的汇编。而且通过采用RTmonitor我们能够顺利完成这些平台的动态测试。在众多客户的实践中已经证明了这一点。.软件工程中软件测试的应用:软件生命期的各个阶段(需要画图)为了说明软件测试策略可以把软件工程过程表达成一个螺旋(如图)。首先系统工程为软件开发规定了任务从而把它与硬件要完成的任务明确的划分开。接着便是进行软件需求分析决定被开发软件功能、性能、限制调剂并确定该软件项目完成后的确认准则。沿着螺线向内旋转将进入软件设计和代码编写阶段。从而使得软件开发工作从抽象逐步走向具体化。软件测试工作也可从这一螺旋线上体现出来。在螺线的核心点针对每个单元的源代码进行单元测试。在各单元测试完成以后沿螺旋线外前进开始针对软件整体构造和设计的集成测试。然后是检验软件选全能否得到满足的确认测试最后来到螺线的最外层把软件和系统的其他部分协调起来当作一个整体完成系统测试。这样沿着螺旋线从内向外逐步扩展了测试的范围。软件测试并不是孤立的、静态的行为而是伴随着软件生命期的各个阶段。从早期就需要引入软件测试在各个阶段进行目标的检验可以保证软件的质量。以上用螺旋线表明的测试过程按四个步骤进行即单元测试、集成测试、确认测试和系统测试。图表示了测试的个步骤。开始时分别完成每个单元测试任务以确保每个模块能正常工作。单元测试大量的采用了白盒测试方法尽可能发现模块内部的程序差错。然后把已经测试过的模块组装起来进行集成测试。其目的在于检验与软件设计相关的程序结构问题。这是较多地采用黑盒测试方法来设计测试用例。完成集成测试以后要对开发工作初期制定的确认准则进行检验。确认测试是检验所开发的软件能否满足所有功能和性能需求的最后手段通常采用黑盒测试方法。完成确认测试以后给出的应该是合格的软件产品但为检验它能否与系统的其他部分(如硬件、数据库和操作人员)协调工作需要进行系统测试。严格的说系统测试已经超出了软件工程的范围。(摘自郑人杰著《计算机软件测试技术》).介绍三种单元测试模式从Testbed进入TBrun作单元测试会发现有三种方法进入TBrun:TBrunTestHarnessGeneratorIntegrateUnitsTBrunTestHarnessGeneratorIsolateUnitsTBrunTestHarnessGeneratorUnitTest这三种模式的差异在于对分析代码中各个单元的隔离程度。所谓隔离就是不与其他部分发生联系在源代码中的联系就是调用关系。IntegrateUnits适合于集成测试各个单元之间没有隔离你指定一个被测单元A测试驱动执行时A会调用真实的下层单元那么这时测试的实际上是一个部件。UnitTest对应于单元测试各个单元之间全部隔离你指定一个被测单元A测试驱动执行时A所调用的下层单元必须用桩函数来代替这是测试的只是A单元本身不与其他代码发生联系。IsolateUnits是LDRA新近推出的一种模式它介于IntegrateUnits和UnitTest之间。你可以灵活的选择哪些单元要被隔离而不是i中的全部放开或者U中的全部隔离。它很好的实现了一种测试策略:自底向上增式测试。增式测试是集成测试的一种方法。它的集成是逐步实现的集成测试也是逐步完成的也可以说它把单元测试与集成测试结合起来进行。自底向上增式测试表示逐步集成和逐步测试的工作是按调用图(CALLGRAPH)的层次自下而上进行的。.介绍编码规则检查:MISRAC语言的强大在于它的灵活正如一枚硬币的两面它的灵活也会导致软件容易出错、不易维护等等毛病。在经历漫长、痛苦的调试之后往往会发现原因可能非常简单。比如早年探测火星所运用的运载火箭因控制程序中错写逗号而爆炸。在软件维护中去阅读前辈们所写的代码是一件令人头疼的事情庞大、复杂的函数各式各样的编程风格……让人如读天书。正是如此人们总结了很多容易引起错误的用法逐渐的积累、发展成一套的编码规则在编写代码的早期就予以检查有效的提高了软件质量。比如有一条规则禁止在条件判断语句中比较两个浮点数是否相等因为浮点数都是有一定精度的相等的几率几乎为零那么这个条件不能满足。汽车工业界是最早注意到这些问题的年国际发动机工业软件可靠性协会MISRA发展并且应用了一套成熟的编码规则“汽车软件C语言使用指南”这份标准的产生在自动化行业记得地推动了使用“安全的C”进行编程这份标准在汽车行业被广泛接受同时他也被其他行业所广泛借鉴。介绍软件覆盖.白盒测试白盒测试又称结构测试或基于程序的测试。采用这一测试方法测试者可以看到被测的源程序他可用以分析程序的内部构造并且根据其内部构造设计测试用例。我们可以据此设计出大量的测试用例甚至可以无休止的测试下去。但是我们如何衡量测试到何种程度是否还需要测试下去?有位软件大师这样说:“不充分的测试是不可取的但是过分的测试更是一种罪过。”为了减少测试的盲目性引入了测试覆盖率。它要求对某些程序的结构特性做到一定程度的覆盖或者说基于覆盖的测试引导我们朝着提高覆盖率的方向努力从而找出那些已被忽视的程序错误。最为常见的程序结构覆盖是语句覆盖(StatementCoverage)。它要求被测程序的每一可执行语句在若干次测试中尽可能都检验过。这是最弱的逻辑覆盖准则。进一步则要求程序中所有判定的两个分支尽可能得到检验即分支覆盖或判定覆盖(BranchDecisionCoverage)。当判定式含有多个条件时可以要求每个软件的取值均得到检验即条件覆盖(BranchConditionCoverage)。在同时考虑条件的组合值及判定结果的检验时我们又有判定条件覆盖(BranchConditionCombinationCoverage)。还有MCDC覆盖、路径覆盖、LCSAJ覆盖等等。这些覆盖的级别由低到高达到这些覆盖的难度也越来越大。现在大部分行业只要求语句覆盖和分支覆盖。.临时软件狗过期更新问题读不出序列号。每个软件狗上都有序列号表示几号狗。从1到16号软件狗都对应一个读取序列号的USAFE*exe软件。17号以后的软件狗统一使用FieldExUtilexe读取序列号。可能问题:1是否成功安装该临时狗的驱动程序(集成在Testbed安装软件中)。     2换一台计算机再试。.为何Testbed软件的主菜单的Configure下没有命令ResetCompilerOptions?在testbedini中的CCLDRATestbed下添加ADDCOMPILERCONFIG=TRUE.网络狗的本地使用如何设置:在testbedini中的CCLDRATestbed下添加LOCALNETCDONGLE=TRUENETBIOSFIRST=TRUENETCTCPIP=FALSENETCDEPTNAME=LDRANET.有些朋友会问你们的产品TESTBED和国外同类测试产品相比优势在哪?答:我总结了以下几点优势可能别的测试软件也涉及到一些雷同的功能。当然还有很多的功能没写出来因为可能这种产品有那种又没有。首先在静态软件的质量分析方面·数据流分析和信息流分析技术·中文报告·含中文帮助的编码规则集其次,从动态覆盖率分析·LCSAJ覆盖率分析·MCDC测试计划·断言分析再次:CC的单元测试·测试驱动自动生成·桩模块自动生成·测试数据生成小精灵·GUI集成环境最后:·支持的语言和平台·技术支持工程师很专业.VC行命令cl的包含选项I不支持带空格的路径。方法:用软件将带空格的路径转换成短路径。(推荐)方法:手工改为不带空格的路径。(不推荐)方法:I空格“路径”(没试过).testbed系统测试报指定的编译工具和实际编译工具不匹配的现象。方法:运行TESTBED的主菜单ConfigureResetCompilerOptions设置编译环境的正确路径。.类中引用类的错误对vc工程的一个cpp程序做单元测试选中一个类的构造函数创建测试用例生成的驱动程序无法连接通过由于该类中使用了外部定义的另一个类该测试驱动程序找不到那个类的析构函数的定义。方法:建一个system集合分析包含当前分析文件和另一个被引用的类的cpp文件。.在C单元测试中当前测试事例无法引用前一个测试事例的对象给vc程序的一个类的方法做单元测试时步骤先给一个类的构造函数创建一个测试事例并做单元测试。步骤并选中测试事例创建的对象再给该类的另一方法创建测试事例。驱动程序无法编译原因是事例的类方法无法与事例的创建的对象关联起来。方法:做单元测试时必须要包含用户头文件分析。.给vc程序做单元测试时TBrun分析不出正确的函数原型。如std::vecter<SimEvent*>IntelligenceReceiver::Receive(…)方法:改为:usingnamespacestdvecter<SimEvent*>IntelligenceReceiver::Receive(…)再分析分析的函数原型正确但返回类型不正确变为:vecter了。再改:方法:修改源程序(不推荐)方法:手工修改驱动程序返回类型成vecter<SimEvent*>。.在什么情况下才对函数打桩?被测软件对外设访问而单元测试时对外设存取不现实被测软件所调用的子程序尚未编写(比如采用TOPDOWN开发模式)被测软件所调用的子程序尚未被测试需采用隔离测试策略.在vxworks环境下做单元测试.启动vxworks的simulator环境.若是白盒测试则插桩如下:.在vxworks环境下用软件方式作系统测试.首先要在testbed中创建system的set方式分析。.若有main函数则改名tbmain.插桩模式如下:.关于做白盒测试生成的报告时非常的慢甚至导致假死现象(所测评中心)。原因:当用户被测试的程序过大(如一个c程序上万行)做白盒测试生成覆盖率报告时将会为每一行生成详细的覆盖率信息如执行次数覆盖率统计等等报告也会非常的庞大。解决办法:用户编写的源程序不应过长最控制在行以内若过长则应改成多个c源程序。.安装testbed后没有配置当前编译环境就做单元测试build通不过。(在所测评中心)原因:在做单元测试以前没有设置正确的编译环境。解决:首先应该从testbed得主菜单的Configure下的ResetCompilerOptions去设置正确的编译器包括路径再做单元测试就没问题了。.通过samba服务配置单元测试环境支持Unix上的源程序单元测试(在所部已做过)请参考testbed的英文安装手册页另外注意:a在页的中的RootDiver应输入登陆用户名所在的路径。(如用户名是dz,在unix上的路径是homeddpc下则应该输入:homeddpcb在页用户一定要指定在unix上所使用的编译连接命令及其相关的选项。.在对c单片机作单元测试时输出的浮点数都变成了解决:若程序中存在有浮点数则连接时应采用支持浮点的库文件cfpllib所以在使用TBConfig配置c的单元测试时要选择支持浮点的编译连接声称目标代码。.testbed静态分析报错可能原因:本身源代码编译有错先编译通过。从testbed报错的对话框中察看报错行数进一步确认。查看格式化代码出错的行数即在哪一行中止了。在源代码中通过屏蔽的方法去定位错误。如在语句中statements前后必须加上{}否则可能分析报错:If(A)StatementsElseStatements.在Testbed界面或弹出的对话框中常常有英文显示不全的现象操作起来很乏。请参考单文件或多文件用户操作手册。.在静态分析汇编程序前注意事项.程序的源代码应大写否则被误认为是外部函数。.最好将所有的子过程尤其是中断服务子程序用XXXPROCNEAR和XXXENDP封装起来否则会被认成是主函数MAIN的一部分。使用dspx和仿真器注意事项.并口模式(EPP或BiDirectional或ECP)端口地址X(别的地址可能不同)仿真器有一个跳线必须选择MPSD同时仿真器与目标板的连接使用MPSD接口.仿真器与目标板的接线应与J端对齐.CodeComposer设置应sdgoxdrv驱动程序.给仿真器和目标板通电后使用SDConfigexe复位再启动CodeComposer.cs编译设置应选目标板C或CX再编译。.注意在连接目标代码时使用的cmd文件中的memory分配最好先参考相关的目标板的文档否则无法正确下载到目标板。做mriK的单元测试注意事项安装mrik编译器后在使用编译命令前在系统环境变量中添加:XRAYMASTER=C:mrikMASTER系统path中如果指向了其它的编译器可能会和mri的编译器冲突现象是编译后没有任何提示信息也生成不了obj文件解决:备份系统path所有的路径到文件中再清除与操作系统不相干的别的路径。目前tbconfig配置的驱动模板中没有在H和S前面加ldraspliter切割的时候结果不对如果被测试函数有返回的时候在程序中会有输出在其它环境下输出的结果为 这里输出结果为这样是不对的可以考虑在驱动模板中加个宏定义#define让输出结果为编译器放的目录不要有空格目录也不要超过个字符(否则I参数指向的include路径找不到)最好就是把整个目录放到根目录下就好。include包含文件的形势应用“”而不是<>,否则便以后找不到当前头文件。单片机作系统测试程序没运行覆盖率就达原因:可能是PRGRD、PRGCS和GND接线错改GND线接地。原因:可能是M映像文件不对问题解决。原因:由于rtinsight是采用地址比较模式的方式作系统测试所以在用rtinsight监控以前确保程序目标代码已下载到存储器。原因:可能RTinsight处于运行状态下下载的目标代码。因为rtinsight使用的地址比较模式测的汇编的系统覆盖率这样她认为全执行了。改为:在运行前下载目标代码再运行。如何测试Unix平台的软件Testbed对Unix平台的软件测试有独到的解决。虽然Testbed有运行于Unix上的版本但Windows平台的版本也能测试Unix程序。采用Free软件Samba通过它Windows客户机可以把Unix主机上的文件当作自己的本地文件来访问我们可以在Windows上运行TestbedTBrun分析测试Unix平台的软件而实际的编译、执行依然在Unix平台上运行。具体方法是这样的。要分析的源代码仍然存放在Unix主机上只需要通过Samba把存放目录映射成为Windows客户机的一个硬盘这是我们就可以把源代码当作本地的文件一样分析了。而需要编译、执行代码时通过r执行Unix主机上的编译、执行指令即可。Testbed已经把这种配置集成到了TBrun系统中只需要在安装过程中配置一些参数你就可以轻松在熟悉的Windows上测试你的Unix软件了。嵌入式系统软件的测试一般的测试软件覆盖的原理是在源代码中插装(instrument)路径记录代码然后编译执行之执行的过程中插装代码把路径执行历史写入到本地文件中然后对这个执行历史文件进行分析得到执行的覆盖率。对于一般运行在通用平台上的软件比如Windows、Unix等这样的方法可以满足要求。而在嵌入式系统的软件测试中常常难以奏效。如何获得覆盖率信息成为一个难题。因为嵌入式系统的硬件存储空间小软件实时性要求高遇到的问题是这样的:第一插装之后的代码编译后目标文件体积变大甚至超过系统中的内存空间无法下载执行。第二由于插装的代码在执行中要记录执行历史信息这就影响了其他部分的执行时效甚至会影响系统功能的实现第三在嵌入式系统中往往没有文件系统比如单片机系统执行历史文件无从生成。借助Testbed开放的接口、bitmap插装等技术我们已经在实践中解决了以上问题。采用bitmap插装技术(可以参考《Testbed的bitmap插装技术》)减小目标文件的体积并且把向文件中输出执行历史改为向指定内存端口(地址)输出这样就把操作文件的大量代码变成了一条简单的写端口指令更加减小了目标文件的大小执行速度更快。没有了文件那么我们如何获得执行历史呢?RTmonitor正是这样一种硬件装置它能够捕捉、存储真实目标机上指定端口(地址)的输出主机可以从RTmonitor中随时取出执行历史进行动态分析得到执行的覆盖信息。从而完美的解决了嵌入式系统的测试问题。关于UTYPE类型网络软件狗操作步骤:安装USB驱动启动SuperpronetServer设置SNETSERVERID即按Superpronet网络狗模式启动服务。LDRATestbed()的网络狗本地使用SNETSERVERID=RNBOSNDRIVER保持网络处于连接状态基于DSP系列(xx)的系统测试步骤及注意事项目的:用Rtinsight测试运行在dspxx上程序的覆盖率软件资源:Testbed,Rtview,Codecomposer,程序事例指令插装模板和supportc程序硬件资源:Rtinsight,TMSC目标板DSPice仿真器操作步骤:插装事例程序连接主机、DSPice和目标板。配置Codecomposer目标运行环境(并口x、驱动sdgoxxdvr)并reset复位。编译连接被插装的事例、supportc和cmd文件正确连接Rtinsight、隔离板和目标板。启动Rtview连接Rtinsight建立工程启动分析。通过Codecomposer调试运行被插装过的目标程序。注意事项:选择testbedrtinsightrtCINSTRDAT,supportc在Codecomposer中cmd文件。若步骤后连接不上目标可能错误(并口地址不错没有reset位(使用dsp复位软件)、线路、目标板问题。使用Testbed和RTinsight测试PC平台的程序步骤及注意事项目的:面向PC目标板的覆盖率分析软件资源:testbed,rtview,事例程序插装模板bc编译环境硬件资源:PC板子Rtinsight,隔离板转接板根数据带操作步骤:.用Testbed插装被测试事例(必须选择静态分析复杂度分析和指令的插装选项)·用TestbedRtinsight目录下的相应指令插装模板·在dos编译环境中最好使用短的插装文件名前缀·同时在插装配置对话框中选用bitmap和historyinonefile选项.编译被插装的事例·修改插装模板的支持文件supportc为了向特定地址或端口写特征值(例如:在bc环境用:poke(Segment,offset,eigenvalue)或outport(端口地址eigenvalue))。·添加MinModNum和FixedBranchNum宏定义MinModNum=Min(zzfileid)FixedBranchNum=或value(>=Max(qqqbranches)).检测RTView和Rtinsight间的软硬件连接·用COMx串口读和设置Rtinsight的ip地址使得与主机在同一个子网内。(并重启动ip生效)·用网线连接主机和Rtinsight设置具体的分析。.检测Rtinsight和PC目标板间的软硬件连接·连接好隔离板转接板和目标板间的数据线(注意问题:电源线一定不能接错高低位数据线不能反接)·启动目标板是否能正常启动·若启动正常将被插装过的程序执行文件拷贝到目标板。.使用RTView分析事例·创建工程·通过ip连接配置具体的分析·覆盖率分析注意事项:转接板的写方式(写内存和IO)决定了指令插装模板的中的对特征值的写函数形式和地址类型。性能分析过程:)Rtview指定指令插装模板来插装源文件)用编译器编译连接被插装的源文件生成执行文件exe)拷贝执行文件到目标板并在目标板执行。)从Rtview中选择性能分析测试基于asm的系统测试步骤及注意事项目的:用Rtinsight测试运行在上汇编程序的覆盖率性能分析软件资源:Testbed(asm),Rtview,CodeCruiser(带编译器),程序事例指令插装模板硬件资源:Rtinsight,EasyProbeFplus仿真器,目标板操作步骤:.修改程序给程序加注函数出入口标注(详细参考).事例程序(选择asm的指令插装模板).连接主机、仿真器和F目标板。.配置目标连接方式启动CodeCruiser建立工程编译连接被插装过的事例程序。.连接主机Rtinsight隔离板和仿真器。.启动Rtview建立工程做覆盖率和性能分析。注意事项:选择RTview给定的汇编指令插装模板。被插装的文件被正确编译后会产生omf目标文件和m符号表映射文件。若步骤不能启动则检查配置信息是否正确目标电源是否开串口线是否连好。所有连接完毕后在做事例的覆盖率时覆盖率始终没有变法(一直为零)可能错误:·隔离板和仿真器间的数据线高低位没对齐·编译连接的程序不是被插装过的事例程序隔离板的PRGRD和PRGCS没有正确连接基于VxWorks系统用纯软件方式做系统覆盖率测试步骤及注意事项目的:熟悉面向tornado开发环境的系统测试软件资源:testbed,tornado,事例程序面向Vxworks的插装模板硬件资源:(无)操作步骤:.Tbconfig配置平台环境(编译器的路径、指定插装模板和驱动模板).Testbed插装·被插装的文件中不能有函数main()若有应改为别的函数名。(为什么)。.Tornado编译连接被插装的文件。·用Tornado创建工程后应加入文件tbmainc(与指令插装模板在同一目录下)和别的被插装的文件一起编译连接。.在Vxworks的模拟环境中搜集产生的历史文件到historyexh·启动VxWorks模拟器·dowload目标文件·在shell中运行相关的函数(tbinit())用gethistory()历史数据。.用Testbed对historyexh数据做系统测试分析。注意:·插装的选项应选择bitmap和historyinonefile选项·测试中要熟悉被插装的文件结构和tbmain()的结构。如何获取死循环的数据Testbed报告生成太慢有时在静态分析和单元测试的时候生成报告慢也可以在testbed的报告生成配置的地方将不需要的报告去掉不生成RTview覆盖率报告中的问题()MOVA,RExecuted()CJNEA,#H,RAMERRExecuted()INCRExecuted()CJNER,#H,LOPExecuted()AJMPCLRRAMExecuted()RAMERR:Unexecuted()LJMPCONTExecuted针对非的情况(RTinsight端口赋值方式):我们的RTview的报告主要是根据格式化后的代码给出的这些工作都是基于Testbed的分析结果的基础上而我们对testbed数据的理解并不十分全面所以有个别地方会不对这种情况软件这边处理起来会比较麻烦因为这些情况大多比较特殊需要软件额外特殊处理。因此在我们的RTview里面添加了一个将测试数据转换为exh的功能(ExporttoEXH)将数据导出用testbed来分析(如果是set模式转换为historyexh,如果是单个文件转换为xxxexhxxx为文件名)只要RTinsight采集的数据没有问题用testbed分析的结果一般就不会有问题而且testbed的报告比较规范一些还有察看动态调用关系图和控制流图也比较直观。而对于:()MOVA,RExecuted()CJNEA,#H,RAMERRExecuted()INCRExecuted()CJNER,#H,LOPExecuted()AJMPCLRRAMExecuted()RAMERR:Unexecuted()LJMPCONTExecuted是行已经执行了没有把行统计进去(如果是这个错误的话应该是RTview处理上考虑的情况不完善)还是行本没有执行而被认为执行了从后面分支覆盖的结果看似乎是行没有执行而将其认为执行了不知道你认为的错误是这个吗?如果是后面这个错误的话可能是下面的原因造成的:系统测试需要在连续的调用以及ret之间添加nop指令因为系统取指是位的而这些指令是位的这样cpu取值的时候会把后面指令的前面部分读取出来但cpu不会运行而RTinsight这边就会认为该指令已被读取运行这样可能会造成测试结果出错这个在RTinsight使用指南里有写源代码插桩首先对要分析的源代码进行格式处理具体可以参考Testbed关于汇编语言分析的说明在做好最基本的处理后还需要在程序中RET和RETI的后面加上一条NOP指令添加的原因是cpu在进行RET等进行取指执行的时候由于指令补足的原因会将其后面的半个字节的指令带出如果不添加NOP的话可能会造成后面分析的结果误判。比较保险的做法是在连续的call之间也要加nop还有就是插装模版改为lldd<M><N>:nop关于switch的参数强制转换为int型类似于这样的代码段            插装后变为{……                         {……UnsignedlongI                switch((int)I):Switch(i):                     {{                                ……  Case:                     }    Break                }          Case:           Break             将i的类型强制转化为int型这可能导致原来long          Default:             型数据重复。           Break       }   }关于switch的一点资料:这是因为switchcase尽量(注意这两个字)使用跳转表(学过汇编的人应当知道吧)所以既然使用的是跳转表那么比较的只可能是整形数。(现在明白为什么switch只能判断整数了吧?)为了能够转化为跳转表那么case值就应当尽量集中。(现在明白为什么有些文章建议这么做了吧?)如果不能转化为跳转表那么降为ifelse(大部分编译器这么做)或者使用HashTable。Ticx汇编语言单元测试地址映射映射问题ccs设置为cxsimulatorcmd文件如下:MEMORY{SRAMT:org=xc,len=xfSRAMD:org=x,len=xRAM:org=xfe,len=xRAM:org=xff,len=x}SECTIONS{text:{}>SRAMTdata:{}>SRAMDstack:{}>SRAMDbss:{}>SRAMD}如果照用户手册所写的在setting窗口里按照如下设置会提示    Illegalcommandcausesimulatorstop!如附件中的图片所示而采用默认的内存地址映射就没有问题是不是不需要进行地址映射原因:Dspcx的地址map中Locationsh–Fhconsistofinterruptvector,trapvector,andreservedlocations,allofwhichareaccessedovertheexternalmemoryport这块是cpu分配的我们的那个demo的cmd里面没有涉及这部分地址如果在tbrun的sim里面setting的时候也不设置这部分地址的话在函数运行到ret指令要返回的时候sim访问到这部分地址空间就会出错把这部分空间在sim中加上就可以了cmd这么写也可以用只是作为Sim的话相当于我们需要把cpu默认的内部的一些地址给初始话了才可以这个手册里面没有具体写加上demo的cmd也刚好没有包括那部分地址所以出了问题将demo的cmd改一下如MEMORY{   SRAMT:org=x,len=x   SRAMD:org=x,len=x   RAM :org=xfe,len=x   RAM :org=xff,len=x}SECTIONS{       text  :{}>SRAMT       data  :{}>SRAMD       stack :{}>SRAMD       bss   :{}>SRAMD}Ticx汇编语言单元测试覆盖率显示异常察看工程文件stp,没有条是信息。由于汇编在编译时没有加入调试选项–gTBRun使用SAMBA服务测试linux的c程序出现了编译链接不过去。原因是编译链接选项不正确导致的。解决方法:首先指导他们工程师把testbed软件生成的驱动程序在linux上编译成可执行程序。其次在window上通过telnet方式在测试一下该编译链接命令的正确性。接着拆分该编译、链接命令选项保留先前的顺序。最后在linux下编辑ldratbruncpp文件加入相关的命令选项。对系列cpu进行系统覆盖率分析的注意事项在做

用户评价(0)

关闭

新课改视野下建构高中语文教学实验成果报告(32KB)

抱歉,积分不足下载失败,请稍后再试!

提示

试读已结束,如需要继续阅读或者下载,敬请购买!

文档小程序码

使用微信“扫一扫”扫码寻找文档

1

打开微信

2

扫描小程序码

3

发布寻找信息

4

等待寻找结果

我知道了
评分:

/29

Testbed常见问题解答FAQ1.0

VIP

在线
客服

免费
邮箱

爱问共享资料服务号

扫描关注领取更多福利