Test device, test method, electronic equipment and readable storage medium

Abstract

The embodiment of the invention provides a testing device, a testing method, electronic equipment and a readable storage medium, and belongs to the technical field of vehicle testing. The device comprises an input interface adaptation assembly used for generating a test instruction set and load information according to SOA service requirements and test cases; the service adaptation component is used for issuing a test instruction set to the tested electronic device in a service subscription mode, obtaining an Ethernet message, converting the Ethernet message into a message object according to the load information, and sending the message object to a theme of the message object, and the execution result of the tested electronic device is carried in the Ethernet message; the message adaptation component is used for acquiring and analyzing the message object to obtain an execution result, and generating an output interface according to the execution result and a predefined member object; and the result processing component is used for obtaining the execution result from the output interface, comparing the execution result with an expected result of the test case, and generating a test result. The test efficiency and the accuracy of the test result are improved.

Description

Technical Field

[0001] This application relates to the field of vehicle testing technology, and more specifically, to a testing apparatus, a testing method, an electronic device, and a readable storage medium. Background Technology

[0002] Service-Oriented Architecture (SOA) achieves modular design by dividing the vehicle system into independent service modules, thereby improving the scalability and maintainability of the vehicle system. When testing in-vehicle SOA service architectures, the CANoe tool is often used, which presents challenges such as the need to manually parse service message payloads and write specific test interfaces for different services. In complex testing scenarios, this can lead to efficiency and accuracy challenges. Summary of the Invention

[0003] This application proposes a testing device, testing method, electronic device, and readable storage medium to automatically parse and convert Ethernet packets returned by the electronic device under test, reducing the possibility of human error introduced by manual parsing, realizing unified processing of different service interfaces between the testing device and the electronic device under test, and improving testing efficiency and the accuracy of test results.

[0004] In a first aspect, embodiments of this application provide a testing apparatus, including: an input interface adaptation component, a service adaptation component, a message adaptation component, and a result processing component, wherein,

[0005] The input interface adapter component is used to generate scenario-based test instruction sets and load information descriptions based on SOA service requirements and test cases.

[0006] The service adaptation component is used to issue the scenario-based test instruction set to the electronic device under test through service subscription, obtain the Ethernet packets sent by the electronic device under test, the Ethernet packets carry the execution results obtained by the electronic device under test executing the instructions in the scenario-based test instruction set, convert the Ethernet packets into message objects according to the load information description, and send the message objects to the topic corresponding to the message objects.

[0007] The message adaptation component is used to obtain and parse the message object, get the execution result, and generate an output interface based on the execution result and predefined member objects;

[0008] The result processing component is used to obtain the execution result from the output interface, compare the execution result with the expected result of the test case, and generate test results.

[0009] In the above technical solution, the testing device includes an input interface adapter component, a service adapter component, a message adapter component, and a result processing component. Through the service adapter component and the message adapter component, the Ethernet packets returned by the electronic device under test are automatically parsed and converted, reducing the possibility of human error introduced by manual parsing. Through the service adapter component, scenario-based test commands are issued to the electronic device under test in a service subscription manner, realizing unified processing of different service interfaces between the testing device and the electronic device under test, effectively shielding the heterogeneity of service interfaces, and improving testing efficiency and the accuracy of test results.

[0010] In some embodiments, the service adaptation component includes:

[0011] The message broker module is used to create virtual nodes, and through the virtual nodes, interact with the electronic device under test according to the scenario-based test instruction set to realize service subscription; receive Ethernet packets from the electronic device under test and send the Ethernet packets to the service-to-message module; and send the message object to the topic corresponding to the message object.

[0012] The service-to-message module is used to parse the Ethernet packet to obtain a first parsing result, and convert the Ethernet packet into a message object based on the first parsing result and the load information description.

[0013] In the above technical solution, the message broker module is used to create virtual nodes, interact with the electronic device under test according to the scenario-based test instruction set to achieve service subscription, and receive Ethernet packets sent by the electronic device under test. The Ethernet packets are sent to the service-to-message module, which automatically parses the packet content to obtain a first parsing result, and converts the Ethernet packets into message objects according to the first parsing result and load information. Through automated packet parsing and conversion, the possibility of human error introduced by manual parsing is reduced. By issuing scenario-based test instructions to the electronic device under test through the service adaptation component in the form of service subscription, unified processing of different service interfaces between the test device and the electronic device under test is realized, effectively shielding the heterogeneity of service interfaces and improving test efficiency and the accuracy of test results.

[0014] In some embodiments, the service-to-message module includes:

[0015] The message parsing submodule is used to parse the protocol header and payload of the Ethernet message to obtain a first parsing result, which includes the service ID, method ID, client ID and actual business data.

[0016] The message conversion submodule is used to combine the service ID, method ID, and client ID into the subject of the message object; and to convert the actual business data into the payload of the message object according to the load information description.

[0017] In the above technical solution, the message parsing submodule is used to automatically parse the protocol header and payload of Ethernet messages to obtain the service ID, method ID, client ID and actual business data. The message conversion submodule combines the service ID, method ID and client ID into the subject of the message object and converts the actual business data into the payload of the message object. This automated parsing and conversion of the Ethernet messages returned by the electronic device under test reduces the possibility of human error introduced by manual parsing.

[0018] In some embodiments, the scenario-based test instruction set includes instructions that need to be sent to the electronic device under test in various business scenarios; the load information description includes the interface data types and internal enumeration information defined in the SOA service requirements.

[0019] In the above technical solution, the scenario-based test instruction set is the instruction that needs to be sent to the electronic device under test in various business scenarios. The load information description includes the interface data type and internal enumeration information defined in the SOA service requirements. Through the scenario-based test instruction set and load information description, real business scenarios can be simulated more effectively to test the electronic device under test.

[0020] In some embodiments, the message broker module includes:

[0021] The virtual node creation submodule is used to create virtual nodes;

[0022] The communication submodule is used to interact with the electronic device under test through the virtual node according to the scenario-based test instruction set to achieve service subscription; receive Ethernet packets from the electronic device under test and send the Ethernet packets to the service-to-message module; receive message objects output by the service-to-message module and send the message objects to the topic corresponding to the message objects.

[0023] In the above technical solution, the message broker module creates virtual nodes through the virtual node creation submodule, and uses the communication submodule to interact with the electronic device under test according to the scenario-based test instruction set to realize service subscription. It receives Ethernet messages from the electronic device under test and forwards them to the service-to-message module for processing. Then, it receives and sends the message objects processed by the service-to-message module to the corresponding topic. It issues scenario-based test instructions to the electronic device under test in the form of service subscription, realizes unified processing of different service interfaces between the test device and the electronic device under test, effectively shields the heterogeneity of service interfaces, and improves test efficiency and the accuracy of test results.

[0024] In some embodiments, the message adaptation component includes a message parsing module and an output interface adaptation module.

[0025] The message parsing module is used to obtain and parse message objects to obtain the payload of the message objects, and the payload of the message objects is the execution result of the test case;

[0026] The output interface adaptation module is used to instantiate predefined member objects and generate output interfaces based on the execution results.

[0027] In the above technical solution, the message adaptation component receives and parses message objects from the service adaptation component through the message parsing module, extracts the payload of the message object, i.e. the execution result of the test case, and the output interface adaptation module 502 instantiates the predefined member objects according to the execution result to generate the output interface. By automatically parsing the message object and generating the output interface, the message adaptation component simplifies the testing process, reduces manual intervention, and improves testing efficiency.

[0028] In some embodiments, the result processing component is further configured to: determine the adjustment content of the input signal based on the test results and the test strategy, adjust the input signal based on the adjustment content, and send the adjusted input signal to the input interface for input injection.

[0029] In the above technical solution, the result processing component is used to adjust the input signal according to the test results and test strategy, and inject input through the input interface to execute the next stage of testing. This enables subsequent tests to cover various possible operating conditions and boundary situations according to the test strategy, shortens the test cycle, and improves the efficiency and effectiveness of testing.

[0030] Secondly, embodiments of this application provide a testing method, including:

[0031] Scenario-based test instruction sets are issued to the electronic devices under test through service subscription;

[0032] Acquire Ethernet packets sent by the electronic device under test, wherein the Ethernet packets carry the execution results obtained by the electronic device under test executing the instructions in the scenario-based test instruction set;

[0033] Based on the load information description, the Ethernet packet is converted into a message object and the message object is sent.

[0034] Obtain and parse the message object to get the execution result, and generate an output interface based on the execution result and predefined member objects;

[0035] The execution result is obtained from the output interface, and the execution result is compared with the expected result of the test case to generate the test result.

[0036] In the above technical solution, scenario-based test command sets are issued to the electronic device under test (DUT) via service subscription. Ethernet packets returned by the DUT are received, parsed, and converted into message objects. An output interface is generated based on the execution results and predefined member objects. Finally, the execution results are compared with the expected results to generate test results. Automated parsing and conversion of Ethernet packets returned by the DUT reduces the possibility of human error introduced by manual parsing. The service subscription method for issuing scenario-based test commands to the DUT enables unified processing of different service interfaces between the DUT and the device under test, effectively shielding the heterogeneity of service interfaces and improving testing efficiency and the accuracy of test results.

[0037] In some embodiments, the method further includes:

[0038] Based on SOA service requirements and test cases, the scenario-based test instruction set and load information description are generated;

[0039] The scenario-based test instruction set includes instructions that need to be sent to the electronic device under test in various business scenarios; the load information description includes the interface data types and internal enumeration information of the relevant protocols defined in the SOA service requirements.

[0040] In the above technical solution, the process of generating scenario-based test instruction sets and load information descriptions based on SOA service requirements and test cases is as follows: the scenario-based test instruction set consists of instructions that need to be sent to the electronic device under test in various business scenarios; the load information description includes the interface data types and internal enumeration information defined in the SOA service requirements. Through the scenario-based test instruction set and load information description, real business scenarios can be simulated more effectively to test the electronic device under test.

[0041] In some embodiments, converting the Ethernet packet into a message object based on the load information description includes:

[0042] The Ethernet packets from the electronic device under test are parsed to obtain a first parsing result. The Ethernet packets are then converted into message objects based on the first parsing result and the load information description.

[0043] In the above technical solution, the Ethernet packets from the electronic device under test are parsed to obtain a first parsing result, and the Ethernet packets are converted into message objects according to the first parsing result and the load information description. The Ethernet packets returned by the electronic device under test are automatically parsed and converted, reducing the possibility of human error introduced by manual parsing.

[0044] In some embodiments, parsing the Ethernet packets from the electronic device under test to obtain a first parsing result, and converting the Ethernet packets into message objects based on the first parsing result and the payload information description, includes:

[0045] The protocol header and payload of the Ethernet packet are parsed to obtain a first parsing result, which includes the service ID, method ID, client ID, and actual business data.

[0046] The service ID, method ID, and client ID are combined to form the subject of the message object. Based on the load information description, the actual business data is converted into the payload of the message object.

[0047] In the above technical solution, the Ethernet packet parsing process includes detailed parsing of its protocol header and payload to obtain a first parsing result containing service ID, method ID, client ID and actual business data. The first parsing result is combined into the subject of the message object, and the actual business data is converted into the payload of the message object according to the payload information description. The Ethernet packets returned by the electronic device under test are automatically parsed and converted, reducing the possibility of human error introduced by manual parsing.

[0048] In some embodiments, the step of issuing a set of scenario-based test instructions to the electronic device under test via service subscription includes:

[0049] A virtual node is created, and the virtual node interacts with the electronic device under test according to the scenario-based test instruction set to achieve service subscription.

[0050] In the above technical solution, the virtual node interacts with the electronic device under test according to the scenario-based test instruction set to achieve service subscription, thereby realizing unified processing of different service interfaces between the test device and the electronic device under test, effectively shielding the heterogeneity of service interfaces, and improving test efficiency and the accuracy of test results.

[0051] In some embodiments, the method further includes:

[0052] Based on the test results and test strategy, determine the adjustment content of the input signal, adjust the input signal according to the adjustment content, and send the adjusted input signal to the input interface for input injection.

[0053] In the above technical solution, the result processing component is used to adjust the input signal according to the test results and test strategy, and inject input through the input interface to execute the next stage of testing. This enables subsequent tests to cover various possible operating conditions and boundary situations according to the test strategy, shortens the test cycle, and improves the efficiency and effectiveness of testing.

[0054] Thirdly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the test method described in the second aspect above.

[0055] Fourthly, this application provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the test method described in the second aspect above.

[0056] Fifthly, this application provides a chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the testing method as described in the second aspect above.

[0057] In a sixth aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the testing method described in the second aspect above. Attached Figure Description

[0058] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0059] Figure 1 This is one of the structural schematic diagrams of the testing apparatus provided in some embodiments of this application;

[0060] Figure 2 This application provides schematic diagrams of the structure of service adaptation components provided in some embodiments;

[0061] Figure 3 This application provides schematic diagrams illustrating the structure of a message broker module according to some embodiments.

[0062] Figure 4 This is a schematic diagram of the structure of a service-to-message module provided in some embodiments of this application;

[0063] Figure 5This is a schematic diagram of the structure of a message adaptation component provided in some embodiments of this application;

[0064] Figure 6 This is a second schematic diagram of the structure of the testing device provided in some embodiments of this application;

[0065] Figure 7 A flowchart illustrating the testing methods provided in some embodiments of this application;

[0066] Figure 8 The diagram shows the structure of an electronic device provided in some embodiments of this application.

[0067] Figure label:

[0068] 100: Test device; 101: Input interface adapter component; 102: Service adapter component;

[0069] 103: Message adaptation component; 104: Result processing component;

[0070] 201: Message broker module; 202: Service to message module;

[0071] 301: Virtual Node Creation Submodule; 302: Communication Submodule;

[0072] 401: Message parsing submodule; 402: Message conversion submodule;

[0073] 501: Message parsing module; 502: Output interface adaptation module. Detailed Implementation

[0074] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0075] Unless otherwise defined, all technical and scientific terms used in this application have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used in the description of this application is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms "comprising" and "having," and any variations thereof, in the description, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the description, claims, or accompanying drawings of this application are used to distinguish different objects, not to describe a specific order or hierarchy.

[0076] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application can be combined with other embodiments.

[0077] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," "linking," and "attachment" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal communication between two components. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0078] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0079] In this application, "multiple" refers to two or more (including two), and similarly, "multiple groups" refers to two or more (including two), and "multiple pieces" refers to two or more (including two).

[0080] Service-Oriented Architecture (SOA) is widely used in the automotive industry. By dividing the vehicle system into independent service modules, it achieves modular design. Under the SOA architecture, each service module is developed, tested, and maintained independently, reducing the complexity of the vehicle system and improving its scalability and maintainability.

[0081] In-vehicle SOA service architectures are typically implemented based on Scalable Service-Oriented Middleware over IP (SOME / IP) protocols, often using the CANoe tool for testing. This tool needs to be connected to the entire vehicle network and obtain description files in various formats such as ARXML. Based on the configuration information contained in the description files, testers can configure network cards and other devices to meet the communication requirements of the vehicle network. After configuration, the CANoe tool can establish communication with the Device Under Test (DUT) and subscribe to corresponding SOA services according to test requirements. During this process, CANoe monitors network communication and verifies the accuracy of the data. However, testing solutions in related technologies face challenges in efficiency and accuracy when handling complex dynamic scenarios. These solutions also rely on the commercial Vector toolchain, thus increasing testing costs.

[0082] Specifically, the testing methods in the relevant technologies have the following problems:

[0083] (1) The business data definitions of each service are different. Testers need to manually parse the message load returned by each service, which is tedious and may introduce human error.

[0084] (2) In the process of issuing test instructions to the DUT corresponding to the service, testers need to write specific interfaces for each different service, which makes it impossible to shield the heterogeneity of service interfaces.

[0085] The testing apparatus, testing method, electronic device, and readable storage medium provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0086] Figure 1 This is a schematic diagram of the structure of a test apparatus provided in some embodiments of this application. For example... Figure 1 As shown, this application provides a testing apparatus 100, including: an input interface adaptation component 101, a service adaptation component 102, a message adaptation component 103, and a result processing component 104, wherein,

[0087] The input interface adapter component 101 is used to generate scenario-based test instruction sets and load information descriptions based on SOA service requirements and test cases.

[0088] SOA service requirements define a series of conditions and standards that must be met when designing and implementing services. They indicate the specific operations and tasks that should be performed for the electronic devices or components corresponding to the service, and may include the functional and non-functional requirements of the service, as well as the interaction specifications with other services.

[0089] Test cases are steps and conditions designed to verify whether a service meets service requirements, including information such as test inputs, expected results, and the test environment. In this embodiment, test cases are designed to test whether the electronic device (i.e., the device under test, DUT) corresponding to the service can normally execute the specific operations indicated by the service requirements. By analyzing the execution data returned by the device under test and the expected results of the test cases, the performance of the service in different application scenarios can be evaluated. Optionally, test cases are determined based on SOA service requirements and testing strategies. The testing strategy is the overall plan for planning and executing tests. For example, the testing strategy may specify that certain key functions of the service should be tested in a focused manner, or specific testing methods may be used to improve the accuracy and efficiency of the tests.

[0090] The input interface adapter component 101 is used to generate scenario-based test instruction sets and load information descriptions based on SOA service requirements and test cases, so as to simulate real business scenarios and load conditions and effectively test the electronic device under test.

[0091] In some embodiments, the scenario-based test instruction set includes instructions that need to be sent to the electronic device under test in various business scenarios; the load information description includes the interface data types and internal enumeration information defined in the SOA service requirements.

[0092] Understandably, scenario-based test instruction sets are sets of test instructions generated to simulate real business scenarios. Optionally, different business scenarios correspond to different test instruction sets. The electronic device under test can achieve the corresponding functions by executing the instructions in the test instruction set. The load information description is used to define the load information that needs to be sent to the electronic device under test during the test, including interface data types (such as the type of request parameters, the type of return value, etc.) and internal enumeration information (such as status codes, error codes, etc.).

[0093] Service adaptation component 102 is used to send the scenario-based test instruction set to the electronic device under test through service subscription, obtain the Ethernet packets sent by the electronic device under test, the Ethernet packets carry the execution results obtained by the electronic device under test executing the instructions in the scenario-based test instruction set, convert the Ethernet packets into message objects according to the load information description, and send the message objects to the topic corresponding to the message objects.

[0094] Optionally, the service adaptation component 102 sends the scenario-based test instructions to the electronic device under test (DUT) via the Message Queuing Telemetry Transport (MQTT) protocol. During this process, the DUT establishes a connection with the service adaptation component 102 or its internal modules, i.e., jointly subscribes to one or more specific topics. These topics are used as channels to receive the scenario-based test instruction set from the service adaptation component 102. The service adaptation component 102 encapsulates the scenario-based test instruction set into an MQTT message and publishes it to the topics subscribed to by the DUT. The DUT receives the MQTT message and parses the content in the message body to extract the scenario-based test instruction set and execute the test instructions therein.

[0095] Understandably, the electronic device under test (DUT) sends the execution results obtained after executing the scenario-based test instruction set to the service adaptation component 102 via Ethernet packets (such as SOME / IP packets). The service adaptation component 102 receives the Ethernet packets from the DUT and, based on the payload information description, converts the Ethernet packets into message objects (such as MQTT message objects). After conversion, the service adaptation component 102 determines the corresponding target topic based on the message object's attributes or characteristics and sends it, enabling subscribers to that topic to receive the message object for subsequent processing.

[0096] The message adaptation component 103 is used to obtain and parse the message object, get the execution result, and generate an output interface based on the execution result and predefined member objects.

[0097] The message adaptation component 103 obtains the message object sent by the service adaptation component 102. The message object contains the execution result obtained by the electronic device under test after executing the scenario-based test instruction set. After parsing these message objects, the message adaptation component 103 generates the output interface based on the execution result and the predefined member object.

[0098] Predefined member objects can be classes, structs, interfaces, or other types of entities. These objects typically contain fixed properties and methods. For example, a vehicle sensor member object can be predefined, which has multiple properties such as temperature, humidity, and pressure, as well as corresponding methods for reading and setting the values ​​of these properties. The message adaptation component 103 parses the message object received from the service adaptation component 102, extracts the vehicle sensor execution results such as temperature, humidity, and pressure values, instantiates the vehicle sensor member object, and generates an output interface. This output interface allows external entities (such as result processing components) to obtain the vehicle sensor execution results in a standardized manner.

[0099] The result processing component 104 is used to obtain the execution result from the output interface, compare the execution result with the expected result of the test case, and generate test results.

[0100] The execution result is obtained by the electronic device under test executing the scenario-based test instruction set. The result processing component 104 compares the execution result with the expected result of the test case to evaluate whether the performance and behavior of the electronic device under test meet the expectations. By comparing the execution results, the result processing component 104 can generate test results, which include a conclusion on whether the electronic device under test passes the test (such as PASS, FAIL, etc.).

[0101] In the above technical solution, the testing device includes an input interface adapter component, a service adapter component, a message adapter component, and a result processing component. Through the service adapter component and the message adapter component, the Ethernet packets returned by the electronic device under test are automatically parsed and converted, reducing the possibility of human error introduced by manual parsing. Through the service adapter component, scenario-based test commands are issued to the electronic device under test in a service subscription manner, realizing unified processing of different service interfaces between the testing device and the electronic device under test, effectively shielding the heterogeneity of service interfaces, and improving testing efficiency and the accuracy of test results.

[0102] Figure 2 This is a schematic diagram illustrating the structure of service adaptation components provided in some embodiments of this application. For example... Figure 2 As shown, in some embodiments of this application, the service adaptation component 102 includes:

[0103] The message broker module 201 is used to create virtual nodes, and through the virtual nodes, interact with the electronic device under test according to the scenario-based test instruction set to realize service subscription; receive Ethernet packets from the electronic device under test and send the Ethernet packets to the service-to-message module 202; and send the message object to the topic corresponding to the message object.

[0104] The service-to-message module 202 is used to parse the Ethernet packet to obtain a first parsing result, and convert the Ethernet packet into a message object according to the first parsing result and the load information description.

[0105] Figure 3 This is a schematic diagram illustrating the structure of a message broker module provided in some embodiments of this application. For example... Figure 3 As shown, in some embodiments of this application, the message broker module 201 includes:

[0106] The virtual node creation submodule 301 is used to create virtual nodes;

[0107] The communication submodule 302 is used to interact with the electronic device under test through the virtual node according to the scenario-based test instruction set to realize service subscription; receive Ethernet packets from the electronic device under test and send the Ethernet packets to the service-to-message module; receive message objects output by the service-to-message module and send the message objects to the topic corresponding to the message objects.

[0108] It can be understood that a virtual node is a simulated entity created by the virtual node creation submodule 301 within the message broker module 201. The virtual node does not actually generate data; instead, it serves as an intermediate node in the testing process, used to send test commands, receive responses from the device under test (DUT), and coordinate the entire testing flow. Through the virtual node, service subscription is achieved by interacting with the DUT. The DUT can obtain a set of scenario-based test commands through subscription, execute the corresponding commands, thereby simulating service requests and responses in real business scenarios to test the DUT.

[0109] Optionally, the virtual node interacts with the electronic device under test (DUT) via the MQTT protocol to subscribe to services. During this process, the DUT establishes a connection with the virtual node and jointly subscribes to one or more specific topics. These topics serve as channels for the DUT to receive scenario-based test instruction sets from the virtual node.

[0110] Understandably, the electronic device under test sends the execution result obtained after executing the scenario-based test instruction set to the communication submodule 302 in the message broker module 201 via Ethernet packets (such as SOME / IP packets). The communication submodule 302 sends the Ethernet packet containing the execution result to the service-to-message module 202, and receives the message object output by the service-to-message module 202, determines the target topic corresponding to the message object and sends it, so that the subscribers of the topic can receive the message object for subsequent processing.

[0111] The message broker module creates virtual nodes through the virtual node creation submodule and uses the communication submodule to interact with the electronic device under test (DUT) according to the scenario-based test instruction set to achieve service subscription. It receives Ethernet packets from the DUT and forwards them to the service-to-message module for processing. Then, it receives and sends the message objects processed by the service-to-message module to the corresponding topic. It issues scenario-based test instructions to the DUT in the form of service subscription, realizing unified processing of different service interfaces between the test device and the DUT, effectively shielding the heterogeneity of service interfaces, and improving test efficiency and the accuracy of test results.

[0112] Figure 4 This is a schematic diagram illustrating the structure of a service-to-message module provided in some embodiments of this application. For example... Figure 4As shown, in some embodiments of this application, the service-to-message module 202 includes:

[0113] The message parsing submodule 401 is used to parse the protocol header and payload of the Ethernet message to obtain a first parsing result, which includes the service ID, method ID, client ID and actual business data.

[0114] The message conversion submodule 402 is used to combine the service ID, method ID, and client ID into the subject of the message object; and to convert the actual business data into the payload of the message object according to the load information description.

[0115] As can be understood, a service ID is an identifier used to uniquely identify a service. In an SOA service architecture, each service is assigned a service ID to enable identification and location of the service. A method ID is an identifier used to uniquely identify a specific method within a service. Within a service, there may be multiple different methods, each performing a specific function. A client ID is an identifier used to uniquely identify a client. In an SOA service architecture, a client may be an application or device that calls the service.

[0116] It is understood that the scenario-based test instruction set is a set of test instructions generated to simulate real business scenarios. The electronic device under test (DUT) generates execution results based on the scenario-based test instruction set in the message object. These results serve as test data and can be used to evaluate whether the DUT's execution of the corresponding instructions meets expectations. In this embodiment, the Ethernet packet is sent by the DUT to the message broker module 201 and further to the service-to-message module 202. The packet parsing submodule 401 in the service-to-message module 202 is used to parse the Ethernet packet to obtain a first parsing result including the service ID, method ID, client ID, and actual business data. The service ID is the unique identifier of the service being simulated in the test, the method ID is the unique identifier of the method that performs the specific test function within the service, the client ID is the unique identifier of the client that initiated the test request, and the actual business data is the execution result obtained by the DUT after executing the scenario-based test instruction set.

[0117] The message conversion submodule 402 is used to combine the service ID, method ID, and client ID according to predetermined rules into a topic for the message object, which serves as the label for the message object. The message conversion submodule 402 is also used to extract the actual business data based on the interface data type (such as the type of request parameters, the type of return value, etc.) and internal enumeration information (such as status codes, error codes, etc.), and convert it into the payload of the message object. Optionally, the message object is an MQTT message object.

[0118] The message parsing submodule is used to automatically parse the protocol header and payload of Ethernet messages to obtain the service ID, method ID, client ID and actual business data. The message conversion submodule then combines the service ID, method ID and client ID into the subject of the message object and converts the actual business data into the payload of the message object. This automated parsing and conversion of Ethernet messages returned by the electronic device under test reduces the possibility of human error introduced by manual parsing.

[0119] In the above technical solution, the message broker module is used to create virtual nodes, interact with the electronic device under test according to the scenario-based test instruction set to achieve service subscription, and receive Ethernet packets sent by the electronic device under test. The Ethernet packets are sent to the service-to-message module, which automatically parses the packet content to obtain a first parsing result, and converts the Ethernet packets into message objects according to the first parsing result and load information. Through automated packet parsing and conversion, the possibility of human error introduced by manual parsing is reduced. By issuing scenario-based test instructions to the electronic device under test through the service adaptation component in the form of service subscription, unified processing of different service interfaces between the test device and the electronic device under test is realized, effectively shielding the heterogeneity of service interfaces and improving test efficiency and the accuracy of test results.

[0120] Figure 5 This is a schematic diagram illustrating the structure of a message adaptation component provided in some embodiments of this application. For example... Figure 5 As shown, in some embodiments of this application, the message adaptation component 103 includes a message parsing module 501 and an output interface adaptation module 502.

[0121] The message parsing module 501 is used to obtain and parse a message object to get the payload of the message object, and the payload of the message object is the execution result of the test case.

[0122] The output interface adaptation module 502 is used to instantiate predefined member objects and generate an output interface based on the execution result.

[0123] The message parsing module 501 receives and parses message objects from the service adaptation component 102. These message objects are generated after the service adaptation component 102 converts the Ethernet packets sent by the electronic device under test. The parsing module 501 extracts the payload from the message object, which is the execution result of the test case, reflecting the response and behavior of the electronic device under test to the scenario-based test instructions.

[0124] The output interface adaptation module 502 is used to instantiate predefined data structures or object models based on the execution results of the test cases provided by the message parsing module 501. This process generates standardized output interfaces, encapsulates the execution results, and allows the result processing component 104 or other system components to access and use this data. By instantiating predefined member objects, the output interface adaptation module 502 improves data consistency and availability, facilitating subsequent test result analysis and verification.

[0125] In the above technical solution, the message adaptation component receives and parses message objects from the service adaptation component through the message parsing module, extracts the payload of the message object, i.e. the execution result of the test case, and the output interface adaptation module 502 instantiates the predefined member objects according to the execution result to generate the output interface. By automatically parsing the message object and generating the output interface, the message adaptation component simplifies the testing process, reduces manual intervention, and improves testing efficiency.

[0126] According to some embodiments of this application, the result processing component 104 is further configured to: determine the adjustment content of the input signal based on the test results and the test strategy, adjust the input signal based on the adjustment content, and send the adjusted input signal to the input interface for input injection.

[0127] The test results include a conclusion on whether the electronic device under test (e.g., PASS, FAIL, etc.). The test strategy is the overall plan for planning and executing the test. For example, the test strategy may specify that certain key functions of the service should be tested in a focused manner, or specific test methods should be used to improve the accuracy and efficiency of the test. The result processing component 104 is also used to determine whether the input signal needs to be adjusted based on the test results and the test strategy. If adjustment is required, the specific adjustment content will be further determined, which may include changing the parameters, conditions, or modes of the input signal to test different aspects or boundary conditions of the electronic device under test.

[0128] Based on the determined adjustments, the result processing component 104 adjusts the input signal, which may involve modifying the signal's value, time series, or characteristics to simulate different test scenarios. The adjusted input signal is sent to the input interface adapter component 101 for input injection, which can generate a new scenario-based instruction set to execute the next stage of testing.

[0129] Understandably, the input signal is adjusted based on the test results and test strategy. The adjusted input signal can participate in the next stage of testing, enabling subsequent tests to cover various possible operating conditions and boundary situations according to the test strategy, thereby improving the efficiency and effectiveness of testing. By adjusting the input signal and injecting input into the input interface, the next stage of testing can be carried out without re-initialization, reducing the test cycle time.

[0130] In the above technical solution, the result processing component is used to adjust the input signal according to the test results and test strategy, and inject input through the input interface to execute the next stage of testing. This enables subsequent tests to cover various possible operating conditions and boundary situations according to the test strategy, shortens the test cycle, and improves the efficiency and effectiveness of testing.

[0131] Figure 6 This is a second schematic diagram of the structure of the testing apparatus provided in some embodiments of this application. For example... Figure 6 As shown, this application provides a testing apparatus 100, including: an input interface adaptation component 101, a service adaptation component 102, a message adaptation component 103, and a result processing component 104, wherein,

[0132] The input interface adapter component 101 is used to generate scenario-based test instruction sets and load information descriptions based on SOA service requirements and test cases.

[0133] Service adaptation component 102 is used to send the scenario-based test instruction set to the electronic device under test through service subscription, obtain the Ethernet packets sent by the electronic device under test, the Ethernet packets carry the execution results obtained by the electronic device under test executing the instructions in the scenario-based test instruction set, convert the Ethernet packets into message objects according to the load information description, and send the message objects to the topic corresponding to the message objects.

[0134] The message adaptation component 103 is used to obtain and parse the message object, get the execution result, and generate an output interface based on the execution result and predefined member objects.

[0135] Result processing component 104 is used to obtain the execution result from the output interface, compare the execution result with the expected result of the test case, and generate test result;

[0136] The service adaptation component 102 includes:

[0137] The message broker module 201 is used to create virtual nodes, and through the virtual nodes, interact with the electronic device under test according to the scenario-based test instruction set to realize service subscription; receive Ethernet packets from the electronic device under test and send the Ethernet packets to the service-to-message module 202; and send the message object to the topic corresponding to the message object.

[0138] The service-to-message module 202 is used to parse the Ethernet packet to obtain a first parsing result, and convert the Ethernet packet into a message object according to the first parsing result and the load information description.

[0139] The scenario-based test instruction set includes instructions that need to be sent to the electronic device under test in various business scenarios; the load information description includes the interface data types and internal enumeration information defined in the SOA service requirements.

[0140] The message adaptation component 103 includes a message parsing module 501 and an output interface adaptation module 502.

[0141] The message parsing module 501 is used to obtain and parse a message object to get the payload of the message object, and the payload of the message object is the execution result of the test case.

[0142] The output interface adaptation module 502 is used to instantiate predefined member objects and generate an output interface based on the execution result.

[0143] The result processing component 104 is further configured to: determine the adjustment content of the input signal according to the test results and test strategy, adjust the input signal according to the adjustment content, and send the adjusted input signal to the input interface for input injection.

[0144] In the above technical solution, the testing device includes an input interface adapter component, a service adapter component, a message adapter component, and a result processing component. Through the service adapter component and the message adapter component, the Ethernet packets returned by the electronic device under test are automatically parsed and converted, reducing the possibility of human error introduced by manual parsing. Through the service adapter component, scenario-based test commands are issued to the electronic device under test in a service subscription manner, realizing unified processing of different service interfaces between the testing device and the electronic device under test, effectively shielding the heterogeneity of service interfaces, and improving testing efficiency and the accuracy of test results.

[0145] The testing device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the scope of the device.

[0146] The testing device in this application embodiment can be a device with an operating system. This operating system can be a Microsoft (Windows) operating system, an Android operating system, an iOS operating system, or other possible operating systems; this application embodiment does not specifically limit the specific operating system used.

[0147] The testing method provided in this application embodiment can be executed by the testing device or electronic device in the foregoing embodiment, or by a functional module or functional entity in an electronic device that can implement the testing method. The electronic devices mentioned in this application embodiment include, but are not limited to, mobile phones, tablets, computers, cameras, and wearable devices. The testing method provided in this application embodiment will be described below using a testing device as the execution subject.

[0148] Figure 7 This is a flowchart illustrating the testing methods provided in some embodiments of this application. For example... Figure 7 As shown, this application provides a testing method, including steps 710, 720, 730, 740 and 750.

[0149] Step 710: Send a set of scenario-based test instructions to the electronic device under test via service subscription;

[0150] Step 720: Obtain the Ethernet message sent by the electronic device under test, wherein the Ethernet message carries the execution result obtained by the electronic device under test executing the instructions in the scenario-based test instruction set;

[0151] Step 730: Based on the load information description, convert the Ethernet packet into a message object and send the message object;

[0152] Step 740: Obtain and parse the message object to get the execution result, and generate an output interface based on the execution result and predefined member objects;

[0153] Step 750: Obtain the execution result from the output interface, compare the execution result with the expected result of the test case, and generate the test result.

[0154] Optionally, the scenario-based test commands are sent to the electronic device under test (DUT) via the Message Queuing Telemetry Transport (MQTT) protocol. During this process, a connection is established with the DUT, i.e., they jointly subscribe to one or more specific topics. These topics are used as channels for the DUT to receive the scenario-based test command set. The scenario-based test command set is encapsulated into an MQTT message and published to the topics subscribed to by the DUT. The DUT receives the MQTT message and parses the content in the message body to extract the scenario-based test command set and execute the test commands therein.

[0155] Understandably, the device under test (DUT) will send the execution results obtained after executing the scenario-based test instruction set via Ethernet packets (such as SOME / IP packets). The system receives Ethernet packets from the DUT, converts them into message objects based on the payload information, and then determines the corresponding target topic based on the message object's attributes or characteristics before sending it. This allows subscribers to that topic to receive the message object for subsequent processing.

[0156] Predefined member objects can be classes, structs, interfaces, or other types of entities, which typically contain fixed attributes and methods. An output interface is generated based on the execution results and the predefined member objects. This output interface allows external entities (such as result processing components) to obtain the execution results of the scenario-based test instructions executed by the electronic device under test in a standardized manner.

[0157] The execution result is obtained by the electronic device under test executing the scenario-based test instruction set. The execution result is compared with the expected result of the test case to evaluate whether the performance and behavior of the electronic device under test meet the expectations. By comparing the execution results, the test result is generated, which includes a conclusion on whether the electronic device under test passes the test (such as PASS, FAIL, etc.).

[0158] In the above technical solution, scenario-based test command sets are issued to the electronic device under test (DUT) via service subscription. Ethernet packets returned by the DUT are received, parsed, and converted into message objects. An output interface is generated based on the execution results and predefined member objects. Finally, the execution results are compared with the expected results to generate test results. Automated parsing and conversion of Ethernet packets returned by the DUT reduces the possibility of human error introduced by manual parsing. The service subscription method for issuing scenario-based test commands to the DUT enables unified processing of different service interfaces between the DUT and the device under test, effectively shielding the heterogeneity of service interfaces and improving testing efficiency and the accuracy of test results.

[0159] According to some embodiments of this application, the method further includes:

[0160] Based on SOA service requirements and test cases, the scenario-based test instruction set and load information description are generated;

[0161] The scenario-based test instruction set includes instructions that need to be sent to the electronic device under test in various business scenarios; the load information description includes the interface data types and internal enumeration information of the relevant protocols defined in the SOA service requirements.

[0162] SOA service requirements define a series of conditions and standards that must be met when designing and implementing services. They indicate the specific operations and tasks that should be performed for the electronic devices or components corresponding to the service, and may include the functional and non-functional requirements of the service, as well as the interaction specifications with other services.

[0163] Test cases are steps and conditions designed to verify whether a service meets service requirements, including information such as test inputs, expected results, and the test environment. In this embodiment, test cases are designed to test whether the electronic device (i.e., the device under test, DUT) corresponding to the service can normally execute the specific operations indicated by the service requirements. By analyzing the execution data returned by the device under test and the expected results of the test cases, the service's performance in different scenarios can be evaluated. Optionally, test cases are determined based on SOA service requirements and testing strategies. The testing strategy is the overall plan for planning and executing tests. For example, the testing strategy may specify that certain key functions of the service should be tested in a focused manner, or specific testing methods may be used to improve the accuracy and efficiency of the tests.

[0164] Based on SOA service requirements and test cases, scenario-based test instruction sets and load information descriptions are generated to simulate real business scenarios and load conditions, and to effectively test the electronic devices under test.

[0165] In the above technical solution, the process of generating scenario-based test instruction sets and load information descriptions based on SOA service requirements and test cases is as follows: the scenario-based test instruction set consists of instructions that need to be sent to the electronic device under test in various business scenarios; the load information description includes the interface data types and internal enumeration information defined in the SOA service requirements. Through the scenario-based test instruction set and load information description, real business scenarios can be simulated more effectively to test the electronic device under test.

[0166] According to some embodiments of this application, the step of converting the Ethernet packet into a message object based on the load information description includes:

[0167] The Ethernet packets from the electronic device under test are parsed to obtain a first parsing result. The Ethernet packets are then converted into message objects based on the first parsing result and the load information description.

[0168] Understandably, upon receiving an Ethernet packet (such as a SOME / IP packet) from the electronic device under test, the Ethernet packet is parsed to obtain the first parsing result. The first parsing result may include the packet header information, data segment content, and possible checksum information, etc.

[0169] The load information description is used to define the load information that needs to be sent to the electronic device under test during the test, including interface data types (such as the type of request parameters, the type of return value, etc.) and internal enumeration information (such as status codes, error codes, etc.). Based on the first parsing result and the load information description, the Ethernet packet is converted into a message object.

[0170] In some embodiments, parsing the Ethernet packets from the electronic device under test to obtain a first parsing result, and converting the Ethernet packets into message objects based on the first parsing result and the payload information description, includes:

[0171] The protocol header and payload of the Ethernet packet are parsed to obtain a first parsing result, which includes the service ID, method ID, client ID, and actual business data.

[0172] The service ID, method ID, and client ID are combined to form the subject of the message object. Based on the load information description, the actual business data is converted into the payload of the message object.

[0173] As can be understood, a service ID is an identifier used to uniquely identify a service. In an SOA service architecture, each service is assigned a service ID to enable identification and location of the service. A method ID is an identifier used to uniquely identify a specific method within a service. Within a service, there may be multiple different methods, each performing a specific function. A client ID is an identifier used to uniquely identify a client. In an SOA service architecture, a client may be an application or device that calls the service.

[0174] It is understandable that a scenario-based test instruction set is a set of test instructions generated to simulate real business scenarios. The electronic device under test (DUT) generates execution results based on the scenario-based test instruction set in the message object. These results serve as test data and can be used to evaluate whether the DUT's execution of the corresponding instructions meets expectations. In this embodiment, the Ethernet packet is parsed to obtain a first parsing result including a service ID, a method ID, a client ID, and actual business data. The service ID is the unique identifier of the service being simulated in the test, the method ID is the unique identifier of the method within the service that executes the specific test function, the client ID is the unique identifier of the client that initiated the test request, and the actual business data is the execution result obtained by the DUT after executing the scenario-based test instruction set.

[0175] The service ID, method ID, and client ID are combined according to predetermined rules to form the topic of the message object, which serves as the label for the message object. Based on the interface data type (such as the type of request parameters, the type of return value, etc.) and internal enumeration information (such as status codes, error codes, etc.), the actual business data is extracted and converted into the payload of the message object. Optionally, the message object is an MQTT message object.

[0176] The Ethernet packet parsing process includes detailed parsing of its protocol header and payload to obtain a first parsing result containing the service ID, method ID, client ID, and actual business data. Based on the first parsing result, the subject of the message object is combined, and the actual business data is converted into the payload of the message object according to the payload information description. The Ethernet packets returned by the electronic device under test are automatically parsed and converted, reducing the possibility of human error introduced by manual parsing.

[0177] In the above technical solution, the Ethernet packets from the electronic device under test are parsed to obtain a first parsing result, and the Ethernet packets are converted into message objects according to the first parsing result and the load information description. The Ethernet packets returned by the electronic device under test are automatically parsed and converted, reducing the possibility of human error introduced by manual parsing.

[0178] According to some embodiments of this application, the step of issuing a scenario-based test instruction set to the electronic device under test via service subscription includes:

[0179] A virtual node is created, and the virtual node interacts with the electronic device under test according to the scenario-based test instruction set to achieve service subscription.

[0180] In essence, a virtual node is a simulated entity that does not actually generate data. Instead, it acts as an intermediary node in the testing process, sending test commands, receiving responses from the device under test (DUT), and coordinating the entire testing flow. Through this virtual node, service subscriptions are achieved by interacting with the DUT. The DUT can obtain scenario-based test command sets through subscription, execute the corresponding commands, and thus simulate service requests and responses in real-world business scenarios for testing.

[0181] Optionally, the virtual node interacts with the electronic device under test (DUT) via the MQTT protocol to subscribe to services. During this process, the DUT establishes a connection with the virtual node and jointly subscribes to one or more specific topics. These topics serve as channels for the DUT to receive scenario-based test instruction sets from the virtual node.

[0182] In the above technical solution, the virtual node interacts with the electronic device under test according to the scenario-based test instruction set to achieve service subscription, thereby realizing unified processing of different service interfaces between the test device and the electronic device under test, effectively shielding the heterogeneity of service interfaces, and improving test efficiency and the accuracy of test results.

[0183] According to some embodiments of this application, the method further includes:

[0184] Based on the test results and test strategy, determine the adjustment content of the input signal, adjust the input signal according to the adjustment content, and send the adjusted input signal to the input interface for input injection.

[0185] Test results include a conclusion on whether the electronic device under test (e.g., PASS, FAIL) passes the test. The test strategy is the overall plan for planning and executing the test. For example, a test strategy might specify focusing on testing certain key functions of the service, or employing specific testing methods to improve the accuracy and efficiency of the test. Based on the test results and test strategy, it is determined whether the input signal needs adjustment. If adjustment is required, the specific adjustments will be further determined, which may include changing the parameters, conditions, or modes of the input signal to test different aspects or boundary conditions of the electronic device under test.

[0186] Understandably, the input signal is adjusted based on the test results and test strategy. The adjusted input signal can participate in the next stage of testing, enabling subsequent tests to cover various possible operating conditions and boundary situations according to the test strategy, thereby improving the efficiency and effectiveness of testing. By adjusting the input signal and injecting input into the input interface, the next stage of testing can be carried out without re-initialization, reducing the test cycle time.

[0187] In the above technical solution, the result processing component is used to adjust the input signal according to the test results and test strategy, and inject input through the input interface to execute the next stage of testing. This enables subsequent tests to cover various possible operating conditions and boundary situations according to the test strategy, shortens the test cycle, and improves the efficiency and effectiveness of testing.

[0188] In some embodiments, such as Figure 8 As shown, this application embodiment also provides an electronic device 800, including a processor 801, a memory 802, and a computer program stored in the memory 802 and executable on the processor 801. When the program is executed by the processor 801, it implements the various processes of the above-described test method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0189] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0190] This application also provides a non-transitory computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described test method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0191] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0192] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described testing method.

[0193] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

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

[0195] 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.

[0196] Unless otherwise specified, all embodiments and optional embodiments of this application can be combined to form new technical solutions.

[0197] Unless otherwise specified, all technical features and optional technical features of this application may be combined to form new technical solutions.

[0198] Unless otherwise specified, all steps of this application may be performed sequentially or randomly, preferably sequentially. For example, the method includes steps (a) and (b), indicating that the method may include steps (a) and (b) performed sequentially, or it may include steps (b) and (a) performed sequentially. For example, the mention that the method may also include step (c) indicates that step (c) may be added to the method in any order; for example, the method may include steps (a), (b), and (c), or it may include steps (a), (c), and (b), or it may include steps (c), (a), and (b), etc.

[0199] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A testing device, characterized in that, include: The components include input interface adaptation components, service adaptation components, message adaptation components, and result processing components. The input interface adapter component is used to generate scenario-based test instruction sets and load information descriptions based on SOA service requirements and test cases. The service adaptation component is used to issue the scenario-based test instruction set to the electronic device under test through service subscription, obtain the Ethernet packets sent by the electronic device under test, the Ethernet packets carry the execution results obtained by the electronic device under test executing the instructions in the scenario-based test instruction set, convert the Ethernet packets into message objects according to the load information description, and send the message objects to the topic corresponding to the message objects. The message adaptation component is used to obtain and parse the message object, get the execution result, and generate an output interface based on the execution result and predefined member objects; The result processing component is used to obtain the execution result from the output interface, compare the execution result with the expected result of the test case, and generate the test result.

2. The testing apparatus according to claim 1, characterized in that, The service adaptation components include: The message broker module is used to create virtual nodes, and through the virtual nodes, interact with the electronic device under test according to the scenario-based test instruction set to realize service subscription; receive Ethernet packets from the electronic device under test and send the Ethernet packets to the service-to-message module; and send the message object to the topic corresponding to the message object. The service-to-message module is used to parse the Ethernet packet to obtain a first parsing result, and convert the Ethernet packet into a message object based on the first parsing result and the load information description.

3. The testing apparatus according to claim 2, characterized in that, The service-to-message module includes: The message parsing submodule is used to parse the protocol header and payload of the Ethernet message to obtain a first parsing result, which includes the service ID, method ID, client ID and actual business data. The message conversion submodule is used to combine the service ID, method ID, and client ID into the subject of the message object; and to convert the actual business data into the payload of the message object according to the load information description.

4. The testing apparatus according to any one of claims 1-3, characterized in that, The scenario-based test instruction set includes instructions that need to be sent to the electronic device under test in various business scenarios; the load information description includes the interface data types and internal enumeration information defined in the SOA service requirements.

5. The testing apparatus according to claim 2, characterized in that, The message broker module includes: The virtual node creation submodule is used to create virtual nodes; The communication submodule is used to interact with the electronic device under test through the virtual node according to the scenario-based test instruction set to achieve service subscription; receive Ethernet packets from the electronic device under test and send the Ethernet packets to the service-to-message module; receive message objects output by the service-to-message module and send the message objects to the topic corresponding to the message objects.

6. The testing apparatus according to claim 3, characterized in that, The message adaptation component includes a message parsing module and an output interface adaptation module. The message parsing module is used to obtain and parse message objects to obtain the payload of the message objects, and the payload of the message objects is the execution result of the test case; The output interface adaptation module is used to instantiate predefined member objects and generate output interfaces based on the execution results.

7. The testing apparatus according to any one of claims 1-6, characterized in that, The result processing component is further configured to: determine the adjustment content of the input signal based on the test results and test strategy, adjust the input signal according to the adjustment content, and send the adjusted input signal to the input interface for input injection.

8. A testing method, characterized in that, include: Scenario-based test instruction sets are issued to the electronic devices under test through service subscription; Acquire Ethernet packets sent by the electronic device under test, wherein the Ethernet packets carry the execution results obtained by the electronic device under test executing the instructions in the scenario-based test instruction set; Based on the load information description, the Ethernet packet is converted into a message object and the message object is sent. Obtain and parse the message object to get the execution result, and generate an output interface based on the execution result and predefined member objects; The execution result is obtained from the output interface, and the execution result is compared with the expected result of the test case to generate the test result.

9. The test method according to claim 8, characterized in that, The method further includes: Based on SOA service requirements and test cases, the scenario-based test instruction set and load information description are generated; The scenario-based test instruction set includes instructions that need to be sent to the electronic device under test in various business scenarios; the load information description includes the interface data types and internal enumeration information of the relevant protocols defined in the SOA service requirements.

10. The test method according to claim 8 or 9, characterized in that, The step of converting the Ethernet packet into a message object based on the load information description includes: The Ethernet packets from the electronic device under test are parsed to obtain a first parsing result. The Ethernet packets are then converted into message objects based on the first parsing result and the load information description.

11. The test method according to claim 10, characterized in that, The step of parsing the Ethernet packets from the electronic device under test to obtain a first parsing result, and converting the Ethernet packets into message objects based on the first parsing result and the load information description, includes: The protocol header and payload of the Ethernet packet are parsed to obtain a first parsing result, which includes the service ID, method ID, client ID, and actual business data. The service ID, method ID, and client ID are combined to form the subject of the message object. Based on the load information description, the actual business data is converted into the payload of the message object.

12. The test method according to any one of claims 8-11, characterized in that, The method of issuing scenario-based test instruction sets to the electronic device under test via service subscription includes: A virtual node is created, and the virtual node interacts with the electronic device under test according to the scenario-based test instruction set to achieve service subscription.

13. The test method according to any one of claims 8-12, characterized in that, The method further includes: Based on the test results and test strategy, determine the adjustment content of the input signal, adjust the input signal according to the adjustment content, and send the adjusted input signal to the input interface for input injection.

14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the test method as described in any one of claims 8-13.

15. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the test method as described in any one of claims 8-13.

Images