A test method, test system, storage medium and computer program product

By automatically configuring and testing the registers of the CAN controller via a host computer, the problem of low testing efficiency of the CAN controller message filtering function is solved, achieving efficient and accurate automated testing, and providing detailed performance evaluation and fault analysis.

CN122111772APending Publication Date: 2026-05-29PHYTIUM TECH CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
PHYTIUM TECH CO LTD
Filing Date
2026-02-11
Publication Date
2026-05-29

AI Technical Summary

Technical Problem

In existing technologies, the message filtering function of CAN controllers is inefficient to test, making it difficult to cover all transmitted message ID values ​​and ACC_ID/ACC_ID_MASK configuration values. Furthermore, the recording of test results is time-consuming and error-prone, and test metrics cannot be quantified.

Method used

The host computer automatically configures the registers of the target controller, determines the target ID range based on the current register information, and automatically tests the message filtering function by actually receiving messages and test information, thereby achieving automated testing and reducing the delay and error of manual operation.

Benefits of technology

It improves testing efficiency and accuracy, reduces testing time overhead, ensures the accuracy and consistency of configuration, and provides quantitative performance evaluation and fault identification capabilities.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122111772A_ABST
    Figure CN122111772A_ABST
Patent Text Reader

Abstract

The embodiment of the specification provides a test method, which can be executed by a host computer and used for testing a message filtering function of a target controller in a device under test. When the method is implemented, current register information of the target controller is automatically acquired after a target test case is executed, and a target ID range is determined according to the register information. Then, based on test information such as the actual received message and the target ID range, the filtering function test is automatically completed. The method can automatically configure the controller through register configuration information in the test case, and automatically acquire the register state after the test, so that full-process automation is realized. This avoids errors, delays and interruptions that may be introduced by manual configuration, reading records and result checking, and significantly improves the continuity, efficiency and accuracy of the test process.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This specification relates to the field of computer technology, specifically to hardware testing technology in the field of computer technology, and more specifically to a testing method, testing system, storage medium, and computer program product. Background Technology

[0002] In the development of Device Under Test (DUT), performance testing of the DUT (such as controllers) is a crucial means of guiding hardware development and optimization. Taking CAN (Controller Area Network) controllers as an example, CAN controllers are widely used in automotive electronics, industrial control, aerospace, and other fields to achieve reliable communication between multiple nodes. Testing the CAN controller before it leaves the factory is essential to ensuring a solid and reliable communication foundation for the entire CAN bus-based system. However, currently, the testing efficiency of DUTs is relatively low. Summary of the Invention

[0003] This specification provides a test method, test system, storage medium, and computer program product to improve the testing efficiency of the device under test.

[0004] To achieve the above technical objectives, the embodiments of this specification provide the following technical solutions: In one aspect, one embodiment of this specification provides a test method for testing the message filtering function of a target controller of a device under test, the test method comprising: In response to the completion of the target test case, the current register information of the target controller is obtained, and the target ID range is determined based on the current register information. The current register information is used to characterize the target ID range of the target controller, and the current register information is configured by the register configuration information in the target test case. Based on the test information, the message filtering function of the target controller is tested. The test information includes the actual received messages and the target ID range. The actual received messages are the messages actually received by the target controller.

[0005] Secondly, one embodiment of this specification provides a test system, including: a host computer and a device under test; the device under test includes a target controller, and the host computer is configured to: In response to the completion of the target test case, the current register information of the target controller is obtained, and the target ID range is determined based on the current register information. The current register information is used to characterize the target ID range of the target controller, and the current register information is configured by the register configuration information in the target test case. Based on the test information, the message filtering function of the target controller is tested. The test information includes the actual received messages and the target ID range. The actual received messages are the messages actually received by the target controller.

[0006] Thirdly, one embodiment of this specification also provides a computing 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 above.

[0007] Fourthly, one embodiment of this specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the test method described above.

[0008] Fifthly, embodiments of this specification provide a computer program product or computer program, the computer program product including a computer program stored in a computer-readable storage medium; a processor of a computer device reads the computer program from the computer-readable storage medium, and when the processor executes the computer program, it implements the steps of the above-described testing method. Optionally, the computer program may be stored in a computer-readable storage medium or in the cloud; the processor of the computer device reads the computer program from the readable storage medium or in the cloud.

[0009] As can be seen from the above technical solution, the test method provided in this specification can be implemented by a host computer, meeting the test requirements for the message filtering function of the target controller of the device under test. During the test, the host computer can obtain the current register information of the target controller after the target test case is executed, and determine the target ID range of the target controller based on the current register information. Then, the message filtering function of the target controller can be tested according to the test information, meeting the test requirements of the message filtering function of the target controller. Throughout the test process, the host computer can configure the registers of the target controller according to the register configuration information in the target test case, and automatically obtain the current register information of the target controller after the test is completed. At the same time, during the execution of the target test case, the host computer can obtain test information (which may include the actual received messages and the target ID range), and test the message filtering function of the target controller according to the test information, realizing automatic testing of the message filtering function of the target controller. There is no need for manual intervention to read or record the target ID range, avoiding the time delay and possible interruption of manual operation, making the test process continuous and fast, directly reducing the time overhead of the test process, and improving test efficiency. In addition, throughout the testing process, the host computer can automatically configure the registers of the target controller based on the register configuration information in the target test cases, eliminating the errors and repetitive work that may be introduced by manually configuring registers item by item, and ensuring the accuracy and consistency of the configuration. During the testing of the message filtering function, there is no need to manually check the messages against the expected range, which is time-consuming and prone to errors. This improves the testing efficiency and accuracy at the same time. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this specification. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0011] Figure 1 This is a schematic diagram illustrating an application scenario provided for one embodiment of this specification.

[0012] Figure 2 This is a flowchart illustrating a test method provided for one embodiment of this specification.

[0013] Figure 3 This is a schematic diagram of a test system provided for one embodiment of this specification.

[0014] Figure 4 This is a schematic diagram of the structure of a computing device provided for one embodiment of this specification. Detailed Implementation

[0015] Unless otherwise defined, the technical or scientific terms used in the embodiments of this specification shall have the ordinary meaning understood by one of ordinary skill in the art to which this specification pertains. The terms "first," "second," and similar terms used in the embodiments of this specification do not indicate any order, quantity, or importance, but are merely used to avoid confusion of constituent elements.

[0016] Unless the context otherwise requires, throughout this specification, "a plurality of" means "at least two," and "including" is interpreted as open-ended or encompassing, that is, "including, but not limited to." In the description of this specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this specification. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example.

[0017] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0018] Overview Taking CAN (Controller Area Network) controllers as an example, CAN controllers are widely used in automotive electronics, industrial control, aerospace, and other fields. The stable operation of a system integrating a CAN controller depends on the stability and correctness of CAN communication. If CAN communication malfunctions, the system may receive and send incorrect data, potentially causing the entire system to malfunction and severely impacting its safe and reliable operation.

[0019] Therefore, in the development of devices integrated with a CAN controller (hereinafter referred to as the device under test), functional testing of the CAN controller is of great significance for ensuring the safe and reliable operation of the device under test. For example, the message filtering function of the CAN controller can filter messages transmitted in the CAN bus in real time, receiving only messages that meet the rules and sending them to the subsequent processing flow. This can ensure system performance and resource optimization, reduce the number of messages that the system needs to process, and improve system performance. If the message filtering function of the CAN controller is abnormal, on the one hand, it may cause the CAN controller to receive a large number of irrelevant messages, resulting in a significant increase in the number of messages that the processor needs to process, wasting processor resources. On the other hand, a large number of irrelevant messages occupying bus transmission time and receive buffer may cause the processor to be unable to respond to high-priority messages in a timely manner, failing to meet the real-time communication requirements.

[0020] Currently, the message filtering function of CAN controllers is mainly tested using static configuration testing. This involves manually configuring a limited number of ACC_ID (Acceptance Code Register) / ACC_ID_MASK (Acceptance Mask Register) combinations and sending preset ID messages to verify the CAN controller's filtering results. However, this testing method is inefficient. Firstly, it requires manually writing test cases, making it difficult to cover all ID values ​​and ACC_ID / ACC_ID_MASK configuration values ​​of the sent messages (such as the 29-bit extended frame's 2...). 29 (In one case), on the other hand, it is necessary to record the test results one by one, and can only record whether the filtering was successful, and cannot quantify the test indicators.

[0021] To address this issue, a testing method is proposed that can be implemented by a host computer to meet the testing requirements of the message filtering function of the target controller of the device under test (DUT). During the testing process, the host computer can obtain the current register information of the target controller after the target test case is executed, and determine the target ID range of the target controller based on the current register information. Then, based on the test information, the message filtering function of the target controller can be tested to meet the testing requirements. Throughout the testing process, the host computer can configure the registers of the target controller according to the register configuration information in the target test case, and automatically obtain the current register information of the target controller after the test is completed. Simultaneously, during the execution of the target test case, the host computer can obtain test information (which may include the actual received messages and the target ID range), and test the message filtering function of the target controller based on the test information. This achieves automated testing of the message filtering function of the target controller, eliminating the need for manual intervention to read or record the target ID range, avoiding time delays and potential interruptions caused by manual operation, making the testing process continuous and fast, directly reducing the time overhead of the testing process, and improving testing efficiency. In addition, throughout the testing process, the host computer can automatically configure the registers of the target controller based on the register configuration information in the target test cases, eliminating the errors and repetitive work that may be introduced by manually configuring registers item by item, and ensuring the accuracy and consistency of the configuration. During the testing of the message filtering function, there is no need to manually check the messages against the expected range, which is time-consuming and prone to errors. This improves the testing efficiency and accuracy at the same time.

[0022] Furthermore, test cases can also be automatically generated based on the host computer, which can automatically traverse the message IDs of standard frames and extended frames under various test scenarios to meet the needs of comprehensive testing of the target controller.

[0023] Based on the above concept, this specification provides a testing method. The testing method provided by this specification will be described exemplarily below with reference to the accompanying drawings.

[0024] Exemplary scenario refer to Figure 1 , Figure 1 This document illustrates a feasible application scenario for the test method provided in the embodiments of this specification. In this scenario, the test method can be implemented by the host computer 10 to test the device under test 20. Alternatively, the test method can be implemented jointly by the host computer 10 and the device under test 20, meaning that the host computer 10 and the device under test 20 each implement a portion of the test method's steps. This specification does not limit the application of this method; the specific implementation depends on the actual situation.

[0025] The host computer 10 can be a computing device with functions such as computing and storage, including but not limited to a computer; the device under test 20 can be a device including the target controller 22 under test, including but not limited to a system on chip (SOC). In addition to the target controller 22 under test, the device under test 20 may also include a transmission controller 21 for sending messages, so as to facilitate the implementation of test cases.

[0026] During testing, the host computer 10 can automatically generate test cases covering different message IDs required for testing in various test scenarios. When the test cases are executed, the host computer 10 can configure the target controller 22 in the device under test 20 according to the register configuration information in the test cases, write the messages in the test cases to the sending controller 21, and send the messages in the test cases to the target controller 22 based on the sending controller 21. During message transmission, the host computer 10 can monitor the message reception status of the target controller 22 and test the message filtering function of the target controller 22 based on the collected test information. (Refer to...) Figure 1 The host computer 10 can establish a communication connection with the transmitting controller 21 and receiving controller (i.e., target controller 22) in the device under test 20 via the CAN bus.

[0027] Exemplary methods This specification provides a test method, such as... Figure 2 As shown, the test method for testing the message filtering function of the target controller 22 of the device under test 20 includes: S201: In response to the completion of the target test case execution, obtain the current register information of the target controller 22, determine the target ID range based on the current register information, the current register information is used to characterize the target ID range of the target controller 22, and the current register information is configured by the register configuration information in the target test case; S202: Based on the test information, test the message filtering function of the target controller 22. The test information includes the actual received messages and the target ID range. The actual received messages are the messages actually received by the target controller 22.

[0028] In this embodiment, the completion of the target test case can serve as a trigger condition for obtaining the current register information of the target controller 22. After the target test case is completed, the host computer 10 can obtain the register state of the target controller 22 at the time of the target test case completion through a triggered register snapshot. This current register information includes, but is not limited to, information such as ACC_ID and ACC_ID_MASK. As mentioned above, ACC_ID and ACC_ID_MASK work together to determine the ID range of messages that the target register can receive (i.e., the target ID range). In some embodiments, the current register information may also include information such as message receiving mode and message receiving rate.

[0029] The test information can be determined by the host computer 10 based on the target test case and its execution process. For example, the host computer 10 can determine the actual received message by monitoring the messages received by the target controller 22 during the execution of the target test case. After determining the actual received message and the target ID range, the message filtering function of the target controller 22 can be tested based on the ID of the actual received message and the target ID range (e.g., whether messages outside the target ID range were received).

[0030] In summary, during the testing process, the host computer 10 can obtain the current register information of the target controller 22 after the target test case is executed, and determine the target ID range of the target controller 22 based on the current register information. Then, based on the test information, it can test the message filtering function of the target controller 22 to meet the testing requirements of the message filtering function. Throughout the testing process, the host computer 10 can configure the registers of the target controller 22 according to the register configuration information in the target test case, and automatically obtain the current register information of the target controller 22 after the test is completed. Simultaneously, during the execution of the target test case, the host computer 10 can obtain test information (which may include the actual received messages and the target ID range), and test the message filtering function of the target controller 22 based on the test information. This achieves automatic testing of the message filtering function of the target controller 22 without manual intervention to read or record the target ID range, avoiding time delays and potential interruptions caused by manual operation. This makes the testing process continuous and fast, directly reducing the time overhead of the testing process and improving testing efficiency. In addition, throughout the testing process, the host computer 10 can automatically configure the registers of the target controller 22 based on the register configuration information in the target test case, eliminating the errors and repetitive work that may be introduced by manually configuring registers item by item, ensuring the accuracy and consistency of the configuration. During the test of the message filtering function, there is no need to manually check the messages against the expected range, which is time-consuming and prone to errors. This improves the test efficiency and accuracy at the same time.

[0031] In one implementation, the test information further includes actual sent messages, which are messages that need to be sent as defined in the target test case; The step of testing the message filtering function of the target controller 22 based on the test information includes: Based on the test information, the filtering accuracy of the target controller 22 is determined. The filtering accuracy is the ratio of the number of correctly filtered frames to the total number of test frames. The number of correctly filtered frames includes the number of correctly received packets and the number of correctly filtered packets. The number of correctly received packets is the number of packets whose IDs are within the target ID range in the actual received packets. The number of correctly filtered packets is the number of packets whose IDs are outside the target ID range in the actual sent packets that were not received by the target controller 22.

[0032] In this embodiment, the host computer 10 can determine the actual sent messages based on the target test cases. Based on the actual sent messages, the actual received messages, and the target ID range, information such as the number of correctly received messages, the number of correctly filtered messages, and the total number of test frames for the target controller 22 can be determined. The total number of test frames can refer to the total number of messages used for testing in the target test cases; in some embodiments, the total number of test frames can be the number of messages actually sent.

[0033] In this embodiment, by determining the filtering accuracy of the target controller 22, the relevant performance of the message filtering function of the target controller 22 can be quantitatively evaluated, laying the foundation for accurately evaluating the message filtering function of the target controller 22.

[0034] In addition to the filtering accuracy as one metric, in one embodiment, after determining the filtering accuracy of the target controller 22 based on the test information, the method further includes: Based on the test information, the misfiltering information of the target controller 22 is determined. The misfiltering information includes false positives and false negatives. A false positive is a message whose ID is outside the target ID range among the actual received messages. A false negative is a message within the target ID range among the messages not received by the target controller 22.

[0035] In this embodiment, by using false filtering information, it is possible to assess whether the target controller 22 experiences false positives and / or false negatives during the message filtering process. This allows for the accurate identification of specific modes of filtering function failure. In addition to providing filtering accuracy, it offers testers richer fault information, providing a basis for determining the fault location of the target controller 22's message filtering function. For example, a false positive may indicate a defect in the target controller 22's comparison logic, causing unacceptable messages to be allowed to pass; a false negative may indicate a register configuration error or a blocked receive path. This specific distinction between error types provides clear directional guidance for subsequent debugging and optimization.

[0036] To comprehensively evaluate the packet filtering function of the target controller 22, in one embodiment, the testing of the packet filtering function of the target controller 22 based on test information further includes: Based on the receive timestamp and the send timestamp, delay information is calculated. The receive timestamp represents the time when the actual received message is received by the target controller 22, and the send timestamp represents the time when the actual sent message is sent. The delay information includes at least one of average delay, maximum delay, and delay distribution. The time difference between the receive timestamp and the send timestamp corresponding to the same message is the delay of the message. The throughput of the target controller 22 is determined based on the number of messages processed by the target controller 22 per unit time.

[0037] In this embodiment, by calculating the time difference (delay) between sending and receiving the same message and performing statistical analysis on the delays of multiple messages, this method can objectively and quantitatively measure the message processing timeliness of the target controller 22. For example, the average delay reflects normal performance, while the maximum delay and delay distribution can reveal worst-case scenarios and performance stability. Furthermore, in this embodiment, by calculating the number of messages successfully processed per unit time (throughput), this method can directly measure the data processing capacity limit of the controller under continuous load, and simultaneously determine the actual throughput of the target controller 22, thus evaluating the performance of the target controller 22 at different baud rates (e.g., 10kbps~5Mbps).

[0038] In one embodiment, testing the message filtering function of the target controller 22 based on test information further includes: Based on the first verification information of the actually sent message and the second verification information of the actually received message, it is determined whether there is a bit error. The bit error indicates that the first verification information of the actually sent message and the second verification information of the actually received message do not match. Based on the timestamp of the actual sent message, determine whether a frame loss error exists; the frame loss error indicates that the actual sent message was not received by the target control within a predetermined time. Based on the reception time interval of actual received messages with the same ID, determine whether there is a duplicate reception error; the duplicate reception error indicates that the reception time interval of actual received messages with the same ID is less than the reception interval threshold.

[0039] The scheduled time can be calculated based on the baud rate.

[0040] In this embodiment, three types of anomalies that may occur during the test can be identified: bit errors, frame loss, and repeated reception. This clarifies the general filtering failure / test failure in related technologies into specific and definable error modes, laying the foundation for accurately locating the anomaly in the target controller 22.

[0041] Specifically, bit errors can help expose problems such as physical layer interference or hardware failures; frame loss errors indicate that the target controller 22 may have problems such as filter configuration errors. For example, if the filtering of a specific ID bit fails (such as bit 7 always not matching), it may mean that there is a hardware problem. If the register configuration timing does not meet the chip manual requirements, it may mean that there is a software problem, etc.; repeated reception errors indicate that there may be problems such as software deduplication logic failure.

[0042] In one implementation, a feasible execution process for a target test case is provided, specifically, the register configuration information includes: first configuration information and second configuration information; The device under test 20 includes a transmitting controller 21 and a target controller 22. The execution process of the target test case includes: The target test case is parsed to obtain the register configuration information; Based on the first configuration information, configure the first type of register of the sending controller 21 to determine the message sending mode and message sending rate of the sending controller 21; Based on the first configuration information, configure the first type of registers of the target controller 22 to determine the message receiving mode and message receiving rate of the target controller 22; Based on the second configuration information, configure the second type of register of the target controller 22 to determine the target ID range; The message determined by the target test case is written into the sending controller 21, and the sending controller 21 is controlled to send the message in a determined message sending mode and message sending rate.

[0043] In this embodiment, by parsing test cases into first configuration information and second configuration information, and automatically configuring the first type of registers of the sending controller 21 and the first and second type of registers of the target controller 22 based on this, the sending controller 21 is ultimately controlled to send messages, thus realizing a highly integrated automated testing process. This embodiment eliminates the tedious, error-prone, and time-consuming problems associated with manually configuring controller modes, rates, and filtering parameters one by one in traditional testing, thereby significantly improving the automation level and overall efficiency of test execution, and ensuring the consistency and repeatability of the testing process.

[0044] In one embodiment, the first type of register includes a mode register and a rate register, wherein the value of the mode register is used to characterize the ID mode of the transmitted or received message, and the value of the rate register is used to characterize the rate of the transmitted or received message. The second type of register includes a matching register and a mask register. The value of the matching register is used to represent the ID of the target message, and the value of the mask register is a mask of the ID of the target message. The mask is used to represent whether the ID of the message that the target controller 22 can receive needs to match each bit of the ID of the target message.

[0045] The message ID mode can include at least one of standard frames and extended frames. The standard frame ID length can be 11 bits, with a range of 0 to 2047; the extended frame ID length can be 29 bits, with a range of 0 to 536870911. The match register configures the ACC_ID, and the mask register configures the ACC_ID_MASK. The rate register configures the controller's transmit and receive rates.

[0046] In this implementation, the test intent (such as whether to test a standard frame or an extended frame, what baud rate to use, and what filtering rules to set) can be accurately mapped to specific register operations. This not only enhances the reliability of the test configuration and the accuracy of the test results, but also lays a clear and scalable technical foundation for the systematic and batch generation and execution of test scenarios covering various modes, rates, and combinations of filtering rules, thereby greatly improving the coverage and systematic nature of the test.

[0047] In one implementation, a feasible process for generating target test cases is provided. Specifically, the testing method further includes: Based on the target test scenario, the message IDs specified in the target test scenario are traversed to automatically generate target test cases corresponding to the target test scenario; the target test scenario includes: single ID scenario, specified range scenario, boundary value scenario and mixed frame scenario. The single-ID scenario refers to the scenario where the target controller 22 only receives packets with an ID of a first value; the specified range scenario refers to the scenario where the target controller 22 only receives packets with IDs within a specified range; the boundary value scenario refers to the scenario where the target controller 22 only receives packets with an ID of a second value; and the mixed frame scenario refers to the scenario where the target controller 22 receives packets with IDs of a first mode and a second mode. The first value includes at least one of the minimum and maximum values ​​of the packet ID and a first target value, and the first target value is different from both the minimum and maximum values. The second value includes at least one of the minimum and maximum values ​​of the packet ID, the first target value, and a second target value, and the adjacent data bits of the second target value have different values. The first mode includes a mode with an 11-bit packet ID, and the second mode includes a mode with a 29-bit packet ID. The target test cases include messages that are expected to be received by the target controller 22 and messages that are expected to be filtered by the target controller 22.

[0048] In some cases, both the first value and the second value refer to specific values ​​of the message ID. The first value and the second value can be the same or different. This specification does not limit this and it depends on the actual situation.

[0049] In this implementation, by automatically traversing specified message IDs to generate test cases containing expected received and expected filtered messages based on four key test scenarios—single ID, specified range, boundary value, and mixed frame—the system achieves a shift from manual design to automatic generation, thereby greatly improving the efficiency of test case generation and the systematic coverage capability. Specifically, the automatic message traversal based on the host computer 10 ensures exhaustive or high-density coverage of ID value ranges (such as extreme values, normal values, and special bit patterns) and frame formats (11-bit and 29-bit IDs) in various scenarios. This not only completely avoids omissions, inconsistencies, and subjective limitations that may occur with manual coding, but also provides a standardized, reproducible, and complete set of test inputs for comprehensively and deeply verifying the behavior of the controller's filtering logic under various extreme, typical, and mixed conditions, fundamentally improving the reliability of the test and the authority of the evaluation results.

[0050] In one embodiment, after obtaining the register configuration information of the target controller 22, the method further includes: Determine whether the register configuration information matches the current register information. If not, determine that the software configuration or driver configuration of the device under test 20 is incorrect.

[0051] In this embodiment, by checking the matching between the register configuration information and the current register information, it is possible to detect whether there is an abnormality in the register configuration process of the target controller 22, thereby determining whether the software configuration or driver configuration of the device under test 20 is abnormal.

[0052] In one specific implementation, a feasible implementation process of the test method provided in this specification is given: S01: Test Case Generation. Based on the test scenario (such as single ID scenario, specified range scenario, boundary value scenario, and mixed frame scenario), automatically traverse the message IDs specified in the test scenario and automatically generate target test cases.

[0053] The following pseudocode describes each target test case. In the code below, the key fields of each target test case may include: "type" indicates the test scenario (single ID scenario, range scenario, edge scenario, and mixed frame scenario); "match" indicates the value of the match register (i.e., ACC_ID); "mask" indicates the value of the mask register (i.e., ACC_MASK_ID); in the mixed frame scenario: "std_match" indicates the value of the match register of the standard frame (i.e., ACC_ID), and "ext_match" indicates the value of the match register of the extended frame.

[0054] def generate_test_cases(): # Generate target test cases (11-bit ID) in standard frame mode std_cases = [ # Single ID scenario: {"type": "single", "match": 0x000, "mask": 0x7FF}, # Minimum ID test {"type": "single", "match": 0x7FF, "mask": 0x7FF}, # Maximum ID Test {"type": "single", "match": 0x100, "mask": 0x7FF}, # Regular ID test # Specified range scenario: {"type": "range", "match": 0x100, "mask": 0x700}, # Matches the high 3 bits (0x100-0x1FF) {"type": "range", "match": 0x000, "mask": 0x000}, # Full receive mode test {"type": "range", "match": 0x7FF, "mask": 0x000}, # Full Filter Mode Test # Boundary value scenarios: {"type": "edge", "match": 0x000, "mask": 0x7FF}, # Match all values ​​for the smallest ID {"type": "edge", "match": 0x7FF, "mask": 0x000}, # Filter all maximum IDs {"type": "edge", "match": 0x555, "mask": 0x555}, # Alternating bit pattern test # Hybrid Frame Scene: {"type": "mixed", "std_match": 0x100, "ext_match":0x10000000, "mask": 0x7FF} # Test cross-format for the same ID value ] # Generate target test cases (29-bit ID) for extended frame mode ext_cases = [ # Single ID scenario: {"type": "single", "match": 0x00000000, "mask": 0x1FFFFFFF},# Minimum ID test {"type": "single", "match": 0x1FFFFFFF, "mask": 0x1FFFFFFF},# Maximum ID test {"type": "single", "match": 0x10000000, "mask": 0x1FFFFFFF},# Regular ID test # Specified range scenario: {"type": "range", "match": 0x10000000, "mask": 0x1F000000}, # Matches the high 5 bits (0x10000000-0x1FFFFFFF) {"type": "range", "match": 0x00000000, "mask": 0x00000000},# Full receive mode test {"type": "range", "match": 0x1FFFFFFF, "mask": 0x00000000},# Full filtering mode test # Boundary value testing: {"type": "edge", "match": 0x00000000, "mask": 0x1FFFFFFF}, #Match all values ​​with the smallest ID {"type": "edge", "match": 0x1FFFFFFF, "mask": 0x00000000}, #Maximum ID filtering {"type": "edge", "match": 0x55555555, "mask": 0x55555555}, #Alternating bit mode test # Hybrid Frame Scene: {"type": "mixed", "std_match": 0x100, "ext_match":0x10000000, "mask": 0x1FFFFFFF} # Test cross-format for the same ID value ] return std_cases + ext_cases Each target test case may include the following information: message ID mode (or CAN transmission frame format, which may include standard frames or extended frames), transmission frame ID, transmission mode, transmission data length, transmission data value, data transmission and reception rate, the value of the matching register of the target controller 22, and the value of the mask register of the target controller 22.

[0055] The message ID pattern can be used to define whether the message is a standard frame or an extended frame. The ID length of a standard frame can be 11 bits, and the ID length of an extended frame can be 29 bits. The frame ID to be sent needs to be specified: the ID value of the frame to be sent, and the ID value needs to conform to the ID range of standard frames and extended frames (refer to the description above for the specific range). The transmission mode defines whether the target controller 22 operates in CAN mode or CANFD (CAN with Flexible Data-Rate) mode. CAN mode refers to the communication mode of the traditional CAN communication protocol following the ISO 11898-1 standard (commonly known as CAN 2.0A / B). CAN FD mode refers to an upgraded version of the CAN protocol following the ISO 11898-1:2015 standard. FD stands for "Flexible Data Rate," and it features key enhancements to classic CAN, designed to meet the higher data throughput requirements of modern automotive and industrial applications.

[0056] The data transmission length (DLC) needs to be specified: the length of the transmitted data segment, with a maximum of 8 bytes for CAN mode and a maximum of 64 bytes for CANFD. The data to be sent needs to be clearly defined: The specific data to be sent must be generated based on the data length. The data transmission and reception rates need to be clearly defined: including the transmission and reception rates of the arbitration segment and the data segment. The transmission and reception controller configurations need to be consistent, and the rate range is (10kbps~5Mbps). The matching register of target controller 22 needs to specify: the frame ID value that target controller 22 can receive; The mask register of the target controller 22 needs to be explicitly defined: the target controller 22 masks the received frame ID value.

[0057] Taking the target test case of a single-ID scenario in a standard frame as an example: The target message ID is 0x000, and the target message ID mask is 0x7FF (corresponding to the binary value: 11111111111). The test logic for the single-ID scenario target test case is as follows: if all bits of the target message ID mask are 1, then the target controller 22 can only receive message IDs that strictly match the 11-bit ID of the target message, i.e., it can only receive messages with ID = 0x000. The purpose of this target test case is to verify whether the target controller 22 can recognize the smallest message ID.

[0058] When the target message ID is 0x7FF, refer to the above for other configurations and parameters. The purpose of this target test case is to verify whether the target controller 22 can recognize the maximum message ID and to verify the high-level processing logic of the target controller 22.

[0059] When the ID of the target message is 0x100, the purpose of this target test case is to verify the target controller 22's ability to accurately match common intermediate values ​​(such as 0x100).

[0060] Taking a scene within a specified range of a standard frame as an example: The target message ID is 0x000, and the target message ID mask is 0x700 (corresponding binary value: 11100000000). The test logic of the target test case in the specified range scenario is as follows: the first three bits of the target message ID mask are 1, and the other bits are 0. Then the high 3 bits of the message ID that the target controller 22 can receive must be consistent with the target message ID, and the low 8 bits are arbitrary. That is, the target controller 22 can receive all messages with IDs from 0x100 to 0x1FF. The purpose of the test is to test the mask function and verify whether the controller can correctly implement ID group reception.

[0061] Taking a mixed-frame scene as an example: In this scenario, the target test cases specify the same target packet ID (e.g., 0x100) and are tested in both standard and extended frames. The mask for the target packet ID in the standard frame is 0x7FF; the mask for the target packet ID in the extended frame is also 0x7FF.

[0062] The purpose of this test case is to verify whether the target controller 22 can correctly distinguish between standard frames and extended frames, test the filtering behavior of the same message ID under different frame formats (standard frames and extended frames), and detect whether the filtering logic is normal after switching between different ID modes.

[0063] For related descriptions of target test cases in other scenarios, please refer to the previous descriptions and so on. This manual will not repeat them here.

[0064] S02: Transceiver Control. Steps in this phase may include: parsing target test case parameters, configuring transceiver controller register parameters, executing message transmission sequences, and recording transmission logs.

[0065] This includes parsing the target test case parameters: parsing the configuration information of the target test cases into specific data structures and checking the validity of the data. For example: typedef struct { u32 baudrate; / baudrate / / Nominal baud rate; u32 sample_point; / sample point / / Sampling point indicates at which point in time the bus level should be sampled within the total time of one bit; u32 prop_seg; / Propagation segment in TQs / / Propagation segment, used to compensate for the delay in the physical propagation of signals on the bus; u32 phase_seg1; / Phase buffer segment 1 in TQs / / Phase buffer segment 1; u32 phase_seg2; / Phase buffer segment 2 in TQs / / Phase buffer segment 2; u32 sjw; / Synchronization jump width in TQs / / Synchronous jump width; u32 brp; / Baudrate prescaler / / Baud rate prescaler; } FCanBaudrateConfig; / / Baud rate configuration structure.

[0066] typedef struct { / / Test configuration structure uint32_t frame_id; / / Send frame ID (11 / 29 bits) uint8_t frame_type; / / 0 - Standard frame 1 - Extended frame uint8_t data_length; / / Data segment length (0-64 bytes) uint8_t data

[64] ; / / Data value FCanBaudrateConfig baudrate_config; / / Send / receive rate (kbps) uint32_t acc_id; / / Receive the value of the ACC_ID register uint32_t acc_mask; / / Receive the value of the ACC_ID_MASK register uint8_t tx_mode; / / Transmission mode (0-CAN, 1-CANFD) uint32_t config_crc; / / Send configuration CRC checksum value } CAN_TestConfig; Configure register parameters. Based on the parsed target test case parameters, call the system configuration interface to configure the mode register and rate register of the transmitting controller 21, and write the data into the transmitting buffer register; configure the mode register, rate register, match register, and mask register of the target controller 22 (i.e., the receiving controller).

[0067] The actual message transmission sequence is executed. The transmission timing is precisely controlled using a transmission ring buffer and the hardware timer of the device under test (DUT) 20, with a timestamp accuracy of 0.02 µs.

[0068] Record the transmission log. Record the target test case sequence number and transmission timestamp, the return value of the transmission interface, the target test case configuration information and the corresponding transmission configuration CRC check value, and the register status of the transmission controller 21. Write the log to the storage medium. The transmission log data structure can be as follows: #pragma pack(push, 1) typedef struct { uint32_t send_index; / / Target test case sequence number uint64_t timestamp; / / Send timestamp CAN_TestConfig test_config; / / Send configuration information uint32_t ret; / / Send the return value uint32_t reg_value

[512] ; / / Send controller 21 register status LogEntry; / / Log entry structure #pragma pack(pop) .

[0069] S03: Result Acquisition: This stage may include steps such as data acquisition and recording, trigger-time register snapshot, and receiving timestamp recording.

[0070] Data acquisition: Real-time monitoring of the CAN bus, receiving and recording messages (standard frames / extended frames); Record the received timestamp: After the message is received, read the received timestamp and record it; Triggered register snapshot: After each target test case is received, the register state of the CAN receiver controller is read and recorded.

[0071] S04: Data Analysis. This stage includes the following steps: parsing raw data, verifying filtering functions, time-series performance analysis, and anomaly detection and diagnosis.

[0072] Parsing the raw data: Data parsing: Parses the acquired raw CAN messages, extracting key fields including message ID (11 bits for standard frames / 29 bits for extended frames), frame type (standard frame / extended frame), data length (DLC), data segment content, receive timestamp (0.02µs precision), and checksum information. Supports automatic identification and parsing of multiple protocol formats (CAN, CAN FD).

[0073] Data comparison: Data recorded in the sending log is read, and the corresponding actual sent packets are compared with the actual received packets based on information such as sending and receiving timestamps to verify data consistency. This mainly includes the following aspects: CRC check: Compares the checksum information configured in the transmission log with the checksum information of the actual received packets. Discards frames with checksum mismatches and records the error counter.

[0074] Length verification: Compare the actual transmitted message data length (DLC) in the transmission log with the actual received message data segment length. Mark frames with abnormal lengths for subsequent diagnostics.

[0075] Data inspection: Compare the actual sent message data with the actual received message data in the sending log for consistency. Mark frames with abnormal data for subsequent diagnosis.

[0076] Timing continuity: Check if the timestamp interval between adjacent messages is reasonable. Detect bus load bursts or controller deadlocks.

[0077] Filtering function verification: Expected result comparison: The target ID range is dynamically calculated based on the matching register and mask register configuration of the target controller 22 recorded in the triggered register snapshot.

[0078] Verify whether the actual received packets conform to the target ID range, and calculate the filtering accuracy (formula: number of correctly filtered frames / total number of test frames × 100%).

[0079] False filtering detection: Identifies false positives and false negatives. A false positive occurs when there is a message whose ID is outside the target ID range among the actually received messages; a false negative occurs when there is a message whose ID is within the target ID range among the messages not received by the target controller 22.

[0080] Timing performance analysis: Delay calculation: Calculate the time difference between the received timestamp and the sent timestamp, and statistically analyze the average delay, maximum delay, and delay distribution.

[0081] Throughput assessment: The throughput of target controller 22 is determined based on the number of messages successfully processed by target controller 22 per unit time.

[0082] Anomaly detection and diagnosis: Error pattern recognition: Bit error: Detected by mismatch of check information (first check information and second check information) or abnormal frame format. Possible causes include physical layer interference or hardware failure.

[0083] Frame loss error: This is detected by determining if a message was actually sent but not received by the target controller 22 within a predetermined time. A possible cause is an incorrect filter configuration.

[0084] Duplicate reception error: This is detected by checking if the time interval between actual received packets with the same ID is less than a reception interval threshold. A possible cause is a failure of the software deduplication logic.

[0085] Cause analysis: Distinguish between hardware problems (such as failure of specific ID bit filtering) and software problems (such as incorrect register configuration timing).

[0086] Exemplary System Accordingly, this specification also provides a testing system, such as... Figure 3 As shown, it includes: a host computer 10 and a device under test 20; the device under test 20 includes a target controller 22, and the host computer 10 is configured as follows: In response to the completion of the target test case execution, the current register information of the target controller 22 is obtained, and the target ID range is determined based on the current register information. The current register information is used to characterize the target ID range of the target controller 22, and the current register information is obtained by configuring the register configuration information in the target test case. Based on the test information, the message filtering function of the target controller 22 is tested. The test information includes the actual received messages and the target ID range. The actual received messages are the messages actually received by the target controller 22.

[0087] Optionally, the test information also includes actual sent messages, which are the messages that need to be sent as defined in the target test case; The host computer 10 tests the message filtering function of the target controller 22 based on the test information, specifically for: Based on the test information, the filtering accuracy of the target controller 22 is determined. The filtering accuracy is the ratio of the number of correctly filtered frames to the total number of test frames. The number of correctly filtered frames includes the number of correctly received packets and the number of correctly filtered packets. The number of correctly received packets is the number of packets whose IDs are within the target ID range in the actual received packets. The number of correctly filtered packets is the number of packets whose IDs are outside the target ID range in the actual sent packets that were not received by the target controller 22.

[0088] Optionally, after determining the filtering accuracy of the target controller 22 based on the test information, the host computer 10 is further configured to: Based on the test information, the misfiltering information of the target controller 22 is determined. The misfiltering information includes false positives and false negatives. A false positive is a message whose ID is outside the target ID range among the actual received messages. A false negative is a message within the target ID range among the messages not received by the target controller 22.

[0089] Optionally, the host computer 10 further tests the message filtering function of the target controller 22 based on the test information by including: Based on the receive timestamp and the send timestamp, delay information is calculated. The receive timestamp represents the time when the actual received message is received by the target controller 22, and the send timestamp represents the time when the actual sent message is sent. The delay information includes at least one of average delay, maximum delay, and delay distribution. The time difference between the receive timestamp and the send timestamp corresponding to the same message is the delay of the message. The throughput of the target controller 22 is determined based on the number of messages processed by the target controller 22 per unit time.

[0090] Optionally, the host computer 10 further tests the message filtering function of the target controller 22 based on the test information by including: Based on the first verification information of the actually sent message and the second verification information of the actually received message, it is determined whether there is a bit error. The bit error indicates that the first verification information of the actually sent message and the second verification information of the actually received message do not match. Based on the timestamp of the actual sent message, determine whether a frame loss error exists; the frame loss error indicates that the actual sent message was not received by the target control within a predetermined time. Based on the reception time interval of actual received messages with the same ID, determine whether there is a duplicate reception error; the duplicate reception error indicates that the reception time interval of actual received messages with the same ID is less than the reception interval threshold.

[0091] Optionally, the register configuration information includes: first configuration information and second configuration information; The device under test 20 includes a transmitting controller 21 and a target controller 22. The execution process of the target test case includes: The target test case is parsed to obtain the register configuration information; Based on the first configuration information, configure the first type of register of the sending controller 21 to determine the message sending mode and message sending rate of the sending controller 21; Based on the first configuration information, configure the first type of registers of the target controller 22 to determine the message receiving mode and message receiving rate of the target controller 22; Based on the second configuration information, configure the second type of register of the target controller 22 to determine the target ID range; The message determined by the target test case is written into the sending controller 21, and the sending controller 21 is controlled to send the message in a determined message sending mode and message sending rate.

[0092] Optionally, the first type of register includes a mode register and a rate register, wherein the value of the mode register is used to characterize the ID mode of the sent or received message, and the value of the rate register is used to characterize the rate of sending or receiving the message. The second type of register includes a matching register and a mask register. The value of the matching register is used to represent the ID of the target message, and the value of the mask register is a mask of the ID of the target message. The mask is used to represent whether the ID of the message that the target controller 22 can receive needs to match each bit of the ID of the target message.

[0093] Optionally, the host computer 10 is further configured to: Based on the target test scenario, the message IDs specified in the target test scenario are traversed to automatically generate target test cases corresponding to the target test scenario; the target test scenario includes: single ID scenario, specified range scenario, boundary value scenario and mixed frame scenario. The single-ID scenario refers to the scenario where the target controller 22 is configured to receive only messages with an ID of a specific value (the first value); the specified range scenario refers to the scenario where the target controller 22 receives only messages with an ID within a specified range; and the boundary value scenario refers to the scenario where the target controller 22 receives only messages with an ID of a second value. In the single-ID scenario, the specified range scenario, and the boundary value scenario, the target controller 22 can test the messages of the first mode or the second mode according to the above rules respectively. The hybrid frame scenario refers to the scenario where the target controller 22 receives messages with IDs of a first mode and a second mode; the first value includes at least one of the minimum value, maximum value, and first target value of the message ID, and the first target value is different from both the minimum value and the maximum value; the second value includes at least one of the minimum value, maximum value, first target value, and second target value of the message ID, and the adjacent data bits of the second target value are different; the first mode includes a mode with 11 bits of message ID, and the second mode includes a mode with 29 bits of message ID; The target test cases include messages that are expected to be received by the target controller 22 and messages that are expected to be filtered by the target controller 22.

[0094] Optionally, after obtaining the register configuration information of the target controller 22, the host computer 10 is further used for: Determine whether the register configuration information matches the current register information. If not, determine that the software configuration or driver configuration of the device under test 20 is incorrect.

[0095] For specific limitations on the test methods executed by the host computer 10, please refer to the relevant explanations above, which will not be repeated here.

[0096] Exemplary device In one exemplary embodiment of this specification, a testing apparatus is also provided for testing the message filtering function of the target controller 22 of the device under test 20, the testing apparatus comprising: The first module is used to obtain the current register information of the target controller 22 in response to the completion of the target test case execution, and determine the target ID range based on the current register information. The current register information is used to characterize the target ID range of the target controller 22. The current register information is configured by the register configuration information in the target test case. Based on the test information, the message filtering function of the target controller 22 is tested. The test information includes the actual received messages and the target ID range. The actual received messages are the messages actually received by the target controller 22.

[0097] In one alternative implementation, such as Figure 3 As shown, the first module may specifically include: a test case generation module 11, a send / receive control module 12, a result acquisition module 13, and a data analysis module 14.

[0098] The test case generation module 11 can be used to automatically generate target test cases under different target test scenarios. That is, the test case generation module 11 can automatically generate target test cases corresponding to the target test scenario by traversing the message IDs specified in the target test scenario. The target test scenarios include: single ID scenario, specified range scenario, boundary value scenario and mixed frame scenario. The single-ID scenario refers to the scenario where the target controller 22 only receives packets with an ID of a first value; the specified range scenario refers to the scenario where the target controller 22 only receives packets with IDs within a specified range; the boundary value scenario refers to the scenario where the target controller 22 only receives packets with an ID of a second value; and the mixed frame scenario refers to the scenario where the target controller 22 receives packets with IDs of a first mode and a second mode. The first value includes at least one of the minimum and maximum values ​​of the packet ID and a first target value, and the first target value is different from both the minimum and maximum values. The second value includes at least one of the minimum and maximum values ​​of the packet ID, the first target value, and a second target value, and the adjacent data bits of the second target value have different values. The first mode includes a mode with an 11-bit packet ID, and the second mode includes a mode with a 29-bit packet ID. The target test cases include messages that are expected to be received by the target controller 22 and messages that are expected to be filtered by the target controller 22.

[0099] The transceiver control module 12 can be used to parse target test cases, configure the registers of the sending controller 21 and the target controller 22, and control data transmission and reception.

[0100] The result acquisition module 13 can be used for data acquisition and recording during the execution of the target test cases.

[0101] The data analysis module 14 can be used for filtering function analysis, timing performance analysis, and anomaly detection and diagnosis. For details, please refer to the limitations of the testing methods mentioned above; they will not be repeated here. Each module in the above testing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device, or stored in the memory of the computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0102] Exemplary computing device Another embodiment of this application also proposes a computing device, see [link to relevant documentation] Figure 4As shown, an exemplary embodiment of this specification also provides a computing device, including: a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the steps in the test methods according to various embodiments of this specification described in the foregoing embodiments.

[0103] The internal structure of the computing device can be as follows: Figure 4 As shown, the computing device includes a processor, memory, network interface, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it follows the steps of the test methods according to various embodiments of this specification as described in the above embodiments.

[0104] The processor may include the main processor, as well as baseband chips, modems, etc.

[0105] It is understood that the processor in the embodiments of this specification can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this specification. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this specification can be directly implemented by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0106] It is understood that the memory in the embodiments of this specification may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM). It should be noted that the memory in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0107] Input devices may include devices that receive data and information input by the user, such as keyboards, mice, cameras, scanners, light pens, voice input devices, touch screens, pedometers, or gravity sensors.

[0108] Output devices may include devices that allow information to be output to the user, such as displays, printers, speakers, etc.

[0109] The communication interface may include any transceiver-like device for communicating with other devices or communication networks, such as CAN, Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

[0110] The computing device may also include a display component and a voice component. The display component may be a liquid crystal display screen or an e-ink display screen. The input device of the computing device may be a touch layer covering the display component, or a button, trackball or touchpad set on the casing of the computing device, or an external keyboard, touchpad or mouse, etc.

[0111] Those skilled in the art will understand that Figure 4 The structures shown are merely block diagrams of some structures related to the solutions in this specification and do not constitute a limitation on the computing devices on which the solutions in this specification are applied. Specific computing devices may include more or fewer components than those shown in the figures, or combine certain components, or have different component arrangements.

[0112] Exemplary computer program products and storage media In addition to the methods and devices described above, the test methods provided in the embodiments of this specification can also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the test methods according to various embodiments of this specification as described in the "Exemplary Methods" section above.

[0113] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0114] The computer program product described herein can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments described herein. These programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0115] Furthermore, embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor of the steps in the test methods according to various embodiments of this specification as described in the "Exemplary Methods" section above.

[0116] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this specification can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0117] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0118] The embodiments described above are merely illustrative of several implementation methods outlined in this specification. While the descriptions are specific and detailed, they should not be construed as limiting the scope of the solutions provided in this specification. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this specification, and these all fall within the scope of protection of this specification. Therefore, the scope of protection for this patent should be determined by the appended claims.

Claims

1. A testing method, characterized in that, The test method for testing the message filtering function of the target controller of the device under test includes: In response to the completion of the target test case, the current register information of the target controller is obtained, and the target ID range is determined based on the current register information. The current register information is used to characterize the target ID range of the target controller, and the current register information is configured by the register configuration information in the target test case. Based on the test information, the message filtering function of the target controller is tested. The test information includes the actual received messages and the target ID range. The actual received messages are the messages actually received by the target controller.

2. The method according to claim 1, characterized in that, The test information also includes the actual sent messages, which are the messages that need to be sent as defined in the target test case; The step of testing the message filtering function of the target controller based on the test information includes: Based on the test information, the filtering accuracy of the target controller is determined. The filtering accuracy is the ratio of the number of correctly filtered frames to the total number of test frames. The number of correctly filtered frames includes the number of correctly received packets and the number of correctly filtered packets. The number of correctly received packets is the number of packets whose IDs are within the target ID range in the actual received packets. The number of correctly filtered packets is the number of packets whose IDs are outside the target ID range in the actual sent packets that were not received by the target controller.

3. The method according to claim 2, characterized in that, After determining the filtering accuracy of the target controller based on the test information, the method further includes: Based on the test information, the misfiltering information of the target controller is determined. The misfiltering information includes false positives and false negatives. A false positive is when there is a message whose ID is outside the target ID range among the actual received messages. A false negative is when there is a message within the target ID range among the messages that were not received by the target controller.

4. The method according to claim 2, characterized in that, The step of testing the message filtering function of the target controller based on the test information also includes: Based on the receive timestamp and the send timestamp, delay information is calculated. The receive timestamp represents the time when the actual received message is received by the target controller, and the send timestamp represents the time when the actual sent message is sent. The delay information includes at least one of average delay, maximum delay, and delay distribution. The time difference between the receive timestamp and the send timestamp corresponding to the same message is the delay of the message. The throughput of the target controller is determined based on the number of messages processed by the target controller per unit time.

5. The method according to claim 2, characterized in that, The step of testing the message filtering function of the target controller based on the test information also includes: Based on the first verification information of the actually sent message and the second verification information of the actually received message, it is determined whether there is a bit error. The bit error indicates that the first verification information of the actually sent message and the second verification information of the actually received message do not match. Based on the timestamp of the actual sent message, determine whether a frame loss error exists; the frame loss error indicates that the actual sent message was not received by the target control within a predetermined time. Based on the reception time interval of actual received messages with the same ID, determine whether there is a duplicate reception error; the duplicate reception error indicates that the reception time interval of actual received messages with the same ID is less than the reception interval threshold.

6. The method according to any one of claims 1 to 5, characterized in that, The register configuration information includes: first configuration information and second configuration information; The device under test includes a transmitting controller and a target controller, and the execution process of the target test case includes: The target test case is parsed to obtain the register configuration information; Based on the first configuration information, configure the first type of registers of the sending controller to determine the message sending mode and message sending rate of the sending controller; Based on the first configuration information, configure the first type of registers of the target controller to determine the message receiving mode and message receiving rate of the target controller; Based on the second configuration information, configure the second type of registers of the target controller to determine the target ID range; The message determined by the target test case is written into the sending controller, and the sending controller is controlled to send the message in a determined message sending mode and message sending rate.

7. The method according to claim 6, characterized in that, The first type of register includes a mode register and a rate register. The value of the mode register is used to characterize the ID mode of the sent or received message, and the value of the rate register is used to characterize the rate of sending or receiving the message. The second type of register includes a matching register and a mask register. The value of the matching register is used to represent the ID of the target message, and the value of the mask register is a mask of the ID of the target message. The mask is used to represent whether the ID of the message that the target controller can receive needs to match each bit of the ID of the target message.

8. The method according to any one of claims 1 to 5, characterized in that, The testing method also includes: Based on the target test scenario, the message IDs specified in the target test scenario are traversed to automatically generate target test cases corresponding to the target test scenario; the target test scenario includes: single ID scenario, specified range scenario, boundary value scenario and mixed frame scenario. The single-ID scenario refers to a scenario where the target controller only receives packets with an ID of a first value; the specified range scenario refers to a scenario where the target controller only receives packets with IDs within a specified range; the boundary value scenario refers to a scenario where the target controller only receives packets with an ID of a second value; and the mixed frame scenario refers to a scenario where the target controller receives packets with IDs of a first mode and a second mode. The first value includes at least one of the minimum and maximum values ​​of the packet ID and a first target value, wherein the first target value is different from both the minimum and maximum values. The second value includes at least one of the minimum and maximum values ​​of the packet ID, the first target value, and a second target value, wherein the adjacent data bits of the second target value are different. The first mode includes a mode with an 11-bit packet ID, and the second mode includes a mode with a 29-bit packet ID. The target test cases include messages that are expected to be received by the target controller and messages that are expected to be filtered by the target controller.

9. The method according to any one of claims 1 to 5, characterized in that, After obtaining the register configuration information of the target controller, the process further includes: Determine whether the register configuration information matches the current register information. If not, determine that the software configuration or driver configuration of the device under test is incorrect.

10. A testing system, characterized in that, Includes: a host computer and a device under test (DUT); the DUT includes a target controller, and the host computer is configured as follows: In response to the completion of the target test case, the current register information of the target controller is obtained, and the target ID range is determined based on the current register information. The current register information is used to characterize the target ID range of the target controller, and the current register information is configured by the register configuration information in the target test case. Based on the test information, the message filtering function of the target controller is tested. The test information includes the actual received messages and the target ID range. The actual received messages are the messages actually received by the target controller.

11. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the test method according to any one of claims 1 to 9.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the test method as described in any one of claims 1 to 9.