模板嵌入式测试Word文档下载推荐.docx
《模板嵌入式测试Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《模板嵌入式测试Word文档下载推荐.docx（33页珍藏版）》请在冰豆网上搜索。
对于嵌入式软件，白盒测试一般不必在目标硬件上进行，更为实际的方式是在开发环境中通过硬件仿真进行，所以选取的测试工具应该支持在宿主环境中的测试。
黑盒测试在某些情况下也称为功能测试。
这类测试方法根据软件的用途和外部特征查找软件缺陷，不需要了解程序的内部结构。
黑盒测试最大的优势在于不依赖代码，而是从实际使用的角度进行测试，通过黑盒测试可以发现白盒测试发现不了的问题。
因为黑盒测试与需求紧密相关，需求规格说明的质量会直接影响测试的结果，黑盒测试只能限制在需求的范围内进行。
在进行嵌入式软件黑盒测试时，要把系统的预期用途作为重要依据，根据需求中对负载、定时、性能的要求，判断软件是否满足这些需求规范。
为了保证正确地测试，还须要检验软硬件之间的接口。
嵌入式软件黑盒测试的一个重要方面是极限测试。
在使用环境中，通常要求嵌入式软件的失效过程要平稳，所以，黑盒测试不仪要检查软件工作过程，也要检查软件换效过程。
2、目标环境测试和宿主环境测试
在嵌入式软件测试中，常常要在基于目标的测试和基于宿主的测试之间作出折衷。
基于目标的测试消耗较多的经费和时间，而基于宿主的测试代价较小，但毕竟是在模拟环境中进行的。
目前的趋势是把更多的测试转移到宿主环境中进行，但是，目标环境的复杂性和独特性不可能完全模拟。
在两个环境中可以出现不同的软件缺陷，重要的是目标环境和宿主环境的测试内容有所选择。
在宿主环境中，可以进行逻辑或界面的测试、以及与硬件无关的测试。
在模拟或宿主环境中的测试消耗时间通常相对较少，用调试工具可以更快地完成调试和测试任务。
而与定时问题有关的白盒测试、中断测试、硬件接口测试只能在目标环境中进行。
在软件测试周期中，基于目标的测试是在较晚的“硬件/软件集成测试”阶段开始的，如果不更早地在模拟环境中进行白盒测试，而是等到“硬件/软件集成测试”阶段进行全部的白盒测试，将耗费更多的财力和人力。
二、嵌入式软件的测试工具
用于辅助嵌入式软件测试的工具很多，下面对几类比较有用的有关嵌入式软件的测试工具加以介绍和分析。
1、内存分析工具
在嵌入式系统中，内存约束通常是有限的。
内存分析工具用来处理在动态内存分配中存在的缺陷。
当动态内存被错误地分配后，通常难以再现，可能导致的失效难以追踪，使用内存分析工具可以避免这类缺陷进入功能测试阶段。
目前有两类内存分析工具——软件和硬件的。
基于软件的内存分析工具可能会对代码的性能造成很大影响，从而严重影响实时操作；
基于硬件的内存分析工具价格昂贵，而且只能在工具所限定的运行环境中使用。
2、性能分析工具
在嵌入式系统中，程序的性能通常是非常重要的。
经常会有这样的要求，在特定时间内处理一个中断，或生成具有特定定时要求的一帧。
开发人面临的问题是决定应该对哪一部分代码进行优化来改进性能，常常会花大量的时间去优化那些对性能没有任何影响的代码。
性能分析工具会提供有关的数据，说明执行时间是如何消耗的，是什么时候消耗的，以及每个例程所用的时间。
根据这些数据，确定哪些例程消耗部分执行时间，从而可以决定如何优化软件，获得更好的时间性能。
对于大多数应用来说，大部分执行时间用在相对少量的代码上，费时的代码估计占所有软件总量的5%-20%。
性能分析工具不仅能指出哪些例程花费时间，而且与调试工具联合使用可以引导开发人员查看需要优化的特定函数，性能分析工具还可以引导开发人员发现在系统调用中存在的错误以及程序结构上的缺陷。
3、GUI测试工具
很多嵌入式应用带有某种形式的图形用户界面进行交互，有些系统性能测试足根掘用户输入响应时间进行的。
GUI测试工具可以作为脚本工具有开发环境中运行测试用例，其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程。
很多嵌入式设备没有GUI，但常常可以对嵌入式设备进行插装来运行GUI测试脚本，虽然这种方式可能要求对被测代码进行更改，但是节省了功能测试和回归测试的时间。
4、覆盖分析工具
在进行白盒测试时，可以使用代码覆盖分析工具追踪哪些代码被执行过。
分析过程可以通过插装来完成，插装可以是在测试环境中嵌入硬件，也可以是在可执行代码中加入软件，也可以是二者相结合。
测试人员对结果数据加以总结，确定哪些代码被执行过，哪些代码被巡漏了。
覆盖分析工具一般会提供有关功能覆盖、分支覆盖、条件覆盖的信息。
对于嵌入式软件来说，代码覆盖分析工具可能侵入代码的执行，影响实时代码的运行过程。
基于硬件的代码覆盖分析工具的侵入程度要小一些，但是价格一般比较昂贵，而且限制被测代码的数量。
三、嵌入式软件测试策略
在嵌入式领域目标系统的应用系统日趋复杂，而由于竞争要求产品快速上市，开发技术日新月异，同时硬件发展的日益稳定，而软件故障却日益突出，软件的重要性逐渐引起人们的重视，越来越多的人认识到嵌入式系统的测试势在必行。
提到嵌入式软件测试，首先要简单介绍一些软件工程的一些观点，现在，被普遍接受的软件的定义是：
软件（software）是计算机系统中与硬件（hardware）相互依存的另一部分，它包括程序（program）、相关数据（data）及其说明文档（document）。
其中程序是按照事先设计的功能和性能要求执行的指令序列；
数据是是程序能正常操纵信息的数据结构；
文档是与程序开发维护和使用有关的各种图文资料。
对于一般商用软件的测试，嵌入式软件测试有其自身的特点和测试困难。
由于嵌入式系统的自身特点，如实时性（Real-timing），内存不丰富，I/O通道少，开发工具昂贵，并且与硬件紧密相关CPU种类繁多，等等。
嵌入式软件的开发和测试也就与一般商用软件的开发和测试策略有了很大的不同，可以说嵌入式软件是最难测试的一种软件。
嵌入式软件测试使用有效的测试策略是唯一的出路，它可以使开发的效率最大化，避免目标系统的瓶颈，使用在线仿真器节省昂贵的目标资源。
自从出现高级语言，开发环境与最终运行环境通常都是存在差异的，嵌入式系统更是如此。
开发环境被认为是主机平台，软件运行环境为目标平台。
相应的测试为host-target测试或cross-testing。
讨论嵌入式软件测试首先就会遇到一个问题：
为什么不把所有测试都放在目标上进行呢？
因为若所有测试都放在目标平台上有很多不利的因素：
1）测试软件，可能会造成与开发者争夺时间的瓶颈，避免它只有提供更多的目标环境。
2）目标环境可能还不可行。
3）比起主机平台环境，目标环境通常是不精密的和不方便的。
4）提供给开发者的目标环境和联合开发环境通常是很昂贵的。
5）开发和测试工作可能会妨碍目标环境已存在持续的应用
从经济上和开发效率上考虑，软件开发周期中尽可能大的比例在主机系统环境中进行，其中包括测试。
确定host-target测试环境后，开发测试人员又会遇到以下的问题：
1）多少开发人员会卷入测试工作（单元测试，软件集成，系统测试）?
2）多少软件应该测试，测试会花费多长时间？
3）在主机环境和目标环境有哪些软件工具，价格怎样，适合怎样?
4）多少目标环境可以提供给开发者，什么时候?
5）主机和目标机之间的连接怎样？
6）被测软件下载到目标机有多快?
7）使用主机与目标环境之间有什么限制（如软件安全标准）?
任何人或组织进行嵌入式软件的测试都应深入考虑以上问题，结合自身实际情况，选定合理测试策略和方案。
对于嵌入式软件测试或叫交叉测试（cross-test），在测试的各个阶段有着通用的策略：
1．单元测试
所有单元级测试都可以在主机环境上进行，除非少数情况，特别具体指定了单元测试直接在目标环境进行。
最大化在主机环境进行软件测试的比例，通过尽可能小的目标单元访问所有目标指定的界面。
在主机平台上运行测试速度比在目标平台上快的多，当在主机平台完成测试，可以在目标环境上重复作一简单的确认测试，确认测试结果在主机和目标机上没有被他们的不同影响。
在目标环境上进行确认测试将确定一些未知的，未预料到的，未说明的主机与目标机的不同。
例如，目标编译器可能有bug，但在主机编译器上没有。
2．集成测试
软件集成也可在主机环境上完成，在主机平台上模拟目标环境运行，当然在目标环境上重复测试也是必须的，在此级别上的确认测试将确定一些环境上的问题，比如内存定位和分配上的一些错误。
在主机环境上的集成测试的使用，依赖于目标系统的具体功能有多少。
有些嵌入式系统与目标环境耦合的非常紧密，若在主机环境做集成是不切实际的。
一个大型软件的开发可以分几个级别的集成。
低级别的软件集成在主机平台上完成有很大优势，越往后的集成越依赖于目标环境。
3．系统测试和确认测试
所有的系统测试和确认测试必须在目标环境下执行。
当然在主机上开发和执行系统测试，然后移植到目标环境重复执行是很方便的。
对目标系统的依赖性会妨碍将主机环境上的系统测试移植到目标系统上，况且只有少数开发者会卷入系统测试，所以有时放弃在主机环境上执行系统测试可能更方便。
确认测试最终的实施舞台必须在目标环境中，系统的确认必须在真实系统之下测试，而不能在主机环境下模拟。
这关系到嵌入式软件的最终使用。
包括恢复测试、安全测试、强度测试、性能测试，已超出了软件测试的范畴，本文暂不讨论。
使用有效的cross-test测试策略可极大的提高嵌入式软件开发测试的水平和效率，当然正确的测试工具使用也是必不可少的，总结一下，应用以上测试工具进行.Cross-test时的策略：
A）使用测试工具的插装功能（主机环境）执行静态测试分析，并且为动态覆盖测试准备好一插装好的软件代码。
B）使用源码在主机环境执行功能测试，修正软件的错误和测试脚本中的错误。
C）使用插装后的软件代码执行覆盖率测试，添加测试用例或修正软件的错误，保证达到所要求的覆盖率目标。
D）在目标环境下重复（B），确认软件在目标环境中执行测试的正确性。
E）若测试需要达到极端的完整性，最好在目标系统上重复（C），确定软件的覆盖率没有改变。
通常在主机环境执行多数的测试，只是在最终确定测试结果和最后的系统测试才移植到目标环境，这样可以避免发生访问目标系统资源上的瓶颈，也可以减少在昂贵资源如在线仿真器上的费用。
另外，若目标系统的硬件由于某种原因而不能使用时，最后的确认测试可以推迟直到目标硬件可用，这为嵌入式软件的开发测试提供了弹性。
设计软件的可移植性是成功进行cross-test的先决条件，它通常可以提高软件的质量，并且度软件的维护大有益处。
以上所提到的测试工具，都可以通过各自的方式提供测试在主机与目标之间的移植，从而使嵌入式软件的测试得以方便的执行。
使用有效的cross-test测试策略可极大的提高嵌入式软件开发测试的水平和效率，提高嵌入式软件的质量。
四、结论
嵌入式系统在人类生活中发挥着重要的作用，包括飞行控制器这样的控制系统，以及洗衣机这样的家用电器。
日前，嵌入式系统中软件的比重越来越大，也越来越复杂，保证嵌入式软件的可靠性正面临严峻的挑战。
大多数软件测试方法都可以直接或间接地用于嵌入式软件的测试，但是由于操作系统的实时和嵌入式特性，嵌入式软件测试也面临一些特殊的问题。
虽然日前已经有一些针对嵌入式软件的测试和调试工具，但是在有些方面仍存在不足，包括许多任务操作系统的并发、非侵入式的测试和凋试、嵌入式系统的软件抽象等。
对于嵌入式软件测试技术的研究人选测试工具有待开发，仍须要做很多进一步的工作。
在嵌入式软件开发过程中，一般来说，花在测试和花在编码的时间比为3:
1（实际上可能更多）。
这个比例随着你的编程和测试水平的提高而不断下降，但不论怎样，软件测试对一般人来讲很重要。
很多年前，一位开发人员为了对嵌入式有更深层次的理解，向Oracle询问了这样的一个问题:
我怎么才能知道并懂得我的系统到底在干些什么呢?
Oracle面对这个问题有些吃惊，因为在当时没有人这么问过，而同时代的嵌入式开发人员问的最多的大都围绕“我怎么才能使程序跑的更快”、“什么编译器最好”等肤浅的问题。
所以，面对这个不同寻常却异乎成熟的问题，Oracle感到欣喜并认真回复了他:
你的问题很有深度很成熟，因为只有不断地去深入理解才有可能不断地提高水平。
并且Oracle为了鼓励这位执着的程序员，把10条关于嵌入式软件开发测试的秘诀告诉了他:
1.懂得使用工具
2.尽早发现内存问题
3.深入理解代码优化
4.不要让自己大海捞针
5.重现并隔离问题
6.以退为进
7.确定测试的完整性
8.提高代码质量意味着节省时间
9.发现它，分析它，解决它
10.利用初学者的思维
这十条秘诀在业界广为流传，使很多人受益。
本文围绕这十条秘诀展开论述。
一、懂得使用工具
通常嵌入式系统对可靠性的要求比较高。
就象修车需要工具一样，好的程序员应该能够熟练运用各种软件工具。
不同的工具，有不同的使用范围，有不同的功能。
使用这些工具，你可以看到你的系统在干些什么，它又占用什么资源，它到底和哪些外界的东西打交道。
让你郁闷好几天的问题可能通过某个工具就能轻松搞定，可惜你就是不知道。
那么为什么那么多的人总是在折腾个半死之后才想到要用测试工具呢?
原因很多，主要有两个。
一个是害怕，另一个是惰性。
害怕是因为加入测试用具或测试模块到代码需要技巧同时有可能引入新的错误，所以他们总喜欢寄希望于通过不断地修改重编译代码来消除bug,结果却无济于事。
懒惰是因为他们习惯了使用printf之类的简单测试手段。
下面来介绍一些嵌入式常用的测试工具。
1.源码级调试器[Source-levelDebugger]
这种调试器一般提供单步或多步调试、断点设置、内存检测、变量查看等功能，是嵌入式调试最根本有效的调试方法。
比如VxWorksTornadoII提供的gdb就属于这一种。
2.简单实用的打印显示工具[printf]
printf或其它类似的打印显示工具估计是最灵活最简单的调试工具。
打印代码执行过程中的各种变量可以让你知道代码执行的情况。
但是，printf对正常的代码执行干扰比较大（一般printf占用CPU比较长的时间），需要慎重使用，最好设置打印开关来控制打印。
3.ICE或JTAG调试器[In-circuitEmulator]
ICE是用来仿真CPU核心的设备，它可以在不干扰运算器的正常运行情况下，实时的检测CPU的内部工作情况。
像桌面调试软件所提供的:
复杂的条件断点、先进的实时跟踪、性能分析和端口分析这些功能，它也都能提供。
ICE一般都有一个比较特殊的CPU，称为外合（bond-out）CPU。
这是一种被打开了封装的CPU，并且通过特殊的连接，可以访问到CPU的内部信号，而这些信号，在CPU被封装时，是没法“看到”的。
当和工作站上强大的调试软件联合使用时，ICE就能提供你所能找到的最全面的调试功能。
但ICE同样有一些缺点:
昂贵;
不能全速工作;
同样，并不是所有的CPU都可以作为外合CPU的，从另一个角度说，这些外合CPU也不大可能及时的被新出的CPU所更换。
JTAG（JointTestActionGroup）虽然它最初开发出来是为了监测IC和电路连接，但是这种串行接口扩展了用途，包括对调试的支持。
AD公司为Blackfin设计的VisualDsp++就支持高速的JTAG调试。
4.ROM监视器[ROMMonitor]
ROM监控器是一小程序，驻留在嵌入系统ROM中，通过串行的或网络的连接和运行在工作站上的调试软件通信。
这是一种便宜的方式，当然也是最低端的技术。
它除了要求一个通信端口和少量的内存空间外，不需要其它任何专门的硬件。
并提供了如下功能:
下载代码、运行控制、断点、单步步进、以及观察、修改寄存器和内存。
因为ROM监控器是操作软件的一部分，只有当你的应用程序运行时，它才会工作。
如果你想检查CPU和应用程序的状态，你就必须停下应用程序，再次进入ROM监控器。
5.Data监视器[DataMonitor]
这种监视器在不停止CPU运行的情况下不仅可以显示指定变量内容，还可以收集并以图形形式显示各个变量的变化过程。
6.OS监视器[OperatingSystemMonitor]
操作系统监视器可以显示诸如任务切换、信号量收发、中断等事件。
一方面，这些监视器能够为你呈现事件之间的关系和时间联系;
另一方面，还可以提供对信号量优先级反转、死锁和中断延时等问题的诊断。
7.性能分析工具[Profiler]
可以用来测试CPU到底耗在那里。
profiler工具可以让你知道系统的瓶颈在那里、CPU的使用率以及需要优化的地方。
8.内存测试工具[MemoryTeseter]
可以找到内存使用的问题所在，比如内存泄露、内存碎片、内存崩溃等问题。
如果发现系统出现一些不可预知的或间歇性的问题，就应该使用内存测试工具测测看。
9.运行跟踪器[ExecutionTracer]
可以显示CPU执行了哪些函数、谁在调用、参数是什么、何时调用等情况。
这种工具主要用于测试代码逻辑，可以在大量的事件中发现异常的那些。
10.覆盖工具[CoverageTester]
主要显示CPU具体执行了那些代码，并让你知道那些代码分支没有被执行到。
这样有助于提高代码质量并消除无用代码。
11.GUI测试工具[GUITester]
很多嵌入式应用带有某种形式的图形用户界面进行交互，有些系统性能测试足根掘用户输入响应时间进行的。
GUI测试工具可以作为脚本工具有开发环境中运行测试用例，其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程（Rational公司的robot和Mercury的Loadrunner工具是杰出的代表）。
12.自制工具[Home-madetester]
在嵌入式应用中，有时候为了特定的目的，需要自行编写一些工具来达到某种测试目的。
本人曾经编写的视频流录显工具在测试视频会议数据流向和变化上帮了大忙,帮公司找到了几个隐藏很深的bug。
二、尽早发现内存问题
内存问题危害很大，不容易排查，主要有三种类型:
内存泄露、内存碎片和内存崩溃。
对于内存问题态度必须要明确，那就是早发现早“治疗”。
在软件设计中，内存泄露的“名气”最大，主要由于不断分配的内存无法及时地被释放，久而久之，系统的内存耗尽。
即使细心的编程老手有时后也会遭遇内存泄露问题。
有测试过内存泄露的朋友估计都有深刻地体验，那就是内存泄露问题一般隐藏很深，很难通过代码阅读来发现。
有些内存泄露甚至可能出现在库当中。
有可能这本身是库中的bug，也有可能是因为程序员没有正确理解它们的接口说明文档造成错用。
在很多时候，大多数的内存泄露问题无法探测，但可能表现为随机的故障。
程序员们往往会把这种现象怪罪于硬件问题。
如果用户对系统稳定性不是很高，那么重启系统问题也不大;
但，如果用户对系统稳定很高，那么这种故障就有可能使用户对产品失去信心，同时也意味着你的项目是个失败的项目。
由于内存泄露危害巨大，现在已经有许多工具来解决这个问题。
这些工具通过查找没有引用或重复使用的代码块、垃圾内存收集、库跟踪等技术来发现内存泄露的问题。
每个工具都有利有弊，不过总的来说，用要比不用好。
总之，负责的开发人员应该去测试内存泄露的问题，做到防患于未然。
内存碎片比内存泄露隐藏还要深。
随着内存的不断分配并释放，大块内存不断分解为小块内存，从而形成碎片，久而久之，当需要申请大块内存是，有可能就会失败。
如果系统内存够大，那么坚持的时间会长一些，但最终还是逃不出分配失败的厄运。
在使用动态分配的系统中，内存碎片经常发生。
目前，解决这个问题最效的方法就是使用工具通过显示系统中内存的使用情况来发现谁是导致内存碎片的罪魁祸首，然后改进相应的部分。
由于动态内存管理的种种问题，在嵌入式应用中，很多公司干脆就禁用malloc/free的以绝后患。
内存崩溃是内存使用最严重的结果，主要原因有数组访问越界、写已经释放的内存、指针计算错误、访问堆栈地址越界等等。
这种内存崩溃造成系统故障是随机的，而且很难查找，目前提供用于排查的工具也很少。
总之，如果要使用内存管理单元的话，必须要小心，并严格遵守它们的使用规则，比如谁分配谁释放。
三、深入理解代码优化
讲到系统稳定性，人们更多地会想到实时性和速度，因为代码效率对嵌入式系统来说太重要了。
知道怎么优化代码是每个嵌入式软件开发人员必须具备的技能。
就象女孩子减肥一样，起码知道她哪个
升级会员 