机载设备驱动软件自动化测试环境框架设计

摘要
#

针对当前机载设备驱动软件测试工程实践中操作复杂、重复性强、工作量大、效率低下的问题，在分析机载设备驱动软件特点及驱动软件测试环境需求基础上，提出一种基于驱动源代码分析和驱动功能配置的自动化测试环境框架，采用不同设计视图系统描述该框架下的任务结构、工作过程和物理结构，解决驱动软件的自动测试的难题。基于该框架开发一套原型验证工具，在实际项目中取得了良好的应用效果。

引言
#

设备驱动软件作为嵌入式操作系统的重要组成部分，承担着底层硬件设备与上层应用软件之间传输数据的重要作用，是应用软件完成对外信息交互的基础。因此在开展机载软件定型测评时，设备驱动软件需独立开展配置项级的测试工作。

当前机载设备接口种类和数量越来越多，实现机制也越来越复杂，开展驱动软件测试时，需要测试人员对每一个驱动API函数分别进行参数有效性、返回值正确性、数据收发准确性等方面的测试脚本设计，并为每一个脚本设计触发条件，编译下载后在辅助测试接口中触发激励，并到硬件环境中分别进行数据的收发，查看测试脚本对数据的响应。该测试过程操作繁琐易出错、重复性强且工作量巨大。当前辅助开展嵌入式软件黑盒测试的工具很多，但均不具备设备驱动软件自动化测试能力，无法支持以API接口为测试对象的软件测试工作。在此背景下，本文提出了一种嵌入式设备驱动软件自动化测试环境构建方法，辅助开展驱动软件测试工作。

机载驱动软件开发及其环境
#

机载驱动软件开发特点
#

机载嵌入式软件多采用VxWorks实时操作系统，其驱动软件也基于VxWorks设备驱动结构设计。在VxWorks中进行硬件控制有两类方式，一类采用VxWorks为设备驱动软件定制的规则，向操作系统注册驱动软件后使用；另一类为直接采用自定义的驱动软件，绕过操作系统的管理直接使用。

基于VxWorks设备管理规则开发的驱动程序，由于其统一的文件格式操作，对复杂设备进行操作时，需频繁查阅编程手册、调用IOctrl函数实现控制，造成程序的可维护性和易读性较差，同时驱动程序开发过程需遵循VxWorks设备管理规则，且设备数量存在限制，因此，在航空实际工程应用中并未得到大面积采纳。

自定义结构的设备驱动程序实现较为简单直观，直接将对硬件地址的访问进行功能划分和函数封装，形成了一系列具有独立功能的API函数集。该类驱动软件一般包含数量众多的API函数，各API函数之间存在着特定的逻辑调用关系，每个API函数又包含不同数量和类型的参数，每个参数之间又存在着一定的逻辑关系，因此应用软件开发人员使用该类驱动软件时，需逐一考虑各API的正常、异常参数和使用场景，无形中增加了开发人员工作量，也给应用软件带来一定风险和隐患。为解决上述问题，需对驱动API函数进行充分的测试，保证其即使在异常的调用情况下也能够合理的避免错误发生，提高驱动API函数的安全性，降低应用软件的开发风险。

机载驱动软件运行环境
#

机载驱动软件在软件工程化管理中虽被当作独立软件配置项管理，但其运行过程却无法独立，需由应用软件调用，与应用软件一起形成可执行目标码在目标CPU上运行。机载驱动软件通常不直接对硬件设备进行访问，而是通过传输层间接的访问物理硬件。其典型运行环境如图１所示。

机载驱动软件的典型运行环境由高层CPU、传输层和外部设备构成。

高层CPU上加载驱动软件、操作系统、板级支持软件和应用软件。驱动软件向应用软件提供访问各外设的API接口集，而驱动何种设备、驱动方式、驱动内容均由应用软件调用API时决定，驱动软件仅将应用软件的设备访问数据转换为相应的地址、指令和数据，通过内部总线发送给传输层CPU。传输层由若干个承担着控制不同设备的CPU或FPGA等控制模块组成，在各个传输层CPU或FPGA上分别运行特定外部设备的控制软件或逻辑，按照外部设备的控制时序将高层驱动软件下发的地址、指令和数据解析分发，形成外部设备能够识别的控制信号，实现外部设备的控制。外部设备通常是系列ASIC构成的总线接口，在航空机载设备中通常包括1553B、ＡFDX、1394B、FC等总线。

机载驱动软件测试环境需求
#

机载驱动软件具有功能单一、接口众多、参数复杂、驱动耦合等特点，在对该类软件开展软件测试时，需对众多的API接口函数分别设计调用过程，形成测试脚本并覆盖性地进行参数、返回值、功能、关联关系等方面的测试，然后在硬件接口环境中查看设备的响应结果。这一测试过程在软件工程中被定义为测试设计、测试执行和测试总结过程，与此相对应，在实际工程中对完整的机载驱动软件测试环境提出了测试设计、测试执行、测试总结等方面的需求。

测试设计需求

驱动软件测试是以驱动软件中的各个API接口函数为测试对象的活动，因此需要将各API调用至特定的应用场景下进行测试。在测试之前由测试人员设计能够覆盖被测API参数、返回值、功能及相关联API的测试脚本程序，实现驱动API接口的调用，然后与被测驱动软件一起编译并下载至高层CPU中运行。除此之外，测试脚本还需具备对测试执行的控制能力，使得测试人员能够根据测试需要实现测试过程的控制。

测试执行需求

驱动软件所实现的总线数据发送和接收，在交联环境中均体现为数据的收发，因此需通过交联环境作为测试执行载体进行数据收发实现被测驱动软件的功能性验证。而机载交联环境通常具有接口复杂、种类繁多、数量庞大、实时性高等特点，所以为了有效模拟机载真实设备、满足被测系统的环境要求，交联环境也应具备同样复杂众多的接口以及强实时性的支撑能力。

测试总结需求

通过测试脚本调用驱动API函数，通过测试环境实现驱动软件数据的收发，最终还需要通过查看总结API运行结果才能完成一个完整的测试过程。驱动软件运行结果主要包含两项内容，即API返回值结果和API的功能运行结果。针对返回值开展测试时，需按照返回值类型获取结果并呈报给测试人员。API的功能运行结果是指驱动软件实际完成的硬件设备操作，如数据收发等。为测试API功能完成情况，需根据驱动软件的输入输出性质分别制定不同的考核准则，如被测API为对外发送数据功能，则应在交联环境中验证接收到的数据与所发送数据的一致性；被测API若为接收数据功能，则应在交联环境中发送数据，通过脚本上报并查看接收到的数据与所发数据的一致性。因此，测试环境对测试脚本设计提出了结果查看需求。

框架设计
#

工作原理
#

构建分布式自动化的驱动测试环境，以驱动软件的源代码和需求为输入，以测试报告为输出，其工作原理如图２所示。

将被测的软件源代码导入测试环境后，由驱动解析器对源代码进行分解、转换，形成形式化的驱动API函数；由测试员对驱动软件的功能需求进行配置，并与API函数一起经同步处理后由测试脚本服务生成测试脚本文件，测试脚本中除对API函数的调用外，还包含了必要的测试控制代码、同步代码及测试结果上报类代码，该测试脚本与源文件一起编译后下载至目标系统中运行。同时，自动化测试环境还将API函数及其配置信息与总线接口进行映射管理，随同测试中需要的初始测试数据一起下载到具有执行能力的驱动数据库中。测试初始化时，驱动数据库根据总线配置信息进行IO通讯的初始化，并与目标系统的辅助测试接口建立连接。测试起动时，由驱动数据库发起测试执行命令，经IO通讯和辅助测试接口传至目标系统的测试脚本中。测试脚本接受该命令后，开始循环执行测试脚本中对API测试的程序部分。测试脚本对API函数进行测试时通过驱动接口与测试环境中的IO通讯接口进行交互，实现API函数中的测试数据与驱动数据库的测试数据的互通。测试脚本的最终测试结果包含API返回值结果和功能运行结果两部分，均通过IO通讯上传至驱动数据库后，统一提交至结果分析模块中进行测试结果的判定和显示，并生成测试报告。

基于上述工作原理，采用ＵＭＬ建模方法的不同视图模型分别对驱动该软件自动化测试环境的任务结构、工作过程和物理结构进行框架设计描述。

任务结构设计
#

将驱动软件自动化测试环境按照任务层次进行结构划分，划分为功能层、服务层和执行层，每层任务中又通过多种类实现，驱动软件测试环境中主要的系统类图如图３所示。

功能层设计
#

在功能层上，主要完成用户界面操作，包括驱动源文件的导入、需求功能的配置、测试过程的控制以及测试结果的分析。

驱动源文件的导入主要完成对源文件字段解析和形式化处理。

需求配置工作是整个测试环境的基础，由测试员将解析后的各API分别进行功能属性配置、关联关系配置；其中功能属性配置包括对API进行发送、接收、初始化、中断或其它服务性质的配置，涉及参数时还需对各参数的表达范围、有效范围、参数关联性、指针等进行配置；关联关系配置包括被测API与其它API之间的关联性配置、调用顺序等API层面配置，以及API参数与总线接口之间的映射配置。测试控制用于分别激活服务层和执行层的相关功能，包括测试初始化、测试开始和测试暂停３个操作。测试初始化的任务是触发服务层进行测试脚本初始化和测试数据初始化，然后触发执行层进行驱动数据库初始化和总线初始化，其输入为需求配置过程获取的配置信息，输出为可编译下载的测试脚本源文件、可被执行的测试数据和就绪的执行层IO总线。测试开始任务通过执行层的IO通讯向被测系统发送一个同步启动码，激活被测系统中插装的测试脚本，由目标系统不断触发执行层进行数据收发，直到完成测试。测试暂停采用异步触发同步收敛方式将当前的测试任务暂停，通过执行层对目标系统分别下发暂停命令中止当前的测试任务。

数据分析任务在测试结束后用于对测试数据的总结，是整个测试过程的结尾。该任务收集测试过程中的同步标识、测试数据和结果数据，并与被测的API驱动进行自动匹配，依据需求配置时的范围设置信息判断执行结果并生成测试报告。

服务层设计
#

服务层对用户不可见，是由功能层操作触发的内部任务，主要由测试脚本、测试数据和总线管理３大服务任务完成。

测试脚本服务在功能层测试初始化的触发下，提取测试数据服务中存储的需求配置信息、API形式化信息，按照预先制定的策略生成测试脚本文件。测试脚本服务除在测试脚本文件中模拟各种复杂应用场景对API进行调用外，还要在测试脚本中植入用于与测试环境进行同步和命令交互的少量代码，如：测试开始命令和测试暂停命令处理、测试进度（由同步标识实现）上报、测试完成上报等代码信息，此类信息通过被测系统的辅助测试接口与测试环境交互，为测试过程同步和数据同步起到了重要作用。

测试数据服务首先将功能层中源文件导入和需求配置所产生的信息进行存储，然后向测试脚本服务提供API测试同步标识及同步数据信息，以支持API调用时所需的环境数据；向总线管理服务提供各API所依赖的总线接口动态配置信息，以支持配置类API对总线接口的控制；最后测试数据服务还提供与执行层进行数据收发的接口，下发初始测试数据，收集测试结果数据，并将全部数据上报至功能层的数据分析任务完成测试总结。

总线管理服务提取驱动测试中所需的IO通讯接口及其动态配置信息，动态管理总线接口与API参数关系，在测试执行时适应API对接口进行的不同参数配置，如通讯速率、校验方式等配置，辅助完成接口配置类API的测试工作。

执行层设计
#

执行层部署于独立的实时节点，完成测试环境与被测系统的直接交互。该层任务主要由驱动数据库和IO通讯构成。

驱动数据库将测试数据服务下发的测试数据进行本地初始化，使其在实时运行过程中能够被快速查找及应用。在测试开始后，驱动数据库接收到目标系统的脚本同步标识后，查找与同步标识匹配的测试数据，并根据同步标识确定测试数据的流向，最后通过IO通讯与目标系统完成交互。驱动数据库将执行完成的测试数据上报给服务层，用以向功能层反馈并数据分析。

IO通讯在测试初始化命令驱使下完成总线接口的初步配置，使测试环境中的IO接口具备与目标系统进行交互的相对就绪状态。所谓相对就绪即未完全就绪，仅完成IO接口创建、打开灯初始操作，在测试执行中还需针对API对总线的参数配置功能进一步实施初始化操作。在IO通讯中设置同步与命令交互接口，与目标系统的辅助测试接口连接，实现与目标系统的测试命令、同步标识、执行结果交互。

工作过程设计
#

基于系统任务结构划分的３个层次，将驱动软件自动化测试环境的工作过程设计为源文件导入与需求配置、测试初始化、编译下载、测试执行和测试中止５个阶段。

源文件导入与需求配置阶段
#

驱动软件测试环境始于对被测系统的理解，该过程由源文件导入与需求配置实现，通过时序图描述该工作过程如图４所示。在该阶段测试员通过功能层的人机交互操作实现源文件导入，并在服务层完成源文件解析和API形式化后，再次通过功能层操作实现对被测驱动软件的功能配置和关联关系配置，在配置过程中服务层将配置信息存储后向测试员报告配置结果。

测试初始化阶段
#

在完成被测驱动软件的基本配置后，由操作员发起测试初始化工作。收到测试初始化命令后，服务层依据配置信息分别生成测试脚本、测试数据。测试脚本反馈给测试员用于下一阶段编译操作，测试数据通过网络服务下发至执行层，在执行层分别开展驱动数据库的初始化和IO通讯接口的初始化，并将最终的初始化结果反馈给测试员，该阶段的顺序如图５所示。

编译下载阶段
#

测试初始化过程中产生的测试脚本文件需与驱动软件源代码联合编译、下载至目标系统中等待运行，该过程可通过开发环境手动完成，也可通过再测试环境中生成Makefile文件，调用开发环境提供的编译和下载指令自动完成。

####　测试执行阶段

目标系统在开始测试前处于等待运行状态，测试员发起执行时，网络服务将测试执行命令发送至执行层驱动数据库，并通过IO通讯接口向目标系统辅助测试端口发出执行测试命令码。目标系统接收到该命令码后，按顺序循环执行测试脚本中的各测试用例。执行测试用例时，测试脚本会首先通过辅助测试端口向测试环境IO发送用例同步标识，执行层接收该同步标识后查找对应的测试类型及其测试数据［14］。测试类型是指针对被测驱动软件功能的类型，包括接收测试、发送测试和其它测试。针对不同测试类型，执行层做出不同响应。

当测试类型为接收测试时，表明被测的驱动API为数据接收类函数，执行层需要准备必要的环境数据发送给目标系统，并通过辅助测试接口读取其数据接收结果和API返回值结果，存储在驱动数据库中，用于后续上传至功能层判定被测API接收功能的正确性。

同理，测试类型为发送测试时表明驱动API为发送类函数，由目标系统发出预置的测试数据，执行层等待接收后，将结果存储于驱动数据库中。

当测试类型为其它类型时，表明被测API为配置类函数，执行层直接按照驱动数据库中的接口配置信息对总线进行初始化，该初始化信息与测试脚本中API对接口的初始化信息相一致，即测试环境和被测系统双方均按照同一参数信息对接口进行初始化配置。然后再对已初始化的接口进行一次数据收发操作，并收集结果存储于驱动数据库。

当测试脚本中所有测试用例执行完成后，驱动数据库核对已执行的用例计数后，通过网络服务向服务层和功能层通知测试完成情况，同时上报驱动数据库。测试执行阶段的顺序如图６所示。

####　测试中止

在使用驱动软件自动化测试环境开展驱动软件测试时，可能出现因需求配置不合理而造成的测试脚本或测试数据无效的情况。在测试执行过程中发现无效测试时，为了避免继续大面积无效测试的发生，在测试环境中设置了测试暂停命令，用于中止当前不合理的测试过程。测试中止不受当前执行进度影响，可在测试开始后的任何时间由测试员发起，属于异步消息。该命令通过网络服务发送至执行层，由执行层通知目标系统，运行完当前用例脚本后，下一个用例运行前挂起脚本任务，并将运行情况反馈给执行层。执行层收到反馈后挂起驱动数据库信息，并将执行结果上报至功能层。

被中止的测试过程可以重新初始化运行，也可以在进行环境确认后，由测试员发起继续执行。

物理结构设计
#

目标被测系统通常为机载嵌入式系统，具有接口复杂、实时性强的特点，因此在进行驱动软件自动化测试环境部署时，需考虑测试环境对接口和实时性的满足情况，驱动软件自动化测试环境的组件如图７所示。

对于复杂的接口环境可通过覆盖常用航空总线接口类型并扩充足够数量的通讯IO实现，为满足测试环境的通用性，在执行层中配备航空机载设备常用总线，并统一受IO通讯服务的管理。机载设备运行环境多为VxWorks嵌入式实时操作系统，为减少测试环境与实际运行环境的差异，在执行层也采用该操作系统进行实时调度，完成驱动数据库的管理，满足总线通讯的实时性要求。因此，将测试环境中具有接口特性和强实时性要求的IO通讯、驱动数据库组件部署于实时节点计算机。

测试环境中的其它组件均无强实时性、总线接口特性方面的特殊要求，而对界面友好性、字符解析高效性等方面提出了更多要求，因此将此类组件部署于非实时节点计算机运行。

非实时节点与实时节点之间通过网络服务进行测试数据和命令的通信，其中非实时节点主要运行的是功能层和服务层任务，实时节点运行的是执行层任务。

应用实例
#

基于上述软件框架设计过程，开发设计了机载驱动软件自动化测试环境原型工具平台ADATE(Airborne Drivers’automated test environment)。在该平台中包括上位机主控软件和下位机执行软件两部分，主控软件通过友好的人机交互界面完成被测驱动软件的分析和配置、总线接口参数映射、测试脚本生成和编辑、测试过程控制、测试结果分析与报告生成等功能；执行软件部署于安装有模拟量、离散量、CAN总线、RS232/４22/４85、ARINC429、MILSTD-1553B总线接口板卡的工控机中，采用VxWorks 5.5内核使得总线通讯实时性可达1ms的通讯周期。

该平台已在某型机电管理计算机系统软件测试项目中应用，为其GJB289A驱动软件和HB6096驱动软件配置项完成大量测试工作，与纯人工测试相比，具有覆盖率高、执行速度快、发现问题多等优势，显著提高了机载驱动软件的测试效率。

结语
#

当前机载设备驱动软件测试过程中效率低下，常规自动化测试工具能够支持的过程有限，本文提出的自动化驱动软件测试环境设计方法填补了驱动软件自动化测试的空白，适用于以API函数为被测目标的嵌入式设备驱动软件测试过程。基于该方法设计的平台原型工具在工程实践中的应用验证了该方法的有效性。下一步工作中，尚需进一步完善和优化该方法和工具平台，如驱动软件需求配置的完整性一致性判断、测试脚本生成策略与算法的优化处理、测试结果判定方法优化等问题。