嵌入式测试

一、嵌入式软件测试的方法

嵌入式软件测试分为 4 个阶段，即模块测试、集成测试、系统测试、硬件 / 软件集成测试。前 3 个阶段适用于任何软件的测

试，硬件 / 软件集成测试阶段是嵌入式软件所特有的，目的是验证嵌入式软件与其所控制的硬件设备能否正确地交互。

在嵌入式软件测试中，常采取折中的方式。基于目标的测试消耗较多的经费和时间，而基于宿主的测试代价较小，但毕竟

是在模拟环境中进行的。目前的趋势是把更多的测试转移到宿主环境中进行，但是，目标环境的复杂性和独特性不可能完全模

拟。

在两个环境中可以出现不同的软件缺陷，重要的是目标环境和宿主环境的测试内容有所选择。在宿主环境中，可以进行逻

辑或界面的测试以及与硬件无关的测试。在模拟或宿主环境中的测试所消耗的时间通常相对较少，用调试工具可以更快地完成

调试和测试任务。而与定时问题有关的白盒测试、中断测试、硬件接口测试只能在目标环境中进行。在软件测试周期中，基于

目标的测试是在较晚的硬件 / 软件集成测试阶段开始的，如果不更早地在模拟环境中进行白盒测试，而是等到硬件 / 软件集成测

试阶段再进行全部的白盒测试，将耗费更多的财力和人力。

二、嵌入式软件测试的过程

根据嵌入式系统的开发流程，为了最经济地实现系统的功能，一般采用自顶向下、层层推进的方法对嵌入式系统进行测

试。图 9.1 为基于模块化设计的嵌入式软件测试流程。

嵌入式软件测试的总体步骤为：首先进行操作系统移植并编写系统底层驱动，然后进行系统平台测试，其中包括硬件电路

测试、操作系统及底层驱动程序的测试等。如果测试未通过，需要重新进行操作系统移植和编写系统底层驱动；如果此测试通

过，可以进入下一步的开发 —— 用模块化的方法编写应用代码，随后再对软件模块进行测试。如果测试没有通过，则要对此代

码模块进行修改，然后对软件模块进行测试；如果所有的模块都通过测试，需要进行集成测试。如果集成测试没有通过，则要

确定模块接口函数错误模块，然后修改错误模块代码，再利用关联矩阵确定需测试模块，并重新回到软件模块测试；如果集成

测试通过，则需要进行系统测试。如果系统测试没有通过，则需要修改程序代码，如果问题出现在操作系统的移植上，需要重

新进行操作系统的移植；如果问题只是出现在软件模块上，只需修改软件模块就行了。如果系统测试通过，就可以退出测试。

在第一件产品生产出来之后，需要对产品进行测试，如果测试通过，则表示嵌入式产品的所有测试步骤已经完成。

图 9.1 嵌入式软件测试的详细流程

三、嵌入式软件测试的特点

1 嵌入式软件测试作为一种特殊的软件测试，它的目的和原则同普通的软件测试是一样的，都是为了验证或达到可靠性要求

而对软件所进行的测试。嵌入式软件测试除了要遵循普通软件测试的原则之外，还需要遵循以下几个原则：

(1) 嵌入式软件测试对软件在硬件平台的测试是必不可少的。

(2) 嵌入式软件测试需要在特定的环境下对软件进行测试。

(3) 嵌入式软件需进行必要的可靠性负载测试，比如测试某些嵌入式系统能否连续 1000 个小时不断电工作。

(4) 除了要对嵌入式软件系统的功能进行测试之外，还需要对实时性进行测试。在判断系统是否失效方面，除了看它的输

出结果是否正确，还应考虑其是否在规定的时间里输出了结果。

(5) 在对嵌入式软件进行测试的时候，需要在特定的硬件平台上进行性能测试、内存测试、 GUI 测试、覆盖分析测试。

四、嵌入式软件测试的工具

1 ．内存分析工具

在嵌入式系统中，内存容量通常是有限的。内存分析工具用来处理在动态内存分配中存在的缺陷。动态内存分配错误，通

常是难以复原的，其导致的失效难以追踪，使用内存分析工具可以避免这类缺陷进入功能测试阶段。目前有两类内存分析工具

— 软件工具和硬件工具。基于软件的内存分析工具可能会对代码的性能造成很大影响，从而严重影响实时操作；基于硬件的内

存分析工具价格昂贵，而且只能在工具所限定的运行环境中使用。

2 ．性能分析工具

在嵌入式系统中，程序的性能通常是非常重要的。经常会有这样的要求，在特定时间内处理一个中断，或生成具有特定定

时要求的一帧。开发人员面临的问题是决定应该对哪一部分代码进行优化来改进性能，并避免花费大量的时间去优化那些对性

能没有任何影响的代码。性能分析工具会提供有关的数据，说明执行时间是如何消耗，什么时候消耗的，以及每个例程所用的

时间。根据这些数据，确定哪些例程消耗部分执行时间，从而可以决定如何优化软件，以获得更好的时间性能。对于大多数应

用来说，大部分执行时间用在相对少量的代码上，费时的代码估计只占所有软件总量的 5% ～ 20% 。性能分析工具不仅能指出

哪些例程花费了时间，而且与调试工具联合使用可以引导开发人员查看需要优化的特定函数，性能分析工具还可以引导开发人

员发现在系统调用中存在的错误以及程序结构上的缺陷。

3 ． GUI 测试工具

很多嵌入式应用提供了某种形式的图形用户界面，有些系统性能测试是根据用户输入响应时间进行的。 GUI 测试工具可以

作为脚本工具在开发环境中运行测试用例，其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测

试过程。对没有 GUI 的嵌入式设备，可以对其进行插装来运行 GUI 测试脚本，虽然这种方式可能要求对被测代码进行更改，但

是节省了功能测试和回归测试的时间。

4 ．覆盖分析工具

在进行白盒测试时，可以使用代码覆盖分析工具追踪被执行过的代码。分析过程可以通过插装的方式来完成，插装可以是

在测试环境中嵌入硬件，也可以是在可执行代码中加入软件，也可以是二者相结合。测试人员对结果数据加以总结，确定哪些

代码被执行过，哪些代码被遗漏了。覆盖分析工具一般会提供有关功能覆盖、分支覆盖、条件覆盖的信息。对于嵌入式软件来

说，代码覆盖分析工具可能侵入代码的执行，影响实时代码的运行过程。基于硬件的代码覆盖分析工具的侵入程度要小一些，

但是价格一般比较昂贵，而且限制被测代码的数量。

五、嵌入式软件测试策略

1 ．单元测试

所有单元测试都可以在主机环境上进行，除非少数情况特别指定了单元测试直接在目标环境进行。测试时，尽可能在主机

环境中进行软件测试，通过尽可能小的目标单元访问所有目标指定的界面。

在主机平台上运行的测试速度比在目标平台上快得多，在主机平台完成测试后，可以在目标环境中重复作一简单的确认测

2 试，确认测试结果不受主机和目标机的环境影响。在目标环境中进行确认测试将确定一些未知的、未预料到的、未说明的主机

与目标机的不同。例如，目标编译器可能有 bug ，但在主机编译器上没有。

2 ．集成测试

软件集成也可在主机环境上完成，并在主机平台上模拟目标环境运行。当然在目标环境上重复测试也是必需的，在此级别

上的确认测试将确定一些环境上的问题，比如内存定位和分配上的一些错误。

在主机环境中如何进行集成测试，取决于目标系统的具体功能有多少。有些嵌入式系统与目标环境耦合得非常紧密，若在

主机环境做集成是不切实际的。对于大型软件的开发则可以分为几个级别的集成。低级别的软件集成在主机平台上完成有很大

优势，越往后的集成越依赖于目标环境。

3 ．系统测试和确认测试

所有的系统测试和确认测试都必须在目标环境下执行。当然在主机上开发和执行系统测试，然后移植到目标环境重复执行

是很方便的。对目标系统的依赖性会妨碍将主机环境中的系统测试移植到目标系统上，况且只有少数开发者会卷入系统测试，

所以有时放弃在主机环境上执行系统测试可能更方便。

确认测试最终的实施舞台必须在目标环境中，系统的确认必须在真实系统之下测试，而不能在主机环境下模拟。这关系到

嵌入式软件的最终使用。

使用有效的 cross-test 测试策略可极大地提高嵌入式软件开发测试的水平和效率，当然正确地使用测试工具也是必不可少

的。

六、 嵌入式软件测试实例

1) 软件指令仿真

软件指令仿真的主要工作是对相关的 I/O 操作进行替换。在 80X86 系列 CPU 指令集中， I/O 指令有两个 IN 和 OUT ，对这两个

指令，我们都定义相应的宏来代替其操作，同时在内存中组织变量来代替 I/O 操作中的寄存器变量。

在软件中， I/O 指令主要有以下几类：

IN REGISTER, BYTE

IN REGISTER, WORD

OUTBYTE, REGISTER

OUTREGISTER, WORD

构造如下的宏指令仿真上述指令的功能：

3 2) 软件插桩

为了便于测试完成后分析软件的执行路径，必须在软件中加入特定的输出语句。这样，我们才能在分析软件的输出数据时

进行对比，得到软件的实际运行情况。可在遥控摄像头的控制及通信软件中加入下列语句：

MOVDADIAN, PATH[NO]

将软件中的上述插入点写入软件的输出结果中，测试结束后分析语句时，就可以根据路径编号来分析软件的执行路径。

3) 软件移植

由于遥控摄像头的控制及通信软件在实际环境中的执行方式是直接操作底层硬件，而 DOS 系统中的软件是和操作系统交互

的，因此，为了完成测试，必须对软件进行移植，使软件能够在 DOS 系统中运行。

在基于 8086 组建的嵌入式系统中，一般将软件安排在特定的存储地址中，系统启动时， CPU 指令首先指向 FF000H ，在

FF000H 单元中安排特定的跳转语句，使软件跳转到存储器中存放软件的地址，然后系统进入正常运行。然而，在 DOS 操作系

统中不能直接操作 CPU 指令指针，使 CPU 指令指针切换到存放特定软件的地址。 DOS 系统下的可执行程序必须符合 DOS 系统的

规范。我们可以在程序中插入驱动模块，然后对程序进行重新编译，使它符合 DOS 系统的规范，就可以解决上述问题。