Testbed常见问题解答.doc

常见问题解答目 录Testbed使用过程中问题解析31如何处理中文？32如何尽快入门：介绍tutorial33安装的问题：文字竖排、输入许可、软件狗驱动44用户许可无效“Control File Configuration”45试用版不要更改日期46嵌入式系统软件的测试(bitmap插装)47Testbed的bitmap插装技术58单元测试的策略：先黑盒再白盒59如何测试unix平台的软件610能否测试汇编软件？611软件工程中软件测试的应用：软件生命期的各个阶段(需要画图）612介绍三种单元测试模式713介绍编码规则检查：MISRA714白盒测试815临时软件狗过期更新问题，读不出序列号。816为何Testbed软件的主菜单的Configure下没有命令Reset Compiler Options？917网络狗的本地使用，如何设置：918有些朋友会问，你们的产品TESTBED和国外同类测试产品相比，优势在哪？919VC行命令cl的包含选项/I不支持带空格的路径。1020testbed系统测试报指定的编译工具和实际编译工具不匹配的现象。1021类中引用类的错误1022在C+单元测试中，当前测试事例无法引用前一个测试事例的对象1122给vc+程序做单元测试时，TBrun分析不出正确的函数原型。1123在什么情况下才对函数打桩？1124在vxworks环境下做单元测试1125在vxworks环境下用软件方式作系统测试1226关于做白盒测试，生成的报告时非常的慢，甚至导致假死现象（28所测评中心）。1327安装testbed后，没有配置当前编译环境就做单元测试，build通不过。（在28所测评中心）1328通过samba服务配置单元测试环境支持Unix上的源程序单元测试（在28所3部已做过）1329在对c51单片机作单元测试时，输出的浮点数都变成了?1430testbed静态分析报错1531在Testbed界面，或弹出的对话框中，常常有英文显示不全的现象，操作起来很乏。1532在静态分析8086汇编程序前，注意事项1533. 使用dsp 3x 和仿真器注意事项1534. 做mri68K的单元测试注意事项1635. 8051单片机作系统测试，程序没运行，覆盖率就达100%1636. 如何测试Unix平台的软件1737. 嵌入式系统软件的测试1738. 关于UTYPE类型网络软件狗操作步骤：1839. 基于DSP 系列（2xx）的系统测试步骤及注意事项1840. 使用Testbed和RTinsight测试PC104平台的程序步骤及注意事项1841. 基于8051asm的系统测试步骤及注意事项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. RTinsight PC104写地址注意事项2854CodeVision的C程序内嵌汇编的静态分析285580C32汇编Keil编译的问题28568031系列汇编系统测试2857LDRA Testbed有选择进行分析2858LDRA Testbed分析的文件的名字2959Ti CCS中的多段编译29608031 ASM Testbed 插装出错2961x86 ASM Testbed 静态分析出错2962x86 ASM宏展开29Testbed使用过程中问题解析1如何处理中文？问：在代码中出现的中文字符（包括字符串和注释），在格式化代码（Reformatted Code）中变成空格，这就导致插装的程序在运行时无法显示中文，比如一些按钮、菜单，非常不方便。答：从c/c+ Testbed 7.07开始能够处理中文，方法如下：编辑%Testbed%ccvals.dat和%Testbed%cppcppvals.dat:修改:166 0 Single line comment flag SLCMTF for kanji and china chars.为:166 1 Single line comment flag SLCMTF for kanji and china chars.还要修改:182 0 Flag for chinese or kanji chars in strings为:182 1 Flag for chinese or kanji chars in strings。2如何尽快入门：介绍tutorial问：Testbed如何入门？想看手册，却发现手册就有800多页，而且是英文。答：Testbed比较庞大。学习使用它其实有很好的教材，已经随Testbed安装了。从开始菜单中打开Testbed程序组，会发现有几个Tutorial文档，这就是LDRA公司编写的入门教材。Testbed的教材有：c_c+ LDRA Testbed Tutorial - Single Filec_c+ LDRA Testbed Tutorial - Setc_c+ LDRA Testbed Tutorial - MSVC ScribbleTBrun的教程有包含在TBrun的手册中。这些教程手把手的带领读者分析示例，一步一步地完成测试流程，如何处理常见问题。教程中大部分篇幅中都配有操作示意图，容易理解。只要花上几天工夫学习教程，边做边学，就能基本掌握Testbed。相应的中文资料为：03.LDRA_Testbed中文安装指南1.2.doc05.LDRA_Testbed中文使用指南1.1.doc08.LDRA_TBrun中文使用指南1.2.doc3安装的问题：文字竖排、输入许可、软件狗驱动问：在Windows 98/Me上安装Testbed，运行时发现窗口中的字符变成竖排。答：这是Windows 98/Me字体的一个bug，替换为正确的字体文件即可。操作：用%Testbed%Riched32.dll替换%Windows%SystemRiched32.dll。4用户许可无效“Control File Configuration”问：安装完Testbed后运行，弹出一个对话框“Control File Configuration”，不能继续运行。答：这说明用户许可无效。需要输入正确的许可信息。许可信息在随软件而来的一张纸上，把上面的信息对照对话框输入，注意大小写和空格敏感，这样就可以使用了。另外，输入的许可信息存放在%Testbed%Testbed.ctl中，可以拷贝这个文件作为备份，下次安装的时候直接把这个文件拷贝过来就可以了，不需要再输入这些许可信息了。5试用版不要更改日期问：我安装了试用版Testbed，为什么不能修改系统日期？答：安装时Testbed记录下了当时的日期，并开始计时，以保证一个月内许可有效。如果用户修改了系统日期，与Testbed计算的日期不符，误差在一天以上，它就会注销现在的许可，你必须重新申请许可。6嵌入式系统软件的测试(bitmap插装)存储空间、运行时间的限制bitmap插装RTinsight的使用创景移植了多种开发环境传统的测试软件覆盖的方法是，在源代码中插装（instrument）路径记录代码，然后编译执行之，执行的过程中，插装代码把路径执行历史写入到本地文件中，然后对这个执行历史文件进行分析，得到执行的覆盖率。对于一般运行在通用平台软件，比如Windows、Unix等，这样的方法可以满足要求。在嵌入式系统的软件测试中，常常难以奏效。如何获得覆盖率信息成为一个难题。因为嵌入式系统的硬件存储空间小，软件实时性要求高，遇到的问题是这样的：第一，插装之后的代码编译后目标文件体积变大，甚至超过系统中的内存空间，无法下载执行。第二，插装的代码在执行中要记录执行历史信息，这就影响了其他部分的执行时效，经常会影响系统功能的实现；第三，在嵌入式系统中，往往没有文件系统，比如51单片机系统，执行历史文件无从生成。借助Testbed的接口开放、bitmap插装等技术，我们已经在实践中解决了以上问题。采用bitmap插装技术（可以参考Testbed的bitmap插装技术）减小目标文件的体积，并且把向文件中输出执行历史改为向指定内存端口（地址）输出，这样就把操作文件的大量代码变成了一条简单的写端口指令，更加减小了目标文件的大小，执行速度更快。没有了文件，那么我们如何获得执行历史呢？RTmonitor正是这样一种硬件装置，它能够捕捉、存储真实目标机上指定端口（地址）的输出，主机可以从RTmonitor中随时取出执行历史进行动态分析，得到执行的覆盖信息。从而完美的解决了嵌入式系统的测试问题。7Testbed的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的x86、PowerPC、Motorola的68K、DSP等等，还有51单片机的汇编。而且通过采用RTmonitor，我们能够顺利完成这些平台的动态测试。在众多客户的实践中，已经证明了这一点。11软件工程中软件测试的应用：软件生命期的各个阶段(需要画图）为了说明软件测试策略，可以把软件工程过程表达成一个螺旋（如图3.3）。首先，系统工程为软件开发规定了任务，从而把它与硬件要完成的任务明确的划分开。接着便是进行软件需求分析，决定被开发软件功能、性能、限制调剂并确定该软件项目完成后的确认准则。沿着螺线向内旋转，将进入软件设计和代码编写阶段。从而使得软件开发工作从抽象逐步走向具体化。软件测试工作也可从这一螺旋线上体现出来。在螺线的核心点针对每个单元的源代码，进行单元测试。在各单元测试完成以后，沿螺旋线外前进，开始针对软件整体构造和设计的集成测试。然后是检验软件选全能否得到满足的确认测试，最后，来到螺线的最外层，把软件和系统的其他部分协调起来，当作一个整体，完成系统测试。这样，沿着螺旋线，从内向外，逐步扩展了测试的范围。软件测试并不是孤立的、静态的行为，而是伴随着软件生命期的各个阶段。从早期就需要引入软件测试，在各个阶段进行目标的检验，可以保证软件的质量。以上用螺旋线表明的测试过程，按四个步骤进行，即单元测试、集成测试、确认测试和系统测试。图2表示了测试的4个步骤。开始时分别完成每个单元测试任务，以确保每个模块能正常工作。单元测试大量的采用了白盒测试方法，尽可能发现模块内部的程序差错。然后，把已经测试过的模块组装起来，进行集成测试。其目的在于检验与软件设计相关的程序结构问题。这是较多地采用黑盒测试方法来设计测试用例。完成集成测试以后，要对开发工作初期制定的确认准则进行检验。确认测试是检验所开发的软件能否满足所有功能和性能需求的最后手段，通常采用黑盒测试方法。完成确认测试以后，给出的应该是合格的软件产品，但为检验它能否与系统的其他部分（如硬件、数据库和操作人员）协调工作，需要进行系统测试。严格的说，系统测试已经超出了软件工程的范围。（摘自郑人杰著计算机软件测试技术）12介绍三种单元测试模式从Testbed进入TBrun作单元测试，会发现有三种方法进入TBrun：TBrun - Test Harness Generator - Integrate UnitsTBrun - Test Harness Generator - Isolate UnitsTBrun - Test Harness Generator - Unit Test这三种模式的差异在于对分析代码中各个单元的隔离程度。所谓隔离，就是不与其他部分发生联系，在源代码中的联系就是调用关系。Integrate Units适合于集成测试，各个单元之间没有隔离，你指定一个被测单元A，测试驱动执行时，A会调用真实的下层单元，那么这时测试的实际上是一个部件。Unit Test对应于单元测试，各个单元之间全部隔离，你指定一个被测单元A，测试驱动执行时，A所调用的下层单元必须用桩函数来代替，这是测试的只是A单元本身，不与其他代码发生联系。Isolate Units是LDRA新近推出的一种模式，它介于Integrate Units和Unit Test之间。你可以灵活的选择哪些单元要被隔离，而不是i中的全部放开或者U中的全部隔离。它很好的实现了一种测试策略：自底向上增式测试。增式测试是集成测试的一种方法。它的集成是逐步实现的，集成测试也是逐步完成的，也可以说它把单元测试与集成测试结合起来进行。自底向上增式测试表示逐步集成和逐步测试的工作是按调用图（CALL GRAPH）的层次自下而上进行的。13介绍编码规则检查：MISRA-C语言的强大在于它的灵活，正如一枚硬币的两面，它的灵活也会导致软件容易出错、不易维护等等毛病。在经历漫长、痛苦的调试之后，往往会发现原因可能非常简单。比如，早年探测火星所运用的运载火箭因控制程序中错写逗号而爆炸。在软件维护中，去阅读前辈们所写的代码是一件令人头疼的事情，庞大、复杂的函数，各式各样的编程风格让人如读天书。正是如此，人们总结了很多容易引起错误的用法，逐渐的积累、发展成一套的编码规则，在编写代码的早期就予以检查，有效的提高了软件质量。比如有一条规则，禁止在条件判断语句中比较两个浮点数是否相等，因为浮点数都是有一定精度的，相等的几率几乎为零，那么这个条件不能满足。汽车工业界是最早注意到这些问题的，1998年，国际发动机工业软件可靠性协会MISRA发展并且应用了一套成熟的编码规则“汽车软件C语言使用指南”，这份标准的产生在自动化行业记得地推动了使用“安全的C”进行编程，这份标准在汽车行业被广泛接受，同时他也被其他行业所广泛借鉴。介绍软件覆盖-14白盒测试白盒测试又称结构测试或基于程序的测试。采用这一测试方法，测试者可以看到被测的源程序，他可用以分析程序的内部构造，并且根据其内部构造设计测试用例。我们可以据此设计出大量的测试用例，甚至可以无休止的测试下去。但是，我们如何衡量测试到何种程度，是否还需要测试下去？有位软件大师这样说：“不充分的测试是不可取的，但是过分的测试更是一种罪过。”为了减少测试的盲目性，引入了测试覆盖率。它要求对某些程序的结构特性做到一定程度的覆盖，或者说基于覆盖的测试，引导我们朝着提高覆盖率的方向努力，从而找出那些已被忽视的程序错误。最为常见的程序结构覆盖是语句覆盖（Statement Coverage）。它要求被测程序的每一可执行语句在若干次测试中尽可能都检验过。这是最弱的逻辑覆盖准则。进一步则要求程序中所有判定的两个分支尽可能得到检验，即分支覆盖或判定覆盖（Branch/Decision Coverage）。当判定式含有多个条件时，可以要求每个软件的取值均得到检验，即条件覆盖（Branch Condition Coverage）。在同时考虑条件的组合值及判定结果的检验时，我们又有判定/条件覆盖（Branch Condition Combination Coverage）。还有MC/DC覆盖、路径覆盖、LCSAJ覆盖等等。这些覆盖的级别由低到高，达到这些覆盖的难度也越来越大。现在大部分行业只要求语句覆盖和分支覆盖。15临时软件狗过期更新问题，读不出序列号。每个软件狗上都有序列号，表示几号狗。从到号软件狗都对应一个读取序列号的USAFE*.exe软件。号以后的软件狗统一使用FieldExUtil.exe读取序列号。可能问题：.是否成功安装该临时狗的驱动程序(集成在Testbed安装软件中)。.换一台计算机再试。16为何Testbed软件的主菜单的Configure下没有命令Reset Compiler Options？在testbed.ini中的C/C+ LDRA Testbed下，添加ADD_COMPILER_CONFIG=TRUE17网络狗的本地使用，如何设置：在testbed.ini中的C/C+ LDRA Testbed下，添加LOCAL_NETC_DONGLE=TRUE;NETBIOS_FIRST = TRUENETC_TCP_IP=FALSENETC_DEPT_NAME=LDRANET18有些朋友会问，你们的产品TESTBED和国外同类测试产品相比，优势在哪？答：我总结了以下几点优势，可能别的测试软件也涉及到一些雷同的功能。当然，还有很多的功能没写出来，因为可能这种产品有，那种又没有。首先，在静态软件的质量分析方面，l 数据流分析和信息流分析技术l 中文报告l 含中文帮助的编码规则集其次, 从动态覆盖率分析l LCSAJ覆盖率分析l MC/DC测试计划l 断言分析再次：C/C+的单元测试l 测试驱动自动生成，l 桩模块自动生成l 测试数据生成小精灵l GUI集成环境 最后：l 支持的语言和平台l 技术支持工程师很专业19VC行命令cl的包含选项/I不支持带空格的路径。方法1：用软件将带空格的路径转换成短路径。（推荐）方法2：手工改为不带空格的路径。（不推荐）方法3：/I + 空格 + “路径” （没试过）20testbed系统测试报指定的编译工具和实际编译工具不匹配的现象。方法： 运行TESTBED的主菜单Configure / Reset Compiler Options设置编译环境的正确路径。21类中引用类的错误对vc+工程的一个cpp程序做单元测试，选中一个类的构造函数创建测试用例，生成的驱动程序无法连接通过，由于该类中使用了外部定义的另一个类，该测试驱动程序找不到那个类的析构函数的定义。方法：建一个system集合分析，包含当前分析文件和另一个被引用的类的cpp文件。22在C+单元测试中，当前测试事例无法引用前一个测试事例的对象给vc+程序的一个类的方法做单元测试时，步骤1，先给一个类的构造函数创建一个测试事例1，并做单元测试。步骤2，并选中测试事例1创建的对象，再给该类的另一方法创建测试事例2。驱动程序无法编译，原因是事例2的类方法无法与事例1的创建的对象关联起来。方法：做单元测试时，必须要包含用户头文件分析。 22给vc+程序做单元测试时，TBrun分析不出正确的函数原型。如，std:vecter IntelligenceReceiver:Receive() 方法： 改为： using namespace std;vecter IntelligenceReceiver:Receive() 再分析， 分析的函数原型正确，但返回类型不正确，变为：vecter了。 再改： 方法1： 修改源程序（不推荐） 方法2： 手工修改驱动程序返回类型成vecter。23在什么情况下才对函数打桩？1. 被测软件对外设访问，而单元测试时对外设存取不现实；2. 被测软件所调用的子程序尚未编写（比如采用TOP-DOWN开发模式）；3. 被测软件所调用的子程序尚未被测试4. 需采用隔离测试策略24在vxworks环境下做单元测试1启动vxworks的simulator环境.2若是白盒测试，则插桩如下：25在vxworks环境下用软件方式作系统测试1首先要在testbed中创建system的set方式分析。2若有main函数，则改名tbmain.3插桩模式如下：3026关于做白盒测试，生成的报告时非常的慢，甚至导致假死现象（28所测评中心）。原因：当用户被测试的程序过大（如，一个.c程序上万行），做白盒测试生成覆盖率报告时，将会为每一行生成详细的覆盖率信息，如执行次数，覆盖率统计等等，报告也会非常的庞大。解决办法：用户编写的源程序不应过长，最控制在2000行以内，若过长，则应改成多个.c源程序。27安装testbed后，没有配置当前编译环境就做单元测试，build通不过。（在28所测评中心）原因：在做单元测试以前，没有设置正确的编译环境。解决：首先应该从testbed得主菜单的Configure下的Reset Compiler Options去设置正确的编译器包括路径，再做单元测试，就没问题了。28通过samba服务配置单元测试环境支持Unix上的源程序单元测试（在28所3部已做过）请参考testbed的英文安装手册62页，另外注意：a. 在66页的 中的Root Diver应输入登陆用户名所在的路径。（如用户名是 dz, 在unix上的路径是/home/dd/pc-10下，则应该输入：/home/dd/pc-10b. 在69页，用户一定要指定在unix上，所使用的编译连接命令及其相关的选项。29在对c51单片机作单元测试时，输出的浮点数都变成了?解决：若程序中存在有浮点数，则连接时，应采用支持浮点的库文件c51fpl.lib，所以在使用TBConfig配置c51的单元测试时，要选择支持浮点的编译连接声称目标代码。30testbed静态分析报错可能原因：1. 本身源代码编译有错，先编译通过。2. 从testbed报错的对话框中，察看报错行数，进一步确认。3. 查看格式化代码出错的行数，即在哪一行中止了。4. 在源代码中通过屏蔽的方法去定位错误。如在语句中statements1前后必须加上，否则，可能分析报错：If (A) Statements1;Else Statements2; 31在Testbed界面，或弹出的对话框中，常常有英文显示不全的现象，操作起来很乏。请参考单文件或多文件用户操作手册。32在静态分析8086汇编程序前，注意事项1 程序的源代码应大写，否则被误认为是外部函数。2 最好将所有的子过程，尤其是中断服务子程序，用XXX PROC NEAR 和 XXX ENDP封装起来，否则会被认成是主函数MAIN的一部分。33. 使用dsp 3x 和仿真器注意事项1并口模式（EPP或Bi Directional 或 ECP） + 端口地址 0X378（别的地址可能不同）2. 仿真器有一个跳线必须选择MPSD，同时仿真器与目标板的连接使用 MPSD接口3仿真器与目标板的接线应与J1端对齐4CodeComposer设置，应sdgo3x.drv驱动程序5给仿真器和目标板通电后，使用SDConfig.exe复位，再启动CodeComposer6cs编译设置应选目标板C32或C3X，再编译。7注意在连接目标代码时，使用的cmd文件中的memory分配，最好先参考相关的目标板的文档，否则，无法正确下载到目标板。34. 做mri68K的单元测试注意事项1. 安装mri68k编译器后，在使用编译命令前，在系统环境变量中添加：XRAYMASTER = C:mri68kMASTER2. 系统path中如果指向了其它的编译器，可能会和mri的编译器冲突，现象是编译后没有任何提示信息也生成不了obj文件；解决:备份系统path所有的路径到文件中，再清除与操作系统不相干的别的路径。3. 目前tbconfig配置的驱动模板中没有在H和S前面加 ldra ，spliter切割的时候结果不对； 4. 如果被测试函数有返回的时候，在程序中会有输出 %，在其它环境下输出的结果为%，这里输出结果为%，这样是不对的，可以考虑在驱动模板中加个 宏定义 #define % % 让输出结果为 % 5. 编译器放的目录不要有空格，目录也不要超过8个字符，（否则 -I 参数指向的include路径找不到）最好就是把整个目录放到根目录下就好。6. include包含文件的形势应用“”而不是,否则，便以后找不到当前头文件。35. 8051单片机作系统测试，程序没运行，覆盖率就达100%原因1：可能是PRGRD、PRGCS和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开放的接口、bitmap插装等技术，我们已经在实践中解决了以上问题。采用bitmap插装技术（可以参考Testbed的bitmap插装技术）减小目标文件的体积，并且把向文件中输出执行历史改为向指定内存端口（地址）输出，这样就把操作文件的大量代码变成了一条简单的写端口指令，更加减小了目标文件的大小，执行速度更快。没有了文件，那么我们如何获得执行历史呢？RTmonitor正是这样一种硬件装置，它能够捕捉、存储真实目标机上指定端口（地址）的输出，主机可以从RTmonitor中随时取出执行历史进行动态分析，得到执行的覆盖信息。从而完美的解决了嵌入式系统的测试问题。38. 关于UTYPE类型网络软件狗操作步骤：1. 安装USB驱动2. 启动Superpronet Server3. 设置SNET_SERVER_ID，即按Superpronet网络狗模式启动服务。4. LDRA Testbed (7.3.2)的网络狗本地使用SNET_SERVER_ID=RNBO_SN_DRIVER5. 保持网络处于连接状态39. 基于DSP 系列（2xx）的系统测试步骤及注意事项目的： 用Rtinsight测试运行在dsp 2xx上程序的覆盖率软件资源：Testbed, Rtview, Code composer, 程序事例， 指令插装模板和 support.c程序硬件资源：Rtinsight, TMS320C240目标板，DSPice仿真器操作步骤：1. 插装事例程序2. 连接主机、DSPice和目标板。3. 配置Code composer目标运行环境（并口0x378、驱动sdgo2xx.dvr），并reset复位。4. 编译连接被插装的事例、support.c和cmd文件5. 正确连接Rtinsight、隔离板和目标板。6. 启动Rtview，连接Rtinsight，建立工程启动分析。7. 通过Code composer调试运行被插装过的目标程序。注意事项：1. 选择testbedrtinsightrt_CINSTR.DAT, support.c2. 在Code composer中cmd文件。3. 若步骤2后，连接不上目标，可能错误（并口地址不错，没有reset位（使用dsp复位软件）、线路、目标板问题。40. 使用Testbed和RTinsight测试PC104平台的程序步骤及注意事项目的： 面向PC104目标板的覆盖率分析软件资源：testbed, rtview,事例程序，插装模板，bc编译环境硬件资源：PC104板子，Rtinsight, 隔离板，转接板，2根数据带操作步骤：1 用Testbed插装被测试事例(必须选择静态分析，复杂度分析和指令的插装选项) 用TestbedRtinsight目录下的相应指令插装模板 在dos编译环境中最好使用短的插装文件名前缀 同时在插装配置对话框中选用bitmap和history in one file选项. 2 编译被插装的事例 修改插装模板的支持文件support.c，为了向特定地址或端口写特征值（例如：在bc环境用：poke(Segment,offset, eigenvalue)；或outport(端口地址，eigenvalue)）。 添加MinModNum和FixedBranchNum宏定义MinModNum= Min(zzfileid)FixedBranchNum=1024或value(=Max(qqqbranches)3 检测RTView和Rtinsight间的软硬件连接 用COMx串口读和设置Rtinsight的ip地址，使得与主机在同一个子网内。（并重启动ip生效） 用网线连接主机和Rtinsight，设置具体的分析。4 检测Rtinsight和PC104目标板间的软硬件连接 连接好隔离板，转接板和目标板间的数据线(注意问题：电源线一定不能接错，高低16位数据线不能反接) 启动目标板，是否能正常启动 若启动正常将被插装过的程序执行文件，拷贝到目标板。5 使用RTView分析事例 创建工程 通过ip连接配置具体的分析 覆盖率分析注意事项： 转接板的写方式（写内存和I/O）决定了指令插装模板的中的对特征值的写函数形式和地址类型。性能分析过程：1) Rtview指定指令插装模板来插装源文件2) 用编译器编译连接被插装的源文件生成执行文件exe3) 拷贝执行文件到目标板，并在目标板执行。4) 从Rtview中选择性能分析测试41. 基于8051asm的系统测试步骤及注意事项目的： 用Rtinsight测试运行在8051上汇编程序的覆盖率，性能分析软件资源： Testbed(8031asm), Rtview, Code Cruiser（带编译器）, 程序事例，指令插装模板硬件资源：Rtinsight, EasyProbe 8052F plus仿真器, 8051目标板操作步骤：1 修改程序，给程序加注函数出入口标注（详细参考）2 事例程序(选择8051asm的指令插装模板)3 连接主机、仿真器 和8052F目标板。4 配置目标，连接方式，启动Code Cruiser，建立工程，编译连接被插装过的事例程序。5 连接主机，Rtinsight，隔离板和仿真器。6 启动Rtview，建立工程做覆盖率和性能分析。注意事项：1. 选择RTview给定的汇编指令插装模板。2. 被插装的文件被正确编译后，会产生omf目标文件，和m51符号表映射文件。3. 若步骤4不能启动，则检查配置信息是否正确，目标电源是否开，串口线是否连好。4. 所有连接完毕后，在做事例的覆盖率时，覆盖率始终没有变法（一直为零），可能错误： 隔离板和仿真器间的数据线高低位没对齐 编译连接的程序不是被插装过的事例程序隔离板的PRG_RD和PRG_CS没有正确连接42. 基于VxWorks系统用纯软件方式做系统覆盖率测试步骤及注意事项目的： 熟悉面向tornado开发环境的系统测试软件资源：testbed, tornado, 事例程序，面向Vxworks的插装模板硬件资源：（无）操作步骤：1 Tbconfig配置平台环境（编译器的路径、指定插装模板和驱动模板）2 Testbed插装 被插装的文件中不能有函数main()，若有，应改为别的函数名。（为什么）。3 Tornado编译，连接被插装的文件。 用Tornado创建工程后，应加入文件tbmain.c(与指令插装模板在同一目录下)和别的被插装的文件一起编译连接。4 在Vxworks的模拟环境中，搜集产生的历史文件到history.exh 启动VxWorks模拟器 dowload 目标文件 在shell中运行相关的函数（tbinit()），用get_history()历史数据。5 用Testbed对history.exh数据做系统测试分析。注意： 插装的选项应选择bitmap和history in one file选项 测试中，要熟悉被插装的文件结构和tbmain()的结构。如何获取死循环的数据43. Testbed报告生成太慢有时在静态分析和 单元测试的时候 生成报告慢，也可以在testbed的报告生成配置的地方，将不需要的报告去掉不生成44. RTview 覆盖率报告中的问题30(22)MOV A,R0Executed31(23)CJNE A,#55H,RAMERRExecuted32(24)INC R0Executed33(25)CJNE R0,#80H,LOPExecuted34(26)AJMP CLRRAMExecuted36(27)RAMERR:Unexecuted37(28)LJMP CONTExecuted针对非8031的情况（RTinsight端口赋值方式）：我们的RTview的报告主要是根据格式化后的代码给出的，这些工作都是基于Testbed的分析结果的基础上，而我们对testbed数据的理解并不十分全面，所以有个别地方会不对，这种情况软件这边处理起来会比较麻烦，因为这些情况大多比较特殊，需要软件额外特殊处理。因此在我们的RTview里面添加了一个将测试数据转换为exh的功能（Export to EXH），将数据导出用testbed来分析（如果是set模式转换为history.exh,如果是单个文件转换为xxx.exh，xxx为文件名），只要RTinsight采集的数据没有问题，用testbed分析的结果一般就不会有问题，而且testbed的报告比较规范一些，还有察看动态调用关系图和控制流图也比较直观。而对于8031：30(22)MOV A,R0Executed31(23)CJNE A,#55H,RAMERRExecuted32(24)INC R0Executed33(25)CJNE R0,#80H,LOPExecuted34(26)AJMP CLRRAMExecuted36(27)RAMERR:Unexecuted37(28)LJMP CONTExecuted是37行已经执行了 没有把36行统计进去（如果是这个错误的话应该是RTview处理上考虑的情况不完善）；还是37行本没有执行而被认为执行了，从后面分支覆盖的结果看， 似乎是 37行没有执行而将其认为执行了，不知道你认为的错误是这个吗？如果是后面这个错误的话，可能是