Service interface test method, device and equipment

Abstract

The application provides a service interface test method, device and equipment. The method comprises the following steps: configuring a plurality of service interfaces based on a pre-acquired interface standard file; configuring a processing rule of the plurality of service interfaces, wherein the processing rule is a rule for processing a preset type of message received and sent by the plurality of service interfaces; sending the preset type of message to the service interface; acquiring a feedback message of the service interface, wherein the feedback message is obtained by processing the received preset type of message according to the processing rule; and determining the feedback message with reference to the interface standard file to obtain a test result. The embodiment of the application can improve the test efficiency of the test service interface.

Description

Technical Field

[0001] This application relates to the field of vehicle testing technology, and in particular to a service interface testing method, apparatus and equipment. Background Technology

[0002] With the increasing application of Service-Oriented Architecture (SOA) in the automotive field, the implementation of vehicle functions increasingly relies on the composition and mutual scheduling of various sub-functional modules (referred to as services). The superiority of services (reusability, loose coupling, etc.) depends on the consistency of communication node protocols and the correctness and stability of service interfaces. Simplified Service-Oriented Middleware over IP (SOME / IP), as a communication middleware, is one of the mechanisms available for implementing service-based communication.

[0003] Currently, communication between services is based on the SOME / IP protocol through a communication controller. The correctness of the service interface mainly depends on the direct judgment of the controller's network packets. The services provided by the controller include trigger-type packets. For trigger-type interfaces / packets, if the trigger conditions are complex and difficult to simulate, the interface is difficult to test at the single-component stage. As a result, testing of the interface / packet can only be carried out after bench integration or even vehicle integration. Once the trigger conditions change, the relevant trigger environment needs to be redeveloped and adapted to meet the test conditions, which is not reusable and results in low testing efficiency. Summary of the Invention

[0004] This application provides a service interface testing method, apparatus, and equipment that can improve testing efficiency.

[0005] In a first aspect, embodiments of this application provide a service interface testing method, the method comprising:

[0006] Configure multiple service interfaces based on the pre-obtained interface standard files;

[0007] Configure processing rules for multiple service interfaces. The processing rules are the rules for processing preset types of messages sent and received by multiple service interfaces.

[0008] Send a message of a preset type to the service interface;

[0009] Get the feedback message from the service interface. The feedback message is obtained by the service interface processing the received message of a preset type according to the processing rules.

[0010] The feedback messages are evaluated using the interface standard documents as a reference to obtain the test results.

[0011] Secondly, this application provides a service interface testing apparatus, the apparatus comprising:

[0012] The first configuration module is used to configure multiple service interfaces based on the pre-acquired interface standard file;

[0013] The second configuration module is used to configure the processing rules for multiple service interfaces. The processing rules are the rules for processing preset types of messages sent and received by multiple service interfaces.

[0014] The sending module is used to send messages of a preset type to the service interface;

[0015] The acquisition module is used to acquire the feedback messages of the service interface. The feedback messages are obtained by the service interface processing the received messages of a preset type according to the processing rules.

[0016] The judgment module is used to judge the feedback messages with reference to the interface standard documents and obtain the test results.

[0017] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions;

[0018] When the processor executes computer program instructions, it implements the service interface testing method as described in any of the embodiments of the first aspect.

[0019] Fourthly, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the service interface testing method as described in any of the embodiments of the first aspect.

[0020] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to execute a service interface testing method as described in any of the embodiments of the first aspect above.

[0021] In a service interface testing method, apparatus, and device provided in this application embodiment, multiple service interfaces are configured based on a pre-acquired interface standard file; processing rules for the multiple service interfaces are configured, which are rules for processing preset type messages sent and received by the multiple service interfaces; preset type messages are sent to the service interfaces; feedback messages from the service interfaces are obtained, which are obtained by the service interfaces processing the received preset type messages according to the processing rules; and the feedback messages are judged with reference to the interface standard file to obtain the test results. Through the above method, by configuring unified preset type processing rules for multiple service interfaces, when testing multiple service interfaces, by sending the same preset type messages to each service interface, feedback messages after each service interface processes the preset type messages according to the processing rules can be obtained. Subsequently, the feedback messages can be compared with the standard interface file to obtain the test results. In the above method, since the processing methods of multiple service interfaces are uniformly configured through processing rules, there is no need for complex test environment simulation, thus improving the testing efficiency of service interface testing. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of the mainstream development process of communication controllers based on the SOME / IP protocol in existing technologies;

[0024] Figure 2 This is a flowchart illustrating a service interface testing method provided in one embodiment of this application;

[0025] Figure 3 This is a schematic diagram of the topology of a test module provided in one embodiment of this application;

[0026] Figure 4 This is a schematic diagram of a message format of a preset type of message provided in one embodiment of this application;

[0027] Figure 5 This is a schematic diagram of the structure of a service interface testing device provided in an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0029] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0030] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0031] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0032] SOME / IP, as a communication middleware, is one of the mechanisms for achieving service-based communication. The AUTOSAR standard "AUTOSAR_PRS_SOMEIP Protocol" (hereinafter referred to as "PRS_SOMEIP") and "AUTOSAR_PRS_SOMEIP Service Discovery Protocol" (hereinafter referred to as "PRS_SD") define its message format, data serialization rules, and service discovery mechanisms. Currently, communication testing based on the SOME / IP protocol in the automotive electronics field is mainly divided into the following categories: 1) "SOME / IP-SERVER" testing (hereinafter referred to as SERVER testing) based on the OPEN Alliance TC8 specification; 2) "SOME / IP-ETS (Enhanced Testability Service)" testing (hereinafter referred to as ETS testing) based on the OPEN Alliance TC8 specification (hereinafter referred to as TC8) to verify the implementation of the SOME / IP protocol stack and its consistency with the AUTOSAR standard; 3) System testing or functional testing based on the test specifications customized by each OEM after the prototype development and integration is completed (hereinafter referred to as integration testing).

[0033] First, the mainstream development process for communication controllers based on the SOME / IP protocol is as follows: Figure 1 As shown, for the three test categories mentioned above, the ETS test is a test of the consistency of the SOME / IP protocol stack. It can only verify the correctness of the protocol stack's implementation of the complete protocol mechanism defined in "PRS_SOMEIP" and "PRS_SD". In actual communication services, the interface configuration provided by the SOME / IP protocol stack cannot be verified. Figure 1 The work done in phase S21 cannot be verified. Server testing and integration testing require the completion of controller application functional logic development and protocol stack adaptation (corresponding to...) Figure 1 The process can only begin after steps S22, S31, and S32 are completed. For services with complex logic and numerous interfaces, the development time for the Software Component (SWC) will be longer (corresponding to step S22), and the exposure of service interface problems will be relatively delayed. Currently, there is a lack of communication testing methods and testing procedures that simplify and unify the functional logic, eliminate the dependency between protocol stack configuration testing and actual functional logic development, enable early testing of service interfaces under specific communication scenarios, discover problems in advance, reduce the coupling between different development stages, and facilitate problem localization in subsequent testing stages.

[0034] Secondly, the correctness of service interfaces primarily depends on the direct judgment of controller network packets. The services provided by the controller may include the following types of interfaces: 1) Trigger-type: packets can only be sent if specific trigger conditions are met; 2) FF (Fire and Forget) type: the controller does not need to send a response packet after receiving an external packet request. For trigger-type interfaces / packets, if the trigger conditions are complex and difficult to simulate, the interface is difficult to test in the single-component stage. Either external simulation equipment is needed to simulate the trigger conditions, or testing can only be carried out after bench integration or even vehicle integration, which also suffers from delayed problem exposure. Once the trigger conditions change, the relevant trigger environment needs to be redeveloped and adapted to meet the test conditions, lacking reusability. For FF type interfaces / packets, since the controller does not need to respond, it is impossible to know whether the controller has correctly received and processed request packets sent by other controllers. Currently, there is a lack of a testing method that defines a unified trigger environment and processing logic for trigger-type and FF type packets, allowing testing of trigger-type and FF type packets in the early stages of controller development.

[0035] To address the problems of the prior art, embodiments of this application provide a service interface testing method, apparatus, and device. The service interface testing method provided in this application embodiment will be described first below.

[0036] Figure 2 A flowchart illustrating a service interface testing method provided in one embodiment of this application is shown. Figure 2 As shown, the method may specifically include the following steps:

[0037] S100 configures multiple service interfaces based on pre-acquired interface standard files.

[0038] Optionally, in this embodiment, the service interface may be an in-vehicle service interface. The interface standard file may include the service interface type of each service, the specific data content and format transmitted by the service interface, the deployment status of the service on each communication node, and the startup sequence of each service (such as startup time, lifecycle, and other parameters).

[0039] Optionally, in one possible implementation of this application, appropriate tools or programming languages ​​can be used to configure multiple service interfaces according to the interface structure and message format defined in the interface standard file. Specifically, before testing, the interface standard file of the system under test can be obtained in advance, and various information of the service interfaces provided by the system can be determined based on the interface standard file, including service name, method name, parameter type, return value type, etc. It should be noted that before testing, the interface standard file needs to be parsed, and the interface information of the parsed service interfaces needs to be used to configure multiple service interfaces in the test system.

[0040] Optionally, in this embodiment, the SOME / IP protocol stack (i.e., a collection of multiple service interfaces) can be configured based on the interface standard file to obtain SOME / IP protocol stack interface code consistent with the interface standard file. The configuration includes the service identifier, major version number, minor version number, data transmission serialization rules (such as endianness and whether memory alignment is used), and service startup sequence for all services within the vehicle system. Specifically, this can be accomplished using a specific protocol stack configuration tool. After completing all configurations in the tool, the corresponding code interface file can be automatically generated for subsequent service interface calls.

[0041] Alternatively, in another possible implementation of this application, when configuring multiple service interfaces based on a pre-obtained interface standard file, the configuration needs to be performed according to the service interfaces and methods defined in the standard file. For example, the configuration tool provides an interface that allows users to select the service interfaces and methods defined in the interface standard file and assign them unique identifiers (Service ID and Method ID). Then, users can bind these identifiers to the corresponding implementation code or protocol stack. Specifically, some initialization functions can be implemented in the code or protocol stack to bind the identifiers to the corresponding implementation functions. It is important to note that when configuring multiple service interfaces, the mutual influence between them needs to be considered. If multiple service interfaces use the same protocol stack or share the same hardware resources, then reasonable resource allocation and scheduling are required to avoid resource contention and conflicts. Furthermore, when configuring multiple service interfaces, performance and security factors also need to be considered to ensure that the system can operate normally and is not attacked.

[0042] S200 configures processing rules for multiple service interfaces. These processing rules are rules for processing preset types of messages sent and received by multiple service interfaces.

[0043] Optionally, in this embodiment, after configuring the service interface, it is also necessary to define corresponding processing rules for each service interface. The processing rules are rules for processing preset types of messages sent and received by the service interface. For example, when testing a service interface, it is necessary to send a specific message (i.e., a message of a preset type) and check whether the received response meets expectations. This specific message and the expected result of the response are the contents defined in the processing rules.

[0044] Optionally, in this embodiment, the processing rules need to be designed and developed. The specific design logic can be to simplify and unify the triggering conditions for all trigger-type messages, that is, all triggering conditions are simplified to receiving a specified control message, and the message format definition is unified; the processing logic of applications corresponding to various service interfaces is also unified. The design output is the processing rules. In one possible approach of this application, the design of the processing rules can be viewed as the design and development of a Service interface Testability Module (STM), and the processing rules are the STM specification.

[0045] Optionally, in one possible implementation of this application, configuring multiple service interfaces can begin by defining processing rules. These rules define the processing rules for each service interface when sending and receiving predefined types of messages, including how to parse the messages, how to process the data in the messages, and how to generate response messages. Based on the defined processing rules, corresponding processing rule scripts are written. These scripts are typically written in a specific programming language to implement the specific logic within the processing rules. Subsequently, the processing rule script path is configured in the test system so that the test system can correctly load the processing rule scripts. Then, the processing rules for each service interface are configured in the test system so that the test system can process the predefined types of messages sent and received by each service interface according to the predefined processing rules. It should be noted that the configuration methods for different test systems and service interfaces may differ.

[0046] S300 sends a message of a preset type to the service interface.

[0047] Optionally, in this embodiment, once the service interface and processing rules are configured, preset types of messages can be sent to the service interface of the system under test using testing tools or written test scripts. These preset types of messages can be defined according to the services and methods defined in the processing rules and configured accordingly. Specifically, communication parameters, such as baud rate and interface, can be configured first. The corresponding service interface module can be opened and connected to the corresponding testing tool. The corresponding service interface can be selected, and the corresponding preset type message can be created. The preset type message can then be sent to the corresponding service interface.

[0048] S400: Obtain the feedback message from the service interface. The feedback message is obtained by the service interface processing the received message of a preset type according to the processing rules.

[0049] Optionally, in this embodiment, after sending the message, the testing tool or test script needs to receive the response message returned by the service interface of the system under test, and parse and process the response message. The processing result is the feedback message obtained from the service interface, including the response result, response time, response code, etc. The corresponding message is the response result of the service interface processing the message of the preset type according to the processing rules. Specifically, according to the processing rules configured above, after receiving the message of the preset type, the service interface will process it according to the rules and generate a response message. Testers can obtain the feedback message by listening to the network and obtaining the response message sent by the service interface. Generally, the response message will carry the result of the service interface processing and related information.

[0050] The S500 uses the interface standard document as a reference to judge the feedback message and obtain the test result.

[0051] Optionally, in one possible implementation of this application, appropriate testing tools or programming languages ​​can be used to judge the feedback messages of the service interface with reference to the interface standard document, thereby obtaining the test results. For example, corresponding test scripts or test programs can be written to automate the execution of test cases, and the expected results and actual results can be compared and judged to determine whether the test results meet expectations. If the test results are consistent with the expected results, the test passes; if they are inconsistent, further analysis and debugging are required.

[0052] Optionally, in this embodiment, the service interfaces to be tested can be determined based on the interface standard document and testing requirements. Preset message types are used as test cases. Expected results are defined for each test case according to processing rules. Expected results should include the corresponding feedback message and the judgment criteria for the feedback message. Then, testing tools or automated scripts are used to send test cases to the service interfaces. The feedback messages from the service interfaces are obtained and compared with the expected results to determine whether the test cases pass. Specific judgment criteria depend on the defined expected results and may include comparing field values, status codes, etc., in the feedback messages. The test results are summarized to generate a test report. The test report should include the number of passed test cases, the number of failed test cases, and the reasons for failure. It should be noted that the testing methods and processes will differ for different interface standard documents and testing requirements. Therefore, before conducting service interface testing, corresponding test plans and test cases need to be developed.

[0053] Optionally, in one specific embodiment of this application, a test program can be designed. The design logic for the SOME / IP interface test is as follows: the purpose of the SOME / IP interface test is to check whether the configured multiple service interfaces are consistent with the interface standard file design. The objects checked include: service representation (ID), service interface types, service major version number, service minor version number, data transmission serialization rules, service startup sequence, etc. The test program reads the interface standard file, i.e., the SOME / IP service interface description file, and extracts these interface standard files as judgment criteria. The implementation of this reading process is not limited; it can be manually input by testers into the test program, or corresponding code can be developed for the test program to automatically read the corresponding design artifact files to obtain the information under test. After sending a message of a preset type, the test program will respond to the service under test in accordance with the STM specification. Upon receiving the feedback message from the service under test, the test program will extract the service identifier, version number, and other information under test based on the message format. Then, the extracted information under test (i.e., the interface standard file) will be compared. If the two are consistent, the configuration of the corresponding parameter meets the requirements, and the test passes. Otherwise, if the two are inconsistent, it means that the configuration of the parameter in the service interface does not conform to the design, and the test fails.

[0054] In a service interface testing method provided in this application embodiment, multiple service interfaces are configured based on a pre-acquired interface standard file; processing rules for the multiple service interfaces are configured, which are rules for processing preset type messages sent and received by the multiple service interfaces; preset type messages are sent to the service interfaces; feedback messages from the service interfaces are obtained, which are obtained by the service interfaces processing the received preset type messages according to the processing rules; and the feedback messages are judged with reference to the interface standard file to obtain the test result. Through the above method, by configuring a unified preset type processing rule for multiple service interfaces, when testing the service interfaces, the same preset type messages are sent to each service interface, and each service interface processes the preset type messages according to the configured unified preset type message processing rules to obtain feedback messages. These feedback messages are then judged with the standard interface file to obtain the test interface. This unifies the processing rules for each service interface, eliminating the need for complex test environment simulation and improving the testing efficiency of service interfaces.

[0055] In one embodiment, prior to step 300 above, the method may further perform the following steps:

[0056] S210, based on the processing rules, obtains the test code of the test module.

[0057] Optionally, in this embodiment, STM code development involves developing relevant functional logic based on processing rules and designing test code (i.e., STM code) according to this logic. Specifically, test cases can be defined according to the processing rules, including information such as input parameters and expected results. Test code is written based on the test cases, including operations such as calling service interfaces, sending preset types of messages, and parsing service interface feedback messages. The test code is then tested and verified to ensure that it can correctly execute the test cases and obtain the expected results.

[0058] In these alternative embodiments, by obtaining the test code of the test module based on the processing rules, the processing rules can be transformed into executable code, thereby enabling automated testing, improving testing efficiency and accuracy, and reducing the cost and error rate of manual testing.

[0059] S220 generates communication code files by calling multiple service interfaces through test code.

[0060] Optionally, in this embodiment of the application, interface adaptation is required. Specifically, the configured service interfaces and the developed test code are adapted. This stage mainly involves the STM code calling the protocol stack interface functions generated in step 100, such as the service start condition interface, the service stop interface, the message sending interface, and the message, thereby forming a complete communication code file based on the SOME / IP protocol.

[0061] Optionally, in other facility methods of this application, a communication code template can be generated based on test code and interface standard documents, including information such as the format, data type, and message ID of sent and received messages. Specific communication code is then written based on the communication code template, including operations such as connecting to the service interface, sending messages, receiving messages, and parsing messages. The communication code is then tested and verified to ensure that it can correctly connect to the service interface and perform communication.

[0062] In these alternative embodiments, by calling multiple service interfaces through test code to generate communication code files, the communication code can be automatically generated, reducing the workload of manually writing communication code and improving development efficiency. Automating the generation of test code and communication code files can reduce labor costs and error rates during the testing process.

[0063] S230 integrates the communication code file into the controller prototype to generate a test module.

[0064] Optionally, in this embodiment, after obtaining the communication code file and test code, code integration can be performed. Specifically, the test code and communication code file can be integrated into the relevant controller sample to obtain the test module. The integration method and steps depend on the type and manufacturer of the chip used. Generally, chip suppliers provide a complete development environment and integration method compatible with the specified chip. The communication code file is used to implement communication between the test module and multiple service interfaces.

[0065] Optionally, in one possible implementation of this application, the communication code file can be added to the controller sample's code library. The compilation and linking parameters of the communication code file are configured according to the controller sample's development environment. The controller sample is then compiled and linked to generate a test module. The test module is subsequently tested and verified to ensure it can correctly connect to the service interface and communicate, execute test cases, and obtain the expected results.

[0066] In these alternative embodiments, automating the generation of test code and communication code files can significantly improve testing efficiency and reduce the time and workload required for manual testing. Furthermore, generating test code based on predefined processing rules ensures the accuracy and consistency of the tests. In the embodiments of this application, the automatically generated test code and communication code files can be reused in different environments to verify the stability and reliability of the controller, improving test reusability.

[0067] In one embodiment, step 300 above may specifically be performed as follows:

[0068] S310 sends a message of a preset type to the service interface through the test module.

[0069] Optionally, in one specific embodiment of this application, the test can be based on an integrated testing module, according to... Figure 3 The topology is used to conduct SOME / IP service interface testing. The Tester (test computer) and the Device Under Test (DUT) are connected via a T1-Tx adapter. The DUT is the integrated test module, which deploys STM code (i.e., test code) and an adapted SOME / IP protocol stack. The STM code calls the SOME / IP protocol stack (i.e., multiple service interfaces) through the interfaces (communication code files) reserved by the SOME / IP protocol stack. Figure 3 The control path shown enables the transmission of preset message types; a test program adapted to STM code is deployed on the Tester. The test program has two main functions: 1) through... Figure 3 The control path shown sends / receives preset types of messages, controlling different behaviors of the DUT according to test requirements; 2) through Figure 3 The communication path shown receives response SOME / IP messages (i.e., feedback messages) from the DUT and determines whether the DUT's SOME / IP interface, i.e., the service interface, is implemented correctly. It's important to understand that this is a virtual logical channel, not a physical channel, and typically consists of different transport layer ports. However, at the application layer, both the control and communication channels are implemented by the same test application. This allows the test program to simultaneously send and receive preset types of messages while monitoring the SOME / IP response messages sent by the DUT for evaluation.

[0070] In these optional embodiments, the correctness of the interface implementation can be verified by sending preset type messages to the service interface through the test module. This step checks whether the service interface processes the preset type messages as expected and correctly returns feedback messages. This helps developers identify and resolve problems when implementing the service interface, ensuring its correctness and reliability. Furthermore, this step also helps testers test the functionality of the service interface and generate test reports, providing assurance for product quality.

[0071] In one embodiment, the preset type includes a preset type and a response type, and step 300 above can specifically be performed as follows:

[0072] S320, the test module sends a message of the preset type to the service interface, so that the service interface sends a feedback message to the test module upon receiving the message of the preset type.

[0073] Optionally, in one possible implementation of this application, code for sending requests can be written in the test module according to the processing rules, including the data format for constructing the request message, filling in the message content, and the method for sending the message.

[0074] Optionally, in this embodiment, after the service interface receives a message of a preset type, it needs to parse and process the request message according to the rules defined in the processing rules, and generate a corresponding response type message, i.e., a feedback message, based on the processing result. This process needs to be implemented in the code of the service interface.

[0075] In these alternative embodiments, setting preset message types can facilitate automated testing, ensuring that the device correctly responds to the corresponding response messages upon receiving them. By simulating the sending of various types of request messages and corresponding response messages, the stability and functionality of the device under different scenarios can be verified, and potential problems and defects can be quickly identified, improving product quality. Simultaneously, automated testing can significantly reduce the time and cost of manual testing.

[0076] In one embodiment, the testing module is used to perform the following functions: identify messages of a preset type; respond to messages of the preset type; and call multiple service interfaces.

[0077] Optionally, in this embodiment, the relevant functional logic of the test module can be designed and developed based on the processing rules. Specifically, the test module must support the recognition of all preset message types defined in the STM specification (i.e., processing rules); after receiving a specific preset message type, the test module must support the response to that message.

[0078] In these alternative embodiments, the functional logic of the test module of this application is uniformly defined and does not depend on the actual functional requirements of the vehicle. Different vehicle models, different services, or different interfaces of the same service are all unified with the same functional logic (i.e., unified STM code), which makes the test module reusable and improves testing efficiency.

[0079] In one embodiment, step S400 above can specifically be performed as follows:

[0080] S410, the test module receives the feedback message sent by the service interface, and the feedback message is filled by the service interface according to the filling rules configured in the processing rules.

[0081] Optionally, in this embodiment, the feedback message is generated by the service interface according to the processing rules. When designing the functional logic of the test module, the test module must also support calling the interface code of multiple configured service interfaces; after receiving a specific control message, the test module must send a SOME / IP message (i.e., a feedback message) according to the rules defined in the STM specification; the test module must support that the payload content of the sent SOME / IP message does not need to be related to the actual functional logic, but should be filled according to the filling rules defined in the STM specification (i.e., processing rules). Here, the payload is the part of the communication protocol that carries the actual data; it contains valid information that needs to be transmitted, processed, or stored during communication.

[0082] In these alternative embodiments, the functional logic of the test module of this application is uniformly defined and does not depend on the actual functional requirements of the vehicle. Different vehicle models, different services, or different interfaces of the same service are all unified with the same functional logic (i.e., unified STM code), which makes the test module reusable and improves testing efficiency.

[0083] In one embodiment, the preset type includes at least one of the following:

[0084] Start type: The start type is used to record the timestamp of the test start and the identifier of the service interface call;

[0085] The end type is used to record the timestamp of the test's end and to trigger the cessation of message transmission;

[0086] Trigger type: The trigger type is used to trigger the notification message of the service interface;

[0087] Stop type: The stop type is used to trigger a halt to sending feedback messages.

[0088] Forwarding type: The forwarding type is used to trigger the service interface to forward packets;

[0089] Get type: This is used to retrieve the version number of the service interface.

[0090] Optionally, in one possible implementation of this application, a total of preset types are defined, including StartTest, StartTestAck, EndTest, EndTestAck, TriggerNotification, TriggerNotificationAck, StopTriggerNotification, StopTriggerNotificationAck, ForwardFFRequest, ForwardFFRequestAck, SendFFRequest, GetVersion, and GetVersionACK. The function of each preset type is defined, and specific requirements are proposed for the behavior and performance that the test module should take after receiving a message of a preset type. Preset types ending in Ack are responses to messages of the same name, indicating the execution result of that preset type message. It should be understood that this application does not limit the specific definition of the preset types; they can be customized according to actual needs. This application is only illustrative.

[0091] Specifically, StartTest (i.e., the start type) indicates the test start point and can be used as a reference to record the test start timestamp. Upon receiving StartTest, the test module must proactively provide all service interfaces corresponding to the services to be tested (OfferService), and simultaneously send a StartTestACK response message, feeding back the execution result (Result Identifier, RID) of the service primitive. The response message does not carry any parameters.

[0092] EndTest (i.e., the termination type) indicates that the current test has terminated and can be used as a reference to record the test end timestamp. After receiving the EndTest service primitive, the test module needs to reset the SOA and stop all active service primitives. The test module should also send an EndTestACK response message.

[0093] The purpose of TriggerNotification (i.e., trigger type) is to indicate that the test module should trigger a specific notification message. Upon receiving this type of message, the test module should trigger the corresponding SOME / IP notification type message (i.e., notification message) based on the MessageID (ServiceID and MethodID) carried in the message's Parameter. The notification message period is 1 second, until a StopTriggerNotification (i.e., stop type) or EndTest type message is received, or the notification subscription times out. The test module should also send a TriggerNotificationACK response message.

[0094] The StopTriggerNotification (i.e., the stop type) indicates that the test module should stop sending specific notification messages. After receiving a message of this type, the test module should stop sending the corresponding notification message according to the Message ID (ServiceID and MethodID) carried in the Parameter, and at the same time send a StopTriggerNotificationACK response message.

[0095] The purpose of ForwardFFRequest (i.e., forwarding type) is to indicate that the test module needs to forward the FF Request message. After the controller receives the message of this type, it should send out the subsequent valid FF messages received through the SendFFRequest type message, and the message corresponding to the message ID (ServiceID and MethodID).

[0096] The purpose of the SendFFRequest type is that, given that the test module has received a ForwardFFRequest, all subsequent supported FF requests will be sent through SendFFRequest.

[0097] The purpose of GetVersion (i.e., get type) is to obtain the protocol version of the current SOA. After receiving a message of this type, the test module should return a GetVersionACK response message, carrying the version number of the currently supported service interface in the Parameter.

[0098] In one embodiment, the message format of the preset type includes at least one of the following:

[0099] The service identifier bit is used to describe the identifier number of the service interface;

[0100] The message identifier bit is used to describe the number of the preset type;

[0101] The length bit describes the number of bytes in the message.

[0102] The result bit describes the processing result of a message of the preset type.

[0103] The supplementary bits are used to describe supplementary information for messages of a preset type.

[0104] Optionally, in this embodiment, the preset type of message is used to control the start or stop of the service, trigger notifications, receive request feedback, etc. The transport layer adopts the User Datagram Protocol (UDP), and the port number is fixed at 20001. The message header format and definition can be referred to the message format definition in the "AUTOSAR Testability Protocol and Service Primitives" protocol. The payload content after the header has different formats depending on the preset type.

[0105] Specifically, such as Figure 4 As shown, Figure 4The specific message format for the preset type of message in this application includes the following: SID (Service Identifier): Service ID, 2 bytes, representing the service ID of the current SOA, fixed at 0xFFF0 by default; EVB: Event Bit, 1 bit, when set, indicating that the preset type of the current message is Event; GID: GroupID, 7 bits, group identifier, which divides the preset type of message into different groups according to the test purpose, where 0 represents a general service primitive and 1 represents an interface test primitive. StartTest, StartTestAck, EndTest, EndTestAck, GetVersion, and GetVersionACK belong to the general type, while the rest belong to the interface test type; PID (Message Identifier): PrimitiveID, 8 bits, service primitive identifier, different PIDs correspond to different service primitives, specifically: 0x01 represents StartTest and StartTestAck; 0x02 represents E... ndTest and EndTestAck; 0x03 represents TriggerNotification and TriggerNotificationAck; 0x04 represents StopTriggerNotification and StopTriggerNotificationAck; 0x05 represents ForwardFFRequest and ForwardFFRequestAck; 0x06 represents SendFFRequest; 0x07 represents GetVersion and GetVersionACK; LEN (length bit): 4 bytes, length field, representing the number of bytes in the message following this field, excluding the length field itself; TID: Type ID, 8 bits, identifier of the preset type, 0x00 indicates the preset type, 0x01 indicates the response type, and 0x02 indicates the event type; RID (Result ID), 8 bits, result identifier, indicating the execution result of the corresponding preset type message, where 0x00 indicates successful processing of the preset type message, and 0x01 indicates failure; Parameters (supplementary bits): indicates the supplementary descriptive information carried by the preset type message. Different preset types carry different parameters. StartTest, StartTestAck, EndTest, EndTestAck, GetVersion, TriggerNotificationACK, StopTriggerNotificationACK, ForwardFFRequest, and ForwardFFRequestACK do not carry any parameters. Other types of control messages carry service information of the service under test.

[0106] In these alternative embodiments, by uniformly defining the message format, it is not necessary to rely on the actual functional requirements of the vehicle. Different vehicle models, different services, or different interfaces of the same service are all unified into the same message format. The triggering conditions of all trigger-type messages are simplified and unified. That is, all triggering conditions are simplified to receiving a specified control message. Furthermore, the unified message format definition makes the entire test environment reusable and improves test efficiency.

[0107] In one embodiment, prior to step 100 above, the following steps may also be performed:

[0108] S600 obtains the interface information of each service interface and the dependencies between the service interfaces. The interface information includes the type of the service interface, the data content transmitted by the service interface, and the data format.

[0109] Optionally, in this embodiment, for each service interface, the definition of the interface type can be obtained by consulting relevant documents, specifications, or code. This may specifically include information such as methods, parameters, and return types. The data content and format transmitted by each service interface are analyzed to determine the data fields, data types, and data formats. The dependencies between various service interfaces are understood through analysis of the system or interface code. This may include call relationships, data dependencies, and control flow. Dependencies are determined by analyzing function calls, interface calls, message passing, and other methods in the interface code.

[0110] In these alternative embodiments, obtaining detailed information such as the type, parameters, and return values ​​of each service interface helps developers and testers accurately understand the interface's functionality and usage, avoiding misunderstandings and misuse. Understanding the data content and format transmitted by the service interface ensures the correctness and consistency of data during interface calls. Developers can correctly construct and parse data according to data format requirements to guarantee correct data transmission and processing. Furthermore, analyzing the dependencies between service interfaces helps developers and testers understand the call order, dependencies, and scope of impact between interfaces. This facilitates writing correct code and test cases, avoiding errors and failures caused by dependency issues.

[0111] S700 generates interface standard files based on the interface information corresponding to each service interface and the dependency relationships between each service interface.

[0112] Optionally, in one possible implementation of this application, the content of an interface standard document can be written based on the interface information and dependencies. The document should describe in detail the function, parameters, data format, and usage methods of each service interface, and explain the impact and limitations of dependencies on the interface. The generation of the interface standard document helps to unify the understanding of the interfaces, standardize their use, and ensure coordination and compatibility between various service interfaces.

[0113] In these alternative embodiments, the interface standard document serves as a reference document, providing developers with guidance and specifications for interface calls. Testers can write test cases based on the interface standard document to verify the correctness and consistency of the interface. This helps improve the efficiency and quality of development and testing. Furthermore, by clearly defining the data format and dependencies of the interface, the interface standard document ensures compatibility and integration between different service interfaces. Developers can write code based on the interface standard document to guarantee the consistency and correctness of data transmission and processing between interfaces, thereby contributing to improved accuracy, consistency, and efficiency in the development and testing process, providing a foundation and guidance for the correct use, compatibility, and reliability of the interface.

[0114] Optionally, in this embodiment of the application, to meet the needs of test development, this application provides a unified definition of the software component (SWC) logic corresponding to all service interface types included in the SOME / IP protocol. Specifically, for the Request and Response Method (RR Method) type: after receiving a valid Request, the test module should set all parameters in the Response to the maximum value within the valid range. If the parameter has a dynamic length, it should be filled according to its maximum valid length. For the FF Method type: after receiving a ForwardFFRequest message of the preset type, the test module should send all subsequently received FF Method request IDs through a message of the specified SendFFReques preset type. For the Notification type: after receiving a message of the specified preset type (TriggerNotification), the test module should support triggering the corresponding Notification sending according to the Service ID and Method ID, with a period of 100ms. All parameters carried should be set to the maximum value within the valid range. If the parameter has a dynamic length, it should be filled according to its maximum valid length.

[0115] In these alternative embodiments, the work outputs of the service interface configuration phase are used as test objects, separating them from the entire controller development process to expose problems in this phase in advance, facilitating the localization of related issues. Unifying the triggering conditions for each scenario into preset message types resolves the complex requirements of the test environment for controller peripherals or simulation devices, making the triggering environment reusable.

[0116] Figure 5 A schematic diagram of the structure of a service interface testing device provided in another embodiment of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0117] Reference Figure 5 The service interface testing device may include:

[0118] The first configuration module 501 is used to configure multiple service interfaces based on the pre-acquired interface standard file;

[0119] The second configuration module 502 is used to configure the processing rules for multiple service interfaces. The processing rules are the rules for processing preset types of messages sent and received by the multiple service interfaces.

[0120] Sending module 503 is used to send messages of a preset type to the service interface;

[0121] The acquisition module 504 is used to acquire the feedback message of the service interface. The feedback message is obtained by the service interface processing the received message of a preset type according to the processing rules.

[0122] The judgment module 505 is used to judge the feedback message with reference to the interface standard file and obtain the test result.

[0123] In one embodiment, the service interface testing apparatus may further include:

[0124] The second acquisition module is used to obtain the test code of the test module based on the processing rules;

[0125] The first generation module is used to generate communication code files by calling multiple service interfaces through test code.

[0126] The integration module is used to integrate communication code files into the controller sample to generate a test module.

[0127] In one embodiment, the sending module 503 may include:

[0128] The first sending submodule is used to send messages of a preset type to the service interface through the test module.

[0129] In one embodiment, the sending module 503 may further include:

[0130] The second sending submodule is used to send a message of the preset type to the service interface through the test module, so that when the service interface receives the message of the preset type, it sends the feedback message to the test module.

[0131] In one embodiment, the testing module is used to implement the following functions:

[0132] Identify messages of preset types;

[0133] Reply with a message of the preset type;

[0134] Call multiple service interfaces.

[0135] In one embodiment, the acquisition module 504 may include:

[0136] The first acquisition submodule is used to receive the feedback message sent by the service interface through the test module. The feedback message is filled by the service interface according to the filling rules configured by the processing rules.

[0137] In one embodiment, the preset type includes at least one of the following:

[0138] Start type: The start type is used to record the timestamp of the test start and the identifier of the service interface call;

[0139] The end type is used to record the timestamp of the test's end and to trigger the cessation of message transmission;

[0140] Trigger type: The trigger type is used to trigger the notification message of the service interface;

[0141] Stop type: The stop type is used to trigger a halt to sending feedback messages.

[0142] Forwarding type: The forwarding type is used to trigger the service interface to forward packets;

[0143] Get Type: This function is used to obtain the version number of the service interface to be tested.

[0144] In one embodiment, the message format of the preset type includes at least one of the following:

[0145] The service identifier bit is used to describe the identifier number of the service interface;

[0146] The message identifier bit is used to describe the number of the preset type;

[0147] The length bit describes the number of bytes in the message.

[0148] The result bit describes the processing result of a message of the preset type.

[0149] The supplementary bits are used to describe additional descriptive information for messages of a preset type.

[0150] In one embodiment, the service interface testing apparatus may further include:

[0151] The third acquisition module is used to acquire the interface information of each service interface and the dependency relationship between each service interface. The interface information includes the type of service interface, the data content transmitted by the service interface, and the data format.

[0152] The second generation module is used to generate interface standard files based on the interface information corresponding to each service interface and the dependency relationships between each service interface.

[0153] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. They are devices corresponding to the above-mentioned battery thermal runaway early warning method. All implementation methods in the above-mentioned method embodiments are applicable to the embodiments of this device. For details on its specific functions and the technical effects it brings, please refer to the method embodiment section. It will not be repeated here.

[0154] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0155] Figure 6 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0156] The device may include a processor 601 and a memory 602 storing program instructions.

[0157] When the processor 601 executes the program, it implements the steps in any of the above method embodiments.

[0158] For example, the program can be divided into one or more modules / units, one or more of which are stored in memory 602 and executed by processor 601 to complete this application. The one or more modules / units can be a series of program instruction segments capable of performing a specific function, which describe the execution process of the program in the device.

[0159] Specifically, the processor 601 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0160] Memory 602 may include mass storage for data or instructions. For example, and not limitingly, memory 602 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 602 may include removable or non-removable (or fixed) media. Where appropriate, memory 602 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 602 is non-volatile solid-state memory.

[0161] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0162] The processor 601 implements any of the methods described in the above embodiments by reading and executing program instructions stored in the memory 602.

[0163] In one example, the electronic device may also include a communication interface 603 and a bus 610. The processor 601, memory 602, and communication interface 603 are connected via the bus 610 and communicate with each other.

[0164] The communication interface 603 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0165] Bus 610 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 610 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0166] Furthermore, in conjunction with the methods in the above embodiments, this application embodiment can provide a storage medium for implementation. This storage medium stores program instructions; when these program instructions are executed by a processor, they implement any of the methods in the above embodiments.

[0167] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0168] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0169] This application provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above method embodiments and achieve the same technical effects. To avoid repetition, it will not be described again here.

[0170] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0171] The functional modules shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on machine-readable media or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable media" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer grids such as the Internet, intranets, etc.

[0172] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0173] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to create a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0174] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A service interface testing method, characterized in that, The method includes: Configure multiple service interfaces based on the pre-obtained interface standard files; Configure the processing rules for the multiple service interfaces, wherein the processing rules are rules for processing preset types of messages sent and received by the multiple service interfaces; Send the preset type of message to the service interface; Obtain the feedback message of the service interface, wherein the feedback message is obtained by the service interface processing the received message of the preset type according to the processing rules; Referring to the interface standard document, the feedback message is judged to obtain the test result; before sending the preset type message to the service interface, the method further includes: Based on the processing rules, the test code for the test module is obtained; The test code calls the multiple service interfaces to generate a communication code file. The communication code file is integrated into the controller prototype to generate the test module, which includes the test code and the communication code file. Sending the preset type of message to the service interface includes: The test code in the test module converts the processing rules into executable code, and writes the code for the request message according to the processing rules, including constructing the data format of the request message, filling in the message content, and sending the message of the preset type to the service interface based on the communication code file, so that the service interface parses and processes the request message according to the rules defined in the processing rules, and generates the feedback message according to the processing result.

2. The method according to claim 1, characterized in that, Sending the preset type of message to the service interface includes: The test module sends a message of the preset type to the service interface, so that when the service interface receives the message of the preset type, it sends the feedback message to the test module.

3. The method according to claim 1, characterized in that, The step of obtaining the feedback message from the service interface includes: The test module receives the feedback message sent by the service interface, and the feedback message is filled by the service interface according to the filling rules configured in the processing rules.

4. The method according to claim 1, characterized in that, The testing module is used to perform the following functions: Identify the message of the preset type; Reply with the preset message type; Call the aforementioned multiple service interfaces.

5. The method according to claim 1, characterized in that, The preset type includes at least one of the following: Start type, which is used to record the timestamp of the start of the test and the identifier of the service interface call; The termination type is used to record the timestamp of the test's end and to trigger the stop sending of messages; Trigger type, the trigger type being used to trigger the notification message of the service interface; Stop type, the stop type being used to trigger a halt to sending the feedback message; Forwarding type, wherein the forwarding type is used to trigger the service interface to forward packets; The type of acquisition is used to obtain the version number of the service interface.

6. The method according to claim 5, characterized in that, The message format of the preset type includes at least one of the following: Service identifier bit, which is used to describe the identifier number of the service interface; The message identifier bit is used to describe the number of the preset type; Length bit, which describes the number of bytes in the message; The result bit describes the processing result of the message of the preset type; Supplementary bits are used to describe supplementary descriptive information for the message of the preset type.

7. The method according to claim 1, characterized in that, Before configuring multiple service interfaces based on the pre-acquired interface standard file, the method further includes: Obtain the interface information of each service interface and the dependencies between the service interfaces. The interface information includes the type of the service interface, the data content transmitted by the service interface, and the data format. Based on the interface information corresponding to each of the service interfaces and the dependencies between the service interfaces, the interface standard file is generated.

8. A service interface testing device, characterized in that, The device includes: The first configuration module is used to configure multiple service interfaces based on the pre-acquired interface standard file; The second configuration module is used to configure the processing rules for the plurality of service interfaces. The processing rules are rules for processing preset types of messages sent and received by the plurality of service interfaces. A sending module is configured to send a message of the preset type to the service interface; it is also configured to obtain test code for the test module based on the processing rules; call the multiple service interfaces through the test code to generate a communication code file; integrate the communication code file into the controller sample to generate the test module, the test module including the test code and the communication code file; it is further configured to convert the processing rules into executable code through the test code in the test module, and write code for a request message according to the processing rules, including constructing the data format of the request message, filling in the message content, and sending the message of the preset type to the service interface based on the communication code file, so that the service interface parses and processes the request message according to the rules defined in the processing rules, and generates a feedback message based on the processing result; The acquisition module is used to acquire the feedback message of the service interface, wherein the feedback message is obtained by the service interface processing the received message of the preset type according to the processing rules; The judgment module is used to judge the feedback message with reference to the interface standard file and obtain the test result.

9. An electronic device, characterized in that, The device includes: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the service interface testing method as described in any one of claims 1-7.

Images