嵌入式软件测试的秘诀在哪里(3)

　　.源码级调试器[Source-level Debugger]

　　这种调试器一般提供单步或多步调试、断点设置、内存检测、变量查看等功能，是嵌入式调试最根本有效的调试方法。比如VxWorks TornadoII提供的gdb就属于这一种。

　　.简单实用的打印显示工具[printf]

　　printf或其它类似的打印显示工具估计是最灵活最简单的调试工具。打印代码执行过程中的各种变量可以让你知道代码执行的情况。但是，printf对正常的代码执行干扰比较大(一般printf占用CPU比较长的时间)，需要慎重使用，最好设置打印开关来控制打印。

　　.ICE或JTAG调试器[In-circuit Emulator]

　　ICE是用来仿真CPU核心的设备，它可以在不干扰运算器的正常运行情况下，实时的检测CPU的内部工作情况。像桌面调试软件所提供的：复杂的条件断点、先进的实时跟踪、性能分析和端口分析这些功能，它也都能提供。ICE一般都有一个比较特殊的CPU，称为外合(bond-out)CPU。这是一种被打开了封装的CPU，并且通过特殊的连接，可以访问到CPU的内部信号，而这些信号，在CPU被封装时，是没法“看到”的。当和工作站上强大的调试软件联合使用时，ICE就能提供你所能找到的最全面的调试功能。但ICE同样有一些缺点：昂贵;不能全速工作;同样，并不是所有的CPU都可以作为外合CPU的，从另一个角度说，这些外合CPU也不大可能及时的被新出的CPU所更换。JTAG(Joint Test Action Group)虽然它最初开发出来是为了监测IC和电路连接，但是这种串行接口扩展了用途，包括对调试的支持。AD公司为Blackfin设计的Visual Dsp++就支持高速的JTAG调试。

　　.ROM监视器[ROM Monitor]

　　ROM监控器是一小程序，驻留在嵌入系统ROM中，通过串行的或网络的连接和运行在工作站上的调试软件通信。这是一种便宜的方式，当然也是最低端的技术。它除了要求一个通信端口和少量的内存空间外，不需要其它任何专门的硬件。并提供了如下功能：下载代码、运行控制、断点、单步步进、以及观察、修改寄存器和内存。因为ROM监控器是操作软件的一部分，只有当你的应用程序运行时，它才会工作。如果你想检查CPU和应用程序的状态，你就必须停下应用程序，再次进入ROM监控器。

　　.Data监视器[Data Monitor]

　　这种监视器在不停止CPU运行的情况下不仅可以显示指定变量内容，还可以收集并以图形形式显示各个变量的变化过程。

　　.OS监视器[Operating System Monitor]

　　操作系统监视器可以显示诸如任务切换、信号量收发、中断等事件。一方面，这些监视器能够为你呈现事件之间的关系和时间联系;另一方面，还可以提供对信号量优先级反转、死锁和中断延时等问题的诊断。

　　.性能分析工具[Profiler]

　　可以用来测试CPU到底耗在那里。profiler工具可以让你知道系统的瓶颈在那里、CPU的使用率以及需要优化的地方。

　　.内存测试工具[Memory Teseter]

　　可以找到内存使用的问题所在，比如内存泄露、内存碎片、内存崩溃等问题。如果发现系统出现一些不可预知的或间歇性的问题，就应该使用内存测试工具测测看。

　　.运行跟踪器[Execution Tracer]

　　可以显示CPU执行了哪些函数、谁在调用、参数是什么、何时调用等情况。这种工具主要用于测试代码逻辑，可以在大量的事件中发现异常的那些。

　　.覆盖工具[Coverage Tester]

　　主要显示CPU具体执行了那些代码，并让你知道那些代码分支没有被执行到。这样有助于提高代码质量并消除无用代码。

　　.GUI测试工具[GUI Tester]

　　很多嵌入式应用带有某种形式的图形用户界面进行交互，有些系统性能测试足根掘用户输入响应时间进行的。GUI测试工具可以作为脚本工具有开发环境中运行测试用例，其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程(Rational公司的robot和Mercury的Loadrunner工具是杰出的代表)。很多嵌入式设备没有GUI，但常常可以对嵌入式设备进行插装来运行GUI测试脚本，虽然这种方式可能要求对被测代码进行更改，但是节省了功能测试和回归测试的时间。

　　.自制工具[Home-madetester]

　　在嵌入式应用中，有时候为了特定的目的，需要自行编写一些工具来达到某种测试目的。本人曾经编写的视频流录显工具在测试视频会议数据流向和变化上帮了大忙,帮公司找到了几个隐藏很深的bug。

　　2.尽早发现内存问题

　　内存问题危害很大，不容易排查，主要有三种类型:内存泄露、内存碎片和内存崩溃。对于内存问题态度必须要明确，那就是早发现早“治疗”。在软件设计中，内存泄露的“名气”最大，主要由于不断分配的内存无法及时地被释放，久而久之，系统的内存耗尽。即使细心的编程老手有时后也会遭遇内存泄露问题。有测试过内存泄露的朋友估计都有深刻地体验，那就是内存泄露问题一般隐藏很深，很难通过代码阅读来发现。有些内存泄露甚至可能出现在库当中。有可能这本身是库中的bug，也有可能是因为程序员没有正确理解它们的接口说明文档造成错用。

　　在很多时候，大多数的内存泄露问题无法探测，但可能表现为随机的故障。程序员们往往会把这种现象怪罪于硬件问题。如果用户对系统稳定性不是很高，那么重启系统问题也不大;但，如果用户对系统稳定很高，那么这种故障就有可能使用户对产品失去信心，同时也意味着你的项目是个失败的项目。由于内存泄露危害巨大，现在已经有许多工具来解决这个问题。这些工具通过查找没有引用或重复使用的代码块、垃圾内存收集、库跟踪等技术来发现内存泄露的问题。每个工具都有利有弊，不过总的来说，用要比不用好。总之，负责的开发人员应该去测试内存泄露的问题，做到防患于未然。

　　内存碎片比内存泄露隐藏还要深。随着内存的不断分配并释放，大块内存不断分解为小块内存，从而形成碎片，久而久之，当需要申请大块内存是，有可能就会失败。如果系统内存够大，那么坚持的时间会长一些，但最终还是逃不出分配失败的厄运。在使用动态分配的系统中，内存碎片经常发生。目前，解决这个问题最效的方法就是使用工具通过显示系统中内存的使用情况来发现谁是导致内存碎片的罪魁祸首，然后改进相应的部分。

原文转自：http://www.ltesting.net