CN111624984B - 一种车辆测试方法及装置 - Google Patents

Abstract

本发明实施例提供一种车辆测试方法及装置，包括：获取控制器局域网中传输的至少一个反馈数据；确定所述至少一个反馈数据的类型；根据所述类型确定所述至少一个反馈数据对应的测试用例，所述测试用例包含测试所述至少一个反馈数据是否正常的测试逻辑；根据所述测试用例对所述至少一个反馈数据进行测试。当测试人员需要对车辆进行测试时，测试人员就无需再通过人工的方式对数据进行逐条分析，即便是不具备数据分析能力的测试人员也能够对车辆进行测试，省去了对测试人员进行培训的过程，减少车辆测试过程中人力和物力的消耗，提高车辆测试的准确性。

Description

一种车辆测试方法及装置

技术领域

本发明涉及汽车技术领域，尤其涉及一种车辆测试方法及装置。

背景技术

现有的车辆测试方法，主要是获取控制器局域网(Controller Area Network，CAN)中传输的数据，然后通过人工对数据进行逐条分析的方式，确定车辆的各项功能是否正常，进而达到对车辆测试的目的。

然而，通过人工对数据进行分析，确定车辆的各项功能是否正常，对测试人员的要求相对较高，即在进行车辆测试前，需要对测试人员进行相关培训，直到测试人员具备了数据分析能力后，才能够对数据进行分析，进而确定车辆的各项功能是否正常。可见，采用人工分析的方式对车辆进行测试，不仅消耗大量的人力物力，还存在人为分析错误而导致测试结果出错的风险，降低车辆测试的准确性。

发明内容

鉴于上述问题，本发明实施例的目的是提供一种车辆测试方法及装置，旨在减少车辆测试过程中人力和物力的消耗，以及提高车辆测试的准确性。

为解决上述技术问题，本发明实施例提供如下技术方案：

第一方面，本发明实施例提供一种车辆测试方法，包括：获取控制器局域网中传输的至少一个反馈数据；确定所述至少一个反馈数据的类型；根据所述类型确定所述至少一个反馈数据对应的测试用例，所述测试用例包含测试所述至少一个反馈数据是否正常的测试逻辑；根据所述测试用例对所述至少一个反馈数据进行测试。

在本发明其它实施例中，所述根据所述测试用例对所述至少一个反馈数据进行测试，包括：判断所述至少一个反馈数据是否符合所述测试用例；当所述至少一个反馈数据符合所述测试用例时，确定所述车辆通过第一测试；当所述至少一个反馈数据不符合所述测试用例时，确定所述车辆未通过第一测试。

在本发明其它实施例中，所述至少一个反馈数据包括第一反馈数据；所述判断所述至少一个反馈数据是否符合所述测试用例，包括：判断所述第一反馈数据是否符合所述测试用例；当所述第一反馈数据符合所述测试用例时，获取所述控制器局域网中传输的第二反馈数据；判断所述第二反馈数据是否符合所述测试用例，所述第二反馈数据与所述第一反馈数据的类型相同；当所述第一反馈数据不符合所述测试用例时，确定所述至少一个反馈数据不符合所述测试用例。

在本发明其它实施例中，所述测试包括充电测试，所述第一反馈数据用于指示供电设备的连接状态，所述第二反馈数据用于指示所述供电设备的充电状态，所述测试用例包括：检测所述供电设备的连接状态；当所述连接状态为已连接时，检测所述供电设备的充电状态；当所述充电状态为正在充电时，结束测试。

在本发明其它实施例中，所述测试包括电源状态测试，所述第一反馈数据用于指示打开车门后的电源模式，所述第二反馈数据用于指示踩制动后的电源模式，所述测试用例包括：检测打开车门后的电源模式；当打开车门后的电源模式为自适应巡航控制模式时，检测踩制动后的电源模式；当踩制动后的电源模式为向所有电器供电模式时，结束测试。

在本发明其它实施例中，所述测试包括档位状态测试，所述至少一个反馈数据还包括第三反馈数据，所述第三反馈数据与所述第一反馈数据的类型相同，所述第一反馈数据用于指示切换为前进档后的档位状态，所述第二反馈数据用于指示切换为倒车档后的档位状态，所述第三反馈数据用于指示切换为停车档后的档位状态，所述测试用例包括：检测切换为前进档后的档为状态；当切换为前进档后的档位状态为前进时，检测切换为倒车档后的档位状态；当切换为倒车档后的档位状态为倒车时，检测切换为停车档后的档位状态；当切换为停车档后的档位状态为停车时，结束测试。

在本发明其它实施例中，在判断所述第一反馈数据是否符合所述测试用例之前，所述方法还包括：获取第一操作信息，所述第一操作信息用于触发所述车辆生成所述第一反馈数据；当所述第一反馈数据符合所述测试用例时，获取第二操作信息，所述第二操作信息用于触发所述车辆生成所述第二反馈数据。

在本发明其它实施例中，在确定所述车辆通过所述第一测试之后，所述方法还包括：获取所述控制器局域网中传输的与第二测试相关的反馈数据；确定与所述第二测试相关的反馈数据的类型；根据与所述第二测试相关的反馈数据的类型确定与所述第二测试相关的反馈数据对应的测试用例，与所述第二测试相关的反馈数据对应的测试用例包含测试与所述第二测试相关的反馈数据是否正常的测试逻辑；根据与所述第二测试相关的反馈数据对应的测试用例对与所述第二测试相关的反馈数据进行测试。

在本发明其它实施例中，Python脚本中包含所述测试用例；所述根据所述测试用例对所述至少一个反馈数据进行测试，包括：通过Python脚本对所述至少一个反馈数据进行测试。

第二方面，本发明实施例提供一种车辆测试装置，包括：获取模块，用于获取控制器局域网中传输的至少一个反馈数据；第一确定模块，用于确定所述至少一个反馈数据的类型；第二确定模块，用于根据所述类型确定所述至少一个反馈数据对应的测试用例，所述测试用例包含测试所述至少一个反馈数据是否正常的测试逻辑；测试模块，用于根据所述测试用例对所述至少一个反馈数据进行测试。

在本发明其它实施例中，所述测试模块，具体用于判断所述至少一个反馈数据是否符合所述测试用例；当所述至少一个反馈数据符合所述测试用例时，确定所述车辆通过第一测试；当所述至少一个反馈数据不符合所述测试用例时，确定所述车辆未通过第一测试。

在本发明其它实施例中，所述至少一个反馈数据包括第一反馈数据；所述测试模块，具体用于判断所述第一反馈数据是否符合所述测试用例；当所述第一反馈数据符合所述测试用例时，获取所述控制器局域网中传输的第二反馈数据；判断所述第二反馈数据是否符合所述测试用例，所述第二反馈数据与所述第一反馈数据的类型相同；当所述第一反馈数据不符合所述测试用例时，确定所述至少一个反馈数据不符合所述测试用例。

在本发明其它实施例中，所述测试包括充电测试，所述第一反馈数据用于指示供电设备的连接状态，所述第二反馈数据用于指示所述供电设备的充电状态，所述测试用例包括：检测所述供电设备的连接状态；当所述连接状态为已连接时，检测所述供电设备的充电状态；当所述充电状态为正在充电时，结束测试。

在本发明其它实施例中，所述测试包括电源状态测试，所述第一反馈数据用于指示打开车门后的电源模式，所述第二反馈数据用于指示踩制动后的电源模式，所述测试用例包括：检测打开车门后的电源模式；当打开车门后的电源模式为自适应巡航控制模式时，检测踩制动后的电源模式；当踩制动后的电源模式为向所有电器供电模式时，结束测试。

在本发明其它实施例中，所述测试包括档位状态测试，所述至少一个反馈数据还包括第三反馈数据，所述第三反馈数据与所述第一反馈数据的类型相同，所述第一反馈数据用于指示切换为前进档后的档位状态，所述第二反馈数据用于指示切换为倒车档后的档位状态，所述第三反馈数据用于指示切换为停车档后的档位状态，所述测试用例包括：检测切换为前进档后的档为状态；当切换为前进档后的档位状态为前进时，检测切换为倒车档后的档位状态；当切换为倒车档后的档位状态为倒车时，检测切换为停车档后的档位状态；当切换为停车档后的档位状态为停车时，结束测试。

在本发明其它实施例中，所述装置还包括：提示模块，用于获取第一操作信息，所述第一操作信息用于触发所述车辆生成所述第一反馈数据；当所述第一反馈数据符合所述测试用例时，获取第二操作信息，所述第二操作信息用于触发所述车辆生成所述第二反馈数据。

在本发明其它实施例中，所述获取模块，还用于获取所述控制器局域网中传输的与第二测试相关的反馈数据；所述第一确定模块，还用于确定与所述第二测试相关的反馈数据的类型；所述第二确定模块，还用于根据与所述第二测试相关的反馈数据的类型确定与所述第二测试相关的反馈数据对应的测试用例，与所述第二测试相关的反馈数据对应的测试用例包含测试与所述第二测试相关的反馈数据是否正常的测试逻辑；所述测试模块，还用于根据与所述第二测试相关的反馈数据对应的测试用例对与所述第二测试相关的反馈数据进行测试。

在本发明其它实施例中，Python脚本中包含所述测试用例；所述测试模块，具体用于通过Python脚本对所述至少一个反馈数据进行测试。

第三方面，本发明实施例提供一种车辆测试设备，所述设备包括：至少一个处理器；以及与所述处理器连接的至少一个存储器、总线；其中，所述处理器、存储器通过所述总线完成相互间的通信；所述处理器用于调用所述存储器中的程序指令，以执行上述第一方面中的方法。

第四方面，本发明实施例提供一种车辆测试系统，所述系统包括：CAN数据获取设备和第三方面的车辆测试设备；第三方面的车辆测试设备与所述CAN数据获取设备连接，利用所述CAN数据获取设备通过CAN获取至少一个反馈数据。

第五方面，本发明实施例提供一种计算机可读存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行上述第一方面中的方法。

本发明实施例提供的车辆测试方法及装置，首先，获取CAN中传输的至少一个反馈数据；然后，确定至少一个反馈数据的类型；接着，根据至少一个反馈数据的类型确定至少一个反馈数据对应的测试用例，测试用例包含测试至少一个反馈数据是否正常的测试逻辑；最后，根据测试用例对至少一个反馈数据进行测试。可见，通过测试用例对从CAN中获取的反馈数据进行测试，进而确定反馈数据相应的车辆功能是否正常，当测试人员需要对车辆进行测试时，测试人员就无需再通过人工的方式对数据进行逐条分析。本发明实施例提供的车辆测试方法能够通过测试用例自动对车辆进行测试，即便是不具备数据分析能力的测试人员也能够对车辆进行测试，省去了对测试人员进行培训的过程，减少车辆测试过程中人力和物力的消耗。并且，通过测试用例对反馈数据进行测试，相对于通过人工进行数据分析测试的方式，能够避免因人为分析错误而导致测试结果出错的问题，提高车辆测试的准确性。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明实施例中车辆测试中进行交互的示意图；

图2为本发明实施例中车辆测试方法的流程示意图一；

图3为本发明实施例中车辆测试方法的流程示意图二；

图4为本发明实施例中车辆测试方法的流程示意图三；

图5为本发明实施例中车辆测试装置的结构示意图；

图6为本发明实施例中车辆测试设备的结构示意图；

图7为本发明实施例中车辆测试系统的结构示意图。

具体实施方式

下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明，并且能够将本发明的范围完整的传达给本领域的技术人员。

图1为本发明实施例中车辆测试中进行交互的示意图，参见图1所示，车辆101为待测试的车辆，CAN数据获取设备102能够从车辆101的CAN中获取指示车辆101状态的反馈数据，并将获取的反馈数据发送给车辆测试设备103，车辆测试设备103能够对接收到的反馈数据进行分析测试，进而确定车辆101的某一项或某几项功能是否正常。在具体实施过程中，测试人员104需要对车辆101的某一项或某几项功能进行测试，进而需要对车辆101采取测试相应的操作，在测试人员104对车辆101进行了操作后，车辆101的CAN中就会产生操作相应的反馈数据，CAN数据获取设备102就能够获取该反馈数据，进而将该反馈数据发送给车辆测试设备103，车辆测试设备103能够对接收到的反馈数据进行分析测试，确定车辆101的相应功能是否正常。

这里需要说明的是：待测试的车辆可以是实际的车辆，也可以是具有需要测试的车辆控制逻辑的设备。当待测试的车辆为具有车辆控制逻辑的设备时，对待测试车辆的操作就是向具有车辆控制逻辑的设备发送一个执行相应动作的信号。

在实际应用中，CAN数据获取设备可以是安装有总线开发环境(Controller AreaNetwork Open Environment，CANoe)的设备，也可以是安装有总线分析工具(ControllerArea Network Alyzer，CANalyzer)的设备。这些设备是各大主机厂商均有的设备，便于获得，通用性较好。当然，CAN数据获取设备还可以是其它能够从CAN中获取反馈数据的设备。对于CAN数据获取设备的具体类型，此处不做限定。

下面对本发明实施例中车辆测试的方法进行详细说明。

图2为本发明实施例中车辆测试方法的流程示意图一，参见图2所示，该方法可以包括：

S201：获取CAN中传输的至少一个反馈数据。

其中，至少一个反馈数据为CAN中指示车辆的状态的数据。这里的车辆为待测试的车辆。当测试人员对车辆进行操作时，车辆就会对测试人员的操作作出相应的反应，即CAN中就会产生操作相应的反馈数据。而如果车辆存在问题，在测试人员对车辆进行操作后，CAN中就会产生错误的反馈数据，甚至可能不会产生反馈数据。因此，获取CAN中的反馈数据，并对其进行分析，就能够确定操作对应的车辆功能是否正常。

在具体实施过程中，车辆测试设备可以通过安装有的CANoe或CANalyzer的CAN数据获取设备获取CAN中的反馈数据。具体的，车辆测试设备通过调用CANoe或CANalyzer的应用程序接口(Application Programming Interface，API)，使CANoe或CANalyzer自动开始记录CAN中的反馈数据，并进行存储，在结束反馈数据的存储后，将存储的反馈数据通过API回传给车辆测试设备。这样，车辆测试设备就能够通过反馈数据判断车辆的某一项或某几项功能是否正常。

这里需要说明的是：在测试车辆的某项功能中，有时并不是仅通过一个反馈数据就能够确定车辆的该项功能是否正常，而是需要通过先后产生的多个反馈数据确定车辆的该项功能是否正常。以及，在连续测试车辆的某几项功能中，每测试一项功能，就需要获取一个或多个反馈数据。因此，有时需要获取多个反馈数据。也就是说，需要获取第一反馈数据、第二反馈数据、第三反馈数据等。获取的反馈数据的数量，需要根据具体的测试逻辑确定。

S202：确定至少一个反馈数据的类型。

在CAN中，存在有多种类型的反馈数据，不同类型的反馈数据能够表征车辆对于不同操作的反应。也就是说，通过对一种类型的反馈数据进行分析，能够得到该种类型的反馈数据对应的车辆功能是否正常。

示例性的，对于电能供给类的反馈数据，通过对该类的反馈数据进行分析，能够确定车辆的充电功能是否正常。对于电源模式类的反馈数据，通过对该类反馈数据进行分析，能够确定车辆的电源切换功能是否正常。对于档位模式类的反馈数据，通过对该类反馈数据进行分析，能够确定车辆的档位切换功能是否正常。

在具体实施过程中，在获取到至少一个反馈数据后，如果该反馈数据中包括类型信息，那么可以直接基于该反馈数据的类型信息确定该反馈数据的类型。而如果该反馈数据中没有包括类型信息，那么就可以对该反馈数据的内容进行识别，进而根据识别结果确定该反馈数据的类型。

S203：根据至少一个反馈数据的类型确定至少一个反馈数据对应的测试用例。

其中，测试用例包含测试至少一个反馈数据是否正常的测试逻辑。

在具体实施过程中，一个测试用例可以对一种类型的反馈数据进行测试，即测试该种类型的反馈数据是否符合测试逻辑。对于存在多种类型的反馈数据的情况，可以针对每一种类型的反馈数据设置一个测试用例。这样，就会有多个测试用例。而这些多个测试用例可以是预先编辑好的，并且在每个测试用例上都预先标记有类型标签。这样，在确定出反馈数据的类型后，就能够根据测试用例上标记的类型标签，找到该反馈数据对应的测试用例，进而采用该测试用例对该反馈数据进行测试。

S204：根据测试用例对至少一个反馈数据进行测试。

接下来，以测试车辆的充电功能是否正常的实例对S201-S204举例说明。

假设测试人员需要测试车辆的充电功能是否正常。首先，测试人员将充电枪插入车辆的充电口。如果车辆与充电枪连接成功，那么CAN中就会产生指示车辆与充电枪已连接的反馈数据；而如果车辆与充电枪连接失败，那么CAN中就会产生车辆与充电枪连接失败或未连接的反馈数据，或者不会产生任何与充电相关的反馈数据。然后，车辆测试设备通过CANoe或CANalyzer的API获取CAN中的反馈数据。接着，车辆测试设备确定出该反馈数据的类型为电能供给类的数据，进而找到电能供给类的反馈数据对应的测试用例。最后，车辆测试设备通过该测试用例对获取的反馈数据进行测试。如果获取的反馈数据的类型为电能供给类的数据，但该反馈数据指示车辆未与充电枪连接，或者没有获取到反馈数据，说明车辆未与充电枪连接成功，要么是测试人员充电枪没有插好，测试人员可以拔出充电枪重新插入，要么就是车辆与充电枪的连接出现问题；如果获取的反馈数据的类型为电能供给类的数据，且该反馈数据指示车辆与充电枪连接，说明车辆能够与充电枪连接，就可以继续后面的测试。继续获取CAN中的反馈数据，如果没有获取到反馈数据，或者获取到的反馈数据并没有指示充电枪正在为车辆充电，说明车辆不能正常充电，要么是充电枪没有电，测试人员可以更换充电枪，要么就是车辆的充电功能出现问题；如果获取到的反馈数据指示充电枪正在为车辆充电，说明车辆的充电功能正常。

由上述内容可知，本发明实施例提供的车辆测试方法，首先，获取CAN中传输的至少一个反馈数据；然后，确定至少一个反馈数据的类型；接着，根据至少一个反馈数据的类型确定至少一个反馈数据对应的测试用例，测试用例包含测试至少一个反馈数据是否正常的测试逻辑；最后，根据测试用例对至少一个反馈数据进行测试。可见，通过测试用例对从CAN中获取的反馈数据进行测试，进而确定反馈数据相应的车辆功能是否正常，当测试人员需要对车辆进行测试时，测试人员就无需再通过人工的方式对数据进行逐条分析。本发明实施例提供的车辆测试方法能够通过测试用例自动对车辆进行测试，即便是不具备数据分析能力的测试人员也能够对车辆进行测试，省去了对测试人员进行培训的过程，减少车辆测试过程中人力和物力的消耗。并且，通过测试用例对反馈数据进行测试，相对于通过人工进行数据分析测试的方式，能够避免因人为分析错误而导致测试结果出错的问题，提高车辆测试的准确性。

进一步地，作为图2所示方法的细化和扩展，本发明实施例还提供了一种车辆测试方法。图3为本发明实施例中车辆测试方法的流程示意图二，参见图3所示，该方法可以包括：

S301：获取第一操作信息。

其中，第一操作信息用于触发车辆生成第一反馈数据。由于车辆并不会凭空生成反馈数据，而是在车辆的状态发生变化的情况下，车辆才会生成反馈数据。这里的车辆的状态变化可以是由人为引起的。并且在开始第一测试时，是需要测试人员先进行一定的操作的。因此，在开始对车辆进行第一测试时，需要先获取第一操作信息。

而为了提醒测试人员尽快执行第一操作，进而能够尽快获得第一反馈数据，以及使无测试经验的测试人员能够开始测试，可以通过信息提醒的方式提示测试人员执行第一操作。具体来说，可以将第一操作信息通过语音进行提示，也可以将第一操作信息通过文字进行提示。当采用文字进行提示时，可以采用超文本标记语言(Hyper Text MarkupLanguage，HTML)显示第一操作信息，以提示测试人员执行第一操作。当然，也可以采用其它语言对测试人员进行执行第一操作的提示，此处不做限定。

S302：获取CAN中传输的第一反馈数据。

本步骤的实现方式与图2中S201的实现方式相同，故不再赘述。

这里需要说明的是：在测试人员执行完第一操作后，可以等待一段时间后，再获取第一反馈数据。因为在测试人员执行完操作后，车辆有可能并不会立即生成反馈数据，车辆会需要一个反应时间，因此，为了避免车辆还没有来得及产生反馈数据，测试过程就开始获取反馈数据，导致误判为无法获得反馈数据的情况，确保能够获得反馈数据，进而提高测试的准确性，在确定测试人员执行完第一操作后，等待一段时间后，再获取第一反馈数据。

在实际应用中，上述等待的一段时间可以是0.5s、5s等。具体等待的时间可以根据具体的测试内容而定。

S303：确定第一反馈数据的类型。

本步骤的实现方式与图2中S202的实现方式相同，故不再赘述。

S304：根据第一反馈数据的类型确定第一反馈数据对应的测试用例。

本步骤的实现方式与图2中S203的实现方式相同，故不再赘述。

S305：判断第一反馈数据是否符合测试用例。若是，则执行S306-S308，执行S309；若否，则执行S310。

需要说明的是：若在一项测试中，如果只需判断一个反馈数据，那么，在判断出该反馈数据符合测试用例后，就直接确定车辆通过该测试，即执行S309。而如果需要依次判断多个反馈数据，那么，在判断出每个反馈数据都符合测试用例后，才确定车辆通过该测试，即执行S306-S309。

在实际应用中，可以通过测试脚本判断第一反馈数据是否符合测试用例。具体来说，不同的测试项目对应有不同的判断标准，相应就有不同的测试用例，将相应的测试用例通过基础组件函数编辑在测试脚本中，就能够形成相应的测试脚本。将反馈数据输入到测试脚本中，测试脚本就能够自行判断反馈数据是否符合测试用例，进而确定车辆的该项测试是否通过。

对于测试脚本的具体类型，可以是基于C/C#/JAVA等语言编辑的脚本，也可以是基于Python语言编辑的脚本，此处不做具体限定。然而，相比于采用C/C#/JAVA等语言编辑的脚本，由于现今大部分软件接口都支持Python语言，因此，采用Python脚本作为测试脚本在进行编辑时更加方便。并且，在CANoe中进行编辑时也可以使用通讯访问编程语言(Communication Access Programming Language，CAPL)，提高了测试中程序编辑的便捷性。

在获取到第一反馈数据以及第一反馈数据对应的测试用例后，需要判断第一反馈数据是否符合测试用例，即判断第一反馈数据指示的内容是否符合测试用例的逻辑。若第一反馈数据指示的内容符合测试用例的逻辑，则确定第一反馈数据符合测试用例；若第一反馈数据指示的内容不符合测试用例的逻辑，则确定第一反馈数据不符合测试用例。

示例性的，假设第一反馈数据指示充电枪与车辆连接，测试用例为充电枪与车辆连接。可见，第一反馈数据指示的内容符合测试用例的逻辑。那么，就认为第一反馈数据符合测试用例，进而确定充电枪与车辆的连接功能正常。相反的，假设第一反馈数据指示充电枪与车辆未连接，测试用例为充电枪与车辆连接。可见，第一反馈数据指示的内容不符合测试用例的逻辑。那么，就认为第一反馈数据不符合测试用例，进而确定充电枪与车辆的连接功能异常。

当然，除了可以通过S301-S305中的反馈数据的类型确定对应的测试用例之外，还可以根据测试人员的操作确定对应的测试用例，进而对反馈数据进行判断，以对车辆进行测试。由于不同的测试用例可以编辑在不同的测试脚本中，当测试人员点击运行某个测试脚本时，车辆测试设备就可以接收到测试人员点击运行的脚本的信息，进而采用该脚本中的测试用例对反馈数据进行测试。

S306：获取第二操作信息。

其中，第二操作信息用于触发车辆生成第二反馈数据。在一项存在多个测试步骤的测试中，并不是只需测试人员在测试开始时进行一次操作即可，可能在某一个测试步骤开始前，还需要测试人员再进行一次相应的操作。也就是说，在判断第二反馈数据是否符合测试用例前，需要测试人员先执行第二操作，只有测试人员对车辆执行第二操作后，车辆才会生成第二反馈数据，进而才能根据第二反馈数据继续进行测试。

同样的，也可以通过HTML显示第二操作信息，以提示测试人员执行第二操作。这样，测试人员就能够清楚地知道在何时执行第二操作，以及具体如何操作，避免由于测试人员没有来得及进行第二操作而耽误后续步骤的测试，能够提高测试效率。以及，还可以通过HTML显示第一反馈数据的判断结果。这样，能够使测试人员清楚地了解每一步的判断结果。如果最终测试未通过，测试人员通过每一步的判断结果，就能够立刻了解测试未通过的具体原因，节省寻找问题点的时间。

S307：获取CAN中传输的第二反馈数据。

这里的第二反馈数据与前面获取的第一反馈数据都是同一项测试中先后生成的两个不同的反馈数据。第一反馈数据基于第一操作先生成，第二反馈数据基于第二操作后生成。

同样的，在获取第二反馈数据前，也需要等待一段时间，给车辆预留对第二操作进行反应的时间，确保能够正常获取到第二反馈数据。

S308：判断第二反馈数据是否符合测试用例。若是，则执行S309；若否，则执行S310。

其中，第二反馈数据与第一反馈数据的类型相同。也就是说，第二反馈数据与第一反馈数据属于同一项测试中的判断对象。

当判断出第一反馈数据符合测试用例时，说明该项测试中的第一步测试已通过，那么就继续判断第二步测试中的第二反馈数据是否符合测试用例，直到该项测试中所有的测试步骤都通过测试时，结束测试，通过HTML显示该项测试通过。这样，在某项测试中存在多个测试步骤时，就能够自动连续地进行测试，无需人工手动进入下一步测试，提高测试效率。

S309：确定车辆通过第一测试。

当然，如果一项测试中需要对三个或三个以上的反馈数据进行判断，那么，在判断出第二反馈数据符合测试用例后，还需要继续判断第三反馈数据是否符合测试用例，这里的第三反馈数据与第一反馈数据的类型相同，直到判断出所有的反馈数据都符合测试用例，才确定该项测试通过。

S310：确定车辆未通过第一测试。

当按照顺序判断出某一个反馈数据不符合测试用例时，说明该项测试中的某一步测试没有通过，即便后续进行的测试步骤都通过测试，但是由于中间某步测试没有通过，最终该项测试也是没有通过。有鉴于此，为了节省测试步骤，提高测试效率，当判断出某一个反馈数据不符合测试用例时，就不再继续判断该反馈数据后的反馈数据是否符合测试用例，直接确定该项测试没有通过，进而结束该项测试。

接下来，以三项具体的测试对本发明实施例中的车辆测试方法进行说明。

第一项测试：充电测试。

在这里，第一反馈数据用于指示供电设备的连接状态，第二反馈数据用于指示供电设备的充电状态。测试用例包括：检测供电设备的连接状态；当连接状态为已连接时，检测供电设备的充电状态；当充电状态为正在充电时，结束测试。这里的供电设备可以是充电枪、充电桩等。下面以充电枪为例。

表1列出了充电测试中的各步骤：

序号	步骤	判断条件
			1	插入充电枪
2	Wait 0.5s	GunSts＝Connect
			3	Wait 5s	ChargingSts＝Charging
4	End

首先，当测试脚本运行时，调用HTML显示“插入充电枪”。在这里，测试人员通过点击测试脚本，使得测试脚本运行。这样，测试人员在开始进行测试后，就能够知道何时需要插入充电枪，可以随即插入充电枪，便于测试脚本能够尽快继续测试，提高测试效率。

然后，测试脚本等待0.5s后，获取CAN中指示充电枪连接状态的反馈数据，判断该反馈数据是否指示充电枪与车辆已连接，若判断结果为否，则调用HTML显示“未通过测试”，结束本次测试，若判断结果为是，则调用HTML显示“通过测试”，自动进入下一步。这样，在中间的测试步骤测试出问题时，就结束本次测试，能够提高测试效率。因为当中间的测试步骤测试出问题时，后续即使都测试通过了，最终的测试结果也是未通过。

接着，测试脚本等待5s后，继续获取CAN中指示充电枪充电状态的反馈数据，判断该反馈数据是否指示充电枪正在为车辆充电，若判断结果为否，则调用HTML显示“未通过测试”，结束本次测试，若判断结果为是，则调用HTML显示“通过测试”，自动进入下一步。

最后，当以上测试步骤均为通过时，测试脚本读取“End”，并调用HTML显示“End”。

第二项测试：电源状态测试。

在这里，第一反馈数据用于指示打开车门后的电源模式，第二反馈数据用于指示踩制动后的电源模式。测试用例包括：检测打开车门后的电源模式；当打开车门后的电源模式为自适应巡航控制模式时，检测踩制动后的电源模式；当踩制动后的电源模式为向所有电器供电模式时，结束测试。

其中，自适应巡航控制模式即ACC模式，向车内所有电器(包括发动机)供电模式即ON模式。

表2列出了电源状态测试中的各步骤：

序号	步骤	判断条件
			1	打开车门
2	Wait 0.5s	Power Mode＝ACC
			3	踩下制动踏板
4	Wait 0.5s	Power Mode＝ON
			5	End

首先，当测试脚本运行时，调用HTML显示“打开车门”。在这里，测试人员通过点击测试脚本，使得测试脚本运行。这样，测试人员在开始进行测试后，就能够知道何时需要打开车门，可以随即打开车门，便于测试脚本能够尽快继续测试，提高测试效率。

然后，测试脚本等待0.5s后，获取CAN中指示打开车门后的电源模式的反馈数据，判断该反馈数据是否用来指示ACC模式，若判断结果为否，则调用HTML显示“未通过测试”，结束本次测试，若判断结果为是，则调用HTML显示“踩下制动踏板”，自动进入下一步。这样，在中间的测试步骤测试出问题时，就结束本次测试，能够提高测试效率。因为当中间的测试步骤测试出问题时，后续即使都测试通过了，最终的测试结果也是未通过。

接着，测试脚本等待0.5s后，获取CAN中指示踩制动后的电源模式的反馈数据，判断该反馈数据是否用来指示ON模式，若判断结果为否，则调用HTML显示“未通过测试”，结束本次测试，若判断结果为是，则调用HTML显示“通过测试”，自动进入下一步。

最后，当以上测试步骤均为通过时，测试脚本读取“End”，并调用HTML显示“End”。

第三项测试：档位状态测试。

在这里，第一反馈数据用于指示切换为前进档后的档位状态，第二反馈数据用于指示切换为倒车档后的档位状态，第三反馈数据用于指示切换为停车档后的档位状态。测试用例包括：检测切换为前进档后的档为状态；当切换为前进档后的档位状态为前进时，检测切换为倒车档后的档位状态；当切换为倒车档后的档位状态为倒车时，检测切换为停车档后的档位状态；当切换为停车档后的档位状态为停车时，结束测试。

其中，停车档即P档，前进档即D档，倒车档即R档。

表3列出了档位状态测试中的各步骤：

首先，当测试脚本运行时，调用HTML显示“Ready，踩制动，P档，按住档把侧边按钮，向后拨动到底”。在这里，测试人员通过点击测试脚本，使得测试脚本运行。这样，测试人员在开始进行测试后，就能够知道何时需要从P档切换至D档，可以随即切换至D档，便于测试脚本能够尽快继续测试，提高测试效率。并且直接以具体的操作步骤进行提示，能够使无经验的测试人员也能够进行档位状态测试。

然后，测试脚本等待0.5s后，获取CAN中切换至D档后的反馈数据，判断该反馈数据指示的档位状态是否为前进，若判断结果为否，则调用HTML显示“未通过测试”，结束本次测试，若判断结果为是，则调用HTML显示“保持制动，档把向前拨动到底”，自动进入下一步。这样，在中间的测试步骤测试出问题时，就结束本次测试，能够提高测试效率。因为当中间的测试步骤测试出问题时，后续即使都测试通过了，最终的测试结果也是未通过。

接着，测试脚本等待0.5s后，获取CAN中切换至R档后的反馈数据，判断该反馈数据指示的档位状态是否为倒车，若判断结果为否，则调用HTML显示“未通过测试”，结束本次测试，若判断结果为是，则调用HTML显示“保持制动，按档把后方按钮”，自动进入下一步。

再接着，测试脚本等待0.5s后，获取CAN中切换至P档后的反馈数据，判断该反馈数据指示的档位状态是否为倒车，若判断结果为否，则调用HTML显示“未通过测试”，结束本次测试，若判断结果为是，则调用HTML显示“通过测试”，自动进入下一步。

最后，当以上测试步骤均为通过时，测试脚本读取“End”，并调用HTML显示“End”。

至此，针对某一项测试的具体测试过程就介绍完了。

接下来，还需要针对多项测试进行说明。

如果在同一时间内对于同一车辆需要进行多项测试，即既需要进行第一测试，又需要进行第二测试。除了针对每一项测试都建立一个测试脚本，当测试人员需要进行哪项测试时，就点击运行相应的测试脚本，使该测试脚本能够自动测试对应的测试项之外，为了节省人工操作的步骤，还可以将多项测试集中在同一个测试脚本中。测试人员只需点击运行一次测试脚本，就能够直接进行多项测试，提高测试效率。

图4为本发明实施例中车辆测试方法的流程示意图三，参见图4所示，该方法可以包括：

S401：获取CAN中传输的第一类反馈数据。

这里的第一类反馈数据就是第一测试中需要判断的至少一个反馈数据。

S402：确定第一类反馈数据的第一类型。

S403：根据第一类型确定第一类反馈数据对应的第一测试用例。

S404：判断第一类反馈数据是否符合第一测试用例。若是，则执行S405；若否，则执行S406。

S405：确定车辆通过第一测试。

S406：确定车辆未通过第一测试。

S407：获取CAN中传输的第二类反馈数据。

这里的第二类反馈数据与第一类反馈数据类似，只是在类型上不同。并且，第二类反馈数据与第二测试相关，是第二测试中需要判断的反馈数据。

S408：确定第二类反馈数据的第二类型。

S409：根据第二类型确定第二类反馈数据对应的第二测试用例。

S410：判断第二类反馈数据是否符合第二测试用例。若是，则执行S411；若否，则执行S412。

S411：确定车辆通过第二测试。

S412：确定车辆未通过第二测试。

这里需要说明的是：无论上一项测试的结果如何，在上一项测试结束后，下一项测试仍然会继续进行。即无论第一测试是否通过，在第一测试结束后，第二测试都会开始进行。这样，在同一时间需要进行多项测试时，就能够直接得到哪些测试项通过，哪些测试项未通过，进而针对所有未通过的测试项对车辆进行一次性维修，避免车辆多次返修，提高测试效率。

至于第二测试的具体测试方式，与第一测试的具体测试方式相同，具体可以参见对第一测试中具体测试过程的描述，此处不再赘述。

在实际应用中，第一测试可以是充电测试、电源状态测试、档位状态测试或者其它类型测试中的任意一种。而第二测试就可以是与第一测试不同的其它测试。例如：第一测试为充电测试，第二测试为电源状态测试。

在这里，第一测试与第二测试仅是为了说明测试脚本可以一次进行多项测试。当然，还可以在第一测试和第二测试之后增加第三测试。对于测试项的多少，可以根据实际测试需求确定。

由上述内容可知，本发明实施例提供的车辆测试方法，通过判断第一反馈数据是否符合测试用例，当第一反馈数据符合测试用例时，再获取第二反馈数据，并判断第二反馈数据是否符合测试用例，能够避免在一项测试中已测试出问题时还继续进行无意义的测试，提高测试效率。并且，通过获取第一操作信息、第二操作信息，并进行显示，能够提醒测试人员尽快执行相应的操作，使车辆尽快产生操作相应的反馈数据，进而对反馈数据进行判断，提高测试效率。还有，在进行完第一测试后继续进行第二测试，能够一次性进行多项测试，提高测试效率。以及，在测试结束后，将测试结果进行显示，使测试人员能够直接看到测试结果，使得测试结果清晰可见。

基于同一发明构思，作为对上述方法的实现，本发明实施例还提供了一种车辆测试装置。图5为本发明实施例中车辆测试装置的结构示意图，参见图5所示，该装置50可以包括：获取模块501，用于获取控制器局域网中传输的至少一个反馈数据；第一确定模块502，用于确定所述至少一个反馈数据的类型；第二确定模块503，用于根据所述类型确定所述至少一个反馈数据对应的测试用例，所述测试用例包含测试所述至少一个反馈数据是否正常的测试逻辑；测试模块504，用于根据所述测试用例对所述至少一个反馈数据进行测试。

基于前述实施例，所述测试模块，具体用于判断所述至少一个反馈数据是否符合所述测试用例；当所述至少一个反馈数据符合所述测试用例时，确定所述车辆通过第一测试；当所述至少一个反馈数据不符合所述测试用例时，确定所述车辆未通过第一测试。

基于前述实施例，所述至少一个反馈数据包括第一反馈数据；所述测试模块，具体用于判断所述第一反馈数据是否符合所述测试用例；当所述第一反馈数据符合所述测试用例时，获取所述控制器局域网中传输的第二反馈数据；判断所述第二反馈数据是否符合所述测试用例，所述第二反馈数据与所述第一反馈数据的类型相同；当所述第一反馈数据不符合所述测试用例时，确定所述至少一个反馈数据不符合所述测试用例。

基于前述实施例，所述测试包括充电测试，所述第一反馈数据用于指示供电设备的连接状态，所述第二反馈数据用于指示所述供电设备的充电状态，所述测试用例包括：检测所述供电设备的连接状态；当所述连接状态为已连接时，检测所述供电设备的充电状态；当所述充电状态为正在充电时，结束测试。

基于前述实施例，所述测试包括电源状态测试，所述第一反馈数据用于指示打开车门后的电源模式，所述第二反馈数据用于指示踩制动后的电源模式，所述测试用例包括：检测打开车门后的电源模式；当打开车门后的电源模式为自适应巡航控制模式时，检测踩制动后的电源模式；当踩制动后的电源模式为向所有电器供电模式时，结束测试。

基于前述实施例，所述测试包括档位状态测试，所述至少一个反馈数据还包括第三反馈数据，所述第三反馈数据与所述第一反馈数据的类型相同，所述第一反馈数据用于指示切换为前进档后的档位状态，所述第二反馈数据用于指示切换为倒车档后的档位状态，所述第三反馈数据用于指示切换为停车档后的档位状态，所述测试用例包括：检测切换为前进档后的档为状态；当切换为前进档后的档位状态为前进时，检测切换为倒车档后的档位状态；当切换为倒车档后的档位状态为倒车时，检测切换为停车档后的档位状态；当切换为停车档后的档位状态为停车时，结束测试。

基于前述实施例，所述装置还包括：提示模块，用于获取第一操作信息，所述第一操作信息用于触发所述车辆生成所述第一反馈数据；当所述第一反馈数据符合所述测试用例时，获取第二操作信息，所述第二操作信息用于触发所述车辆生成所述第二反馈数据。

基于前述实施例，所述获取模块，还用于获取所述控制器局域网中传输的与第二测试相关的反馈数据；所述第一确定模块，还用于确定与所述第二测试相关的反馈数据的类型；所述第二确定模块，还用于根据与所述第二测试相关的反馈数据的类型确定与所述第二测试相关的反馈数据对应的测试用例，与所述第二测试相关的反馈数据对应的测试用例包含测试与所述第二测试相关的反馈数据是否正常的测试逻辑；所述测试模块，还用于根据与所述第二测试相关的反馈数据对应的测试用例对与所述第二测试相关的反馈数据进行测试。

基于前述实施例，Python脚本中包含所述测试用例；所述测试模块，具体用于通过Python脚本对所述至少一个反馈数据进行测试。

这里需要指出的是：以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本发明装置实施例中未披露的技术细节，请参照本发明方法实施例的描述而理解。

基于同一发明构思，本发明实施例还提供了一种车辆测试设备。图6为本发明实施例中车辆测试设备的结构示意图，参见图6所示，该设备103可以包括：至少一个处理器601；以及与处理器601连接的至少一个存储器602、总线603；其中，处理器601、存储器602通过总线603完成相互间的通信；处理器601用于调用存储器602中的程序指令，以执行上述一个或多个实施例中的方法。

这里需要指出的是：以上设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本发明实施例的设备的实施例中未披露的技术细节，请参照本发明方法实施例的描述而理解。

基于同一发明构思，本发明实施例还提供了一种车辆测试系统。图7为本发明实施例中车辆测试系统的结构示意图，参见图7所示，该系统70可以包括：CAN数据获取设备102和上述实施例中的车辆测试设备103；上述实施例中的车辆测试设备103与CAN数据获取设备102连接，利用所述CAN数据获取设备通过CAN获取至少一个反馈数据。

在实际应用中，CAN数据获取设备可以是安装有CANoe或CANalyzer的设备。具体来说，车辆测试设备通过调用CANoe或CANalyzer中的API，使CAN数据获取设备自动开始记录CAN中的反馈数据，并进行存储，在结束反馈数据的存储后，将存储的反馈数据通过API回传给车辆测试设备。以使车辆测试设备通过反馈数据判断车辆的某一项或某几项功能是否正常。

这里需要指出的是：以上系统实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本发明系统实施例中未披露的技术细节，请参照本发明方法实施例的描述而理解。

基于同一发明构思，本发明实施例还提供了一种计算机可读存储介质，上述计算机可读存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行上述一个或多个实施例中的方法。

这里需要指出的是：以上计算机可读存储介质实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本发明实施例的计算机可读存储介质的实施例中未披露的技术细节，请参照本发明方法实施例的描述而理解。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (12)

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

通过数据获取设备获取控制器局域网中传输的至少一个反馈数据；

确定所述至少一个反馈数据的类型；

根据所述类型确定所述至少一个反馈数据对应的测试用例，所述测试用例包含测试所述至少一个反馈数据是否正常的测试逻辑；

根据所述测试用例对所述至少一个反馈数据进行测试；

所述根据所述测试用例对所述至少一个反馈数据进行测试，包括：

判断所述至少一个反馈数据是否符合所述测试用例；

当所述至少一个反馈数据符合所述测试用例时，确定所述车辆通过第一测试，所述确定所述车辆通过第一测试用于表征所述车辆参与所述第一测试；

当所述至少一个反馈数据不符合所述测试用例时，确定所述车辆未通过第一测试，所述确定所述车辆未通过第一测试用于表征所述车辆未参与所述第一测试；

在确定所述车辆通过所述第一测试之后，所述方法还包括：

获取所述控制器局域网中传输的与第二测试相关的反馈数据；

确定与所述第二测试相关的反馈数据的类型；

根据与所述第二测试相关的反馈数据的类型确定与所述第二测试相关的反馈数据对应的测试用例，与所述第二测试相关的反馈数据对应的测试用例包含测试与所述第二测试相关的反馈数据是否正常的测试逻辑；

根据与所述第二测试相关的反馈数据对应的测试用例对与所述第二测试相关的反馈数据进行测试。

2.根据权利要求1所述的方法，其特征在于，所述至少一个反馈数据包括第一反馈数据；所述判断所述至少一个反馈数据是否符合所述测试用例，包括：

判断所述第一反馈数据是否符合所述测试用例；

当所述第一反馈数据符合所述测试用例时，获取所述控制器局域网中传输的第二反馈数据；判断所述第二反馈数据是否符合所述测试用例，所述第二反馈数据与所述第一反馈数据的类型相同；

当所述第一反馈数据不符合所述测试用例时，确定所述至少一个反馈数据不符合所述测试用例。

3.根据权利要求2所述的方法，其特征在于，所述测试包括充电测试，所述第一反馈数据用于指示供电设备的连接状态，所述第二反馈数据用于指示所述供电设备的充电状态，

所述测试用例包括：检测所述供电设备的连接状态；当所述连接状态为已连接时，检测所述供电设备的充电状态；当所述充电状态为正在充电时，结束测试。

4.根据权利要求2所述的方法，其特征在于，所述测试包括电源状态测试，所述第一反馈数据用于指示打开车门后的电源模式，所述第二反馈数据用于指示踩制动后的电源模式，

所述测试用例包括：检测打开车门后的电源模式；当打开车门后的电源模式为自适应巡航控制模式时，检测踩制动后的电源模式；当踩制动后的电源模式为向所有电器供电模式时，结束测试。

5.根据权利要求2所述的方法，其特征在于，所述测试包括档位状态测试，所述至少一个反馈数据还包括第三反馈数据，所述第三反馈数据与所述第一反馈数据的类型相同，

所述第一反馈数据用于指示切换为前进档后的档位状态，所述第二反馈数据用于指示切换为倒车档后的档位状态，所述第三反馈数据用于指示切换为停车档后的档位状态，

所述测试用例包括：检测切换为前进档后的档位 状态；当切换为前进档后的档位状态为前进时，检测切换为倒车档后的档位状态；当切换为倒车档后的档位状态为倒车时，检测切换为停车档后的档位状态；当切换为停车档后的档位状态为停车时，结束测试。

6.根据权利要求2至5中任一项所述的方法，其特征在于，在判断所述第一反馈数据是否符合所述测试用例之前，所述方法还包括：

获取第一操作信息，所述第一操作信息用于触发所述车辆生成所述第一反馈数据；

当所述第一反馈数据符合所述测试用例时，获取第二操作信息，所述第二操作信息用于触发所述车辆生成所述第二反馈数据。

7.根据权利要求1所述的方法，其特征在于，Python脚本中包含所述测试用例；所述根据所述测试用例对所述至少一个反馈数据进行测试，包括：

通过Python脚本对所述至少一个反馈数据进行测试。

8.一种车辆测试装置，其特征在于，包括：

获取模块，用于通过数据获取设备获取控制器局域网中传输的至少一个反馈数据；

第一确定模块，用于确定所述至少一个反馈数据的类型；

第二确定模块，用于根据所述类型确定所述至少一个反馈数据对应的测试用例，所述测试用例包含测试所述至少一个反馈数据是否正常的测试逻辑；

测试模块，用于根据所述测试用例对所述至少一个反馈数据进行测试；

所述测试模块，具体用于判断所述至少一个反馈数据是否符合所述测试用例；当所述至少一个反馈数据符合所述测试用例时，确定所述车辆通过第一测试，所述确定所述车辆通过第一测试用于表征所述车辆参与所述第一测试；当所述至少一个反馈数据不符合所述测试用例时，确定所述车辆未通过第一测试，所述确定所述车辆未通过第一测试用于表征所述车辆未参与所述第一测试；

所述获取模块，还用于获取所述控制器局域网中传输的与第二测试相关的反馈数据；所述第一确定模块，还用于确定与所述第二测试相关的反馈数据的类型；所述第二确定模块，还用于根据与所述第二测试相关的反馈数据的类型确定与所述第二测试相关的反馈数据对应的测试用例，与所述第二测试相关的反馈数据对应的测试用例包含测试与所述第二测试相关的反馈数据是否正常的测试逻辑；所述测试模块，还用于根据与所述第二测试相关的反馈数据对应的测试用例对与所述第二测试相关的反馈数据进行测试。

9.根据权利要求8所述的装置，其特征在于，所述至少一个反馈数据包括第一反馈数据；所述测试模块，具体用于判断所述第一反馈数据是否符合所述测试用例；当所述第一反馈数据符合所述测试用例时，获取所述控制器局域网中传输的第二反馈数据；判断所述第二反馈数据是否符合所述测试用例，所述第二反馈数据与所述第一反馈数据的类型相同；当所述第一反馈数据不符合所述测试用例时，确定所述至少一个反馈数据不符合所述测试用例。

10.一种车辆测试设备，其特征在于，所述设备包括：

至少一个处理器；

以及与所述处理器连接的至少一个存储器、总线；

其中，所述处理器、存储器通过所述总线完成相互间的通信；所述处理器用于调用所述存储器中的程序指令，以执行如权利要求1至7中任一项所述的方法。

11.一种车辆测试系统，其特征在于，所述系统包括：CAN数据获取设备和权利要求10所述的设备；权利要求10所述的设备与所述CAN数据获取设备连接，利用所述CAN数据获取设备通过控制器局域网获取至少一个反馈数据。

12.一种计算机可读存储介质，其特征在于，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行如权利要求1至7中任一项所述的方法。

Images