嵌入式系统测试（精选11篇）
嵌入式系统测试 篇1
中断机制是嵌入式系统的重要组成部分,中断是指在程序执行过程中,遇到急需处理的某个事件时,暂时中止正在执行的程序,转而执行相应的事件处理程序,待事件处理完毕后,再返回断点处继续执行,或调度其他程序执行的过程。嵌入式软件的中断具有多种类型,从执行时间上划分包括偶发的和周期性的;从触发类型上划分包括内部中断和外部中断;从中断级别上划分包括高优先级中断和低优先级中断等。随着嵌入式系统在各领域的广泛应用,相应的软件也越来越复杂,随之带来中断系统的设计和使用的也日益复杂。与一般程序不同,中断处理程序的执行具有随机性和不确定性,因此相关软件中断部分的测试也比一般程序要复杂。中断问题比一般软件问题要更具有隐蔽性、偶发性。某些问题测试人员很难复进行复现,这给软件测试工作带来了很大的难度。本文从静态和动态两方面总结了嵌入式软件中断系统的测试技术,从而对提高相关软件的质量有所帮助。
1 静态测试技术
软件静态测试技术主要包括代码审查和静态分析。不同的芯片中断代码的设计也存在一定的差异,且中断处理代码存在的问题可能根据具体应用的不同而存在,因此静态分析工具一般不具备对中断代码存在问题的详细分析。因此对中断程序的静态测试技术主要还是采用代码审查方法进行。代码审查的要点主要包括以下几类。
1)中断资源冲突检查
中断资源使用冲突是中断使用中最有可能发生的问题。中断资源冲突检测主要对中断中使用的公共资源进行分析,包括全局变量、寄存器、缓存区域、标识等。检查的第一步是筛选出中断与主程序、中断与中断中均使用的公共资源。第二步是对这些资源的读写情况进行分析,每个资源在程序中的使用存在三种情况:只读、只写和读写,这三种情况在主程序、中断处理程序中都可能存在。通常,一个资源在中断和主程序或不同中断中均为只读,或者主程序只在中断未使能状态下对资源进行访问时,一般不存在冲突。而在主循环和中断中,或不同中断中进行了修改的资源则一般需要仔细分析冲突的可能。图1则描述了一个中断资源冲突案例。
图1 中中断程序用于接收数据,接收完成之后置接收标志。主程序用于处理接收到的数据,处理完毕后清接收标志。接收第一帧数据接收完成后,主程序开始处理数据,如果在处理过程中又接收一帧新数据,则该数据会丢失不被处理。对共用资源进行冲突检测通常还需结合软件时序进行分析。
2)中断现场备份和恢复
中断处理程序执行会打断主程序,且主程序中发生中断的位置一般不固定,为了保护被打断的主程序现场,需要在中断程序开始处对主程序现场进行备份,并在出口处进行恢复。对中断程序进行代码审查时需要检查需要备份的资源是否都进行了备份。这些资源通常包含程序状态寄存器、与主程序共用的寄存器以及一些全局变量。中断处理程序在入口处会对这些资源进行压栈操作,而在出口则进行出栈操作。代码审查需要检查需要被保护的资源是否已经全部被保护,各资源入栈和出栈的顺序是否匹配。
3)中断优先级
各种不同的芯片对中断优先级的处理是不一样的,例如8051 芯片只能设置高、低两种级别的中断;TI的F2812 芯片则各中断源的中断优先级固定的;而ARM芯片的中断优先级则是可编程的。且有些芯片的中断是可嵌套的,有些芯片则不能嵌套。对中断程序的代码审查应考虑到各芯片的具体特点,例如对不可嵌套的中断,则需考虑高优先级中断被延迟的问题,即如果在低优先级中断执行时,高优先级中断到来,则高优先级中断被延迟执行,该延时是否满足设计的要求。而对于可嵌套的中断,则需要考虑低优先级的中断被高优先级打断后,共用的中断资源是否存在冲突。对于中断优先级可编程的芯片,代码审查时还需检查中断优先级的设置是否正确,低优先级的中断被延迟或打断后,是否满足设计的要求。
以上是对中断程序进行代码审查时,需重点检查的要点。当然代码审查还应根据具体应该包括其他一些方面,例如对有些安全性要求比较高的软件则要求对未使用的中断应设置跳转到陷进程序,以防止软件异常进入未使用中断时,能够进行复位防止跑飞。还有一些芯片的编译器会对内存访问进行优化处理,则中断和主程序的共用资源则需声明为volatile类型,使芯片每次从内存取数,防止内存和寄存器数据不一致引发问题。在对中断程序进行代码审查时,如果注意到以上几点,能够有效地减少代码中存在的问题,提高软件的质量。
2 动态测试技术
对中断程序的动态测试主要包括测试中断程序的响应时间和处理时间。中断响应时间是从触发中断到中断程序开始执行之间的时间,中断处理时间则是从中断开始处到结束处的执行时间。对于响应时间和处理时间的测试,主要是测试时间是否满足软件需求的要求。
软件只存在一个中断,或存在多个中断,但不会同时发生时,一般响应时间和处理时间可直接测试;当软件存在多个可同时执行的中断时,则很难直接得到中断的响应时间和处理时间。存在以下几种情况:
1)两个中断同时到来,则程序会先执行高优先级,则低优先级中断被延迟执行,因此其响应时间则应包括高优先级中断的处理时间;
2)程序执行一个中断时,另一个中断触发,但该芯片不支持嵌套执行,则第二个中断响应时间包括第一个中断的部分执行时间;
3)程序执行低优先级中断时,发生高优先级中断,且该芯片支持中断嵌套,则低优先级的处理时间应包括高优先级中断的执行时间。
测试人员一般需要得到中断最长的响应时间和处理时间,上述情况在动态测试时不一定能够测量到,因此测试人员可先测量每个中断单独发生时的响应时间和处理时间,再根据芯片特点和程序中断执行时序计算理论上的最长响应时间和处理时间。
动态测试时,还需考虑中断处理时间对主循环处理时间的影响。例如,一个程序,存在两个中断,每个中断的处理时间均为200ms,程序主循环要求500毫秒内执行完毕,不发生中断时主循环的处理时间为200ms。当在一次主循环执行过程中,只发生一个中断时,程序主循环执行时间满足要求,但如果两个中断均发生,则执行时间为600ms,不满足处理要求。尽管该事件可能很少发生,但程序仍存在潜在问题。
3 结束语
本文从静态和动态两方面总结了嵌入式软件中断测试技术,这些技术在实际的嵌入式软件测试工作中的应用可有效减少中断程序的错误。嵌入式芯片类型多种多样,应用场景也各不相同,因此这些技术在实际测试工作中也需要灵活使用。
摘要：由中断引发的软件故障往往具有隐蔽性和随机性,因此嵌入式软件中断系统测试是嵌入式软件测试中的难点。该文对中断测试技术进行了研究,从静态和动态测试两方面总结了测试需关注的重点,通过使用文中的测试方法,发现中断系统中一些常见的问题。
关键词：中断,软件测试,静态测试,动态测试
嵌入式系统测试 篇2
支持嵌入式软件覆盖测试的工具应解决如下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。
嵌入式软件测试方法的初探 篇3
摘要：嵌入式计算机技术的飞速发展加速了电器行业嵌入式系统的应用，嵌入式系统中软件系统的比重越来越大，软件架构也越发复杂，软件运行的可靠性逐渐成为业界关注的焦点问题。本文由嵌入式软件测试的基本概念入手，基于嵌入式软件测试特点，综合分析嵌入式软件的关键技术和测试方法，旨在改善嵌入式软件的质量，提高其应用性能。
关键词：嵌入式软件 软件测试 测试方法
0 引言
当前，嵌入式软件已广泛运用于工业控制系统、信息家电、通讯设备、医疗仪器、智能仪器仪表等众多领域，软件的质量和应用性能备受业界关注。以往业界仅仅将功能的软件开发-测试模式作为重点研究课题，但当前所取得研究成果已无法满足日益增长的软件测试需求，其对软件行业的发展也产生了一些负面影响。嵌入式软件测试的工作内容主要是软件质量的监测，这对于嵌入式软件的开发及应用十分关键。
本文在软件测试基本技术的基础上，进一步探究嵌入式软件测试技术与监测方法，试图形成一种较为规范化的嵌入式软件测试解决方法。
1 软件测试基础
1.1 软件测试概念 软件是可以用来设计、制造、运行并且能有效维护的高质量、高可靠性的技术解决方案的一系列计算机程序和相关的组件。对软件进行测试是软件能否正常运行的重要保证，软件测试是以发现错误和缺陷为目的的一系列处理分析的程序或过程。
根据IEEE（1983）对测试定义是选择合适的测试用例，执行被测试程序的过程，其目的在于发现程序错误。在IEEEStd829-1998对IEEE（1983）修订版中，将测试定义为：测试（A）一个或多个的测试用例集，或（B）一个或多个的测试过程集，或（C）一个或多个的测试用例和测试过程集，是软件的分析过程，其目的在于发现软件功能特性等实现和要求不一致的地方（也即软件错误）及对软件的评估[1]。
从以上对软件测试的定义我们可以了解到，软件测试是以发现软件缺陷为目的，进而测试软件功能，最终评估软件质量为目的的试验过程。另外，为了确保测试结果客观、准确，必须按照设计要求选用合理的施测软件。
1.2 软件测试步骤 软件测试工作分五步完成，即单元测试、集成测试、确认测试、系统测试和验收测试（详见图1-1）。
■
单元测试完成对最小的软件设计单元的检验工作，筛查程序最小单位（模块）中的缺陷，编码后也需要作进一步验证。单元测试主要包括模块接口、局部数据结构、边界条件、独立路径及错误处理五项内容。
集成测试是将经过单元测试的模块按照软件结构组合在一起作为系统或子系统来进行的测试，验证模块间接口的正确性和各部分工作是否达到或实现相应技术指标及要求。集成测试一般在宿主机环境中进行。
确认测试是把软件系统作为单一的执行实体而进行的需求有效性测试。其目的是验证软件是否满足所有功能、性能、行为和执行要求。主要验证两个方面：一是确认软件正确实现了需求中所要求的功能，二是确认软件实现的功能是需求中所需要的。
系统测试实际是通过比较系统的需求定义，筛查软件中与需求定义不相符或相互矛盾的功能架构。系统测试须综合验证软件及其所含的信息、硬件程序是否与需求定义相一致，并检验程序的运行状态能否达到应用要求。
确认测试主要通过用户的参与，检验软件的性能、功能能否满足用户的使用需求，即验证软件的有效性，因此确认测试亦可称作有效性测试。
2 嵌入式软件测试的特点
性能和功能的测试是嵌入式软件测试的主要内容，但相对于一般性的软件测试而言，嵌入式软件测试仍有其特殊性。
①嵌入式软件运行时对硬件环境有一定的要求，嵌入式软件测试的重要目的是测试软件在特定的硬件环境下能否可靠运行，故对嵌入式软件的测试就需要在相应的硬件环境下进行。
②嵌入式软件测试还要保证嵌入式软件的实时性。测试还需在特定的外部环境下对嵌入式软件进行测试，例如强磁场、高温等环境中保证软件运行的可靠性。
③嵌入式软件产品除了满足设计的外部性能要求，还需要在特定的平台上运用相应的测试工具对软件进行内存测试、GUI测试、覆盖率分析。
嵌入式软件的质量以及程序的稳定性须通过软件测试来维护，这也是软件从开发阶段到应用阶段所必经的环节。图2-1即为嵌入式软件测试模型。
■
测试用例是详细描述测试如何执行的正式文档。选用相应的测试用例，配以测试平台的操作系统以及驱动程序，使得被测软件在正确的环境中运行。根据测试用例的执行结果与预期的测试结果相比较，找出被测程序的缺陷，并加以改进。
3 嵌入式软件测试技术
科学合理的软件测试技术是嵌入式软件测试项目顺利实施的基本前提。根据软件测试程序的应用情况我们可以对软件测试技术进行分类探讨。从测试对象在施测阶段是否被执行角度来看，软件测试涵盖了动态测试与静态测试两部分内容。
静态测试即静态分析，是对被测软件进行特性分析的一些方法的总称。静态测试无需执行程序代码，即可通过其他途径筛查程序内部的缺陷或对程序代码目的进行综合评估。静态测试的测试主要包括代码审查、代码走查、桌面检查、技术评查，这些内容全部须手动完成，另外还包括软件自动完成的静态分析[3]。
和静态测试相对应，动态测试是使被测代码在真实环境或仿真环境下有控制地运行，通过输入测试用例，对代码在运行时体现出的功能、逻辑、行为、结构等多角度观察，检查运行结果与预期结果的差异以发现其中的缺陷，并分析运行效率和健壮性等性能。动态测试的关键在于如何选择测试用例。
按软件测试技术分类有两种，即白盒测试与黑盒测试。
白盒测试主要涉及程序的内部设计和结构的测试。它将施测对象视为一可视化软件，施测人员须全面掌握程序的内部逻辑构造和功能特性，然后选择及设计测试用例，根据程序的逻辑路径施测。在各施测点对程序运行状态进行监测，确定实际的状态是否与预期的状态一致。
黑盒测试在某些情况下也称功能测试。这类测试方法根据软件的用途和外部特征查找软件缺陷，无须了解程序内部的结构，黑盒测试的最大优势在于不依赖代码，只需根据需求，设计相应的测试用例，根据输出结果判断程序功能以及性能正确性。
4 嵌入式软件系统测试方法
理论上讲，将所有可能的输入均作为测试情况考虑，软件测试只有采用穷举输入测试，才能将程序内所有的错误检测出来。而现实中测试情况可有无穷多个，所有可能的输入包含着合法输入和非法输入，要将所有的可能性输入一一检测仍有一定难度，因而须针对测试对象采取适当的测试手段，并参考测试对象的基本条件制定科学的测试用例，为测试工作提供参考依据，以确保有序地落实软件测试各个步骤。笔者结合实践经验，对当前常用的等价分类、边界值分析、McCabe循环复杂度度量和因果图法进行了具体分析。
4.1 等价分类 等价类划分就是把输入划分为若干部分，从每个部分中选取少量代表性数据，来对被测应用进行测试的方法。等价类应为互不相交的一组子集，而子集的并应该是整个集合[4]。
因为软件不仅要接收合理的数据信息，同时须经受意外的考验，因此等价类可细分为有效和无效两种情况。有效等价类，即对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。通过有效等价类，可对程序所达到的性能和功能是否符合规格说明进行验证。而无效等价类与有效等价类恰好是两个相反的概念。另外，对等价类进行划分后须根据设计要求全面测试用例的有效性。
4.2 边界值分析 边界值分析是一种黑盒测试方法，它是对等价类划分方法的补充，通过选择等价类边界的测试用例。通过这种测试方法设计测试用例，须对边界情况有大致的了解。一般来讲，输入与输出等价类的边界即应着重测试的边界情况[5]。
从某种意义上讲，边界值分析法也是一种测试输入或输出的边界值的有效途径。这里所有的边界值涵盖了边界值两边的值。边界值测试的基本原理：输入变量的极值附近极有可能是缺陷点；基本思想：在最小值、略高于最小值、正常值、略低于最大值和最大值处取输入变量的值。
4.3 McCabe循环复杂度度量 要全面测试某一软件或某一功能模块的有效性，先确保被测对象具有可测试性。顾名思义，可测试性即被测对象所具有的内在属性，它与测试工具或测试方法无关。可测试性能够反映出软件质量优劣，只有高内聚、低耦合、接口明确、意图清晰的软件才具有可测试性。相反，高耦合、内部逻辑混乱的软件即为不可测试性软件。
4.4 因果图法 等价划分和边界值分析没有对输入条件进行分析。组合分析有时是一件困难的事情，因为组合的数量可能达到天文数字。因果图有助于找出高效的测试用例，甚至可以找到规格说明欠缺的地方。
因果图法的步骤如下：①分析规格说明中的原因、结果，并赋予标示符。②找出因果之间的对应关系，画出因果图。③在因果图上标明约束条件。④把因果图转化为判定表。⑤根据判定表每一列表示的情况生成测试用例。
5 结束语
伴随着嵌入式软件事业的持续拓展，软件测试作为保证软件质量的一项关键性的工作，已越来越受到重视。正确的嵌入式测试方法是软件测试工作的工作重点。本文除了对有关软件测试的基本概念作了简要阐述，还对它们之间的内在架构进行了重点分析，并介绍了几种常用的嵌入式软件测试技术及嵌入式软件测试方法。这些技术与方法的运用对软件测质量和稳定性起到非常关键的作用。
参考文献：
[1]IEEE，IEEE Standard for Software Test Documentation.IEEEStd829-1998.
[2]梁合庆.当今嵌入式系统综述与新的投资机遇[J].测控技术，2000（4）.
[3]康一梅，张永革.嵌入式软件测试[M].北京：机械工业出版社，2007.
[4]古乐，史九林.软件测试技术概论[M].北京：清华大学出版社，2004.
[5]蔡建平.嵌入式软件测试实用技术[M].北京：清华大学出版社，2010.
基金项目：
浙江省大学生科研创新团队资助项目（编号：2012R409046）；
嵌入式系统测试 篇4
关键词：嵌入式系统,税控收款机,JavaPOS,ARM
0 引 言
随着嵌入式计算机应用技术的发展, 嵌入式技术已经广泛应用到现代生活的方方面面。在零售系统方面, 零售收款机是嵌入式应用的一个重要领域。目前, 市场上的收款机大体上可分为三类:第一类是基于PC和DOS/Windows体系的, 这类产品目前占市场绝大多数, 属于高端产品, 价格太高, 适合大的商场和销售系统;第二类是基于单片机 (51系列居多) 的, 基本上没有操作系统的支持, 功能也较弱, 主要用于餐饮娱乐, 占据中低档市场;第三类是正在快速发展的基于嵌入式芯片和嵌入式操作系统的, 价格较低, 功能较强, 适用于中高档市场, 这类产品将是未来市场的主体。以上三类收款机的开发平台形形色色, 基本上是每一款就是一种开发平台, 没有统一的规范、开发和调试平台。系统升级和移植困难, 尤其对于一体机等需要第三方开发软件的应用, 造成开发上更大的难度。虚拟机VM的改进, Java应用的速度已经不是太大的问题。
1 JUnit分析与应用
MUnit是JUnit的子集, 使用方法类似JUnit, 在这里只对JUnit做分析。JUnit是一个开源的Java测试框架, 它是XUnit测试体系架构的一种实现。在JUnit单元测试框架的设计时, 设定了三个总体目标, 第一个是简化测试的编写, 这种简化包括测试框架的学习和实际测试单元的编写;第二个是使测试单元保持持久性;第三个则是可以利用既有的测试编写相关的测试。所以这些目的也是为什么使用模式的根本原因。JUnit的设计使用以Patterns Generate Architectures的方式来架构系统。其设计思想是通过从零开始应用设计模式, 然后一个接一个, 直至获得最终合适的系统架构。JUnit是一个测试Framework, 测试人员只需开发测试用例, 然后把这些测试用例 (TestCase) 组成请求 (可能是一个或者多个) , 发送到JUnit, 然后由JUnit执行, 最后报告详细测试结果。其中, 包括执行的时间、错误方法、错误位置等。这样测试用例的开发人员就不需知道JUnit内部的细节, 只要符合它定义的请求格式即可。从JUnit的角度考虑, 它并不需要知道请求TestCase的具体操作信息, 仅把它当作一种命令来执行, 然后把执行测试结果发给测试人员。这样就使JUnit框架和TestCase的开发人员独立开来, 使得请求的一方不必知道接收请求一方的详细信息, 更不必知道是怎样被接收, 以及怎样被执行的, 实现系统的松耦合。
Junit.Framework包中包含了JUnit测试类所需要的所有基类, 实际上这个包也是整个JUnit的基础框架。TestCase类是这个包的核心类, 测试人员对TestCase类进行继承开发自己的类测试驱动程序。其余的类用来支援这个TestCase类, 比如TestSuite用类聚合多个测试用例 (Testcase) , Assert类实现期望值和实际值的验证, TestResult收集所有测试用例执行后的结果。Test接口是这个包的关键所在, 它建立了TestCase和TestSuite之间的关联, 同时为整个框架做了扩展预留。在J2SE下简单应用举例:
(运行) 调试方式→JUnit测试。图1为运行结果。
JUnit在J2SE下可以很好地应用, 但是在J2ME下应用存在比较大的困难, 因为在J2ME下没有反射机制。在实际测试中可以利用其优点来最大地发挥。
2 POSDouble测试
由于MIDP 1.0下不支持浮点数 (float) 运算, 因此必须开发适合J2ME下的浮点数运算方法。这里主要实现了以下方法, 这些方法的测试都是通过JUnit进行的白盒测试, 测试数据的选择主要是根据市场的实际需求设定, 保证了现阶段的实际需求;而在MIDP 2.0下可以支持浮点数的运算, 无须自己开发浮点数运算的方法。
类名:POSDouble, 主要是用于浮点数计算, 主要测试以下方法:
3 通用接口测试
由于POSDouble是在J2SE下开发的, 所以使用了JUnit工具, 而其他接口函数是在J2ME下开发的, 所以接口的测试采用了MUnit (JUnit的子集) 工具。MUnit工具的使用方法、规则请参考《MUnit测试集编写规范》。
(1) 测试框架
目录结构的总原则是:源代码目录与测试代码目录分离, 互不干扰;测试代码目录与源代码目录的分支结构一致, 便于查找、维护。
(2) 仿真环境测试执行流程
首先编写测试代码, 测试代码尽量放在与源代码相对应的测试目录中。修改测试程序入口, 如使用ePos.set.FunctionFormFactory。
(3) 目标环境测试执行流程
编写测试代码, 修改测试程序入口, 构建测试代码的Jar文件, 下载Jar文件到目标机运行。
(4) 测试捷径
通常情况下, 在目标环境下测试, 需要先编写测试用例、再编译、再下载、再运行, 如果突然想到一个测试用例, 又需重复上述操作步骤, 就会非常耗时。为了增强测试的灵活性, 可以加入键盘监听事件。首先编写键盘监听类, 将所有的测试单步对应到不同的按键上去, 即按一个键执行一个操作步骤。如:“a”对应open操作, “b”对应claim操作, “c”对应setDeviceEnable (true) 操作。要执行一个完整的测试过程, 就分步骤按相应的按键。要想执行不同的测试用例就按不同的顺序按相应的按键, 这样就不再需要编写测试用例、编译、构建、下载, 可以节约很多时间, 测试效率得到很大提升。同时可以结合原有测试用例, 让不同的按键对应到不同的 (完整的) 测试用例, 这样不占用程序入口, 同样可以实现并执行原来的测试用例。
(5) 快速回归测试
bug修正后需要做回归测试, 为了在目标环境上回归测试, 必须经过以下步骤:
① 从CVS更新最新源码;
② 将Java源码编译成C文件;
③ 构建Elf文件;
④ 下载Elf文件;
⑤ 执行测试用例做回归测试。
其中的步骤②～④将耗费很多时间。为了提升回归测试效率, 将设备的DeviceServices从Elf文件中剥离出来, 单独生成一个Jar文件, 如果只有DeviceServices更新, 只需要重新编译DeviceServices的Jar文件, 不需更改Elf文件。更新Jar文件比更新Elf文件从步骤及时间上都高效得多。
4 示例
(1) 占用一个入口, 加入键盘监听事件, 如图2所示。
(2) 在keyboardlistener中编写按键对应的测试用例或方法, 如图3所示。
(3) 编译构建Elf文件。先编译evm, ejpos两个项目;编译ROMJavaWin.c, NativeFunctionTable.c用于构建Elf (含evm, ejpos) ;在LambdaIDE下构建Elf文件并优化;通过LBOOT下载到目标环境中。
(4) 编译测试用例的Jar文件。
(5) 在目标机上根据按键执行不同的测试用例。
bug回归测试时, 更新DeviceService的内容, 重复步骤 (5) 即可完成回归测试。
参考文献
[1]郑棋, 蔡建平.协同、实时和测试三大技术影响嵌入式应用[N].中国计算机报, 2004-4-5.
[2]探矽工作室.深入嵌入式Java虚拟机[M].北京:中国铁道出版社, 2003.
[3]电子科技大学计算机学院.嵌入式实时操作系统及应用开发[Z].2003.
[4][美]布洛克.Effective Java[M].潘爱民, 译.北京:机械工业出版社, 2003.
[5]王东刚.软件测试与JUnit实践[M].北京:人民邮电出版社, 2004.
[6]王健, 苗勇.软件测试员培训教材[M].北京:电子工业出版社, 2003.
[7]薛震宇.基于虚拟串口的嵌入式系统测试卡设计[J].仪表技术, 2008 (2) :54-55.
[8]刘凯.嵌入式系统设计技术浅谈[J].电子制作, 2008 (3) :6-7.
[9]王益, 耿相铭, 陈慧.嵌入式测试系统设计[J].计算机工程, 2008, 34 (18) :237-238.
嵌入式系统测试 篇5
嵌入式设计已经成为工业现代化、智能化的必经之路，嵌入式产品已经深入到各行各业。嵌入式系统的专用程度较高，系统的整体继承性相对较小，为了保证系统的稳定性，软件的测试成为嵌入式开发的一个重要环节。由于嵌入式软件自身的特点，传统的软件测试理论不能直接用于嵌入式软件的测试，因此，研究嵌入式软件的测试有重要意义。
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给出了嵌入式软件测试的统一测试模型。软件测试逐渐成为一门成熟的学科，前人针对面向对象和面向过程的非实时软件的测试作了大量的研究，其中大部分方法可以用到嵌入式软件的测试。
根据不同的指标，软件测试方法有不同的划分方法。从软件开发过程中测试所处的不同阶段可分为模块测试、集成测试和系统测试。根据是否需要运行目标代码分为动态测试和静态测试；根据目标代码的可见性可分为白盒测试（结构测试）和黑盒测试（功能测试）。在软件的.测试中，每种测试方法都不是孤立的。为了最经济最有效地达到测试的目的，各种测试方法往往是互相嵌套的。例如，在软件的单元测试
阶段，可以用黑盒测试和白盒测试的方法分别进行动态测试。
嵌入式系统测试 篇6
关键词：嵌入式系统；家居控制系统；研究；探讨
中图分类号：TP311文献标识码：A文章编号：1007-9599 (2011) 05-0000-02
Home Control System Research Based on Embedded System
Zhou Zuhua
(Vocational and Technical College,Guizhou University,Guiyang550003,China)
Abstract:At present,the rapid development of family intelligent technology,the family intelligent controller of home intelligent system is the key.Home control system based on embedded system has become one of our development focus of the study.Based on the study of a large number of home and abroad on the basis of the control system,a home control system to achieve:that is, the control module to combine with the operating system,plus a variety of sensors embedded home control system.
Keywords:Embedded system;Home control system;Research;Discussion
一、嵌入式系统家居控制系统的硬件设计及功能
对基于嵌入式系统家居控制系统的进行研究探讨，就需要我们对其硬件进行科学合理的设计，并充分实现其功能作用。因此，在设计嵌入式系统家居控制系统的时候，我们必须要充分考虑到控制系统的科学、稳定、扩展等特点。这样，就要求我们必须把嵌入式系统家居控制系统的硬件设计当作其中最为核心的组成部分来进行，尽量优化设计，最大限度地发挥其功能作用。一般情况下，我们可以把嵌入式系统家居控制系统设计成为核心模块和控制模块两个部分。在嵌入式系统家居控制系统中，核心模块主要用来构建嵌入式控制系统的，而控制模块则主要是一些位置处于外面环境的接口所组成的。实际上，嵌入式系统家居控制系统的硬件主要有：核心模块主要是由处理装置（如微处理器等）以及处于外面环境中的存储芯片等所组成的。就嵌入式系统家居控制系统的发展而言，三星公司所生产的S3C2440微处理器使用最多最广。这是因为，S3C2440微处理器被广泛应用到多媒体软件、便捷式通信产品等嵌入式系统内，同时还能够比较轻易地运行到Windows CE中。此外，因为整个嵌入式系统家居控制系统的实现要求比较高，所以采用三星公司生产的S3C2440微处理器则能够很好地满足了这些要求。处于外面环境中的存储芯片，即控制模块则采用芯片，通过串口信号线与微处理器相互连接，同时通过CPU进行控制。不过，这样需要增加相应的驱动线路。但是其触摸屏则采用了四线电阻式，直接把它同CPU相互连接起来。
二、嵌入式系统家居控制系统的软件设计及功能
通过Windows CE操作控制系统可以实现和满足嵌入式系统家居控制系统对实时性以及网络功能的具体要求。不过，我们也必须同时综合考虑开发成本以及难易程度等因素。此外，Windows CE操作控制系统具有比较好的用户界面，而且比较容易于操作、控制和管理等。同时，在嵌入式系统家居控制系统中，我们主要是应用层面的开发与研究。因此，选用Windows CE操作控制系统比较适合，也比较划算。但在Windows CE操作控制系统产品的开发过程中，有以下几个方面的重要内容值得我们重视：一是驱动程序的研究开发；二是内核定制；三是应用程序的研究开发等。以上几点在嵌入式系统家居控制系统极为重要与关键。而微软在这些方面都提供了比较好的开发工具，因而也就成为了内核定制以及应用程序研究开发的重要工具之一。
（一）嵌入式系统家居操作控制系统的平台定制
在嵌入式系统家居控制系统中，其硬件平台成功组建以后，我们必须结合具体的家居应用实际，针对特定的硬件定制嵌入式操作控制系统，这也是本文研究和探讨的重点。可以这么说，要想直接在嵌入式系统家居控制系统的硬件平台上编写相应的软件是相当困难的，因为嵌入式系统家居控制系统资源受到极大的限制。当前，人们通常是采用宿主机或者目标机等的方式进行，即就是首先在相应的电脑上编写控制程序，接着应用交叉编译方式，从而生成在目标平台上可以运行的二进制程序或文件，最后一个步骤是下载到相应的目标平台上运行，进而实现其功能与作用。但是，在进行嵌入式系统家居控制系统研究开发以前，我们必须首先要建立和配置好交叉研究开发的环境与条件。Windows CE操作控制系统作为一个很好的平台，其定制过程主要包括以下几个方面：一是确定并选择操作系统的基本配置，并且要为特定的操作控制平台确定和选择相应的微处理器以及支持包等。二是利用标准研究开发向导，并根据Windows CE操作控制系统的基本架构，结合目标硬件设备研究开发、添加适当的组件、设备驱动程序等，创建一个定制的平台。如果可以，就对一些配置文件进行修改之后，再培植所需要的功能模块中去，与此同时通过编译进而生成相应的镜像文件。三是应用串口、网络或USB等把编译生成的相应镜像文件下载到目标设备中，可以使用调试工具查看Windows CE操作控制系统的运行情况，并可以随时进行调试或修改。若有必要，可以重新进行配置、封装、调试以及修改等，直到达到用户的要求为止，从而更好地实现嵌入式系统家居控制系统的功能。四是最后需要导出相应的软件研究开发工具包，在运行后安装到系统中，从而使得系统可以进行特定硬件平台的应用程序研究与开发。
（二）嵌入式系统家居控制系统驱动程序的研究开发
通常情况下，由于嵌入式系统家居控制系统的驱动程序涉及到中断驱动程序和GPIO 驱动，因此可以采用单片驱动程序和分层驱动两种方式进行。在这里，单片驱动程序我们就不用多说了，而主要研究分层驱动程序。分层驱动程序主要由两个部分组成，即模型设备驱动程序依赖平台的驱动程序。微软为连接驱动程序提供了相应的设备驱动程序，模型驱动程序对于平台来说都是通用的，也就是同时都是源代码和库。总体上看，模型驱动程序主要执行以下任务：一是连接设备驱动程序提供器接口；二是把不同的操作控制系统连接在一起；三是负责与系统控制模块与内核之间的通信，与此同时，也包括诸如中断控制等一些复杂的操作。而设备驱动程序接口主要是供模型设备驱动程序调用，主要由模型设备驱动程序提供。而对于分层驱动程序方面，编写驱动主要就是要编写直接操作处理器中寄存器的相应数值和操作系统平台中传递的参数。通常，它们在操作控制系统的层面上，通过传递数值和返回参数，修改和获取S3C244的相应数值，并通过调用相关应用程序来实现需要的控制功能。
（三）嵌入式系统家居控制系统应用软件的研究开发
作为微软公司研究开发的Windows CE操作控制系统具有与Windows系统基本一致的功能与作用。当然，Windows CE操作控制系统的研究开发也有着自己显著的特征。对于Windows CE操作控制系统应用软件的研究开发，我们应当注意以下几点：首先，必须使用Unicode字符集的程序。其次，程序代码应当做到和最小，因为嵌入式设备一般都没有太大的空间容纳像台式电脑那样的内存，如果程序过大，运行的时间就会延长。再次，Windows CE操作控制系统应用软件的程序主要是通过驱动程序读取。直接获取与S3C2440端口相连的传感器的状态和数值后，把相关信息返回Windows CE操作控制系统应用软件的程序中，程序再根据传感器的状态及数值又把关联的信息通过调用串口驱动程序，发送相应的命令并传给有关功能模块，随后该模块发送信息到用户手机，用户就可以随时看到家中的变化。倘若用户要对家中的一些设备进行操作，就可以应用发送信息的方式把控制信息传给有关功能模块，该功能模块再将此信息又传到Windows CE操作控制系统应用软件的程序中，这时应用程序就可以控制相应的端口了，进而满足用户的具体要求。
三、结束语
在当今社会，随着家庭智能化技术的全面快速发展，家居控制系统的重要意义和作用越来越凸显在人们的面前，这也是嵌入式系统家居控制系统的关键所在。因此，我们必须结合实际，坚持以先进的现代科学技术和通信技术为前提与基础，尽力做到以嵌入式系统为技术核心，不断优化家居控制系统的结构与功能，保证其功能全面、性能稳定、耗能低下等特征，促进其全面快速健康发展，更好地为人们提供方便快捷的服务。
参考文献：
[1]赵静,梅军.嵌入式智能家居控制系统的研究与设计[J].今日电子,2010,2
[2]彭小军,李荣.基于ARM的嵌入式智能家居控制系统研究[J].低压电器,2009,18
[3]郭海杰,吴飞,雷必成.嵌入式智能家居控制系统的研究[J].福建电脑,2009,3
嵌入式系统测试 篇7
Linux操作系统并不是专为嵌入式系统设计的, 应用于嵌入式设备时必须进行裁剪优化, 其目的之一是为了简化已有的操作系统内核的功能和结构, 以满足嵌入式系统对资源的限制需求。
嵌入式操作系统需要裁剪的对象主要有:引导及初始化程序, 操作系统内核, 系统动态加载模块, 动态链接库以及根文件系统等。定制裁剪的一般操作过程如下:获取linux内核、GNU utility等源代码, 根据项目需求和具体平台对内核源代码进行补丁操作, 手工配置, 去掉多余的功能模块, 保留部分开发调试用模块和目标功能模块, 生成配置文件。然后根据配置文件进行自动交叉编译和链接, 生成压缩过的适合具体硬件平台的内核映像文件。再以同样方式生成引导初始化程序映像和根文件系统映像, 最后把三者通过适当的方式安装到目标开发板中, 生成我们的目标操作系统, 并且进行功能和性能测试分析。
2 内核的裁剪和移植
内核裁剪方式有多种, 有基于原内核提供的kbuild体系的裁剪方法, 有基于代码分析的linux裁剪方法, 有基于调用图的linux裁剪方法。基于短开发周期的需求考虑, 选择采用kbuild体系的裁剪方法。Kbuild体系通过预定义一些变量 (obj-m, obj-y) 和目标 (bzImage) , 使内核的编译和扩展变得十分方便, 具有很强的可定制性。
2.1 选择交叉编译环境
可以有多种方式来建立交叉编译环境, 包括自行通过源码编译, 通过外部工具进行批处理编译, 本文采用开发板自带的交叉编译器。
2.2 支持开发板的arm架构
原始内核源码包缺乏支持目标开发板的模块, 需要打上由厂商所提供的补丁。
2.3 修改内核Makefile文件
在内核源码目录下的Makefile中修改指定内核架构和交叉编译器, 这样就不需要在编译时再指定了。
2.4 选择默认配置文件, 在此基础上进行内核配置的修改
配置内核有四种基本方式, 有基于字符终端的也有在图形界面下配置的。
make config基于文本的最为传统的配置界面, 不推荐使用;
make menuconfig基于文本选单的配置界面, 字符终端下推荐使用;
make xconfig基于图形窗口模式的配置界面, Xwindow下推荐使用;
make oldconfig如果只想在原来内核配置的基础上修改一些小地方, 会省去不少麻烦。
以make menuconfig为例, 选择相应的配置时, 有三种选择, 它们分别代表的含义如下:
Y-将该功能编译进内核;
N-不将该功能编译进内核;
M-将该功能编译成可以在需要时动态插入到内核中的模块;
配置过程需要使用空格键进行选取。在每一个选项前都有个括号, 但有的是中括号有的是尖括号, 还有一种圆括号。
用空格键选择时可以发现, 中括号里要么是空, 要么是"*", 而尖括号里可以是空, "*"和"M"。这表示前者对应的项要么不要, 要么编译到内核里;后者则多一样选择, 可以编译成模块。而圆括号的内容是要你在所提供的几个选项中选择一项。
快速配置方法:make localmodconfig。Linux 2.6.32开始引入了一个make localmodconfig用于简化kernel的配置。make localmodconfig会执行lsmod命令查看当前系统中加载了哪些模块 (Modules) , 将原来的配置文件中不需要的模块去掉, 仅保留前面lsmod出来的这些模块, 从而简化了内核的配置过程。
这个方法的缺点是:仅能使编译出的内核支持已经加载的模块。因为该方法使用的是lsmod的结果, 如果有的模块当前没有加载, 那么就不会编到新的内核中。
配置完成后, 保存退出, 配置程序会自动生成一个隐藏的配置文件.config, 需要把这份文件另存到其他地方以便管理和使用。编译内核时, 源代码目录顶层Makefile文件读取该目录下的.config文件, 得到内核配置过程中所产生的编译宏。Makefile根据这些使用编译宏, 决定所编译的文件列表, 并通过Rules.make使用公共规则产生相应的目标。
在GCC中, 最常用的优化选项是-Os, 有-O0-O1-O2-O3-Os。-O0关闭编译器优化, -O1是第一级优化, 编译器将在不显著增加编译时间的基础上, 尝试减少代码尺寸, 缩短执行时间。使用-O2和-O3将增加优化级别, 同时仍然保留-O1所采取的优化方法。-Os是介于-O2和-O3之间的优化级别, 使用-O3优化可能造成不好的后果。
2.5 编译内核
在内核源码目录执行下列命令, 生成内核镜像文件。
生成的内核镜像位于源码目录的arch/arm/boot/, 第一步命令生成的是zImage, 是一般情况下默认的压缩内核映像文件, 通过压缩vmlinux, 再加上一段自解压代码生成。第二步命令是生成uImage, uImage是使用工具mkimage对普通zImage之前加上一段长度为64字节的字段生成, 说明了该内核的版本, 加载位置, 生成时间, 内核大小等信息, 是ARM架构专用的映像文件。
3 根文件系统的实现
典型的嵌入式linux根文件系统具有几个特征, 其一是根文件系统中文件、库和目录, 通常是经过必要的选取和简化的, 其二是根文件系统是经过压缩的, 系统启动时解压到内存中。
嵌入式linux根文件系统制作工具BusyBox是标准Linux工具的一个单个可执行实现。BusyBox通过传递特定参数的方式来实现特定的linux工具和命令, 提供超过200个Linux工具和命令的简化模式。
3.1 配置和编译
由于BusyBox也采用了ncurses工具, 因此可以通过类似编译内核的配置方式:make menuconfig来进行BusyBox的具体配置过程。配置过程中, 可以在Makefile中具体指定ARCH和CROSS_COMPILE, 安装目录, 是否采用动态编译和需要哪些linux命令工具。
3.2 制作jffs2镜像
通过mkfs工具生成经过压缩的根文件系统镜像jffs2.img。
4 系统测试
将内核镜像文件uImage和根文件系统镜像文件jffs2.img通过开发板工具载入开发板flash进行功能测试, 也可以在boot阶段通过tftp来完成载入内存工作。测量内核静态体积大小, 缩小到约原来的30%。
4.1 初步启动测试结果
嵌入式linux操作系统成功启动。
4.2 可用性测试
通过对U盘, 网卡等板上设备使用、C应用程序运行, 操作系统命令运行等进行测试, 结果正常。
4.3 性能基准测试
lmbench具体通过内存拷贝, 内存读写, 管道, 上下文切换, 网络连接的建立, 文件系统, 进程创建, 信号处理, 系统调用等参数来建立性能指标体系。
4.4 测试结果及其分析
在原来的嵌入式操作系统和目标操作系统上运行lmbench100次, 获取有效数据进行处理分析, 性能指标选取有如下几类:processes-time, pipe communication latencies, File create&delete latencies。比较各性能指标平均数发现, 裁剪后的linux操作系统性能提升约5%~10%, 稳定性有一定提高。
5 结论
随着linux的发展, linux内核的体积越来越大, 通过优化内核体积和系统内存占用, 可以在一定程度上提升linux的性能表现。目前linux的裁剪定制主要依赖于灵活的kbuild体系, 通过条件编译来实现。其他更细粒度的技术比如代码分析技术, 调用图技术还有待发展和成熟。
参考文献
[1]Anand K Santhanam, Vishal Kulkarn.嵌入式设备上的linux系统开发[DB/OL].http://www.ibm.com/developerworks/cn/linux/embdev/samsung.com, 2004, 3.
[2]李绍勋, 陈朔鹰, 罗国良.linux2.6内核测试及其到ARM嵌入式平台的移植[J].理论和研究测试卷, 2005 (5) .
[3]刘文峰, 李程远, 李善平.嵌入式Linux操作系统的研究[J].浙江大学学报:工学版, 2004, 38 (4) :447-452.
[4]马永光, 席亚宾, 林永君.基于linux的嵌入式操作系统的研究[J].计算机世界网, 2003.
[5]郑家玲, 张云峰, 嵌入式系统的内核载入过程浅析[J].微型机与应用, 2002 (11) :59-60.
[6]TINYNew project home page of tiny:http://tinylab.org/index.php/projects/tinylinux.
[7]Karim Yaghmour.构建嵌入式linux系统.台湾:O'Reilly, 2005:579-613.
[8]Greg Kroab-Hartman.Linux Kernel in a Nutsbell:O'Reilly, 2010.
嵌入式系统测试 篇8
关键词：软硬结合,嵌入式软件,在线测试系统
在很多领域内, 常用嵌入设备, 这类软件被布设在微处理器、其他设备之内。嵌入软件渐渐变得复杂, 在这种情形下, 快速辨识它独有的在线特性, 是应被注重的。传统测试流程, 手动测试获取的成效还是偏低, 效果不够优良, 含有偏多隐患。依照软硬结合, 创设了汇编特性的新颖测试, 识别拟定编码。
1 概要体系构架
软硬结合状态之下的嵌入式软件, 在布设测试体系时, 拟定了独特框架。具体而言, 它整合了多重的子系统:识别模块特性、识别代码特性、解析各类数值、报告给定文档、变更通信接口如图1所示。
在这之中, 测定软件特性, 辨识了目标体系特有的测试信号, 接纳这类信号。在这种情形下, 辨识软硬件是否契合了拟定好的规格, 归属黑盒测试。测定代码特性, 依托嵌入式这样的体系软件, 识别代码等级。这类测试步骤, 含有追踪测试、常见覆盖测试、其他特性解析。这类白盒测试, 辨识了软件范畴内的各类缺陷。
2 设计测试进程
2.1 拟定测试步骤
第一步, 识别图形界面, 用户选出某一性能。选出来的性能, 归属性能测定或对应的代码测验。依照用户选择, 系统经由自动的路径来生成必备的这种用例。若筛选了代码测验, 对于初始的源代码还应予以插桩。在这以后, 转变通讯接口, 传递数据直至设定好的目的体系。
第二步, 真正运行以后, 体系会把测得的数值再次经由互换板块, 反馈至解析文档、相关报告模块。在数值解析中, 文档报告必备的模块会慎重解析接纳的这类数值, 构建通用报告。测试数值被设定成图形化, 插入测试报告。在后续流程中, 把数值返回至初始的用户。
第三步, 再次辨别要求, 以便调整参数。若没能吻合初始的要求, 则进到第一步;若符合了规格, 则可终结测试。
2.2 汇编测试必备的进程
基于汇编体系, 创设了嵌入式特有的这类测试。软件测试涵盖着程序插桩、生成测试用例、查验动态信息、构建集成环境。历经预处理后, 还要辨识语法, 明晰插桩函数特有的精准位置。在关键字段处, 添加必备的桩, 生成目标文件。动态集成这样的环境内, 要筛选细分出来的测试类别, 含有覆盖语句。记录插桩必备的文件内, 录入函数位置、相关地址编号, 生成可用的用例。依照选出来的文件来着手激活这一函数。
真正运行之后, 测得信息被反馈至测试机, 数值被存留在缓冲区段内。依照测得结果, 对比设定好的期望值, 以便识别出现有的覆盖状态。若不合乎要求, 则要解析情况, 寻找出没能被覆盖住的这一目标。依照控制流图, 找出明晰的到达路径, 拟定多重节点, 构建新的用例, 以便拓展原有的覆盖范畴。在测试最后, 结果被设定为GUI特有的形式。
3 构建在线测试
3.1 初始预先处理
预处理步骤中, 要完成宏替换, 把初始的短跳转变更为更长的这种跳转。构建汇编程序, 含有偏多的短跳转;仅需8个字节, 即可明晰偏移地址。这类步骤优势, 是缩减了运行情形下的空间耗费;但是它的弊病, 是把相对地址限缩在偏小的区段内, 添加了覆盖测试之中的多样阻碍。为此插桩以前, 应能先去处理。在汇编进程内, 调用宏的速率很快, 为此常被采纳。在后续编译中, 它被完整镶嵌在了设定好的调用之处。在现有的宏中, 如果添加探针, 会带来初始的规模膨胀, 很难保障顺畅的后续运行。预处理的进程, 要把这样的调用宏变更为等价的另一进程。
3.2 辨识相关语法
解析语法及词法, 常常紧密关联着构建好的设计语言。经过解析词法, 源程序涵盖着的字符都被替换成记号, 便于常规识记。对应着的语法解析, 从这样的记号内辨别出明晰的程序, 识别程序结构。这类识别要素, 含有表达式子、语句及函数体、程序内的分支、若干的关键字。详细而言, 可以构建表格, 便于自动插桩。
3.3 嵌入体系插桩
3.3.1 确认插桩方位
设定插桩位置, 以便顺利予以插桩。总体程序可被细分成多重的模块, 探针代表着选出来的插桩位置。汇编流程中, 要考量细化的位置。具体而言, 确认精准的插桩方位, 含有如下标识:
Start标识着初始的程序, 它含有线性块;JMP标识为转移指令, 在这之前要添加第一个必备的label;程序设定好的出口被标识为end。
3.3.2 设定插桩途径
插桩必备的途径, 含有植入探针。从细化步骤看, 先要选出精准的植入位置, 再去设定途径。在拟定途径时, 要辨别出分支的探针、块的探针。对于块状探针, 它含有顺序块, 它整合了彼此衔接着的语句序列。后续执行之中, 它显示了明晰的线性特性。若选出来的执行对象含有初始的语句, 那么后续设定好的线性块都可被执行。在初始及末尾, 都可添加探针。这种添加做法, 规避了细化解析这样的语句, 回避多余的插桩。对于分支探针, 它含有辨识对错的这类语句, 它归结了多重分支现有的覆盖概率, 设定了测试点。
3.3.3 插桩的进程
在被测程序内, 应当植入探针, 设定为函数桩, 拟定函数声明。这类插桩函数被存留在函数库以内。目标文件有着可执行的特性, 应当衔接着函数库。触发这类函数, 就要依托选出来的记录文件。若覆盖率有着差异, 函数被激活的频次也会凸显差异。
3.4 存留测试结论
在动态测试后, 存留解析数值, 算出运行路径下的语句总体覆盖、分支覆盖概率。获取动态信息, 存在缓冲之中。被执行的程序含有顺序块、子程序的分支。经过解析运算, 可把缓冲区段内的内涵解析为必备的覆盖信息。
测得的数值被动态存留下来, 以便后续解析。程序被运行时, 可以辨识分支覆盖、语句覆盖频率。运行态势下的动态信息可被存留, 把它们归整在缓冲区之中。设定执行次序, 含有顺序块、子程序及关联的分支。经由动态测定, 辨识了给出来的信息。缓冲存留着的一切数值, 都可被变为明晰的数值结果, 然后有序存储。
4 归结测试结果
在给定测验之中, 选出可用的串口通信, 以便操控对象。选出来的模块, 含有多重分支的这类子模块。依照测试需求来创设多样的用例, 设定覆盖测试。模块含有多层级的复杂状态, 输入进来的参数并不彼此等同。这种状态之下, 测试用例可浮动的范畴为19至51个。对于各类模块, 先要算出不同数值的覆盖指标;依托仿真平台, 对比多样的覆盖指标。这种对比步骤, 就查验出了初始测试得来的数值是否精准。
在选定用例中, 推算得来语句总的覆盖率、体系内的分支覆盖率。运算二者结果:77%及59%。历经运行以后, 手动运算得来的数值能够彼此契合。由此可以表明:构建起来的初始模型吻合了测得的结果, 测得数值正确。
5 结语
在线测定嵌入软件, 基于汇编语言, 描画了流程图。自动予以生成, 采纳了虚拟情形下的插桩步骤以便动态调整。在给定时段内, 算出总体范畴的覆盖率。对于各个模块, 都拟定了最适宜的逻辑、给定输入参数。运用测试用例, 查验了测试得来的精准数值。这类软硬结合, 提升了原有的测定成效, 摸索新式途径。
参考文献
[1]杨军丽, 张晓辉, 章慧雅.星载设备嵌入式软件可靠性仿真测试系统设计[J].计算机仿真, 2008 (3) :63-65, 69.
[2]王奉国, 刘宏生.某嵌入式软件可靠性仿真测试系统设计与实现[J].电子测试, 2009 (3) :54-57.
嵌入式系统测试 篇9
近几年, 软件应用日趋完善, 软件功能日益多样化。在这种背景下, 行业内对嵌入式软件“释放关键的运行错误空间, 减少测试费用”的要求越来越高, 所以测试技术的改进迫在眉睫。
抽象解释是一个比较成熟, 相对可靠的数学方法。有了这种方法, 就能在程序的编译阶段静态验证软件的动态属性。所以可以把它当作另一种编译技术, 这种技术比原有的编译技术更加强大。这种编译技术可以使测试人员在执行一个软件之前预言这个软件未来的运行情况。综上所述, 抽象解释可以把传统的静态分析技术和动态测试有机的联系在一起。对一个程序而言, 这样可以在不运行它的前提下提供更大范围的可以重复利用的动态特性。
在以前, 我们为了查找程序运行错误, 需要做代码审查。虽然代码审查是一个非常有效的方法, 但是它需要花费大量的时间和人力。并且它有着非常苛刻的要求, 只有经验丰富的软件测试工程师才能有较的查找缺陷。而现在, 抽象解释技术的引进, 解决了这些难题。
那么, 什么是抽象解释呢?在我看来, 首先这项技术离不开大量的数学定理, 而这些数学定理制定了规则来服务于复杂的动态系统——嵌入式应用软件。这样, 抽象解释并没有具体地分析这个程序的每一个细节, 而是使用了更加全面的方法——抽象来表示这个程序的状态。而且, 它为此指定了使用时的规范——对抽象的解释, 即抽象解释。
有了抽象解释, 运行错误这个一直困扰着程序员的难题就基本解开了。当使用抽象解释检测运行错误的时候, 它会在这个程序运行、调试甚至加载之前, 就完成对该程序中所有可能出现的错误操作的分析与检测, 然后生成一个运行错误的列表。这一系列操作的结果会在最早的测试阶段——编译阶段就可以获得。
就因为抽象解释具有静态验证应用软件动态特性的功能, 所以它有着以下的优点:
(1) 可实现自动化测试, 只需要提供源代码, 无需设计用例和代码插桩。
(2) 使测试工作提前到编译阶段, 错误发现的越早, 软件修改的成本就越低, 不仅提高了效率, 也节省了财力人力和整个软件的开发时间。
(3) 与众不同的检测方法, 可以得到一些以前得不到的结果。
(4) 执行彻底, 检测出的错误都是运行错误。
对嵌入式软件测试技术而言, 抽象解释的引入将会是一场大的变革, 对当前大部分棘手的、无法解决的问题会有较大的作用和成效。但是, 任何技术都有局限性, 不可能是万能的。这就需要我们长期的实验, 验证和完善。作为用户, 我们需要根据自己的具体需求来选择适合自己的测试技术和工具。
2 CODETEST测试方法
CODETEST是专为嵌入式系统设计的软件测试工具。它通过采用和改进软件打点技术, 不像纯软件那样插入一个函数, 而是直接插入一条赋值语句。因此, 它的执行时间非常短, 对被检测系统的影响也非常小。纯硬件工具从总线捕获数据的技术, CODETEST也进行了采用, 并且比其更加完善。它不再使用采样的方法, 而是直接监视系统总线, 只有程序运行到它的插入点时才会主动在数据总线上把数据捕捉回来。所以, CODETEST可以同时对多个任务进行分析, 而且还可以精确地得出被检测程序执行的最大、最小和平均时间。对于各个函数或者任务之间的调用情况, 也能够精确地显示出来。同时它还可以动态地跟踪内存的分配情况。另外, CODETEST还能够实时的在系统环境下测试各种覆盖率指标, 掌握当前代码测试覆盖的真实情况。
基于CODETEST的这一种嵌入式软件测试技术对诸如软件打点技术、从总线捕捉数据技术等进行了改进。这些原理上的优势, 使得CODETEST测试方法具有了强大的性能分析、内存分析、覆盖率分析和代码跟踪能力。如果可以适当地借助CODETEST测试工具, 将可以获得大量的、实时的、可靠的测试结果, 借此来发现嵌入式软件运行过程以及实现中的不足之处, 并对其进行进一步的优化、改进。
3 探索性测试方法
对嵌入式系统来说, 软件的作用越来越大。因此, 一个软件的质量, 将直接关系到系统运行的成败, 甚至关系到设备以及人员的安全。如今用户对嵌入式系统软件质量要求越来越高, 因此, 软件测试也成为嵌入式系统完成中必不可少的环节。
探索性测试可以在短时间内, 甚至在文档不完善的情况下, 充分发挥测试人员的经验和能力, 快速并且高质量地完成软件测试的任务。到目前为止, 这种测试方法已经形成了一套管理方法和应用模型, 并且已经在微软等多个公司开展了成功的实践。可以说, 探索性测试方法比其他方法更注重实用性, 所以对它大部分的研究也都集中于实际应用方面而非理论研究。
嵌入式系统软件有着一系列现实问题, 比如需求变化快, 软件文档缺乏, 测试周期短等等。而解决这一系列问题, 探索性测试就是可行的手段之一。为了让人们恰当地使用, 需要积累和总结探索性测试的一般性应用方法体系, 并且要探讨它与嵌入式系统软件测试体系的联系和冲突。然后在这样的基础上, 提出更加适用于嵌入式系统软件测试的探索性测试应用模型。
如今, 探索性测试已经成功在互联网和桌面应用上完成了实践, 但是在嵌入式领域的应用还并不是很多。所以在进行嵌入式系统软件测试中使用探索性测试技术时, 应该注意:
(1) 要重视探索性测试的过程管理和注意更新相应的文档。以保证测试过程受控, 保留测试阶段性成果。
(2) 结合具体的领域的相关信息, 有助于团队新成员快速熟悉被测系统, 也可以提高探索性测试的效率。
(3) 要针对特定的测试团队和项目制定具体的策略。
4 结语
除了以上说的这三种测试方法, 较为先进的还有交互式开发测试方法, 使用它的优点在于可以更为全面的检测系统, 到达系统深层的部分。另外, 我们大部分测试时测试的都不是单独一个项目, 而是许多项目需要同时进行, 交互式开发方法能够完美的解决这个问题, 可以单项同时进行, 大大的减少了测试人员的工作量, 节约了时间和成本。
这些方法都各有各的优势, 但是, 不管是哪一种, 都得经过长期的实践研究, 需要时间去改正, 去完善。
摘要：随着自动化技术的不断发展, 近年来, 嵌入式软件测试变得越来越重要。由于嵌入式软件自身的复杂性、多样性, 软件开发成本高、周期短等特点, 先进的软件测试方法的应用是十分必要的。
关键词：软件测试,嵌入式,应用
参考文献
[1]常硕.抽象解释技术在嵌入式软件测试中的应用[J].中国测试技术, 2007 (06) .
[2]任志伟.嵌入式软件测试技术研究[J].软件导刊, 2013 (09) .
浅谈交换机嵌入式系统的离线测试 篇10
嵌入式系统是“执行专用功能并被内部计算机控制的设备或者系统, 嵌入式系统不能使用通用型计算机, 而且运行的是固化的软件, 用术语表示就是固件, 终端用户很难或者不可能改变固件。”按照历史性、本质性、普遍性要求, 嵌入式系统应定义为:“嵌入到对象体系中的专用计算机系统”。
二、离线单板硬件测试概述
在宽带交换机系统中, 离线测试包括自检测试和一般的离线测试。自检测试是单板初始化完成后为了保证板子的正确运转进行的测试。它主要包括看门狗测试、快速硬件器件测试和下载通路测试。快速硬件测试完成寄存器测试和单板上单个硬件设备测试, 其中又包括许多测试项。如果某一测试项测试失败, 整个测试就会停止直到看门狗超时重启系统。下载测试是为了保证软件下载功能能正常工作而进行的测试。这项测试主要完成通信接口收发数据测试、中断功能测试。而一般的离线测试是在出厂检验、开发阶段中的检测和维修诊断时对上述的各测试项进行更具体的测试, 以定位单板上的出错位置。
三、离线测试方法
1. 看门狗测试
在做任何一项硬件测试之前必须完成看门狗测试。这是因为一项硬件测试失败之后需要重启系统, 而硬件测试的失败通常是以看门狗超时为判断条件的。这就需要看门狗在硬件测试时能正常工作。看门狗测试方法是设置并激活一个1秒的看门狗, 等待1秒后系统重启。
2. Flash测试
在Flash中可存放程序, 也可以存放数据。在烧录Flash时, 可存放预先计算好的checksum值。要测试Flash时, 程序重新计算checksum, 然后与预先存放的值进行比较。数据Flash的测试方法有两种。一种是非破坏性的基本测试, 主要是checksum测试。另一种是破坏性的扩展测试, 包括读写测试和地址/数据总线测试, 具体方法与内存测试一致。基本测试可在系统自检时使用, 扩展测试可在维修诊断时采用。
3. 内存测试
内存测试可分为三类: (1) …数据总线测试:…将0001循环左移并写入内存, 然后读出并比较测试。 (2) 内存区测试:…对内存所有存储单元进行读写测试 (读写5555H和AAAAH测试) 。 (3) 地址总线测试:对内存所有存储单元进行地址累加测试。从RAM的基地址起, 在每一个存储单元 (按照总线宽度) 中写入不同的值 (递增值) , 地址递增, 直至所有的存储单元都保存不同的内容, 然后读出并进行检验。地址总线测试还可采用快速测试的方法:对0x1地址的内存单元写入地址值0x1, 地址值循环左移, 依次将相应的地址值写入相应的内存地址, 最后检验。
4. 主控芯片测试
主控芯片测试主要是对主控芯片进行定时器测试、寄存器测试、中断测试和片内RAM测试。寄存器测试是对一些特殊寄存器的功能进行测试, 以验证CPU寄存器是否能正常工作。中断测试是人为产生一些硬件中断, 检测主控芯片对中断的反应, 是否能及时标志中断寄存器的相应标志位。片内内存测试则遵循一般内存测试规则。
5. PCI总线测试
PCI总线常用于连接处理器和各类外设。它提供了一个低时延路径, 使处理器能够直接存取任何映射在存储器或I/O地址空间的PCI设备。它还提供一个高带宽路径, 允许PCI主设备直接到主存储器存取。测试方法是先测试是否能正确读写PCI配置空间寄存器, 然后测试内存映射是否可以在两端正确读写。
6. 综合测试方法
目前大型的嵌入式系统大部分是分布式处理系统, 由多个模块协同工作完成复杂的功能, 模块之间通过网络互联。一般将整个系统分成3个不同的层次:设备层、系统层和应用层。针对这3个层次, 系统的离线综合测试可以通过互通性测试、功能测试和性能测试来进行。
7. 互通性测试
互通性测试包括物理连通性和一致性的测试, 确保系统中的各模块之间进行互联时不会出现问题。物理连通性和一致性的测试是最基本的网络系统测试内容, 其中主要是线缆测试, …用以查明所测线缆及布线是否符合设计要求和国际标准。在宽带交换机系统中, 互通性测试由主控板按照网络连接的层次, 依次发送消息给各块PBA单板, 等待它们的回复。如果主控板能在规定时间内收到回复, 说明从主控板到该单板的网络连线正确。同时, 主控板从PBA的回复中也获取了有关单板的相关信息, 为下一步的功能测试和性能测试奠定了基础。
8. 功能测试
在整个系统内部的互通性测试完成之后, 接着要进行功能测试, 目的是检验设备能否完成它应该具备的功能。设备不同, 其所要进行的功能测试也相应变化。如果单板硬件工作没有异常, 再由主控板启动单板, 执行其所具有的特定功能。
9. 性能测试
完成系统设备测试和网络互通性测试之后就可以在系统上加载各种应用。性能测试是综合测试中最高层次的测试内容, 主要测试系统对应用的支持水平。性能测试有不同的分类方法。在宽带交换机系统中采用了仿真的方法, 在实际的机架环境中, 由测试集中的第一块单板主动发送数据包, 进行环回测试, 主要进行的是数据链路层的测试, 包括流量分析、错误数据统计等。
以上介绍了宽带交换机系统中嵌入式系统实现单板硬件测试的一些方法和系统离线集成测试模型。在具体的开发中, 用这些测试在设计阶段尽早地检查出了设计方面的问题。在维护阶段, 这些测试有效地定位了现场发现的问题。这些测试对宽带交换机系统的可靠性起到了非常重要的作用, 保证了系统在现场安全稳定的工作。
摘要：随着嵌入式系统的发展, 迫切需要在嵌入式系统开发阶段对嵌入式系统进行离线测试与分析, 以保证系统的软件应用程序、硬件具有兼容性、高可靠性和高可用性, 迅速发现并准确定位系统中存在的问题。
关键词：交换机,嵌入式系统,离线测试
参考文献
[1]PCI Local Bus Specification Revision 2.2 December 18, 1998 Copyright 1992, 1993, 1995, 1998 PCI Special Interest Group
嵌入式系统测试 篇11
1、研制测试平台的必要性
研制第三方配置项测试独立的测试平台的必要性主要包含以下几点:
(1) 受设计条件限制, 第三方配置项测试无法注入全面的测试激励, 对软件的性能测试、接口测试、安全性测试、可靠性测试等往往需要进行很多异常测试, 来验证软件对异常处理的正确性, 而实装平台上的软件通常已经固化, 无法模拟异常测试输入, 同时对相关的测试输出缺乏直观有效的观测对比手段, 研制独立的测试平台有利于测试的全面性;
(2) 某些应用于特殊场合的嵌入式系统 (如航空航天设备、国防装备等) , 研制任务重、研制周期短, 其软件开发, 系统联试, 第三方配置项测试等往往需要并行进行, 而供各方使用的实装平台往往只有一套, 无法同时满足各方的要求, 研制独立的测试平台有利于第三方测试的有效进行;
(3) 由于某些嵌入式系统的保密性要求, 其试验往往在条件差, 环境恶劣的场所进行, 且试验繁忙, 测试工作只能见缝插针进行, 不利于测试人员长期现场工作, 以及测试的全面充分。
2、接口转换计算机软件测试平台概述
接口转换计算机软件运行在接口转换及时统插件的接口转换计算机中, 在VxWorks实时操作系统支持下运行, 结合硬件电路实现嵌入式系统中各设备的接口适配和自动信息交换。
接口转换计算机软件接口配置如图1所示:
(1) 网络接口1:内部接口, 接口转换及时统插件通过嵌入式系统内部控制总线与系统内部各设备进行网络通信; (2) 网络接口2:外部接口, 接口转换及时统插件通过双冗余网络接口与嵌入式系统外部各设备进行网络通信; (3) RS-422串行通讯接口1:外部接口, 接口转换及时统插件通过串口与串口通讯设备进行通讯, 完成嵌入式系统与串口通讯设备之间的信息交换; (4) RS-422串行通讯接口2:外部接口, 接口转换及时统插件通过串口接收时统设备的准秒脉冲。
针对接口转换计算机软件第三方测评需要, 建设接口转换计算机软件测试平台, 对被测软件的功能、性能、接口、边界、强度、安全性等方面开展配置项测试。测试平台的研制包括被测件运行环境、外围通讯环境、测试管理环境和辅助环境四个主要组成部分的建设。
3、平台主要功能和技术特点
3.1 主要功能
测试平台的建立主要功能是模拟以下平台环境: (1) 建设接口转换及时统插件与武器系统内部各设备的内部网络通信环境; (2) 建设接口转换及时统插件与系统外部设备的外部网络通信环境; (3) 建设接口转换计算机与串口通讯设备的串口通讯环境; (4) 建设接口转换计算机与时统设备的串口通讯环境; (5) 实现UDP网络协议下的单播、组播、广播通讯; (6) 建设接口、边界、安全性异常状态的测试激励环境; (7) 建设可录取、监听、解析、回放的测试输出观测环境; (8) 关键输入输出单位的人机交互建设。
3.2 技术特点
接口转换计算机软件第三方配置项测试平台建设除了能够实现与实装设备上一致的所有网络通讯、串口通讯以及正常的功能、性能、接口等测试以外, 还包括以下几个技术特点:
(1) 开发外围模拟器, 使各模拟器功能更加全面, 可以模拟实装设备上无法实现的接口、边界、安全性等异常状态的测试激励, 来验证软件对异常处理的正确性;
(2) 通过模拟器的开发实现关键输入输出单位的人机交互、各状态参数的设置与观测, 通过安装EtherPeek网络分析软件, 对被测件交互报文进行实时收录与解析, 提供测试数据的观察与记录, 实现一个友好的测试输入、输出观测环境;
(3) 平台留有可扩展接口, 可在相应基础上进一步扩展, 增加外围模拟器组件和接口关系, 构建后续相关系列测试环境, 实现良好的可扩展性。
4、平台结构及组成
测试平台根据接口转换计算机软件的运行环境和外围接口, 实现对测试所需信号信息的激励、采集, 完成数据通讯。平台示意见下图2, 组成主要包括:被测件运行环境、外围通讯设备、测试管理环境、辅助环境。
接口转换计算机软件所运行的硬件环境包括接口转换计算机和时统板组成。接口转换计算机主要由一块PC104组成, 必须满足普军级要求, 同时满足一定的硬件配置要求, 包括CPU主频、内存容量、存储盘容量等以及包含所需要的相应接口。接口转换及时统板主要包括CPLD集成电路、时统产生芯片、译码电路以及插座等相关硬件组成。
根据接口转换计算机软件需求说明、接口协议等要求, 确定外围各模拟器的通讯需求和功能, 建立被测件外围接口通讯环境, 实现了: (1) 被测件外围通讯接口; (2) 接口、边界、安全性异常状态的设置与观测; (3) 关键输入输出单位的人机交互。
外围各模拟器的硬件环境主要是满足一定配置要求且性能稳定的工控机, 相应的硬件环境要求主要包括CPU主频、内存容量、硬盘容量等配置要求, 以及包含所需要的相应网络接口和串口等接口。x'�
各模拟器的软件环境为Visual Studio 2008 C++, 组装后实现模拟各外围设备与接口转换计算机软件的信息交互。
5、平台校验及测试
5.1 平台硬件
平台硬件校验主要验证被测件运行环境和模拟器运行环境是否符合平台硬件环境及外围各模拟器的硬件环境指标。
经校验接口转换计算机软件测试平台的被测件运行环境和模拟器运行环境均符合相应硬件环境指标。
平台软件的验证主要比对相同的测试
5.2 平台软件
用例在时装环境和在第三方测试平台上的运行情况, 查看两者的执行结果是否一致或在偏差范围内。接口转换计算机软件测试平台的验证情况如下:
(1) 选取部分正常功能测试用例分别在时装环境和接口转换计算机软件测试平台上执行, 正常功能在测试平台上的执行正确, 执行结果与实装环境下执行情况一致;
(2) 选取部分性能测试用例分别在时装环境和接口转换计算机软件测试平台上执行, 被测件在测试平台上的运行性能满足指标要求;
(3) 选取部分原来在实装环境下无法执行的异常接口和边界等测试用例在测试平台环境上执行, 经测试, 测试平台环境上可以完成原测试无法执行的异常接口和边界测试等。
6、结语
针对接口转换计算机软件的测试需求, 在借鉴通用测试工具技术的基础上实现了一个测试平台, 为测试人员提供了一个良好的测试环境, 平台具有很好的针对性和适用性。在使用接口转换计算机软件测试平台对接口转换计算机软件配置项进行功能、性能等测试时, 系统运行稳定, 不仅完成了原来在实装环境上的全套测试用例, 而且能够执行在实装环境上无法进行的异常测试用例, 为软件的可靠性提供了保障。
摘要：嵌入式系统的专用程度和可靠性要求高, 常用的测试方法不能对其进行有效和完善的测试。本文分析了嵌入式系统接口转换计算机软件测试要求, 研制了第三方配置项测试独立的测试平台, 包括测试平台的主要功能、技术特点、平台结构和组成、以及平台的校验测试, 并在该平台上完成了接口转换计算机软件的第三方配置项测试实验, 验证该平台具有很好的针对性和适用性。
关键词：接口转换计算机软件,软件测试,嵌入式系统
参考文献
[1]吕宝林, 王晓东等.航天遥感相机TDI CCD成像系统逻辑软件测试平台的设计.硅谷, 2010, (02)
[2]池云.嵌入式软件测试研究.中国科技信息, 2009, (02) .