51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

12
返回列表 发新帖
楼主: jason_zy
打印 上一主题 下一主题

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

[复制链接]

该用户从未签到

21#
发表于 2010-5-17 14:46:20 | 只看该作者

回复 16# 的帖子

任何测试工具都有局限性的!!!感觉这个工具已经不错了!
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2010-5-17 14:50:42 | 只看该作者

转来的!很犀利!

《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 编辑 ]

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
回复 支持 反对

使用道具 举报

该用户从未签到

23#
发表于 2010-6-11 11:19:29 | 只看该作者
study...
回复 支持 反对

使用道具 举报

该用户从未签到

24#
发表于 2010-7-23 19:05:34 | 只看该作者

codetest问题

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。看看谁在用的话可以去弄过来还是没有问题的。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
回复 支持 反对

使用道具 举报

该用户从未签到

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

我前两年研究过使用的方法,如果有朋友感兴趣可以给我Email,我们可以交流交流。我的Email是:
littlecorn@126.com
回复 支持 反对

使用道具 举报

该用户从未签到

26#
发表于 2011-3-17 23:28:54 | 只看该作者
一般人学不会
回复 支持 反对

使用道具 举报

该用户从未签到

27#
发表于 2011-5-31 14:23:00 | 只看该作者
收藏了
回复 支持 反对

使用道具 举报

该用户从未签到

28#
发表于 2011-6-21 14:12:17 | 只看该作者
回复 支持 反对

使用道具 举报

该用户从未签到

29#
发表于 2011-8-12 09:45:12 | 只看该作者
哪位高手知道codetest**版下载网址啊?还请指点,找很久都没找到,我的邮箱是329243307@qq.com,谢谢!
回复 支持 反对

使用道具 举报

该用户从未签到

30#
发表于 2011-9-6 11:57:08 | 只看该作者
谁有下载地址呀!给个**版的。
回复 支持 反对

使用道具 举报

该用户从未签到

31#
发表于 2013-5-23 18:07:53 | 只看该作者
谁有下载版的codetest工具
回复 支持 反对

使用道具 举报

该用户从未签到

32#
发表于 2014-6-12 16:34:47 | 只看该作者
现在还有可以试用的老版本吗
回复 支持 反对

使用道具 举报

该用户从未签到

34#
发表于 2017-5-19 11:03:44 | 只看该作者
初来乍到,请多多关照。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-23 18:08 , Processed in 0.077409 second(s), 22 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表