嵌入式软件测试和验证
一、软件测试
1.1定义
1993 年IEEE 对软件测试给出了一个综合的定义：①将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中；②是对①中所述方法的研究。它指出软件工程是一种层次化的技术。科学的测试是贯穿整个产品生命周期中的测试。要突破原来对测试的理解，着眼于整个软件生存期，特别是着眼于编码以前各开发阶段的测试工作，以保证软件的质量。
1.2软件测试的真正目标
软件测试的真正目标是寻找bug。即使是在交付时间表很紧的情况下，采取一个步骤来想一下从哪里开始着手，这样，测试才会是最有效率的。但即使在时间非常充足的情况下，也不可能测试出每一个bug，所以必须将测试划分优先级，划分的根据是基于产品目前的状态(新的，修改的或者只是纯漏洞)和对客户的可能影响而进行的最诚实的评估。避免采用知道软件可以处理的测试数据和操作;测试人员的任务是在测试中扩大软件的边界。在设计自动化测试时，也要避免“踩灭”失败条件的误区。测试人员的任务不是创造大量的总是可以干净的成功运行的测试。测试人员需要去寻找和理解故障条件。不要浪费时间去想软件产品中是否存在bug。它肯定有bug，并且不可能全部找出它们。测试的目的是指望测试人员找出那些最有影响的bug。必须要做的是，要从消极的角度考虑这些问题。
1.3软件测试的意义
1.发现软件错误;
2.有效定义和实现软件成分由低层到高层的组装过程；
3.验证软件是否满足任务书和系统定义文档所规定的技术要求；
4.为软件质量模型的建立提供依据；
即软件测试包括“找错”、“组装”、“确认”和“评估”四个层次的作用。
1.4软件测试方法
从不同的角度来看，可以将软件测试的方法分为以下几类：根据是否需要运行被测软件的角度，软件测试分为静态测试方法和动态测试方法。根据在动态测试中是否需要了解被测软件代码结构的角度，又分为白盒测试和黑盒测试。根据在静态测试中是否要了解源程序语法的角度，测试可分为语法测试和语义测试。根据如何选择测试数据的角度，测试又可分为功能测试、结构测试和随机测试。根据使用的测试数据的类型，测试又可分为确定性测试和随机测试等等。图1 是软件测试方法的分类图。
图1软件测试分类图
1.5软件测试的基本内容
软件测试工作包括两个层次:
1.测试工作的组织与管理，包括:制定测试方法与规范、控制测试进度、管理测试资源。
2.测试工作的实施，包括:编制符合标准的测试文档、研制测试环境、与开发组织协作实现各阶段的测试活动。
软件测试工作可以分为四个方面:
1.测试管理。测试小组是质量保证组织的一个成分，因此测试管理工作应被置于软件质量管理工作范围内。
2.测试计划。独立的测试组织负责定义软件测试的方法与规范。开发组织负责编制单元测试的计划和说明;测试组织主要负责编制其它各测试阶段的测试计划和说明。
3.测试实施。测试实施组织的作用是:按测试计划与测试说明的定义对测试对象进行相应的测试;填写测试报告中相应的表格。
4.测试评审。依据软件测试评审准则在各测试阶段评审时提交类型完整的测试文档。1.6软件测试的标准
组织者在指定范围内选择软件测试遵循的标准，并结合本软件系统的具体要求，使之贯彻到整个软件测试的计划、实现和管理过程之中。根据标准，需要被明确的内容包括:测试阶段和测试文档类型。可以从三个角度来划分测试阶段:面向测试操作类型的阶段划分、面向测试操作对象的阶段划分、面向测试实施者的阶段划分。测试操作类型包括:调试、集成、确认、验证、组装、验收、操作等。测试操作对象可以是:单元、部件、配置项、子系统、系统等。测试实施者可以是:开发者、测试者、使用者、验收者等。各类标准从不同角度定义测试评审阶段，而测试组织者可以在符合所选标准的同时，结合多个划分因素规定本系统的测试阶段。各标准规定的测试文档类型也不尽相同。如国标《软件产品开发文件编制指南》规定了两类测试文档:测试计划、测试分析报告;国标《计算机软件测试文件编制规范》定义了八类测试文档:测试计划、测试设计说明、测试用例说明、测试规程说明、测试项传递报告、测试日志、测试事件报告、测试总结报告; 《XXXX软件工程化技术文件》定义了三类测试文档:测试计划、测试说明、测试报告。我们认为最后这种规定较易操作:因为，太
少的测试文档类型不利于有步骤有层次地定义测试内容，也不利于测试用例和测试例程的良好表达;太多的测试文档类型易使测试组织陷入到繁杂的文档规范和编制中去;而第三种定义较为适中。其中:测试计划在系统分析/设计阶段提交，着重定义测试的资源、范围、内容、安排、通过准则等;测试说明在测试计划明确后开始编制，针对软件需求和设计要求具体定义测试用例和测试规程;测试报告分析和总结测试结果，测试日志是其必要附件。
二、嵌入式软件测试和验证
2.1嵌入式软件测试的独特性和必要性
嵌入式系统在人类生活中发挥着重要的作用，包括飞行控制器这样的控制系统，以及洗衣机这样的家用电器。目前，嵌入式系统中软件的比重越来越大，也越来越复杂，保证嵌入式软件的可靠性正面临严峻的挑战。大多数软件测试方法都可以直接或间接地用于嵌入式软件的测试，但是由于操作系统的实时和嵌入式特性，嵌入式软件测试也面临一些特殊的问题。虽然目前已经有一些针对嵌入式软件的测试和调试工具，但是在有些方面仍存在不足，包括许多任务操作系统的并发、非侵入式的测试和调试、嵌入式系统的软件抽象等。对于嵌入式软件测试技术的研究人选测试工具有待开发，仍须要做很多进一步的工作。
软件测试的目的是保证软件满足需求规格说明。系统失效是系统没有满足一个或多个正式需求规范中所要求的需求项。嵌入式软件有其特殊的失效判定准则，但是，嵌入式软件测试/嵌入式测试或叫交叉测试(cross-test)的目的与非嵌入式软件是相同的。在嵌入式系统设计中，软件正越来越多地取代硬件，以降低系统的成本，获得更大的灵活性，这就需要使用更好的测试方法和工具进行嵌入式和实时软件的测试。通常嵌入式系统对可靠性的要求比较高。嵌入式系统安全性的失效可能会导致灾难性的后果，即使是非安全性系统，由于大批量生产也会导致严重的经济损失。这就要求对嵌入式系统，包括嵌入式软件进行严格的测试、确认和验证。随着越来越多的领域使用软件和微处理器控制各种嵌入式设备，对日益复杂的嵌入式软件进行快速有效的测试愈加显得重要。例如，航天飞机的飞行软件达50 万行源代码，F-22 战斗机更达150 多万行源代码，软件失效已成为系统瘫痪的主要原因。根据美国国防部和NASA 的统计，当今武器系统和航天项目中的软件可靠性比硬件系统大约低一个数量级。在工程应用中由软件引发的、震惊科技界的故障持续不断，在某些类型的设备中软件故障甚至远远超过了硬件，成为系统的主要故障源。如何保障软件具有一定的可靠性以避免灾难性后果的发生，是当前计算机学科应该重点研究的问题。
2.2嵌入式软件测试环境
软件测试环境包括设计环境、实施环境和管理环境。软件测试设计环境指:编制测试计划/说明/报告及与测试有关的文件所基于的软/硬件设备和支持。软件测试实施环境指:对软件系统进行各级测试所基于的软/硬件设备和支持。测试实施环境包括被测软件的运行平台和用于各级测试的工具。软件测试管理环境指:管理测试资源所基于的软/硬件设备和支持。测试资源指测试活动所利用或产生的有形物质(如软件、硬件、文档)或无形财富(如人力、时间、测试操作等)。广义的测试管理环境包含测试设计环境、测试实施环境，和专门的测试管理工具。对软件测试环境的定义包括两个方面:折衷需求和实际条件来选择已有的测试工具;有重点地自行开发测试辅助工具。
软件测试必须依托工具，以便测试过程的自动/半自动执行和测试结果的自动/半自动评审和报告。目前市场上测试工具分为三类:代码分析工具、自动/半自动测试过程管理工具和测试资源管理工具。
嵌入式软件与其他软件相比，它具有专用性，它只能在需求所指定的硬件平台上运行。并且嵌入式软件的开发环境和运行环境是不一致的，因此即使宿主机环境下测试再充分，也不能说明在目标机环境下运行该软件就不出问题。因而，嵌入式软件还面临着目标环境的测试。这不仅增加了测试的代价，而且还带来了嵌入式软件的测试策略问题，即哪些测试分配到宿主机环境进行，哪些测试分配到目标机环境下进行。
嵌入式软件测试使用有效的测试策略是唯一的出路，它可以使开发的效率最大化，避免目标系统的瓶颈，使用在线仿真器节省昂贵的目标资源。嵌入式系统开发环境被认为是主机平台，软件运行环境为目标平台。相应的测试为Host/Target测试或cross-testing。通常在主机环境执行多数的测试（即Host/Host），只是在最终确定测试结果和最后的系统测试才移植到目标环境，这样可以避免发生访问目标系统资源上的瓶颈，也可以减少在昂贵资源如在线仿真器上的费用。另外，若目标系统的硬件由于某种原因而不能使用时，最后的确认测试可以推迟直到目标硬件可用，这为嵌入式软件的开发测试提供了弹性。设计软件的可移植性是成功进行Host/Target的先决条件，它通常可以提高软件的质量，并且对软件的维护大有益处。有效采用Host/Target 测试策略可极大地提高嵌入式软件开发测试的水平和效率，提高嵌入式软件的质量。
当在真实运行环境下进行测试是不可能的时候，仿真便成了一种有效的建立运行环境的手段。软件驱动的仿真器是用来替代真实的运行环境，能提供真实运行环境中的各种功能模拟。而在仿真器中运行的软件不会受到真实环境下的一些干扰。由于仿真器是用于观察软件的运行状况，不是测量运行性能，所以不需要精确的性能测量。实际上，真实环境下的随机性引起的性能变化要大于精确的性能测量和在仿真器上的类似的性能测量的不同，因此，仿真器能很好地工作，为软件测试提供运行模拟。
嵌入式软件的专用性决定了其测试需要专用的测试环境。测试环境可分为宿主机软件仿真、在线仿真器（In Circuit Emulator）、目标机仿真。由于受测试成本、效率、测试自动化程度和目标机的可用性等因素影响，这三种测试环境都各有利弊。
宿主机软件仿真是用软件构造一个嵌入式应用程序运行所需的仿真环境，能模拟执行目标机CPU 的指令，还能模拟中断、I/O 命令等外部消息。这种仿真方式需要对处理器有良好的定义，可仿真总线模型及处理器与外部设备的交互。其优点是无须目标机硬件便可测试，灵活、方便；用软件仿真的手段可分清软、硬件各自的错误；可对测试过程编程；自动化程度较高；降低开发成本。但也有不足，首先实时性受限，无法模拟真实硬设备之间的高速通信，此种仿真环境适用于软实时或无实时性要求的嵌入式系统。其次，由于宿主机的操作系统运行着大量的进程，可能对仿真环境造成干扰，如何排除干扰是一个不能忽视的问题。
在线仿真器（ICE）是一种专用设备，配有专用于特定CPU 芯片的接头。它能提供与应用程序交互的软信道或硬信道，有的ICE 还有与外设接口的信道。其不足是硬件性能受成本限制，硬件依赖性强，测试范围受限。
目标机仿真提供应用程序实际的运行环境，测试结果真实。但要受到目标机的硬件限制，难以区分软件和硬件的错误。
在实际测试工作中，应综合考虑成本、测试类型、测试可靠性以及项目进度等因素选择测试环境。一般而言，ICE 较多用于程序开发和调式阶段，测试可先在宿主机上充分完成后，再在目标机环境下确认测试。
2.3嵌入式软件测试工具
用于辅助嵌入式软件测试的工具很多，下面对几类比较有用的有关嵌入式软件的测试工具加以介绍和分析。
1.内存分析工具
在嵌入式系统中，内存约束通常是有限的。内存分析工具用来处理在动态内存分配中存在的缺陷。当动态内存被错误地分配后，通常难以再现，可能导致的失效难以追踪，使用内存分析工具可以避免这类缺陷进入功能测试阶段。目前有两类内存分析工具——软件和硬件的。基于软件的内存分析工具可能会对代码的性能造成很大影响，从而严重影响实时操作；基于硬件的内存分析工具价格昂贵，而且只能在工具所限定的运行环境中使用。
2.性能分析工具
在嵌入式系统中，程序的性能通常是非常重要的。经常会有这样的要求，在特定时间内处理一个中断，或生成具有特定定时要求的一帧。开发人面临的问题是决定应该对哪一部分代码进行优化来改进性能，常常会花大量的时间去优化那些对性能没有任何影响的代码。性能分析工具会提供有关的数据，说明执行时间是如何消耗的，是什么时候消耗的，以及每个例程所用的时间。根据这些数据，确定哪些例程消耗部分执行时间，从而可以决定如何优化软件，获得更好的时间性能。对于大多数应用来说，大部分执行时间用在相对少量的代码上，费时的代码估计占所有软件总量的5%-20%。性能分析工具不仅能指出哪些例程花费时间，而且与调试工具联合使用可以引导开发人员查看需要优化的特定函数，性能分析工具还可以引导开发人员发现在系统调用中存在的错误以及程序结构上的缺陷。
3. GUI测试工具
很多嵌入式应用带有某种形式的图形用户界面进行交互，有些系统性能测试足根掘用户输入响应时间进行的。GUI测试工具可以作为脚本工具有开发环境中运行测试用例，其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程。很多嵌入式设备没有GUI，但常常可以对嵌入式设备进行插装来运行GUI测试脚本，虽然这种方式可能要求对被测代码进行更改，但是节省了功能测试和回归测试的时间。
4.覆盖分析工具
在进行白盒测试时，可以使用代码覆盖分析工具追踪哪些代码被执行过。分析过程可以通过插装来完成，插装可以是在测试环境中嵌入硬件，也可以是在可执行代码中加入软件，也可以是二者相结合。测试人员对结果数据加以总结，确定哪些代码被执行过，哪些代码被巡漏了。覆盖分析工具一般会提供有关功能覆盖、分支覆盖、条件覆盖的信息。对于嵌入式软件来说，代码覆盖分析工具可能侵入代码的执行，影响实时代码的运行过程。基于硬件的代码覆盖分析工具的侵入程度要小一些，但是价格一般比较昂贵，而且限制被测代码的数量。
2.4嵌入式软件测试的内容
嵌入式软件测试的内容主要为：软件代码测试、编程规范标准符合性测试、代码编码规范符合性测试、开发维护文档规范符合性测试、用户文档测试。
其中软件测试服务范围包括：系统级测试、应用测试、中间件测试、BSP及驱动程序测试、嵌入式硬件设计测试。
其中，按照嵌入式软件有无操作系统将嵌入式系统分为两大类：无操作系统的嵌入式软件、有操作系统的嵌入式软件。
1.无操作系统的嵌入式软件
无操作系统的嵌入式软件主要包括C语言代码、汇编语言代码、Apa代码等。
C语言模式软件测试：硬件设备及其他宏定义（编译阶段处理）、API函数测试、模块初始化（包括系统初始化）、中间功能件测试、功能模块测试、中断处理测试、任务调度测试、区域功能测试、总体功能测试。
汇编语言模式软件测试：硬件设备及其他宏定义（编译阶段处理）、模块初始化（包括系统初始化）、中间功能件测试、功能模块测试、中断处理测试、区域功能测试、总体功能测试。
2.基于操作系统的嵌入式软件
基于操作系统的嵌入式软件主要包括应用软件测试、系统软件测试、整体性能测试。
应用软件测试：模块初始化（包括系统初始化）、中间功能件测试、功能模块测试、区域功能测试、总体功能测试。
系统软件测试：硬件设备及其他宏定义（编译阶段处理）、API函数测试、模块初始化（包括系统初始化）、中间功能件测试、功能模块测试、中断处理测试、区域功能测试、总体功能测试、标准符合性测试。
其中，操作系统的标准符合性测试的标准依据主要包括：
IEEE POSIX 1003.1-1990 （VSX4-PSE）
IEEE POSIX 1003.1b-1993/1003.1i-1995 Realtime extension （VSRT-PSE）
IEEE Std POSIX 1003.1c-1995 Threads （pthreads）extension （VSTH-PSE）
IEEE POSIX 1003.13-1998 Profile 52 （VSPSE52）
VSPSE52：2003 - A conformance test suite for IEEE Std 1003.13-2003 Profile PSE52
整体性能测试：基于操作系统之上的嵌入式系统整体软件测试，主要采用应用软件测试，着重分析性能、内存分配、代码覆盖率、软件执行流程，并采用仿真器、逻辑分析仪的硬件测试工具进行整体性能的测试。
2.5嵌入式软件测试的重点
1.测试用例和测试例程的良好设计。测试用例及测试例程的设计是整个嵌入式软件测试工作的核心。测试用例反映对被测对象的质量要求，决定对测试对象的质量评估。
2.测试工作的管理。尤其是对包含多个子系统的大型软件系统，其测试工作涉及大量人力和物力，有效的测试工作管理是保证有效测试工作的必要前提。
3.测试环境的建立。嵌入式软件测试的工作量很大，重复/繁杂的劳动很多，在有限的测试条件下，建立测试环境、提供测试辅助工具是减少软件研制费用的重要措施。
2.6嵌入式软件测试的策略
任何人或组织进行嵌入式软件的测试都应深入考虑以上问题，结合自身实际情况，选定合理测试策略和方案。对于嵌入式软件测试或叫交叉测试(cross-test)，在测试的各个阶段有着通用的策略:
1.单元测试:
所有单元级测试都可以在主机环境上进行，除非少数情况，特别具体指定了单元测试直接在目标环境进行。最大化在主机环境进行软件测试的比例，通过尽能小的目标单元访问所有目标指定的界面。在主机平台上运行测试速度比在目标平台上快的多，当在主机平台完成测试，可以在目标环境上重复作一个简单的确认测试，确认测试结果在主机和目标机上没有被他们的不同影响。在目标环境上进行确认测试将确定一些未知的，未预料到的，未说明的主机与目标机的不同。例如，目标编译器可能有bug，但在主机编译器上没有。
2.集成测试:
软件集成也可在主机环境上完成，在主机平台上模拟目标环境运行，当然在目标环境上重复测试也是必须的，在此级别上的确认测试将确定一些环境上的问题，比如内存定位和分配上的一些错误。在主机环境上的集成测试的使用，依赖于目标系统的具体功能有多少。有些嵌入式系统与目标环境藕合的非常紧密，若在主机环境做集成是不切实际的。一个大型软件的开发可以分几个级别的集成。低级别的软件集成在主机平台上完成有很大优势，越往后的集成越依赖于目标环境。
3.系统测试和确认测试
所有的系统测试和确认测试必须在目标环境下执行。当然在主机上开发和执行系统测试，然后移植到目标环境重复执行是很方便的。对目标系统的依赖性会妨碍将主机环境上的系统测试移植到目标系统上，况且只有少数开发者会卷入系统测试，所以有时放弃在主机环境上执行系统测试可能更方便。确认测试最终的实施舞台必须在目标环境中，系统的确认必须在真实系统之下测试，而不能在主机环境下模拟。这关系到嵌入式软件的最终使用。包括恢复测试、安全测试、强度测试、性能测试等。
使用有效的cross-test测试策略可极大的提高嵌入式软件开发测试的水平和效率，当然正确的测试工具使用也是必不可少的:
总结一下，应用以上测试工具进行cross-test时的策略:
A)使用测试工具的插装功能(主机环境)执行静态测试分析，并且为动态覆盖测试准备好一插装好的软件代码。
B)使用源码在主机环境执行功能测试，修正软件的错误和测试脚本中的错误。
C)使用插装后的软件代码执行覆盖率测试，添加测试用例或修正软件的错误，保证达到所要求的覆盖率目标。
D)在目标环境下重复(B)，确认软件在目标环境中执行测试的正确性。
E)若测试需要达到极端的完整性，最好在目标系统上重复(C)，确定软件的覆盖率没有改变。
通常在主机环境执行多数的测试，只是在最终确定测试结果和最后的系统测试才移植到目标环境，这样可以避免发生访问目标系统资源上的瓶颈，也可以减少在昂贵资源如在线仿真器上的费用。另外，若目标系统的硬件由于某种原因而不能使用时，最后的确认测试可以推迟直到目标硬件可用，这为嵌入式软件的开发测试提供了弹性。设计软件的可移植性是成功进行cross-test的先决条件，它通常可以提高软件的质量，并且对软件的维护大有益处。以上所提到的测试工具，都可以通过各自的方式提供测试在主机与目标之间的移植，从而使嵌入式软件的测试得以方便的执行。使用有效的cross-test测试策略可极大的提高嵌入式软件开发测试的水平和效率，提高嵌入式软件的质量。
2.7国内外的嵌入式测试服务
嵌入式软件测试要提供嵌入式软件及硬件的端到端测试服务，横跨工具/设备、实时操作系统（RTOS）、开发平台和编程语言。服务内容包括嵌入式软件和硬件的测试策略和代码级测试，以及覆盖分析，功能测试，压力测试，代码审查，调试和代码维护。测试服务覆盖从设备驱动，中间件/协议和系统及应用水平测试。主要解决如通信、汽车电子行业、消费电子及多媒体、工业自动化、网络、存储、计算机硬件和外设的嵌入式系统测试。
1.国外嵌入式软件测试服务
国外的嵌入式软件测试服务有：黑盒测试、功能测试、单元测试、回归测试、配置测试、压力测试、UI测试、安装测试、模块化测试、集成测试、手动黑盒测试、负载测试、验收测试。
提供给用户的测试结果主要为：测试规划、测试用例、验收测试用例、用户手册、缺陷报告、改进建议等。
2.国内嵌入式软件测试服务
国内的嵌入式软件测试服务还处于起步阶段，并且主要限于嵌入式应用软件、工业控制软件，测试的主要内容包括：
1）功能测试
依据ISO/IEC 9126-1 质量模型，验证系统是否满足明确和隐含要求功能。功能测试覆盖实用性、准确性、互操作性、互用性、保密安全性、功能依从性。
2）可靠性测试
依据ISO/IEC 9126-1 质量模型，测试在指定条件使用时，软件产品维持规定的性能级别的能力。可靠性测试覆盖成熟性、容错性、易恢复性等质量特性。
3）性能测试
依据ISO/IEC 9126-2 质量模型，检测在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐量的能力以及使用合适的数量和类型的资源的能力。
4）安全性测试
依据ISO/IEC 9126-3 质量模型，测试在指定条件使用时，软件产品维持规定的性能级别的能力。可靠性测试覆盖成熟性、容错性、易恢复性等质量特性。
5）易用性测试
依据ISO/IEC 9126-4 质量模型，测试在指定条件使用时，软件产品被理解、学习、使用和吸引用户的能力。测试覆盖易理解性、易学性、易操作性、吸引性。
6）可移植性测试
依据ISO/IEC 9126-5 质量模型，测试软件产品从一种环境迁移到另外一种环境的能力，测试覆盖适应性。
三、总结
测试是用来保证软件开发过程的高效性，以及保证开发出来的软件产品的高质量和可用性的。软件开发本身就是一件非常困难的事情，这也决定了有效的测试决不是简单地依靠一些测试工具就可以进行的。在使用工具的同时，我们更要加强关于测试的培训、教育，使大家对于测试首先有一个正确的认识。只有这样，我们才能够更加有效、高效的使用工具，才能够使测试真正起到它应有的作用。
目前，随着嵌入式软件越来越多的出现在人类生活的各个角落，嵌入式系统的地位日益增长，对嵌入式软件测试的研究也势在必行。作为软件测试的一种，嵌入式软件测试具有软件测试的通性，大多数软件测试的理论和方法都适用于嵌入式软件的测试。但是，由于嵌入式系统的实时性和嵌入式特点，使得嵌入式软件测试有其独特性，嵌入式软件测试有两种测试模型:基于目标机的测试和基于宿主机的测试。基于宿主的测试代价较小，但毕竟是在模拟环境中进行的，目标环境的复杂性和独特性不可能完全模拟;而基于目标的测试则消耗较多的经费和时间。因此，我们常常需要在这两种测试模型中做出折衷。
嵌入式软件测试和其他软件测试相比，被测的软件代码量更少，但是测试环境更为复杂。尤其是在目前还没有一个明确的测试标准和规范的情况下，要想更好的完成嵌入式软件的测试，只有针对不同的项目制定不同的测试方案。我们需要根据自己测试内容、测试目标
和测试环境(包括人力、物力、时间、设备等)选择不同的测试策略、测试方法、构造合理的测试用例。
本论文已经总结了一些嵌入式软件的测试方法、分析了嵌入式软件测试的策略、介绍了一些相关测试工具的知识。但是为了能够满足嵌入式软件的高可靠性，仍有很多进一步的工作需要做。
参考文献：
[1] McDonald J., Murray L., Lindsay P., Strooper P. Module testing embedded software-an industrial pilot project. Engineering of Complex Computer Systems, 2001. Proceedings.Seventh IEEE International Conference on ,11-13 June 2000
[2] Zhu H, Hall P, May J. Software unit test coverage and adequacy. ACM Computing Surveys, 1997,
29(4): 366~427
[3] 郑人杰，计算机软件测试技术，北京：清华大学出版社，1992
[4] 孙昌爱，靳若明，刘超，等实时嵌入式软件的测试技术[J]，小型微型计算机系统，第21 卷第9 期2000.9 920-924
[5] 邓世伟. 嵌入式软件的测试方法和工具单片机与嵌入式系统应用2001, 4 ,0026-03
[6] 刘斌，高小鹏，陆民燕，等嵌入式软件可靠性仿真测试系统研究北航学报, 2000, 26(4): 0490-04