Test result determination method and device, storage medium and electronic equipment

Abstract

The invention discloses a test result determination method and device, a storage medium and electronic device.The method comprises the steps that a target file used for conducting operation regulation and control on an electronic control unit is read from the storage device, a test logic corresponding to the target file is determined, and a target interface starting use case test process conforming to the test logic is scheduled; wherein the test logic comprises at least one of loop logic, conditional branch logic and exception retry logic; and monitoring the use case test process, generating a target monitoring result, and determining a final test result of the target file based on a response message and a response code in the target monitoring result. Through the method and the device, the problems of complicated test process and inconvenience in large-scale management in related technologies are solved, so that the effects of improving the automation level, the accuracy and the flexibility of the diagnostic test and reducing the technical complexity and the time cost of test case iteration and maintenance are achieved.

Description

Methods and apparatus for determining test results, storage media and electronic equipment Technical Field

[0001] This application relates to the field of diagnostic testing technology for automotive electronic control units, and more specifically, to a method and apparatus for determining test results, a storage medium, and an electronic device. Background Technology

[0002] In the context of the rapid development of the automotive electronics industry, the Electronic Control Unit (ECU), as the core of vehicle intelligent control, is increasingly important for diagnostic testing. However, traditional manual testing methods rely heavily on engineers' personal experience and manual operation, which is not only inefficient but also frequently affected by inconsistencies caused by human factors. Although there are various automated testing tools on the market, such as ZCANPRO and CANoe, which can perform basic Unified Diagnostic Services (UDS) protocol testing, these tools generally have several limitations: First, the flexibility of test execution is insufficient, making it difficult to automatically adjust to complex test logic, such as conditional branches, loops, and abnormal retries; second, the report generation process is manual and the format is non-standardized, making it difficult to uniformly manage and analyze large-scale test results; third, test scripts are highly coupled with project configurations, making it difficult to reuse across ECUs or vehicle models, resulting in time-consuming and resource-wasting preparation phases for each test. In addition, most tools do not provide open APIs, making it difficult to integrate the testing process with enterprise-level continuous integration / continuous deployment (CI / CD) systems, limiting the role of test automation in the software development cycle.

[0003] Therefore, no effective solution has yet been proposed to address the problems of complex testing processes and inconvenient large-scale management in related technologies. Summary of the Invention

[0004] This application provides a method and apparatus for determining test results, a storage medium, and an electronic device to at least solve the technical problems of complex testing processes and inconvenient large-scale management in related technologies.

[0005] According to one aspect of the embodiments of this application, a method for determining test results is provided, comprising: reading a target file for operating and controlling an electronic control unit from a storage device, wherein the target file includes: a configuration file containing test data packets, test parameters, and expected results; determining the test logic corresponding to the target file and scheduling a target interface conforming to the test logic to start a test case process; wherein the test logic includes at least one of the following: loop logic, conditional branch logic, and exception retry logic; monitoring the test case process, generating target monitoring results, and determining the final test result of the target file based on the response messages and response codes in the target monitoring results.

[0006] In an exemplary embodiment, monitoring the test case process and generating target monitoring results includes: reading multiple real-time messages generated by the test case process through an interface loop function; filtering response messages containing a target address from the multiple real-time messages, wherein the target address is the address of the electronic control unit in the vehicle network; obtaining code information for a preset duration after the occurrence of the response message to obtain a response code; and summarizing the response messages and response codes to generate target monitoring results.

[0007] In an exemplary embodiment, after monitoring the test case testing process and generating the target monitoring result, the method further includes: when the response code is a negative response code, determining the code byte corresponding to the response code and the test failure type corresponding to the code byte; adjusting the test case testing process according to the test failure type and the preset processing strategy corresponding to the test failure type; and if the adjustment is successful, diagnosing whether the test case testing process is complete based on the final output response message after adjustment.

[0008] In an exemplary embodiment, after determining the test logic corresponding to the target file and scheduling the target interface that conforms to the test logic to start the test case process, the above method further includes: generating a diagnostic request message corresponding to the current test case process based on a preset protocol; synchronizing the diagnostic request message and the identifier corresponding to the diagnostic request message to the controller area network of the vehicle where the electronic control unit is located through a sending interface function; and enabling the diagnostic request message corresponding to the current test case when the electronic control unit participates in the current test case test.

[0009] In an exemplary embodiment, determining the final test result of a target file based on the response message and response code in the target monitoring result includes: if the response message is a positive response message, comparing the data content carried by the response message with the target data content corresponding to the configuration file, and determining the final test result based on the comparison result; if the response message is a negative response message, determining the matching result between the response code and the expected code set of the configuration file, and determining the final test result based on the matching result.

[0010] In an exemplary embodiment, when the response message is a positive response message, the data content carried in the response message is compared with the target data content corresponding to the configuration file, and the final test result is determined based on the comparison result, including: generating a final test result indicating that the test has passed when the similarity between the data content and the target data content is greater than a preset similarity threshold, and generating a final test result indicating that the test has failed when the similarity between the data content and the target data content is less than or equal to the preset similarity threshold.

[0011] In an exemplary embodiment, when the response message is a negative response message, determining the matching result between the response code and the expected code set in the configuration file, and determining the final test result based on the matching result, includes: generating a final test result indicating that the response code has a matching object in the expected code set if the matching result indicates that the response code does not have a matching object in the expected code set if the matching result indicates that the test failed or the test was incorrect.

[0012] According to another aspect of the embodiments of this application, a test result determination apparatus is also provided, comprising: a reading module, configured to read a target file for operating and controlling an electronic control unit from a storage device, wherein the target file includes: a test data package, test parameters, and a configuration file of expected results; a scheduling module, configured to determine the test logic corresponding to the target file and schedule a target interface conforming to the test logic to start a test case process; wherein the test logic includes at least one of the following: loop logic, conditional branch logic, and exception retry logic; and a determination module, configured to monitor the test case process, generate target monitoring results, and determine the final test result of the target file based on the response message and response code in the target monitoring results.

[0013] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed by a processor.

[0014] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the steps in any of the method embodiments described above.

[0015] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to perform the steps of any of the above method embodiments through the computer program.

[0016] This application retrieves a target file from a storage device for controlling the operation of an ECU. The target file contains a configuration file with test data packages, test parameters, and expected results. Using a standard library of a high-level scripting language (such as Python), the data in the configuration file is parsed and loaded into memory as input for subsequent tests. The test logic corresponding to the target file is dynamically determined, including but not limited to loop logic, conditional branching logic, or exception retry logic. Based on this logic, the corresponding test interface (API) is scheduled to initiate the test case process, automating the execution of the UDS diagnostic service, such as reading data identifiers (DIDs), performing session control, and secure access, without manual intervention. During the testing process, the test case process is continuously monitored, generating target monitoring results. Specifically, when a response message from the ECU is received, the final state of the test case (pass, fail, or error) is automatically determined based on the response code (NRC or PRC) in the response message, combined with predefined test logic and parameters. The final test results are recorded, including the request message, response message, determination result, and possible fault cause analysis. Therefore, it can solve the technical problems of complex test processes and inconvenient large-scale management, thereby improving the automation level, accuracy, and flexibility of diagnostic testing, and reducing the technical complexity and time cost of test case iteration and maintenance. Attached Figure Description

[0017] Figure 1 is a schematic diagram of an application scenario of a method for determining test results according to an embodiment of this application;

[0018] Figure 2 is a flowchart illustrating an optional method for determining test results according to an embodiment of this application;

[0019] Figure 3 is a flowchart illustrating the automated testing method for UDS diagnosis according to an embodiment of this application;

[0020] Figure 4 is a schematic diagram of the test environment according to an embodiment of this application;

[0021] Figure 5 is a structural block diagram of an optional test result determination device according to an embodiment of this application;

[0022] Figure 6 is a computer system architecture block diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0024] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] According to one aspect of the embodiments of this application, a method for determining test results is provided. Optionally, in this embodiment, the above-described method for determining test results can be applied, but is not limited to, to a hardware environment including a terminal device 102 and a server 104 as shown in FIG. 1. The server 104 can be connected to the terminal device 102 via a network and can be used to provide services (e.g., application services, etc.) to the terminal device 102 or clients installed on the terminal device 102. A database can be set up on the server 104 or independently of the server 104 to provide data storage services for the server 104.

[0026] The aforementioned network may include, but is not limited to, at least one of the following: wired network and wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network (WAN), metropolitan area network (MAN), and local area network (LAN). The aforementioned wireless network may include, but is not limited to, at least one of the following: Wireless Fidelity (WIFI) and Bluetooth. Terminal device 102 may be, but is not limited to, a personal computer (PC), mobile phone, tablet computer, etc. Server 104 may be, but is not limited to, a cloud server, server cluster, or other server types.

[0027] The method for determining the test results in this embodiment can be executed by server 104, terminal device 102, or jointly by server 104 and terminal device 102. Alternatively, the method for determining the test results in this embodiment can be executed by a client installed on terminal device 102.

[0028] Taking the method for determining the test result in this embodiment executed by terminal device 102 (server 104) as an example, Figure 2 is a flowchart of an optional method for determining the test result according to an embodiment of this application. As shown in Figure 2, the process of this method may include the following steps:

[0029] Step S202: Read the target file for operating and controlling the electronic control unit from the storage device, wherein the target file includes: test data package, test parameters and configuration file of expected results;

[0030] Before testing begins, pre-prepared target files are read from storage devices such as hard drives, flash memory, or network storage. These files are the core input to the test, containing test data packets for the specific ECU, necessary test parameters (such as message IDs, service codes, timeouts, etc.), and expected test results. Configuration files are typically in easily parsed and extended formats, such as JSON or XML, to facilitate reading and processing by the test scripts.

[0031] Step S204: Determine the test logic corresponding to the target file and schedule the target interface that conforms to the test logic to start the test case process; wherein, the test logic includes at least one of the following: loop logic, conditional branch logic, and exception retry logic;

[0032] After reading the target file, the system analyzes the test logic defined in the file and automatically identifies and schedules test interfaces or methods that conform to that logic to initiate the test process. Test logic can be loop logic (e.g., executing the same test multiple times consecutively to verify the consistency of the ECU's response), conditional branching logic (selecting different test paths based on the ECU's current state or the result of the previous test), or exception retry logic (automatically retrying or adjusting the test strategy when the ECU returns a negative response). By encapsulating these advanced logics in test scripts, the system can intelligently adjust test strategies to cope with complex and ever-changing test scenarios, improving test coverage and intelligence.

[0033] Step S206: Monitor the test case process, generate target monitoring results, and determine the final test result of the target file based on the response message and response code in the target monitoring results.

[0034] During the test case testing process, the testing process is monitored in real time, recording the timestamps of each request sent and ECU response received, as well as the actual response data or response code (NRC or PRC). This information constitutes the target monitoring results and is the key basis for determining whether the test is successful. Furthermore, based on the response messages and response codes in the target monitoring results, the final test result for each test case is intelligently determined. For example, if the response code is 0x50, it indicates that the UDS service 0x10 (routine control) request was responded to normally, and the test case is considered passed. If the response code is 0x22 (incorrect condition), it may trigger conditional branching logic, attempting to change the test conditions and retry, or it may be directly judged as a failure, and the reason for failure is recorded. In this way, test results can be automatically and accurately determined, significantly reducing the workload of manual analysis and judgment, while also improving the objectivity and accuracy of result determination.

[0035] The embodiments provided in this application read target files for controlling the operation of an ECU from a storage device. The target files contain test data packages, test parameters, and configuration files for expected results. Using a standard library of a high-level scripting language (such as Python), the data in the configuration files is parsed and loaded into memory as input for subsequent tests. The test logic corresponding to the target files is dynamically determined, including but not limited to loop logic, conditional branch logic, or exception retry logic. Based on this logic, the corresponding test interfaces (APIs) are scheduled to initiate the test case testing process, automating the execution of UDS diagnostic services, such as reading data identifiers (DIDs), performing session control, and secure access, without manual intervention. During the testing process, the test case testing process is continuously monitored, generating target monitoring results. Specifically, when a response message from an ECU is received, the system automatically determines the final state of the test case (pass, fail, or error) based on the response code (NRC or PRC) in the response message, combined with predefined test logic and parameters, and records the final test results, including the request message, response message, determination result, and possible fault cause analysis. Therefore, it can solve the technical problems of complex test processes and inconvenient large-scale management, and achieve the effect of significantly improving the automation level, accuracy, and flexibility of diagnostic testing, while reducing the technical complexity and time cost of test case iteration and maintenance.

[0036] In an exemplary embodiment, monitoring the test case process and generating target monitoring results includes: reading multiple real-time messages generated by the test case process through an interface loop function; filtering response messages containing a target address from the multiple real-time messages, wherein the target address is the address of the electronic control unit in the vehicle network; obtaining code information for a preset duration after the occurrence of the response message to obtain a response code; and summarizing the response messages and response codes to generate target monitoring results.

[0037] Optionally, after starting the test case, the interface loop function continuously listens for and reads multiple real-time messages generated by the test process. These messages carry communication information between the ECU and the test system, including test requests and service responses. The system intelligently filters out response messages containing target addresses from these real-time messages. The target address specifically refers to the unique identifier address of the tested ECU in the vehicle network communication, ensuring that the monitoring results correspond one-to-one with the test cases and eliminating irrelevant interference. Once a response message containing a target address is captured, it immediately analyzes the message content, focusing on the code information portion. It acquires the code information of response messages received within a preset time after the test request is issued. These response messages typically refer to messages where the ECU directly responds to the test request, and their code information includes the UDS service response code (such as NRC or PRC), indicating whether the ECU successfully executed the requested service or what problems were encountered during execution. Based on the content of the response code and in conjunction with the UDS protocol standard, the system parses the ECU's response status and identifies possible fault conditions. Finally, all filtered and parsed response messages and their response codes are summarized to form a structured target monitoring result. This result not only forms the basis for subsequent determination of whether test cases pass or fail, but also includes detailed test requests, ECU responses, timestamp records, and preliminary diagnostic descriptions based on response codes, providing rich information for subsequent in-depth analysis and troubleshooting. Automated monitoring and result aggregation significantly improve testing efficiency while ensuring the accuracy and traceability of test results.

[0038] In an exemplary embodiment, after monitoring the test case testing process and generating the target monitoring result, the method further includes: when the response code is a negative response code, determining the code byte corresponding to the response code and the test failure type corresponding to the code byte; adjusting the test case testing process according to the test failure type and the preset processing strategy corresponding to the test failure type; and if the adjustment is successful, diagnosing whether the test case testing process is complete based on the final output response message after adjustment.

[0039] Optionally, when the test system detects that the response code returned by the ECU is a negative response code (NRC), a series of measures will be taken to adjust the test process and attempt to obtain complete and valid test results. The specific steps are as follows:

[0040] Step 1: Identify and parse the code bytes carried in the NRC. These code bytes specifically describe the type of reason for the test failure, such as "condition not met," "service not recognized," or "data domain error." Based on the UDS protocol specification, each type of NRC corresponds to specific code bytes.

[0041] The second step involves automatically invoking preset handling strategies to adjust the test process based on the parsed test failure type. These strategies are typically based on the dependencies between the ECU's state model and the UDS service. For example, if the NRC indicates "condition not met," the 0x10 service (session control) might be automatically executed, switching to a higher-level session mode; if it's "security access not permitted," the 0x27 service (security access) would be invoked for key exchange. Through such dynamic adjustments, more suitable test conditions are provided, giving previously failed tests a chance to be executed and succeed.

[0042] Step 3: After adjusting the process, re-execute the corresponding test cases and capture the ECU's response. If the ECU returns a positive response code (PRC) or the expected response data this time, it indicates that the adjustment was successful and the test process was executed completely. At this point, based on the final output response message after adjustment, re-diagnose the integrity of the entire test case process, that is, confirm that all predetermined test steps have been completed correctly, without any missing or skipped steps.

[0043] In summary, by dynamically analyzing and adjusting the testing process, we have not only effectively improved the success rate of automated testing and the accuracy of problem localization, but also greatly saved testing time and manpower costs.

[0044] In an exemplary embodiment, after determining the test logic corresponding to the target file and scheduling the target interface that conforms to the test logic to start the test case process, the above method further includes: generating a diagnostic request message corresponding to the current test case process based on a preset protocol; synchronizing the diagnostic request message and the identifier corresponding to the diagnostic request message to the controller area network of the vehicle where the electronic control unit is located through a sending interface function; and enabling the diagnostic request message corresponding to the current test case when the electronic control unit participates in the current test case test.

[0045] Understandably, the automated testing process goes beyond simply scheduling test logic; it delves deeper into the specific operations of generating specific diagnostic request messages and sending them to the vehicle's network where the ECU resides, ensuring accurate test execution. Once the test logic corresponding to the target file is determined and the appropriate test interface is scheduled to initiate the test case process, a diagnostic request message required for the current test case is generated based on the preset UDS protocol standard. This message contains all the necessary information for executing a specific UDS service, such as the service ID, parameter data, and serial number. Then, using the send interface function, the generated diagnostic request message, along with its corresponding unique identifier, is synchronized to the vehicle's CAN (Controller Area Network). This unique identifier ensures correct message identification and routing. After being transmitted to the CAN network, the message is captured by the ECU and processed according to the instructions and service requirements it carries.

[0046] It's important to note that the entire message generation and transmission process is highly automated. It dynamically generates and sends corresponding messages based on the characteristics of the current test case, such as the required security level and the data identifiers to be read. This means that in each test case, the correct diagnostic request can be accurately sent to the ECU without manual writing or verification of message content, simplifying test preparation and improving test execution speed and accuracy. Furthermore, when the ECU participates in the current test case, the diagnostic request message corresponding to that case is automatically activated, ensuring the test's relevance and effectiveness. Through a series of automated operations, from message generation to transmission and ECU response monitoring, a complete, closed-loop test execution process is formed.

[0047] In an exemplary embodiment, determining the final test result of a target file based on the response message and response code in the target monitoring result includes: if the response message is a positive response message, comparing the data content carried by the response message with the target data content corresponding to the configuration file, and determining the final test result based on the comparison result; if the response message is a negative response message, determining the matching result between the response code and the expected code set of the configuration file, and determining the final test result based on the matching result.

[0048] In other words, when a response message is detected from the ECU, different judgment strategies will be adopted based on the type of the response message (positive or negative):

[0049] Strategy 1: Determination of Positive Response Messages: If a response message is identified as a positive response message, its response code indicates that the ECU has successfully executed the service requested by the test. The data content carried in the response message will be automatically compared with the preset target data content in the configuration file. This comparison process can be a precise data match or a tolerance-based determination to adapt to the needs of different test scenarios. If the data content is completely consistent or within the allowable error range, the test case is deemed to have passed, and this result is recorded in the final test results; otherwise, it is deemed a failure, and the specific difference information is recorded.

[0050] Strategy 2: Determining Negative Response Messages: When a response message is identified as a negative response message, its response code belongs to the NRC set defined by the UDS protocol, indicating that the ECU failed to execute the service request. The response code will be checked to see if it matches the expected code set defined in the configuration file. In some test scenarios, specific NRCs are expected, such as testing the ECU's response to illegal access requests. If the response code matches the expected set, the test item is still considered passed, and this special case is recorded. If the response code is not in the expected set or exceeds the expected response range, the test is considered a failure, and the specific code of the negative response is recorded for subsequent fault analysis and diagnosis.

[0051] In an exemplary embodiment, when the response message is a positive response message, the data content carried in the response message is compared with the target data content corresponding to the configuration file, and the final test result is determined based on the comparison result, including: generating a final test result indicating that the test has passed when the similarity between the data content and the target data content is greater than a preset similarity threshold, and generating a final test result indicating that the test has failed when the similarity between the data content and the target data content is less than or equal to the preset similarity threshold.

[0052] Optionally, when the ECU returns a positive response message, indicating that the response code signifies that the ECU successfully executed the test request service, a detailed comparison is performed on the content of the response data against the predefined target data content in the configuration file. This comparison process is not a simple byte-level matching but introduces similarity calculation, quantifying the differences between the response data and the target data to determine the test result. If, after calculation, the similarity between the response data and the target data is greater than a preset similarity threshold (e.g., 95%, pre-set based on the specific test scenario and data type), the ECU's response is considered highly consistent with expectations, and a final test result indicating that the test has passed is generated. This indicates that the ECU correctly understood and executed the test request, and the response result meets expectations. Conversely, if the similarity indicated by the comparison result is less than or equal to the preset similarity threshold, it is determined that the current test case has an unexpected situation, which may involve various factors such as data parsing errors, communication delays, or abnormal internal states of the ECU. In this case, a final test result indicating that the test has failed is generated, and the specific difference information and possible reasons for failure are recorded to provide a basis for subsequent fault analysis and debugging.

[0053] In an exemplary embodiment, when the response message is a negative response message, determining the matching result between the response code and the expected code set in the configuration file, and determining the final test result based on the matching result, includes: generating a final test result indicating that the response code has a matching object in the expected code set if the matching result indicates that the response code does not have a matching object in the expected code set if the matching result indicates that the test failed or the test was incorrect.

[0054] Optionally, the response code carried in the negative response message is parsed and compared with a preset set of expected codes in the configuration file. The set of expected codes contains the expected negative response codes that the ECU might return under specific test scenarios. While these NRCs indicate that the test request was not successfully executed by the ECU, they are necessary for test success in some cases, such as testing the ECU's ability to respond to illegal access or out-of-bounds requests. If the parsed response code finds a match in the set of expected codes, it means that the ECU's response behavior matches the preset test strategy; that is, the ECU did indeed return the correct NRC under the expected abnormal scenario, indicating that the ECU can correctly identify and handle such requests. In this case, although the ECU superficially denies service, the current test case is still considered passed because it verifies the correctness of the ECU's protection mechanism and response logic.

[0055] Conversely, if the response code fails to find a match in the expected code set, meaning the NRC is outside the preset reasonable response range, it may indicate a problem with the ECU's internal state, software implementation, or communication protocol, causing it to fail to process the test request according to the expected logic. In this case, a final test result indicating test failure or error will be generated based on the specific scenario and the type of NRC, indicating that an unexpected anomaly was encountered during the test, requiring further investigation and repair. This dynamic comparison and intelligent judgment mechanism based on the NRC and expected code set can not only evaluate the ECU's responsiveness to standard UDS service requests but also verify the ECU's behavioral logic under abnormal scenarios.

[0056] The method for determining test results in the embodiments of this application will be explained below with reference to optional examples.

[0057] In this optional example, a UDS diagnostic automated testing system and method based on ZCANPRO and Python scripts is provided, relating to the field of automotive electronic control unit (ECU) diagnostic testing technology, and particularly to UDS diagnostic automated testing and report generation based on ZCANPRO and Python scripts. As an optional implementation, Figure 3 is a flowchart illustrating the UDS diagnostic automated testing method according to an embodiment of this application; the specific implementation includes the following process:

[0058] Step 1: Set up the test environment, that is, build a test environment that meets the diagnostic requirements of ECU.

[0059] Optionally, Figure 4 is a schematic diagram of the test environment according to an embodiment of this application, which mainly includes the following components:

[0060] PC: As the host computer, it is used to generate test cases, send control commands, and transmit data via USB interface.

[0061] CAN Card: Employs a multi-channel CAN interface card, communicating with a PC via USB. The CAN card supports the standard CAN protocol and has two independent channels, CAN0 and CAN1. Each channel can be configured with a different baud rate to match the controller's communication requirements.

[0062] Signal connections: The CANH and CANL lines of the CAN0 channel are connected to the H and L lines of the vehicle signal on the controller, respectively; the CANH and CANL lines of the CAN1 channel are connected to the H and L lines of the radar signal on the controller, respectively. This channel-specific design allows for simultaneous testing of different signal types, avoiding interference.

[0063] Power supply: Provides DC power (12V) to power the CAN card and controller via power cord, ensuring stable system operation.

[0064] It should be noted that the hardware components are physically connected. The PC, equipped with ZCANPRO software and a Python environment, will be physically connected to the ECU under test or the vehicle's CAN network via a ZCAN series CAN / CANFD interface device (such as ZCANUSB, ZCANPCIe, etc.). Ensure the hardware connections are secure and that power is connected.

[0065] Furthermore, after the various hardware components are assembled, the system is started, and the PC sends an initialization command to the CAN card via USB. The CAN card, based on the command, sends test signals to the vehicle controller via CAN0 channel and to the radar controller via CAN1 channel. Upon receiving the signals, the controller returns data via the original path to the PC, where the PC software analyzes the data to evaluate controller performance. During the test, continuous power supply ensures signal integrity.

[0066] Step 2: Load configuration and script. Optionally, enter: zcanpro configuration interface, Test.py, etc., to run the following actions:

[0067] Action 1: Load Configuration File: Using the `load()` function from Python's standard library `json`, the configuration file (e.g., `ECU_Config.json`) is read from disk and converted into an in-memory dictionary `cfg`. This dictionary contains all the configuration information needed during testing, such as the list of DIDs (Data Identifiers) to be read, session control parameters, security access levels, etc. This information will be dynamically read and applied by the system during testing, replacing traditional global hard-coded variables and improving configuration flexibility and system maintainability.

[0068] Action 2: Dynamically Load Test Scripts: By calling the `importlib.util.spec_from_file_location()` function, the `Test_Flow.py` file on disk is dynamically loaded as a module `test_flow`. This process avoids directly using hard-coded file paths or import statements, making test script loading more flexible and allowing the loading path to be dynamically adjusted according to changes in the test environment or requirements. The `test_flow` module typically contains the test logic and flow, such as the `test_sequence()` function, which can be called by subsequent test flows.

[0069] Action 3: Reading parameters from the configuration dictionary: After the test process starts, the system reads the hardware channel configuration, DID list, expected ECU response data, and security access algorithm index from the cfg dictionary previously loaded into memory. This means that the test script will no longer rely on fixed global variables, but can flexibly read the required parameters from the configuration file according to different test scenarios or ECU configurations, further enhancing the adaptability and robustness of the test system.

[0070] Action 4: Output Configuration and Callable Objects: Ultimately, the system will output two important things: a dictionary `cfg` containing all configuration parameters, and a directly callable `test_flow` module object. The `cfg` dictionary serves as the configuration information repository for the test, while the `test_sequence()` function in the `test_flow` module serves as the execution entry point for the test flow. Together, they form the core components of the automated testing system, enabling testers to quickly adapt to different test scenarios and requirements by modifying configuration files and test scripts without altering the system's core code.

[0071] Step 3: Initialize ZCANPRO. This includes: opening the ZCANPRO software, selecting the device type, clicking "Start," setting the protocol, CANFD standard, CANFD acceleration, arbitration domain baud rate, and data domain baud rate, enabling the terminating resistor, and performing initialization. After powering on the device, you will see messages running in the CAN view of the ZCANPRO interface. You can perform a message send and receive test beforehand to ensure a response is received.

[0072] Step 4: Execute the UDS automated test, involving the following operations: Operation 1: After initializing the ZCANPRO software, click Advanced Functions, Extend Scripts, select the script file, and click Run to begin executing the test cases in the predetermined order. Operation 2: For each test case (e.g., reading the VIN code), the script will: assemble a complete diagnostic request message according to the UDS protocol. For example, the request message for ReadDataByIdentifier(0x22)F190 is 22F190. By calling the ZCANPRO send_request interface function, the assembled message data, message ID (e.g., 0x756), and other parameters are filled in and sent to the CAN bus. Operation 3: The script then enters the listening state and reads messages on the CAN bus in a loop through the ZCANPRO receive interface function. The system will filter out response messages whose sending address is the target ECU address (0x756) and wait according to the timeout period (P2timeout) of the UDS protocol. Step 4: If a negative response code (NRC) is received, the script does not simply log the failure, but can handle it according to a preset dynamic strategy. For example, if the NRC is 0x22 (Incorrect condition), the script can automatically jump to execute the 0x1003 (Extended Session) and 0x27 (Secure Access) services first, and then retry the original request after completion, thus simulating an intelligent diagnostic process.

[0073] In short, when testing requirements change (such as adjustments to UDS service parameters or the addition of new test scenarios), traditional manual testing requires redesigning and executing all related steps, which is extremely time-consuming and prone to omissions. Meanwhile, fixed automated tools typically require modifications to underlying code or configurations, a complex process. By adopting a script-driven architecture and a design philosophy that separates data from logic, specific test cases, parameters, and process logic are encapsulated in highly readable Python scripts, while the core communication, decision-making, and report generation engines remain stable. When customer requirements change or ECU software iterations require updating test cases, engineers do not need to modify the entire system's core architecture; they only need to centrally modify or supplement the corresponding Python script files (or JSON configuration files). This design localizes the impact of changes, making test suite updates targeted, simple, and extremely time-efficient, thus enabling rapid response to frequent changes during development and significantly reducing the maintenance costs throughout the system's lifecycle. This directly solves the technical challenges of traditional testing methods being slow to react and costly to requirement changes.

[0074] Step 5: Collect and Determine Results; Optionally, the collection process includes: the script records the request messages sent in Step 4, the received response messages (including positive response data or negative response codes), and timestamps in real time to the test directory. The determination process includes: a built-in automatic result determination module in the script. This module compares the actual received response with the predefined expected results in the test case. For positive responses, it compares whether the data content is completely consistent or within the allowable tolerance range. For negative responses, it determines whether the NRC meets expectations (e.g., when testing an unsupported function, the expectation is to receive a specific NRC). Finally, it automatically provides a determination of pass, failure, or error.

[0075] Optionally, the decision logic can be implemented using Python's assertion statements or a custom complex rule engine. For example, if a negative response code of 0x13 (incorrect message length or format) is received, the reason is determined to be an incorrect request message format; if a negative response code of 0x22 (incorrect condition) is received, the possible reasons, based on the test context (such as the current diagnostic session state), are determined to be unmet security access conditions or failure to switch the required session mode.

[0076] This means it doesn't simply perform a pass / fail binary judgment, but instead incorporates intelligent analysis logic based on the UDS protocol. This logic can parse received negative response codes and map them into natural language descriptions with clear implications, such as "secure access not unlocked" or "request out of scope." This intelligent judgment capability elevates testing from simply discovering phenomena to diagnosing the root causes. It can quickly and accurately pinpoint the fault location, directly transforming negative response codes into actionable diagnostic clues, significantly reducing developers' debugging time and decreasing reliance on the extensive experience of testers.

[0077] Step 6: Generate a report. After all test cases have been executed, the script calls the report generation module. This module, based on a pre-designed HTML template, summarizes and formats all the results data collected and judged in Step 5. The report content includes not only detailed requests, responses, and results for each test item, but also automatically calculates key indicators such as the total number of test cases, pass rate, list of failed test cases, and execution time, and may include visual charts, such as a pass rate pie chart.

[0078] Step 7: Upload / Archive and End. Specifically, the generated test report file is automatically saved to the specified directory and can be named according to preset rules, such as including the timestamp TestReport_20231027_143052.html. The script can further automatically upload the report to the company's internal file server and test management system, realizing automatic archiving and publication of test results. Finally, the script calls the dev_auto_send_stop and close interfaces to close the CAN channel and release hardware resources, ending the entire automated testing process.

[0079] Subsequently, detailed logs are automatically recorded during test execution, and a structured test report is created in the report generation step. Finally, all this data is automatically archived through the upload / archive step. Information such as request messages, response messages, judgment results, and timestamps for each test are completely saved, forming a complete data chain. This provides tamper-proof and detailed data support for subsequent quality trend analysis, fault reproduction, and process auditing, achieving transparent and standardized management of the testing process.

[0080] Step 8: Customizing the Report Automation Tool. After the test report is generated, the process enters the final stage of result delivery. To achieve seamless integration with the client's specific format requirements, a separate customized report automation tool is introduced. This tool is an executable program (.exe) independent of the ZCANPRO software environment. It is not a built-in function or plugin of ZCANPRO, but rather a dedicated post-processing module of the entire automated testing system. This design separates the report customization logic from the test execution logic, improving the system's flexibility and maintainability.

[0081] The technical implementation involves compiling the tool into a Python script. The tool can be triggered manually (by the user double-clicking to run it after the test) or automatically (by the main test script calling the .exe program via system command after step 7). Its core function is to read the test result file generated by the preceding steps, which has an intermediate or general format, and then perform format conversion and data rearrangement according to a predefined report template that strictly matches the client's requirements.

[0082] For example, the main test process generates a process file for sending and receiving messages for each test case, which can be a log or txt text file. The customized tool reads this file and then uses Python's reporting library to populate the data into specific locations within a customized Word or Excel template, ultimately generating a final test report (docx, xlsx, etc.) that fully conforms to the client's format requirements. This tool is coupled to the core test process through a file interface. That is, the output of the core test process (the original result file) serves as the input to this tool. This design ensures that changes to the report format do not affect the core test logic; only the tool needs to be updated.

[0083] It's worth noting that by introducing a separate, customized report automation tool, the core testing logic is decoupled from the report output format. This tool specifically handles how to populate client-specific report templates with common test result data. This modular design allows the system to quickly adapt to the personalized report format requirements of different clients and projects without altering the core testing workflow. Simultaneously, this architecture facilitates future expansion with new testing functionalities or integration into more complex CI / CD systems, enhancing the solution's lifecycle and applicability.

[0084] As an alternative implementation, a central scheduling engine written in a high-level scripting language (such as Python) is designed. This engine can read and parse a predefined structured configuration file (such as JSON format), which describes the complete test sequence, parameters, and expected results. The engine then automatically and sequentially calls the application programming interfaces (APIs) of the underlying testing tools (such as ZCANPRO) to dynamically complete a series of steps, including test environment initialization, test case execution, result monitoring, and resource reclamation, thereby achieving full-process automation without human intervention. This avoids the current approach where existing technologies mostly involve manual step-by-step operation of testing tools or the use of the tools' built-in, fixed-function recording and playback and linear scripting features. It enables a higher level of flexible and customizable intelligent scheduling, significantly improving the intelligence and adaptability of testing.

[0085] As an optional implementation, during automated testing, when a Negative Response Code (NRC) is received from the ECU, the system's built-in judgment module automatically parses the specific meaning of the NRC according to the UDS protocol standard, mapping it to clearly identifiable natural language diagnostic information such as condition not met or request sequence error. The system integrates this information with the test context to automatically determine the final state (pass / fail) of the test case and record the root cause, rather than simply performing binary yes / no judgments or relying on manual analysis. This solves the problem that existing automated solutions typically only determine whether communication was successful or the response matched, failing to deeply diagnose the specific reasons for failure. It improves the accuracy and efficiency of problem localization and reduces reliance on the tester's experience.

[0086] As an optional implementation, a decoupled architecture is adopted. The test engine is responsible for executing tests and generating a structured, intermediate-format test result data file (such as JSON or XML). Subsequently, a separate report generator (such as an executable program compiled from a Python script) reads this result file and automatically generates a final test report conforming to specific format requirements (such as Word, Excel, or PDF) based on a predefined, flexibly configurable report template. This avoids the common practice in existing technologies of tightly binding report generation functionality to testing tools, resulting in fixed report formats. Furthermore, through decoupling, report generation is independent of the core testing logic, enabling flexible customization and rapid adaptation of report formats, thus enhancing the system's scalability and usability.

[0087] In summary, by seamlessly integrating multiple steps such as loading configuration and scripts, initializing ZCANPRO, executing UDS automated tests, collecting and judging results, generating reports, and uploading / archiving, a complete automated pipeline is constructed. Without human intervention, it automatically completes all tasks from environment preparation, test execution, result judgment to report generation. This completely eliminates the inherent delays, fatigue, and random errors of manual operations, not only improving testing efficiency by orders of magnitude but also ensuring complete consistency in execution conditions, judgment criteria, and process records for each test. This significantly enhances the reliability and comparability of test results, achieving full automation and high consistency in UDS diagnostic testing, greatly improving testing efficiency and reliability.

[0088] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0089] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0090] According to another aspect of the embodiments of this application, a test result determination apparatus is also provided. This apparatus can be used to implement the test result determination method provided in the above embodiments, and details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0091] Figure 5 is a structural block diagram of an optional test result determination device according to an embodiment of this application. As shown in Figure 5, the test result determination device includes:

[0092] The reading module 402 is used to read a target file for operating and controlling the electronic control unit from a storage device, wherein the target file includes: a test data package, test parameters, and a configuration file of expected results;

[0093] The scheduling module 404 is used to determine the test logic corresponding to the target file and schedule the target interface that conforms to the test logic to start the test case process; wherein, the test logic includes at least one of the following: loop logic, conditional branch logic, and exception retry logic;

[0094] The determination module 406 is used to monitor the test case process, generate target monitoring results, and determine the final test result of the target file based on the response message and response code in the target monitoring results.

[0095] It should be noted that the acquisition module 402 in this embodiment can be used to perform the above step S202, the determination module 404 in this embodiment can be used to perform the above step S204, and the detection module 406 in this embodiment can be used to perform the above step S206.

[0096] The embodiments provided in this application read target files for controlling the operation of an ECU from a storage device. The target files contain test data packages, test parameters, and configuration files for expected results. Using a standard library of a high-level scripting language (such as Python), the data in the configuration files is parsed and loaded into memory as input for subsequent tests. The test logic corresponding to the target files is dynamically determined, including but not limited to loop logic, conditional branch logic, or exception retry logic. Based on this logic, the corresponding test interfaces (APIs) are scheduled to initiate the test case testing process, automating the execution of UDS diagnostic services, such as reading data identifiers (DIDs), performing session control, and secure access, without manual intervention. During the testing process, the test case testing process is continuously monitored, generating target monitoring results. Specifically, when a response message from the ECU is received, the final state of the test case (pass, fail, or error) is automatically determined based on the response code (NRC or PRC) in the response message, combined with predefined test logic and parameters. The final test results are recorded, including the request message, response message, determination result, and possible fault cause analysis. Therefore, it can solve the technical problems of complex test processes and inconvenient large-scale management, thereby improving the automation level, accuracy, and flexibility of diagnostic testing, and reducing the technical complexity and time cost of test case iteration and maintenance.

[0097] In an exemplary embodiment, the aforementioned determining module is further configured to read multiple real-time messages generated by the test case process through an interface loop function; filter response messages containing a target address from the multiple real-time messages, wherein the target address is the address corresponding to the electronic control unit in the vehicle network; obtain code information for a preset duration after the occurrence of the response message to obtain a response code; and summarize the response messages and response codes to generate target monitoring results.

[0098] In an exemplary embodiment, the above apparatus further includes: an adjustment module, configured to monitor the test case testing process, generate a target monitoring result, and, in the case of a negative response code, determine the code byte corresponding to the response code and the test failure type corresponding to the code byte; adjust the test case testing process according to the test failure type and the preset processing strategy corresponding to the test failure type; and, if the adjustment is successful, diagnose whether the test case testing process is complete based on the final output response message after adjustment.

[0099] In an exemplary embodiment, the above apparatus further includes: a generation module, configured to determine the test logic corresponding to the target file and schedule the target interface that conforms to the test logic to start the test case process, and then generate a diagnostic request message corresponding to the current test case process based on a preset protocol; synchronize the diagnostic request message and the identifier corresponding to the diagnostic request message to the controller local area network of the vehicle where the electronic control unit is located through a sending interface function; and enable the diagnostic request message corresponding to the current test case when the electronic control unit participates in the current test case test.

[0100] In an exemplary embodiment, the determining module is further configured to, when the response message is a positive response message, compare the data content carried in the response message with the target data content corresponding to the configuration file, and determine the final test result based on the comparison result; when the response message is a negative response message, determine the matching result between the response code and the expected code set of the configuration file, and determine the final test result based on the matching result.

[0101] In an exemplary embodiment, the determining module is further configured to generate a final test result indicating that the test has passed if the similarity between the comparison result indicating the data content and the target data content is greater than a preset similarity threshold; and to generate a final test result indicating that the test has failed if the similarity between the comparison result indicating the data content and the target data content is less than or equal to the preset similarity threshold.

[0102] In an exemplary embodiment, the determining module is further configured to generate a final test result indicating that the test has passed if the matching result indicates that the response code has a matching object in the expected code set; and to generate a final test result indicating that the test has failed or is incorrect if the matching result indicates that the response code has no matching object in the expected code set.

[0103] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0104] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein the program executes the steps in any of the above method embodiments when it is run.

[0105] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0106] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps of any of the method embodiments described above via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0107] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0108] According to another aspect of the embodiments of this application, a computer program product is also provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit 501, it performs various functions provided in the embodiments of this application. The sequence numbers of the embodiments of this application above are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0109] Figure 6 schematically illustrates a computer system architecture block diagram for an electronic device implementing embodiments of the present application. As shown in Figure 6, the computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes according to a program stored in ROM 502 or a program loaded from storage portion 508 into RAM 503. Random access memory 503 also stores various programs and data required for system operation. The CPU 501, read-only memory 502, and random access memory 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0110] The following components are connected to I / O interface 505: input section 506 including keyboard, mouse, etc.; output section 507 including cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; storage section 508 including hard disk, etc.; and communication section 509 including network interface card, modem, etc. Communication section 509 performs communication processing via a network such as the Internet. Drive 510 is also connected to I / O interface 505 as needed. Removable media 511, such as disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 510 as needed so that computer programs read from them can be installed into storage section 508 as needed.

[0111] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit 501, it performs various functions defined in the system of this application.

[0112] It should be noted that the computer system 500 of the electronic device shown in Figure 6 is only an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0113] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0114] 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 principles of this application should be included within the protection scope of this application.

Claims

1. A method for determining test results, characterized in that, include: The system reads a target file from a storage device for operating and controlling the electronic control unit. The target file contains a configuration file of test data packets, test parameters, and expected results. It then determines the test logic corresponding to the target file and schedules a target interface conforming to the test logic to initiate a test case process. The test logic includes at least one of the following: loop logic, conditional branch logic, or exception retry logic. The system monitors the test case process, generates target monitoring results, and determines the final test result of the target file based on the response messages and response codes in the target monitoring results.

2. The method according to claim 1, characterized in that, The process of monitoring the test cases and generating target monitoring results includes: reading multiple real-time messages generated by the test cases through an interface loop function; filtering response messages containing a target address from the multiple real-time messages, wherein the target address is the address of the electronic control unit in the vehicle network; obtaining code information for a preset duration after the occurrence of the response message to obtain a response code; and summarizing the response messages and the response code to generate target monitoring results.

3. The method according to claim 1, characterized in that, After monitoring the test case testing process and generating target monitoring results, the method further includes: if the response code is a negative response code, determining the code byte corresponding to the response code and the test failure type corresponding to the code byte; adjusting the test case testing process according to the test failure type and the preset processing strategy corresponding to the test failure type; and if the adjustment is successful, diagnosing whether the test case testing process is complete based on the final output response message after adjustment.

4. The method according to claim 1, characterized in that, After determining the test logic corresponding to the target file and scheduling the target interface that conforms to the test logic to start the test case process, the method further includes: generating a diagnostic request message corresponding to the current test case process based on a preset protocol; synchronizing the diagnostic request message and the identifier corresponding to the diagnostic request message to the controller local area network of the vehicle where the electronic control unit is located through a sending interface function; and enabling the diagnostic request message corresponding to the current test case when the electronic control unit participates in the current test case test.

5. The method according to claim 1, characterized in that, Determining the final test result of the target file based on the response message and response code in the target monitoring result includes: if the response message is a positive response message, comparing the data content carried by the response message with the target data content corresponding to the configuration file, and determining the final test result based on the comparison result; if the response message is a negative response message, determining the matching result of the response code with the expected code set of the configuration file, and determining the final test result based on the matching result.

6. The method according to claim 5, characterized in that, When the response message is a positive response message, the data content carried in the response message is compared with the target data content corresponding to the configuration file, and the final test result is determined based on the comparison result, including: if the comparison result indicates that the similarity symbol between the data content and the target data content is greater than a preset similarity threshold, a final test result indicating that the test has passed is generated; if the comparison result indicates that the similarity symbol between the data content and the target data content is less than or equal to the preset similarity threshold, a final test result indicating that the test has failed is generated.

7. The method according to claim 5, characterized in that, When the response message is a negative response message, determine the matching result between the response code and the expected code set of the configuration file, and determine the final test result based on the matching result, including: if the matching result indicates that the response code has a matching object in the expected code set, generate a final test result indicating that the test passed; if the matching result indicates that the response code does not have a matching object in the expected code set, generate a final test result indicating that the test failed or the test was incorrect.

8. A device for determining test results, characterized in that, include: A reading module is used to read a target file for operating and controlling the electronic control unit from a storage device. The target file contains a configuration file containing test data packets, test parameters, and expected results. A scheduling module is used to determine the test logic corresponding to the target file and schedule the target interface that conforms to the test logic to start the test case process. The test logic includes at least one of the following: loop logic, conditional branch logic, and exception retry logic. A determining module is used to monitor the test case process, generate target monitoring results, and determine the final test result of the target file based on the response messages and response codes in the target monitoring results.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.

10. 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 computer program, it implements the steps of the method according to any one of claims 1 to 7.

Images