---

1）什么是软件测试？

软件测试，即Software Testing。在软件生产过程中，手工或者利用软件测试工具有计划地根据程序代码和用户文档，检查软件功能和性能，从而发现软件产品中存在的问题（bug），并追踪和验证缺陷（bug）的处理。测试用例通常是从无限执行域中适当选取的。

软件测试是对软件形成过程中的所有工作产品（包括程序以及相关文档）进行的测试，而不仅仅是对程序的运行进行测试。

• 测试的目的：

  不是没有错误，而是软件产品经过发布之后，虽然有缺陷，但是用户可以接受和容忍的。

• 软件测试的特点：

  • 大多数硬件实验失败的方式和方法是固定的，而软件测试失败则是毫无规律的，探索所有软件测试失败的模式是不可能的。
  • 软件方面的许多缺陷都源于设计和实现上的错误，而不是源于生产制造方面的缺陷。
  • 软件质量保证的关键在于我们如何避免错误的产生和消除已经产生的错误，是程序中的错误密度达到尽可能低的程度。
  • 软件测试是一个动态的执行过程，体现在输入、行为和行为的输出结果上。
  • 软件测试是一个有限的集合。

软件测试信息流：

嵌入式软件测和普通软件测试对象相同，包括软件中所有内容，贯穿软件定义与开发的整个过程。

• 软件测试的对象：

  需求分析、概要设计、详细设计、程序编码等各阶段所得到的文档及源程序，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序。

嵌入式软件的开发和测试也就与普通软件的开发和测试策略有了很大的不同，嵌入式软件系统是一种针对特殊任务、特殊环境而进行特殊设计的定制产品，有其专门的开发环境、软硬件紧密结合、严格的实时要求等特点。使得嵌入式软件测试与普通软件测试虽有相似之处，但有也有其自身独特的特点。

2）嵌入式软件测试

2.1 嵌入式软件

嵌入式软件是一种比较特殊的软件，软件经过分析、设计、编码后只有烧入硬件环境中才可以看见，比如数字电视的中间件软件，洗衣机的自动控制软件，手机游戏软件等等。

2.2 嵌入式软件测试

嵌入式软件测试/嵌入式测试或叫交叉测试（cross-test），其目的与普通软件测试是相同的，都是为了发现软件缺陷，而后修正缺陷以提高软件的可靠性。嵌入式系统安全性的失效可能会导致灾难性的后果，即使非安全性失效，由于其应用场合特殊也会导致重大经济损失。因此，往往嵌入式软件对可靠性的要求比普通软件高。这就要求对嵌入式软件进行严格的测试、确认和验证，以提高产品的可靠性。

• 嵌入式软件测试的特点：

  • 嵌入式软件测试是在特定的硬件环境下才能运行的软件。
  • 嵌入式软件测试除了要保证嵌入式软件在特定环境下运行的高可靠性，还要保证嵌入式软件系统的实时性。
  • 嵌入式软件产品为了满足高可靠性的要求，不允许内存在运行时有泄漏等情况发生，因此嵌入式软件测试除了对软件进行性能测试、GUI测试、覆盖分析测试是同普通软件测试一样都不可或缺之外，还要对内存进行测试。
  • 嵌入式产品不同于一般软件产品，在嵌入式软件和硬件集成测试完成之后，并不代表测试全部完成，在第一件嵌入式产品生产出来之后，还需对其进行产品测试。
  • 嵌入式软件测试的最终目的是使嵌入式产品在能够满足所有功能的同时安全可靠的进行。

3）嵌入式软件测试与普通软件测试的区别

由于嵌入式系统的自身特点，如实时性(Real-timing)，内存不丰富，I/O通道少，开发工具昂贵，并且与硬件紧密相关，CPU种类繁多，等等。嵌入式软件的开发和测试也就与一般商用软件的开发和测试策略有了很大的不同，可以说嵌入式软件是最难测试的一种软件。
嵌入式系统由于上述特点，决定了不同的嵌入式系统必须有不同的测试方法。

3.1 嵌入式软件测试的各个阶段测试的环境是不一样的

嵌入式软件开发和运行的环境是分开的，嵌入式软件开发环境往往是交叉开发环境。因此，各个阶段测试的环境是不一样的。

• 交叉开发：

  交叉开发是指先在一台通用PC上进行软件的编辑、编译与连接，然后下载到嵌入式设备中运行调试的开发过程。通用PC称为宿主机，嵌入式设备称为目标机。

• 交叉开发环境：

  交叉开发环境（Cross Development Environment）是指编译、链接和调试嵌入式应用软件的环境。它与运行嵌入式应用软件的环境有所不同，通常采用“宿主机——目标机”模式。
  开放的交叉开发环境的典型代表是：GNU工具链。它能够支持X86、ARM、MIPS、PowerPC等多种处理器。

• 交叉编译：

  在一种平台上编译出能够在另一种平台（体系结构不同）上运行的程序。用来编译这种程序的编译器就叫做交叉编译器。

• GUN工具链：

  GNU工具链 (GNU Toolchain) 是一组用于开发应用程序和操作系统的编程工具的集合，这些工具构成了一个完整的系统。GNU工具链包括GCC、GNU Binutils、GNU
  m4、GNU Autoconf和GNU make等部分。

3.1.1 单元测试阶段

所有的单元测试基本都可以在宿主机环境下进行，只有个别情况下会特别指定单元测试要直接在目标机环境下进行。应该最大化在宿主机环境下进行软件测试的比例，通过尽可能小的目标单元访问其指定的目标单元界面，提高单元的有效性和针对性。

在宿主机平台上运行测试的速度比在目标机平台上快得多，当在宿主机平台上完成测试后可以在目标机环境下重复做一次简单的确认测试，确认测试结果在宿主机和目标机上没有不同**。在目标机环境下进行确认测试将确定一些未知的、未预料到的、未说明的宿主机与目标机的不同之处**，例如，目标机编译器可能有缺陷，但在宿主机编译器上没有。

3.1.2 集成测试阶段

软件集成也可在宿主机环境下完成，在宿主机平台上模拟目标环境运行，在此级别上的确认测试可以确定一些与环境有关的问题，比如内存定位和分配方面的一些错误。

在宿主机环境上的集成测试的使用，依赖于目标系统的具体功能有多少。有些嵌入式系统与目标机环境耦合的非常紧密，这种情况下就不适合在宿主机环境下进行集成。对于一个大型的软件开发而言，集成可以分几个级别。低级别的软件集成在宿主机平台上完成有很大优势，级别越高，集成越依赖于目标环境。

3.1.3 系统测试和确认测试

所有的系统测试和确认测试必须在目标机环境下执行。当然在宿主机上开发和执行系统测试，然后移植到目标机环境重复执行是很方便的。对目标系统的依赖性会妨碍将宿主机上的系统测试移植到目标系统上，况且只有少数开发者会卷入系统测试，所以有时放弃在宿主机上执行系统测试可能更方便。

确认测试最终必须在目标机环境中进行，因为系统的确认必须在真实系统下完成，而不能在宿主机环境下模拟，这关系到嵌入式软件的最终使用。

3.2 嵌入式软件测试的复杂多样

因为嵌入式系统的一个突出的特点，是其专用性，即一个嵌入式系统只进行特定的一项或几项工作，嵌入式软件运行的平台都是为进行这些工作而开发出来的专用硬件电路，他们的体系结构、硬件电路，甚至所用的元器件都是不一样的，所以嵌入式软件运行的平台也是复杂多样的。

由于开发平台的复杂多样性，使得嵌入式软件的测试从测试环境的建立到测试用例的编写也是复杂多样的。与不同的开发平台对应的嵌入式软件是肯定不相同的。嵌入式软件测试在一定程度的上并不只是对嵌入式软件的测试，很多情况下是对嵌入式软件在开发平台中同硬件的兼容性测试。因此，对于任何一套嵌入式软件系统，都需要有其自己的测试、创建其自己的测试环境、编写其自己的测试用例。

3.3 嵌入式软件测试中对实时性有严格要求

由于嵌入式系统的实时性，决定了嵌入式系统的运行时间也是受严格限制的。嵌入式软件在测试时应当充分考虑系统实时响应的问题，很多嵌入式系统会要求系统的响应时间应在多少毫秒之内。在测试有严格响应时间要求的嵌入式系统时，要做负载测试。

3.4 嵌入式软件测试需要进行插桩测试

嵌入式软件最终的测试需要在目标机平台上进行，在对目标机进行测试时，我们需要对在宿主机上编译通过的代码进行插桩处理。插桩完成之后，需要重新对代码进行编译，如果编译通过，就可以将编译好的代码下载到目标机上执行。在目标机执行程序的时候，需要将插桩时预测好的数据返回到宿主机上，因此，宿主机和目标机上要有能够相互传递数据的网线或者串口线，宿主机上同时要有能够处理返回的数据的处理程序或软件。

• 插桩技术：

  指在保证原有程序逻辑完整性的基础上，在程序中插入探针，通过探针采集代码中的信息（方法本身、方法参数值、返回值等）在特定的位置插入代码段，从而收集程序运行时的动态上下文信息。

3.5 嵌入式软件对系统的可靠性和安全性要求比一般的软件系统高

因为嵌入式软件对系统的可靠性和安全性要求比一般的软件系统高，所以还需要进行系统的可靠性测试。对于不同的嵌入式系统，需要制定相应的符合系统需求的可靠级别，在进行可靠性测试时应该将系统的可靠性级别考虑进去。

4）常见问题之内存问题

内存问题危害很大，不容易排查，主要有三种类型：

• 内存泄露
• 内存碎片
• 内存崩溃

4.1 内存泄漏

在软件设计中，内存泄露最著名，主要由于不断分配的内存无法及时地被释放，久而久之，系统的内存耗尽。内存泄露问题一般隐藏很深，很难通过代码阅读来发现。有些内存泄露甚至可能出现在库当中，有可能这本身是库中的bug，也有可能是因为程序员没有正确理解它们的接口说明文档造成错用。

在很多时候，大多数的内存泄露问题无法探测，但可能表现为随机的故障。程序员们往往会把这种现象怪罪于硬件问题。如果用户对系统稳定性不是很高，那么重启系统问题也不大；但，如果用户对系统稳定很高，那么这种故障就有可能使用户对产品失去信心，同时也意味着这是个失败的项目。由于内存泄露危害巨大，现在已经有许多工具来解决这个问题。这些工具通过查找没有引用或重复使用的代码块、垃圾内存收集、库跟踪等技术来发现内存泄露的问题。每个工具都有利有弊，不过总的来说，用要比不用好。总之，负责的开发人员应该去测试内存泄露的问题，做到防患于未然。

4.2 内存碎片

内存碎片比内存泄露隐藏还要深。随着内存的不断分配并释放，大块内存不断分解为小块内存，从而形成碎片，久而久之，当需要申请大块内存是，有可能就会失败。如果系统内存够大，那么坚持的时间会长一些，但最终还是逃不出分配失败的厄运。在使用动态分配的系统中，内存碎片经常发生。目前，解决这个问题最效的方法就是使用工具通过显示系统中内存的使用情况来发现谁是导致内存碎片的罪魁祸首，然后改进相应的部分。

由于动态内存管理的种种问题，在嵌入式应用中，很多公司干脆就禁用malloc/free的以绝后患。

4.3 内存崩溃

内存崩溃是内存使用最严重的结果，主要原因有数组访问越界、写已经释放的内存、指针计算错误、访问堆栈地址越界等等。这种内存崩溃造成系统故障是随机的，而且很难查找，目前提供用于排查的工具也很少。

5）嵌入式测试工具和测试方法

5.1 嵌入式测试工具

5.1.1 内存分析工具

内存分析工具用来处理在动态内存分配中存在的缺陷。当动态内存被错误地分配后，通常难以再现，可能导致的失效难以追踪，使用内存分析工具可以避免这类缺陷进入功能测试阶段。

目前有两类内存分析工具（软件的和硬件的）：

• 基于软件的内存分析工具可能会对代码的性能造成很大影响，从而严重影响实时操作。
• 基于硬件的内存分析工具价格昂贵，而且只能在工具所限定的运行环境中使用。

5.1.2 性能分析工具

在嵌入式系统中，程序的性能通常是非常重要的。经常会有这样的要求，在特定时间内处理一个中断，或生成具有特定定时要求的一帧。开发人员面临的问题是决定应该对哪一部分代码进行优化来改进性能，常常会花大量的时间去优化那些对性能没有任何影响的代码。

性能分析工具会提供有关的数据，说明执行时间是如何消耗的，是什么时候消耗的，以及每个例程所用的时间。根据这些数据，确定哪些例程消耗大部分执行时间，从而可以决定如何优化软件，获得更好的时间性能。对于大多数应用来说，大部分执行时间用在相对少量的代码上，费时的代码估计占所有软件总量的5%~20%。性能分析工具不仅能指出哪些例程花费时间，而且与调试工具联合使用可以引导开发人员查看需要优化的特定函数，性能分析工具还可以引导开发人员发现在系统调用中存在的错误以及程序结构上的缺陷。

5.1.3 GUI测试工具

很多嵌入式应用带有某种形式的图形用户界面进行交互，有些系统性能测试是根据用户输入响应时间进行的。GUI测试工具可以作为脚本工具在开发环境中运行测试用例，其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程。很多嵌入式设备没有GUI，但常常可以对嵌入式设备进行插装来运行GUI测试脚本。虽然这种方式可能要求对被测代码进行更改，但是节省了功能测试和回归测试的时间。

5.1.4 覆盖分析工具

在进行白盒测试时，可以使用代码覆盖分析工具追踪哪些代码被执行过。分析过程可以通过插装来完成，插装可以是在测试环境中嵌入硬件，也可以是在可执行代码中加入软件，也可以是二者相结合。测试人员对结果数据加以总结，确定哪些代码被执行过，哪些代码被遗漏了。覆盖分析工具一般会提供有关功能覆盖、分支覆盖、条件覆盖的信息。对于嵌入式软件来说，代码覆盖分析工具可能侵入代码的执行，影响实时代码的运行过程。基于硬件的代码覆盖分析工具的侵入程度要小一些，但是价格一般比较昂贵，而且限制被测代码的数量。

5.2 嵌入式软件的测试方法

一般来说，软件测试有7个基本阶段，即单元或模块测试、集成测试、外部功能测试、回归测试、系统测试、验收测试、安装测试。嵌入式软件测试在4个阶段上进行，即模块测试、集成测试、系统测试、硬件/软件集成测试。前3个阶段适用于任何软件的测试，硬件/软件集成测试阶段是嵌入式软件所特有的，目的是验证嵌入式软件与其所控制的硬件设备能否正确地交互。

软件测试有两种基本的方式，即白盒测试方法与黑盒测试方法，嵌入式软件测试也不例外。

5.2.1 白盒测试

• 白盒测试或基于代码的测试检查程序的内部设计。根据源代码的组织结构查找软件缺陷，一般要求测试人员对软件的结构和作用有详细的了解。

对于嵌入式软件，白盒测试一般不必在目标硬件上进行，更为实际的方式是在开发环境中通过硬件仿真进行，所以选取的测试工具应该支持在宿主环境中的测试。

5.2.2 黑盒测试

黑盒测试在某些情况下也称为功能测试。这类测试方法根据软件的用途和外部特征查找软件缺陷，不需要了解程序的内部结构。黑盒测试最大的优势在于不依赖代码，而是从实际使用的角度进行测试，通过黑盒测试可以发现白盒测试发现不了的问题。因为黑盒测试与需求紧密相关，需求规格说明的质量会直接影响测试的结果，黑盒测试只能限制在需求的范围内进行。

在进行嵌入式软件黑盒测试时，要把系统的预期用途作为重要依据，根据需求中对负载、定时、性能的要求，判断软件是否满足这些需求规范。为了保证正确地测试，还须要检验软硬件之间的接口。嵌入式软件黑盒测试的一个重要方面是极限测试。在使用环境中，通常要求嵌入式软件的失效过程要平稳，所以，黑盒测试不仅要检查软件工作过程，也要检查软件失效过程。

---

【部分内容参考自】

• 嵌入式软件测试与一般软件测试之异同研究：http://www.51testing.com/html/88/n-837488.html
• 嵌入式软件测试：https://blog.csdn.net/weixin_34150503/article/details/93253249
• 嵌入式软件测试工具和测试方法：https://blog.csdn.net/wuxiaobingandbob/article/details/47274411