A communication driver test system and method

Abstract

The present application relates to a communication driven test system and method. The communication driven test system comprises a control end and a hardware test end, the hardware test end comprises a master processor and a processor under test, the control end is respectively connected with the master processor and the processor under test through a serial port, the master processor and the processor under test establish a target communication link through the respective deployed communication modules, the control end is used for sending a start instruction to the master processor and the processor under test through the serial port, wherein the start instruction is used for triggering the master processor and the processor under test to synchronously execute the communication driven test; the master processor and the processor under test are used for responding to the start instruction, carrying out data interaction through the target communication link, and respectively returning the communication driven test results generated by each to the control end through the serial port. The system provided by the present application realizes the automatic test of the MCAL communication driver, reduces the influence of human factors, and improves the consistency and repeatability of the subsequent verification process.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a communication-driven testing system and method. Background Technology

[0002] In the software development of microcontroller units (MCUs) based on the Automotive Open System Architecture (AUTOSAR), communication driver testing of the microcontroller abstraction layer (MCAL) typically relies on external communication simulation equipment. Testers then manually configure the relevant test parameters and provide the test results. This approach is not only inefficient, but the test results are also highly susceptible to human error, resulting in poor consistency and repeatability of the verification process. Summary of the Invention

[0003] To address the aforementioned technical problems, this disclosure provides a communication-driven testing system and method.

[0004] In a first aspect, embodiments of this disclosure provide a communication-driven testing system, which includes a control terminal and a hardware testing terminal. The hardware testing terminal includes a main control processor and a processor under test (DUT). The control terminal is communicatively connected to both the main control processor and the DUT via serial ports. The main control processor and the DUT establish a target communication link for test data transmission through their respective deployed communication modules. The control terminal is used to send start commands to the main control processor and the processor under test via serial port. The start command is used to trigger the main control processor and the processor under test to execute communication driver test synchronously. The main control processor and the processor under test are used to respond to the start command, interact with each other through the target communication link, and return the communication driver test results generated by each to the control terminal through the serial port.

[0005] Optionally, the control terminal is used to send a start command to the main control processor through the first serial port and to the processor under test through the second serial port; wherein the first serial port and the second serial port are different, and the start command includes a synchronization identifier, a test case identifier and test configuration parameters. The synchronization identifier is used to instruct the main control processor and the processor under test to execute the same test case in the same test cycle. The test case to be executed corresponding to the test case identifier is used to instruct the main control processor and the processor under test to perform the execution behavior when synchronously executing the communication drive test.

[0006] Optionally, the main control processor includes a test control module; the test control module is used to obtain local configuration parameters and test reference data corresponding to the test case identifier, and update the parameters of the first communication module deployed in the main control processor according to the local configuration parameters, so as to interact with the processor under test through the first communication module after parameter update; wherein, the first communication module is a serial communication module or a bus control module.

[0007] Optionally, the main control processor also includes a test case execution module. The test configuration parameters include preset test logic, first test data, and / or a first test sequence. The test case execution module is used to drive the first communication module to send the first test data to the processor under test according to the preset test logic, and / or receive the second test data sent by the processor under test within the first test sequence. The data transmitted on the target communication link includes the first test data and / or the second test data.

[0008] Optionally, the main control processor also includes a result reporting module. The result reporting module is used to acquire test interaction data generated by the main control processor when interacting with the processor under test, and to generate a first communication-driven test result based on the test interaction data and test reference data. The test interaction data includes at least one of the following: data received and sent on the target communication link, status data generated during communication, and timing data. The first communication-driven test result includes a test result identifier and descriptive data used to describe the differences between the test interaction data and the test reference data.

[0009] Optionally, the processor under test includes test execution firmware and MCAL communication driver. The test execution firmware is used to parse the boot instructions and call the MCAL communication driver to update the parameters of the second communication module deployed in the processor under test, so as to interact with the main control processor through the parameter-updated second communication module.

[0010] Optionally, the processor under test is used to acquire test execution data during the execution of the MCAL communication driver, wherein the test execution data includes at least one of the internal state data and error flags during the execution of the MCAL communication driver; The test execution firmware is used to judge the test execution data according to preset inspection rules and generate the second communication driver test result.

[0011] Optionally, the processor under test is also used for: After updating the parameters of the second communication module, a completion message is generated and fed back to the control terminal. The system receives and responds to a synchronization start signal, and interacts with the main control processor via the target communication link. The synchronization start signal is sent by the control terminal after receiving the completion information, or by the main control processor at a preset time point. The synchronization start signal is used to instruct the processor under test to start executing the test cases within the target time window.

[0012] Optionally, the control terminal is used for: Obtain the first communication driver test result and test interaction data returned by the main control processor; Obtain the second communication driver test results and test execution data returned by the processor under test; Compare the test result identifiers in the first and second communication driver test results, as well as the preset fields in the test interaction data and test execution data; If both the test result identifier and the preset fields correspond, a test result indicating successful communication driving test is generated; or, if either the test result identifier or the preset fields do not correspond, a test result indicating failed communication driving test is generated.

[0013] Secondly, this disclosure provides a communication driver testing method applied to a control terminal, the method comprising: A start command is sent to the hardware test terminal via serial port. The hardware test terminal includes a main control processor and a processor under test. The start command is used to trigger the main control processor and the processor under test to execute communication driver tests synchronously. The system receives communication driver test results returned by the main control processor and the processor under test via serial port. These results are generated after the main control processor and the processor under test respond to the start command and interact with each other through the target communication link. The target communication link is established by the main control processor and the processor under test through their respective deployed communication modules and is used to test data transmission.

[0014] Thirdly, embodiments of this disclosure provide an electronic device, including: Memory; Processor; and Computer programs; The computer program is stored in memory and configured to be executed by a processor to implement the second aspect of the method described above.

[0015] Fourthly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the second aspect above.

[0016] The communication-driven testing system disclosed herein includes a control terminal and a hardware testing terminal. The hardware testing terminal includes a main control processor and a processor under test (DUT). The control terminal communicates with both the main control processor and the DUT via serial ports. The main control processor and the DUT establish a target communication link for test data transmission through their respective deployed communication modules. Specifically, the control terminal sends start commands to both the main control processor and the DUT via the serial port, triggering them to synchronously execute communication-driven tests. The main control processor and the DUT respond to the start commands, interacting with each other through the target communication link and returning their respective generated communication-driven test results to the control terminal via the serial port. This system achieves automated testing of MCAL communication drivers, reducing the impact of human factors and improving the consistency and repeatability of subsequent verification processes. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0018] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the structure of a communication-driven testing system provided in an embodiment of the present disclosure; Figure 2 This is a schematic diagram of another communication-driven test system provided in an embodiment of the present disclosure; Figure 3 A flowchart illustrating a communication-driven testing method provided in an embodiment of this disclosure; Figure 4 A flowchart illustrating another communication-driven testing method provided in this embodiment of the disclosure; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

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

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

[0022] Specifically, in MCU software development based on the AUTOSAR architecture, the development and testing of MCAL communication drivers (such as CAN, SPI, I2C, etc.) typically rely on external communication simulation or analysis equipment, such as CAN bus analyzers, SPI / I2C protocol emulators, and general communication debugging tools. Testers or developers manually configure communication parameters, construct test frames, and trigger transmission via a host computer, then collect and judge the MCU's response. However, this development and testing method has significant shortcomings: on the one hand, it relies heavily on manual operation, resulting in low testing efficiency and difficulty in supporting high-frequency regression and continuous integration verification of MCAL drivers during the development phase; on the other hand, test results are easily affected by human factors such as experience and configuration deviations, leading to poor consistency and repeatability in the verification process. Furthermore, different communication interface types and different MCU platforms often require replacement or reconfiguration of external devices, resulting in high costs for test environment setup and maintenance, limited versatility and scalability, and difficulty in meeting the needs of conventional software for highly automated and reliable development and verification of AUTOSAR MCAL communication drivers.

[0023] Currently, semi-automatic testing solutions based on external bus analyzers or protocol emulators typically involve a host computer test script controlling the bus analyzer or protocol emulator to automatically construct and send bus messages such as CAN, SPI, and I2C, while simultaneously acquiring response data on the bus in real time. The test script can flexibly set message content, timing parameters, and abnormal scenarios according to pre-configured test cases, and decodes and records the acquired data through protocol parsing functions, thus covering various communication interfaces and complex operating conditions. During test execution, testers can also utilize the waveform display, trigger condition setting, message filtering, and statistics functions provided by the tool to observe and analyze the communication behavior on the MCU side, achieving multi-level verification from the message level, waveform level, to the protocol level. However, testing solutions based on external bus analyzers or protocol emulators have the following shortcomings: First, they are highly dependent on dedicated hardware equipment. Different communication protocols require different models of analyzers or emulators, resulting in high equipment procurement and maintenance costs, and complex test environment setup. Second, test scripts are strongly bound to specific devices, leading to poor cross-platform portability. When changing the MCU model or communication interface type, the host computer control program and device configuration parameters need to be re-adapted. Third, manual intervention is required for result comparison and anomaly detection during the testing process, resulting in limited automation and difficulty in supporting the high-frequency regression testing requirements of the MCAL driver development stage. Finally, test results are easily affected by human factors such as human operation and parameter configuration deviations, resulting in poor consistency and repeatability, which is not conducive to continuous integration and quality traceability.

[0024] To address the aforementioned technical problems, this disclosure provides a communication driver testing system that achieves high coverage, automated testing and integration of AUTOSAR MCAL communication drivers without relying on an external bus analyzer. Detailed description is provided through one or more of the following embodiments.

[0025] Figure 1 This is a schematic diagram of a communication-driven testing system provided in an embodiment of the present disclosure. The communication-driven testing system 100 includes a control terminal 110 and a hardware testing terminal 120. The hardware testing terminal 120 includes a main control processor 121 and a processor under test 122. The control terminal 110 is connected to the main control processor 121 and the processor under test 122 via a serial port. The main control processor 121 and the processor under test 122 establish a target communication link for test data transmission through their respective deployed communication modules.

[0026] Understandably, a communication-driven test system is an automated test system that utilizes a communication module to drive the collaborative work of a control unit, a main control processor, and a processor under test (DUT). In one embodiment, the control unit is a PC host, the main control processor is a main control MCU, and the DUT is the DUT MCU. The control unit communicates with both the main control processor and the DUT via two serial ports. A data link is established between the main control processor and the DUT through their internally deployed communication modules. This system architecture enables synchronous execution of test cases across multiple processors and centralized management of test results by the control unit.

[0027] Understandably, there is no limit to the number of main control processors and processors under test included in the hardware test end. For example, the hardware test end includes one main control processor and multiple processors under test. The main control processor and multiple processors under test interact with each other to realize the communication-driven test of multiple processors under test.

[0028] The control terminal sends start commands to the main control processor and the processor under test via serial port. The start command triggers the main control processor and the processor under test to synchronously execute communication driver tests. The main control processor and the processor under test respond to the start command, interact with each other through the target communication link, and return the generated communication driver test results to the control terminal via serial port.

[0029] Understandably, the control terminal sends start commands to both the main control processor and the processor under test (DUT) via serial ports, driving them to synchronously execute a pre-designed communication test sequence. The main control processor, acting as the test device, interacts with the DUT through its internal communication module, collecting data content, timing characteristics, and error states returned by the DUT. The DUT, acting as the device under test, runs test execution firmware based on the MCAL layer communication driver. After processing the received start command, it calls its internal communication module to complete data interaction with the main control processor and returns to the execution status after the test. Data interaction refers to data sending and receiving. Subsequently, both the main control processor and the DUT report their local communication driver test results to the control terminal via serial ports. The control terminal records and comprehensively judges the reported results, automatically generating test logs and reports, thereby achieving automated verification of the MCAL communication driver and its underlying communication module on the DUT, including functional and timing verification.

[0030] Understandably, before the communication-driven test begins, the control terminal imports a pre-compiled test list, parses the test list file, and obtains the parsing results. These results include information on multiple test cases to be executed. Each test case includes at least the test case number, target communication channel identifier, working mode, data direction, data length, expected result type, and whether it is enabled. Subsequently, the control terminal generates the current test task queue based on the parsing results. The current test task queue includes at least one test case, which is a relevant example used for communication-driven testing.

[0031] Optionally, the control terminal is used to send a start command to the main control processor through the first serial port and to the processor under test through the second serial port; wherein the first serial port and the second serial port are different, and the start command includes a synchronization identifier, a test case identifier and test configuration parameters. The synchronization identifier is used to instruct the main control processor and the processor under test to execute the same test case in the same test cycle. The test case to be executed corresponding to the test case identifier is used to instruct the main control processor and the processor under test to perform the execution behavior when synchronously executing the communication drive test.

[0032] Understandably, the control unit includes a script and serial port driver module, which in turn includes multiple serial ports, including a first serial port and a second serial port. For the Nth test case in the current test task queue (i.e., the test case to be executed), the control unit sends a start command to the main control processor via the first serial port and a start command to the processor under test via the second serial port. The start commands sent by the control unit to the main control processor and the processor under test may not be exactly the same, but for the main control processor and the processor under test that require collaborative testing, the two start commands must include at least the same test case number and test configuration parameters. Both start commands include a synchronization flag, used for the two processors to execute the same test case within the same test cycle.

[0033] The main control processor includes a test control module, a test case execution module, and a result reporting module.

[0034] Optionally, the main control processor includes a test control module; the test control module is used to obtain local configuration parameters and test reference data corresponding to the test case identifier, and update the parameters of the first communication module deployed in the main control processor according to the local configuration parameters, so as to interact with the processor under test through the first communication module after parameter update; wherein, the first communication module is a serial communication module or a bus control module.

[0035] Understandably, after receiving the start command from the control terminal, the main control processor, through the test control module, selects the corresponding local configuration parameters and test reference data based on the test case number, and initializes or updates the parameters of the first communication module deployed within it using the local configuration parameters. The local configuration parameters refer to the communication driver parameters required to execute the current test case, such as baud rate, data length, frame format, and communication timeout. These parameters can be pre-stored in the main control processor's local storage. The test reference data (also known as the expected test result) is benchmark data used to compare with the actual test output to determine whether the test passed. The first communication module is either a serial communication module or a bus control module. This method, where the processor automatically matches test parameters and reference data based on the test case number, avoids manual configuration errors and effectively improves the automation and consistency of test execution.

[0036] Understandably, after completing local parameter configuration, the master processor can also send configuration completion information back to the control terminal to notify it that it is in a ready state. Upon receiving the configuration completion information from both the master processor and the processor under test (DUT), the control terminal sends synchronization start signals to both the master processor and the DUT via serial port, enabling them to begin executing the current test case within a pre-defined time window. Alternatively, the master processor can initiate a synchronization handshake with the DUT at a predetermined time.

[0037] Optionally, the main control processor also includes a test case execution module. The test configuration parameters include preset test logic, first test data, and / or a first test sequence. The test case execution module is used to drive the first communication module to send the first test data to the processor under test according to the preset test logic, and / or receive the second test data sent by the processor under test within the first test sequence. The data transmitted on the target communication link includes the first test data and / or the second test data.

[0038] Understandably, the test configuration parameters include preset test logic, first test data, and / or first test timing. The preset test logic defines the control flow for test execution, such as sending before receiving, cyclic sending, and status detection after error injection. The first test data is the communication data content to be sent, and the first test timing specifies time constraints during communication, such as frame sending intervals, response timeouts, and timing sampling points. After the main control processor starts, the test case execution module drives the first communication module to send the first test data to the processor under test (DUT) or receive the second test data from the DUT within the first test timing, according to the preset test logic. Both the first and second test data are data transmitted on the target communication link.

[0039] Optionally, the main control processor also includes a result reporting module. The result reporting module is used to acquire test interaction data generated by the main control processor when interacting with the processor under test, and to generate a first communication-driven test result based on the test interaction data and test reference data. The test interaction data includes at least one of the following: data received and sent on the target communication link, status data generated during communication, and timing data. The first communication-driven test result includes a test result identifier and descriptive data used to describe the differences between the test interaction data and the test reference data.

[0040] Understandably, during communication, the main control processor also collects key information on the target communication link, obtaining test interaction data generated by the main control processor when interacting with the processor under test. This test interaction data includes at least one of the following: the actual data sequences sent and received, status data generated during communication, and key timing parameters. Status data includes status flags and error codes. After the communication process of the current test case ends, the main control processor compares the collected test interaction data with the locally stored test reference data (i.e., the expected result template) to obtain a preliminary judgment result, denoted as the first communication-driven test result. This first communication-driven test result includes a test result identifier and difference description data. The test result identifier includes whether the test passed or failed, and the difference description data describes the differences in data content, status information, and timing parameters between the actual test data and the expected test data, in order to generate an accurate judgment result.

[0041] Understandably, after completing the local test judgment, the main control processor will send the current test case number, local judgment result, error code, some key information and / or statistical information to the control terminal through the result reporting module via the first serial port.

[0042] The processor under test includes an MCAL communication driver module and a test execution firmware module.

[0043] Understandably, test execution firmware refers to an embedded control program pre-programmed or deployed in the processor under test (DUT), responsible for parsing instructions from the control unit or main processor and scheduling local low-level driver modules to execute corresponding operations. MCAL communication driver refers to the microcontroller abstraction layer communication driver, which is a low-level software module that directly operates the registers of the internal communication peripherals (such as CAN controllers and SPI / I2C interfaces) of the DUT.

[0044] Optionally, the processor under test includes test execution firmware and MCAL communication driver. The test execution firmware is used to parse the boot instructions and call the MCAL communication driver to update the parameters of the second communication module deployed in the processor under test, so as to interact with the main control processor through the parameter-updated second communication module.

[0045] Understandably, after receiving the startup command from the control terminal, the processor under test (DUT) parses the startup command using the test execution firmware to obtain the parsing result. Subsequently, the test execution firmware calls the MCAL communication driver to initialize or reconfigure its internally deployed second communication module, and can also return a ready response to the control terminal. After confirming that both the main control processor and the DUT are in a ready state, the control terminal considers the current test case ready for execution.

[0046] Optionally, the processor under test is further configured to: generate completion information after completing the parameter update of the second communication module, and feed the completion information back to the control terminal; receive a synchronization start signal, and respond to the synchronization start signal to perform data interaction with the main control processor through the target communication link; wherein, the synchronization start signal is sent by the control terminal after receiving the completion information, or by the main control processor at a preset time point, and the synchronization start signal is used to instruct the processor under test to start executing the test cases to be executed within the target time window.

[0047] Understandably, once both the main control processor and the processor under test are ready, the control terminal sends a synchronization start signal to both the main control processor and the processor under test via a serial port, or the main control processor initiates a synchronization handshake with the processor under test at a predetermined time point, so that the main control processor and the processor under test can start executing the current test case within the agreed time window.

[0048] Optionally, the processor under test is used to acquire test execution data during the execution of the MCAL communication driver, wherein the test execution data includes at least one of the internal state data and error flags during the execution of the MCAL communication driver; the test execution firmware is used to judge the test execution data according to preset checking rules and generate a second communication driver test result.

[0049] Understandably, while executing the MCAL communication driver, the processor under test (DUT) records its own test execution data. This data includes the driver return value, internal status register data, and error flags, used for subsequent result reporting and test judgment. Subsequently, the test execution firmware judges the status and error flags returned by the MCAL communication driver according to preset checking rules, forming its own execution result and optional additional information, thus obtaining the second communication driver test result. Simultaneously, the same test case number, local execution result, MCAL error code, and internal status information can be sent to the control terminal via the second serial port. The control terminal's result acquisition and recording module receives and stores the result data from both MCUs.

[0050] Optionally, the control terminal is used to: obtain the first communication driver test result and test interaction data returned by the main control processor; obtain the second communication driver test result and test execution data returned by the processor under test; compare the test result identifier in the first communication driver test result and the second communication driver test result with the preset fields in the test interaction data and the test execution data; generate a test result indicating successful communication driver test if both the test result identifier and the preset fields correspond; or generate a test result indicating failed communication driver test if either the test result identifier or the preset fields do not correspond.

[0051] Understandably, the control unit receives the judgment results returned by the main control processor and the controller under test (DUT), and associates the judgment results from the two MCUs according to the test case number. It also compares the consistency of the judgment results and key fields between the main control processor and the DUT. When both MCUs return a pass judgment result, and the key data matches the status field, the test case is marked as passed, and a successful communication drive test result is generated. When either MCU returns a failure judgment result, or the judgment results returned by the two MCUs are inconsistent (i.e., one returns pass, the other returns failure), the test case is marked as failed, and a failed communication drive test result is generated. Simultaneously, information such as the failed endpoint, error code, and differences between the two MCUs is recorded.

[0052] Understandably, after processing the results of the current test case, the control terminal selects the next unexecuted test case from the test task queue and repeats the above steps until all test cases in the test task queue have been executed. During test case execution, if a communication error or device disconnection occurs, the control terminal can retry or abort according to a preset strategy and record the cause of the error in the log. Additionally, the control terminal can write the comprehensive results of each test case to a test result database or log file. After all test cases are executed, the control terminal calls the log / report generation module to perform statistical analysis on the records during the test process and automatically generate a communication module-driven test report. This test report includes the number and pass rate of test cases covered, statistics of failed test cases categorized by error type, a list of test cases with inconsistent results between the master processor and the processor under test, and at least one data point from detailed data and status records for typical failed test cases. The generated test report can also be exported and saved for subsequent defect analysis and regression testing.

[0053] For example, see Figure 2 , Figure 2 This is a schematic diagram of another communication-driven test system provided in an embodiment of this disclosure, as shown below. Figure 2As shown, the communication-driven testing system includes a PC host and a hardware testing terminal. The PC host includes a test list management module, a script and serial port driver module, a result acquisition and recording module, and a log / report generation module. The hardware testing terminal includes a main control MCU A (i.e., the main control processor) and a test MCU B (i.e., the processor under test). The main control MCU A includes a test control module, a test case execution module, and a result reporting module, while the test MCU B includes an MCAL communication driver module and a test execution firmware module. The PC host sends a start command to the main control MCU A via serial port 1 and to the test MCU B via serial port 2. Data transmission between the main control MCU A and the test MCU B is achieved via a bus. Specific implementation details of each module are provided in the above embodiment and will not be repeated here.

[0054] In one embodiment, the MCU under test (MCU B) is an automotive-grade MCU, and the test object is its MCAL communication driver for its SPI peripheral. The PC host imports a test list containing multiple SPI test cases, each with a preset different operating mode (e.g., master mode, different baud rates and polarity / phase combinations) and data length. The PC host sequentially sends start commands, including test case numbers and configuration parameters, to both the master MCU A and the MCU B under test. The two MCUs then transmit and receive data via the SPI bus. The master MCU A records the received data and timing parameters and performs local judgment, while the MCU B under test executes the corresponding transmission and reports its status via the SPI MCAL driver. The PC host integrates the judgment results from both ends and automatically generates a test report for the SPI MCAL driver.

[0055] The communication driver testing system provided in this application achieves closed-loop automated verification of the MCAL communication driver and its underlying communication modules on the processor under test through the collaborative work of the control terminal, the main control processor, and the processor under test. Data interaction and timing measurements performed on a real hardware link make the test results more closely resemble actual applications. Secondly, the control terminal centrally manages the test list and supports use in complex scenarios such as batch regression and pattern combination, making expansion and maintenance convenient. Furthermore, the main control processor and the processor under test independently report results, and the control terminal performs consistency comparison based on the results from both ends, facilitating rapid location of driver defects or hardware problems. Moreover, the entire process of test execution, result recording, and report generation is automated, allowing for easy integration into a continuous integration platform, significantly improving the efficiency and coverage of communication driver testing.

[0056] Based on the above embodiments, Figure 3 This is a flowchart illustrating a communication-driven testing method provided in an embodiment of the present disclosure. Applied to the control terminal of the aforementioned communication-driven testing system, it specifically includes, as follows: Figure 3 The following steps are shown: S301. Send a start command to the hardware test terminal via serial port. The hardware test terminal includes a main control processor and a processor under test. The start command is used to trigger the main control processor and the processor under test to execute communication driver test synchronously.

[0057] S302. Receive the communication driver test results returned by the main control processor and the processor under test respectively through the serial port. The communication driver test results are generated after the main control processor and the processor under test respond to the start command and interact with each other through the target communication link. The target communication link is established by the main control processor and the processor under test through their respective deployed communication modules and is used to test data transmission.

[0058] Understandably, the specific implementation details of S301 and S302 can be found in the above embodiments and will not be repeated here.

[0059] Optionally, the execution steps on the control end may also include: After receiving configuration completion information from the main control processor and the processor under test, a synchronization start signal is sent to the main control processor and the processor under test.

[0060] Optionally, the execution steps on the control end may also include: A startup command is sent to the main control processor via the first serial port and to the processor under test via the second serial port. The first and second serial ports are different. The startup command includes a synchronization identifier, a test case identifier, and test configuration parameters. The synchronization identifier is used to instruct the main control processor and the processor under test to execute the same test case within the same test cycle. The test case to be executed corresponding to the test case identifier is used to instruct the execution behavior of the main control processor and the processor under test when synchronously executing the communication driver test.

[0061] Optionally, the execution steps on the control end may also include: Obtain the first communication driver test result and test interaction data returned by the main control processor; obtain the second communication driver test result and test execution data returned by the processor under test; compare the test result identifier in the first communication driver test result and the second communication driver test result with the preset fields in the test interaction data and test execution data; if the test result identifier and the preset fields both correspond, generate a test result indicating that the communication driver test was successful; or, if the test result identifier and any preset field do not correspond, generate a test result indicating that the communication driver test failed.

[0062] Optionally, the execution steps of the main control processor include: Obtain the local configuration parameters and test reference data corresponding to the test case identifier, and update the parameters of the first communication module deployed in the main control processor according to the local configuration parameters, so as to interact with the processor under test through the first communication module with updated parameters; wherein, the first communication module is a serial communication module or a bus control module.

[0063] Optionally, the execution steps of the main control processor may also include: According to the preset test logic, the first communication module is driven to send first test data to the processor under test, and / or receive second test data sent by the processor under test within the first test sequence; wherein, the data transmitted on the target communication link includes the first test data and / or the second test data.

[0064] Optionally, the execution steps of the main control processor may also include: The test interaction data generated by the main control processor during data interaction with the processor under test is acquired, and a first communication-driven test result is generated based on the test interaction data and test reference data. The test interaction data includes at least one of the following: data received and sent on the target communication link, status data generated during communication, and timing data. The first communication-driven test result includes a test result identifier and descriptive data used to describe the differences between the test interaction data and the test reference data.

[0065] Optionally, the execution steps of the processor under test include: The startup command is parsed, and the MCAL communication driver is called to update the parameters of the second communication module deployed in the processor under test, so as to exchange data with the main control processor through the second communication module with updated parameters.

[0066] Optionally, the execution steps of the processor under test may also include: Obtain test execution data during MCAL communication driver execution, wherein the test execution data includes at least one of the internal state data and error flags of MCAL communication driver execution; judge the test execution data according to preset checking rules, and generate a second communication driver test result.

[0067] Optionally, the execution steps of the processor under test may also include: After updating the parameters of the second communication module, completion information is generated and fed back to the control terminal; a synchronization start signal is received and responded to, and data interaction is performed with the main control processor through the target communication link; wherein, the synchronization start signal is sent by the control terminal after receiving the completion information, or by the main control processor at a preset time point, and the synchronization start signal is used to instruct the processor under test to start executing the test cases to be executed within the target time window.

[0068] Understandably, the specific implementation details of the above steps can be found in the above embodiments, and will not be repeated here.

[0069] The communication driver testing method provided in this disclosure achieves high coverage and automated testing and debugging of MCAL communication drivers without relying on an external bus analyzer. The MCU under test (DUT) is used as the unit under test, running the actual business software and MCAL driver. The main control MCU acts as a collaborative test control unit, interacting directly with the DUT via the on-board bus to complete message construction, exception injection, timing control, and result acquisition, thereby reproducing the real communication scenario within the target hardware environment. Through the collaborative operation of two MCUs, a lightweight and portable test platform can be built, reducing testing costs, decreasing reliance on manual operation and dedicated equipment, and improving regression testing efficiency and result consistency.

[0070] Based on the above embodiments, Figure 4 This is a flowchart illustrating another communication-driven testing method provided in an embodiment of this disclosure, applied to the aforementioned communication-driven testing system, specifically including as follows: Figure 4 The following steps are shown: (1) Test list import and parsing: The PC host imports and parses the test list to generate a task queue. (2) Test case start command issuance: The PC host sends a start command containing the test case number and configuration parameters to the main control MCU A and the MCU under test B through serial port 1 / 2. (3) The main control MCU A and the MCU under test B enter the ready state. (4) Synchronous start of communication test sequence: The PC host sends a synchronization signal, and the two MCUs start executing the current test case. (5) Communication data and status acquisition: The main control MCU A acquires data and timing, and the MCU under test B records status data. (6) Local point result judgment: The two MCUs generate local judgment results and difference information respectively. (7) Test results are sent back to the PC host: The two MCUs report the test case number and judgment result through the serial port. (8) PC host comprehensive recording and consistency check: The PC host associates the judgment results of both ends, gives the final judgment result of pass or fail and records it. (9) Determine whether there are any unexecuted test cases in the task queue, and execute the next test case until the end. (10) Generate test report statistics and output report.

[0071] Understandably, the specific implementation details of (1) to (10) above can be found in the above embodiments, and will not be repeated here.

[0072] Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of the present disclosure. See below for details. Figure 5The diagram illustrates a structural schematic suitable for implementing the electronic device 500 in the embodiments of this disclosure. The electronic device 500 in the embodiments of this disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), wearable electronic devices, etc., as well as fixed terminals such as digital TVs, desktop computers, smart home devices, etc. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0073] like Figure 5 As shown, the electronic device 500 may include a processing unit 501 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503 to implement the communication-driven testing method as described in the embodiments of this disclosure. The RAM 503 also stores various programs and data required for the operation of the electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0074] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0075] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts, thereby implementing the communication-driven testing method as described above. In such embodiments, the computer program can be downloaded and installed from a network via communication device 509, or installed from storage device 508, or installed from ROM 502. When the computer program is executed by processing device 501, it performs the functions defined in the methods of embodiments of this disclosure.

[0076] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0077] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0078] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0079] Optionally, when one or more of the above-described procedures are executed by the electronic device, the electronic device may also perform other steps described in the above embodiments.

[0080] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0081] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0082] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0083] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0084] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

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

[0086] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A communication-driven testing system, characterized in that, The communication-driven testing system includes a control terminal and a hardware testing terminal. The hardware testing terminal includes a main control processor and a processor under test (DUT). The control terminal communicates with both the main control processor and the DUT via serial ports. The main control processor and the DUT establish a target communication link for test data transmission through their respective deployed communication modules. The control terminal is used to send start commands to the main control processor and the processor under test respectively via serial port, wherein the start command is used to trigger the main control processor and the processor under test to synchronously execute communication driver test; The main control processor and the processor under test are used to respond to the start command, interact with each other through the target communication link, and return the communication driver test results generated by each to the control terminal through the serial port.

2. The system according to claim 1, characterized in that, The control terminal is used to send a start command to the main control processor through a first serial port and to the processor under test through a second serial port; wherein the first serial port and the second serial port are different, the start command includes a synchronization identifier, a test case identifier and test configuration parameters, the synchronization identifier is used to instruct the main control processor and the processor under test to execute the same test case in the same test cycle, and the test case to be executed corresponding to the test case identifier is used to instruct the main control processor and the processor under test to perform the execution behavior when synchronously executing the communication driver test.

3. The system according to claim 2, characterized in that, The main control processor includes a test control module; the test control module is used to obtain local configuration parameters and test reference data corresponding to the test case identifier, and update the parameters of the first communication module deployed in the main control processor according to the local configuration parameters, so as to interact with the processor under test through the first communication module after parameter update; wherein, the first communication module is a serial communication module or a bus control module.

4. The system according to claim 3, characterized in that, The main control processor also includes a test case execution module, and the test configuration parameters include preset test logic, as well as first test data and / or first test timing; The test case execution module is used to drive the first communication module to send the first test data to the processor under test according to the preset test logic, and / or receive the second test data sent by the processor under test within the first test sequence; wherein, the data transmitted on the target communication link includes the first test data and / or the second test data.

5. The system according to claim 3, characterized in that, The main control processor further includes a result reporting module, which is used to acquire test interaction data generated by the main control processor when interacting with the processor under test, and generate a first communication-driven test result based on the test interaction data and the test reference data; wherein, the test interaction data includes at least one of data received and sent on the target communication link, status data generated during communication, and timing data, and the first communication-driven test result includes a test result identifier and descriptive data for describing the differences between the test interaction data and the test reference data.

6. The system according to claim 2, characterized in that, The processor under test includes test execution firmware and MCAL communication driver. The test execution firmware is used to parse the startup instruction and call the MCAL communication driver to update the parameters of the second communication module deployed in the processor under test, so as to interact with the main control processor through the parameter-updated second communication module.

7. The system according to claim 6, characterized in that, The processor under test is used to acquire test execution data when the MCAL communication driver is executed, wherein the test execution data includes at least one of the internal state data of the MCAL communication driver and error flags; The test execution firmware is used to judge the test execution data according to preset inspection rules and generate a second communication driver test result.

8. The system according to claim 6, characterized in that, The processor under test is also used for: After completing the parameter update of the second communication module, a completion message is generated and fed back to the control terminal. The system receives and responds to a synchronization start signal, and interacts with the main control processor via the target communication link. The synchronization start signal is sent by the control terminal after receiving the completion information, or by the main control processor at a preset time point. The synchronization start signal is used to instruct the processor under test to start executing the test cases within the target time window.

9. The system according to claim 1, characterized in that, The control terminal is used for: Obtain the first communication driver test result and test interaction data returned by the main control processor; Obtain the second communication driver test result and test execution data returned by the processor under test; Compare the test result identifiers in the first communication driver test result and the second communication driver test result, as well as the preset fields in the test interaction data and the test execution data; If both the test result identifier and the preset field correspond, a test result indicating successful communication driving test is generated; or, if neither the test result identifier nor the preset field corresponds, a test result indicating failed communication driving test is generated.

10. A communication-driven testing method, characterized in that, Applied to the control terminal, the method includes: A start command is sent to the hardware test terminal via a serial port. The hardware test terminal includes a main control processor and a processor under test. The start command is used to trigger the main control processor and the processor under test to synchronously execute communication driver tests. The communication driver test results returned by the main control processor and the processor under test are received via serial port. The communication driver test results are generated after the main control processor and the processor under test respond to the start command and interact with each other through the target communication link. The target communication link is established by the main control processor and the processor under test through their respective deployed communication modules and is used to test data transmission.

Images