基于模块化设计的嵌入式软件测试方法

下面是小编给大家带来的基于模块化设计的嵌入式软件测试方法，本文共7篇，以供大家参考，我们一起来看看吧!本文原稿由网友“加热栗色”提供。

篇1：基于模块化设计的嵌入式软件测试方法

摘要：分析嵌入式软件的特点，综述传统的软件测试方法；针对嵌入式软件的特点，提出嵌入式软件的四级测试流程和集成测试的测试模型，并结合开发数控系统的实例进行分析。

关键词：模块化设计 嵌入式软件 软件测试 测试方法 测试模型 数控系统

嵌入式设计已经成为工业现代化、智能化的必经之路，嵌入式产品已经深入到各行各业。嵌入式系统的专用程度较高，系统的整体继承性相对较小，为了保证系统的稳定性，软件的测试成为嵌入式开发的一个重要环节。由于嵌入式软件自身的特点，传统的软件测试理论不能直接用于嵌入式软件的测试，因此，研究嵌入式软件的测试有重要意义。

1 基本概念简述

1．1 模块化设计

(本网网收集整理)

软件的设计是以一定的方法为基础的。面对越来越复杂的软件开发任务，人们提出了各种软件设计的模型。从用户需求和系统要实现的任务功能出发，把大型的软件划分为相对较小的模块。为了减少模块与模块之间的关联性，模块之间的逻辑结构相对独立，无函数的交叉调用，数据传递由全局变量完成，这就是模块化设计的基本思想。模块化设计的核心是模块的独立性，主要包括功能独立性和结构独立性，这使得软件开发的分工易于实现。软件测试是软件开发中的关键环节，基于模块化设计的软件测试模型简单，查错和纠错都易于实现。下面以单链路数据传递的软件模型说明模块化软件设计的软件测试的基本原则。

在图1中，函数F（X－Y）定义为软件模块X到软件模块Y的接口函数，用来通过终端显示由模块X进入模块Y的数据。如果模块C执行后发生错误，则由模块B和模块C的数据接口函数F（B－C）判断是否是模块B出来的数据就是错误的。如果F（B－C）不错，则证明模块C存在错误；如果F（B－C）传递数据错误，再察看F（A－B）传出的数据是否错误，如果不错则证明模块B存在错误。用此依次前推孤立错误的方法，即可以很容易地定位错误所在的模块。这就是模块化设计时软件测试的基本原则。

1．2 嵌入式系统

嵌入式系统开发有其自身的特点。一般先进行硬件部分的开发，主要包括形成裸机平台，根据需要移植实时操作系统，开发底层的硬件驱动程序等。硬件平台测试通过后，应该软件的开发调试是基于该硬件平台进行的，这同时也是对硬件平台的一个测试。整个嵌入式系统开发流程如图2所示。因此可以说，嵌入式系统的开发过程是一个软硬件互相协调，互相反馈和互相测试的过程。一般来说，在嵌入式系统软件中，底层驱动程序、操作系统和应用程序的界线是不清晰的，根据需要甚至混编在一起。这主要是由于嵌入式系统中软件对硬件的依赖性造成的。嵌入式软件对硬件的依赖性要求，软件测试时必须最大限度地模拟被测软件的实际运行环境，以保证测试的可靠性。底层程序和应用程序界限的不清晰增加了测试时的难度，测试时只有确认嵌入式系统平台及底层程序正确的情况下才能进行应用程序的测试，而且在系统测试时，错误的定位较为困难。软件的专用性也是嵌入式软件的一个重要特点。由于嵌入式软件设计是以一定的目标硬件平台为基础的、面向固定的任务进行的，因此，一旦被加载到目标系统上，功能必须完全确定。这个特点决定了嵌入式应用软件的继承性较差，延长的系统的测试时间，增加了测试费用。嵌入式软件的另外一个重要特点就是实时性。这是从软件的执行角度出发说明的，也就是说嵌入式软件的执行要满足一定的时间约束。嵌入式系统中，应用软件自身算法的复杂度和操作系统任务调度，决定了系统资源的分配和消耗，因此，对系统实时性进行测试时，要借助一定的测试工具对应用程序算法复杂度和操作系统任务调度进行分析测试。可见嵌入式软件与传统的面向对象和面向过程的软件相比有其自身的特点。针对这些特点对嵌入式软件的测试进行研究是必要的，有意义的。

1．3 嵌入式软件测试

软件测试是从经济、效率的角度出发，对软件代码进行质量、正确性保证的一个过程。软件测试是软件开发中的一个重要环节，也是软件从开发过程到应用过程的关键一环。嵌入式软件也不例外，图3给出了嵌入式软件测试的统一测试模型。软件测试逐渐成为一门成熟的学科，前人针对面向对象和面向过程的非实时软件的测试作了大量的研究，其中大部分方法可以用到嵌入式软件的测试。

根据不同的指标，软件测试方法有不同的划分方法。从软件开发过程中测试所处的不同阶段可分为模块测试、集成测试和系统测试。根据是否需要运行目标代码分为动态测试和静态测试；根据目标代码的可见性可分为白盒测试（结构测试）和黑盒测试（功能测试）。在软件的.测试中，每种测试方法都不是孤立的。为了最经济最有效地达到测试的目的，各种测试方法往往是互相嵌套的。例如，在软件的单元测试

阶段，可以用黑盒测试和白盒测试的方法分别进行动态测试。

值得一提的是，近年来软件测试中，测试代码的覆盖率逐渐成为软件测试的统一标准，因此不管采用何种测试方法，尽可能地提高软件测试中的代码覆盖率是必需的。软件测试代码覆盖率是基于白盒测试方法的，因此，为了提高软件测试的代码覆盖率，测试人员必须清楚源代码的结构，拥有程序设计文档，以便设计测试用例使测试尽可能地覆盖程序内部结构的每条语句，提高代码的覆盖率。

篇2：基于模块化设计的嵌入式软件测试方法

根据嵌入式系统的开发流程，为了最经济地实现系统的功能，采用自顶向下、层层推进的方法对嵌入式系统进行测试，提出了如图4所示的基于模块化设计的嵌入式软件四级测试流程。在四级测试中，本测试阶段以前的测试完成后，当发现错误时，可排队此测试阶段以前的错误，在本测试阶段内查找错误。这并不是一个绝对准确的方法，但最大限度地节了错误定位的时间。

2．1 系统平台测试

这部分包括硬件电路测试、操作系统及底层驱动程序的测试等。硬件电路的测试需要用专门的测试工具进行测试。这里不再多述。操作系统和底层驱动程序的测试主要包括测试操作系统的任务调度、实时性能、通信端口的数据传输率。该阶段测试完成后，系统应为一个完整的嵌入式系统平台，用户只需添加应用程序即可完成特定的任务。

2．2 模块测试

把大型的嵌入式软件系统划分为若干个相对较小的任务模块，由不同的程序员分别同时对其进行编码。编码完成后，把各个模块集成起来前，必须对单个模块进行测试。由于没有其它数据模块进行数据传递的支持，该阶段测试一段是在宿主机上进行的（宿主机有丰富的资源和方便的调试环境）。此阶段主要是进行白盒测试，尽可能地测试每一个函数、每一个条件分支、每一个程序语句，提高代码测试的覆盖率。由于只有单个模块正确才有整体集成的必要性，因此，单个模块测试时测试一定要充分、完整。模块测试阶段，测试用例的构造不但要测试系统正常的运行情况，还要进行边界测试。边界测试就是进行某一数据变量的最大值和最小值的测试，同时进行越界测试，即输入不该输入的数据变量测试系统的运行情况。理想的嵌入式系统是不应该由用户的信息交互导致死机的，这也是嵌入式设计的一个基本要求。因此，不论进行何种测试，系统死机都该被作为测试错误处理。在模块测试阶段，由模块化编程的基本思想，根据模块内部的紧凑程序，也可以把大的模块划分成小的模块。在程序内部，小模块之间数据传递的入口设计接口函数，用于快速地定位错误。用此模块嵌套的思想进行软件测试，需要模块内部结构清晰，数据链路简单。

2．3 集成测试

单个软件模块测试正确之后，将所有模块集成起来进行测试。本阶段主要是找出各模块之间数据传递和系统组成后的逻辑结构的错误。在宿主机上采用黑盒与白盒相结合的方法进行测试，要最大限度地模拟实际运行环境，可以屏蔽掉一些不影响系统执行的和数据传递的难以模拟的函数。集成测试是模块化设计软件的测试优点充分体现的阶段。集成测试前，应该由程序员根据模块之间的数据的输入输出编写模块接口函数，这需要负责不同软件模块的程序员共同协调完成，然后将模块接口函数集成到接收数据模块的入口处。由前面的分析可知，单链路数据传递的软件模块集成测试时容易定位错误所在的软件模块。一个软件模块的数据不一定只有另外一个模块提供，即软件模块的数据链路不一定只是单链路的，测试时可以把复杂链路结构的数据传递划分为单链路结构数据传送进行错误定位。修改输出数据的软件模块时，可能导致输入数据的软件模块引入新的错误，因此在这里引入关联矩阵确定修改某一模块后需要重要测试的模块。

假定模块化设计的嵌入式系统软件由软件模块Ai(i=1,2,…，m,n)组成，m表示矩阵的行号，n表示矩阵的列号。图5所示的矩阵即为其关联矩阵。

在关联矩阵中，Aij=1表示Aj接受了Ai输出的数据，故修改了Ai重新测试Ai的同时也需重新测试Aj。

集成测试是在拥有程序设计文档、程序结构和数据结构时，对软件模块在集成中出现的错误进行测试。集成测试时，根据模块接口函数定位错误修改代码，根据关联矩阵确定重新测试的软件模块。图6给出了模块化设计的嵌入式软件集成测试模型。

2．4 系统测试

集成测试完成后，退出宿主机测试环境，把系统移植到目标机上来，完成应用到现场环境中，从用户的角度对系统进行黑盒测试，验证每一项具体的功能。由于测试者对程序内容程序执行情况一无所知，因此本测试阶段的错误定位比较困难。系统测试阶段应该进行意外测试和破坏性测试，即测试系统正常执行情况下不该发生的激发活动和人为的破坏性的测试，进一步验证系统性能。系统测试阶段不应该确定错误后立即修改代码，应根据一定的错误

发生频率，确定测试周期，在每个测试周期结束时修改代码，进行反复测试；否则，不但增加了完全测试的任务量，而且降低了测试的可信度。

2．5 测试结果分析

测试结果的分析可以定位错误，指导程序员修改代码，同时指出测试进行的程序并进一步指明测试方向。测试结果的分析是一个由测试结果和测试预得结果进行分析、比较和定位错误的过程。测试结果的分析是一次测试的最后环节，分析时应该考虑软件的运行环境和实际运行环境的差异以及各种外界因素的影响等。

2．6 测试用例的构造与管理

测试用例是为了测试目标程序设计的包括输入项和预得结果的一种文件，根据测试环境和测试目标程序的不同，可分为某种格式的文档或某种输入行为（如一次按键）等。测试用例的构造要尽可能覆盖所有可能的取值范围，使测试尽可能地覆盖所有程序代码，提高代码的测试覆盖率，同时又不作多余、重复和无意义的测试。在嵌入式软件测试的不同阶段，要构造不同的测试用例；在系统平台测试阶段，要构造针对系统任务调度、实时性能和底层驱动程序的测试用例；在模块测试阶段，应构造针对某一模块进行测试的测试用例；在集成测试阶段，针对系统集成时数据传递、结构斜接的问题构造相应的测试用例；在系统测试阶段，要构造针对某项功能的或多项功能结合在一起的测试用例，或使用已经在同类产品上已经验证正确的测试用例。测试用例是可复用的。此外大型的软件开发过程中，测试用例的种类繁多，应该按一定的方法进行管理。用数据库的来管理测试用例是一个很好的选择。根据测试阶段将测试用例进行划分，然后用关键字唯一确定。这样在使用、修改和保存测试用例时都很方便，直接用查询的方式就可以调出测试用例。

3 数控系统软件测试

本数控系统采用ARM7处理器，操作系统采用μC／OS实时操作系统，是一个典型的嵌入式系统。由于数控系统较为复杂，开发过程中将任务进行了详细的划分，软件的开发采用模块化开发。模块的划分及数据流向如图7所示。

根据图7所示的软件模块和数据流向可构造关联矩阵，如图8所示。

开发过程中，几个模块由不同的程序员分别进行编码，分别由程序员进行模块测试，并按白盒测试的方法进行覆盖测试。最后集成测试前，根据关联矩阵，程序员协作编写了模块接口函数F（A1-A2）、F（A1－A4）、F（A1－A5）、F（A1－A6）、F（F2－A3）、F（A3－A4）、F（A4－A5）、F（F5－A6）、F（A6－A2），然后根据图6所示的测试模型和图8所示的关联矩阵对系统进行了集成测试。分析可知，一些关键模块，如译码模块和刀补模块的测试代码覆盖率达到90％之上。图9所示的整个系统经过系统测试之后性能稳定，图10为其加工的零件，目前该系统已经小批量生产。

4 结论

文章对嵌入式软件的特点和传统的测试方法作了分析之后，提出了四级测试流程和集成测试的模型。此测试方法用于工程机械控制器和数控系统开发的测试。测试的效率和可靠性满足要求。文中的单链路数据传递的错误定位、模块接口函数、关联矩阵等方法也可以用于面向对象的和面向对象的软件系统。

篇3：基于模块化设计的嵌入式软件测试方法

基于模块化设计的嵌入式软件测试方法

关键词：模块化设计 嵌入式软件 软件测试 测试方法 测试模型 数控系统

嵌入式设计已经成为工业现代化、智能化的必经之路，嵌入式产品已经深入到各行各业。嵌入式系统的专用程度较高，系统的整体继承性相对较小，为了保证系统的稳定性，软件的测试成为嵌入式开发的一个重要环节。由于嵌入式软件自身的特点，传统的软件测试理论不能直接用于嵌入式软件的测试，因此，研究嵌入式软件的测试有重要意义。

1 基本概念简述

1．1 模块化设计

软件的设计是以一定的方法为基础的。面对越来越复杂的软件开发任务，人们提出了各种软件设计的模型。从用户需求和系统要实现的任务功能出发，把大型的软件划分为相对较小的模块。为了减少模块与模块之间的关联性，模块之间的逻辑结构相对独立，无函数的交叉调用，数据传递由全局变量完成，这就是模块化设计的基本思想。模块化设计的核心是模块的独立性，主要包括功能独立性和结构独立性，这使得软件开发的分工易于实现。软件测试是软件开发中的关键环节，基于模块化设计的软件测试模型简单，查错和纠错都易于实现。下面以单链路数据传递的软件模型说明模块化软件设计的软件测试的基本原则。

在图1中，函数F（X－Y）定义为软件模块X到软件模块Y的接口函数，用来通过终端显示由模块X进入模块Y的数据。如果模块C执行后发生错误，则由模块B和模块C的数据接口函数F（B－C）判断是否是模块B出来的数据就是错误的。如果F（B－C）不错，则证明模块C存在错误；如果F（B－C）传递数据错误，再察看F（A－B）传出的数据是否错误，如果不错则证明模块B存在错误。用此依次前推孤立错误的方法，即可以很容易地定位错误所在的模块。这就是模块化设计时软件测试的基本原则。

1．2 嵌入式系统

嵌入式系统开发有其自身的特点。一般先进行硬件部分的开发，主要包括形成裸机平台，根据需要移植实时操作系统，开发底层的硬件驱动程序等。硬件平台测试通过后，应该软件的开发调试是基于该硬件平台进行的，这同时也是对硬件平台的一个测试。整个嵌入式系统开发流程如图2所示。因此可以说，嵌入式系统的开发过程是一个软硬件互相协调，互相反馈和互相测试的过程。一般来说，在嵌入式系统软件中，底层驱动程序、操作系统和应用程序的界线是不清晰的，根据需要甚至混编在一起。这主要是由于嵌入式系统中软件对硬件的依赖性造成的。嵌入式软件对硬件的依赖性要求，软件测试时必须最大限度地模拟被测软件的实际运行环境，以保证测试的可靠性。底层程序和应用程序界限的不清晰增加了测试时的难度，测试时只有确认嵌入式系统平台及底层程序正确的情况下才能进行应用程序的`测试，而且在系统测试时，错误的定位较为困难。软件的专用性也是嵌入式软件的一个重要特点。由于嵌入式软件设计是以一定的目标硬件平台为基础的、面向固定的任务进行的，因此，一旦被加载到目标系统上，功能必须完全确定。这个特点决定了嵌入式应用软件的继承性较差，延长的系统的测试时间，增加了测试费用。嵌入式软件的另外一个重要特点就是实时性。这是从软件的执行角度出发说明的，也就是说嵌入式软件的执行要满足一定的时间约束。嵌入式系统中，应用软件自身算法的复杂度和操作系统任务调度，决定了系统资源的分配和消耗，因此，对系统实时

[1] [2] [3] [4]

篇4：嵌入式软件的覆盖测试

覆盖是一种白盒测试方法，测试人员必须拥有程序的规格说明和程序清单，以程序的内部结构为基础，来设计测试案例。其基本准则是则测试案例来尽可能多地覆盖程序的内部逻辑结构，发现其中的错误和问题。所以，覆盖测试一般应用在软件测试的早期，即单元测试阶段。

覆盖的几种方法或策略如表1所列。

表1几种典型的覆盖策略

覆盖策略定义语句覆盖在制定测试案例时，使程序中的每个语句都至少执行1次。其缺点是不能发现某些逻辑错误判定覆盖执行足够的测试案例，使得程序中每个判定都获得一次“真”值和“假”值，或者说使每一个分支都至少通过1次条件覆盖执行足够的测试案例，使得判定中的每个条件获得各种可能的结果判定/条件覆盖执行足够的测试案例，使得判定中的每个条件取得各种可能的值，并使得每个判定取得各种可能的结果条件组合覆盖执行足够的测试案例，使得每个判定中的条件的各种组合都至少出现1次。其特点是覆盖较充分，满足条件组合覆盖的测试案例也一定满足判定覆盖、条件覆盖和判定/条件覆盖。

从以上简要介绍可看出，这几种覆盖策略的严格程序有如下趋势：

其它一些覆盖策略还包括：修改的条件/判断覆盖（通常简称为MCDC）、路径覆盖、函数覆盖、调用覆盖、线性代码顺序和跳转覆盖、数据流覆盖、目标代码分支覆盖、循环覆盖、关系操作符覆盖等。随着软件规模的增长，实现全面的覆盖所需的测试案例的数目也越来越庞大，因此根据被测软件对象的特点选择适当的覆盖策略是非常重要的；同时，要确定合理测试目标，达到100%的覆盖往往要付出很大的代价，应该同形式化评审等方法结合，以发现更多的软件故障。

3覆盖测试工具

要取得较好的覆盖测试效果，需要借助一定的工具软件。这些工具软件一般具备如下的功能特点，可弥补人为测试的缺陷：

①分析软件内部结构，帮助制定覆盖策略及设计测试案例；

②与适当的编译器结合，对被测软件实施自动插装，以便在其运行过程中生成覆盖信息并收集这些信息；

③根据搜集的覆盖信息计算覆盖率，帮助测试人员找到未被覆盖的软件部位，以改进测试案例提高覆盖率。

在利用工具进行动态覆盖测试时，需要3个要素：测试用例、插装过的被测代码、搜集覆盖信息并进行分析的工具本身。代码插装由工具自动完成，通过执行测试用例，再由工具搜集覆盖信息并进行分析，就可以看到覆盖率指标了。图1展示实现覆盖测试的基本过程。

篇5：嵌入式软件的覆盖测试

在目标机方，插装过的被测应用程序将覆盖信息发送到消息队列中，一个专门的任务负责在适当的时候将这些信息发送到宿主机方。缩主机方有专门的模块负责接收覆盖信息。并交给分析工具分析和在线动态显示覆盖率的增长情况。

支持嵌入式软件覆盖测试的工具应解决如下2方面的关键问题：

*与嵌入式操作系统的结合

覆盖测试工具与嵌入式操作系统的结合体现在3方面。首先，在目标机方，应用任务与专门负责收集/上传覆盖信息的任务是通过消息队列来传递数据的，该消息队列可使用嵌入式操作系统的相应机制实现。其次，这个专门任务也可以被看作一个特殊的应用任务，也必须有嵌入式操作系统的支持，因为任务管理是后者的基本功能之一。最后，目标机与宿主机之间的通信可以采用串口或以太网方式，对串口的驱动或网络协议均可使用嵌入式操作系统的相应程序组件。

*与其它嵌入式交叉开发工具的关系

嵌入式应用程序的开发通常采用交叉开发方式，几乎所有的开发工具均要解决3部分的问题：宿主机部分的功能、目标机部分的功能、宿主机与目标机的连接问题。其中，宿主机与目标机的连接是个瓶颈，如果不同的工具要使用同一物理线路实现数据传输，则要解决对该物理线路（或者说硬件端口）的正确共享。比如在图3所示的环境中，宿主机方的各种工具通过统一的接口――目标服务器（targetserver）实现对通信线路的访问，目标机方的调试代理（debugagent）则是各种信息（调试信息、覆盖信息、时间信息、对象信息等）的收集与传递的核心。

5Logiscope在嵌入式操作系统DeltaCORE测试中的应用

Logiscope是Verilog公司的CASE产品，对软件的编码、测试、维护提供多方面的服务，并且支持嵌入式软件的覆盖测试。

5.1测试前的准备

测试前的准备即为支持对DeltaCORE的测试所做的移植工作。

目前，Logiscope已经为一些成熟的商用嵌入式操作系统提供了支持，比如pSOS。DeltaCORE是我国自主开发的嵌入式强实时操作系统内核，为了利用Logiscope实现对DeltaCORE的应用程序乃至DeltaCORE本身的测试，我们主要解决了第4节中描述的第1个关键问题。

为了支持嵌入式程序的测试，Logiscope提供了运行在目标机方的程序代码（或称为目标机端的支持库），里面包含了：

*1个用来收集和发送覆盖信息的主循环线程，该线程即是嵌入式应用中的特殊任务；

*实现具体数据传输的函数，包括对串口或网络的驱动，它们将被上述线程调用；

*插装函数的实现，这些函数被被测代码调用，向缓冲中放入覆盖消息块；

*对缓冲信息队列的管理；

*初始化代码。

例如，当被测程序运行进入到一条if(……)语句时，整个过程如图4所示。

为了支持对DeltaCORE的测试，将与这些机制相关的代码进行移植，包括以下几方面：

*将收集和发送覆盖信息的主循环线程作为在目标机端运行的应用程序中的特殊任务；

*对串口的驱动采用LambdaTOOLBSP（板级支持包）中的串口驱动代替，对网络的驱动，用DeltaCORE的配套组件DeltaNET中的驱动程序实现；

*利用DeltaCORE的信箱机制实现消息队列的创建和管理，插装代码向这些信箱发送覆盖消息块；

*在DetaCORE应用程序的根任务中调用Logiscope的初始化函数，达到创建特殊任务信箱的目的。

开发DeltaCORE应用程序时，我们使用了其配套开发工具LambdaTOOL。由于所使用的工具版本没有实现目标服务器（targetserver）的调试方式，因此对物理端口的使用采用的独占方式，即调试工具不能与其它工具共享同一端口。我们可以用网络试上载并启动目标应用程序，而通过串口传送覆盖信息。

5.2对DeltaCORE的覆盖测试过程及结果

对于函数内部，Logiscope支持的覆盖策略有：

*指令块IBs(InstructionBlocks)

*判断到判断的路径DDPs(Decision-to-DecisionPaths)

*MCDC（ModifiedCondition/Decision）

在项目层次上支持的覆盖策略是：

*过程到过程路径PPP（Procedure-to-ProcedurePath）

在DeltaCORE的测试中，我们采用了较为常用的覆盖策略――判断到判断的路径，其含义是：DDP是一个指令序列，它的起点是函数或判断（if，while，……）的入口点，它的出口是下一个函数或判断的退出点，之间不能再有判断，比如在图5中包含了5个DDPs：

测试的具体过程是：

①利用插装分析器对DeltaCORE的源代码进行插装，并生成插装信息文件。

②将移植后的Logiscope目标机端程序与插装后的内核源代码一同编译链接成库，以替代原来的内核库，供应用程序使用。

③编写测试案例，从实现应用的角度使用DeltaCORE的各种系统功能调用，力求遍历内核函数所有的判定分支，并将这些案例编译成可执行程序。

④在宿主机端启动覆盖信息收集和分析程序，用LambdaTOOL的调试器下载并启动应用程序。DeltaCORE的覆盖信息被传递到宿主机上，分析程序动态显示覆盖率的增长情况，并将这些信息记录在一个文件中。

⑤应用程序执行完毕后，启动Logiscope的事后分析工具，将覆盖信息记录文件与插装信息文件（在源代码插装在生成的附属文件）进行比较，帮助测试人员清晰地了解每个被测函数内部的路径覆盖情况，借此可为测试案例的改进提供帮助。

⑥测试人员修改测试案例，并重新进行整个测试过程；各项测试的结果可以叠加，覆盖率将得到增长。

经过2个多月的时间，我们对DeltaCORE1.1版本79个文件共计115个函数进行了覆盖测试，覆盖率已经达到了70.55%。编写测试用例89个，主要的60个API函数均已获得较高的覆盖，覆盖率达100%的约占51.3%。

6小结

我们借助Logiscope工具对嵌入式实时操作系统DeltaCORE进行了覆盖测试，达到了较好的覆盖率；发现并处理了一些缺陷，提高了软件的质量和可靠性，但同时也存在不足之处：

①测试应好好规划，包括测试顺序的选择、测试案例的设计、测试文档的管理等等。

②由于该测试手段依赖于操作系统的有关机制，而被测对象又是操作系统本身，因此与这些机制有关的部分代码未被插装和测试，否则就会出错。比如，操作系统的初始化函数os_init，在这个函数运行完毕之前，操作系统的相应机制尚未建立起来，因此对它进行插装就会造成问题，不能正确地得到覆盖信息。又比如，出于效率方面的考虑，与系统时钟相关的部分函数未被插装，因为在程序运行过程中，时钟是最频繁产生的一种外部事件，如果插装，就会产生大量的覆盖信息，会对信息缓存、传递、收集和处理造成压力。另外，所用的工具不支持对汇编函数的插装和测试。综合上述各种原因，DeltaCORE1.1的总体覆盖率还显得比较低，需要采用其它的方法来提高它。对于非操作系统组件及应用的测试，由于不存在操作系统本身的问题，因此可望达到较高的覆盖率。

③该方法不能用于时间性能测试。因此它属于纯软件的测试方式，大量数据信息的产生、传递与收集对被测程序的干扰大，只能做白盒性的功能结构验证。如果做性能测试，应采用某些软硬结合方式的工具，比如CodeTEST。

对嵌入式软件产品的测试是多方面的，除覆盖测试外，还有时间性能测试、内存使用测试与分析等，也是我们研究的重要课题。

篇6：嵌入式软件的覆盖测试

嵌入式软件的开发与通用软件很大的`不同点在于，需要采用交叉开发的方式：开发工具运行在软硬件配置丰富的宿主机上，而嵌入式应用程序运行在软硬件资源相对缺乏的目标机上。对于这类软件的测试也存在着同样的问题：测试工具运行在宿主机上，测试所需要的信息在目标机上产生，并通过一定的物理/逻辑连接传输到缩主机上，由测试工具接收。因此，嵌入式软件测试的一个重要问题是建立宿主机与目标机之间的物理/逻辑连接，解决数据信息的传输问题。

篇7：嵌入式软件的覆盖测试

摘要：覆盖测试是验证软件功能结构正确性以及查找问题的非常重要的方法和手段，它要借助一定的工具才能取得较好的效果，满足软件在质量和时间上的双重要求（纯粹的人工测试工作量大、不方便、周期长）。如何利用好这方面比较成熟的工具，对其机理的研究及适应性改造是很重要。本文着重描述这类工具的工作机理，以及对嵌入式软件测试的特殊要求，并以对自主知识产权嵌入式操作系统的`测试为例进行说明。

关键词：嵌入式操作系统 覆盖测试 软件测试工具

1 概述

软件测试是很广的概念。从其贯穿软件生命周期全过程来看，测试可分为模块测试、集成测试、系统测试等阶段。测试还可分为静态检查和动态运行测试两大类。在动态运行测试中，又可有基于程序结构的白盒测试（或称为覆盖测试）和基于功能的黑盒测试。测试不仅关注程序的功能，还有性有测试、强度测试等等。

要达到比较好的测试效果，除了要有周全的测试计划、可控的测试过程、测试人员丰富的经验外，还需要借助一些行之有效的辅助工具，尤其在当今软件规模日益庞大、测试工作量成倍增加的情况下。对应上述的测试分类情况，测试工具可划分为：支持对程序源代码进行静态规则检查和质量评估的静态分析工具、支持对程序单元进行动态覆盖测试的工具、对软件系统的整体运行性能进行测试的工具。另外，还有一些特殊用途的或专用工具，如协议测试仪、内存检测工具等。这些工具都有较为成熟的商业化产品，也可通过自行开发的方式获得。

本文具体讨论了对一类特殊的系统软件――嵌入式实时操作系统――进行覆盖测试的情况。内容涉及对这类软件特性的研究、测试的难点和特点、对现有测试工具的适应性改造和测试实例说明。

软件正版化工作总结

软件正版化工作计划

软件测试工程师简历

软件测试与会计的前景

软件测试分析报告

基于模块化设计的嵌入式软件测试方法.doc

将本文的Word文档下载到电脑，方便收藏和打印

推荐度：

点击下载文档