嵌入式软件测试基本概念
这里讨论的嵌入式软件测试是一个系统测试的概念。即将开发的软件系统（包括嵌入式操作系统和嵌入式应用软件）、硬件系统和其它相关因素（如人员的操作、数据的获取等）综合起来，对整个产品进行的全面测试。嵌入式系统的系统测试比PC系统软件测试要困难得多，主要体现如下：
- 测试软件功能依赖不需编码的硬件功能，快速定位软硬件错误困难；
- 强壮性测试、可知性测试很难编码实现；
- 交叉测试平台的测试用例、测试结果上载困难；
- 基于消息系统测试的复杂性，包括线程、任务、子系统之间的交互，并发、容错和对时间的要求；
- 性能测试、确定性能瓶颈困难；
- 实施测试自动化技术困难。
嵌入式软件测试和传统软件测试异同点
嵌入式软件与别的软件相比，它具有专用性，它只能在需求所指定的硬件平台上执行，并且嵌入式软件的开发环境和运行环境是不一致的，因此即使宿主机环境下测试再充分，也不能说明在目标机环境下运行该软件就不出问题。因而，嵌入式软件还面临着目标环境的测试。这不仅增加了测试的代价，而且还带来了嵌入式软件的测试策略问题，即哪些测试分配在宿主环境进行，哪些测试分配到目标环境下进行（户军茹，2007）。
所以嵌入式软件测试更有它的必要性，而且比一般的软件测试存在更多的困难。
嵌入式软件测试与普通软件测试的相同之处
传统的软件测试是将软件分在不同的层面上进行测试，包括模块测试（或单元测试），集成测试，系统测试等。
嵌入式软件测试和一般的软件测试存在着许多相似的问题和相似的解决方法。这就是我们寻找的嵌入式软件的通用的测试方法。
按阶段可分为单元测试、集成测试、系统测试和确认测试。
单元测试(Unit testing):完成对最小的软件设计单元的验证工作，只有在该基础之上才能保证后续的测试工作。主要采用白盒测试技术，用来保证单元的最大覆盖率和发现编码和详细设计中的错误。单元测试一般可以就在宿主环境上运行。嵌入式测试系统一般分为以下几个单元:预处理和词法语法分析单元、插桩单元和测试信息分析和显示单元以及测试用例单元。
集成测试(Integration testing):是把经过单元测试的模块按软件的结构组合在一起作为一个系统或一个子系统来综合测试。主要是用来发现程序的架构和体系结构设计方面的错误。虽然白盒测试用来保证大部分的路径覆盖率，但黑盒测试在集成测试中还是比较广泛。集成测试一般是在宿主环境中进行。
系统测试(System Testing):将系统的测试软件系统和其他资源(硬件、人机交互信息资源和数据库等)都综合起来构成完整的计算机应用系统进行测试的。是用来确保整个系统的性能、执行强度、安全性和功能都达到了我们的要求。所以在这个阶段是要和硬件结合，即和目标板一起进行测试，在目标环境中进行。确认测试(Validation testing):是把软件系统作为一个单一的执行实体而进行的需求有效性测试。其目的是验证我们的软件是否满足所有的功能、行为和执行要求，这部分主要是用黑盒测试。
根据测试时是否运行被测试的程序，软件测试技术还可分为静态测试方法和动态测试方法。
静态测试方法的主要特征就是不运行被测试的程序，主要采用检查、技术复审和代码静态分析来检查被测软件的错误，对于嵌入式软件来说该测试只需在主机上进行就可以了;动态测试方法是使被测代码在相对真实环境下运行，从多角度观察程序运行时能体现的功能、行为、结构等，并从中发现错误。它又分为白盒测试方法和黑盒测试方法。对于嵌入式软件来说，为了保证测试的真实性，一般要求在目标环境中进行。
从测试是否针对系统的内部结构和逻辑处理过程，通常可分为:白盒测试与黑盒测试。
黑盒测试又称为功能测试、数据驱动测试或基于规格说明的测试。它必须依靠能够反映这一关系和程序功能的需求规格说明书来考虑测试用例和推断测试结果的正确性。即所依据的只能是程序的外部特性。因此黑盒测试是从用户观点出发的测试。黑盒测试方法包括等价类划分、边界值分析、因果图和正交设计等基于软件功能的测试技术。在进行嵌入式软件黑盒测试时，要把系统的预期用途作为重要依据，根据需求中对负载、定时、性能的要求，判断软件是否满足这些需求规范。为了保证正确地测试，还需要检验与硬件之间的接口。嵌入式软件黑盒测试的一个重要方面是极限测试。在使用环境中，通常要求嵌入式软件的失效过程要平稳，所以，黑盒测试不仅要检查软件工作过程，也要检查软件失效过程。
白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试。采用这一测试方法，测试者可以看到被测的源程序，用以分析程序的内部构造，并且根据其内部构造设计测试用例。这时测试者可以完全不顾程序的功能。白盒测试方法又包括逻辑覆盖、符号测试、路径分析、程序插桩和程序变异等基于软件内部结构的测试技术。白盒测试与代码覆盖率密切相关，可以在白盒测试的同时计算出测试的代码覆盖率，保证测试的充分性。由于严格的安全性和可靠性的要求，嵌入式软件测试同非嵌入式软件测试相比，通常要求有更高的代码覆盖率。在软件工程的测试中有一个颇为实用的覆盖准则，即当语句覆盖率100%，分支覆盖率≥85%时，认为测试是理想的，软件错误可查出近90%，且允许时间和空间的消耗。日本日立公司和美国空军均采用此标准。对于嵌入式软件，白盒测试一般不必在目标硬件上进行，更为实际的方式是在开发环境中通过硬件仿真进行，所以选取的测试工具应该支持在宿主环境中的测试。
嵌入式软件测试强调的是白盒测试，一般的白盒测试包括语句覆盖、分支覆盖和条件覆盖。
嵌入式系统软件的独特之处
嵌入式系统由于自己本身的特点，如实时性强、内存不丰富、I/O通道少、开发工具昂贵并且与硬件紧密相关、CPU种类繁多等等，决定了不同的嵌入式系统必须有不同的测试方法，下面介绍几种不同的嵌入式产品在测试时应特别关注的问题。
唯一系统——“一次性”开发
某些系统，比如人造卫星，一旦发射之后就无法对其进行维护。这样的系统是“唯一系统”，意味着其建造是一次性的。
自治系统
有些嵌入式系统可以在无限长的时间内自主运行，它们担负某种任务。一旦运行后，就不再需要有人干预或与人交互。
硬件限制
硬件资源的局限性会给嵌入式软件带来一定的约束，比如内存使用和电力消耗。有时候特定的硬件也依赖于软件中计时的解决方法。对软件方面的这些约束并不会影响到需求的系统功能，但它们却是系统运行的首要条件，需要对此进行大量深入而技术性又很强的测试。
硬实时行为
“实时”的本质就是输入或输出在发生的瞬间就能够影响到系统的行为。
控制系统
控制系统通过连续的反馈机制和环境相互作用：系统的输出会影响环境，而环境反过来会影响到控制的行为。
强调安全系统
在嵌入式系统中当嵌入式系统的故障会导致对人体健康的严重伤害（或更为可怕的后果）时，则称该系统是“强调安全”的。大量的嵌入式系统都和人体有直接的物理接触，故障会直接导致身体的损伤，例如航空电子设备、医疗设备及核反应堆等。对这样的系统进行风险分析是极其重要的，需要采用严格的技术来分析并提高系统的可靠性。
极端的环境条件
有些系统需要在极端的环境条件下进行连续的操作，比如极热或极冷、机械震动、化学物质或放射性等环境条件。测试这些系统需要有特殊的设备来提供极端条件。当真实环境中的测试太危险时，就需要用设备来模拟环境。
嵌入式软件集成测试注意事项
嵌入式软件集成测试不仅要求软件行为的正确性，而且它要与其被控制的硬件设备实现正确的交互。在具体测试过程中可包含以下几个方面的测试工作
任务测试:首先独立测试系统中的每个任务，对每个任务设计白盒测试和黑盒测试用例。任务测试可以发现任务中的逻辑错误和功能错误，不能发现实时性错误和行为错误;行为测试:通过使用CASE工具创建的软件模型来仿真实时系统，按照外部事件(如中断、控制信号和数据)的序列检查其行为的正确性，可以先对每个事件进行独立测试，然后随机的把事件输入给系统来检查系统行为的正确性;
任务间测试:独立的任务测试完成后，就可以多个任务一起来测试时间相关的错误，错误用不同的数据率和处理负载来测试任务间的通信，来确定任务间的同步是否会产生;另外，测试通过消息队列和数据存储进行通信的任务以发现这些数据存储区域大小方面的错误。
集成测试:集成软件和硬件一起测试，来发现软硬件之间接口错误，同时测试是否存在中断处理方面的错误，包括中断优先级的分配是否正确、中断的处理是否正确、中断处理是否满足时间要求、多个中断出现的情况下系统的功能和性能是否存在问题。
| 
