CN114844813A

CN114844813A - 一种基于通信异常注入的测试方法、装置及相关设备

Info

Publication number: CN114844813A
Application number: CN202210468488.5A
Authority: CN
Inventors: 吴捷成; 韩旭
Original assignee: Guangzhou Weride Technology Co Ltd
Current assignee: Guangzhou Weride Technology Co Ltd
Priority date: 2022-04-29
Filing date: 2022-04-29
Publication date: 2022-08-02
Anticipated expiration: 2042-04-29
Also published as: CN114844813B

Abstract

本申请公开了一种基于通信异常注入的测试方法、装置及相关设备，包括：当需要发送消息时，判断是否需要注入异常；若是，基于所述消息对应的异常逻辑，采用预设的通信接口发送或丢弃所述消息；其中，所述通信接口为通过工厂模式对初始通信接口进行封装后得到的，所述异常逻辑通过工厂模式记载在所述通信接口中。在通过工厂模式创建对象时，不会对客户端暴露对象的创建逻辑，而是通过使用共同的接口来创建对象，在这种情况下，通过工厂模式增加通信接口的业务逻辑不需要改动初始通信接口，从而实现了在不修改现有代码的前提下，对消息进行了异常注入，便于进行通信异常情况的测试。

Description

一种基于通信异常注入的测试方法、装置及相关设备

技术领域

本申请涉及自动驾驶技术领域，更具体地说，是涉及一种基于通信异常注入的测试方法、装置及相关设备。

背景技术

现有的分布式系统由多个相互独立的节点(node)组成，节点之间的通信方式因系统而异。为了适配多种通信方式的需求，现有的系统往往会将通信功能通过接口(interface)来实现，通信的发送方和接收方不需要了解所采用的具体通信方式，通过调用通信接口来实现通信功能。

例如，在自动驾驶软件系统中，可将整个软件系统看作一个分布式系统，系统中各个组件(如摄像机传感器、感知模块、规划模块等)可看作这个分布式系统的节点，它们之间相互独立，并通过共享内存等方式实现通信。

在分布式系统的开发过程中，需要对所开发的节点进行测试，其中，对通信异常情况的测试是非常重要的一环。然而，为了不影响系统在生产环境的正常运行，应该在不对现有节点的代码进行修改的前提下进行异常注入测试，如何在不修改节点的现有代码的前提下，进行通信异常情况的测试成为一个亟待解决的问题。

发明内容

有鉴于此，本申请提供了一种基于通信异常注入的测试方法、装置及相关设备，以实现在不修改节点的现有代码的前提下，进行通信异常测试。

为实现上述目的，本申请第一方面提供了一种基于通信异常注入的测试方法，包括：

当需要发送消息时，判断是否需要注入异常；

若是，基于所述消息对应的异常逻辑，采用预设的通信接口发送或丢弃所述消息；

其中，所述通信接口为通过工厂模式对初始通信接口进行封装后得到的，所述异常逻辑通过工厂模式记载在所述通信接口中。

优选地，所述通过工厂模式对初始通信接口进行封装的过程，包括：

调用预设的工厂方法构造所述初始通信接口，得到实例化的通信接口；

将所述实例化的通信接口封装到注册有异常逻辑的外层通信接口中。

优选地，将所述实例化的通信接口封装到注册有异常逻辑的外层通信接口中的过程，包括：

对预设的异常定义配置文件进行解析，得到异常逻辑；

将所述异常逻辑注册到外层通信接口中，并将所述实例化的通信接口封装到所述外层通信接口中。

优选地，所述异常逻辑包括与各消息主题对应的异常条件；所述判断是否需要注入异常的过程，包括：

获取运行数据，基于所述消息的主题、所述运行数据以及所述异常条件，判断是否需要注入异常。

优选地，所述运行数据包括就绪时间、当前时间、在所述主题下的上一次异常注入的时间、在所述主题下的异常注入次数；基于所述消息的主题、所述运行数据以及所述异常条件，判断是否需要注入异常的过程，包括：

基于所述消息的主题，获取与所述消息的主题匹配的目标异常条件；

若所述目标异常条件包含时间条件，基于所述就绪时间、当前时间以及在所述主题下的上一次异常注入的时间，判断是否满足所述时间条件，得到第一判断结果；

若所述目标异常条件包含次数条件，基于所述主题下的异常注入次数，判断是否满足所述次数条件，得到第二判断结果；

基于所述第一判断结果和/或所述第二判断结果，确定是否需要注入异常。

优选地，所述异常逻辑还包括与各消息主题对应的异常规则；基于所述消息对应的异常逻辑，采用预设的通信接口发送或丢弃所述消息的过程，包括：

基于所述消息的主题，获取与所述消息的主题匹配的目标异常规则；

基于所述目标异常规则，丢弃所述消息，或者，对所述消息进行延迟和/或降质发送。

优选地，所述基于通信异常注入的测试方法还包括：

对发出的每一条消息以及发出消息时的运行状态进行记录，得到运行记录；

将所述运行记录与预先配置好的期望运行状态进行比对，得到测试结果。

本申请第二方面提供了一种基于通信异常注入的测试系统，包括：

采用上述的基于通信异常注入的测试方法对自动驾驶软件系统中的各个模块之间的通信功能进行测试；

其中，所述各个模块包括感知模块、认知模块和执行模块。

本申请第三方面提供了一种基于通信异常注入的测试装置，包括：

判断单元，用于当需要发送消息时，判断是否需要注入异常；

处理单元，用于当所述判断单元判断出需要注入异常时，基于所述消息对应的异常逻辑，采用预设的通信接口发送或丢弃所述消息；

本申请第四方面提供了一种基于通信异常注入的测试设备，包括：存储器和处理器；

所述存储器，用于存储程序；

所述处理器，用于执行所述程序，实现上述的基于通信异常注入的测试方法的各个步骤。

本申请第五方面提供了一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现如上述的基于通信异常注入的测试方法的各个步骤。

经由上述的技术方案可知，当需要发送消息时，本申请首先判断是否需要注入异常。若是，基于所述消息对应的异常规则，采用预设的通信接口发送或丢弃所述消息。其中，所述通信接口为通过工厂模式对初始通信接口进行封装后得到的，所述异常规则通过工厂模式记载在所述通信接口中，由于通过工厂模式增加通信接口的业务逻辑不需要改动初始通信接口，从而实现了在不修改现有代码的前提下，对消息进行了异常注入，便于进行通信异常情况的测试。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例公开的基于通信异常注入的测试系统的示意图；

图2为本申请实施例公开的基于通信异常注入的测试方法的示意图；

图3为本申请实施例公开的基于通信异常注入的测试方法的另一示意图；

图4为本申请实施例公开的基于通信异常注入的测试方法的整体示意图；

图5为本申请实施例公开的基于通信异常注入的测试装置的示意图；

图6为本申请实施例公开的基于通信异常注入的测试装置的另一示意图；

图7为本申请实施例公开的基于通信异常注入的测试装置的另一示意图；

图8为本申请实施例公开的基于通信异常注入的测试设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

请参阅图1，自动驾驶系统的架构一般地可以划分为以下几个功能层：感知层、认知层和执行层。其中，感知层包含多个感知模块，用于检测驾驶员的输入及状态、车辆自身的运动状态以及车辆周围的环境情况；认知层包含多个认知模块，用于根据感知层得到的驾驶员驾驶意图和驾驶状态、当前车身的速度和位姿以及外部威胁情况，通过一定的决策逻辑、规划算法，得出期望的车辆速度、行驶路径等信息，并将其下发给执行层；执行层包含多个执行模块，用于执行认知层下发的控制指令。感知模块、认知模块以及执行模块可以看成独立的节点，各节点之间可以通过共享内存、事件总线(Event Bus)、SPI(ServiceProvider Interface)或者基于TCP/IP的套接字等方式实现通信，而为了对这些节点之间的通信功能进行测试，可以在发生通信时按照具体的测试用例注入异常，并记录系统的反应。为了不影响系统在生产环境的正常运行，可以采用本申请提供的基于通信异常注入的测试方法，在不对现有节点的代码进行修改的前提下进行异常注入测试。

下面介绍本申请实施例提供的基于通信异常注入的测试方法。请参阅图2，本申请实施例提供的基于通信异常注入的测试方法可以包括如下步骤：

步骤S101，当需要发送消息时，判断是否需要注入异常。若是，执行步骤S102。

例如，可以设置一些触发异常的条件，如果当前状况满足这些条件，则启动异常的注入，在注入异常后再发送该消息。

步骤S102，基于该消息对应的异常逻辑，采用预设的通信接口发送或丢弃该消息。

其中，该通信接口为通过工厂模式(Factory Design Pattern)对初始通信接口进行封装后得到的；该异常逻辑描述了在什么情况下需要注入什么样的异常，异常逻辑也是通过工厂模式记载在该通信接口中。

当需要发送消息时，本申请实施例首先判断是否需要注入异常。若是，基于该消息对应的异常规则，采用预设的通信接口发送或丢弃该消息。其中，该通信接口为通过工厂模式对初始通信接口进行封装后得到的，该异常规则通过工厂模式记载在所述通信接口中。其中，工厂模式是一种非常常用的创建型设计模式，其提供了创建对象的最佳方式。在通过工厂模式创建对象时，不会对客户端暴露对象的创建逻辑，而是通过使用共同的接口来创建对象，在这种情况下，通过工厂模式增加通信接口的业务逻辑不需要改动初始通信接口，从而实现了在不修改现有代码的前提下，对消息进行了异常注入，便于进行通信异常情况的测试。

在本申请的一些实施例中，上述通过工厂模式对初始通信接口进行封装的过程，可以包括：

S1，调用预设的工厂方法构造该初始通信接口，得到实例化的通信接口。

S2，将该实例化的通信接口封装到注册有异常逻辑的外层通信接口中。

其中，工厂方法模式是一种常用的类创建型设计模式，该模式的核心精神是封装类中变化的部分，提取其中个性化善变的部分为独立类，通过依赖注入以达到解耦、复用和方便后期维护拓展的目的。

在本申请的一些实施例中，上述S2将该实例化的通信接口封装到注册有异常逻辑的外层通信接口中的过程，可以包括：

S21，对预设的异常定义配置文件进行解析，得到异常逻辑。

S22，将该异常逻辑注册到外层通信接口中，并将该实例化的通信接口封装到该外层通信接口中。

表1：异常定义配置文件的模板示例

实际应用中，通信异常的情况可以是多种多样的，如消息丢失、延迟、数据损坏等，为了尽可能多地覆盖各种场景，测试项目应该具有一定可扩展性。表1示例了异常定义配置文件的其中一种模板，其中“ScenarioConfig”定义了一次通信异常测试场景，由场景名“name”、期望系统运行状态“grading_config”和注入异常“fault_configs”组成。期望系统运行状态定义为状态名“name”(用于区分状态定义)、故障定义“malfunction_definition”(如是否期望发生某个类型的故障)、聚合方式“aggregation_type”(“与”/“或”，即对于当前异常注入的判断，进行“与运算”还是“或运算”以得到最终判断结果)。异常注入定义为需要异常注入的消息的主题“topic”、异常类型“Fault”(包括丢帧、延迟、降质、节点崩溃等等)、触发异常的频率“Frequency”(全部消息、连续x条消息、按概率触发等等)、异常触发的间隔“trigger_interval_ns”(例如希望每20秒触发一次异常)、异常触发等待时间“start_ns_from_system_ready”(有时候不希望软件系统就绪后立马触发异常，可设置此值)。通过采用配置文件的形式来描述异常定义，使得可以根据实际需要扩展测试项目。

基于此，在本申请的一些实施例中，前面所提及的异常逻辑可以包括与各消息主题对应的异常条件。其中，自动驾驶软件中可以包括多种消息主题(topic)，不同消息主题的消息可以对应有不同的异常注入策略；异常条件描述了触发异常注入需要满足什么样的条件。基于此，上述步骤S101判断是否需要注入异常的过程，可以包括：

S1，获取运行数据。

S2，基于该消息的主题、该运行数据以及该异常条件，判断是否需要注入异常。

其中，运行数据是指步骤S101中需要发送消息时，软件系统的运行数据，如各个变量的具体数值、系统状态以及当前的时间信息等。

在本申请的一些实施例中，上述的运行数据可以包括就绪时间、当前时间、在该主题下的上一次异常注入的时间、在该主题下的异常注入次数等。

其中，就绪时间是指软件系统的就绪时间；当前时间是指步骤S101中需要发送消息时的时间；在该主题下的上一次异常注入的时间是指在该消息的主题下，发生上一次异常注入的时间；在该主题下的异常注入次数是指在该消息的主题下，发生异常注入的总次数。

基于此，在本申请的一些实施例中，上述S2基于该消息的主题、该运行数据以及该异常条件，判断是否需要注入异常的过程，可以包括：

S21，基于该消息的主题，获取与该消息的主题匹配的目标异常条件。

S22，若该目标异常条件包含时间条件，基于该就绪时间、当前时间以及在该主题下的上一次异常注入的时间，判断是否满足该时间条件，得到第一判断结果。

其中，该第一判断结果可以是满足条件，或者，不满足条件。

S23，若该述目标异常条件包含次数条件，基于该主题下的异常注入次数，判断是否满足该次数条件，得到第二判断结果。

其中，该第二判断结果可以是满足条件，或者，不满足条件。

S24，基于该第一判断结果和该第二判断结果，确定是否需要注入异常。

具体地，要依据时间条件与次数条件的聚合方式(与逻辑或者或逻辑)，来确定是否需要注入异常。即，假设时间条件与次数条件的聚合方式为“与”，则当第一判断结果和第二判断结果同时满足条件时，则确定需要注入异常；假设时间条件与次数条件的聚合方式为“或”，则当第一判断结果或者第二判断结果满足条件时，则确定需要注入异常。

表2：异常定义配置文件的代码示例

请参阅表2中的异常定义配置文件的示例，其定义了“在系统就绪1000000000ns后，每20000000000ns向主题为‘/topic_name’的消息注入一次连续5帧延迟125ms的异常”。在这个示例代码中，时间条件包括“系统就绪1000000000ns”以及“每20000000000ns”定期发送；次数条件为“连续5帧”，超出5帧就不再注入异常。且聚合方式(aggregationType)为“AND”，当时间条件与次数条件均满足时，才触发异常注入。

在本申请的一些实施例中，前面提及的异常逻辑还可以包括与各消息主题对应的异常规则，该异常规则用于描述注入什么样的异常。在表2的示例代码中，该异常规则表现为“在系统就绪1000000000ns后，每20000000000ns向主题为‘/topic_name’的消息注入一次连续5帧延迟125ms的异常”。此外，请如表1所示的异常定义模板中，异常规则还可以包括降质因子(frame_degrade)、丢帧(frame_missing)、触发频率(percentage)等等。

基于此，在本申请的一些实施例中，上述步骤S102基于所述消息对应的异常逻辑，采用预设的通信接口发送或丢弃该消息的过程，可以包括：

S1，基于该消息的主题，获取与该消息的主题匹配的目标异常规则。

S2，基于该目标异常规则，丢弃该消息，或者，对该消息进行延迟和降质发送中的至少一种。

对于丢弃该消息的情况，采取直接丢弃、不发送即可；对于延迟发送的情况，指人为地增加通信时延；对于降质发送的情况，可以是降低消息发送的优先级。其中，延迟发送和降质发送可以同时进行。

上面描述了对消息进行异常注入的各种实施方法，对于软件系统的测试还需要记录异常注入后对消息进行发送的各种状态信息，已确认软件系统是否在期望范围内正常运行。

基于此，请参见图3，在本申请的一些实施例中，该基于通信异常注入的测试还可以包括：

步骤S103，对发出的每一条消息以及发出消息时的运行状态进行记录，得到运行记录。

其中，可以通过外部工具监控整个软件系统的消息通信历史，并对产生消息通信时的运行状态进行记录。

步骤S104，将该运行记录与预先配置好的期望运行状态进行比对，得到测试结果。

其中，可以在异常定义配置文件中定义期望运行状态，软件系统在解释执行代码时则可以从该异常定义配置文件中提取得到期望运行状态。如表2所示的代码示例中，描述了在此次异常注入测试执行完毕后，系统每一帧都不应该出现2级以上的故障(thresholdAdvFaultLevel)。

结合上述多个实施例，可以得到如图4所示的整体流程图。请参阅图4，工程师在启动通信异常测试前，编写异常定义配置文件，同时可定义期望的系统运行状态。在软件系统启动后，会初始化各个节点，此时节点会实例化通信接口，为后续收发消息做准备。当节点准备发送消息时，可根据异常定义判断是否将异常注入此次消息发送。如果判断出应该注入异常，则根据异常定义选择异常种类(如丢弃信息、延迟发送等)注入到此次消息发送中，并使用实例化后的通信接口向其他节点发送消息。其中，软件系统在运行过程中，可以利用外部工具或其他方法记录每个时刻各个节点发送的消息以及当时的运行状态，以便后续对测试结果进行评估。在需要时，可以根据异常配置中期望的系统运行状态以及记录到的实际运行状态进行比对，从而获知节点是否按照设计正确处理通信异常。

下面对本申请实施例提供的基于通信异常注入的测试装置进行描述，下文描述的基于通信异常注入的测试装置与上文描述的基于通信异常注入的测试方法可相互对应参照。

请参见图5，本申请实施例提供的基于通信异常注入的测试装置，可以包括：

判断单元21，用于当需要发送消息时，判断是否需要注入异常；

处理单元22，用于当所述判断单元判断出需要注入异常时，基于所述消息对应的异常逻辑，采用预设的通信接口发送或丢弃所述消息；

在本申请的一些实施例中，请参阅图6，基于通信异常注入的测试装置还可以包括封装单元23，所述封装单元用于通过工厂模式对初始通信接口进行封装。具体地，封装单元23通过工厂模式对初始通信接口进行封装的过程，可以包括：

在本申请的一些实施例中，封装单元23将所述实例化的通信接口封装到注册有异常逻辑的外层通信接口中的过程，可以包括：

对预设的异常定义配置文件进行解析，得到异常逻辑；

在本申请的一些实施例中，所述异常逻辑包括与各消息主题对应的异常条件；判断单元21判断是否需要注入异常的过程，可以包括：

在本申请的一些实施例中，所述运行数据包括就绪时间、当前时间、在所述主题下的上一次异常注入的时间、在所述主题下的异常注入次数；判断单元21基于所述消息的主题、所述运行数据以及所述异常条件，判断是否需要注入异常的过程，可以包括：

在本申请的一些实施例中，所述异常逻辑还包括与各消息主题对应的异常规则；处理单元22基于所述消息对应的异常逻辑，采用预设的通信接口发送或丢弃所述消息的过程，可以包括：

在本申请的一些实施例中，请参阅图7，基于通信异常注入的测试装置还可以包括比对单元24，用于：

本申请实施例提供的基于通信异常注入的测试装置可应用于基于通信异常注入的测试设备，如计算机等。可选的，图8示出了基于通信异常注入的测试设备的硬件结构框图，参照图8，基于通信异常注入的测试设备的硬件结构可以包括：至少一个处理器31，至少一个通信接口32，至少一个存储器33和至少一个通信总线34。

在本申请实施例中，处理器31、通信接口32、存储器33、通信总线34的数量为至少一个，且处理器31、通信接口32、存储器33通过通信总线34完成相互间的通信；

处理器31可能是一个中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路等；

存储器32可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatilememory)等，例如至少一个磁盘存储器；

其中，存储器33存储有程序，处理器31可调用存储器33存储的程序，所述程序用于：

当需要发送消息时，判断是否需要注入异常；

可选的，所述程序的细化功能和扩展功能可参照上文描述。

本申请实施例还提供一种存储介质，该存储介质可存储有适于处理器执行的程序，所述程序用于：

当需要发送消息时，判断是否需要注入异常；

可选的，所述程序的细化功能和扩展功能可参照上文描述。

综上所述：

进一步地，本申请采用异常定义配置文件对异常逻辑以及软件系统的期望运行状态进行描述，便于各种测试场景的引入，具有一定的可扩展性。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间可以根据需要进行组合，且相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims

1.一种基于通信异常注入的测试方法，其特征在于，包括：

当需要发送消息时，判断是否需要注入异常；

2.根据权利要求1所述的方法，其特征在于，所述通过工厂模式对初始通信接口进行封装的过程，包括：

3.根据权利要求2所述的方法，其特征在于，将所述实例化的通信接口封装到注册有异常逻辑的外层通信接口中的过程，包括：

对预设的异常定义配置文件进行解析，得到异常逻辑；

4.根据权利要求1所述的方法，其特征在于，所述异常逻辑包括与各消息主题对应的异常条件；所述判断是否需要注入异常的过程，包括：

5.根据权利要求4所述的方法，其特征在于，所述运行数据包括就绪时间、当前时间、在所述主题下的上一次异常注入的时间、在所述主题下的异常注入次数；基于所述消息的主题、所述运行数据以及所述异常条件，判断是否需要注入异常的过程，包括：

6.根据权利要求4所述的方法，其特征在于，所述异常逻辑还包括与各消息主题对应的异常规则；基于所述消息对应的异常逻辑，采用预设的通信接口发送或丢弃所述消息的过程，包括：

7.根据权利要求1至6任一项所述的方法，其特征在于，还包括：

8.一种自动驾驶测试系统，其特征在于，包括：

采用权利要求1～7中任一项所述的基于通信异常注入的测试方法对自动驾驶软件系统中的各个模块之间的通信功能进行测试；

其中，所述各个模块包括感知模块、认知模块和执行模块。

9.一种基于通信异常注入的测试装置，其特征在于，包括：

10.一种基于通信异常注入的测试设备，其特征在于，包括：存储器和处理器；

所述存储器，用于存储程序；

所述处理器，用于执行所述程序，实现如权利要求1～7中任一项所述的基于通信异常注入的测试方法的各个步骤。

11.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现如权利要求1～7中任一项所述的基于通信异常注入的测试方法的各个步骤。