CN118068754A - 汽车仪表软件测试方法、装置、设备及存储介质 - Google Patents

汽车仪表软件测试方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN118068754A
CN118068754A CN202410136016.9A CN202410136016A CN118068754A CN 118068754 A CN118068754 A CN 118068754A CN 202410136016 A CN202410136016 A CN 202410136016A CN 118068754 A CN118068754 A CN 118068754A
Authority
CN
China
Prior art keywords
test
simulation
signal
mcu
instrument
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202410136016.9A
Other languages
English (en)
Inventor
陈艳君
吴华伟
耿向阳
马毓博
李智
周哲
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hubei University of Arts and Science
Dongfeng Electric Drive Systems Co Ltd
Original Assignee
Hubei University of Arts and Science
Dongfeng Electric Drive Systems Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hubei University of Arts and Science, Dongfeng Electric Drive Systems Co Ltd filed Critical Hubei University of Arts and Science
Priority to CN202410136016.9A priority Critical patent/CN118068754A/zh
Publication of CN118068754A publication Critical patent/CN118068754A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/04Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0423Input/output
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/366Software debugging using diagnostics
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/24Pc safety
    • G05B2219/24215Scada supervisory control and data acquisition

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明属于汽车控制系统测试技术领域,公开了一种汽车仪表软件测试方法、装置、设备及存储介质。本发明通过获取测试任务,根据所述测试任务确定测试参数类型;根据所述测试参数类型,通过QT仿真信号库生成对应类型的仿真MCU测试信号;将所述仿真MCU测试信号传输至待测仪表盘,对所述待测仪表盘的MCU进行监听,得到所述仿真MCU测试信号的实际中间结果数据;获取所述待测仪表盘的实时显示结果,基于所述仿真MCU测试信号、实际中间结果数据以及实时显示结果,确定所述仪表主程序的故障板块。本发明通过生成仿真MCU测试信号并监听实际中间结果数据,能够快速确定故障位置,让对应类型的测试人员进行修复,提高测试效率与测试的准确性。

Description

汽车仪表软件测试方法、装置、设备及存储介质
技术领域
本发明涉及汽车控制系统测试技术领域,尤其涉及一种汽车仪表软件测试方法、装置、设备及存储介质。
背景技术
随着现代汽车科技的不断发展,汽车仪表盘在车辆信息显示和驾驶辅助方面起着关键作用。仪表软件的可靠性和安全性对于汽车制造商和开发团队来说至关重要。因此,对仪表软件进行全面的测试和验证是必不可少的。
目前,汽车仪表软件测试主要依赖于人工操作和基于模拟器的测试平台。针对仪表盘的调试问题,常见的分为前端调试和后端调试两种,前端调试是基于可视化的显示内容进行调试,而后端调试则是从软件的代码逻辑层面进行调试,调试结果仅限于特定的代码板块,然而,这些方法存在效率低下、准确性不足以及对人力资源和时间成本的高需求等问题。特别是在仪表盘的前端和后端调试中,由于两者操作不同步且可能产生冲突,导致调试效率较低。
专利申请公布号CN114964809B的文献中提出一种车辆仪表测试方法。首先,通过串口识别检测烧录成功的仪表。在此基础上,实现对仪表多个模块展开测试,并记录测试结果。当所有模块测试结果正常时,可判定整个仪表系统处于正常状态。该方法有效提升了测试效率,但在某功能测试结果异常时,无法明确故障板块是出现在前端代码还是后端代码中。这方面的限制可实现进一步的改进,以提高对异常情况的精确定位和诊断能力。
针对仪表盘的前端和后端调试冲突问题,需要一种新的汽车仪表软件测试方法。
发明内容
本发明的主要目的在于提供一种汽车仪表软件测试方法,旨在解决在仪表盘的前端和后端调试中,由于两者操作不同步且可能产生冲突,导致调试效率较低等一系列问题。
为实现上述目的,本发明提供了一种汽车仪表软件测试方法,所述汽车仪表软件测试方法,包括:
获取测试任务,根据所述测试任务确定测试参数类型;
根据所述测试参数类型,通过QT仿真信号库生成对应类型的仿真MCU测试信号;
将所述仿真MCU测试信号传输至待测仪表盘,对所述待测仪表盘的MCU进行监听,得到所述仿真MCU测试信号的实际中间结果数据;
获取所述待测仪表盘的实时显示结果,基于所述仿真MCU测试信号、实际中间结果数据以及实时显示结果,确定所述仪表主程序的故障板块。
可选地,所述获取测试任务,根据所述测试任务确定测试参数类型之前,还包括:
获取所述待测仪表的串口通信参数与串口通信协议,所述串口通信参数包括串口号、波特率、数据位、校验位以及停止位;
根据所述串口通信协议与串口通信参数,对所述待测仪表主程序进行初始化通信配置,建立串口通信。
可选地,所述获取测试任务,根据所述测试任务确定测试参数类型,包括:
获取测试任务,对所述测试任务进行解析,得到所述测试任务中所需的原始车辆信号数据;
根据所述原始车辆信号数据进行数据倒推,确定达成所述测试结果产生的中间结果数据;
将所述原始车辆信号数据与所述中间结果数据进行汇总,确定所述测试任务中所有的测试参数类型。
可选地,所述根据所述测试参数类型,通过QT仿真信号库生成对应类型的仿真MCU测试信号,包括:
基于QT仿真信号库,根据所述测试参数类型,确定仿真信号生成函数;
获取测试程序界面内所述测试参数类型对应的文本框内容;
当所述文本框内容不为空时,根据所述文本框内容,通过所述仿真信号生成函数,生成所述文本框内容对应的仿真MCU测试信号。
可选地,所述获取测试程序界面内所述测试参数类型对应的文本框内容之后,还包括:
当所述文本框内容为空时,获取所述测试参数类型的参数范围;
基于所述参数范围,通过随机生成函数,生成所述测试参数类型的随机值;
通过仿真信号生成函数,生成所述随机值对应的仿真MCU测试信号。
可选地,所述获取所述待测仪表盘的实时显示结果,基于所述仿真MCU测试信号、中间结果数据以及实时显示结果,确定所述仪表主程序的故障板块,包括:
获取所述待测仪表盘的实时显示结果;
根据所述仿真MCU测试信号,得到预测中间结果数据;
当所述实时显示结果与所述仿真MCU测试信号有差异,且所述预测中间结果数据与实际中间结果数据对应无误时,确定所述仪表主程序的故障板块位于前端代码部分;
当所述预测中间结果数据与实际中间结果数据有差异时,确定所述仪表主程序的故障板块位于后端代码部分。
可选地,所述获取所述待测仪表盘的实时显示结果,基于所述仿真MCU测试信号、中间结果数据以及实时显示结果,确定所述仪表主程序的故障板块,还包括:
获取所述待测仪表盘的实时显示结果;
根据所述仿真MCU测试信号,得到预测中间结果数据;
当所述实时显示结果与所述仿真MCU测试信号对应无误,且所述预测中间结果数据与实际中间结果数据对应无误时,确定所述仪表主程序无故障。
此外,为实现上述目的,本发明还提出一种汽车仪表软件测试装置,所述汽车仪表软件测试装置,包括:
参数类型获取模块,用于获取测试任务,根据所述测试任务确定测试参数类型;
仿真信号生成模块,用于根据所述测试参数类型,通过QT仿真信号库生成对应类型的仿真MCU测试信号;
信号监听模块,用于将所述仿真MCU测试信号传输至待测仪表盘,对所述待测仪表盘的MCU进行监听,得到所述仿真MCU测试信号的实际中间结果数据;
故障确认模块,用于获取所述待测仪表盘的实时显示结果,基于所述仿真MCU测试信号、实际中间结果数据以及实时显示结果,确定所述仪表主程序的故障板块。
此外,为实现上述目的,本发明还提出一种汽车仪表软件测试设备,所述汽车仪表软件测试设备包括:存储器、处理器及存储在所述存储器上并可在所述处理器上运行的汽车仪表软件测试程序,所述汽车仪表软件测试程序配置为实现所述的汽车仪表软件测试方法的步骤。
此外,为实现上述目的,本发明还提出一种存储介质,所述存储介质上存储有汽车仪表软件测试程序,所述汽车仪表软件测试程序被处理器执行时实现所述的汽车仪表软件测试方法的步骤。
本发明通过获取测试任务,根据所述测试任务确定测试参数类型;根据所述测试参数类型,通过QT仿真信号库生成对应类型的仿真MCU测试信号;将所述仿真MCU测试信号传输至待测仪表盘,对所述待测仪表盘的MCU进行监听,得到所述仿真MCU测试信号的实际中间结果数据;获取所述待测仪表盘的实时显示结果,基于所述仿真MCU测试信号、实际中间结果数据以及实时显示结果,确定所述仪表主程序的故障板块。本发明通过生成仿真MCU测试信号传输至待测仪表盘的主程序,并监听实际产生的中间结果数据,能够快速确定故障位置,让对应的测试人员进行修复,提高测试效率与测试的准确性。
附图说明
图1是本发明实施例方案涉及的硬件运行环境的汽车仪表软件测试设备的结构示意图;
图2为本发明汽车仪表软件测试方法第一实施例的流程示意图;
图3为本发明汽车仪表软件测试方法第二实施例的流程示意图;
图4为本发明汽车仪表软件测试方法第三实施例的流程示意图;
图5为本发明汽车仪表软件测试方法第四实施例的流程示意图;
图6为本发明汽车仪表软件测试装置第一实施例的结构框图。
本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。
具体实施方式
应当理解,此处所描述的具体实施例仅用以解释本发明,并不用于限定本发明。
参照图1,图1为本发明实施例方案涉及的硬件运行环境的汽车仪表软件测试设备结构示意图。
如图1所示,该汽车仪表软件测试设备可以包括:处理器1001,例如中央处理器(Central Processing Unit,CPU),通信总线1002、用户接口1003,网络接口1004,存储器1005。其中,通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard),可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(Wireless-Fidelity,Wi-Fi)接口)。存储器1005可以是高速的随机存取存储器(RandomAccess Memory,RAM)存储器,也可以是稳定的非易失性存储器(Non-Volatile Memory,NVM),例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。
本领域技术人员可以理解,图1中示出的结构并不构成对汽车仪表软件测试设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
如图1所示,作为一种存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及汽车仪表软件测试程序。
在图1所示的汽车仪表软件测试设备中,网络接口1004主要用于与网络服务器进行数据通信;用户接口1003主要用于与用户进行数据交互;本发明汽车仪表软件测试设备中的处理器1001、存储器1005可以设置在汽车仪表软件测试设备中,所述汽车仪表软件测试设备通过处理器1001调用存储器1005中存储的汽车仪表软件测试程序,并执行本发明实施例提供的汽车仪表软件测试方法。
本发明实施例提供了一种汽车仪表软件测试方法,参照图2,图2为本发明汽车仪表软件测试方法第一实施例的流程示意图。
步骤S10:获取测试任务,根据所述测试任务确定测试参数类型。
需要说明的是,测试任务一般包括指定需要进行测试的内容,例如对于仪表盘程序而言,测试任务可以特指为有关速度显示、油耗显示或者其他类型的显示内容的调试,例如,当测试任务为速度显示方面的任务类型,此时需要确定的测试参数类型就是与车速相关的测试参数,而这类参数经过细分后可能包括一系列与车速这个板块相关的车速值、速度单位、速度变化响应、警示功能等内容,每一个都对应一种测试参数类型。
可以理解的是,测试任务只是确定大体的测试方向,基于这个方向,测试程序确定出执行此次测试可能需要使用或者检测的测试参数,一般情况下,测试参数除了直接显示到仪表盘显示界面的内容以外,还包括一些中间结果数据,例如,常规的速度显示一般是根据速度传感器得到的实时结果作为速度显示的参考值,但是另一方面,实时车速与车轮转速具有一定的对应关系,通过并不复杂的计算可以通过实时的车轮转速得到实时车速,此时根据车轮转速得到车速的过程中,计算出的车速值就是中间结果数据,这里的中间结果数据的数据类型应该归纳为测试参数的一种,所以实际情况中,测试结果除了部分传感器能够直接得到显示结果的类型以外,还包括中间结果数据代表的类型,这两部分共同组成测试参数类型。
应当理解的是,与直接通过传感器得到的数据结果相比,通过中间参数得到的数据结果能够作为辅助验证实时的显示结果,由于传感器中得到的数据在不经过处理直接显示到显示界面的情况下,缺少逻辑代码的验证,很容易与实际情况不符,导致用户误解或错误判断,因此一般情况下针对同一个显示内容会设置验证程序,而验证程序中将引入新的中间结果数据作为额外的测试参数类型。
步骤S20:根据所述测试参数类型,通过QT仿真信号库生成对应类型的仿真MCU测试信号。
需要说明的是,QT是一个跨平台的 C++ 应用程序开发框架。QT提供了一套工具和库,用于构建图形用户界面 (GUI) 应用程序和非 GUI 应用程序。QT的信号和槽是一种用于处理对象间通信的机制,它用于将特定事件(信号)与相应的操作(槽)进行连接,从而实现对象间的交互。在仿真MCU测试信号的生成过程中,可以使用信号和槽机制来模拟MCU内部的信号传输,实现自定义的仿真信号库,用于生成仿真信号,可以根据实际需求,实现合适的仿真信号库。
可以理解的是,通过QT仿真信号库,可以模拟生成真实的原始车辆信号传输给待测仪表盘程序,而仪表盘程序根据接收到这种信号进行处理并作为显示结果,另一方面,QT仿真信号库还可以模拟生成真实的中间数据信号,只要以特定的通信方式传输到仪表盘主程序内的节点中,该主程序一样可以根据当前情况,处理当前接收到的中间数据信号,并将处理结果显示在显示界面上。
可以理解的是,仿真MCU测试信号根据类型分为数据信号、故障码信号和控制信号三类,数据信号反映车辆状态和性能,如车速、发动机转速等;故障码信号指示车辆是否出现故障或异常,例如发动机故障码;控制信号是MCU发送给车辆系统和控制器的指令,如切换行驶模式、激活安全功能等。模拟这些信号可用于测试仪表盘与MCU通信的正常性和准确性,以及验证仪表盘的功能和稳定性。
应当理解的是,QT仿真信号库设计了一套完备的仿真信号算法,既可以根据需要,计算出指定物理量对应的原始车辆信号,也可以进一步根据原始车辆信号计算出对应的中间数据,也就是说只要确定了一项测试参数的类型,就可以生成与该测试参数相关联的其他测试参数。
步骤S30:将所述仿真MCU测试信号传输至待测仪表盘,对所述待测仪表盘的MCU进行监听,得到所述仿真MCU测试信号的实际中间结果数据。
需要说明的是,由于针对仪表盘的调试一般分为在仪表界面、图标位置或者其他类型的前端调试,以及根据接收到的传感器信号这类数据逻辑层面的后端调试,针对后端的调试由于不像前端调试是基于可视化的显示内容进行调试,而是后端测试工程师从软件的代码逻辑层面在编辑器中进行调试的,调试结果只能局限在某个特定的代码板块,与前端调试是不同步的,双方调试操作容易产生冲突,需要双方在软件逻辑与显示逻辑协同调试才能确保结果正确。
可以理解的是,区分前后端代码故障的关键点在于确定有待测仪表盘进行处理后得到的中间信号是否出现错误,由于信号的处理与流转是基于原始信号到中间信号,再到显示结果的流程,其中从原始车辆信号到中间数据的过程是由后端代码按照其代码逻辑进行处理的,从中间信号到显示结果的过程一般是由前端代码按照其显示逻辑进行处理的,通过对中间数据进行单独校验,可以以此作为分水岭确定故障位置的所在。
应当理解的是,中间数据在实际情况下可以不止一个,这是因为进行显示之前可能存在多个处理阶段或数据流转以及验证的过程,这样会像数据链条一样产生多个中间数据,只有当全部的中间数据都能正确时,才能确保最终后端程序没有出错。另一方面,当中间数据无误但最终的显示结果出现问题时,则可以确定是前端代码出现问题。
步骤S40:获取所述待测仪表盘的实时显示结果,基于所述仿真MCU测试信号、实际中间结果数据以及实时显示结果,确定所述仪表主程序的故障板块。
需要说明的是,由于执行的过程中,仿真MCU测试信号是由仿真信号库产生的,而仿真信号库可以根据已经产生的仿真MCU测试信号进一步得到该信号对应的中间数据,并将此处计算得到的中间数据作为实际得到的中间数据的参考值,通过对比两者,可以确定MCU在处理过程中得到的中间数据是否出现错误。
可以理解的是,当中间数据经过对比后全部无误时,可以认为后端代码没有出现故障,所有的数据在后端部分都得到了正确处理,在此基础之上,如果显示结果也能够正确显示仿真MCU测试信号对应的显示结果,则证明前端代码部分也没有出现问题,反之则是故障出现在前端代码部分。
在本实施例中,通过获取测试任务,根据所述测试任务确定测试参数类型,根据所述测试参数类型,通过QT仿真信号库生成对应类型的仿真MCU测试信号,将所述仿真MCU测试信号传输至待测仪表盘,对所述待测仪表盘的MCU进行监听,得到所述仿真MCU测试信号的实际中间结果数据,获取所述待测仪表盘的实时显示结果,基于所述仿真MCU测试信号、实际中间结果数据以及实时显示结果,确定所述仪表主程序的故障板块。通过上述步骤实现了细分测试参数类型,利用QT仿真信号库生成仿真信号,模拟真实场景。通过对比结果确定故障板块并针对性修复,提高测试效率和准确性,改进产品质量和用户体验的有益效果。
参照图3,图3为本发明汽车仪表软件测试方法第二实施例的流程示意图。
基于上述第一实施例,本实施例汽车仪表软件测试方法中所述步骤S10,包括:
步骤S101:获取测试任务,对所述测试任务进行解析,得到所述测试任务中所需的原始车辆信号数据。
需要说明的是,测试任务一般只是确定待测仪表盘上需要测试的显示项目,而从原始车辆信号数据到实际的显示项目则需要提前确认该车辆的电子系统手册或者仪表盘的型号,然后根据仪表盘的型号、技术规格或者相关文档,了解仪表盘各个显示项目的逻辑和计算方式,以确定实际过程中该类型的仪表盘所需要的原始车辆信号。
进一步的,在所述步骤S101之前,还包括:获取所述待测仪表的串口通信参数与串口通信协议,所述串口通信参数包括串口号、波特率、数据位、校验位以及停止位;根据所述串口通信协议与串口通信参数,对所述待测仪表主程序进行初始化通信配置,建立串口通信。
可以理解的是,从仪表盘的技术规格文件或者相关厂家提供的文档中获取串口通信参数,包括串口号、波特率、数据位、校验位以及停止位,同时也需要了解串口通信协议的规范,如通信命令格式、数据交互流程等,然后在软件开发环境中,使用相应的串口通信库或API,根据所获得的串口通信参数,设置串口号、波特率、数据位、校验位和停止位等参数,根据通信协议的规范,编写程序代码,包括通信命令的格式、数据交互流程以及与待测仪表的通信方式的设置。这可能涉及特定的通信协议解析和封装,确保程序能够准确地发送和接收数据,最后将初始化好的通信配置加载到待测仪表的主程序中,即可完成两者的通信连接。
步骤S102:根据所述原始车辆信号数据进行数据倒推,确定达成显示结果产生的中间结果数据。
需要说明的是,中间结果数据是经过对原始车辆信号数据进行处理和计算得出的数据,用于最终呈现在仪表盘上的显示项目,对获取的原始车辆信号数据进行解析,将其转换为可读取和使用的格式,如数值、状态、文本等,然后根据已经得到的实际信息,可以进一步倒推出可能需要的中间信号,例如,当测试任务包括了车速时,中间信号的类型可能是车轮转速或者燃油消耗量,然后进一步根据车轮转速倒推出发动机转速等中间数据,由此例可知,在一定条件下,可以跟据发动机转速、车轮转速、燃油消耗量可以确定最终的车速信息,当确认了显示项目对应的中间信息之后,就能够确定整体上所有需要生成或对比的数据类型了,然后由仿真信号生成库,根据其中一个信号类型的具体值,可以间接计算出其他信号类型的具体值。
步骤S103:将所述原始车辆信号数据与所述中间结果数据进行汇总,确定所述测试任务中所有的测试参数类型。
可以理解的是,当原始车辆信号数据的类型确认后,可以根据上述方法推理出该原始车辆信号相关的中间数据类型,将这些数据类型进行汇总,可以确定此次测试任务整体需要的测试参数类型。
在本实施例中,通过获取测试任务,对所述测试任务进行解析,得到所述测试任务中所需的原始车辆信号数据,根据所述原始车辆信号数据进行数据倒推,确定达成显示结果产生的中间结果数据,将所述原始车辆信号数据与所述中间结果数据进行汇总,确定所述测试任务中所有的测试参数类型。通过上述步骤,可以确定此次测试任务中所有需要的测试参数类型,当这部分数据确认后可以供给仿真信号生成库一次性在全局范围内生成所有的仿真信号,有利于降低多次信号生成带来的调试冲突的情况。
参照图4,图4为本发明汽车仪表软件测试方法第三实施例的流程示意图。
基于上述第一实施例,本实施例汽车仪表软件测试方法中所述步骤S20,包括:
步骤S201:基于QT仿真信号库,根据所述测试参数类型,确定仿真信号生成函数。
需要说明的是,根据前一步骤中确定的测试参数类型,包括所有需要生成或对比的数据类型,明确需要生成仿真信号的数据类型的汇总结果,根据QT仿真信号库的文档和API,查找相应的接口函数来生成各类测试参数类型所需的仿真信号。在函数内部,调用QT提供的信号生成接口,根据每种参数类型的特点和要求,生成符合标准的仿真信号数据。
可以理解的是,通过调用仿真信号生成函数,根据参数类型提供的具体值,生成对应的仿真信号数据,使得确保生成的信号能够准确模拟实际车辆的信号数据特征。然后将编写的仿真信号生成函数集成到测试环境中,确保在测试过程中能够根据需要自动调用并生成相应的仿真信号数据,以满足测试需求。
步骤S202:获取测试程序界面内所述测试参数类型对应的文本框内容。
需要说明的是,测试参数的类型是由测试程序根据测试任务进行推演得到的,而具体的测试参数值是通过在测试程序界面进行直接设置的,例如测试时,输入的测试内容为车速类型,就可以对应设置产生的车速值,并依照具体的车速值,可以按照一定的计算方式,得到该车速值对应的中间数据的具体值,并以此作为后续测试中由待测仪表盘主程序产生的中间数据的对比值。
可以理解的是,测试程序界面包含了多个原始车辆信号类型以及其对应的文本框,通过在这些文本框内输入具体数值或者具体文本,可以人为调整测试信号的产生结果。
步骤S203:当所述文本框内容不为空时,根据所述文本框内容,通过所述仿真信号生成函数,生成所述文本框内容对应的仿真MCU测试信号。
需要说明的是,由于界面内的测试参数类型一般情况下不止一项,而是包含多项内容,而部分测试参数之间由于具有一定的关联性,当某一项确定以后,另一项测试参数也对应确定了,例如,当车轮转速或者发动机转速确定时,车速会限制在一定范围内,在这种情况下就无法任意设置车速值,而是以已经设置完成的参数值作为依据,生成对应的测试信号即可。
进一步的,当所述文本框内容为空时,获取所述测试参数类型的参数范围;基于所述参数范围,通过随机生成函数,生成所述测试参数类型的随机值;通过仿真信号生成函数,生成所述随机值对应的仿真MCU测试信号。
需要说明的是,当文本框内容为空时,由于其他关联参数的限制导致没有被设置的参数类型,会按照该参数适当的范围进行随机生成,并将随机生成值填入文本框内供以展示,同理,没有被特意设置的测试参数也会按照正常的测试范围,生成该参数的随机值,并以此生成对应的测试信号。
在本实施例中,基于QT仿真信号库,根据所述测试参数类型,确定仿真信号生成函数;获取测试程序界面内所述测试参数类型对应的文本框内容;当所述文本框内容不为空时,根据所述文本框内容,通过所述仿真信号生成函数,生成所述文本框内容对应的仿真MCU测试信号;当所述文本框内容为空时,获取所述测试参数类型的参数范围;基于所述参数范围,通过随机生成函数,生成所述测试参数类型的随机值;通过仿真信号生成函数,生成所述随机值对应的仿真MCU测试信号。解决了测试信号之间的冲突问题,有利于测试工作的快速展开。
参照图5,图5为本发明汽车仪表软件测试方法第三实施例的流程示意图。
基于上述第一实施例,本实施例汽车仪表软件测试方法中所述步骤S40,包括:
步骤S401:获取所述待测仪表盘的实时显示结果。
需要说明的是,当测试信号按照既定的串口通信传输至MCU后,经过短暂时间的处理,待测仪表盘会根据测试信号产生对应的显示画面,而根据测试任务可以确定显示画面中该测试信号对应的显示结果。
步骤S402:根据所述仿真MCU测试信号,得到预测中间结果数据。
可以理解的是,当仿真MCU测试信号确定后,与其关联的中间结果数据也可以进一步确定,而此处的中间结果数据是基于仿真信号生成函数进行数据推演来的,也就是说得到的是该类型中间结果数据的预测值,而后续过程中通过串口通信对MCU进行监听的过程中可以得到实际的中间结果数据,通过两者的对比可以确定该仪表盘主程序是否存在故障,以及故障的位置。
步骤S403:当所述实时显示结果与所述仿真MCU测试信号有差异,且所述预测中间结果数据与实际中间结果数据对应无误时,确定所述仪表主程序的故障板块位于前端代码部分。
进一步的,当所述预测中间结果数据与实际中间结果数据有差异时,确定所述仪表主程序的故障板块位于后端代码部分。
进一步的,当所述实时显示结果与所述仿真MCU测试信号对应无误,且所述预测中间结果数据与实际中间结果数据对应无误时,确定所述仪表主程序无故障。
在本实施例中,通过获取所述待测仪表盘的实时显示结果,根据所述仿真MCU测试信号,得到预测中间结果数据,然后将实时显示结果与仿真MCU测试信号进行对比,从而确定仪表盘主程序是否存在故障,然后通过对比理论上的预测中间结果数据与串口通信处监听的实际中间结果数据,确定最终的故障位置。这有助于提高测试的准确性和效率,帮助开发人员快速定位和修复软件故障,优化仪表盘主程序。
如图6所示,本发明实施例提出的汽车仪表软件测试装置包括:
参数类型获取模块10,用于获取测试任务,根据所述测试任务确定测试参数类型;
仿真信号生成模块20,用于根据所述测试参数类型,通过QT仿真信号库生成对应类型的仿真MCU测试信号;
信号监听模块30,用于将所述仿真MCU测试信号传输至待测仪表盘,对所述待测仪表盘的MCU进行监听,得到所述仿真MCU测试信号的实际中间结果数据;
故障确认模块40,用于获取所述待测仪表盘的实时显示结果,基于所述仿真MCU测试信号、实际中间结果数据以及实时显示结果,确定所述仪表主程序的故障板块。
在一实施例中,所述信号监听模块30,还用于获取所述待测仪表的串口通信参数与串口通信协议,所述串口通信参数包括串口号、波特率、数据位、校验位以及停止位;根据所述串口通信协议与串口通信参数,对所述待测仪表主程序进行初始化通信配置,建立串口通信。
在一实施例中,所述参数类型获取模块10,还用于获取测试任务,对所述测试任务进行解析,得到所述测试任务中所需的原始车辆信号数据;根据所述原始车辆信号数据进行数据倒推,确定达成显示结果产生的中间结果数据;将所述原始车辆信号数据与所述中间结果数据进行汇总,确定所述测试任务中所有的测试参数类型。
在一实施例中,所述仿真信号生成模块20,还用于基于QT仿真信号库,根据所述测试参数类型,确定仿真信号生成函数;获取测试程序界面内所述测试参数类型对应的文本框内容;当所述文本框内容不为空时,根据所述文本框内容,通过所述仿真信号生成函数,生成所述文本框内容对应的仿真MCU测试信号。
在一实施例中,所述仿真信号生成模块20,还用于当所述文本框内容为空时,获取所述测试参数类型的参数范围;基于所述参数范围,通过随机生成函数,生成所述测试参数类型的随机值;通过仿真信号生成函数,生成所述随机值对应的仿真MCU测试信号。
在一实施例中,所述故障确认模块40,还用于获取所述待测仪表盘的实时显示结果;根据所述仿真MCU测试信号,得到预测中间结果数据;当所述实时显示结果与所述仿真MCU测试信号有差异,且所述预测中间结果数据与实际中间结果数据对应无误时,确定所述仪表主程序的故障板块位于前端代码部分;当所述预测中间结果数据与实际中间结果数据有差异时,确定所述仪表主程序的故障板块位于后端代码部分。
在一实施例中,所述故障确认模块40,还用于当所述实时显示结果与所述仿真MCU测试信号对应无误,且所述预测中间结果数据与实际中间结果数据对应无误时,确定所述仪表主程序无故障。
此外,为实现上述目的,本发明提供一种汽车仪表软件测试设备,所述汽车仪表软件测试设备包括:存储器、处理器及存储在所述存储器上并可在所述处理器上运行的汽车仪表软件测试程序,所述汽车仪表软件测试程序配置为实现所述的汽车仪表软件测试方法的步骤。
此外,为实现上述目的,本发明提供一种存储介质,所述存储介质上存储有汽车仪表软件测试程序,所述汽车仪表软件测试程序被处理器执行时实现所述的汽车仪表软件测试方法的步骤。
应该理解的是,虽然本申请实施例中的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,其可以以其他的顺序执行。而且,图中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,其执行顺序也不必然是依次进行,而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
需要说明的是,以上所描述的工作流程仅仅是示意性的,并不对本发明的保护范围构成限定,在实际应用中,本领域的技术人员可以根据实际的需要选择其中的部分或者全部来实现本实施例方案的目的,此处不做限制。
此外,需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述 实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通 过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的 技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体 现出来,该计算机软件产品存储在一个存储介质(如只读存储器(Read Only Memory,ROM)/RAM、磁碟、光 盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种汽车仪表软件测试方法,其特征在于,所述汽车仪表软件测试方法,包括:
获取测试任务,根据所述测试任务确定测试参数类型;
根据所述测试参数类型,通过QT仿真信号库生成对应类型的仿真MCU测试信号;
将所述仿真MCU测试信号传输至待测仪表盘,对所述待测仪表盘的MCU进行监听,得到所述仿真MCU测试信号的实际中间结果数据;
获取所述待测仪表盘的实时显示结果,基于所述仿真MCU测试信号、实际中间结果数据以及实时显示结果,确定所述仪表主程序的故障板块。
2.根据权利要求1所述的汽车仪表软件测试方法,其特征在于,所述获取测试任务,根据所述测试任务确定测试参数类型之前,还包括:
获取所述待测仪表的串口通信参数与串口通信协议,所述串口通信参数包括串口号、波特率、数据位、校验位以及停止位;
根据所述串口通信协议与串口通信参数,对所述待测仪表主程序进行初始化通信配置,建立串口通信。
3.根据权利要求1所述的汽车仪表软件测试方法,其特征在于,所述获取测试任务,根据所述测试任务确定测试参数类型,包括:
获取测试任务,对所述测试任务进行解析,得到所述测试任务中所需的原始车辆信号数据;
根据所述原始车辆信号数据进行数据倒推,确定达成显示结果产生的中间结果数据;
将所述原始车辆信号数据与所述中间结果数据进行汇总,确定所述测试任务中所有的测试参数类型。
4.根据权利要求1所述的汽车仪表软件测试方法,其特征在于,所述根据所述测试参数类型,通过QT仿真信号库生成对应类型的仿真MCU测试信号,包括:
基于QT仿真信号库,根据所述测试参数类型,确定仿真信号生成函数;
获取测试程序界面内所述测试参数类型对应的文本框内容;
当所述文本框内容不为空时,根据所述文本框内容,通过所述仿真信号生成函数,生成所述文本框内容对应的仿真MCU测试信号。
5.根据权利要求4所述的汽车仪表软件测试方法,其特征在于,所述获取测试程序界面内所述测试参数类型对应的文本框内容之后,还包括:
当所述文本框内容为空时,获取所述测试参数类型的参数范围;
基于所述参数范围,通过随机生成函数,生成所述测试参数类型的随机值;
通过仿真信号生成函数,生成所述随机值对应的仿真MCU测试信号。
6.根据权利要求1所述的汽车仪表软件测试方法,其特征在于,所述获取所述待测仪表盘的实时显示结果,基于所述仿真MCU测试信号、中间结果数据以及实时显示结果,确定所述仪表主程序的故障板块,包括:
获取所述待测仪表盘的实时显示结果;
根据所述仿真MCU测试信号,得到预测中间结果数据;
当所述实时显示结果与所述仿真MCU测试信号有差异,且所述预测中间结果数据与实际中间结果数据对应无误时,确定所述仪表主程序的故障板块位于前端代码部分;
当所述预测中间结果数据与实际中间结果数据有差异时,确定所述仪表主程序的故障板块位于后端代码部分。
7.根据权利要求1所述的汽车仪表软件测试方法,其特征在于,所述获取所述待测仪表盘的实时显示结果,基于所述仿真MCU测试信号、实际中间结果数据以及实时显示结果,确定所述仪表主程序的故障板块,还包括:
获取所述待测仪表盘的实时显示结果;
根据所述仿真MCU测试信号,得到预测中间结果数据;
当所述实时显示结果与所述仿真MCU测试信号对应无误,且所述预测中间结果数据与实际中间结果数据对应无误时,确定所述仪表主程序无故障。
8.一种汽车仪表软件测试装置,其特征在于,所述汽车仪表软件测试装置,包括:
参数类型获取模块,用于获取测试任务,根据所述测试任务确定测试参数类型;
仿真信号生成模块,用于根据所述测试参数类型,通过QT仿真信号库生成对应类型的仿真MCU测试信号;
信号监听模块,用于将所述仿真MCU测试信号传输至待测仪表盘,对所述待测仪表盘的MCU进行监听,得到所述仿真MCU测试信号的实际中间结果数据;
故障确认模块,用于获取所述待测仪表盘的实时显示结果,基于所述仿真MCU测试信号、实际中间结果数据以及实时显示结果,确定所述仪表主程序的故障板块。
9.一种汽车仪表软件测试设备,其特征在于,所述汽车仪表软件测试设备包括:存储器、处理器及存储在所述存储器上并可在所述处理器上运行的汽车仪表软件测试程序,所述汽车仪表软件测试程序配置为实现如权利要求1至7中任一项所述的汽车仪表软件测试方法的步骤。
10.一种存储介质,其特征在于,所述存储介质上存储有汽车仪表软件测试程序,所述汽车仪表软件测试程序被处理器执行时实现如权利要求1至7任一项所述的汽车仪表软件测试方法的步骤。
CN202410136016.9A 2024-01-31 2024-01-31 汽车仪表软件测试方法、装置、设备及存储介质 Pending CN118068754A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410136016.9A CN118068754A (zh) 2024-01-31 2024-01-31 汽车仪表软件测试方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202410136016.9A CN118068754A (zh) 2024-01-31 2024-01-31 汽车仪表软件测试方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
CN118068754A true CN118068754A (zh) 2024-05-24

Family

ID=91094507

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202410136016.9A Pending CN118068754A (zh) 2024-01-31 2024-01-31 汽车仪表软件测试方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN118068754A (zh)

Similar Documents

Publication Publication Date Title
CN112860563B (zh) 汽车诊断仪测试方法、装置、设备及存储介质
CN110907882B (zh) 一种面向电能表的虚拟化的测试方法及系统
US20070157134A1 (en) Method for testing a hardware circuit block written in a hardware description language
CN110968517B (zh) 自动测试方法、装置、平台和计算机可读存储介质
CN113918465A (zh) 兼容性测试方法、装置、电子设备及可读存储介质
CN118068754A (zh) 汽车仪表软件测试方法、装置、设备及存储介质
CN109960238B (zh) 一种车辆诊断仪自动化测试系统和方法
CN111190786A (zh) 基于uvm的测试构架、测试平台及测试方法
Suganya et al. A study of object oriented testing techniques: Survey and challenges
CN115840707A (zh) 一种刷写测试方法、装置及介质
CN115422033A (zh) 一种分布交互式仿真时序验证方法和系统
CN111782553B (zh) 一种基于故障注入的软件反应缺陷分析方法
CN104572470A (zh) 一种基于蜕变关系的整数溢出故障检测方法
CN115185258A (zh) 一种适用于整车控制器的hil仿真测试系统及方法
CN113986753A (zh) 接口测试方法、装置、设备及存储介质
CN115129495A (zh) 故障处理方法、装置、终端设备及计算机可读存储介质
JPH1185828A (ja) 順序回路機能検証方法および順序回路機能検証システム
CN111427762A (zh) 自动调用工具分析技术
CN111044826A (zh) 检测方法及检测系统
CN118113618A (zh) 软件测试库生成方法、装置、设备、介质以及程序产品
AU2023201696B2 (en) Method and device for determining coverage in HIL testing, and storage medium
Heimdahl et al. NIMBUS: A tool for specification centered development
CN118567974A (zh) 一种基于打桩的软件集成测试方法、系统及存储介质
US11847393B2 (en) Computing device and method for developing a system model utilizing a simulation assessment module
CN114546845B (zh) 一种功能安全软件工具链的鉴定方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination