目前在嵌入式领域目标系统的应用系统日趋复杂，而由于竞争要求产品快速上市，开发技术日新月异，同时硬件发展的日益稳定，而软件故障却日益突出，软件的重要性逐渐引起人们的重视，越来越多的人认识到嵌入式系统的测试势在必行。

由于嵌入式系统的自身特点，如实时性(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测试策略可极大的提高嵌入式软件开发测试的水平和效率，当然正确的测试工具使用也是必不可少的：

下面给出各个阶段的嵌入式软件测试的方案：

一、静态测试:

静态测试不利用计算机运行被测程序，度量程序静态复杂度，检查软件是否符合编程 标准。

静态测试工具McCabe QA，QAC/C++

1) 静态测试工具-McCabe QA

McCabe QA是美国McCabe&Association公司的产品。它利用著名学者McCabe的软件结构化测试理论，使用V(G)圈复杂度=模块内部独立线性路径数度量软件的复杂度。

McCabe最大的特点就是可视化，以独特的图形技术表示代码。软件通过分析源码，特到整个软件系统的结构图，同时得到了各种基于工业标准评估代码复杂性，包括V(g)，EV(g)，DV(g)，Halstead等数十种静态复杂度度量。用不同的颜色表示软件模块的复杂性，测试人员的测试重点放在质量差的模块上;提供各种质量模型深入评价软件质量，纪录软件质量波动曲线和版本变化趋势分析，从而控制软件修改不同阶段的质量。在单元级McCabe显示模块的流程图，并且相对应的标出了代码的位置，视图与代码相互对应，可很快找出问题所在。分析最终可得到各种可定制的符合工业标准的综合报告。

2) 代码规则检查工具-QAC/C++

QAC/QAC++是用于代码规则检查的自动化工具。

代码审查主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面;可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。

MISRA Compliance 模块为QAC可选组件，执行MISRA 2004准则检查，在MISRA Compliance 模块的帮助下，分析源代码查找不符合MISRA的结构。QA C的警告信息直接通过HTML连接到被分析的源代码，同时也与MISRA相关规则参考信息连接。这些参考信息包括MISRA兼容代码中解释性的例子和标准描述。

二、动态测试

动态测试时软件必须被执行。动态测试方法分为黑盒法和白盒法。为了较快得到测试效果，通常先进行功能测试，达到所有功能后，为确定软件的可靠性进行必要的覆盖测试。

在软件开发的不同时期进行动态测试，测试又分为单元测试，集成测试，确认测试，系统测试。

1) 单元测试

单元测试方案之一Cantata++

Cantata++是能够满足开发者进行高效的单元和集成测试要求的专业测试工具，该产品能帮助提高测试效率，具有一整套包含测试、覆盖率分析和静态分析的功能。

Cantata++含有以下几个主要部分：

CTH-The Cantata++ Test Harness，测试功能库，Cantata通过CTH提供的测试函数执行测试，提供测试所需用例的输入输出，并检查输出结果是否符合要求，给出PASS / FAIL的确切结果。打桩、封装和动态分析的执行也是利用CTH。

Cantata++主程序包括测试脚本自动生成器和管理器。测试脚本生成工具通过分析源代码得到参数和数据信息，连同自动产生的Stub桩函数和Wrap封装函数，自动生成到测试脚本中。测试脚本完全使用C或C++语言构成，可重用。通过使用测试脚本管理器可以自动完成测试用例定义到测试脚本的转换。对于熟练的用户，可以直接利用CTH提供的库函数，直接编写C或C++语言的测试脚本。

{{分页}}

完全支持白盒测试和黑盒测试技术，通过脚本检查所有标准的和用户定义的类型，对期望和不期望的异常进行检查;对继承类和模板实例的测试用例重用;为所有预期结果和实际结果的检查进行详细的测试分析。支持覆盖率分析，提供从语句覆盖级到MC/DC (DO-178B A)的度量。

2)集成测试IntegratedTesting

集成测试是软件的单元测试完成后进行的。

集成测试工具：

Cantata++同样支持集成测试方法，进行调用序列，传递参数的检查。并且提供独一无二的封装功能，完成硬件错误注入的测试。提供Wrapping技术，相对于桩函数stub，封装Wrapping有以下优势：

1) 在被测模块中模拟errors，避免真实代码的执行。模拟硬件问题，进行逆向测试。

2) 可以校验集成调用的执行过程Call 序列：

a) 允许测试者控制被测软件的外部环境。

b) 检查调用其成员函数执行的是否正确(包括参数、执行的顺序)

3) 允许真实调用类的某些成员函数，而封装wrap另一些函数调用，控制其的输入和返回参数。

另一款集成阶段测试工具是McCabe Test。正如前一部分提到的，它可很直观从整体上把握软件的结构，生成集成测试Plan，通过插装被测试软件，得到被插装后的源代码。运行目标编译器，最后并测量覆盖率。McCabe自动跟踪软件执行，得到测试信息，产生覆盖率报告。

通过被测试软件的结构图，直观的评估“测了多少”，深入得到代码级，以图形的方式标那些代码测试过，而那些还没测。支持MC / DC覆盖分析，满足DO178B-A标准。

McCabe QA 与McCabe TEST等组件组成McCabe IQ工具包，构成了一整套完整的白盒测试方案。

13)确认测试&系统测试

包括恢复测试、安全测试、强度测试、性能测试，已超出了本文讨论的范畴，本文暂不详述。

总结一下，应用以上测试工具进行.Cross-test时的策略：

A) 使用测试工具的插装功能(主机环境)执行静态测试分析，并且为动态覆盖测试准备好一插装好的软件代码。

B) 使用源码在主机环境执行功能测试，修正软件的错误和测试脚本中的错误。

C) 使用插装后的软件代码执行覆盖率测试，添加测试用例或修正软件的错误，保证达到所要求的覆盖率目标。

D) 在目标环境下重复(B)，确认软件在目标环境中执行测试的正确性。

E) 若测试需要达到极端的完整性，最好在目标系统上重复(C)，确定软件的覆盖率没有改变。

通常在主机环境执行多数的测试，只是在最终确定测试结果和最后的系统测试才移植到目标环境，这样可以避免发生访问目标系统资源上的瓶颈，也可以减少在昂贵资源如在线仿真器上的费用。另外，若目标系统的硬件由于某种原因而不能使用时，最后的确认测试可以推迟直到目标硬件可用，这为嵌入式软件的开发测试提供了弹性。设计软件的可移植性是成功进行cross-test的先决条件，它通常可以提高软件的质量，并且对软件的维护大有益处。以上所提到的测试工具，都可以通过各自的方式提供测试在主机与目标之间的移植，从而使嵌入式软件的测试得以方便的执行。

{{分页}}

使用有效的cross-test测试策略可极大的提高嵌入式软件开发测试的水平和效率，提高嵌入式软件的质量。