Automated Interface Testing Methods

Abstract

This invention provides an automated interface testing method for testing multiple interfaces of a device under test (DUT). The automated interface testing method includes: electrically connecting one or more of the interfaces under test to an interface testing device; electrically connecting the interface testing device to an edge computing terminal; executing test commands issued by the edge computing terminal through the interface testing device to test the functional integrity of the interfaces under test and obtaining feedback data; receiving the feedback data through the edge computing terminal and comparing the feedback data with a preset standard to output the test result of the interface under test, wherein the test commands include multiple commands, and each interface under test corresponds to one command. This embodiment, by integrating multiple interface testing modules, can effectively improve the versatility and reusability of the device.

Description

Technical Field

[0001] This invention relates to the field of computer testing technology, and in particular to an automated interface testing method. Background Technology

[0002] In the production testing phase of the computer manufacturing industry, interface function verification is a core step in ensuring product quality. Common interfaces on devices under test lack universal automated testing tools; different products require different testing tools and processes, resulting in high adaptation costs and long lead times. Furthermore, many test items still rely on manual intervention, which is not only inefficient but also prone to misjudgments due to human error, leading to unreliable test results. Summary of the Invention

[0003] Therefore, in order to overcome at least some of the defects and deficiencies in the existing technology, the embodiments of the present invention provide an automated interface testing method that can adapt to the testing needs of various types of interfaces.

[0004] This invention provides an automated interface testing method for testing multiple interfaces of a device under test (DUT). The automated interface testing method includes: electrically connecting one or more of the multiple DUT interfaces to an interface testing device; electrically connecting the interface testing device to an edge computing terminal; executing test instructions issued by the edge computing terminal through the interface testing device to test the functional integrity of the DUT interfaces and obtain feedback data; receiving the feedback data through the edge computing terminal and comparing the feedback data with a preset standard to output the test result of the DUT interfaces, wherein the test instructions include multiple instructions, and each of the test interfaces... Each port corresponds to one of the aforementioned instructions; the edge computing terminal accesses internal data through a database, compares the feedback data with preset standards, including expected read / write data, communication success rate thresholds, and signal parameter ranges, and ultimately determines whether the function of the interface under test corresponding to the device under test is normal; the interface testing device is configured with multiple independent testing modules, each corresponding to a unique and different testing interface, covering the low-speed and industrial bus interface testing requirements of the device under test, as well as the testing logic that can adapt to different interfaces according to the instructions of the edge computing terminal; wherein, the testing module matches the communication protocol and transmission logic of the corresponding interface, outputs functional test information, and receives test data.

[0005] In one embodiment, the test command is to test the read / write function of the SPI interface of the device under test, and / or configure the CAN interface bus baud rate and send a test frame.

[0006] In one embodiment, the interface testing device receives a test instruction and generates corresponding functional test information according to the instruction. The functional test information includes the target address for SPI interface reading and writing, and / or the test frame content for CAN interface.

[0007] In one embodiment, after receiving test data, the interface testing device performs format standardization processing on the test data to obtain the feedback data.

[0008] In one embodiment, the interface testing device includes: a main control module, used to generate corresponding functional test information according to the test instructions; multiple test modules, each electrically connected to the main control module, each test module having a corresponding test interface, and the multiple test interfaces corresponding to the multiple test modules are all different; the test interface is used to output the functional test information to the interface under test and receive test data, the feedback data including the test data.

[0009] In one embodiment, the interface under test includes a UART interface, the test command includes a UART interface test command, and the test module includes a UART interface module electrically connected to the main control module. The UART interface module includes a UART test interface for electrically connecting to the UART interface. The main control module generates UART interface functional test information according to the UART interface test command and transmits it to the UART interface module. The UART test interface receives UART interface test data generated after the UART interface executes the UART interface functional test information, and the feedback data includes the UART interface test data.

[0010] In one embodiment, the testing module includes a console interface module electrically connected to the main control module. The edge computing terminal sends test commands to the main control module through the console interface module, and the main control module transmits the feedback data to the edge computing terminal through the console interface module.

[0011] In one embodiment, the interface under test is connected to the corresponding interface under test of the device under test through the test interface of the interface testing device, and commands are issued interactively.

[0012] In one embodiment, for local extended testing, the edge computing terminal is directly controlled by its edge control program, and the data is processed locally.

[0013] As can be seen from the above, the technical features of the present invention can have one or more of the following beneficial effects: By integrating multiple commonly used interface testing modules into an interface testing device, this device becomes compatible with various interfaces under test, eliminating the need for separate dedicated testing equipment for different types of interfaces. This effectively improves versatility and reusability, and reduces testing costs. Leveraging edge computing terminals and testing modules in collaboration, each interface is tested with specific commands, ensuring accurate and reliable testing. The entire process operates in a fully automated closed-loop manner, requiring no manual intervention, significantly improving testing efficiency and shortening the cycle time. Attached Figure Description

[0014] Figure 1 A schematic diagram of the connection structure of an automated interface testing device provided in this application; Figure 2 for Figure 1 A schematic diagram of the specific structure of the interface testing equipment; Figure 3 for Figure 1 A schematic diagram of the specific structure of the device under test; Figure 4 for Figure 1 A schematic diagram of the connection structure between the edge computing terminal, interface testing equipment, and the device under test.

[0015] Figure 5 for Figure 1 A schematic diagram of the connection structure between the edge computing terminal, interface testing equipment, and the device under test.

[0016] Figure 6 for Figure 1 A schematic diagram of the connection structure between the edge computing terminal, interface testing equipment, and the device under test. Detailed Implementation

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

[0018] On the one hand, refer to Figure 1 , Figure 2 , Figure 3 and Figure 4As shown, this embodiment provides an automated interface testing device 1, which is used to test various interfaces 13 of a device under test (DUT) 12. Exemplarily, the DUT 12 may be, for example, a microcontroller development board, an industrial control module, etc. The interface 13 may be, for example, various interfaces. In one embodiment, the interface 13 may be, for example, a low-speed interface, such as a serial port, GPIO (General-Purpose Input / Output), I2C (Inter-Integrated Circuit), SPI (Serial Peripheral Interface), CAN (Controller Area Network), and other communication bus interfaces with lower transmission rates.

[0019] The automated interface testing device 1 includes an interface testing equipment 10 and an edge computing terminal 20. The interface testing equipment 10 is used to electrically connect to one or more of a variety of interfaces 13 under test. The edge computing terminal 20 is electrically connected to the interface testing equipment 10. The interface testing equipment 10 is used to execute test commands issued by the edge computing terminal 20 to test the functional integrity of the interface 13 under test and to acquire feedback data. The edge computing terminal 20 is used to receive the feedback data and, based on the feedback data, compare it with a preset standard and output the test result of the interface 13 under test. The test commands include multiple commands, with one command corresponding to each test interface.

[0020] For example, the edge computing terminal 20 may be equipped with a Windows / Linux system, capable of running standard operating systems, and can utilize open-source software tools to simplify the development of test programs. It possesses ample computing and storage resources, multiple USB (Universal Serial Bus) ports, network ports, PCIe (Peripheral Component Interconnect Express) slots, and other expansion interfaces, supporting testing of interfaces such as network ports, audio, and displays. Testing of visual objects, such as LEDs (Light-Emitting Diodes), can be achieved through indirect machine vision. For example, the interface testing device 10 may have a rich variety of interface types, a large number of commonly used interfaces, and easily replaceable consumable components. It supports USB power supply or sharing with a console port, uses a serial port as the control panel, and supports command and jumper switching of interface modes, such as TTL / RS232 / RS485 serial ports, adapting to the flexible testing needs of various interfaces.

[0021] Edge computing terminal 20 is electrically connected to interface testing device 10. Edge computing terminal 20 sends specific test commands to interface testing device 10. Specific test commands include, for example, testing the read / write function of SPI interface 135 of device under test 12, and / or configuring the CAN interface 132 bus baud rate to 500kbps and sending test frames. Interface testing device 10 receives the test commands and generates corresponding functional test information according to the commands, such as the target address for SPI interface read / write and / or the content of CAN interface test frames, and transmits it to the corresponding interface of device under test 12 through the corresponding test interface, for example, SPI test interface 4051 transmits to SPI interface 135, CAN test interface transmits to CAN interface 132, etc. After receiving the functional test information, device under test 12 performs corresponding operations, such as reading / writing SPI flash, receiving CAN frames and transmitting them back, etc. Device under test 12 generates test data and transmits it to interface testing device 10. Test data includes, for example, read SPI data, CAN return frames, GPIO level states, etc. After receiving the test data, the interface testing device 10 performs format standardization processing on the test data to obtain feedback data. Standardization processing includes things like unifying the data format and adding timestamps. The interface testing device 10 then transmits the feedback data to the edge computing terminal 20. The edge computing terminal 20 can access internal data through a database and compare the feedback data with preset standards, such as expected read / write data, communication success rate thresholds, and signal parameter ranges, ultimately determining whether the interface 13 corresponding to the device under test 12 is functioning correctly.

[0022] The interface testing equipment 10 can cover the testing needs of various low-speed and industrial bus interfaces such as SPI, CAN, and GPIO. The interface testing equipment 10 can adapt the test logic of different interfaces according to the instructions of the edge computing terminal 20, without the need to develop test programs or configure special test tools for different interfaces under test 13, which greatly reduces the equipment adaptation cost of testing multiple types of interfaces.

[0023] In different embodiments, such as Figure 5 As shown, the interface testing device 10 may include at least one low-speed interface testing module. This module is connected to the device under test (DUT) 12 and the edge computing terminal 20, and can be used to test low-speed interfaces, such as serial ports, GPIO, I2C, SPI, CAN, and other communication bus interfaces with low transmission rates. The low-speed interface testing module may include a microcontroller (MCU) and multiple low-speed interfaces. For example, a microcontroller model with a rich variety of interface types and a large number of commonly used interfaces may be selected. The low-speed interface testing module can be powered via a USB interface or share a power supply with the low-speed interfaces. The low-speed interface testing module also includes a memory unit, such as an EEPROM or SPI flash. This memory unit may not require microcontroller control and can be provided as a separate external device to the DUT for self-reading and writing testing.

[0024] In different embodiments, the edge computing terminal 20 can issue corresponding test instructions, the interface testing device 10 can automatically generate corresponding test information and complete the standardized processing of data, and the feedback data of the device under test 12 can be directly and automatically compared with the preset standard and output the judgment result. This replaces the inefficient mode of manually configuring interface parameters, manually reading test data, and manually judging test results in traditional testing. It not only eliminates the subjective error caused by manual operation, but also improves the standardization and traceability of the test process, and effectively improves the test efficiency.

[0025] Reference Figure 2 As shown, in some embodiments, the interface testing device 10 includes a main control module 30 and multiple test modules 40. The main control module 30 is used to generate corresponding functional test information according to test instructions. The multiple test modules 40 are electrically connected to the main control module 30, and each test module 40 has a corresponding test interface, and the multiple test interfaces corresponding to the multiple test modules 40 are all different. The test interface is used to output functional test information to the interface under test 13 and receive test data, and the feedback data includes test data.

[0026] For example, the main control module 30 may be an MCU (Microcontroller Unit) motherboard. It should be noted that multiple test modules 40 and the main control module 30 are all integrated on a PCB (Printed Circuit Board). Each test module 40 is electrically connected to the main control module 30. The main control module 30 receives test commands, reads and generates corresponding functional test information, and transmits the functional test information to the corresponding test module 40. The test module 40 outputs the data to the interface under test 13 through a test interface. The test data generated by the device under test 12 after performing the corresponding operation is transmitted through the interface under test 13 to the test interface corresponding to the test module 40, and then through the test module 40 corresponding to that test interface to the main control module 30. The main control module 30 performs formatted and standardized processing on the test data to obtain feedback data, and then transmits the feedback data to the edge computing terminal 20.

[0027] The interface testing device 10, configured with multiple independent testing modules 40, each corresponding to a unique and different testing interface such as SPI, CAN, I2C, and GPIO, can simultaneously cover the testing needs of various low-speed and industrial bus interfaces of the device under test 12. This avoids the limitations of traditional single test fixtures that can only adapt to a few interfaces and require frequent device replacements. Furthermore, each testing module 40 is specifically matched to the communication protocol and transmission logic of its corresponding interface, enabling accurate output of functional test information and reception of test data. This ensures the professionalism and accuracy of testing different interfaces and adapts to comprehensive interface verification scenarios for multiple types of devices under test 12.

[0028] Reference Figure 2 , Figure 3 and Figure 4 As shown, in some embodiments, the interface under test 13 includes a UART interface 131. The test command includes a UART interface test command. The test module 40 includes a UART interface module 401, which is electrically connected to the main control module 30. The UART interface module 401 includes a UART test interface 4011, which is used to electrically connect to the UART interface 131. The main control module 30 is used to generate UART interface function test information according to the UART interface test command and transmit it to the UART interface module 401. The UART test interface 4011 is used to receive UART interface test data generated after the UART interface 131 executes the UART interface function test information, and the feedback data includes the UART interface test data.

[0029] UART interface module 401 receives functional test information and executes it through UART test interface 4011. UART interface module 401 allows for custom configuration of communication parameters such as baud rate, data bits, stop bits, parity, and flow control. It also supports loopback functionality, enabling the transmission of all received characters back to the device under test 12 along their original path. Arbitrary strings can be sent via functional test information, provided the string length limit is explicitly specified. Furthermore, the switching between serial port communication modes, such as RS232 and RS485, supports electronic control, allowing for instrument mode changes without manual jumpers, thus adapting to the automated testing needs of different serial port types.

[0030] For example, the edge computing terminal 20 sends a UART interface test command to the interface testing device 10. The main control module 30 generates functional test information according to the command. The functional test information, for example, sets the serial port test port baud rate to 9600bps and starts the loopback function. The UART interface module 401 receives the functional test information and controls the UART test interface 4011 to perform the corresponding operation.

[0031] The interface testing device 10, through an independent UART interface module 401 and a dedicated UART test interface 4011, can specifically match the communication protocol and transmission logic of the UART interface. The main control module 30 can generate adapted functional test information according to the UART interface test instructions, avoiding protocol compatibility issues when the general test module 40 is adapted to the UART interface. At the same time, the UART test interface 4011 can directly establish a stable communication link with the UART interface under test, ensuring the accuracy of test information transmission and test data feedback, effectively verifying the core functions of the UART interface such as baud rate adaptation and data transmission and reception, and improving the professionalism and accuracy of UART interface testing results.

[0032] Reference Figure 2 , Figure 3 and Figure 4 As shown, in some embodiments, the interface under test 13 includes a CAN interface 132. The test command includes a CAN interface test command. The test module 40 includes a CAN controller module 402, which is electrically connected to the main control module 30. The CAN controller module 402 includes a CAN controller interface 4021, which is used to electrically connect to the CAN interface 132. The main control module 30 generates CAN interface function test information according to the CAN interface test command and transmits it to the CAN controller module 402. The CAN controller interface 4021 receives CAN interface test data generated after the CAN interface 132 executes the CAN interface function test information, and the feedback data includes the CAN interface test data.

[0033] The CAN controller module 402 supports loopback functionality, enabling it to transmit all received characters back to the device under test (DUT) 12 along their original path. Based on functional test information, parameters such as baud rate and data length can be configured, and specific data frames can be sent. The CAN controller module 402 precisely matches the core communication logic of the CAN interface 132, including differential transmission, bus arbitration, and frame format. The dedicated CAN controller interface 4021 establishes a stable differential communication link with the DUT, ensuring accurate transmission of functional test information and complete acquisition of test data (such as CAN return frames and bus error codes), effectively verifying the communication stability, frame transmission and reception reliability, and bus compatibility of the DUT.

[0034] For example, the edge computing terminal 20 sends a CAN interface test command to the main control module 30, which can, for example, test the data transmission and reception function of the CAN interface 132 of the device under test 12 at a baud rate of 500kbps. The main control module 30 parses the command to generate functional test information, such as CAN frame ID=0x123, data length=8 bytes, payload=0x01-0x08, and sends the parameters to the CAN controller module 402. The CAN controller module 402 encapsulates the above test parameters into a CAN protocol frame and outputs a TTL logic level signal. The CAN transceiver converts the TTL signal into a CAN bus differential signal and transmits it to the CAN interface 132 of the device under test 12 through the CAN controller interface 4021. The device under test 12 performs the test by receiving the CAN frame and sending back a response frame. The generated response signal is sent back to the CAN transceiver through the CAN interface 132. The CAN transceiver converts the differential signal back to TTL logic level. The CAN controller module 402 parses the TTL signal, extracts test data such as the response frame ID and data content, and sends it back to the main control module 30. After standardizing the test data, the main control module 30 uploads it to the edge computing terminal 20, which determines whether the CAN interface 132 of the device under test 12 is functioning normally.

[0035] Reference Figure 2 , Figure 3 and Figure 4 As shown, in some embodiments, the interface under test 13 includes a GPIO interface 133. The test instructions include GPIO interface test instructions. The test module 40 includes a GPIO interface module 403, which is electrically connected to the main control module 30. The GPIO interface module 403 includes a GPIO test interface 4031, which is used to electrically connect to the GPIO interface 133. The main control module 30 is used to generate GPIO interface functional test information according to the GPIO interface test instructions and transmit it to the GPIO interface module 403. The GPIO test interface 4031 is used to receive GPIO interface test data generated after the GPIO interface 133 executes the GPIO interface functional test information, and the feedback data includes the GPIO interface test data.

[0036] The GPIO interface module 403 is electrically connected to the peripheral pins of the main control module 30. Logically, it is driven by the internal hardware module of the main control module 30 and does not require a separate chip. It is a direct application of the core functions of the main control module 30 in the test scenario. The GPIO interface module 403 can configure the pin direction, set the output pin level, read the input pin level, output a PWM waveform with a specified frequency and duty cycle, and read the number of rising edges triggered on the input pin within 1 second, which can be approximated as the frequency of the waveform. The maximum sampling accuracy should be noted.

[0037] The interface testing device 10 is equipped with a GPIO interface module 403, which enables precise and specialized testing of the GPIO interface under test 13. Through the GPIO test interface 4031, which is directly connected to the GPIO interface under test, the main control module 30 generates appropriate functional test information based on the GPIO test instructions, ensuring the accuracy of test instruction issuance and level status data feedback, effectively verifying the input / output control capabilities of the GPIO interface 133. Its modular architecture can be seamlessly integrated with modules such as UART and CAN, achieving unified management of multiple interfaces and improving device integration and compatibility.

[0038] Reference Figure 2 , Figure 3 and Figure 4 As shown, in some embodiments, the interface under test 13 includes an I2C interface 134. The test instructions include I2C interface test instructions. The test module 40 includes an EEPROM (Electrically Erasable Programmable Read-Only Memory) module, which is electrically connected to the main control module 30. The EEPROM module 404 includes an I2C test interface 4041, which is used to electrically connect to the I2C interface 134. The main control module 30 generates I2C interface function test information according to the I2C interface test instructions and transmits it to the EEPROM module 404. The I2C test interface 4041 receives I2C interface test data generated after the I2C interface 134 executes the I2C interface function test information, and the feedback data includes the I2C interface test data.

[0039] The EEPROM memory module 404 is an independent peripheral device, not connected to the control link of the main control module 30, but directly connected to the device under test 12. The device under test 12 can independently initiate read and write commands to the EEPROM memory module 404 without intervention from the main control module 30, thereby directly verifying the driving capability, data read and write logic, and communication stability of the storage peripheral device of the device under test 12. The grounding terminal of the EEPROM memory module 404 must be connected to the grounding terminal of the device under test 12 to avoid signal interference or electrostatic damage caused by grounding potential difference, ensuring the accuracy of read and write data and the safety of the device. The EEPROM memory module 404 can be powered by the main control module 30 or directly by the device under test 12 to adapt to the power supply interface and test scenario requirements of different devices under test 12.

[0040] For example, the device under test (DUT) 12 autonomously initiates an I2C interface test command to write preset data, such as consecutive bytes from 0x01 to 0x0F, into the address range 0x00 to 0x0F of the EEPROM memory module 404. The interface test device 10 only monitors the power supply voltage and bus level and does not interfere with the read / write process. The DUT 12 then initiates an I2C read command to read the stored data in the address range 0x00 to 0x0F and compares the read result with the preset written data. The DUT 12 attempts to write data to an address beyond the capacity of the EEPROM memory module 404, such as 0x100, to verify its ability to identify memory address boundaries. Simultaneously, 100 consecutive read / write operations are performed to verify the stability of data read / write operations.

[0041] Reference Figure 2 , Figure 3 and Figure 4 As shown, in some embodiments, the interface under test 13 includes an SPI interface 135. The test instructions include SPI interface test instructions. The test module 40 includes a FLASH storage module 405, which is electrically connected to the main control module 30. The FLASH storage module 405 includes an SPI test interface 4051, which is used to electrically connect to the SPI interface 135. The main control module 30 is used to generate SPI interface function test information according to the SPI interface test instructions and transmit it to the FLASH storage module 405. The SPI test interface 4051 is used to receive SPI interface test data generated after the SPI interface 135 executes the SPI interface function test information; the feedback data includes the SPI interface test data.

[0042] The FLASH storage module 405 is an independent test peripheral and is not connected to the control link of the main control module 30 of the interface test equipment 10. Its SPI test interface 4051 is directly connected to the SPI interface 135 of the device under test 12. The device under test 12 can independently initiate SPI communication commands to independently complete read, write, and erase operations on the FLASH storage module 405. The interface test equipment 10 only provides basic support and does not interfere with the data interaction process, thereby directly verifying the driving capability, communication protocol compatibility, and data read / write logic of the device under test 12 to the FLASH storage module 405 peripheral. Connecting the ground pin of the FLASH storage module 405 to the ground terminal of the device under test 12 is to eliminate the potential difference between the two, avoid signal interference, data transmission errors, or even electrostatic discharge damage to the chip caused by inconsistent grounding, and ensure the stability of the test process and the safety of the equipment. The FLASH storage module 405 can be powered by the main control module 30, adapting to scenarios where the interface test equipment 10 has no spare power supply interface. It can also be directly powered by the device under test 12 to simulate the power supply environment of the FLASH storage module 405 in actual applications, making the test scenario closer to the real working conditions.

[0043] For example, the device under test (DUT) 12 autonomously initiates an SPI interface test command, first writing preset data, such as an alternating byte sequence of 0x55 and 0xAA, into the address range 0x000000~0x0000FF of the FLASH storage module 405. After writing, it immediately reads the data in that address range and compares the read result with the written data to verify the basic read and write functions. The DUT 12 then sends a block erase command to erase the address block 0x001000~0x001FFF in the FLASH storage module 405. After erasing, it writes all 0xFF data into that address block and then reads the data to confirm the erasure and write effects, verifying its support for the erase command of the FLASH storage module 405. The DUT 12 continuously executes 100 write-read-erase loop operations, writing a different random byte sequence each time, recording the consistency and response time of each round of read and write, to verify the long-term stability of the SPI communication link.

[0044] Reference Figure 2 As shown, in some embodiments, the test module 40 includes a TTL to RS232 converter 406, which is electrically connected to the main control module 30 and the UART interface module 401. It is used to convert between TTL level signals and RS232 level signals between the UART test interface 4011 and the UART interface 131.

[0045] TTL level is commonly found in microcontrollers, such as the main control module 30 of interface testing equipment 10. Its high level is 3.3V / 5V, and its low level is 0V, suitable for short-distance, on-board, or near-distance device communication. RS232 level is a commonly used serial communication level in industry or computers. It uses positive and negative voltages to represent logic, for example, +3~+15V is low level, and -3~-15V is high level. It has stronger anti-interference capabilities and is suitable for communication between devices several meters to tens of meters apart, such as between a computer and a module, or between a module and a remote device under test 12. The TTL to RS232 module 406 converts the TTL level signal output by the main control module 30 to an RS232 level signal, or vice versa, allowing devices with different level standards to send and receive data normally, achieving interoperability.

[0046] Reference Figure 2 As shown, in some embodiments, the test module 40 includes a TTL to RS485 converter 407, which is electrically connected to the main control module 30 and the UART interface module 401. This converter is used to convert between TTL level signals and RS485 level signals between the UART test interface 4011 and the UART interface 131.

[0047] RS485 level is a commonly used differential level for serial communication in the industrial field. It uses the voltage difference between two lines to represent logic. For example, if line A is 200mV~6V higher than line B, it is a high level; if line B is 200mV~6V higher than line A, it is a low level. It has extremely strong anti-interference capabilities and is suitable for multi-device network communication over distances of tens to thousands of meters, such as industrial sensor networking, multi-module interconnection of vehicle electronics, and data interaction between long-distance industrial control equipment and the terminal under test. The TTL to RS485 module 407 is used to convert the TTL level signal of the main control module 30 into an RS485 differential level signal and send it to the device under test 12. Or, it can convert the RS485 differential level signal fed back by the device under test 12 back into a TTL level signal. Through level conversion, the test functions of the UART interface module 401 of the interface test device 10, such as parameter configuration, data transmission and reception, and loopback, can cover the three common levels of the interface under test 13: TTL, RS232, and RS485, achieving compatibility with multiple types of serial port testing.

[0048] Reference Figure 2 , Figure 3 and Figure 4 As shown, in some embodiments, the test module 40 includes a Console interface module 408, which is electrically connected to the main control module 30. The Console interface module 408 includes a Console interface 4081, which is electrically connected to the edge computing terminal 20. It is used to receive test commands from the edge computing terminal 20 and send feedback data. The edge computing terminal 20 sends test commands to the main control module 30 through the Console interface module 408, and the main control module 30 transmits feedback data to the edge computing terminal 20 through the Console interface module 408.

[0049] In some embodiments, the interface testing device 10 further includes a USB interface testing module, which can replace Bear and is compatible with both USB 3.0 and 2.0 interface testing, balancing test compatibility and cost control. The interface testing device 10 also includes a coin cell battery leakage detection testing module, which can be manufactured as a dedicated testing device or integrated into the interface testing device 10. The coin cell battery leakage detection testing module is used to detect the coin cell battery current when the mains power is off, thereby determining whether the battery leakage current of the board exceeds the standard. The interface testing device 10 also includes a PCIe interface testing module, adapting to the testing requirements of multiple generations of PCIe interfaces (4.0, 3.0, 2.0), ensuring test coverage of multiple PCIe interface specifications.

[0050] In some embodiments, the plurality of test modules 40 include a UART interface module 401, a CAN controller module 402, a GPIO interface module 403, an EEPROM memory module 404, and a FLASH storage module 405.

[0051] In some embodiments, the interface testing device 10 can be customized with a mechanical frame so that all test interfaces are concentrated on the same side. When establishing a connection with the device under test (DUT) 12, all interfaces can be plugged in and unplugged simultaneously, reducing the connection time of the DUT 12. For connectors vertically placed on the PCB surface, the frame enables simultaneous plugging and unplugging of multiple connectors, shortening the installation time of the DUT 12. The original power supply of the test module 40 can be replaced with a programmable model, achieving automated control of the power supply to the test module 40 and improving the intelligence of the testing process. For example, a mechanical device controlled by electrical signals can be installed to replace the traditional manually operated board fixing handle.

[0052] Furthermore, the edge computing terminal 20 includes a host, with specific models such as IMB-46 and RK-620MB-L. Secondly, the edge computing terminal 20 can optionally be equipped with PCIe expansion SFP+, PCIe expansion USB, PCIe expansion Gigabit Ethernet ports, an NPU (specific model such as Hailo8L), a microphone, a high-definition camera, and a webcam. The edge computing terminal 20 includes an edge control program that runs on the edge computing terminal 20, supporting both Windows and Linux operating systems. It should be noted that if installing Linux is inconvenient in certain situations but is still necessary, a virtual machine can be installed to communicate with it via a virtual network.

[0053] The edge computing terminal 20 includes network ports, all of which can be tested using iperf3 or similar open-source tools. The network port LEDs and network speed are tested simultaneously; note the LED patterns at different speeds. When scanning MAC addresses, the sticker location is indicated on the test program interface.

[0054] The edge computing terminal 20 includes an audio interface, uses a microphone to record preset audio played by the device under test 12, and uses mature audio processing tools under Linux to compare the similarity and determine whether the audio is playing normally. The microphone of the edge computing terminal 20 and the playback device of the device under test 12 are wrapped together with packaging material to avoid external interference and to prevent interference between adjacent devices.

[0055] Edge computing terminal 20 includes a video interface. The device under test 12 displays a preset image, such as RGB color blocks, on a monitor. Edge computing terminal 20 uses a camera to take a picture and detects whether the preset image is displayed. If image quality requirements are not high, a low-cost camera can be used. When using display detection, care should be taken to avoid being affected by ambient light. Alternatively, a signal detection card can be considered for testing, which is more comprehensive and reliable.

[0056] Edge computing terminal 20 includes LEDs. It uses a camera to capture images and detects whether the device under test 12 turns the LEDs on or off according to a program. Similarly, it checks the digital tube display; LEDs can also be detected using a light sensor. If high image quality is not required, a low-cost camera can be used.

[0057] Edge computing terminal 20 includes PCB component inspection. Before testing begins, a high-definition camera takes high-resolution photos of the PCB, either panoramically or focusing on specific areas, to check for defects such as reversed chip soldering. All photos are automatically uploaded to a server for manual sampling. Defective photos are marked and used as training samples.

[0058] The visual inspection of the machine replacement items includes DIP switches, jumpers, cable connections (such as fan cables), battery installation, and screws. Before packaging, checks are made for any overlapping parts, and comparisons are made with photos from the testing phase. BIOS configuration is handled automatically by the test script.

[0059] like Figure 4 , Figure 6 As shown, for the interface under test 13 (e.g., CAN interface 132, GPIO interface 133, etc.), it can be directly connected to the corresponding interface of the device under test 12 through the test interface of the interface testing device 10, and commands can be issued interactively. For local expansion testing (e.g., PCIe expansion SFP+, PCIe expansion USB, etc.), it is directly controlled by the edge control program of the edge computing terminal 20, and the data is processed locally. For some indirect interfaces, such as video and audio detection, the edge control program of the edge computing terminal 20 directly controls the information collection device, such as the camera and microphone, and processes the data locally.

[0060] The edge control program provides a graphical user interface that can be operated using a mouse and keyboard. The main interface provides a "Start" button to initiate a single complete test or resume a paused test. A "Pause" button is provided to pause the current complete test; it aborts the ongoing test item and resumes from that item upon resumption. An "Exit" button is provided to exit the current test round and restart from the beginning; for example, if a board installation error is found, the connection needs to be adjusted before retesting. A log window is provided, displaying test information such as test items, server interactions, and error messages. The main interface displays the test cycle number (Cycle), recording the total number of test rounds the current board has undergone, which can be considered as the retest count +1. Data needs to be transmitted back to the TE Server. "Test Time" is displayed, showing the time consumed in this test round. "Cumulative Time" is displayed, showing the total test time the current board has undergone; data needs to be transmitted back to the TE Server. Finally, for items that fail the test, pre-built maintenance suggestions from the development team are provided.

[0061] The testing process for the edge control program is as follows: Upon startup, the edge control program automatically detects the reachability of the servers it depends on and provides prompts. The user logs in to the program using their MES account. The user scans the serial number barcode of the product under test, and the program retrieves the test list for that product from the online database. The user scans and enters various programming information, such as the MAC address. The user clicks the "Start" button to begin the test. Each test item is executed according to a preset mode, defined as follows: wait - wait for the previous test to finish before starting execution. sync - Multiple test items are tested by a single test command, and the pass / fail status is determined based on the return information. Delayed Start - Provides several fixed delay options. After the previous test item is started, this test item will start after the fixed delay has elapsed.

[0062] Each test item should have a set timeout period; failure is considered after the timeout. Test items should be executed in parallel as much as possible to minimize the test cycle. After all test items are completed, the test results should be displayed on the user interface. After all test items are completed, the test results and logs should be saved on both local and remote servers. This program should support individual retesting of single test items and record the number of retests. This program should record all manual operations and send them back to the server. Each test item should specify the test command or test script from the database to ensure test method traceability. Each test item should specify the evaluation criteria to ensure test criteria traceability. Test commands or tools for the same interface should be standardized, with command parameters used to control specific differences.

[0063] On the other hand, this embodiment provides an automated interface testing system, which includes the aforementioned automated interface testing device 1 and the device under test 12.

[0064] The automated interface testing system in this embodiment connects the automated interface testing device 1 with the device under test 12 to achieve interaction, thus constructing a highly efficient integrated testing system. The system relies on multiple testing modules 40, such as UART, CAN, and GPIO, of the device to achieve a fully automated closed-loop process of test command issuance, data acquisition, and result verification, replacing manual operation and shortening the testing cycle.

[0065] The computers / servers used in this application can be applied to, for example, network platform servers (e.g., 5G network servers), data centers (e.g., large-scale cloud data centers), databases (e.g., financial database servers), AI computing servers (e.g., edge computing platform servers), servers for monitoring and data acquisition systems, traffic control system servers, smart grid platform servers, distributed control system (DCS) operator stations, artificial intelligence and high-performance computing (HPC) servers, big data analysis servers, network security platform servers, communication and collaboration platform servers, industrial control computers, medical systems / computers, industrial tablet computers, automated testing systems, drones, robots, general-purpose humanoid robots, AOI platform servers, embedded computing platforms, industrial IoT, vehicle networking, fanless minicomputers, or other suitable types of computers / servers.

[0066] Furthermore, it is understood that the foregoing embodiments are merely illustrative examples of the present invention. Provided that the technical features do not conflict, the structure is not contradictory, and the purpose of the invention is not violated, the technical solutions of the various embodiments can be arbitrarily combined and used.

[0067] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An automated interface testing method, characterized in that, Used for testing various interfaces under test of the device under test; The automated interface testing method includes: The interface testing device is electrically connected to one or more of the various interfaces under test. The interface testing device is electrically connected via an edge computing terminal; The interface testing device executes the test commands issued by the edge computing terminal to test the functional integrity of the interface under test and obtains feedback data. The edge computing terminal receives the feedback data and compares it with a preset standard to output the test result of the interface under test. The test instructions include multiple instructions, and each test interface corresponds to one instruction. The edge computing terminal accesses internal data through a database, compares the feedback data with preset standards, including expected read / write data, communication success rate threshold, and signal parameter range, and finally determines whether the function of the interface under test corresponding to the device under test is normal. The interface testing equipment is configured with multiple independent testing modules, each corresponding to a unique and different testing interface, covering the low-speed and industrial bus interface testing requirements of the device under test, as well as the testing logic that can adapt to different interfaces according to edge computing terminal instructions; wherein, the testing module matches the communication protocol and transmission logic of the corresponding interface, outputs functional test information and receives test data.

2. The automated interface testing method according to claim 1, characterized in that, The test command is to test the read / write function of the SPI interface of the device under test, and / or configure the CAN interface bus baud rate and send test frames.

3. The automated interface testing method according to claim 2, characterized in that, The interface testing device receives test instructions and generates corresponding functional test information according to the instructions. The functional test information includes the target address for SPI interface reading and writing, and / or the test frame content for CAN interface.

4. The automated interface testing method according to claim 1, characterized in that, After receiving the test data, the interface testing device performs format standardization processing on the test data to obtain the feedback data.

5. The automated interface testing method according to claim 1, characterized in that, The interface testing equipment includes: The main control module is used to generate corresponding functional test information according to the test instructions; Multiple test modules are electrically connected to the main control module, and each test module has a corresponding test interface. The multiple test interfaces corresponding to the multiple test modules are all different. The test interface is used to output the functional test information to the interface under test and to receive test data. The feedback data includes the test data.

6. The automated interface testing method according to claim 5, characterized in that, The interface under test includes a UART interface, the test commands include UART interface test commands, and the test module includes: A UART interface module is electrically connected to the main control module. The UART interface module includes a UART test interface, which is used to electrically connect to the UART interface. The main control module is used to generate UART interface function test information according to the UART interface test command and transmit it to the UART interface module; the UART test interface is used to receive UART interface test data generated after the UART interface executes the UART interface function test information, and the feedback data includes the UART interface test data.

7. The automated interface testing method according to claim 5, characterized in that, The testing module includes a console interface module, which is electrically connected to the main control module. The edge computing terminal sends test commands to the main control module through the console interface module, and the main control module transmits the feedback data to the edge computing terminal through the console interface module.

8. The automated interface testing method according to claim 1, characterized in that, The interface under test is connected to the corresponding interface under test of the interface testing device through the test interface of the interface testing device, and commands are issued in an interactive manner.

9. The automated interface testing method according to claim 8, characterized in that, For local extended testing, the edge computing terminal is directly controlled by its edge control program, and the data is processed locally.

Images