一种车辆诊断自动化测试方法、装置、电子设备及介质与流程
未命名
08-15
阅读:90
评论:0
1.本技术涉及车载网络通信诊断技术领域,具体涉及一种车辆诊断自动化测试方法、装置、电子设备及介质。
背景技术:
2.uds(unifieddiagnosticservices,统一的诊断服务)诊断是汽车上所有ecu(electroniccontrolunit,电子控制单元)进行车型配置、数据写入、故障诊断的主流方式,因此uds诊断测试也是汽车ecu测试中非常重要的测试模块之一。而随着汽车电子技术的发展,汽车电子电器架构日趋复杂,从而导致需要测试的地方越来越多,工作量越来越大,因此汽车电子测试领域急需引入自动化测试来简化人工测试,提高单位时间的测试覆盖率。
3.相关技术中的uds车辆诊断测试方式主要有两种,一是手动测试,测试手段是发送相应的服务,人工查看应答,得到肯定响应则通过,二是基于自动化测试系统将测试过程维护在代码中,发起自动化测试,例如在专利号为cn115546927a的专利文件中,提供了一种基于autosar标准的uds诊断自动化测试系统,该系统以davinci软件为autosar设计平台,采用pycharm软件编写自动化测试脚本,用robotframework模块生成测试样例,最终通过canoe完成udsoncan的诊断测试验证工作。但是这两种测试方法都存在以下缺点,手动测试的覆盖率得不到保证,花费大量人工成本,数据量较大时容易出错,自动化测试系统用例难以维护,数据不方便修改,不方便其他测试人员使用。
技术实现要素:
4.鉴于以上所述现有技术的缺点,本技术的实施例提供一种车辆诊断自动化测试方法、装置、电子设备及介质,以解决上述uds车辆诊断中存在浪费人力,难于维护和通用性不好的技术问题。
5.本技术的实施例提供的一种车辆诊断自动化测试方法,包括获取测试用例和所述测试用例的功能类型,所述测试用例包括期望数据和测试数据;基于所述测试用例的所述功能类型将所述测试数据组装成测试报文;发送所述测试报文至待测试车辆单板,以得到响应数据;若所述响应数据与所述期望数据一致,则所述测试用例测试通过并生成测试报告。
6.于本技术的一实施例中,若所述响应数据与所述期望数据不一致,则所述测试用例测试失败并生成异常报告。
7.于本技术的一实施例中,基于所述测试用例的功能类型将所述测试数据组装成测试报文包括:基于所述测试用例的所述功能类型确定配置参数;根据所述配置参数将所述测试数据组装成所述测试报文。
8.于本技术的一实施例中,调用协议分析接口发送所述测试报文至所述待测试车辆单板,所述待测试车辆单板接收到所述测试报文后,基于所述车辆单板运行状态返回所述测试报文对应的所述响应数据。
9.于本技术的一实施例中,若所述响应数据与所述期望数据一致,则将所述测试用例的测试通过状态设置为通过;基于所述测试用例和所述测试通过状态生成测试报告;将所述测试报告基于表格或超文本标记语言形式保存。
10.于本技术的一实施例中,若所述响应数据与所述期望数据不一致,则将所述测试用例的测试通过状态设置为失败;基于所述测试用例和所述测试通过状态生成所述异常报告;将所述异常报告基于表格或超文本标记语言形式保存。
11.于本技术的一实施例中,所述测试用例还包括用例编号、项目描述、发送方法以及是否执行中至少之一。
12.本技术的实施例提供一种车辆诊断自动化测试装置,用例获取模块,用于获取测试用例和所述测试用例的功能类型,所述测试用例包括期望数据和测试数据;报文组装模块,用于基于所述测试用例的所述功能类型将所述测试数据组装成测试报文;测试执行模块,用于发送所述测试报文至待测试车辆单板,以得到响应数据;报告生成模块,用于若所述响应数据与所述期望数据一致,则所述测试用例测试通过并生成测试报告。
13.本发明的有益效果:本发明实施例提供的种车辆诊断自动化测试方法、装置、电子设备及介质,该方法通过获取测试用例和测试用例的功能类型,基于测试用例的功能类型将测试数据组装成测试报文,发送测试报文至待测试车辆单板,以得到响应数据,若响应数据与期望数据一致,则测试用例测试通过并生成测试报告,通过自动获取测试用例和期望数据,再发送测试报文得到响应数据与期望数据做对比,形成报告以供查看,节省了大量的人力物力成本,测试用例也易于修改,维护简易可靠和测试覆盖度完全可控,降低了人工测试误测和漏测的概率,提高了车辆诊断测试的可靠性和有效性。
14.应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本技术。
附图说明
15.此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本技术的实施例,并与说明书一起用于解释本技术的原理。显而易见地,下面描述中的附图仅仅是本技术的一些实施例,对于本领域普通技术者来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。在附图中:
16.图1是本技术的一示例性实施例示出的车辆诊断自动化测试环境示意图;
17.图2是本技术的一示例性实施例示出车辆诊断自动化测试方法流程示意图;
18.图3是本技术的一示例性实施例示出的车辆诊断自动化测试系统结构示意图;
19.图4是本技术的一示例性实施例示出的车辆诊断自动化测试系统流程示意图;
20.图5是本技术的一示例性实施例示出的车辆诊断自动化测试装置的框图;
21.图6示出了适于用来实现本技术实施例的电子设备的计算机系统的结构示意图。
具体实施方式
22.以下将参照附图和优选实施例来说明本技术的实施方式,本领域技术人员可由本说明书中所揭露的内容轻易地了解本技术的其他优点与功效。本技术还可以通过另外不同的具体实施方式加以实施或应用,本说明书中的各项细节也可以基于不同观点与应用,在
没有背离本技术的精神下进行各种修饰或改变。应当理解,优选实施例仅为了说明本技术,而不是为了限制本技术的保护范围。
23.需要说明的是,以下实施例中所提供的图示仅以示意方式说明本技术的基本构想,遂图式中仅显示与本技术中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制,其实际实施时各组件的型态、数量及比例可为一种随意的改变,且其组件布局型态也可能更为复杂。
24.在下文描述中,探讨了大量细节,以提供对本技术实施例的更透彻的解释,然而,对本领域技术人员来说,可以在没有这些具体细节的情况下实施本技术的实施例是显而易见的,在其他实施例中,以方框图的形式而不是以细节的形式来示出公知的结构和设备,以避免使本技术的实施例难以理解。
25.首先需要说明的是,uds诊断功能类似于互联网产品的接口功能,发送特定的命令和参数,ecu返回响应应答,然后将应答与期望数据做对比,从而达到获得或修改ecu内部信息的目的。ecu是随时监控着输入的各种数据(比如刹车、换挡等)和汽车运行的各种状态(加速、打滑、油耗等),并按照预先设计的程序计算各种传感器送来的信息,经过处理以后,把各个参数发送给各相关的执行机构,执行各种预定的控制功能。
26.而为了改进现有的uds诊断测试中手动测试覆盖度得不到保证,浪费人力物力,测试用例难于维护的缺点,本技术的实施例具有用例易于修改、维护简易可靠和测试覆盖度完全可控的特点,能够极大提高测试效率和准确率,且节省人力物力成本,基于此,本技术的实施例提供了一种车辆诊断自动化测试方法,一种车辆诊断自动化测试装置,一种电子设备和一种可存储介质,详细介绍如下。
27.请参见图1,图1是本技术的一示例性实施例示出的车辆诊断自动化测试环境示意图,该车辆诊断自动化测试环境包括计算机、zcanpro、测试单板和供电电源。其中,计算机可以是微型计算机、嵌入式计算机、神经网络计算机等中的至少一种,在本实施例中zcanpro为周立功can卡,计算机用于获取测试用例和测试用例功能类型,并基于测试用例的功能类型将测试数据组装成测试报文并发送至测试单板,以得到响应数据并进行比对,zcanpro用于作为计算机和测试单板之间的接口,用于连接计算机和测试单板,供电电源用于为整个车辆诊断自动化测试环境进行供电。
28.在本技术的一个实施例中,将待测试车辆单板作为测试单板进行车辆诊断自动化测试,计算机获取测试用例和该测试用例的功能类型,测试用例包括期望数据和测试数据,基于测试用例的功能类型将该测试用例组装成报文并通过zcanpro发送至待测试车辆单板。待测试车辆单板接收到组装报文后,对该报文进行响应并向计算机返回响应数据,计算机将响应数据与期望数据比对,若响应数据与期望数据一致,则该测试用例测试通过,计算机生成测试报告;若响应数据与期望数据不一致,则该测试用例测试不通过,计算机生成异常报告,可见,本技术的实施例的技术方案能够通过自动获取测试用例中的测试数据和期望数据,发送测试用例后获取响应数据,并将响应数据与期望数据做对比,得到测试结果并形成报告以供查看,同时具有用例易于修改、维护简易可靠和测试覆盖率完全可控的特点,能够极大提高测试效率和准确性,且节省人力物力成本。
29.请参见图2,图2是本技术的一示例性实施例示出的车辆诊断自动化测试方法流程示意图,在一示例性实施例中,车辆诊断自动化测试方法至少包括步骤s210至步骤s240,详
细介绍如下:
30.步骤s210,获取测试用例和测试用例的功能类型,测试用例包括期望数据和测试数据。
31.在本技术的一个实施例中,获取测试用例和测试用例的功能类型,该测试用例包括期望数据和测试数据以外,还包括用例编号、项目描述、发送方法以及是否执行中至少之一。
32.在本技术的一个实施例中,测试用例的功能类型包括应用层测试类型、网络层测试类型、dtc测试类型和did测试类型等,基于不同的测试类型,测试用例的测试用例也不同,组装成测试报文的配置参数也不同。
33.在本技术的一个实施例中,期望数据为若测试的功能正常情况下,待测试车辆单板应返回的响应报文,若待测试车辆单板为响应相同的期望数据,则该待测试车辆单板该功能有异常,则测试不通过。
34.步骤s220,基于测试用例的功能类型将测试数据组装成测试报文。
35.在本技术的一个实施例中,基于测试用例的功能类型确定配置参数;根据配置参数将测试数据组装成测试报文。
36.在本技术的一个实施例中,根据不同的功能类型完成不同的组装函数,以组装不同的测试报文,功能类型包括应用层测试类型、网络层测试类型、dtc测试类型以及did测试类型等,还有复用uds诊断的其他功能都要写进组装函数中以供组装报文时调用。在组装测试报文时,根据功能类型确定相应的配置参数,配置参数包括是否canfd加速,是否启用多帧发送及间隔时间阈值和响应超时时间阈值。
37.步骤s230,发送测试报文至待测试车辆单板,以得到响应数据
38.在本技术的一个实施例中,调用协议分析接口发送测试报文至待测试车辆单板,待测试车辆单板接收到测试报文后,基于车辆单板运行状态返回测试报文对应的响应数据。
39.在本技术的一个实施例中,通过zcanpro提供接口将测试报文发送至待测试车辆单板,在封装接口的时候以简要稳定为目标,使接口易于阅读,便于维护。
40.步骤s240,若响应数据与期望数据一致,则测试用例测试通过并生成测试报告。通过接收的响应数据判断该测试用例是否通过测试,若响应数据与期望数据一致,则该测试用例通过测试,并生成测试报告,该测试报告包括测试的数据及测试通过结果,测试报告基于excle或html的文件形式保存下来;若响应数据与期望数据不一致,则测试用例测试失败并生成异常报告,该异常报告包括测试运行的日志及测试通过结果,便于测试人员基于该异常报告寻找发生错误的节点,异常报告基于ecxel和html的文件形式保存下来。
41.在本技术的一个实施例中,若响应数据与期望数据一致,则将测试用例的测试通过状态设置为通过;基于测试用例和测试通过状态生成测试报告;将测试报告基于表格或超文本标记语言形式保存。
42.在本技术的一个实施例中,若响应数据与期望数据不一致,则将测试用例的测试通过状态设置为失败;基于测试用例和测试通过状态生成异常报告;将异常报告基于表格或超文本标记语言形式保存。
43.请参见图3,图3是本技术的一示例性实施例示出的车辆诊断自动化测试系统结构
示意图,该车辆诊断自动化测试系统结构包括用例设计、配置参数、结果分析,业务功能包括测试数据、基础服务、业务服务和运行环境。
44.首先是用例设计模块,用于测试用例和报告设计,根据公司或市面测试规范对于测试用例进行设计编写。一条测试用例最好包括:用例编号,项目描述,数据,发送方法,期望响应以及是否执行等主要信息。根据测试工作的具体需求设计测试报告,测试报告除了用例的部分外,还应包括:测试结果,对比结果,测试结论和测试时间等主要项目。
45.然后是处理数据模块,用于实现excle处理数据。有了测试用例和测试报告样例,就能以此为目标编写处理excle模块,其中包括读取类和写入类。读取类实现了读取指定excle文档,它的初始化函数打开某个测试用例,将里面的数据加载至内存,它内部特定方法,则将数据加工处理,整合成一个个数据结构返回,以供测试模块,日志模块等调用。写入类则实现了测试结果数据的整合处理,写入excle报告中。
46.再是报文组装模块,用于将测试用例组装成报文。在得到用例里面的数据信息后,就可以进行报文的组装了,需要满足如下两点需求。其一,通常是根据不同的功能,完成不同的组装函数。例如应用层测试协议,网络层协议,dtc测试以及did测试,还有就是项目复用uds诊断的其他功能,也要编写函数在该模块内以供调用。其二,要根据测试工具的规范来组装报文,并根据测试环境或需求填写相应的参数。例如是否canfd加速,是否启用多帧发送及间隔时间stmin和响应超时时间。
47.然后是测试执行模块,用于发送数据功能,接收处理返回数据功能,组装填写报告和日志填写。数据交互功能基于调用zcanpro提供的接口,因此在封装的时候以简要稳定为目标。这样使得整个模块易于阅读,便于维护,且不影响其他模块。
48.最后是参数配置模块及日志与报告生成模块。参数配置模块则是平时测试人员需要改动的模块,根据测试实际情况,调整参数以驱动整个测试程序正确运行。日志与报告生成模块这是提供接口给测试执行模块,以获得要形成报告的数据,并将数据以excle或html的文件形式保存下来。
49.得到测试报告之后,分析测试报告数据。测试过程产生的报告,测试人员通过查看分析,判断测试是否达标。对于没有通过的用例,测试人员需要排查问题,确定为测试代码的问题,则进行修改完善。
50.在本技术的实施例中,若响应数据与期望数据不一致,则根据测试结果生成异常报告,可以便于测试人员通过异常报告找到本次测试的异常,便于测试人员对车机进行调试。
51.在本技术的实施例中,根据功能类型确定配置参数,基于配置参数组装测试报文,可以适配多种功能测试的车辆诊断自动化,便于测试人员操作。
52.在本技术的实施例中,调用协议分析接口发送报文至待测试车辆单板,再接收响应数据以通过响应数据和期望数据进行比对得到测试是否通过。
53.在本技术的实施例中,将测试报告基于表格或超文本标记语言保存,可以便于测试人员查看测试报告。
54.在本技术的实施例中,将异常报告基于表格或超文本标记语言保存,可以便于测试人员查看异常报告。
55.在本技术的实施例中,测试用例还包括测试编号、项目描述、发送方法以及是否执
行中至少之一,可以便于新的测试人员操作整个流程,减少测试人员的学习成本。
56.请参见图4,图4是本技术的一示例性实施例示出的车辆诊断自动化测试系统流程示意图,根据图4所示,详细步骤介绍如下。
57.首先获取测试用例,用例设计、编制与维护。测试用例通常用excle文件来维护,确定好一条用例要填写的各个要素,根据公司或市面上的uds诊断测试的标准文档,填写一份完整的用例。后续根据各个项目不同的需求,从完整版用例里面挑选出需要的部分形成特定用例。在软件的发展过程中,如果测试要求有变化,测试人员也只需修改各项目的用例就可以了。
58.在本技术的一个实施例中,根据uds诊断测试的特性及代码易于维护的需求,我们选用python语言来编写代码,代码模块主要分为处理excel模块,组装报文模块,测试实现模块,参数配置模块及日志与报告生成模块。代码编写则是具体完成各个模块功能,调试测试通过。
59.然后将获取的测试用例组装成测试报文,基于测试用例的功能类型将该测试用例组装成对应的测试报文。
60.然后调用接口发送该测试报文至待测试车辆单板,从而获得响应数据。在本实施例中,在经过前期工作后,测试执行过程则相对简单,测试人员只需要连接好can卡和待测试产品,其中can卡在本技术中以周立功can卡为例进行阐述说明
61.在测试执行过后,代码会生成测试结果文档,以供查看,若该响应数据与期望数据相同,则组成一条正常结果并生成检测报告,若该响应数据与期望数据不同,则组成一条异常结果并生成异常报告。
62.图5是本技术的一示例性实施例示出的车辆诊断自动化测试装置的框图,如图5所示,该示例性的车辆诊断自动化测试装置包括,用例获取模块501、报文组装模块502、测试执行模块503和报告生成模块504。
63.用例获取模块501,用于获取测试用例和测试用例的功能类型,测试用例包括期望数据和测试数据;
64.报文组装模块502,用于基于测试用例的功能类型将测试数据组装成测试报文;
65.测试执行模块503,用于发送测试报文至待测试车辆单板,以得到响应数据;
66.报告生成模块504,用于若响应数据与期望数据一致,则测试用例测试通过并生成测试报告。
67.需要说明的是,上述实施例所提供的车辆诊断自动化测试装置与上述实施例所提供的车辆诊断自动化测试方法属于同一构思,其中各个模块和单元执行操作的具体方式已经在方法实施例中进行了详细描述,此处不再赘述。上述实施例所提供的车辆诊断自动化测试装置在实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能,本处也不对此进行限制。
68.本技术的实施例还提供了一种电子设备,包括:一个或多个处理器;存储装置,用于存储一个或多个程序,当所述一个或多个程序被所述一个或多个处理器执行时,使得所述电子设备实现上述各个实施例中提供的车辆诊断自动化测试方法。
69.图6示出了适于用来实现本技术实施例的电子设备的计算机系统的结构示意图。
需要说明的是,图6示出的电子设备的计算机系统600仅是一个示例,不应对本技术实施例的功能和使用范围带来任何限制。
70.如图6所示,计算机系统600包括中央处理单元(centralprocessingunit,cpu)601,其可以根据存储在只读存储器(read-onlymemory,rom)602中的程序或者从储存部分608加载到随机访问存储器(randomaccessmemory,ram)603中的程序而执行各种适当的动作和处理,例如执行上述实施例中所述的方法。在ram603中,还存储有系统操作所需的各种程序和数据。cpu601、rom602以及ram603通过总线604彼此相连。输入/输出(input/output,i/o)接口605也连接至总线604。
71.以下部件连接至i/o接口605:包括键盘、鼠标等的输入部分606;包括诸如阴极射线管(cathoderaytube,crt)、液晶显示器(liquidcrystaldisplay,lcd)等以及扬声器等的输出部分607;包括硬盘等的储存部分608;以及包括诸如lan(localareanetwork,局域网)卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至i/o接口605。可拆卸介质611,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器610上,以便于从其上读出的计算机程序根据需要被安装入储存部分608。
72.特别地,根据本技术的实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本技术的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中,该计算机程序可以通过通信部分609从网络上被下载和安装,和/或从可拆卸介质611被安装。在该计算机程序被中央处理单元(cpu)601执行时,执行本技术的系统中限定的各种功能。
73.需要说明的是,本技术实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(erasableprogrammablereadonlymemory,eprom)、闪存、光纤、便携式紧凑磁盘只读存储器(compactdiscread-onlymemory,cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本技术中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输,包括但不限于:无线、有线等等,或者上述的任意合适的组合。
74.附图中的流程图和框图,图示了按照本技术各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注
的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
75.描述于本技术实施例中所涉及到的单元可以通过软件的方式实现,也可以通过硬件的方式来实现,所描述的单元也可以设置在处理器中。其中,这些单元的名称在某种情况下并不构成对该单元本身的限定。
76.本技术的另一方面还提供了一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被计算机的处理器执行时,使计算机执行如前所述的车辆诊断自动化测试方法。该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的,也可以是单独存在,而未装配入该电子设备中。
77.本技术的另一方面还提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述各个实施例中提供的车辆诊断自动化测试方法。
78.上述实施例仅示例性说明本技术的原理及其功效,而非用于限制本技术。任何熟悉此技术的人士皆可在不违背本技术的精神及范畴下,对上述实施例进行修饰或改变。因此,但凡所属技术领域中具有通常知识者在未脱离本技术所揭示的精神与技术思想下所完成的一切等效修饰或改变,仍应由本技术的权利要求所涵盖。
技术特征:
1.一种车辆诊断自动化测试方法,其特征在于,所述车辆诊断自动化测试方法包括:获取测试用例和所述测试用例的功能类型,所述测试用例包括期望数据和测试数据;基于所述测试用例的所述功能类型将所述测试数据组装成测试报文;发送所述测试报文至待测试车辆单板,以得到响应数据;若所述响应数据与所述期望数据一致,则所述测试用例测试通过并生成测试报告。2.根据权利要求1所述的车辆诊断自动化测试方法,其特征在于,所述车辆诊断自动化测试方法,还包括:若所述响应数据与所述期望数据不一致,则所述测试用例测试失败并生成异常报告。3.根据权利要求1或2所述的车辆诊断自动化测试方法,其特征在于,基于所述测试用例的功能类型将所述测试数据组装成测试报文包括:基于所述测试用例的所述功能类型确定配置参数;根据所述配置参数将所述测试数据组装成所述测试报文。4.根据权利要求1或2所述的车辆诊断自动化测试方法,其特征在于,发送所述测试报文至待测试车辆单板,以得到响应数据包括:调用协议分析接口发送所述测试报文至所述待测试车辆单板,所述待测试车辆单板接收到所述测试报文后,基于所述车辆单板运行状态返回所述测试报文对应的所述响应数据。5.根据权利要求1或2所述的车辆诊断自动化测试方法,其特征在于,若所述响应数据与所述期望数据一致,则所述测试用例测试通过并生成测试报告包括:若所述响应数据与所述期望数据一致,则将所述测试用例的测试通过状态设置为通过;基于所述测试用例和所述测试通过状态生成测试报告;将所述测试报告基于表格或超文本标记语言形式保存。6.根据权利要求2所述的车辆诊断自动化测试方法,其特征在于,若所述响应数据与所述期望数据不一致,则所述测试用例测试失败并生成异常报告包括:若所述响应数据与所述期望数据不一致,则将所述测试用例的测试通过状态设置为失败;基于所述测试用例和所述测试通过状态生成所述异常报告;将所述异常报告基于表格或超文本标记语言形式保存。7.根据权利要求1或2所述的车辆诊断自动化测试方法,其特征在于,所述测试用例还包括用例编号、项目描述、发送方法以及是否执行中至少之一。8.一种车辆诊断自动化测试装置,其特征在于,所述车辆诊断自动化测试装置包括:用例获取模块,用于获取测试用例和所述测试用例的功能类型,所述测试用例包括期望数据和测试数据;报文组装模块,用于基于所述测试用例的所述功能类型将所述测试数据组装成测试报文;测试执行模块,用于发送所述测试报文至待测试车辆单板,以得到响应数据;报告生成模块,用于若所述响应数据与所述期望数据一致,则所述测试用例测试通过并生成测试报告。
9.一种电子设备,其特征在于,所述电子设备包括:一个或多个处理器;存储装置,用于存储一个或多个程序,当所述一个或多个程序被所述一个或多个处理器执行时,使得所述电子设备实现如权利要求1至7中任一项所述的车辆诊断自动化测试方法。10.一种计算机可读存储介质,其特征在于,其上存储有计算机程序,当所述计算机程序被计算机的处理器执行时,使计算机执行权利要求1至7中任一项所述的车辆诊断自动化测试方法。
技术总结
本发明提供一种车辆诊断自动化测试方法、装置、电子设备及介质,该方法包括获取测试用例和测试用例的功能类型,基于测试用例的功能类型将测试数据组装成测试报文,发送测试报文至待测试车辆单板,以得到响应数据,若响应数据与期望数据一致,则测试用例测试通过并生成测试报告,通过车辆诊断自动化检测方法极大程度的节省了人力物力和时间成本,而且还易于维护和迭代升级,避免了其他测试人员使用时的学习成本,降低了人工测试误测和漏测的概率,提高了车辆诊断的可靠性和有效性。高了车辆诊断的可靠性和有效性。高了车辆诊断的可靠性和有效性。
技术研发人员:刘磊
受保护的技术使用者:深蓝汽车科技有限公司
技术研发日:2023.05.04
技术公布日:2023/8/14
版权声明
本文仅代表作者观点,不代表航空之家立场。
本文系作者授权航家号发表,未经原创作者书面授权,任何单位或个人不得引用、复制、转载、摘编、链接或以其他任何方式复制发表。任何单位或个人在获得书面授权使用航空之家内容时,须注明作者及来源 “航空之家”。如非法使用航空之家的部分或全部内容的,航空之家将依法追究其法律责任。(航空之家官方QQ:2926969996)
飞行汽车 https://www.autovtol.com/
