对嵌入式系统软件执行 测试是一项很有挑战性的工作。因为嵌入式系统的软件开发平台和最终运行平台是完全不一样的两个平台，开发者不可能在其运行平台上像在桌面环境那样执行测试程序。这些差异可以表现在这多个方面。在软件开发的时候目标硬件平台可能还没有准备好，软件工程师在访问硬件时可能会很麻烦，在开发环境下模拟整个系统存在困难性等。

　　本文阐述了单元测试在嵌入式系统软件开发流程中的作用以及其如何 帮助开发者处理上述疑问。简要地讲，它提升了桩函数在宿主环境下或者仿真器中的作用。这使软件工程师在代码编写完毕之后就可以立即对其执行 验证，即使此时目标硬件系统还没有准备好或暂时不能执行 测试。这样，绝大部分的潜藏在程序中的逻辑疑问都能够在早期被发觉，软件工程师就可以迅捷地修正这些疑问，而目标平台上的测试就可以注重于检测软硬件接口方面的疑问。

　　为何要对嵌入式系统软件执行单元测试？

　　单元测试是检查嵌入式系统软件缺陷的最有效的一种要领，更确切而言也即在宿主机环境下或在仿真器上执行 的API测试。这能使测试尽早开始并且最大程度地降低了测试工作对目标硬件平台的依赖性。嵌入式系统软件的单元测试的一个前提是能够让软件独立于硬件执行 测试，这是由桩函数对目标硬件平台的模拟而实现的。在这种情况下，代码的绝大多数功能性测试都能够独立于目标硬件系统执行 测试。这对嵌入式系统开发者而言有以下主要优点。

　　1. 单元测试能让开发者在目标硬件平台准备好之前就开始测试周期，开发者可以直接在宿主开发环境下开始原始测试（而不须要目标硬件平台）。早期测试能够为开发团队发觉并修正缺陷提供尽可能充足的时间。此外，早期测试还能将测试工作较平均地分配于产品开发的各个阶段中，从而防止将所有的测试工作留到产品揭晓之前才执行 ，为开发团队争取了充足的时间。

　　2. 单元测试采取一种“各个击破”的策略，允许用户将复杂的系统分为相对较基本的准独立系统执行 测试。测试工具能够管理模块之间的关联性并运用桩函数来模拟这些模块的行为。

　　图1：运用桩函数，开发者可以模拟真实环境和程序之间的相互影响对程序的某个模块执行 测试，而不须要目标硬件平台以及暂时还未完成的其它代码模块。在测试环境中，桩函数充当了为待测模块提供外部关联性桥梁的作用。

　　在代码修改流程中保卫代码完整性

　　复杂系统的开发者最大的烦恼就是不能确定对代码的修改能不能改动或破坏了程序的既有功能性。为了打消这些顾虑，用户可以建立一个基准单元测试套件来捕捉代码的既有功能性。如果用户希望检查相对于基准单元测试套件的改动，只须要对修改过的代码定期地运行该测试套件即可。因为单元测试能够独立地测试系统的某些代码，所以这样一组回归测试套件可以持续地执行而无论目标硬件平台准备好与否。这种测试并不排斥对整个程序执行 测试的分离回归测试套件。

　　这样的测试套件作为变更检测完全能够让用户确保如果无意间破坏了既有功能性能够被立即告知。当目标硬件平台准备好后，用户可以直接用宿主环境下的测试来验证代码能不能会在实际的目标硬件平台上正确地运行。虽然代码在宿主环境下执行 了回归测试，但是在目标硬件平台上还是须要执行 一定的自动系统测试。

　　验证不正确处理

　　由于消费类产品的不正确处理可靠性需求的不同，所以系统测试情景变得更加复杂了。因为不能精确地预测其运用情况，所以系统的设计和测试都不能基于某个特定的情况。

　　相反这些系统必须经过广泛地不正确以及未预期输入的验证，以保证这些输入能够被正确地处理。

　　运用含有桩函数的单元测试同样能够大大地简化不正确测试流程。总的而言，在运用 程序这一层级来测试不正确条件是一件相当耗时的事，因为将程序置于“正确的不正确状态”须要准备相对复杂的输入数据并且同时要求程序在其大量的可能状态中处于相应的状态。与之形成鲜明比较的是，运用 “不正确模拟”要领来对某些函数执行 不正确处理测试则要基本得多。

　　例如，测试一个含有输入数据不正确处理机制的测试是相当基本的：