CN116069648A - 一种软件测试方法、系统、设备以及存储介质 - Google Patents

Abstract

本发明属于汽车软件测试技术领域，具体涉及一种软件测试方法，包括：获取所述控制器软件RTE层的接口文件；对所述接口文件进行预处理，得到接口目标文件；获取控制器软件应用层的C代码；根据所述C代码创建运行文件；根据所述接口目标文件和所述运行文件编译生成第一动态链接库文件；将所述控制器对应的车辆模型编译生成第二动态链接库文件；根据所述第一动态链接库文件和所述第二动态链接库文件构造软件测试模型。本发明通过模拟一个软件测试环境理想地模拟了基础软件层的功能，使原本支持应用层运行的与硬件强关联而复杂的基础软件层功能变得简单，使测试能够集中关注应用层策略问题，不需要关注基础软件层实现对应用层的影响。

Description

一种软件测试方法、系统、设备以及存储介质

技术领域

本发明属于汽车软件测试技术领域，具体涉及一种软件测试方法、系统、设备以及存储介质。

背景技术

汽车控制器软件的开发一般包含以下流程：模型化编程，生成C代码，集成二进制文件，烧录到控制器中，在硬件在环环境中进行功能验证。当验证发现功能实现偏差，需要从基础软件层/策略应用软件层分别定位问题，在各自层级中，依据a2l等标定地址描述文件，读取相关变量查找逻辑偏差。

目前的系统性的黑盒测试方法，有以下劣势：应用层策略的验证受基础软件及硬件开发进度的桎梏，无法与应用层策略软件开发同步；迭代周期长，应用层策略的阶段内改善，需要重复集成为二进制文件，烧录到控制器；应用层策略的验证受基础软件层的实现偏差影响。

对于符合AutoSar标准的控制器软件，在BSW(Basic Software，基础软件层)中包含各种服务/驱动，是ASW(Application Software，应用层)策略不需要关注具体实现的功能。

发明内容

鉴于以上所述现有技术的缺点，本发明的目的在于提供一种软件测试方法，使测试不依赖于不关注的硬件及BSW软件实现，且测试环境的开发能够与ASW软件开发同步。

为实现上述目的及其他相关目的，本发明提供一种软件测试方法，包括：获取所述控制器软件RTE层的接口文件；对所述接口文件进行预处理，得到接口目标文件；获取控制器软件应用层的C代码；根据所述C代码创建运行文件；根据所述接口目标文件和所述运行文件编译生成第一动态链接库文件；将所述控制器对应的车辆模型编译生成第二动态链接库文件；根据所述第一动态链接库文件和所述第二动态链接库文件构造软件测试模型。

根据本发明一具体实施例，所述对所述接口文件进行预处理，得到接口目标文件的步骤包括：筛选出所述接口文件中与所述控制器软件基础软件层有依赖关系的接口文件，并将其定义为空；对筛选后的所述接口文件按照默认值进行填充，得到所述接口目标文件。

根据本发明一具体实施例，所述根据所述C代码创建运行文件的步骤包括：根据所述C代码创建初始化函数和周期函数；根据所述控制器中软件的标定参数创建调度函数，并将所述初始化函数、周期函数以及调度函数生成对应的所述运行文件中的任务文件；根据所述控制器中软件的标定参数配置非易失性存储变量，并将其生成对应的所述运行文件中的存储文件。

根据本发明一具体实施例，所述接口文件包括：复杂驱动层接口定义文件，I/O硬件抽象层接口定义文件，通信服务层接口定义文件，存储服务层接口定义文件，OS服务层接口定义文件以及应用层SWC接口定义文件。

根据本发明一具体实施例，所述接口目标文件包括：I/O硬件抽象层接口定义文件、通信服务层接口定义文件以及应用层SWC接口定义文件。

根据本发明一具体实施例，通过Davinci工具获取所述控制器软件RTE层的接口文件。

根据本发明一具体实施例，通过Silver的“sbsBuild.exe”指令编译生成所述第一动态链接库文件；通过所述Silver的“SimBuild.dll”组件编译生成所述第二动态链接库文件；且所述第一动态链接库文件和所述第二动态链接库文件在所述Silver环境中生成所述软件测试模型。

一种软件测试系统，包括：接口文件提取模块，用于获取所述控制器软件RTE层的接口文件；接口文件处理模块，用于对所述接口文件进行预处理，得到接口目标文件；C代码提取模块，用于获取控制器软件应用层的C代码；运行配置模块，用于根据所述C代码创建运行文件；第一模型生成模块，用于根据所述接口目标文件和所述运行文件编译生成第一动态链接库文件；第二模型生成模块，用于将所述控制器对应的车辆模型编译生成第二动态链接库文件；第三模型生成模块，用于根据所述第一动态链接库文件和所述第二动态链接库文件构造软件测试模型。

一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述所述任一项所述方法的步骤。

一种计算机可读介质，其上存储有指令，所述指令由处理器加载并执行如上述所述任一项所述的方法。

本发明的技术效果在于，通过模拟一个软件测试环境使测试不依赖于不关注的硬件及基础应用层的软件实现，且测试环境的开发能够与应用层软件开发同步。同时理想地模拟了基础软件层的功能，使原本支持应用层运行的与硬件强关联而复杂的基础软件层功能变得简单，使测试能够集中关注应用层策略问题，不需要关注基础软件层实现对应用层的影响。进一步使测试过程小阶段内迭代快捷，不需要重新集成二进制文件。

附图说明

图1为本发明所提供的一种软件测试方法一具体实施例的流程示意图；

图2为本发明所提供的一种软件测试系统一具体实施例的流程示意图；

图3为本发明所提供的一种电子设备一具体实施例的结构示意图。

具体实施方式

以下将参照附图和优选实施例来说明本发明的实施方式，本领域技术人员可由本说明书中所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。应当理解，优选实施例仅为了说明本发明，而不是为了限制本发明的保护范围。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

在下文描述中，探讨了大量细节，以提供对本发明实施例的更透彻的解释，然而，对本领域技术人员来说，可以在没有这些具体细节的情况下实施本发明的实施例是显而易见的，在其他实施例中，以方框图的形式而不是以细节的形式来示出公知的结构和设备，以避免使本发明的实施例难以理解。

首先需要说明的是，为了使本技术领域的人员能够更好地理解本申请方案，对本申请实施例中的技术方案进行清楚、完整的描述。

AUTOSAR，全称为Automotive Open System Architecture，即汽车开放系统架构。它是由全球各家汽车制造商、零部件供应商以及各种研究、服务机构共同参与的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器(ECU)标准软件架构。

在AUTOSAR架构中，系统软件被规规整整的进行了分层，整个架构从上到下分层依次为：应用层(Application Software，ASW)，运行时环境(Runtime Environment，RTE)，基础软件层(Basic Software，BSW)，微控制器(Microcontroller)。每层之间为保持独立性，每一层只能调用下一层的接口，并为其上一层提供接口。分层架构是实现软硬件分离的关键，它也使得汽车嵌入式系统控制软件开发者，得以在ECU软件开发与验证过程中，摆脱对硬件系统的依赖。

AUTOSAR的出现极大的解决了车企和供应商们最大的苦恼，大大降低了软硬件之间的耦合度。它所带来的好处是显而易见的：有利于提高软件的复用度，使软件可以跨平台复用；便于软件的交换与更新；软件功能可以进行先期架构级别的定义和验证，从而减少开发错误；减少手工代码量，减轻测试验证负担，提高软件质量；使用一种标准化的数据交换格式，方便各个公司之间的交流合作。这些优势，使得各个企业在保证软件质量的同时，大大降低了开发的风险与成本。

ASW包含若干个软件组件(Software Component，SWC)，软件组件间通过端口(Port)进行交互。每个软件组件可以包含一个或者多个运行实体(Runnable Entity，RE)，运行实体中封装了相关控制算法，其可由RTE事件(RTE Event)触发。主机厂(整车厂)一般会掌握主要控制器的应用层开发。因为软件定义汽车的时代，主要控制器会影响车的驾驶性、舒适性、经济性等一系列指标，它蕴含着整车厂的传承与风格。

RTE作为ASW与BSW交互的桥梁，为软硬件分离提供了可能。RTE可以实现软件组件间、基础软件间以及软件组件与基础软件之间的通信。RTE封装了基础软件层的通信和服务，为ASW组件提供了标准化的基础软件和通信接口，使得ASW可以通过RTE接口函数调用基础软件的服务。此外，RTE抽象了ECU之间的通信，即RTE通过使用标准化的接口将其统一为软件组件之间的通信。由于RTE的实现与具体ECU相关，所以必须为每个ECU分别实现。

BSW包含众多基础软件模块，它所负责的是ECU非应用相关的功能。BSW最重要的功能之一是ECU间的通信，即信号交互。BSW又可分为四层，即服务层(Services Layer)、ECU抽象层(ECU Abstraction Layer)、微控制器抽象层(Microcontroller Abstraction Layer，MCAL)和复杂驱动(Complex Drivers)。上述各层又由一系列基础软件组件构成，包括系统服务(System Services)、存储器服务(Memory Services)、通信服务(CommunicationServices)等，主要用于提供基础软件服务，包括标准化的系统功能和功能接口。

本申请实施例通过模拟RTE层与ASW/BSW交互的接口，这些接口函数依据AutoSar标准，能够实现普适性和提前性，符合AutoSar标准的控制器软件，依据所述控制器具体信息，实现Rte层接口定义和提前于BSW开发的验证。同时根据控制器中软件的标定参数配置RTE层与BSW交互的接口，与被控车辆模型仿真的总线信号/硬线信号匹配形成闭环，模拟BSW OS层的上电初始化/周期调度/EEProm，实现ASW与BSW的解耦，使得测试不依赖于不关注的硬件及BSW软件实现，且测试环境的开发能够与ASW软件开发同步。

实施例1

请参见图1所示，一种软件测试方法，包括：

步骤S10，获取所述控制器软件RTE层的接口文件。

RTE层作为应用层和基础软件层之间的桥梁，为应用层软件组件提供了标准化的基础软件和通信接口，使得应用层可以通过RTE接口函数调用基础软件层的服务。因此，通过Davinci工具编译生成所述RTE层的接口文件，用来配合所述运行文件构造软件正常运行的环境。具体的，所述接口文件包括有：复杂驱动层接口定义文件，I/O硬件抽象层接口定义文件，通信服务层接口定义文件，存储服务层接口定义文件，OS服务层接口定义文件以及应用层SWC接口定义文件。由于大多接口文件实际不参与软件正常运行，因此需要进行筛选并去除，从而使原本支持应用层运行的与硬件强关联而复杂的基础软件层功能变得简单，使测试能够集中关注应用层策略问题，不需要关注基础软件层实现对应用层的影响。

步骤S20，对所述接口文件进行预处理，得到接口目标文件。具体步骤如下：

筛选出所述接口文件与所述基础软件层有依赖关系且无用的接口文件，并将其定义为空，从而完成简化。进一步的，筛选后的接口文件中可能存在缺失全局变量或者数据类型定义，因此为保证创建软件测试环境能够正常运行，按照设定的默认值对接口文件进行补充，使其完善，最终得到所述目标接口文件。具体的，所述目标接口文件至少包括：所述I/O硬件抽象层接口定义文件、通信服务层接口定义文件以及应用层SWC接口定义文件。

步骤S30，获取控制器软件应用层的C代码。

所述应用层中包含若干个软体组件SWC，软件组件不仅仅是应用层的核心，也是一些抽象层、复杂驱动层等实现的载体。软体组件之间通过端口进行交互，软件组件的端口根据输入/输出方向可分为需型端口(Require Port，RPort)与供型端口(Provide Port，PPort)以及供需端口(Provide and Require Port，PRPort)。其中，需型端口，用于从其他软件组件获得所需数据或者所请求的操作。供型端口，用于对外提供某种数据或者某类操作。供需端口，兼有需型端口与供型端口的特性。进一步，所述软体组件SWC包含一个或多个运行实体，运行实体中封装有控制算法，且每个运行实体都会被赋予一个RTE事件，这个事件可以引发这个运行实体的执行。因此，编译生成所述应用层的代码，解析所述C代码去构造软件的运行环境。

步骤S40，根据所述C代码创建运行文件。具体步骤如下：

识别并提取所述软体组件中软件运行的初始化函数以及周期函数，并根据所述控制器中软件的标定参数去创建软件运行的调度函数。具体的，所述标定参数即所述控制器中不同软件固定运行的参数条件。同时将所述初始化函数、周期函数以及调度函数生成对应的任务文件Task.c。进一步的，根据所述控制器中软件的标定参数去配置软件的非易失性存储变量。具体的，软件运行时，若关闭则会失去当前的运行进度，通过复制控制器中软件存储的标定参数配置软件的非易失性存储变量。同时将所述非易失性存储变量生成对应的存储文件NVMCtrl.c。其中，所述任务文件和存储文件整合为所述运行文件。

因此，通过编译生成所述应用层、RTE层以及基础软件层中的软件运行参数文件来模拟软件测试环境。

步骤S50，根据所述接口目标文件和所述运行文件编译生成第一动态链接库文件。

同时，为实现软件的正常运行，还需模拟供电接口以及线路。

步骤S60，将所述控制器对应的车辆模型编译生成第二动态链接库文件。

具体的，所述第一动态链接库文件通过Silver的“sbsBuild.exe”指令编译生成，所述第二动态链接库文件通过Silver的“SimBuild.dll”组件编译生成。其中，所述车辆模型包含有总线输入及输出接口/硬线输入及输出接口/车辆仿真模型。

步骤S70，根据所述第一动态链接库文件和所述第二动态链接库文件构造软件测试模型。

具体的，所述软件测试模型由所述第一动态链接库文件和所述第二动态链接库文件在所述Silver环境中生成。

其中，Silver是虚拟ECU仿真平台，用于将开发任务从道路和测试台架转移到PC机上，以实现软件开发的最大效率。工程师可以使用Silver来构建虚拟ECU，这些虚拟ECU与真实的ECU行为非常相似，同时Silver也是一个强大的仿真平台，可用来仿真验证多个控制器之间的数据交互，如发动机，变速器以及其它车载部件。通过设置自动化构建过程，每次ECU软件版本更新时，新的虚拟ECU可以在几分钟内自动被构建出来，这样可以在ECU软件应用到实车之前，通过仿真手段更早的发现软件中的错误。

Silver可以部署到Windows或Linux PC上，支持运行各种工具的仿真模型(如MATLAB/Simulink,Dymola,SimulationX,MapleSim,AMEsim,GT-Power,axisuite)，并且在仿真过程中，不需要启动这些工具。在分布式合作开发过程中，模型在不同的开发者之间以二进制的形式(FMU,sFunction,Silver模块)进行交换，而不需要传递相应的源代码，有利与信息安全和知识产权保护。

软件测试模型构造好即可进行软件的测试，本申请实施例通过模拟一个软件测试模型，不需要在AUTOSAR软件架构中，即可完成软件的测试工作。理想地模拟了基础软件层的功能，使原本支持应用层运行的与硬件强关联而复杂的基础软件层功能变得简单，使测试能够集中关注应用层策略问题，不需要关注基础软件层实现对应用层的影响。同时使小阶段内迭代快捷，不需要重新集成二进制文件。

实施例2

请参见图2所示，本申请的实施例还提供一种软件测试系统，包括：

接口文件提取模块30，用于获取所述控制器软件RTE层的接口文件。

接口文件处理模块40，用于对所述接口文件进行预处理，得到接口目标文件。

C代码提取模块10，用于获取控制器软件应用层的C代码。

运行配置模块20，用于根据所述C代码创建运行文件。

第一模型生成模块50，用于根据所述接口目标文件和所述运行文件编译生成第一动态链接库文件。

第二模型生成模块60，用于将所述控制器对应的车辆模型编译生成第二动态链接库文件。

第三模型生成模块70，用于根据所述第一动态链接库文件和所述第二动态链接库文件构造软件测试模型。

需要说明的是，上述实施例所提供的软件测试系统与上述实施例1所提供的软件测试方法属于同一构思，其中各个模块和单元执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。上述实施例1所提供的软件测试方法在实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能，本处也不对此进行限制。

实施例3

请参见图3所示，本申请的实施例还提供了一种电子设备，包括存储器2、处理器1及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任一项所述方法的步骤。

其中，存储器至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、移动硬盘、多媒体卡、卡型存储器(例如：SD或DX存储器等)、磁性存储器、磁盘、光盘等。存储器在一些实施例中可以是电子设备的内部存储单元，例如该电子设备的移动硬盘。存储器在另一些实施例中也可以是电子设备的外部存储设备，例如电子设备上配备的插接式移动硬盘、智能存储卡(Smart Media Card,SMC)、安全数字(Secure Digital,SD)卡、闪存卡(Flash Card)等。进一步地，存储器还可以既包括电子设备的内部存储单元也包括外部存储设备。存储器不仅可以用于存储安装于电子设备的应用软件及各类数据，还可以用于暂时地存储已经输出或者将要输出的数据。

处理器在一些实施例中可以由集成电路组成，例如可以由单个封装的集成电路所组成，也可以是由多个相同功能或不同功能封装的集成电路所组成，包括一个或者多个中央处理器(Central Processing unit，CPU)、微处理器、数字处理芯片、图形处理器及各种控制芯片的组合等。处理器是所述电子设备的控制核心(Control Unit)，利用各种接口和线路连接整个电子设备的各个部件，通过运行或执行存储在所述存储器内的程序或者模块，以及调用存储在所述存储器内的数据，以执行电子设备的各种功能和处理数据。

所述处理器执行所述电子设备的操作系统以及安装的各类应用程序。所述处理器执行所述应用程序以实现上述各个锂动力电池虚焊检测方法实施例中的步骤。

示例性的，所述计算机程序可以被分割成一个或多个模块，所述一个或者多个模块被存储在所述存储器中，并由所述处理器执行，以完成本发明。所述一个或多个模块可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序在所述电子设备中的执行过程。

上述以软件功能模块的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、计算机设备，或者网络设备等)或处理器(processor)执行本发明各个实施例锂电池虚焊检测方法的部分功能。

综上所述，本发明的技术效果在于，通过模拟一个软件测试环境使测试不依赖于不关注的硬件及基础应用层的软件实现，且测试环境的开发能够与应用层软件开发同步。同时理想地模拟了基础软件层的功能，使原本支持应用层运行的与硬件强关联而复杂的基础软件层功能变得简单，使测试能够集中关注应用层策略问题，不需要关注基础软件层实现对应用层的影响。进一步使测试过程小阶段内迭代快捷，不需要重新集成二进制文件。

上述实施例仅示例性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，但凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。

Claims (10)

1.一种软件测试方法，其特征在于，包括：

获取所述控制器软件RTE层的接口文件；

对所述接口文件进行预处理，得到接口目标文件；

获取控制器软件应用层的C代码；

根据所述C代码创建运行文件；

根据所述接口目标文件和所述运行文件编译生成第一动态链接库文件；

将所述控制器对应的车辆模型编译生成第二动态链接库文件；

根据所述第一动态链接库文件和所述第二动态链接库文件构造软件测试模型。

2.根据权利要求1所述的软件测试方法，其特征在于，所述对所述接口文件进行预处理，得到接口目标文件的步骤包括：

筛选出所述接口文件中与所述控制器软件基础软件层有依赖关系的接口文件，并将其定义为空；

对筛选后的所述接口文件按照默认值进行填充，得到所述接口目标文件。

3.根据权利要求1所述的软件测试方法，其特征在于，所述根据所述C代码创建运行文件的步骤包括：

根据所述C代码创建初始化函数和周期函数；

根据所述控制器中软件的标定参数创建调度函数，并将所述初始化函数、周期函数以及调度函数生成对应的所述运行文件中的任务文件；

根据所述控制器中软件的标定参数配置非易失性存储变量，并将其生成对应的所述运行文件中的存储文件。

4.根据权利要求1所述的软件测试方法，其特征在于，所述接口文件包括：复杂驱动层接口定义文件，I/O硬件抽象层接口定义文件，通信服务层接口定义文件，存储服务层接口定义文件，OS服务层接口定义文件以及应用层SWC接口定义文件。

5.根据权利要求1所述的软件测试方法，其特征在于，所述接口目标文件包括：I/O硬件抽象层接口定义文件、通信服务层接口定义文件以及应用层SWC接口定义文件。

6.根据权利要求1所述的软件测试方法，其特征在于，通过Davinci工具获取所述控制器软件RTE层的接口文件。

7.根据权利要求1所述的软件测试方法，其特征在于，通过Silver的“sbsBuild.exe”指令编译生成所述第一动态链接库文件；通过所述Silver的“SimBuild.dll”组件编译生成所述第二动态链接库文件；且所述第一动态链接库文件和所述第二动态链接库文件在所述Silver环境中生成所述软件测试模型。

8.一种软件测试系统，其特征在于，包括：

接口文件提取模块，用于获取所述控制器软件RTE层的接口文件；

接口文件处理模块，用于对所述接口文件进行预处理，得到接口目标文件；

C代码提取模块，用于获取控制器软件应用层的C代码；

运行配置模块，用于根据所述C代码创建运行文件；

第一模型生成模块，用于根据所述接口目标文件和所述运行文件编译生成第一动态链接库文件；

第二模型生成模块，用于将所述控制器对应的车辆模型编译生成第二动态链接库文件；

第三模型生成模块，用于根据所述第一动态链接库文件和所述第二动态链接库文件构造软件测试模型。

9.一种电子设备，其特征在于，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。

10.一种计算机可读介质，其特征在于，其上存储有指令，所述指令由处理器加载并执行如权利要求1至7中任一项所述的方法。

Images