服务接口测试方法、装置及设备与流程

1.本技术涉及车辆测试技术领域，特别是涉及一种服务接口测试方法、装置及设备。


背景技术：

2.随着面向服务架构(service-oriented architecture，soa)在车载领域越来越广泛的应用，整车功能的实现也逐渐依赖于各个子功能模块(简称为服务)的组成和相互调度，服务体现其优越性(可复用、松耦合等)的前提是通信节点协议的一致性、服务接口的正确性和稳定性。简化的跨域通信协议(scalable service-oriented middleware over ip，some/ip)作为一种通信中间件，是可以实现基于服务的通信的机制选择之一。
3.目前基于some/ip协议通过通信控制器进行服务之间的通信，而服务接口的正确与否主要依赖于对控制器网络报文的直接判断，而控制器提供的服务存在触发类型的报文，针对触发类接口/报文，如果触发条件较为复杂且不好模拟，则该接口在单部件阶段很难测试，导致只能在台架集成甚至实车集成后才能开展对该接口/报文的测试，一旦触发条件发生变化，若要满足测试条件，相关的触发环境则需要重新开发和适配，不具有可复用性，导致测试效率较低。


技术实现要素：

4.本技术提供的一种服务接口测试方法、装置及设备，能够提高测试效率。
5.第一方面，本技术实施例提供一种服务接口测试方法，方法包括：
6.基于预获取的接口标准文件配置多个服务接口；
7.配置多个服务接口的处理规则，处理规则是对多个服务接口收发的预设类型的报文进行处理的规则；
8.向服务接口发送预设类型的报文；
9.获取服务接口的反馈报文，反馈报文是服务接口按照处理规则对接收到的预设类型的报文进行处理得到的；
10.以接口标准文件为参照，对反馈报文进行判定，得到测试结果。
11.第二方面，本技术提供一种服务接口测试装置，该装置包括：
12.第一配置模块，用于基于预获取的接口标准文件配置多个服务接口；
13.第二配置模块，用于配置多个服务接口的处理规则，处理规则是对多个服务接口收发的预设类型的报文进行处理的规则；
14.发送模块，用于向服务接口发送预设类型的报文；
15.获取模块，用于获取服务接口的反馈报文，反馈报文是服务接口按照处理规则对接收到的预设类型的报文进行处理得到的；
16.判定模块，用于以接口标准文件为参照，对反馈报文进行判定，得到测试结果。
17.第三方面，本技术实施例提供了一种电子设备，该电子设备包括：处理器以及存储有计算机程序指令的存储器；
18.处理器执行计算机程序指令时实现如第一方面中任意一个实施例中的服务接口测试方法。
19.第四方面，本技术实施例提供了一种计算机存储介质，计算机存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现如第一方面中任意一个实施例中的服务接口测试方法。
20.第五方面，本技术实施例提供了一种计算机程序产品，计算机程序产品中的指令由电子设备的处理器执行时，使得电子设备执行实现如上述第一方面中任意一个实施例中的服务接口测试方法。
21.在本技术实施例提供的一种服务接口测试方法、装置及设备中，通过基于预获取的接口标准文件配置多个服务接口；配置多个服务接口的处理规则，处理规则是对多个服务接口收发的预设类型的报文进行处理的规则；向服务接口发送预设类型的报文；获取服务接口的反馈报文，反馈报文是服务接口按照处理规则对接收到的预设类型的报文进行处理得到的；以接口标准文件为参照，对反馈报文进行判定，得到测试结果。通过上述方式，通过向多个服务接口配置统一预设类型的处理规则，在对多个服务接口进行测试时，通过向各服务接口发送相同预设类型的报文，可得到每个服务接口按照处理规则对预设类型的报文进行处理后的反馈报文，后续可将反馈报文与标准接口文件进行比对，得到测试结果，上述方式中，由于通过处理规则对多个服务接口的处理方式进行统一配置，无需进行复杂的测试环境的仿真，提高了服务接口测试的测试效率。
附图说明
22.为了更清楚地说明本技术实施例的技术方案，下面将对本技术实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
23.图1是现有技术中基于some/ip协议的通信控制器主流开发流程示意图；
24.图2是本技术一个实施例提供的服务接口测试方法的流程示意图；
25.图3是本技术一个实施例提供的一种测试模块的拓扑结构示意图；
26.图4是本技术一个实施例提供的一种预设类型的报文的报文格式的示意图；
27.图5是本技术实施例提供的一种服务接口测试装置的结构示意图；
28.图6是本技术实施例提供的电子设备的结构示意图。
具体实施方式
29.为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。
30.在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。
31.需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之
间存在任何这种实际的关系或者顺序。而且，术语“包括”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
32.some/ip作为一种通信中间件，是可以实现基于服务的通信的机制选择之一，autosar标准《autosar_prs_someipprotocol》(简称《prs_someip》)及《autosar_prs_someipservicediscovery protocol》(后续简称《prs_sd》)定义了其报文格式、数据序列化规则和服务发现等运行机制，目前汽车电子技术领域针对基于some/ip协议的通信测试主要分为以下几类：1)依据open alliance tc8规范进行的“some/ip-server”测试(后续简称server测试)；2)依据open alliance tc8规范(后续简称tc8)进行的“some/ip-ets(enhanced testability service)”测试(后续简称ets测试)，验证some/ip协议栈的实现和autosar标准的一致性；3)样件开发集成完成后基于各主机厂自定义的测试规范开展的系统测试或功能测试(后续简称集成测试)。
33.首先，目前基于some/ip协议的通信控制器主流开发流程如图1所示，对于前文所述三种测试类别，ets测试是针对some/ip协议栈一致性的测试，仅可验证协议栈对于《prs_someip》和《prs_sd》定义的完整协议机制实现的正确性，在实际通信业务中，some/ip协议栈提供的接口配置无法验证，即图1中s21阶段的工作无法验证。server测试和集成测试需要依赖控制器应用功能逻辑开发结束并完成协议栈适配后(对应图1中s22、s31、s31步骤完成)才可以开展，对于逻辑复杂、接口较多的服务来说，软件组件(softwarecomopnent，swc)开发的时间也就越久(对应s22步骤)，服务接口的问题的暴露就会相对滞后，目前缺少一种通信测试方法和测试环节，将功能逻辑进行简化和统一，取消协议栈的配置测试与实际功能逻辑开发的依赖性，实现提前针对特定通信场景下的服务接口进行测试，提前发现问题，减少各开发阶段的耦合性，也方便后续测试阶段的问题定位。
34.其次，服务接口的正确与否主要依赖于对控制器网络报文的直接判断，而控制器提供的服务可能存在如下类型的接口：1)触发类：需要满足特定触发条件相关报文才可以发出；2)ff(fire and forget)类：控制器接收到外部报文请求后，无需发出响应报文。针对触发类接口/报文，如果触发条件较为复杂且不好模拟，则该接口在单部件阶段很难测试，要么需要借助外部仿真设备对触发条件进行模拟，要么只能在台架集成甚至实车集成后才能开展对该报文的测试，同样存在问题暴露滞后的缺陷；一旦触发条件发生变化，若要满足测试条件，相关的触发环境则需要重新开发和适配，不具有可复用性。针对ff类接口/报文，由于控制器无需进行响应，因此无法得知控制器是否有正确接收并处理其他控制器发过来的请求报文。目前缺少一种测试方法，针对触发类和ff类报文定义统一的触发环境和处理逻辑，这样可以在控制器较为前期开发阶段，针对触发类和ff类报文进行测试。
35.为了解决现有技术问题，本技术实施例提供了一种服务接口测试方法、装置及设备。下面首先对本技术实施例所提供的服务接口测试方法进行介绍。
36.图2示出了本技术一个实施例提供的服务接口测试方法的流程示意图。如图2所示，该方法具体可以包括如下步骤：
37.s100，基于预获取的接口标准文件配置多个服务接口。
38.可选地，在本技术实施例中，服务接口可以是车载服务接口。接口标准文件可以包括各服务的服务接口类型、服务接口传输的具体数据内容和数据格式、服务在各个通信节点的部署情况以及各服务的启动时序(如启动时间、生命周期等参数)等。
39.可选地，在本技术一种可能的实现方式中，可以使用相应的工具或编程语言，按照接口标准文件中定义的接口结构和消息格式进行配置，以实现对多个服务接口的配置。具体而言，可以在进行测试前，事先获取被测系统的接口标准文件，并根据接口标准文件，确定系统提供的服务接口的各种信息，包括服务名称、方法名称、参数类型、返回值类型等。需要注意的是，在进行测试前，需要对接口标准文件进行解析，并将解析得到的服务接口的接口信息用于配置测试系统中的多个服务接口。
40.可选地，在本技术实施例中，可以基于接口标准文件开展some/ip协议栈(即多个服务接口的集合)配置，目的是得到和接口标准文件一致的some/ip协议栈接口代码。其中，配置内容包括整车系统内所有服务的服务标识号、服务主版本号、次版本号、数据传输序列化规则(如大小端传输及是否采用内存对齐等)、服务的启动时序等。具体而言，可以基于特定的协议栈配置工具来完成，在工具中完成所有配置后可自动生成相应的代码接口文件以供后续进行服务接口的调用。
41.可选地，在本技术另一种可能的实现方式中，在基于预获取的接口标准文件配置多个服务接口时，需要按照标准文件中定义的服务接口和方法来进行配置。例如，配置工具提供一个界面，让用户选择接口标准文件中定义的服务接口和方法，并为它们分配一个唯一的标识符(service id和method id)。然后，用户可以将这些标识符与对应的实现代码或者协议栈进行绑定。具体可以在代码或者协议栈中实现一些初始化函数，将标识符和相应的实现功能绑定在一起。需要注意的是，在配置多个服务接口时，需要考虑各服务接口之间的互相影响。如果多个服务接口使用相同的协议栈或者共享同一个硬件资源，那么就需要进行合理的资源分配和调度，以避免资源竞争和冲突。此外，在配置多个服务接口时，还需要考虑性能和安全等因素，以确保系统能够正常运行并且不会受到攻击。
42.s200，配置多个服务接口的处理规则，处理规则是对多个服务接口收发的预设类型的报文进行处理的规则。
43.可选地，在本技术实施例中，在配置完服务接口后，还需要为每个服务接口定义相应的处理规则。处理规则是对服务接口收发的预设类型的报文进行处理的规则。例如，在测试某个服务接口时，需要发送一个特定的报文(即预设类型的报文)，并检查接收到的响应是否符合预期。这个特定的报文以及响应的预期结果就是处理规则中定义的内容。
44.可选地，在本技术实施例中，需要对处理规则进行设计开发，具体的设计逻辑可以为将所有触发类报文的触发条件进行了简化和统一，即所有的触发条件均简化为接收到指定的控制报文，且统一了报文格式定义；统一各类服务接口对应的应用的处理逻辑。设计产物即为处理规则。在本技术一种可能的方式中，处理规则的设计可以看成是服务接口可测试模块(service interface testability module，stm)的设计和开发，处理规则即为stm规范。
45.可选地，在本技术一种可能的实现方式中，配置多个服务接口可以首先定义处理规则，定义每个服务接口收发预设类型的报文时的处理规则，包括如何解析报文、如何处理报文中的数据、如何生成响应报文等。并根据定义好的处理规则，编写对应的处理规则脚
本，处理规则脚本通常采用特定的编程语言编写，用于实现处理规则中的具体逻辑。随后配置处理规则脚本路径，在测试系统中配置处理规则脚本的路径，以便测试系统能够正确地加载处理规则脚本。随后在测试系统中配置每个服务接口对应的处理规则，以便测试系统能够根据预设的处理规则对每个服务接口收发的预设类型的报文进行处理。需要注意的是，不同的测试系统和服务接口的配置方式可能会有所不同。
46.s300，向服务接口发送预设类型的报文。
47.可选地，在本技术实施例中，一旦配置好了服务接口和处理规则，就可以通过测试工具或编写测试脚本来向被测系统的服务接口发送预设类型的报文。这些预设类型的报文可以根据处理规则中定义的服务和方法进行定义，并根据处理规则进行配置。具体而言，可以首先配置通信参数，如波特率、接口等。打开相应的服务接口模块，并连接到相应的测试工具。选择相应的服务接口，创建对应的预设类型报文。将预设类型报文发送到相应的服务接口。
48.s400，获取服务接口的反馈报文，反馈报文是服务接口按照处理规则对接收到的预设类型的报文进行处理得到的。
49.可选地，在本技术实施例中，发送报文后，测试工具或测试脚本需要接收被测系统的服务接口返回的响应报文，并对响应报文进行解析和处理。处理结果就是获取到的服务接口的反馈报文，包括响应结果、响应时间、响应码等。相应报文即为服务接口按照处理规则处理预设类型的报文的响应结果。具体而言，根据上述配置的处理规则，服务接口在接收到预设类型的报文后，会按照规则进行处理，并生成响应报文。测试人员可以通过监听网络，获取服务接口发送的响应报文，从而获取反馈报文。一般情况下，响应报文中会携带服务接口处理的结果和相关信息。
50.s500，以接口标准文件为参照，对反馈报文进行判定，得到测试结果。
51.可选地，在本技术一种可能的实现方式中，可以使用相应的测试工具或编程语言，以接口标准文件为参照，对服务接口的反馈报文进行判定，从而得到测试结果。例如，可以编写对应的测试脚本或测试程序，自动化执行测试用例，并根据预期结果和实际结果进行比较和判断，以判断测试结果是否符合预期。如果测试结果与预期结果一致，则测试通过；如果不一致，则需要进一步分析和调试。
52.可选地，在本技术实施例中，可以根据接口标准文件和测试需求，确定需要对哪些服务接口进行测试。并将预设类型的报文作为测试用例。根据处理规则，对每个测试用例进行预期结果的制定。预期结果应包括对应的反馈报文，以及针对反馈报文的判定标准。随后使用测试工具或自动化脚本，向服务接口发送测试用例。获取服务接口的反馈报文并对比反馈报文和预期结果，判断测试用例是否通过。具体判断标准根据预期结果的制定而定，例如可以包括比对反馈报文中的字段值、状态码等。汇总测试结果，生成测试报告。测试报告应包括测试通过的用例数、测试失败的用例数以及失败原因等信息。需要注意的是，针对不同的接口标准文件和测试需求，测试方法和过程会有所不同。因此，在进行服务接口测试之前，需要制定相应的测试计划和测试用例。
53.可选地，在本技术一种具体地实施方式中，可以设计一种测试程序，其中测试程序进行some/ip接口测试的设计逻辑为some/ip接口测试的测试目的为检查配置完成的多个服务接口是否和接口标准文件设计的一致，检查的对象包括：服务的表示(id)、服务包括的
接口类型、服务主版本号、服务次版本号、数据传输序列化规则、服务启动时序等。测试程序读取接口标准文件，即some/ip服务接口描述文件，提取这些接口标准文件作为判断标准。其中，该读取过程的实现不做限制，可由测试人员通过手动输入至测试程序，也可以开发相应代码，由测试程序自动读取对应的设计产物文件来获取被测信息。测试程序发送预设类型的报文后，会依照stm规范对被测服务具有期待的响应行为，在接收到被测服务的反馈报文后，测试程序会根据反馈报文的报文格式，提取服务标识、版本号等被测信息，然后提取的被测信息(即接口标准文件)进行比较，若两者保持一致，则对应参数的配置即满足要求，测试通过；反之若二者保持不一致，则说明服务接口对该参数的配置与设计不符，测试未通过。
54.在本技术实施例提供的一种服务接口测试方法中，通过基于预获取的接口标准文件配置多个服务接口；配置多个服务接口的处理规则，处理规则是对多个服务接口收发的预设类型的报文进行处理的规则；向服务接口发送预设类型的报文；获取服务接口的反馈报文，反馈报文是服务接口按照处理规则对接收到的预设类型的报文进行处理得到的；以接口标准文件为参照，对反馈报文进行判定，得到测试结果。通过上述方式，通过向多个服务接口配置一个统一预设类型的处理规则，如此在对服务接口进行测试时，通过向各服务接口发送相同预设类型的报文，并使得每个服务接口按照配置的统一的预设类型的报文的处理规则处理预设类型的报文，得到反馈报文，并将该反馈报文与标准接口文件进行判定得到测试接口，由此使得各服务接口的处理规则进行统一，无需进行复杂的测试环境的仿真，提高了服务接口测试的测试效率。
55.在一实施例中，在上述步骤300之前，该方法还可以执行如下步骤：
56.s210，基于处理规则，获得测试模块的测试代码。
57.可选地，在本技术实施例中，stm代码开发。可以基于处理规则，开发相关的功能逻辑并根据这些功能逻辑设计测试代码(即stm代码)。具体而言，可以根据处理规则定义测试用例，包括输入参数、预期结果等信息。根据测试用例编写测试代码，包括调用服务接口、发送预设类型的报文、解析服务接口反馈报文等操作。对测试代码进行测试和验证，确保其可以正确地执行测试用例并得到预期结果。
58.在这些可选地实施例中，通过基于处理规则获得测试模块的测试代码，能够将处理规则转化为可执行的代码，进而进行自动化测试，提高测试效率和准确性，降低人工测试的成本和错误率。
59.s220，通过测试代码调用多个服务接口，生成通信代码文件。
60.可选地，在本技术实施例中，需要进行接口适配，具体是将配置完的多个服务接口和开发完成的测试代码进行适配，该阶段主要是stm代码去调用步骤100中生成的协议栈接口函数，例如服务的启动条件接口、服务的停止接口、报文的发送接口以及报文等，从而组成完整的基于some/ip协议的通信代码文件。
61.可选地，在本技术其他设施方式中，还可以根据测试代码和接口标准文件生成通信代码模板，包括发送和接收报文的格式、数据类型、报文id等信息。并根据通信代码模板编写具体的通信代码，包括连接服务接口、发送报文、接收报文、解析报文等操作。随后对通信代码进行测试和验证，确保其可以正确地连接服务接口并进行通信。
62.在这些可选地实施例中，通过测试代码调用多个服务接口，生成通信代码文件，可
以自动生成通信代码，减少手工编写通信代码的工作量，提高开发效率。通过自动化生成测试代码和通信代码文件，可以减少测试过程中的人力成本和错误率。
63.s230，将通信代码文件集成至控制器样件中，生成测试模块。
64.可选地，在本技术实施例中，在得到通信代码文件和测试代码以后，可以进行代码集成，具体可以将测试代码和通信代码文件，集成至相关控制器样件中，得到测试模块。集成方法和步骤依赖于使用的芯片类型和芯片厂家，一般芯片供应商均会提供和指定芯片配套的完整开发环境和集成方法。其中，通信代码文件用于实现测试模块和多个服务接口之间的通信。
65.可选地，在本技术一种可能的实现方式中，可以将通信代码文件添加至控制器样件的代码库中。并根据控制器样件的开发环境，配置通信代码文件的编译、链接等参数。编译、链接控制器样件，生成测试模块。随后对测试模块进行测试和验证，确保其可以正确地连接服务接口并进行通信，执行测试用例并得到预期结果。
66.在这些可选地实施例中，通过自动化生成测试代码和通信代码文件，可以大大提高测试效率，减少人工测试所需的时间和工作量。并且通过基于预先定义的处理规则生成测试代码，可以确保测试的准确性和一致性。在本技术实施例中，通过自动化生成的测试代码和通信代码文件，可以在不同环境下重复使用，以验证控制器的稳定性和可靠性，提高测试的可复用性。
67.在一实施例中，上述步骤300具体可以执行如下步骤：
68.s310，通过测试模块向服务接口发送预设类型的报文。
69.可选地，在本技术一种具体的实施方式中，可以基于集成的测试模块，按照图3的拓扑，开展some/ip服务接口测试。其中，tester(测试电脑)和被测设备(device under test，dut)之间通过一个t1-tx适配器进行连接。dut即集成完毕的测试模块，测试模块上部署了stm代码(即测试代码)和适配完成的some/ip协议栈，stm代码通过some/ip协议栈预留的接口(interfaces)，即通信代码文件调用some/ip协议栈(即多个服务接口)，同时通过图3所示的控制通道(control path)实现预设类型的报文进行传输；在tester上部署了和stm代码适配的测试程序(test program)，测试程序的作用主要有两个：1)通过图3中所示的控制通道(control path)发送/接收预设类型的报文，根据测试需求，控制dut的不同行为；2)通过图3中所示通信通道(communication path)接收dut发出的响应some/ip报文(即反馈报文)，判断dut的some/ip接口，即服务接口实现正确与否。需要理解的是，上述通道为虚拟出来的逻辑通道，非物理通道，一般为不同的传输层端口(port)，但是在应用层，控制通道和通信通道在的实现均由同一测试应用程序来实现，这样测试程序可以做到在发送、接收预设类型的报文的同时，监听dut发送出来的响应some/ip报文进行判断。
70.在这些可选地实施例中，通过测试模块向服务接口发送预设类型的报文，可以验证接口实现的正确性。通过这个步骤，可以检查服务接口是否按照预期处理预设类型的报文，并且能够正确地返回反馈报文。能够帮助开发人员在实现服务接口时发现和解决问题，确保服务接口的正确性和可靠性。此外，通过这个步骤，也可以帮助测试人员对服务接口的功能进行测试，并生成测试报告，为产品质量提供保障。
71.在一实施例中，预设类型包括预设类型和响应类型，上述步骤300具体可以执行如下步骤：
72.s320，通过所述测试模块向所述服务接口发送所述预设类型的报文，使得所述服务接口在接收到所述预设类型的报文的情况下，向所述测试模块发送反馈报文。
73.可选地，在本技术一种可能的实现方式中，可以在测试模块中按照处理规则编写发送请求的代码，包括构建请求报文的数据格式、填充报文内容以及发送报文的方法等。
74.可选地，在本技术实施例中，在服务接口接收到预设类型的报文后，需要根据处理规则中定义的规则对请求报文进行解析和处理，并根据处理结果生成对应的响应类型的报文即反馈报文。这个过程需要在服务接口的代码中实现。
75.在这些可选地实施例中，通过设置预设类型的报文可以帮助进行自动化测试，确保设备在收到预设类型的报文后能够正确响应相应的响应报文。通过模拟发送各种类型的请求报文和对应的响应报文，可以验证设备在不同场景下的稳定性、功能是否符合预期，并且可以快速发现潜在的问题和缺陷，提高产品质量。同时，自动化测试可以大大减少人工测试的时间和成本。
76.在一实施例中，测试模块用于实现如下功能：识别预设类型的报文；对预设类型的报文进行响应；调用多个服务接口。
77.可选地，在本技术实施例中，可以基于处理规则，设计开发测试模块的相关功能逻辑。具体而言，测试模块必须支持识别stm规范(即处理规则)中定义的所有预设类型的报文；测试模块接收到特定的预设类型的报文后，必须支持对该报文的回复。
78.在这些可选地实施例中，本技术的测试模块的功能逻辑是统一定义的，不需要依赖车辆的实际功能需求，不同车型、不同服务或者是同一服务的不同接口均统一为相同的功能逻辑(即统一的stm代码)，使得测试模块具有可复用性，提高了测试效率。
79.在一实施例中，上述步骤s400，具体可以执行如下步骤：
80.s410，通过所述测试模块接收所述服务接口发送的所述反馈报文，所述反馈报文由所述服务接口按照所述处理规则配置的填充规则进行填充。
81.可选地，在本技术实施例中，反馈报文即为服务接口按照处理规则生成的。在设计测试模块的功能逻辑时，测试模块还需要必须支持调用配置完成的多个服务接口的接口代码；测试模块接收到特定控制报文后，必须按照stm规范定义的规则发送some/ip报文(即反馈报文)；测试模块必须支持发送的some/ip报文的payload内容无需和实际功能逻辑相关，而应按照stm规范(即处理规则)定义的填充规则进行填充。其中，payload(负载)是通信协议中承载实际数据的部分，它包含了需要在通信过程中传输、处理或存储的有效信息。
82.在这些可选地实施例中，本技术的测试模块的功能逻辑是统一定义的，不需要依赖车辆的实际功能需求，不同车型、不同服务或者是同一服务的不同接口均统一为相同的功能逻辑(即统一的stm代码)，使得测试模块具有可复用性，提高了测试效率。
83.在一实施例中，预设类型包括如下至少一种：
84.开始类型，开始类型用于记录测试开始的时间戳，以及调用服务接口的标识；
85.结束类型，结束类型用于记录测试结束的时间戳，以及触发停止发送报文；
86.触发类型，触发类型用于触发服务接口的通知报文；
87.停止类型，停止类型用于触发停止发送反馈报文；
88.转发类型，转发类型用于触发服务接口转发报文；
89.获取类型，获取类型用于获取服务接口的版本号。
90.可选地，在本技术一种可能的实现方式中，共定义了starttest、starttestack、endtest、endtestack、triggernotification、triggernotificationack、stoptriggernotification、stoptriggernotificationack、forwardffrequest、forwardffrequestack、sendffrequest、getversion、getversionack等预设类型，同时定义了每类预设类型的作用，并针对测试模块接收到预设类型的报文后应采取的行为和表现提出了具体需求，其中后缀为ack的预设类型均为同名预设类型的报文的响应，表示对该预设类型的报文的执行结果。需要理解的是，本技术并不限制预设类型的具体定义，可以根据实际需要进行自定义，本技术仅示例性的进行说明。
91.具体而言，starttest(即开始类型)的作用是表明测试起始点，可用于记录测试开始时间戳的参考。测试模块需要在接收到starttest后需主动提供所有待测试服务(offerservice)对应的服务接口，同时发送starttestack响应报文，反馈该服务原语执行结果(result identifier，rid)，响应报文不携带任何参数。
92.endtest(即结束类型)表明当前测试终止，可用于记录测试结束时间戳的参考，测试模块在接收到endtest服务原语后，需要重置soa，同时停止所有活动的服务原语。测试模块还应发送endtestack响应报文。
93.triggernotification(即触发类型)的作用表示测试模块应触发特定的通知型报文，测试模块在接收到该类型的报文后应根据报文的parameter(参数值)里携带的message id(serviceid及methodid)触发相应some/ip通知类型报文(即通知报文)，通知报文周期为1s，直到接收到stoptriggernotification(即停止类型)或者endtest类型的报文或者该通知订阅超时。测试模块还应发送triggernotificationack响应报文。
94.stoptriggernotification(即停止类型)的作用表示测试模块应停止发送特定的通知型报文，测试模块接收到该类型的报文后应根据parameter里携带的message id(serviceid及methodid)停止发送相应的通知报文，同时发送stoptriggernotificationack响应报文。
95.forwardffrequest(即转发类型)的作用表示测试模块需要将ff request请求报文进行转发，控制器接收到该类型的报文后应将后续接收到的有效ff报文通过sendffrequest类型的报文发送出来，且该报文对应的message id(serviceid及methodid)。
96.sendffrequest类型的作用是测试模块在接收到forwardffrequest的前提下，后续将接收到的所有支持的ff请求会通过sendffrequest进行发送。
97.getversion(即获取类型)的作用是获取当前soa的协议版本，收到该类型的报文后，测试模块应返回getversionack响应报文，在parameter中携带当前支持的服务接口的版本号。
98.在一实施例中，预设类型的报文格式包括如下至少一项：
99.服务标识位，服务标识位用于描述服务接口的标识编号；
100.报文标识位，报文标识位用于描述预设类型的编号；
101.长度位，长度位用于描述报文的字节数量；
102.结果位，结果位用于描述对预设类型的报文的处理结果；
103.补充位，补充位用于描述预设类型的报文的补充描述信息
104.可选地，在本技术实施例中，预设类型的报文用于控制服务的启动或停止、触发通知、接收请求反馈等，传输层采用用户数据报协议(user datagram protocol，udp)，端口号固定采用20001。报文的报头格式及定义可参考《autosar testability protocol and service primitives》协议中消息格式定义，报头之后的payload内容根据预设类型的不同而定义不同的格式。
105.具体而言，如图4所示，图4为本技术预设类型的报文的具体报文格式，其中，报文格式可以包括sid(即服务标识位)：service id，2字节，表示当前soa的服务id，默认固定为0xfff0；evb：event bit，1比特，该字段置位，表示当前报文的预设类型为event；gid：group id，7比特，组标识，根据测试目的将预设类型的报文分为不同组，其中0表示通用类服务原语，1表示接口测试类，其中starttest、starttestack、endtest、endtestack、getversion、getversionack均属于通用类，其余类型属于接口测试类；pid(即报文标识位)：primitive id，8比特，服务原语标识，不同pid对应不同服务原语，具体为：0x01表示starttest和starttestack；0x02表示endtest和endtestack；0x03表示triggernotification和triggernotificationack；0x04表示stoptriggernotification和stoptriggernotificationack；0x05表示forwardffrequest和forwardffrequestack；0x06表示sendffrequest；0x07表示getversion和getversionack；len(即长度位)：4字节，长度字段，代表从该字段之后的报文字节数，不包括长度字段本身；tid：type id，8比特，预设类型的标识符，0x00表示预设类型，0x01表示回复类型，0x02表示事件类型；rid(即结果位)：result id，8比特，结果标识符，表明对应预设类型报文的执行结果，其中0x00表示预设类型报文处理成功，0x01表示处理失败；parameters(即补充位)：表示预设类型报文携带的补充描述信息，预设类型不同，其携带parameters不同，其中starttest、starttestack、endtest、endtestack、getversion、triggernotificationack、stoptriggernotificationack、forwardffrequest、forwardffrequestack不携带任何参数，其余类型控制报文携带被测服务的服务信息。
106.在这些可选地实施例中，通过对报文格式进行统一定义的，不需要依赖车辆的实际功能需求，不同车型、不同服务或者是同一服务的不同接口均统一为相同的报文格式，将所有触发类报文的触发条件进行了简化和统一，即所有的触发条件均简化为接收到指定的控制报文，且统一了报文格式定义使得整个测试环境具有可复用性，提高了测试效率。
107.在一实施例中，在上述步骤100之前，还可以具体执行如下步骤：
108.s600，获取每个服务接口的接口信息和各个服务接口之间的依赖关系，接口信息包括服务接口的类型、服务接口传输的数据内容和数据格式。
109.可选地，在本技术实施例中，针对每个服务接口，可以通过查阅相关文档、规范或代码，以获取接口类型的定义。具体可以包括方法、参数、返回类型等信息。并分析每个服务接口传输的数据内容和数据格式。确定数据的字段、数据类型、数据格式等信息。通过对系统或接口代码的分析，了解各个服务接口之间的依赖关系。这可以包括调用关系、数据依赖、控制流程等。分析接口代码中的函数调用、接口调用、消息传递等方式来确定依赖关系。
110.在这些可选地实施例中，通过获取每个服务接口的类型、参数、返回值等详细信息，可以帮助开发人员和测试人员准确理解接口的功能和使用方式，避免误解和错误的使用。通过了解服务接口传输的数据内容和数据格式，可以确保在接口调用过程中数据的正
确性和一致性。开发人员可以根据数据格式要求正确地构造和解析数据，以保证数据的正确传输和处理。并通过分析服务接口之间的依赖关系可以帮助开发人员和测试人员了解接口之间的调用顺序、依赖关系和影响范围。这有助于编写正确的代码和测试用例，避免因依赖关系问题引发的错误和故障。
111.s700，基于各个服务接口对应的接口信息和各个服务接口之间的依赖关系，生成接口标准文件。
112.可选地，在本技术一种可能的实现方式中，可以根据接口信息和依赖关系，编写接口标准文件的文档内容。在文档中详细描述每个服务接口的功能、参数、数据格式、使用方法等信息，并说明依赖关系对接口的影响和限制。接口标准文件的生成有助于统一对接口的理解、规范接口的使用，以及确保各个服务接口之间的协调和兼容性。
113.在这些可选地实施例中，接口标准文件作为参考文档，可以为开发人员提供接口调用的指导和规范。测试人员可以根据接口标准文件编写测试用例，验证接口的正确性和一致性。这有助于提高开发和测试工作的效率和质量。并通过明确定义接口的数据格式和依赖关系，接口标准文件可以确保不同服务接口之间的兼容性和集成性。开发人员可以根据接口标准文件编写代码，保证接口之间的数据传输和处理的一致性和正确性，从而有助于提高开发和测试过程的准确性、一致性和效率，为接口的正确使用、兼容性和可靠性提供了基础和指导。
114.可选地，在本技术实施例中，为满足测试开发需求，本技术对some/ip协议包括的所有服务接口类型对应的软件组件(software comopnent，swc)逻辑进行了统一的定义，具体而言，请求-响应方式(request and response method，rr method)类型：测试模块在接收到合法的request(请求)之后，应当在响应的response中将所有参数置为合法范围内的最大值，如果参数为动态长度，应按照其最大合法长度进行填充。ff method类型：测试模块在接收到forwardffrequest预设类型的报文后，应当将之后接收到的所有ff method请求id通过指定sendffreques预设类型的报文发出。notification(通知)类型：测试模块在接收到指定预设类型的报文(triggernotification)后，应根据service id和method id支持触发相应的notification发送，周期为100ms，其携带的所有参数应置为合法范围内的最大值。如果参数为动态长度，应按照其最大合法长度进行填充。
115.在这些可选地实施例中，将服务接口配置阶段的工作产物作为测试对象，从整个控制器开发流程中独立出来，提前暴露该阶段的问题，方便相关问题定位。将各场景的触发条件统一为预设类型的报文，解决了测试环境对控制器外设设备或仿真设备的复杂需求，使得触发环境具有可复用性。
116.图5示出了本技术另一个实施例提供的服务接口测试装置的结构示意图，为了便于说明，仅示出了与本技术实施例相关的部分。
117.参照图5，服务接口测试装置可以包括：
118.第一配置模块501，用于基于预获取的接口标准文件配置多个服务接口；
119.第二配置模块502，用于配置多个服务接口的处理规则，处理规则是对多个服务接口收发的预设类型的报文进行处理的规则；
120.发送模块503，用于向服务接口发送预设类型的报文；
121.获取模块504，用于获取服务接口的反馈报文，反馈报文是服务接口按照处理规则
对接收到的预设类型的报文进行处理得到的；
122.判定模块505，用于以接口标准文件为参照，对反馈报文进行判定，得到测试结果。
123.在一实施例中，服务接口测试装置还可以包括：
124.第二获取模块，用于基于处理规则，获得测试模块的测试代码；
125.第一生成模块，用于通过测试代码调用多个服务接口，生成通信代码文件；
126.集成模块，用于将通信代码文件集成至控制器样件中，生成测试模块。
127.在一实施例中，发送模块503可以包括：
128.第一发送子模块，用于通过测试模块向服务接口发送预设类型的报文。
129.在一实施例中，发送模块503还可以包括：
130.第二发送子模块，用于通过所述测试模块向所述服务接口发送所述预设类型的报文，使得所述服务接口在接收到所述预设类型的报文的情况下，向所述测试模块发送所述反馈报文。
131.在一实施例中，测试模块用于实现如下功能：
132.识别预设类型的报文；
133.回复预设类型的报文；
134.调用多个服务接口。
135.在一实施例中，获取模块504可以包括：
136.第一获取子模块，用于通过所述测试模块接收所述服务接口发送的所述反馈报文，所述反馈报文由所述服务接口按照所述处理规则配置的填充规则进行填充。
137.在一实施例中，预设类型，包括如下至少一种：
138.开始类型，开始类型用于记录测试开始的时间戳，以及调用服务接口的标识；
139.结束类型，结束类型用于记录测试结束的时间戳，以及触发停止发送报文；
140.触发类型，触发类型用于触发服务接口的通知报文；
141.停止类型，停止类型用于触发停止发送反馈报文；
142.转发类型，转发类型用于触发服务接口转发报文；
143.获取类型，获取类型用于获取待测试服务接口的版本号。
144.在一实施例中，预设类型的报文格式包括如下至少一项：
145.服务标识位，服务标识位用于描述服务接口的标识编号；
146.报文标识位，报文标识位用于描述预设类型的编号；
147.长度位，长度位用于描述报文的字节数量；
148.结果位，结果位用于描述对预设类型的报文的处理结果；
149.补充位，补充位用于描述预设类型的报文的补充描述信息。
150.在一实施例中，服务接口测试装置还可以包括：
151.第三获取模块，用于获取每个服务接口的接口信息和各个服务接口之间的依赖关系，接口信息包括服务接口的类型、服务接口传输的数据内容和数据格式；
152.第二生成模块，用于基于各个服务接口对应的接口信息和各个服务接口之间的依赖关系，生成接口标准文件。
153.需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，与本技术方法实施例基于同一构思，是与上述电池热失控预警方法对应的装置，上述方法实施例中所有
实现方式均适用于该装置的实施例中，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。
154.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本技术的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
155.图6示出了本技术实施例提供的电子设备的硬件结构示意图。
156.设备可以包括处理器601以及存储有程序指令的存储器602。
157.处理器601执行程序时实现上述任意各个方法实施例中的步骤。
158.示例性的，程序可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器602中，并由处理器601执行，以完成本技术。一个或多个模块/单元可以是能够完成特定功能的一系列程序指令段，该指令段用于描述程序在设备中的执行过程。
159.具体地，上述处理器601可以包括中央处理器(cpu)，或者特定集成电路(application specific integrated circuit，asic)，或者可以被配置成实施本技术实施例的一个或多个集成电路。
160.存储器602可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器602可包括硬盘驱动器(hard disk drive，hdd)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(universal serial bus，usb)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器602可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器602可在综合网关容灾设备的内部或外部。在特定实施例中，存储器602是非易失性固态存储器。
161.存储器可包括只读存储器(rom)，随机存取存储器(ram)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本公开的一方面的方法所描述的操作。
162.处理器601通过读取并执行存储器602中存储的程序指令，以实现上述实施例中的任意一种方法。
163.在一个示例中，电子设备还可包括通信接口603和总线610。其中，处理器601、存储器602、通信接口603通过总线610连接并完成相互间的通信。
164.通信接口603，主要用于实现本技术实施例中各模块、装置、单元和/或设备之间的通信。
165.总线610包括硬件、软件或两者，将在线数据流量计费设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(agp)或其他图形总线、增强工业标准架构(eisa)总线、前端总线(fsb)、超传输(ht)互连、工业标准架构(isa)总线、无限带宽互连、
低引脚数(lpc)总线、存储器总线、微信道架构(mca)总线、外围组件互连(pci)总线、pci-express(pci-x)总线、串行高级技术附件(sata)总线、视频电子标准协会局部(vlb)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线610可包括一个或多个总线。尽管本技术实施例描述和示出了特定的总线，但本技术考虑任何合适的总线或互连。
166.另外，结合上述实施例中的方法，本技术实施例可提供一种存储介质来实现。该存储介质上存储有程序指令；该程序指令被处理器执行时实现上述实施例中的任意一种方法。
167.本技术实施例另提供了一种芯片，芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行程序或指令，实现上述方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
168.应理解，本技术实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。
169.本技术实施例提供一种计算机程序产品，该程序产品被存储在存储介质中，该程序产品被至少一个处理器执行以实现如上述方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
170.需要明确的是，本技术并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本技术的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本技术的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。
171.以上的结构框图中所示的功能模块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(asic)、适当的固件、插件、功能卡等等。当以软件方式实现时，本技术的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、rom、闪存、可擦除rom(erom)、软盘、cd-rom、光盘、硬盘、光纤介质、射频(rf)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网格被下载。
172.还需要说明的是，本技术中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本技术不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。
173.上面参考根据本公开的实施例的方法、装置(系统)和程序产品的流程图和/或框图描述了本公开的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图
和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。
174.以上，仅为本技术的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本技术的保护范围之内。

技术特征：
1.一种服务接口测试方法，其特征在于，所述方法包括：基于预获取的接口标准文件配置多个服务接口；配置所述多个服务接口的处理规则，所述处理规则是对所述多个服务接口收发的预设类型的报文进行处理的规则；向所述服务接口发送所述预设类型的报文；获取所述服务接口的反馈报文，所述反馈报文是所述服务接口按照所述处理规则对接收到的所述预设类型的报文进行处理得到的；以所述接口标准文件为参照，对所述反馈报文进行判定，得到测试结果。2.根据权利要求1所述的方法，其特征在于，在所述向所述服务接口发送所述预设类型的报文之前，所述方法还包括：基于所述处理规则，获得测试模块的测试代码；通过所述测试代码调用所述多个服务接口，生成通信代码文件；将所述通信代码文件集成至控制器样件中，生成所述测试模块；所述向所述服务接口发送所述预设类型的报文，包括：通过所述测试模块向所述服务接口发送所述预设类型的报文。3.根据权利要求2所述的方法，其特征在于，所述向所述服务接口发送所述预设类型的报文，包括：通过所述测试模块向所述服务接口发送所述预设类型的报文，使得所述服务接口在接收到所述预设类型的报文的情况下，向所述测试模块发送所述反馈报文。4.根据权利要求2所述的方法，其特征在于，所述获取所述服务接口的反馈报文，包括：通过所述测试模块接收所述服务接口发送的所述反馈报文，所述反馈报文由所述服务接口按照所述处理规则配置的填充规则进行填充。5.根据权利要求2所述的方法，其特征在于，所述测试模块用于实现如下功能：识别所述预设类型的报文；回复所述预设类型的报文；调用所述多个服务接口。6.根据权利要求1所述的方法，其特征在于，所述预设类型包括如下至少一种：开始类型，所述开始类型用于记录测试开始的时间戳，以及调用所述服务接口的标识；结束类型，所述结束类型用于记录测试结束的时间戳，以及触发停止发送报文；触发类型，所述触发类型用于触发所述服务接口的通知报文；停止类型，所述停止类型用于触发停止发送所述反馈报文；转发类型，所述转发类型用于触发所述服务接口转发报文；获取类型，所述获取类型用于获取所述服务接口的版本号。7.根据权利要求6所述的方法，其特征在于，所述预设类型的报文格式包括如下至少一项：服务标识位，所述服务标识位用于描述所述服务接口的标识编号；报文标识位，所述报文标识位用于描述所述预设类型的编号；长度位，所述长度位用于描述报文的字节数量；结果位，所述结果位用于描述对所述预设类型的报文的处理结果；
补充位，所述补充位用于描述所述预设类型的报文的补充描述信息。8.根据权利要求1所述的方法，其特征在于，在所述基于预获取的接口标准文件配置多个服务接口之前，所述方法还包括：获取每个所述服务接口的接口信息和各个所述服务接口之间的依赖关系，所述接口信息包括所述服务接口的类型、所述服务接口传输的数据内容和数据格式；基于各个所述服务接口对应的接口信息和各个所述服务接口之间的依赖关系，生成所述接口标准文件。9.一种服务接口测试装置，其特征在于，所述装置包括：第一配置模块，用于基于预获取的接口标准文件配置多个服务接口；第二配置模块，用于配置所述多个服务接口的处理规则，所述处理规则是对所述多个服务接口收发的预设类型的报文进行处理的规则；发送模块，用于向所述服务接口发送所述预设类型的报文；获取模块，用于获取所述服务接口的反馈报文，所述反馈报文是所述服务接口按照所述处理规则对接收到的所述预设类型的报文进行处理得到的；判定模块，用于以所述接口标准文件为参照，对所述反馈报文进行判定，得到测试结果。10.一种电子设备，其特征在于，所述设备包括：处理器以及存储有计算机程序指令的存储器；所述处理器执行所述计算机程序指令时实现如权利要求1-8任意一项所述的服务接口测试方法。

技术总结
本申请提供了一种服务接口测试方法、装置及设备，通过基于预获取的接口标准文件配置多个服务接口；配置多个服务接口的处理规则，处理规则是对多个服务接口收发的预设类型的报文进行处理的规则；向服务接口发送预设类型的报文；获取服务接口的反馈报文，反馈报文是服务接口按照处理规则对接收到的预设类型的报文进行处理得到的；以接口标准文件为参照，对反馈报文进行判定，得到测试结果。本申请实施例能够提高测试服务接口的测试效率。例能够提高测试服务接口的测试效率。例能够提高测试服务接口的测试效率。


技术研发人员：冯军
受保护的技术使用者：北京经纬恒润科技股份有限公司
技术研发日：2023.07.12
技术公布日：2023/10/11