CN103064403B - 一种ecu硬件在环仿真自动化测试方法和系统 - Google Patents

Abstract

本发明公开了一种ECU硬件在环仿真自动化测试方法和系统，该方法包括以下步骤：填写测试表格从而设计成单个或多个表格测试用例；运行自动化代码将表格测试用例生成可执行的测试用文件；执行测试；生成测试报告。本发明只需一次设计好自动化翻译代码，永久有效，使自动化测试开发工程师脱离海量测试用例代码翻译工作；采用表格式测试用例开发方式，既简单高效，又通用灵活，性价比很高很实用；测试工程开发出大量的表格测试用后，一键排队生成相应的可执行的测试用例，一键自动执行，实现真正意义上ECU的HIL自动化测试。

Description

一种ECU硬件在环仿真自动化测试方法和系统

技术领域

本发明涉及汽车电子领域，特别涉及一种ECU硬件在环仿真自动化测试方法和系统。

背景技术

ECU(ElectronicControlUnit)电子控制单元，又称“行车电脑”、“车载电脑”等。从用途上讲则是汽车专用微机控制器，也叫汽车专用单片机。它和普通的单片机一样，由微处理器(CPU)、存储器(ROM、、RAM)、输入/输出接口(I/O)、模数转换器(A/D)以及整形、驱动等大规模集成电路组成。电控单元由微型计算机、输入、输出及控制电路等组成。

汽车电控系统包括传感器、ECU和执行器三大部分。传感器是ECU采集汽车的各种信息(如车速、发动机转速、冷却水温度、进气压力、点火开关等)的接口，ECU通过对传感器信息的分析和内部控制逻辑的处理输出控制信号驱动执行器(如喷油器、空调继电器等)。汽车ECU在开发设计的过程中，软硬件集成在一起后就要进行逻辑测试和功能验证，完成此过程要使用硬件在环仿真设备(即HIL)，之后才能上台架或者整车验证。HIL模拟ECU所有的传感器信号和汽车电子电器负载，和ECU在环连接起来，让ECU认为自己在控制一辆汽车。

HIL设备包括汽车的数学模型(运行于仿真机)、HIL配置和试验环境(运行于上位机)、IO接口和负载板卡(模拟传感器信号和电子电器负载)三部分。用户通过HIL配置和实验环境完成HIL的配置和试验测试任务。测试过程中使用测试标定工具和HIL试验环境，通过HIL实验环境设定特定工况，观察测试标定工具测量的变量值和期望值。由于控制的逻辑的复杂，手动测试任务量巨大，并且不具有可重复性。将测试用例写成测试脚本，通过调用其API函数使测试标定软件工具和HIL实验环境自动地执行测试用例中的步骤，这种测试叫做HIL自动化测试。这既减轻测试人员的工作量，又可以将测试做得细微而全面。例如测试ECU对传感器信号的采集精度，如果手动测试的话，一般测量有限个点(比如8个或者10个点)的工作量正常，但是如果要测试的全面的话，应该从0V-5V，每隔0.1V或者0.2V就要测量一次。这样的话，如果不进行回归测试的话，测试工作量增加5倍。

将测试用例脚本化的工作，工作量也很大，甚至比设计软件的工作量还大。如果是这样的话，就是失去了HIL自动化测试的意义了。现在的HIL的自动测试软件的测试用例开发工具都存在这样或那样的问题，很多功能不完善，不成熟，如程式化的翻译有时不能按照测试意图去生成相应的代码，无法真正用于实际应用；每次只能翻译一个当前设计好的测试用例，当需要设计大量的测试用例时，需要多次翻译和一些其他的辅助操作，降低了工作效率。而且使用需要license，通用性不强，只能在有限的PC机上使用。一般的工程师都直接采用脚本设计测试用例。本发明开发一种表格式测试用例开发方法，只需设计一次测试脚本，测试脚本将表格式测试用例生成可执行文件。

发明内容

本发明要解决的问题是提供一种ECU硬件在环仿真自动化测试方法和装置，以克服现有技术中测试用例翻译过程程式化和每次只能翻译一个测试用例的问题。

为达到上述目的，本发明提供了一种ECU硬件在环仿真自动化测试方法，所述方法包括以下步骤：

A、填写测试表格从而设计成单个或多个表格测试用例；

B、运行自动化翻译代码将表格测试用例翻译成可执行的测试用文件；

C、执行翻译生成的可执行的测试用文件，得到测试结果。

进一步的，还包括根据所述测试结果生成测试报告。

进一步的，所述的自动化翻译代码包括两部分，一部分是通用代码；另一部分是通用脚本。

进一步的，所述的通用代码采用面向对象的编程语言编写的代码，任何表格测试用例经过此代码的翻译运行都能生成一个可执行测试用例。

进一步的，所述的通用脚本可以依次排队运行通用代码，生成和表格测试用例相对应的可执行的测试用例文件。

进一步的，所述的表格是事先设定好的，通用代码可以从表格中读取出信息。

为实现上述目的，本发明提供了一种ECU硬件在环仿真自动化测试装置来实施上述方法，所述装置包括转化模块、翻译模块和执行模块；

所述转化模块，用于将测试需求转化为表格化的测试用例；

所述翻译模块，用于运行所述的自动化翻译代码将多个表格测试用例排队依次生成可执行的测试用例，并且其生成的可执行文件的名字分别和表格测试用例的名字相对应；

所述执行模块，执行翻译完成的测试用例，并在执行完成后生成对应的测试报告。

进一步的，所述的自动化测试系统采用通用性强的表格工具来开发自动化测试用例，使测试工程师可以在任意的PC机上开发，不受商业license限制。

进一步的，所述的转化模块包括：根据测试需要的相关数据和信息，预先设计好的表格。

进一步的，所述的翻译模块包括：

通用代码单元，该种代码为采用面向对象的编程语言的通用代码，任何表格测试用例经过此代码的编译运行都能生成一个可执行的测试用例；

通用脚本单元，该脚本的作用是依次排队运行通用代码，生成和表格测试用例相对应的可执行的测试用例文件，即＊.exe。

进一步的，所述的执行模块拥有一键自动执行测试用例的功能，能将多个可执行的测试用例文件排队依次执行，并生成与可执行测试用例文件对应的测试报告。

与现有技术相比，本发明具有以下有点：

通过本发明所述的技术方案，用表格化的测试用例来代替框图式的测试用例，相比框图式的测试用例，表格化测试的测试用例具有统一性强和规律性强等特点，在翻译过程中提高了准确性。这样，只需开发工程师一次性设计好自动化翻译代码，永久有效，使自动化测试开发工程师脱离海量测试用例代码翻译工作。在测试工程开发出大量的表格测试用例后，一键排队生成相应的可执行的测试用例，一键自动执行，真正意义上ECU的HIL自动化测试。另外，本发明中采用通用性很强的表格工具来开发HIL自动化测试用例，使测试工程师可以在任意PC机上开发，不受商业license限制。

附图说明

图1是本发明提供的一种ECU硬件在环仿真自动化测试方法的一个实施例的流程图；

图2是本发明提供的一种ECU硬件在环仿真自动化测试系统的一个整体结构图；

图3是本发明中通用脚本工作过程图。

具体实施方式

下面我们将结合附图，对本发明的最佳实施方案进行详细描述。首先要指出的是，本发明中用到的术语、字词及权利要求的含义不能仅仅限于其字面和普通的含义去理解，还包括进而与本发明的技术相符的含义和概念，这是因为我们作为发明者，要适当地给出术语的定义，以便对我们的发明进行最恰当的描述。因此，本说明和附图中给出的配置，只是本发明的首选实施方案，而不是要列举本发明的所有技术特性。我们要认识到，还有各种各样的可以取代我们方案的同等方案或修改方案。

图1示出了本发明提供的一种ECU硬件在环仿真自动化测试方法的一个实施例的流程图，该方法包括以下步骤：

在步骤A之前还包括：测试工程师根据测试需求包括的项目和内容预先设计好表格。

测试需求：比如说测试发动机启动过程是否成功，上电启动后如果发动机的转速大于600rpm，就认为是启动成功了。当然只是个简单的测试需求。

表格设计时需要按照特定的格式，因为所述的通用代码要去表格里面读取信息，然后做处理。举一个简单的例子，表格的第一行是item，有：测试用例名称，测试动作(是定义好的一些动作label)，测试变量，设定值，期望值，误差，结果等。还是上面的那个例子，启动发动机成功与否的测试用例。然后填写表格，每一行在对应的item中填写相应的数据和变量。第一行，测试用例名称，TC-Start；测试动作，SetModel(就是设定HIL)，测试变量填入PowerSwich，设定值1，期望值1，误差依情况而定这写0，结果不用填。

步骤A，测试工程师根据测试需求中所包含的项目、内容和数据等信息，将测试需求分为不同的种类，然后分别填入预先已经设计好的专用表格中，把这些表格放入指定的路径中，即已经完成将测试需求转化为表格化测试用例的步骤。

步骤B，运行自动化翻译代码，翻译这些存放在指定路径内的表格化测试用例。

由于现有技术中，框图式的测试用例由于程式化的翻译，会出现框图式测试用例生成的代码中执行的次序和框图式测试用例中的次序不一致的状况，比如对HIL驱动、初始化的过程会出现次序颠倒的现象，造成测试无法顺利进行。测试工程师在框图中明明是先上电，然后读取ECU的变量，转换成的代码变成了先启动INCA(in-coreanalysis)堆芯分析，然后这时候因为没有上电，所以INCA连接不上，所以无法读取ECU变量，导致翻译后的测试用例无法执行，一直报错。由于框图式的测试用例在翻译时会出现错误率较高和不能完整体现测试需求的情况，一般的测试工程师都不愿使用框图式这种不成熟的工具，而是根据每个测试用例的特点手工编写通用代码，这样每一个测试用例，都要编写通用代码，海量的测试用例，耗费大量人力和时间，大大降低了效率。

而本发明中，用表格化的测试用例来代替框图式的测试用例，相比框图式的测试用例，表格化测试的测试用例具有统一性强和规律性强等特点，比如通用代码可以从表格中固定的位置读出信息，并且在读取的顺序上也有严格的规定，提高了翻译过程的准确性。这样，只需开发工程师一次性编写好通用代码，将测试工程师从海量通用代码的工作中解放出来。

所述的通用代码对表格测试用例数据的读取采用数据库的方式或者调用表格工具本身的动态链接库文件。定位方法是根据特定表格测试用例文件的路径。

所述的数据库的读取方式有很多种方式，因为有许多主流的数据库开发的软件。在此我们给出一种常用方法，MicrosoftJet提供程序用于连接到Excel工作簿。在以下连接字符串中，ExtendedProperties关键字设置Excel特定的属性。“HDR＝Yes；”指示第一行中包含列名，而不是数据，“IMEX＝1；”通知驱动程序始终将“互混”数据列作为文本读取。在连接字符串默认的情况下，系统认为Excel数据源的第一行包含可用作字段名的列标题。如果不是这种情况，则必须将该设置关闭，否则，第一行数据将会“消失”，而被用作字段名称。这可通过向连接字符串的扩展属性添加可选的HDR＝设置来完成。默认情况下(无需指定)是HDR＝Yes。如果没有列标题，则需要指定HDR＝No；提供程序将字段命名为F1、F2等等。因为扩展属性字符串现在包含了多个值，所以必须用引号单独包起来。

所述的调用表格工具本身的动态链接库文件的读取方法，动态链接库英文为DLL，是DynamicLinkLibrary的缩写形式，DLL是一个包含可由多个程序同时使用的代码和数据的库，DLL不是可执行文件。动态链接提供了一种方法，使进程可以调用不属于其可执行代码的函数。函数的可执行代码位于一个DLL中，该DLL包含一个或多个已被编译、链接并与使用它们的进程分开存储的函数。DLL还有助于共享数据和资源。多个应用程序可同时访问内存中单个DLL副本的内容。动态链接库可以更为容易地将更新应用于各个模块，而不会影响该程序的其他部分。动态链接库文件，是一种不可执行的二进制程序文件，它允许程序共享执行特殊任务所必需的代码和其他资源。例如，在Windows操作系统下，Windows提供的DLL文件中包含了允许基于Windows的程序在Windows环境下操作的许多函数和资源。一般被存放在C：视窗系统System目录下。Windows中，DLL多数情况下是带有DLL扩展名的文件，但也可能是EXE或其他扩展名；Debian系统中常常是.so的文件。它们向运行于Windows操作系统下的程序提供代码、数据或函数。程序可根据DLL文件中的指令打开、启用、查询、禁用和关闭驱动程序。

所述的通用代码实现对测量标定工具和HIL实验环境的操作动作，是通过调用其API函数实现的、常用的动作有设定HIL变量、读取HIL变量、标定ECU参数、标定ECU参数曲线、标定ECU参数MAP、读取ECU变量、读取ECU标定参数、读取ECU参数曲线、读取ECU参数MAP、等待、故障注入、记录数据等。

实际，如果只有这一部分通用代码往往是不能够实现排队生成可执行测试用例的，因为图形化的开发方式在翻译框图式的测试用例时，点击翻译按钮，经通用代码翻译生成了一个对应测试用例。再翻译另一个测试用例时，需要再次点击翻译按钮。这就导致图形化的开发方式在翻译框图式的测试用例时，只能在一次运行过程中翻译一个框图式的测试用例，不能够连续自动的翻译多个框图式的测试用例。

为了解决这个问题，在本发明中翻译模块中，特别增加了通用脚本，通用脚本可采用M语言等编写。通用脚本能够在每次编译运行通用代码之前要修改一次代码中表格测试用例文件的路径，具体过程为，通用脚本运行逻辑判断功能先定位上次被执行翻译操作的表格测试用例在存储路径内的逻辑位置，然后在本次运行翻译操作前，自动将指针指向该逻辑位置的下面的第一个位置，并指示通用代码对该位置的表格测试用例进行翻译操作，目的是使读取的表格测试用例文件切换到下一个，这样就可以实现排队编译运行生成可执行测试用例的过程。但是在执行这些操作后，测试人员会发现生成所有的可执行的表格化的测试用例的名字都是一样的，因为所有的表格测试用例共用一个通用代码，生成的可执行测试用例文件的名字是一样的，这样就会带来一个严重的问题，测试工程师无法分清不同类型的测试用例，不便于测试用例管理。为了解决这个问题，本发明中通用脚本的另外一个作用，就是将生成的可执行的测试用例文件的名字改为和相应表格测试用例的名字相同，这样在运行群组可执行测试用例时便于进行调度管理，其工作过程如图3所示。

步骤C，执行完成翻译操作后生成的可执行测试用例，并执行这些测试用例，得出测试结果。

另外，现有的HIL自动化测试用例开发软件采用图形化的开发方式，这是一种专业很强的商用软件，凡是商用软件的应用都需要license，不能够在任意一台PC上使用，性价比很低。本发明采用通用性很强的表格工具来开发HIL自动化测试用例，使测试工程师可以在任意的PC机上开发，不受商业license的限制。

本发明另一个实施例还提供一种ECU硬件在环仿真自动化测试系统的整体结构如图2所示，包括：转化模块、翻译模块和执行模块。

测试工程师根据测试需求中所包含的项目、内容和数据等信息，将测试需求分为不同的种类，然后分别填入预先已经设计好的专用表格中，把这些表格放入转化模块指定的路径中，即已经完成将测试需求转化为表格化测试用例的步骤。

翻译模块接收由转化模块发送的表格化测试用例，翻译模块开始运行自动化翻译代码，根据表格化测试用例存放在存储路径内的顺序，一个接一个自动地翻译这些表格化测试用例，并将翻译后生成的可执行的测试用例文件的名字改为和相应表格测试用例的名字相同，这样在运行群组可执行测试用例时便于进行调度管理。

执行模块接收由翻译模块执行完成翻译操作后生成的可执行测试用例，并执行这些测试用例，得出准确的测试结果，将测试结果与测试工程师事先设定的各项标准比较，生成测试报告。

该系统中的各个模块功能中的具体实现可以参照上述图1中所供的方法中的各流程的具体实现。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (7)

1.一种ECU电子控制单元硬件在环仿真自动化测试方法，其特征在于，包括以下步骤：

A、填写测试表格从而设计成至少一个表格测试用例；

B、运行自动化翻译代码将所述表格测试用例排队编译成可执行的测试用例，其中，所述自动化翻译代码包括两部分，一部分是通用代码,另一部分是通用脚本，所述通用代码采用面向对象的编程语言编写的代码，任何表格测试用例经过此代码的翻译运行都能生成一个可执行测试用例；所述通用脚本依次排队运行通用代码，生成和表格测试用例相对应的可执行的测试用例文件；

C、执行翻译生成的可执行的测试用例，得到测试结果。

2.根据权利要求1所述的方法，其特征在于，还包括根据所述测试结果生成测试报告。

3.如权利要求1所述的方法，其特征在于，所述的表格是事先设定好的，通用代码可以从表格中读取出信息。

4.一种ECU硬件在环仿真自动化测试系统，其特征在于，包括：

转化模块，用于将测试需求转化为表格化的测试用例；

翻译模块，用于运行自动化翻译代码将多个表格测试用例排队依次生成可执行的测试用例，并且其生成的可执行的测试用例的名字分别和表格测试用例的名字相对应；

执行模块，执行翻译完成的测试用例，并在执行完成后生成对应的测试报告；

其中，所述自动化翻译代码包括通用代码和通用脚本，所述的翻译模块包括：

通用代码单元，所述通用代码为采用面向对象的编程语言的通用代码，任何表格测试用例经过此代码的编译运行都能生成一个可执行的测试用例；

通用脚本单元，所述通用脚本能依次排队运行所述通用代码，生成和表格测试用例相对应的可执行的测试用例文件，即.exe文件，且将所述可执行的测试用例文件的名字修改为和相应表格测试用例的名字相同。

5.如权利要求4所述的系统，其特征在于，所述的自动化测试系统采用通用性强的表格工具来开发自动化测试用例，使测试工程师可以在任意的PC机上开发，不受商业license限制。

6.如权利要求4所述的系统，其特征在于，所述的转化模块包括：根据测试需要的相关数据和信息，预先设计好的表格。

7.如权利要求4所述的系统，其特征在于，所述的执行模块拥有一键自动执行测试用例的功能，能将多个可执行的测试用例文件排队依次执行，并生成与可执行测试用例文件对应的测试报告。