CodeTEST嵌入式软件在线测试与分析工具在嵌入式系统开发中的应用

jason_zy

随着嵌入式技术的发展，嵌入式应用的不断增长以及嵌入式系统复杂性不断提高，要求嵌入式软件的规模和复杂性也不断提高，嵌入式软件的质量和开发周期对产品的最终质量和上市时间起到决定性的影响，嵌入式软件的开发、分析与测试成为了研究的热点。针对这一变化，本文提出了一种为嵌入式软件的开发、分析与测试特别设计的一种测试方法。
    嵌入式软件分析与测试的重要性
    随着计算机硬件技术的进步和元件质量逐步提高，元件的集成量也大大增加，从而使嵌入式设备的硬件性能得到了极大的提高；与此同时，通过采用成熟的商用操作系统，使系统运行在一个高性能的、可靠的软件平台上，为实现各种大型的复杂的应用打下了良好的基础。面对系统复杂性的增加，自然需要功能强大、性能稳定的应用软件与之相适应。所以，在嵌入系统开发中软件的代码量也越来越大，电子类产品的代码量以每两年就翻一翻的速度增长。同时，系统又要求应用也要精简高效、稳定可靠，使软件的开发在整个系统开发中所占的时间也越来越长，软件的质量对产品的最终质量起到了决定性的作用。但是事实上由于软件的开发缺乏科学的管理手段，开发的软件得不到很好的测试与分析，所编写的程序没有得到有效的测试就交付给用户使用。那些没有运行过的代码带着潜在的危险交付到客户手中，经常会给用户带来巨大的经济损失、为产品供应商带来信誉上的损失，在一些特殊的领域甚至会危及人的生命安全。
    综上所述，随着嵌入式系统的发展，我们迫切需要一种工具能够在软件开发的单板阶段、集成阶段、系统阶段等各阶段对嵌入式系统的软件进行实时在线的测试与分析，以保证系统的性能和可靠性。
    市面上流行的测试工具大致分为纯软件的测试工具和纯硬件的测试工具（如逻辑分析仪和仿真器等），下面我们从原理上分析使用传统的测试工具对嵌入式软件进行分析和测试的优缺点。
    纯软件的测试工具
    纯软件的测试工具采用的是软件打点技术，在被测代码中插入一些函数，用这些函数来完成数据的生成，并上送数据到目标系统的共享内存中。同时在目标系统中运行一个预处理任务，完成这些数据的预处理，将处理后的数据通过目标机的网口或串口上送到主机平台。这一切都需借助于用户的目标处理器完成。 通过以上过程，测试者得以知道程序当前的运行状态。 从上述分析可知，纯软件的测试工具的测试原理有两个必然存在的特点——插桩函数和预处理任务。
    由于插入插桩函数和预处理任务的存在，使系统的代码增大，更严重的是这些代码会对系统的运行效率有很大的影响（超过50%）。函数本身要有它的实现过程，它要完成数据的生成和暂存，而且这些函数在它的实现过程中还可能被其他优先级更高的中断程序所中断，预处理任务需要占用目标系统CPU处理时间、共享内存和通信通道完成数据的处理、数据的上送。由于这些弊端的存在，当采用纯软件测试工具对目标系统进行测试时，用户目标系统是在一种不真实的环境下运行的，我们所捕获的数据也是不够精确。
    所以采用纯软件的测试工具缺乏性能分析，它不能对用户目标系统中的函数和任务运行的时间指标进行精确的分析。
    当做覆盖率分析的时候，因为要大量打点，而打点多于200时就会影响系统的运行，所以只能做单元覆盖率分析且单元的程序量不能太大。
    它不能对内存的动态分配进行动态的观察。
    纯硬件的测试工具
    纯硬件工具通常用于系统的硬件设计与测试工作。当它用于软件的分析测试时，却无法满足用户的基本要求。
    以逻辑分析仪为例，逻辑分析仪是通过监控系统在运行时总线上的指令周期，并以一定的频率捕获这些信号，通过对捕获的信号进行分析来判断程序当前运行的状况。由于它使用的是采样的方式，难免会遗失一些重要的信号；同时，分析的范围也及其有限。以性能分析为例，当使用某种逻辑分析仪进行性能分析时，我们只能以抽样的方式，同时对８０个函数做性能分析，得到一个不精确的结果；而若使用CodeTEST，我们可以同时对128０００个函数做性能分析，得到一个精确的结果。
    当对程序做覆盖率分析时，因为硬件工具是从系统总线捕获数据的，如当CACHE打开我们会采用指令预取技术，从外存中读一段代码到一级CACHE中，这时逻辑分析仪在总线上监视到这些代码被读取的信号，就会报告这些代码已经被执行了,但实际上被送到CACHE中的代码可能根本没有被命中。为了避免这种误差必须把CACHE关闭掉，而CACHE关掉就不是系统真实的运行环境了，有时甚至会由于CACHE关闭而导致系统无法正常运行。
    而仿真器通常采用内存标记技术，它所关心的也是处理器从外存的代码段读取数据的情况。所以也无法在CACHE打开的方式下工作。而它的性能分析也是以仿真器的时间系统以抽样的方式进行的，也无法时实对系统进行真实的分析。所以我们所得出的结果也是不精确的。
    纯硬件工具根本不能对内存分配进行分析和检查的能力。
    CodeTEST对软件分析测试功能的实现原理
    AMC公司吸取了纯软件测试工具和纯硬件测试工具的优点，并对它们进行改善和提升后推出了CodeTEST。
由上图我们可以看出，程序员编写的源代码首先会通过CodeTEST的编译驱动器调用原编译器对进行预编译，然后CodeTEST的插桩器（源代码分析程序）对预编译好的源代码进行自动的插桩，即在需要插桩的关键位置写入一条赋值语句（如：amc_ctrt=0x74100009）,并把插入的标记送入一个数据库文件中生成一个符号数据库暂存起来，以备为以后分析时调用。然后，CodeTEST的编译驱动器又会调用原编译器对插桩后的代码进行编译生成可执行目标代码送到目标板上运行。当程序在目标系统运行到插桩点的位置时，目标板的控制总线和地址总线上会出现相应的控制信号和地址信号。当CodeTEST的辅助硬件（信号捕获探头）从控制总线和地址总线上监视到符合以上条件的信号时，CodeTEST会主动地从数据总线上把数据捕获回来送到CodeTEST的内存中暂存并对这些数据进行预处理，然后将预处理后的数据通过局域网送到工作平台上。通过与前面生成的符号数据库中的数据进行比较，我们就此得知当前程序的运行状态，借此完成对嵌入式软件的性能分析，高级覆盖率分析，内存分析和大容量的代码跟踪。
    由此可知，CodeTEST是一个硬件辅助软件的测试与分析工具，它一方面吸取软件打点技术，并对这种技术进行了改善，纯软件工具插入的是一个函数，而CodeTEST插入的是一条赋值语句， 它在汇编级也是一条语句，所以它执行的时间非常短，同时避免了被其它的中断所中断，所以它对目标系统的影响非常小（1%-15%）。另一方面，CodeTEST从纯硬件的测试工具那里吸取了从总线捕获数据的技术并且对它进行了改善，CodeTEST不再是采样的方式，它是通过监视系统总线，当程序运行到插入的特殊的点的时候才会主动的到数据总线上把数据捕获回来，借此，在同样的处理能力下，CodeTEST可以做到精确的数据观察。
    CodeTEST强大的测试分析功能。
    由于CodeTEST对软件打点技术和从总线捕获数据进行了改善和提升，正是这种原理上的优势，所以CodeTEST具有强大的性能分析、内存分析、高级覆盖率分析和代码跟踪功能。
    1． 强大的性能分析：CodeTEST能同时对128000个函数和1000个任务进行性能分析，可以精确的得出每个函数或任务执行的最大时间、最小时间和平均时间，精确度达到50ns；能够精确的显示各函数或任务之间的调用情况，帮助你发现系统瓶颈、优化系统和提升你的系统性能。
    2． 强大的覆盖率分析。 CodeTEST可以在系统真实的环境下，可以从单元级、集成级、系统级以及产品终端现场阶段进行嵌入式软件的分析与测试。帮助测试工程师掌握当前的测试覆盖率数据，指导测试用例的编写。
    3． 强大的内存分析。CodeTEST可以动态追踪内存分配，报告内存出错和相应的原始数据。他不仅可以在程序运行时报告为每条语句分配多少字节的内存，而且他可以鉴别20多种内存分配的错误。例如：CodeTEST可以捕捉“释放空指针（freeing a null pointer）”一样常见的程序错误，报告发生错误的函数和代码行帮，助你尽早发现动态内纯泄漏，而无需到系统崩溃时。
    4． 强大的代码跟踪分析。CodeTEST提供400K的追踪缓冲空间，能追踪150万行的源代码。我们可以设置触发器来追踪自己感兴趣的事件，可以显示运行过程中程序运行的实际情况，帮助你查找程序的BUG所在。
    结束语
    随着后ＰＣ时代的到来，嵌入式应用将会迅速增长，应用的复杂性也急剧增加，传统的软件分析和测试手段已不能满足嵌入式软件分析测试的基本要求，与此相比，AMC公司以其公司的几项专利技术，为我们提供的针对嵌入式软件分析测试的解决方案，为广大的嵌入式系统开发者提供了新的技术手段，使我们可以以全新的视角审视我们原有的开发过程，发现一切可以变的如此快捷、简单。

RMBchun

收藏学习

gmx7u3

初来乍到，请多多关照。

zjh99110_830209

OK

xjslyl

现在还有可以试用的老版本吗

aprilydd

谁有下载版的codetest工具

zyw19890317

谁有下载地址呀！给个**版的。

jessie_xumeng

哪位高手知道codetest**版下载网址啊？还请指点，找很久都没找到，我的邮箱是329243307@qq.com,谢谢！

shenchao

好

a248322143

收藏了

gameboyxz

一般人学不会

littlecorn

看到很多朋友在问这个工具有没有**，我想说的是，这个工具在软件上的东西实际上并不多，更加复杂的是在硬件的使用。他主要支持的编译器有：gnu、gcc、diab等等这些主流的编译器，支持Linux、windows、VxWorks等操作系统。对于VC平台的软件，据说是有一个主机版本的可以用来测试，但是我没有用过，我觉得意义不大，平台软件的测试手段很多，没必要用CodeTEST这么复杂的东西。

我前两年研究过使用的方法，如果有朋友感兴趣可以给我Email，我们可以交流交流。我的Email是：
littlecorn@126.com。

bingren84

codeTEST整个系统分为上位主机用的codeTEST manage(这部分是软件)、和主机建立网络通信的数据分析处理单元DPU(硬件)、和DPU通过1394火线连接的数据采集探头DCU(硬件的，这个还有配合很多种连接方式的板卡。因为，codeTEST的优势是利用hardware--in-circuit的探针时，测试数据采集是基于目标机系统总线的。可以将测试数据的输出所消耗的系统资源控制在最小范围内。有PCI卡、VME卡、专用CPU座，以及飞线。飞线是最为灵活的方式，相对也是比较复杂的)。
        codeTEST有四大功能：覆盖率分析、内存检测、性能分析和代码追踪。插桩分为三种探针模式：nativ、software-in-circuit和hardware--in-circuit。nativ是针对软件开发的早期做单元测试用，也就是在主机平台上进行测试，不需要目标系统。此时无需codeTEST硬件辅助系统。software-in-circuit时，测试就要放在目标机上进行了。但是这个时候是不需要codeTEST硬件支持的.被测软件经过codetest插桩器（ctcc）插桩后，调用原来的编译器编译成可执行代码放在目标系统运行，同时目标系统运行一个codetest提供的agent（ctserver）就可以了。ctserver实现测试数据的收集，通过目标系统的网络传输给上位主机。如果对于实时性要求不是特别苛刻，一般还是可以满足系统的时间约束的。这种方式的缺点就是插入的桩点是一个函数。这种插桩方式造成目标代码的膨胀，测试数据传递需要调用驱动组件，占用大量了CPU和I/O资源。致使系统实时性受影响，降低系统的性能。这并不是codetest的优势所在。第三种探针模式hardware--in-circuit。这种插桩方式下插桩测试数据是一个向总线上地址空间中某个确切的物理地址赋值的方式。不用多说，道理还是很简单的。cpu完成一个动作——将一个16bit的数据放到总线上去（如果没有操作系统，这个动作最少可以在一个总线周期内完成）。这样就能够将资源的占用降低到最小。需要硬件了。这个时候才是需要硬件的。硬件说白了就是从总线上采集这些数据。不管是哪个厂家，哪个体系的CPU，如果有codetest相应的板卡支持，直接插上去就是了。例如一张pci卡。但是有些系统，例如ARM上面没有标准的总线可供codeTEST使用，它有最灵活的方式--飞线。飞线采集探头的数据总线、地址总线、还有控制总线连接到目标机系统总线上。只要目标机系统总线的“写”周期满足采集探头的时序要求就可以了。支持面还是很广的：arm、mips、intel、ppc。
     原来codeTEST是amc公司的，后来被metroweks收购（摩托罗拉旗下子公司），现在又被飞思卡尔买了。它没有将codeTEST继续推广，而主要是用在自己的芯片上，做内部测试用。国内去可能还有存货吧！但是，技术支持不提供了。我用了一年，开始是挺难得。会了也就不难了。这里呢！要感谢一个人，北京关键科技的王友振。以前他做过这个的技术支持。我们买的工具没有在他的公司，但是该公司跟我们买工具的公司还是同行。找原来公司帮忙，说因为不再支持，只能加费用来指导。关键科技的王工知道我的情况后，亲自来了几次。中间也遇到很大的问题，但是对我们的帮助很大。王工为人谦虚，工作认真。再次谢过！
  最后，我想说大家要是用codetest，可以整个纯软件版本的。用一根网线跟目标机连就是了。license嘛不是问题！这个软件比较大。主程序加上RTOS的支持包有500多M。看看谁在用的话可以去弄过来还是没有问题的。

60124

study...

ting127

《CodeTEST嵌入式软件在线测试与分析工具在嵌入式系统开发中的应用》（参见http://bbs.51testing.com/thread-3149-1-1.html）一文论述了嵌入式软件分析和测试的重要性，着重分析纯软件、纯硬件和半硬半软（以CodeTEST为例）这三种测试工具的优缺点。笔者非常赞同《应用》文中认为对嵌入式软件进行测试分析是十分重要的观点，但不敢苟同其对纯软件测试工具的最终看法。

       为了证明纯软件工具不适合做性能分析、覆盖率分析以及内存动态分配动态观察，《应用》用了两段文字进行论证。先对纯软件工具的测试原理进行分析，指出纯软件工具“必然存在”“插桩函数和预处理任务”。这一步的分析和结论是正确的，不过其接下来的论证过程就变得有点牵强了。

一 不适合做性能分析？非也！

      因为“用户目标系统是在一种不真实的环境下运行”，导致纯软件工具“捕获的数据也是不够精确”，“不能对用户目标系统中的函数和任务运行的时间指标进行精确的分析”，“所以采用纯软件的测试工具缺乏性能分析”。乍看推导过程貌似没有问题，但仔细推敲，却发现其逻辑不够严密，有偷换概念之嫌。

      首先，“不真实的环境”并非只是纯软件工具所造成的，严格的说，只要在目标系统插桩了一条语句，那么目标系统就会与插桩前有所不同，变得“不真实”。测试工具必然会对其测试目标系统造成影响——这是一种客观事实。不管其影响如何，只要测试工具在测试过程中不把“薛定谔的猫”弄死，那么就不能否认该测试工具的作用。

      其次，我们知道，PC平台的所有性能分析工具均属于纯软件工具。那为何在嵌入式领域纯软件工具就不适合做性能分析了呢？《应用》一文给出的原因是纯软件工具捕捉的数据不够精确。孰是孰非？关键在于“性能分析”一词上，对该词的不同解读就会有不同的结论。性能分析只是一个过程，用户关心的是经历此过程是否能达到他们想要达到的目的。而进行“性能分析”的目的有二，一是对系统性能进行度量，二是找出系统性能瓶颈。系统的性能一般体现于功能与所需资源（时间、内存等）的比值，如任务上下文切换时间、中断响应时间等等。如果不进行软件插桩，又如何得到这些性能数据呢？看来《应用》认为的数据不够精确，绝非所指这些系统性能指标，而是特指某些代码段的运行时间，譬如函数的运行时间。使用纯软件工具插入的代码量大于半软半硬工具插入的代码量，二者相比，前者在测试代码段运行时间时产生的误差就会大于后者，所以《应用》才认为“纯软件工具捕捉的数据不够”半软半硬工具来得“精确”。还好，《应用》只是认为数据不够精确，并不否认纯软件工具获取测试数据的能力和科学性。

      如果嵌入式系统对实时指标要求不高，那么也就没必要高精度地获取每一个函数的运行时间等数据。对于大多数非实时的嵌入式系统而言，进行性能分析的目的在于找出系统性能瓶颈，通过系统优化来提高系统性能水平。那么纯软件工具是否可以找出目标系统的性能瓶颈？答案是肯定的。

      在拙作《浅论工具于嵌入式软件性能优化工作的重要性》一文提到，系统运行热点就是软件的系统性能瓶颈，而系统运行热点的粒度可分为任务级和函数级。任务级运行热点即为CPU占用率最高（或占用时间最长）的任务。要测量系统每个任务的CPU占用率，非要操作系统支持不可。如何支持？提供任务切换钩子函数由用户自己实现，或者操作系统本身提供统计各任务CPU占用率的功能，见图1。和任务CPU占用率实现原理一样，要提供函数级的CPU占用率，就必须在各函数之间插入一段代码，或者直接提供一个函数切换钩子函数，见图2。正如我们一般只关心任务的CPU占用率，而非运行一次所花的时间一样，函数的CPU占用率比单次运行函数所花的时间值更重要。CPU占用率高的函数就是系统运行热点。函数切换钩子函数的插入，会影响系统的运行效率，但和任务切换钩子函数一样，不会改变系统的运行逻辑，也不会影响各函数之间的CPU占用比例。纯软件工具和半软半硬工具在计算各函数运行时间的原理上是一致的，只不过纯软件工具需要在函数切换钩子函数内完成时间的统计运算，而半软半硬工具则可以把运算工作交由硬件完成，在函数切换钩子函数（此时已没有钩子函数的概念）的位置只需放置一条或数条标识语句即可。

图1 任务CPU占用率实现原理示意图









图2 函数CPU占用率实现原理示意图






二 不适合做覆盖率分析？非也！

      《应用》认为“当做覆盖率分析的时候，因为要大量打点，而打点多于200时就会影响系统的运行，所以只能做单元覆盖率分析且单元的程序量不能太大。”难道半软半硬工具在做覆盖率分析的时候，可以无需打点，抑或打点数目可以少于200？

三 不适合跟踪内存的动态分配？非也！

      《应用》直接得出纯软件工具“不能对内存的动态分配进行动态的观察”的结论，连分析推论都给省掉了。也许《应用》的作者认为该论述是真理，无需讨论，但事实上该说法纯属谬论。目前市场上可以提供内存动态分配跟踪功能的纯软件工具并不在少数这一事实足以推翻其观点。至于如何可以做到内存的动态分配跟踪的技术细节就不必在此展开了，各位细想片刻便可知晓。

四 不该忘记的事实！

      最后，特别需要提醒的是，《应用》的作者可能忘记了一件事实，CodeTEST也是有一个纯软件版本的。

[ 本帖最后由 ting127 于 2010-5-17 14:52 编辑 ]

ting127

任何测试工具都有局限性的！！！感觉这个工具已经不错了！

zhefish

功能很强，但设置较为复杂！

cr19800604

不错，学习了，我们这里一般是用来做覆盖率分析的，没想到它还有那么多的功能。

forpeople

很实用啊

huazai_888

hao好

zhouqing0

CT可以测试嵌入式软件也可以测试VC工程，
测试VC的，好像可以有破解版本~~
这个没有用过，
一直用CT测试嵌入式软件。
不过也有局限性~~