论文部分内容阅读
摘 要： 随着软件技术的不断革新，人们对软件的正确性和准确性的要求也在不断提高，软件测试技术得到越来越多的重视和应用。嵌入式软件作为一种特殊的软件，符合软件的大多数特征的同时也具有自己特点。本文指出软件测试的目的，并根据嵌入式系统软件的特点，介绍嵌入式系统软件的测试方法、测试工具盒测试策略。
关键词： ARM-Linux；嵌入式系统；软件测试；测试研究
1 软件测试的目的
软件作为一种产品要为用户提供服务并最终达到满足用户需求的目的。但在实际软件使用过程中往往会发现一些软件错误和缺陷。如：不能达到用户需求的功能和性能；软件在某些方面超出了客户的需求范围；软件的使用不符合客户的工作环境和使用习惯等。这些错误和缺陷都会给用户的带来一些潜在的隐患和风险。软件测试就是要在软件发布之前利用最少的人力、物力和时间找出软件中存在的各种错误和缺陷，并及时的进行修正，以提高软件的质量。
软件测试时，要尽可能的找出最多的错误和缺陷，并在软件发布之前进行修正和改善，以保障最终用户手中软件的正确性和准确性。但软件测试只能发现所做测试项目的正确性，对软件程序的正确性不能保障。
2 软件测试技术
2.1 静态测试
静态测试是软件开发早期阶段最有力的错误检测技术，它是对被测试程序特性分析的一些方法的总称。静态测试包括设计、代码和其他工作产品的审查、走查以及和同行评审，并用于揭露语法、数据结构等的缺陷。静态测试的作用很大，在实际的工作中也有不足之处，它不利用计算机运行被测试的程序，而是采用其它手段达到检测的目的。目前，静态测试被当作是一种自动化的代码检验过程，主要对程序进行控制流分析、数据流分析、接口分析和表达式分析等。
2.2 动态测试
动态测试是通过在相对真实的环境中运行被测软件，观察程序运行时的功能、逻辑、行为和结构，比较软件程序的实际行为与预期行为是否一致以查找软件缺陷的方法。动态测试是软件测试的核心之一，它可以实现功能测试、性能测试、强度测试等多种类型的测试。
3 嵌入式系统软件测试技术
嵌入式系统软件测试又叫交叉测试，它与PC机的软件测试有相似之处，但是在嵌入式系统软件设计中，为降低系统成本，获得更大的灵活性，嵌入式系统软件正越来越多的取代硬件，使得嵌入式系统软件测试具有更加重要的意义。由于嵌入式系统尤其是嵌入式实时系统的错误可能会带来灾难性的后果，所以嵌入式系统软件需要使用更好地测试方法和工具，经过更为严格的测试、确认和验证，才能保证嵌入式系统软件的质量。
4 嵌入式系统软件的测试方法
4.1 白盒测试与黑盒测试
白盒测试与黑盒测试是软件测试的两种基本方法，嵌入式系统软件测试也不例外。在对嵌入式系统软件进行的白盒测试中一般采取比较实际的方式，即在开发环境中通过硬件仿真进行，而不需要在目标硬件上进行，所以在测试时选取的测试工具应该支持在宿主环境中的测试。嵌入式系统软件的黑盒测试主要是极限测试，在使用环境中，通常要求嵌入式软件的失效过程要平稳，所以黑盒测试不仅要检查软件的工作过程，也要检查软件的失效过程。
4.2 目标环境测试和宿主环境测试
在嵌入式软件测试中，常常要在基于目标环境的测试和基于宿主环境的测试之间作出折中。基于目标的测试所需的经费较多、时间长，而基于宿主的测试代价较小。目前嵌入式系统软件测试的趋势是把更多的测试转移到宿主环境中进行，但基于宿主的测试是在模拟环境中进行的，可目标环境的复杂性和独特性不可能完全模拟，所以在两种环境中的测试都可以出现不同的系统软件缺陷。
目标环境和宿主环境的测试内容是有所选择的，在宿主环境中，可以进行逻辑或界面的测试以及与硬件无关的测试。在宿主环境中的测试消耗时间相对较少，用调试工具可以较快地完成调试和测试任务。但遇到与定时问题有关的白盒测试、中断测试、硬件接口测试时，只能在目标环境中进行。
5 嵌入式软件的测试工具
5.1 内存分析工具
在嵌入式系统中，内存分析工具主要用来处理在动态内存分配中存在的缺陷。由于嵌入式系统的内存约束通常是有限的，所以当动态内存被错误的分配后，通常难以再现，甚至导致的失效难以追踪，使用内存分析工具就可以避免这类错误和缺陷，并能有效防止其进入功能调试阶段造成不良影响。基于硬件的内存分析工具价格昂贵，且只能在工具所限定的运行环境中使用，而基于软件的内存分析工具可能会对代码的性能造成很大的影响，严重影响实时操作。由此可见这两类内存分析工具都有自己的缺陷。
5.2 性能分析工具
在嵌入式系统中，程序的性能通常是非常重要的。性能分析工具能够提供有关的数据，说明执行时间是如何消耗的，是什么时候消耗的以及每个例程所用的时间。根据这些数据，开发人员可以确定哪些例程消耗大部分执行时间，从而决定从哪一部分代码进行优化来改善软件，避免对性能没有任何影响的代码的干扰，以更快地解决优化问题，是软件获得更好的时间性能。
5.3 覆盖分析工具
覆盖分析工具一般会提供有关功能覆盖、分支覆盖、条件覆盖的信息。对于嵌入式系统软件来说，代码覆盖分析工具可能侵入代码的执行，影响实时代码的运行过程。基于硬件的代码覆盖分析工具价格昂贵，但侵入程度要小一些。进行白盒测试时，可以使用代码覆盖分析工具追踪哪些代码被执行过。
6 嵌入式系统的测试策略
6.1 单元测试
除非特别指定单元测试直接在目标环境进行，所有单元测试都可以在宿主环境上进行。最大化在宿主环境进行软件测试的比例，通过尽可能小的目标单元访问所有目标指定的界面。在宿主平台上进行测试，其速度比在目标平台上快得多，当在宿主平台完成测试，可以在目标环境上重复作简单的确认测试，在目标环境上进行确认测试可以确定一些未知的、未预料到的问题。 基于ARM-Linux的嵌入式系统软件测试的单元测试中，主要采用基于GDB的远程测试方法、基于集成开发环境的ADTIDE的测试方法和基于JTAG仿真器和Multi-ICE的测试方法。
6.2 集成测试
软件集成也可以通过在宿主平台上模拟目标环境运行来完成，在宿主环境中完成集成测试后还要在目标环境上进行重复测试，以保障测试结果的准确性。在宿主环境中的确认测试可以确定内存定位和分配上的错误等一些环境上的问题。
在宿主环境中的集成测试的使用，依赖于目标系统的具体功能。有些嵌入式系统与目标环境耦合得非常紧密，若在宿主环境做集成测试是不切实际的。一个大型软件的开发可以分几个级别的集成。低级别的软件集成在宿主平台上完成有很大的优势，越往后的集成测试越依赖于目标环境。ARM主流开发工具在Linux操作系统下主要采用GNU和GDB相结合的方式进行。
6.3 系统测试和确认测试
系统测试主要是针对软件功能的测试，主要在目标环境下执行。有的嵌入式系统软件在宿主环境中开发和执行系统测试，然后再移植到目标环境重复执行很方便。但由于软件对目标系统具有依赖性，导致将宿主环境中的系统测试移植到目标系统上会遇到障碍。鉴于目前只有少数开发者会参与系统测试，所以有时放弃在宿主环境上执行系统测试会更加方便。
确认测试也需要在目标环境下执行，且确认测试最终的实施舞台必须在目标环境中，系统的确认必须在真实系统下测试，而不能在宿主环境下模拟，这关系到嵌入式软件的最终使用。
通常情况下，嵌入式软件的可移植性是成功进行交叉测试的先决条件，嵌入式系统软件测试在宿主环境执行多数测试，只将最终确定测试结果和最后的系统测试移植到目标环境，这样可以避免出现使用目标系统资源的瓶颈，也可以节约成本。另外，若目标系统的硬件由于某种原因不能使用，最后的确认测试可以推迟直到目标硬件可用时，这为嵌入式软件的开发测试提供了弹性。
6.4 回归测试
回归测试主要是由于系统未修改的部分可能受修改部分的影响，导致已测试通过的部分在使用中使系统产生失效而进行的测试。每当嵌入式系统软件发生变化时，都需要重新测试已有的功能，以确定修改是否达到了预期的目的。
参考文献：
[1]陆巍，嵌入式数控系统人机界面及系统软件，2006年（01）.
[2]韩鹏，基于ARM-LINUX的路由器研究，2005年（02）.
[3]方政，基于ARM的网络型多环境参数测控系统的研究，2007（06）.
[4]程秀全、王玉辉、夏琴香，ARM嵌入式数控旋压机床控制系统应用软件开发，2008（03）.
[5]蒋洪、雷运理，基于ARM嵌入式技术的数控机床控制系统的研究2012（01）.
关键词： ARM-Linux；嵌入式系统；软件测试；测试研究
1 软件测试的目的
软件作为一种产品要为用户提供服务并最终达到满足用户需求的目的。但在实际软件使用过程中往往会发现一些软件错误和缺陷。如：不能达到用户需求的功能和性能；软件在某些方面超出了客户的需求范围；软件的使用不符合客户的工作环境和使用习惯等。这些错误和缺陷都会给用户的带来一些潜在的隐患和风险。软件测试就是要在软件发布之前利用最少的人力、物力和时间找出软件中存在的各种错误和缺陷，并及时的进行修正，以提高软件的质量。
软件测试时，要尽可能的找出最多的错误和缺陷，并在软件发布之前进行修正和改善，以保障最终用户手中软件的正确性和准确性。但软件测试只能发现所做测试项目的正确性，对软件程序的正确性不能保障。
2 软件测试技术
2.1 静态测试
静态测试是软件开发早期阶段最有力的错误检测技术，它是对被测试程序特性分析的一些方法的总称。静态测试包括设计、代码和其他工作产品的审查、走查以及和同行评审，并用于揭露语法、数据结构等的缺陷。静态测试的作用很大，在实际的工作中也有不足之处，它不利用计算机运行被测试的程序，而是采用其它手段达到检测的目的。目前，静态测试被当作是一种自动化的代码检验过程，主要对程序进行控制流分析、数据流分析、接口分析和表达式分析等。
2.2 动态测试
动态测试是通过在相对真实的环境中运行被测软件，观察程序运行时的功能、逻辑、行为和结构，比较软件程序的实际行为与预期行为是否一致以查找软件缺陷的方法。动态测试是软件测试的核心之一，它可以实现功能测试、性能测试、强度测试等多种类型的测试。
3 嵌入式系统软件测试技术
嵌入式系统软件测试又叫交叉测试，它与PC机的软件测试有相似之处，但是在嵌入式系统软件设计中，为降低系统成本，获得更大的灵活性，嵌入式系统软件正越来越多的取代硬件，使得嵌入式系统软件测试具有更加重要的意义。由于嵌入式系统尤其是嵌入式实时系统的错误可能会带来灾难性的后果，所以嵌入式系统软件需要使用更好地测试方法和工具，经过更为严格的测试、确认和验证，才能保证嵌入式系统软件的质量。
4 嵌入式系统软件的测试方法
4.1 白盒测试与黑盒测试
白盒测试与黑盒测试是软件测试的两种基本方法，嵌入式系统软件测试也不例外。在对嵌入式系统软件进行的白盒测试中一般采取比较实际的方式，即在开发环境中通过硬件仿真进行，而不需要在目标硬件上进行，所以在测试时选取的测试工具应该支持在宿主环境中的测试。嵌入式系统软件的黑盒测试主要是极限测试，在使用环境中，通常要求嵌入式软件的失效过程要平稳，所以黑盒测试不仅要检查软件的工作过程，也要检查软件的失效过程。
4.2 目标环境测试和宿主环境测试
在嵌入式软件测试中，常常要在基于目标环境的测试和基于宿主环境的测试之间作出折中。基于目标的测试所需的经费较多、时间长，而基于宿主的测试代价较小。目前嵌入式系统软件测试的趋势是把更多的测试转移到宿主环境中进行，但基于宿主的测试是在模拟环境中进行的，可目标环境的复杂性和独特性不可能完全模拟，所以在两种环境中的测试都可以出现不同的系统软件缺陷。
目标环境和宿主环境的测试内容是有所选择的，在宿主环境中，可以进行逻辑或界面的测试以及与硬件无关的测试。在宿主环境中的测试消耗时间相对较少，用调试工具可以较快地完成调试和测试任务。但遇到与定时问题有关的白盒测试、中断测试、硬件接口测试时，只能在目标环境中进行。
5 嵌入式软件的测试工具
5.1 内存分析工具
在嵌入式系统中，内存分析工具主要用来处理在动态内存分配中存在的缺陷。由于嵌入式系统的内存约束通常是有限的，所以当动态内存被错误的分配后，通常难以再现，甚至导致的失效难以追踪，使用内存分析工具就可以避免这类错误和缺陷，并能有效防止其进入功能调试阶段造成不良影响。基于硬件的内存分析工具价格昂贵，且只能在工具所限定的运行环境中使用，而基于软件的内存分析工具可能会对代码的性能造成很大的影响，严重影响实时操作。由此可见这两类内存分析工具都有自己的缺陷。
5.2 性能分析工具
在嵌入式系统中，程序的性能通常是非常重要的。性能分析工具能够提供有关的数据，说明执行时间是如何消耗的，是什么时候消耗的以及每个例程所用的时间。根据这些数据，开发人员可以确定哪些例程消耗大部分执行时间，从而决定从哪一部分代码进行优化来改善软件，避免对性能没有任何影响的代码的干扰，以更快地解决优化问题，是软件获得更好的时间性能。
5.3 覆盖分析工具
覆盖分析工具一般会提供有关功能覆盖、分支覆盖、条件覆盖的信息。对于嵌入式系统软件来说，代码覆盖分析工具可能侵入代码的执行，影响实时代码的运行过程。基于硬件的代码覆盖分析工具价格昂贵，但侵入程度要小一些。进行白盒测试时，可以使用代码覆盖分析工具追踪哪些代码被执行过。
6 嵌入式系统的测试策略
6.1 单元测试
除非特别指定单元测试直接在目标环境进行，所有单元测试都可以在宿主环境上进行。最大化在宿主环境进行软件测试的比例，通过尽可能小的目标单元访问所有目标指定的界面。在宿主平台上进行测试，其速度比在目标平台上快得多，当在宿主平台完成测试，可以在目标环境上重复作简单的确认测试，在目标环境上进行确认测试可以确定一些未知的、未预料到的问题。 基于ARM-Linux的嵌入式系统软件测试的单元测试中，主要采用基于GDB的远程测试方法、基于集成开发环境的ADTIDE的测试方法和基于JTAG仿真器和Multi-ICE的测试方法。
6.2 集成测试
软件集成也可以通过在宿主平台上模拟目标环境运行来完成，在宿主环境中完成集成测试后还要在目标环境上进行重复测试，以保障测试结果的准确性。在宿主环境中的确认测试可以确定内存定位和分配上的错误等一些环境上的问题。
在宿主环境中的集成测试的使用，依赖于目标系统的具体功能。有些嵌入式系统与目标环境耦合得非常紧密，若在宿主环境做集成测试是不切实际的。一个大型软件的开发可以分几个级别的集成。低级别的软件集成在宿主平台上完成有很大的优势，越往后的集成测试越依赖于目标环境。ARM主流开发工具在Linux操作系统下主要采用GNU和GDB相结合的方式进行。
6.3 系统测试和确认测试
系统测试主要是针对软件功能的测试，主要在目标环境下执行。有的嵌入式系统软件在宿主环境中开发和执行系统测试，然后再移植到目标环境重复执行很方便。但由于软件对目标系统具有依赖性，导致将宿主环境中的系统测试移植到目标系统上会遇到障碍。鉴于目前只有少数开发者会参与系统测试，所以有时放弃在宿主环境上执行系统测试会更加方便。
确认测试也需要在目标环境下执行，且确认测试最终的实施舞台必须在目标环境中，系统的确认必须在真实系统下测试，而不能在宿主环境下模拟，这关系到嵌入式软件的最终使用。
通常情况下，嵌入式软件的可移植性是成功进行交叉测试的先决条件，嵌入式系统软件测试在宿主环境执行多数测试，只将最终确定测试结果和最后的系统测试移植到目标环境，这样可以避免出现使用目标系统资源的瓶颈，也可以节约成本。另外，若目标系统的硬件由于某种原因不能使用，最后的确认测试可以推迟直到目标硬件可用时，这为嵌入式软件的开发测试提供了弹性。
6.4 回归测试
回归测试主要是由于系统未修改的部分可能受修改部分的影响，导致已测试通过的部分在使用中使系统产生失效而进行的测试。每当嵌入式系统软件发生变化时，都需要重新测试已有的功能，以确定修改是否达到了预期的目的。
参考文献：
[1]陆巍，嵌入式数控系统人机界面及系统软件，2006年（01）.
[2]韩鹏，基于ARM-LINUX的路由器研究，2005年（02）.
[3]方政，基于ARM的网络型多环境参数测控系统的研究，2007（06）.
[4]程秀全、王玉辉、夏琴香，ARM嵌入式数控旋压机床控制系统应用软件开发，2008（03）.
[5]蒋洪、雷运理，基于ARM嵌入式技术的数控机床控制系统的研究2012（01）.