一种基于虚拟测试工具的TBox功能测试方法及系统

技术领域

本发明涉及车辆技术领域，特别涉及一种基于虚拟测试工具的TBox功能测试方法及系统。

背景技术

TBox是当前智能网联汽车的核心部件，主要负责车端和云端通讯。其中通讯数据主要分为上行和下行两种方向：1.车端数据主动上报(例如：车端数据或事件主动周期性上报云端)；2.云端下发命令到车端执行，车端将执行结果反馈云端(例如：云端查询车端配置信息或云端控制车端执行相关命令等)。

目前，在车辆下线入库前，都需要对TBox进行性能测试，其中，当前TBOX测试主要分为台架测试和实车测试两种：台架测试主要通过以下方式测试：在进行上行测试时，车端通过CANoe模拟车端周期性发送CAN报文到TBox，TBox按照OTA信号列表周期上报车端数据到云端。在进行下行测试时，云端下发远控，查询等命令到TBox，TBox发送整车控制命令到CANoe，CANoe模拟整车应答控制命令，将控制结果返回给TBox，最终反馈回云端。而实车测试的方式与台架测试方案类似，仅仅只是把虚拟的车端(CANoe)替换为实车，其它整个测试方案无差别。

然而，上述两种方式都属于手动测试方案，只能人工认定测试结果。实车测试无法模拟很多整车不容易出现的故障状态，例如：很多发动机故障无法模拟，大部分情况下只能测试正常工况。导致测试效果差。

发明内容

有鉴于此，本发明的目的在于提供一种基于虚拟测试工具的TBox功能测试方法及系统，旨在解决现有技术中在进行TBox测试时效果差的问题。

本发明实施例是这样实现的：

一种基于虚拟测试工具的TBox功能测试方法，应用于测试终端，所述测试终端集成有测试工具，所述方法包括：

获取车辆TBox在实际过程当中需要遇到的不同测试场景，并根据所述测试场景设计对应的测试用例及制定预期测试结果以对所述测试工具进行初始化处理；

当检测到所述TBox需要进行上行测试时，获取测试数据，并将所述测试数据通过报文的形式以预设工具发送给所述TBox，后通过所述TBox对所述测试数据进行处理后，后发送处理结果给所述测试工具以确定所述TBox上行通讯是否正常；

当检测到所述车辆需要进行下行测试时，获取测试指令，并将所述测试指令发送给车辆远程通讯模块，后通过所述车辆远程通讯模块发送执行所述测试指令的测试报文至所述测试工具，后将测试结果发送至所述车辆远程通讯模块转发给所述测试工具以确定所述TBox下行通讯是否正常。

进一步的，上述基于虚拟测试工具的TBox功能测试方法，其中，所述当检测到所述TBox需要进行上行测试时，获取测试数据，并将所述测试数据通过报文的形式以预设工具发送给所述TBox，后通过所述TBox对所述测试数据进行处理后，后发送处理结果给所述测试工具以确定所述TBox上行通讯是否正常的步骤包括：

当检测到所述TBox需要进行车况数据上报功能测试时，模拟发送各种不同的报文，所述报文中包含车辆的各种不同车况信号；

通过所述TBox接收所述各种不同车况信号并获取对应的车况数据结果，根据所述车况数据结果与所述测试工具中的车况信号对应的预期测试结果是否一致确定所述TBox上行通讯是否正常。

进一步的，上述基于虚拟测试工具的TBox功能测试方法，其中，所述当检测到所述车辆需要进行下行测试时，获取测试指令，并将所述测试指令发送给车辆远程通讯模块，后通过所述车辆远程通讯模块发送执行所述测试指令的测试报文至所述测试工具，后将测试结果发送至所述车辆远程通讯模块转发给所述测试工具以确定所述TBox下行通讯是否正常的步骤包括：

当检测到所述TBox需要进行远控开车门功能测试时，模拟下发远控开门指令至所述TBox；

控制所述TBox按照远控功能规范往CAN总线下发远控CAN报文，并在接收到所述远控CAN报文后，发送开门成功信息给所述TBox；

通过所述TBox按照OTA信号列表定义上报指令结果信息给所述测试工具，根据所述指令结果信息与所述开门成功信息是否一致确定所述TBox下行通讯是否正常。

进一步的，上述基于虚拟测试工具的TBox功能测试方法，其中，所述测试工具分别通过CAN tool以及车载以太网转换器与所述TBox通讯连接。

进一步的，上述基于虚拟测试工具的TBox功能测试方法，其中，所述测试工具内集成有CAN tool的驱动程序，以调用所述CAN tool提供的API接口控制CAN报文的接收和发送，从而与所述TBox通讯连接。

进一步的，上述基于虚拟测试工具的TBox功能测试方法，其中，所述测试工具依次通过车载以太网转换器、网线与所述TBox通讯连接，以模拟云端接收所述TBox的上报数据以及发送远控命令给所述TBox。

进一步的，上述基于虚拟测试工具的TBox功能测试方法，其中，其特征在于，所述方法还包括：

连续下发多条远控指令至所述TBox，控制所述TBox按照远控功能规范往CAN总线下发远控CAN报文；

通过所述TBox按照OTA信号列表定义上报的多条指令结果信息给所述测试工具是否正确以对所述TBox远控压力进行测试。

本发明的另一个目的在于提供一种基于虚拟测试工具的TBox功能测试系统，应用于测试终端，所述测试终端集成有测试工具，所述系统包括：

获取模块，用于获取车辆TBox在实际过程当中需要遇到的不同测试场景，并根据所述测试场景设计对应的测试用例及制定预期测试结果以对所述测试工具进行初始化处理；

上行检测模块，用于当检测到所述TBox需要进行上行测试时，获取测试数据，并将所述测试数据通过报文的形式以预设工具发送给所述TBox，后通过所述TBox对所述测试数据进行处理后，后发送处理结果给所述测试工具以确定所述TBox上行通讯是否正常；

下行检测模块，用于当检测到所述车辆需要进行下行测试时，获取测试指令，并将所述测试指令发送给车辆远程通讯模块，后通过所述车辆远程通讯模块发送执行所述测试指令的测试报文至所述测试工具，后将测试结果发送至所述车辆远程通讯模块转发给所述测试工具以确定所述TBox下行通讯是否正常。

本发明实施例的另一个目的是提供一种可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述的方法的步骤。

本发明实施例的另一个目的是提供一种电子设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述的方法的步骤。

本发明通过获取车辆TBox在实际过程当中需要遇到的不同测试场景，并根据测试场景设计对应的测试用例及制定预期测试结果以对测试工具进行初始化处理；当检测到TBox需要进行上行测试时，获取测试数据，并将测试数据通过报文的形式以预设工具发送给TBox，后通过TBox对测试数据进行处理后，后发送处理结果给测试工具以确定TBox上行通讯是否正常；当检测到车辆需要进行下行测试时，获取测试指令，并将测试指令发送给车辆远程通讯模块，后通过车辆远程通讯模块发送执行测试指令的测试报文至测试工具，后将测试结果发送至车辆远程通讯模块转发给测试工具以确定TBox下行通讯是否正常，从而能够自动测试TBOX的上行和下行功能，自动判定测试结果生成测试报告；同时可以最大化的模拟车端的故障，保证更多的使用场景被测试，提升了测试效果，解决了现有技术中在进行TBox测试时效果不佳的问题。

另外，本发明至少还可以解决如下的技术问题：

1、实车很多故障状态无法产生，测试项不够广的问题；

2、实车和云端无法自动连续下发命令执行压力测试的问题。

附图说明

图1为本发明一实施例中提出基于虚拟测试工具的TBox功能测试的系统框架图

图2为本发明第一实施例中基于虚拟测试工具的TBox功能测试方法的流程图；

图3为本发明第二实施例中基于虚拟测试工具的TBox功能测试系统的结构框图。

如下具体实施方式将结合上述附图进一步说明本发明。

具体实施方式

为了便于理解本发明，下面将参照相关附图对本发明进行更全面的描述。附图中给出了本发明的若干实施例。但是，本发明可以以许多不同的形式来实现，并不限于本文所描述的实施例。相反地，提供这些实施例的目的是使对本发明的公开内容更加透彻全面。

需要说明的是，当元件被称为“固设于”另一个元件，它可以直接在另一个元件上或者也可以存在居中的元件。当一个元件被认为是“连接”另一个元件，它可以是直接连接到另一个元件或者可能同时存在居中元件。本文所使用的术语“垂直的”、“水平的”、“左”、“右”以及类似的表述只是为了说明的目的。

除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在本发明的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本发明。本文所使用的术语“及/或”包括一个或多个相关的所列类型的任意的和所有的组合。

请参阅图1，所示为本发明一实施例中提出的基于虚拟测试工具的TBox功能测试方法中的TBox测试的系统框架图，包括测试终端与测试终端通讯连接的TBox，其中：

测试终端主要用于集成测试工具，具体的，测试终端包括但不限于PC、平板以及手机等，在本实施例当中，测试工具为JboxTestTool，测试工具分别通过CAN tool以及车载以太网转换器与TBox通讯连接，具体的，测试工具内集成有CAN tool的驱动程序，以调用CANtool提供的API接口控制CAN报文的接收和发送，从而与TBox通讯连接，测试工具依次通过车载以太网转换器、网线与TBox通讯连接，以模拟云端接收TBox的上报数据以及发送远控命令给Tbox，

需要说明的是，JboxTestTool是本发明的主体工具，包含虚拟云端和车端的功能。对于上行业务：例如：数据上报的数据路径是：JboxTestTool–>CAN tool->Tbox->JboxTestTool；对于下行业务：例如：远程控制的数据路径是：JboxTestTool–>Tbox->CANtool->JboxTestTool->CAN tool->Tbox->JboxTestTool；所有业务起始和结束的节点都是JboxTestTool。

需要指出的是，图1示出的结构并不构成对TBox测试的系统框架图的限定，在其它实施例当中，该TBox测试的系统框架图可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。

以下将结合具体实施例和附图来详细说明如何提升TBox测试的效果。

实施例一

请参阅图2，所示为本发明第一实施例中的提出的基于虚拟测试工具的TBox功能测试方法，应用于测试终端，所述测试终端集成有测试工具，所述方法包括步骤S10～S12。

步骤S10，获取车辆TBox在实际过程当中需要遇到的不同测试场景，并根据所述测试场景设计对应的测试用例及制定预期测试结果以对所述测试工具进行初始化处理。

具体的，在一台PC上开发一个测试工具JboxTestTool同时模拟云端和车端(云端与TBOX，车端与TBOX通讯协议都与项目需求保持一致)，提前规划好测试项，模拟尽可能多的测试场景，编写相关测试用例以及每个用例的预期结果。这样在同一个软件里面，就可以自动测试时，测试TBOX主要功能。

步骤S11，当检测到所述TBox需要进行上行测试时，获取测试数据，并将所述测试数据通过报文的形式以预设工具发送给所述TBox，后通过所述TBox对所述测试数据进行处理后，后发送处理结果给所述测试工具以确定所述TBox上行通讯是否正常。

其中，Tbox的上行，主要是车端数据主动上报(例如：车端数据或事件主动周期性上报云端)，JboxTestTool会把每条报文发给Tbox，Tbox按照内部逻辑处理后，就会把数据按照后台通讯协议上报实际后台以及JboxTestTool工具。这样JboxTestTool就可以按照预期结果评定Tbox上报功能是否正常。

具体的，在实际过程当中，当检测到所述TBox需要进行车况数据上报功能测试时，模拟发送各种不同的报文，所述报文中包含车辆的各种不同车况信号；

通过所述TBox接收所述各种不同车况信号并获取对应的车况数据结果，根据所述车况数据结果与所述测试工具中的车况信号对应的预期测试结果是否一致确定所述TBox上行通讯是否正常，在具体实施时，JboxTestTool会按照厂家整车通讯矩阵的定义，模拟发送各种不同的报文，这些报文中每个信号的值会尽量采用穷举的方式保证大部分信号值(很多信号值实车很难产生)都能被测试，同时按照TBOX和后台之间的通讯协议(OTA信号列表)，制定出每种信号对应的不同预期结果。

步骤S12，当检测到所述车辆需要进行下行测试时，获取测试指令，并将所述测试指令发送给车辆远程通讯模块，后通过所述车辆远程通讯模块发送执行所述测试指令的测试报文至所述测试工具，后将测试结果发送至所述车辆远程通讯模块转发给所述测试工具以确定所述TBox下行通讯是否正常。

其中，JboxTestTool会模拟云端下发远控指令，TBox收到指令后，会按照厂家的远控功能规范往CAN总线下发远控CAN报文，JboxTestTool收到远控CAN报文后，会按照预期结果模拟BCM回复信息给TBox，TBox按照OTA信号列表定义上报远控结果给JboxTestTool后台。这样JboxTestTool就可以按照预期结果评定TBOX远控功能是否正常。

具体的，当检测到TBox需要进行远控开车门功能测试时，模拟下发远控开门指令至TBox；控制TBox按照远控功能规范往CAN总线下发远控CAN报文，并在接收到远控CAN报文后，发送开门成功信息给TBox；通过TBox按照OTA信号列表定义上报指令结果信息给测试工具，根据指令结果信息与开门成功信息是否一致确定TBox下行通讯是否正常。

进一步的，在本发明一些可选的实施例当中，所述方法还包括：

连续下发多条远控指令至所述TBox，控制所述TBox按照远控功能规范往CAN总线下发远控CAN报文；

通过所述TBox按照OTA信号列表定义上报的多条指令结果信息给所述测试工具是否正确以对所述TBox远控压力进行测试。

具体的，可以预先设计好有连续多少种远控命令下发给TBOX，对应用例的预期结果分别是什么。这样就可以连续下发多条远控命令以及判断TBOX功能是否正常。

综上，本发明上述实施例当中的基于虚拟测试工具的TBox功能测试方法，通过获取车辆TBox在实际过程当中需要遇到的不同测试场景，并根据测试场景设计对应的测试用例及制定预期测试结果以对测试工具进行初始化处理；当检测到TBox需要进行上行测试时，获取测试数据，并将测试数据通过报文的形式以预设工具发送给TBox，后通过TBox对测试数据进行处理后，后发送处理结果给测试工具以确定TBox上行通讯是否正常；当检测到车辆需要进行下行测试时，获取测试指令，并将测试指令发送给车辆远程通讯模块，后通过车辆远程通讯模块发送执行测试指令的测试报文至测试工具，后将测试结果发送至车辆远程通讯模块转发给测试工具以确定TBox下行通讯是否正常，从而能够自动测试TBOX的上行和下行功能，自动判定测试结果生成测试报告；同时可以最大化的模拟车端的故障，保证更多的使用场景被测试，提升了测试效果，解决了现有技术中在进行TBox测试时效果不佳的问题。

实施例二

请参阅图3，所示为本发明第二实施例中提出的基于虚拟测试工具的TBox功能测试系统，应用于测试终端，所述测试终端集成有测试工具，所述系统包括：

获取模块100，用于获取车辆TBox在实际过程当中需要遇到的不同测试场景，并根据所述测试场景设计对应的测试用例及制定预期测试结果以对所述测试工具进行初始化处理；

上行检测模块200，用于当检测到所述TBox需要进行上行测试时，获取测试数据，并将所述测试数据通过报文的形式以预设工具发送给所述TBox，后通过所述TBox对所述测试数据进行处理后，后发送处理结果给所述测试工具以确定所述TBox上行通讯是否正常；

下行检测模块300，用于当检测到所述车辆需要进行下行测试时，获取测试指令，并将所述测试指令发送给车辆远程通讯模块，后通过所述车辆远程通讯模块发送执行所述测试指令的测试报文至所述测试工具，后将测试结果发送至所述车辆远程通讯模块转发给所述测试工具以确定所述TBox下行通讯是否正常。

进一步的，上述基于虚拟测试工具的TBox功能测试系统，其中，所述上行检测模块具体用于：

当检测到所述TBox需要进行车况数据上报功能测试时，模拟发送各种不同的报文，所述报文中包含车辆的各种不同车况信号；

通过所述TBox接收所述各种不同车况信号并获取对应的车况数据结果，根据所述车况数据结果与所述测试工具中的车况信号对应的预期测试结果是否一致确定所述TBox上行通讯是否正常。

进一步的，上述基于虚拟测试工具的TBox功能测试系统，其中，所述下行检测模块具体用于：

当检测到所述TBox需要进行远控开车门功能测试时，模拟下发远控开门指令至所述TBox；

控制所述TBox按照远控功能规范往CAN总线下发远控CAN报文，并在接收到所述远控CAN报文后，发送开门成功信息给所述TBox；

通过所述TBox按照OTA信号列表定义上报指令结果信息给所述测试工具，根据所述指令结果信息与所述开门成功信息是否一致确定所述TBox下行通讯是否正常。

进一步的，上述基于虚拟测试工具的TBox功能测试系统，其中，所述测试工具分别通过CAN tool以及车载以太网转换器与所述TBox通讯连接。

进一步的，上述基于虚拟测试工具的TBox功能测试系统，其中，所述测试工具内集成有CAN tool的驱动程序，以调用所述CAN tool提供的API接口控制CAN报文的接收和发送，从而与所述TBox通讯连接。

进一步的，上述基于虚拟测试工具的TBox功能测试系统，其中，所述测试工具依次通过车载以太网转换器、网线与所述TBox通讯连接，以模拟云端接收所述TBox的上报数据以及发送远控命令给所述TBox。

进一步的，上述基于虚拟测试工具的TBox功能测试系统，其中，其特征在于，所述系统还包括：

压力测试模块，用于连续下发多条远控指令至所述TBox，控制所述TBox按照远控功能规范往CAN总线下发远控CAN报文；

通过所述TBox按照OTA信号列表定义上报的多条指令结果信息给所述测试工具是否正确以对所述TBox远控压力进行测试。

上述各模块被执行时所实现的功能或操作步骤与上述方法实施例大体相同，在此不再赘述。

实施例三

本发明另一方面还提供一种可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述实施例一中任意一个所述的方法的步骤。

实施例四

本发明另一方面还提供一种电子设备，所述电子设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述实施例一中任意一个所述的方法的步骤。

以上各个实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

本领域技术人员可以理解，在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何存储介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，“存储介质”可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。

存储介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，存储介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或它们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。