A method for testing an interface of a circuit board

Abstract

The application relates to a circuit board interface test method, which comprises the following steps: reading board card identification information of the circuit board; loading a corresponding test configuration file according to the board card identification information of the circuit board; performing interface test on multiple interfaces of the circuit board according to the test configuration file; collecting relevant state data of the interface test; judging whether the interface test passes the test; if the interface test passes, a test report of test passing is generated; if the interface test fails, fault classification is performed according to a preset rule, and a test report of test failing is generated. The application can optimize the multiple interface test method of the circuit board.

Description

Technical Field

[0001] This invention relates to the field of testing, and more particularly to an interface testing method for circuit boards. Background Technology

[0002] Circuit board cards (such as circuit boards) serve as the core hardware carriers for embedded terminals, industrial control equipment, IoT gateways, edge computing hardware, and multimedia terminal devices. These cards integrate numerous peripheral interfaces, including USB interfaces, asynchronous serial ports, Ethernet interfaces, display output interfaces, audio codec interfaces, wireless communication module interfaces, Type-C composite interfaces, general purpose input / output (GPIO) interfaces, and storage media interfaces. Before leaving the factory, all interface functions of the circuit board must undergo full functional verification to ensure that hardware soldering, component assembly, firmware drivers, and underlying software configuration all comply with product design specifications.

[0003] With the rapid iteration of embedded hardware technology, the same hardware platform can spawn multiple circuit board versions. These versions are created by removing peripheral interfaces, replacing peripheral components, adjusting resistor divider networks, and changing board traces, resulting in a series of circuit board products. While the core processor remains the same across different models within the same series, significant differences exist in the types and numbers of peripheral interfaces, device node paths, GPIO definitions, screen display parameters, audio codec chip models, and wireless communication module selections. During the board manufacturing process, after each circuit board is surface-mounted, interface function testing is mandatory to eliminate defective boards with poor soldering, component failures, interface damage, firmware driver incompatibility, or underlying configuration errors. However, the industry currently lacks a unified automated testing system for the various interfaces of circuit boards, revealing numerous deficiencies in mass production and multi-version mixed testing scenarios. Summary of the Invention

[0004] Therefore, to overcome at least some of the defects and deficiencies of the prior art, the present invention provides an interface testing method for a circuit board, comprising: Read the board identification information of the circuit board; Based on the board identification information of the circuit board, load the corresponding test configuration file; According to the test configuration file, perform interface tests on multiple interfaces of the circuit board; Collect relevant status data for the interface test; and Determine whether the interface test passes; If the interface test passes, a test report indicating that the test has passed is generated. If the interface test fails, the fault will be classified according to preset rules, and a test report of test failure will be generated.

[0005] In one embodiment, in the step of reading the board identification information, the board hardware identity recognition is performed, and the board multidimensional identification information is read. The multidimensional identification information includes at least two of the following identification sources: GPIO pin level combination information, board identity field written in the EEPROM non-volatile memory area, analog voltage sampling value corresponding to the ADC sampling voltage divider resistor, hardware serial number read by the CPU chip, VID / PID of the USB device tree and USB physical topology path, and hardware version tag file pre-stored in the system partition.

[0006] In one embodiment, the multi-dimensional identification information obtained is compared with a preset model matching table to identify the board model and hardware version number corresponding to the circuit board under test.

[0007] In one embodiment, each record in the preset model matching table includes: a set of multi-dimensional identification features of the board, the corresponding board model string, the hardware version number, and the index path of the corresponding test configuration file.

[0008] In one embodiment, after reading is completed, the multi-dimensional identification information is verified and fused; when the reading results of multiple identification sources conflict, the higher priority identification source is used according to the preset priority strategy; when the key identification source fails to read, an alarm is triggered, the test process is terminated, and a board identity recognition anomaly prompt is output.

[0009] In one embodiment, during the step of collecting relevant status data, the system's multidimensional status raw data is automatically collected before, during, and after each test item is executed.

[0010] In one embodiment, the system's multidimensional state raw data includes global information and single test item binding information. The global information includes: UTC test timestamp, board unique serial number, board model, hardware version number, bootloader version, operating system firmware version, kernel version number, test station number, and / or operator number. The single test item binding information includes: test start timestamp, test end timestamp, test execution return code, device node existence detection result, driver module loading status, dmesg kernel log fragment, sysfs node read raw value, communication send and receive raw message, error code, test time, and / or peripheral register read snapshot.

[0011] In one embodiment, the interface testing of the plurality of interfaces includes at least two of the following: USB interface testing, serial port testing, Ethernet port testing, display output interface testing, audio interface testing, communication module testing, Type-C composite interface testing, GPIO input / output testing, and storage medium read / write testing.

[0012] In one embodiment, in the interface testing step, for each test item, the actual collected data and the preset judgment threshold are compared to obtain the preliminary result of the single test; when the test item is judged to be a failure, the fault judgment rule set is called, and the root cause of the fault is automatically classified based on the collected multi-dimensional state raw data, and standardized fault classification labels and auxiliary explanatory text are output.

[0013] In one embodiment, when a test item is determined to pass, a test normal label is marked. In each interface test task, all the multi-dimensional state raw data collected for this test are bound and associated with the test result.

[0014] As can be seen from the above, this application can automatically identify different board models or hardware versions, and automatically load corresponding test items according to different board models to execute automated tests of multiple interfaces. Furthermore, it can automatically collect system status, driver information, device node and log information during the test, and automatically classify the cause of failure when the test fails, and then generate a traceable test report for production, debugging and after-sales analysis. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating a testing method provided in an embodiment of the present invention.

[0017] Figure 2 This is a schematic diagram of a fault classification process provided in an embodiment of the present invention.

[0018] Figure 3 This is a schematic diagram of the output report process provided in an embodiment of the present invention.

[0019] Figure 4 This is a schematic diagram of a testing system provided in an embodiment of the present invention.

[0020] Figure 5 This is a schematic diagram of a storage medium module provided in an embodiment of the present invention. Detailed Implementation

[0021] 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 of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] This invention discloses an automated testing method and fault tracing method for multi-interface circuit boards. It can be applied to an automated testing system for circuit boards, which can run locally on the circuit board under test or on a host testing fixture electrically connected to the circuit board. The circuit board under test can integrate several peripheral interfaces, including at least two of the following: USB interface, asynchronous serial port, Ethernet interface, display interface, audio interface, wireless communication module interface, Type-C composite interface, GPIO interface, and storage interface. Figure 1 As shown, the method includes the following steps: Step S100: Read the board identification information of the circuit board; Step S200: Load the corresponding test configuration file based on the board identification information of the circuit board; Step S300: Perform interface tests on multiple interfaces of the circuit board according to the test configuration file; Step S400: Collect relevant status data for the interface test; Step S500: Determine whether the interface test passes. If the interface test passes, generate a test report; if the interface test fails, classify the fault according to preset rules and generate a test failure report.

[0023] Further, in step S100, the board identification information of the circuit board can be read, the hardware identity recognition of the circuit board under test can be performed, and the multi-dimensional identification information of the board can be read. The multi-dimensional identification information may include at least two of the following identification sources: GPIO pin level combination information, board identity field written in the EEPROM non-volatile memory area, analog voltage sampling value corresponding to the ADC sampling voltage divider resistor, hardware serial number read by the CPU chip, VID / PID of the USB device tree and USB physical topology path, and hardware version tag file pre-stored in the system partition.

[0024] Furthermore, in step S100, the multi-dimensional identification information obtained can be compared with a preset model matching table to identify the board model and hardware version number corresponding to the circuit board under test.

[0025] Furthermore, the specific execution steps of hardware identity recognition in step S100 may include: after the test program starts, reading data from various recognition sources in parallel or sequentially; after reading, verifying and fusing the multi-dimensional recognition information; when there is a conflict in the reading results of multiple recognition sources, the higher priority recognition source shall prevail according to the preset priority strategy; when the key recognition source fails to read, an alarm is triggered, the test process is terminated, and an abnormal board identity recognition prompt is output.

[0026] An example priority setting is as follows: the board identification field stored in the EEPROM has the highest priority, followed by the CPU hardware serial number, then the GPIO level combination, then the ADC voltage divider sampling voltage, then the USB topology information, and finally the system partition hardware version tag file. This multi-source verification avoids model identification errors caused by damage to a single identification source or abnormal reading.

[0027] Furthermore, the preset model matching table is pre-stored locally on the test system or on a remote server. Each record in the model matching table includes: a set of multi-dimensional identification features of the board, the corresponding board model string, the hardware version number, and the index path of the corresponding test configuration file. After the system completes the collection of multi-dimensional identification information, it traverses the model matching table, performs feature matching, and outputs the uniquely matching board model and hardware version; if multiple matching records exist, or if no matching record exists, the model identification is deemed to have failed, the test is terminated, and an exception log is output.

[0028] In one embodiment, the board identification step may include one or more of the following: reading GPIO level combinations; reading the board model stored in EEPROM; reading ADC voltage values ​​and identifying the hardware version by voltage division with different resistors; reading the device serial number in the CPU or system; reading the VID, PID, interface number, and physical topology path of the USB device; and reading the hardware version information in the configuration partition or file system.

[0029] In one embodiment, the system can match the read identification information with a preset model table to determine the model and hardware version of the circuit board under test. For example: When GPIO2_D6 = 0 and GPIO3_A0 = 1, it is identified as a type A board. When GPIO2_D6 = 1 and GPIO3_A0 = 1, it is identified as a type B board.

[0030] Furthermore, in step S200, the test configuration file bound to the identified board model and hardware version number can be automatically retrieved and loaded.

[0031] Furthermore, the test configuration file is, for example, a structured format file such as JSON, YAML, or XML. Each board model-hardware version combination corresponds to an independent test configuration file. The internal configuration fields of the test configuration file include: a list of interface test items, an enable / disable switch for each test item, a set of device node paths corresponding to peripherals, a test execution script / command sequence, input parameters, expected return values, judgment thresholds, communication timeout thresholds, retry counts, a set of fault judgment rule IDs, a list of kernel log filtering keywords, log storage paths, and a report output format template. The test configuration file supports extensible customization of adding test items; production line personnel only need to modify the configuration file, without modifying the main test program code, to adapt to new circuit board derivative board versions. In step S300, the test configuration file can be parsed to obtain the complete set of test items to be executed on the board under test, the device node paths corresponding to each test item, test execution instructions, test judgment thresholds, maximum timeout time, a set of fault judgment rules, log output paths, and report output templates. The test configuration file supports extensible customization of adding test items; production line personnel only need to modify the configuration file, without modifying the main test program code, to adapt to new circuit board derivative board versions.

[0032] In one embodiment, the test configuration file may include: a list of interfaces that the board needs to be tested; the device node corresponding to each interface; the test command for each interface; the judgment criteria for each interface; the timeout period for each interface; the error classification rules for each interface; the log storage path; and the test report format. For example, Type A boards need to test USB, Ethernet, serial, audio, and display interfaces; Type B boards need to test USB, Ethernet, 4G module, and Type-C interface. By automatically loading the configuration, manual selection of incorrect test scripts can be avoided.

[0033] In step S300, based on the test configuration file, multiple automated interface test tasks can be scheduled and executed sequentially or in parallel. Furthermore, the multiple automated interface test steps in step S300 may include at least two of the following: USB interface testing, serial port testing, Ethernet port testing, display output interface testing, audio interface testing, communication module testing, Type-C composite interface testing, GPIO input / output testing, and storage medium read / write testing.

[0034] The steps for performing USB interface tests may include, for example: detecting the USB bus enumeration status; reading the USB device VID and PID; verifying whether the VID / PID matches the design expectations; detecting whether the USB device nodes under / dev are generated normally; reading the USB physical topology path; performing USB read / write stress tests; and collecting the USB subsystem kernel logs.

[0035] The serial port test execution steps may include, for example,: detecting whether the tty serial port device node exists; setting the serial port baud rate, parity, and stop bit parameters; issuing a preset test command; waiting to receive the serial port return message; comparing the received message with the expected response; counting the number of communication timeouts; and collecting the serial port subsystem kernel print logs.

[0036] Ethernet port testing steps may include, for example: detecting network PHY device nodes; reading port link status; obtaining network card MAC address and IP address; performing ping connectivity test; performing iperf bandwidth rate test; calculating packet loss rate; and collecting network subsystem dmesg logs.

[0037] The test execution steps for the display output interface may include, for example, the following: the board under test outputs a preset standard test image, which includes a solid color image, a checkerboard image, and a positioning mark pattern; an external image acquisition tool camera captures the screen output image; image recognition and analysis are performed on the acquired image; it is identified whether there are black screen, distorted screen, color cast, abnormal resolution, or screen offset faults; and the display driver kernel log is collected.

[0038] The audio interface test execution steps may include, for example: verifying the existence of the sound card device node; reading the mixer configuration parameters; playing standard test audio waveforms on the board; acquiring the output audio signal using an external audio acquisition tool; analyzing the audio signal amplitude and frequency to determine whether the audio path output is normal; and acquiring audio codec driver logs.

[0039] The test execution steps for a wireless communication module may include, for example: detecting the module's serial port node; issuing AT commands for interaction; reading the SIM card's presence status; reading the network signal strength; detecting the module's dial-up network status; obtaining the module's IP address and performing an external network connectivity test; and recording the AT command return code.

[0040] The test execution steps for the Type-C composite interface may include, for example, detecting the Type-C insertion and removal states (positive and negative); identifying the current Type-C operating mode: USB data mode, PD power supply mode, DP video output mode, and audio accessory mode; reading the CC pin status register; verifying whether the switching of each mode meets the design expectations; and recording error logs during the mode switching process.

[0041] The steps for performing GPIO interface tests may include, for example: configuring the GPIO pin to output mode, outputting high and low levels, and reading the sampled level; configuring the GPIO to input mode, inputting the level from an external tool, and reading the GPIO sampled level; comparing the consistency between the output and the sampled level; and recording GPIO subsystem errors.

[0042] The steps for performing a storage medium read / write test may include, for example, detecting storage device nodes; performing file read / write, verification, and validation; calculating read / write time and errors; and recording storage medium driver error information.

[0043] In step S400, before, during, and after each test item is executed, multi-dimensional raw system status data is automatically collected. The automatically collected multi-dimensional raw system status data may include, for example, global information and single test item binding information. Global information may include, for example, UTC test timestamp, board unique serial number, board model, hardware version number, bootloader version, operating system firmware version, kernel version number, test station number, and operator number. Single test item binding information may include, for example, the test start timestamp, end timestamp, test execution return code, device node existence detection result, driver module loading status, dmesg kernel log fragment, sysfs node read raw values, communication send / receive raw messages, error codes, test duration, and peripheral register read snapshots.

[0044] In step S400, the collected information may include: system time; board model; software version; kernel version; device node list; driver loading status; dmesg log; test command return value; communication data; error codes; test time; and tester or workstation number. This information is bound to the test results and saved for easy review later.

[0045] In step S500, for each test item, the actual collected data and the preset judgment threshold in the configuration file can be compared to obtain the preliminary result of the single test. When a test item is judged as a failure, the fault judgment rule set is invoked to automatically classify the root cause of the fault based on the collected multi-dimensional state raw data, and output standardized fault classification labels and auxiliary explanatory text. When a test item is judged as a pass, a test normal label is marked. In each interface test task, all multi-dimensional state raw data collected for this test can be bound and associated with the test result, not just the final OK / NG result, preserving complete original evidence to facilitate subsequent backtracking and reproduction of the fault.

[0046] Furthermore, the fault judgment rule set in step S500 can be multi-condition logical judgment rules, with the rule input being the multi-dimensional state raw data collected in step S400. The rules can employ a combination of logical AND and logical OR conditions, and different fault phenomena correspond to different standardized fault classification labels.

[0047] In different embodiments, when a test item fails, the system does not simply output "failure," but rather classifies the fault according to preset rules. For example... Figure 2As shown, for example: when a device node does not exist, it can be determined that the device is not recognized, the driver is not loaded, or the hardware is not connected; when the driver status is abnormal, it can be determined that the driver is abnormal; when a device node exists but communication fails, it can be determined that the communication is abnormal, the interface is abnormal, or the peripheral is abnormal; when there is timeout information in the driver log, it can be determined that the interface communication timeout has occurred; when there is a log error code, it can be determined that the error code classification is faulty; when the USB device VID / PID does not match, it can be determined that the device access is incorrect or the enumeration is abnormal; when the network port connection is abnormal, it can be determined that the network cable, PHY, power supply, or hardware connection is abnormal; when the display image recognition fails, it can be determined that the display interface is abnormal, the screen parameters are incorrect, or the image output is abnormal; when the audio device exists but has no output, it can be determined that the audio codec, power amplifier, mixer configuration, or hardware path is abnormal. Therefore, the automatic fault classification of the method / system of this application can reduce the time spent on manual log analysis.

[0048] In some embodiments, when a test failure meets the conditions of multiple fault rules, the fault classification label with the highest priority can be output according to the preset fault rule priority, and the remaining fault rules that are hit can be written as candidate faults into the report remarks field.

[0049] In some embodiments, such as Figure 3 As shown, when generating a report, it can include: integrating board identity information, software firmware information, full test results, fault classification tags, all collected multi-dimensional status raw data, and timestamp information to generate a standardized test report; persistent storage of the test report, establishing an index relationship between the board's unique identifier and the test report; support for multiple test records to be added to the same board without overwriting historical test data, completing fault tracing throughout the entire lifecycle of board test data.

[0050] In some embodiments, a test report may include: board model; board number; hardware version; software version; test time; test station; tester; test items; results for each test item; fault classification for failed items; key logs; raw test data; and final test conclusions. Test reports may be saved by date, board number, or batch number.

[0051] Furthermore, the test report in step S500 supports multiple output formats, such as JSON structured data files, CSV table files, log text files, and HTML visual web reports. Each test report file name includes the board's unique serial number, test timestamp, and batch number. The test report storage location can support local board's built-in Flash, SD memory card, local test tool hard drive, or remote backend server database. The test system maintains an index database, which stores the board's unique serial number and the storage path of all historical test reports for that board. When the same circuit board is tested repeatedly, a new independent test report file is created, the index database is appended with the new record, and the original historical report files are neither deleted nor overwritten, thus completely saving the records of multiple retests.

[0052] Furthermore, in one embodiment, step S500 may include a traceability query step, including: receiving the unique serial number of the board input from an external source, querying the index database, and retrieving all historical test reports of the board; parsing the reports to reproduce all original collected data, test results, and fault classification labels for each test; filtering and statistically analyzing the fault classification labels, hardware version, batch number, and test time to calculate the percentage of various faults occurring in the batch of boards, and outputting a fault statistics report for reverse optimization of the production process.

[0053] like Figure 4 As shown, this invention also discloses an automated testing system for multiple interfaces of a circuit board, used to implement the aforementioned method. The system includes: a test host 101, used to test multiple interfaces (e.g., USB, serial port, network port, display, audio, 4G, Type-C, etc.) of the circuit board under test (e.g., a PCB board); a test module 102, set within the test host 101, the test module 102 including: an interface test module 103, which loads a corresponding test configuration file based on the board identification information of the circuit board, and performs interface tests on multiple interfaces of the circuit board according to the test configuration file; a status acquisition module 104, used to acquire relevant status data of the interface tests; and a result determination module 105, used to determine whether the interface tests pass or fail.

[0054] In one embodiment, the test host is, for example, an industrial control host, and may be equipped with a motherboard, solid-state drive, memory, network port, USB host port, PCI-E expansion slot, and other components. The test module is, for example, a combination of software and hardware modules, and is configured inside the test host. Some data acquisition hardware is installed in the PCI-E expansion slot of the test host, for example, via PCI-E expansion cards.

[0055] In one embodiment, when the circuit board under test can be pressed and fixed on the test fixture, the fixture probes physically contact the pins of the circuit board under test (such as SDA, SCL, GND), and the I2C signal can be connected to the internal board identification and reading hardware of the test host (such as the I2C master control acquisition card) via the signal conversion backplane.

[0056] In one embodiment, the interface testing module and the status acquisition module can be implemented, for example, through a PCI-E plug-in hardware board and upper-layer driver software. The result determination module can be run by the CPU of the test host. The determination process can be partially offloaded to the FPGA hardware acceleration of the board. The determination logic can be programmed into the FPGA of the interface testing module board, or it can be entirely performed by the CPU of the test host for software determination.

[0057] In one embodiment, the interface testing module is, for example, a multi-functional interface testing PCIe board. The test host can send test commands to the test PCIe board to perform interface tests on multiple interfaces.

[0058] In one embodiment, the status acquisition module is, for example, a synchronous data acquisition PCIe board. The electrical status of the interface of the circuit board under test can be uploaded to the memory of the test host via a fixture probe and a signal adapter backplane. The relevant status data acquired includes, for example, sampled data such as interface voltage, interface operating current, communication messages, communication error count, level timing, transient overvoltage and overcurrent.

[0059] In one embodiment, the test system further includes a log module 106 connected to the test module 102 to output anomaly logs. The log module 106 can be implemented, for example, through non-volatile storage hardware (such as a solid-state drive, SSD) built into the test host. The test module can write abnormal events, raw hardware sampling data, channel numbers, and timestamps to the log module 106 via the test host's internal system bus, thus outputting the anomaly logs.

[0060] In one embodiment, the testing system further includes a reporting module 107 connected to the testing module 102, for generating a test report based on the determination result of the result determination module 105. The report file can be stored in the memory of the testing host and can be pushed to an external server via the network port hardware of the testing host, or output to a USB flash drive via a USB interface.

[0061] This invention also discloses a computer-readable storage medium storing a computer-executable program. When the computer-executable program is run by a processor, it executes all the steps of the aforementioned automated testing and fault tracing method for multi-interface circuit boards. Figure 5As shown, one embodiment of the present invention provides a storage medium, such as a computer-readable storage medium 500. The computer-readable storage medium 500 is, for example, a non-volatile memory, such as a magnetic medium (e.g., hard disk, floppy disk, and magnetic tape), an optical medium (e.g., CD-ROM and DVD), a magneto-optical medium (e.g., optical disc), and hardware devices specifically configured for storing and executing computer-executable instructions (e.g., read-only memory (ROM), random access memory (RAM), flash memory, etc.). Computer-executable instructions 510 are stored on the computer-readable storage medium 500. The computer-readable storage medium 500 can be executed by one or more processors or processing devices to implement the aforementioned method.

[0062] The circuit boards tested by the methods and / or systems provided 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 servers.

[0063] Therefore, this application can automatically identify different board models or hardware versions, and automatically load corresponding test items according to different board models to execute automated tests on multiple interfaces. Furthermore, it can automatically collect system status, driver information, device node and log information during the test, and automatically classify the cause of failure when the test fails, and then generate a traceable test report for production, debugging and after-sales analysis.

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

[0065] 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. A method for testing the interface of a circuit board, characterized in that, include: Read the board identification information of the circuit board; Based on the board identification information of the circuit board, load the corresponding test configuration file; Perform interface tests on multiple interfaces of the circuit board according to the test configuration file. Collect relevant status data for the interface test; and Determine whether the interface test passes; If the interface test passes, a test report indicating that the test has passed is generated. If the interface test fails, the fault is classified according to preset rules, and a test failure report is generated. When a test failure meets the conditions of multiple fault rules, the fault classification label with the highest priority is output according to the preset fault rule priority, and the remaining fault rules are written as candidate faults into the report remarks field. The test report is persistently stored, and an index relationship is established between the board's unique identifier and the test report. Multiple test records can be added to the same board without overwriting historical test data, thus completing the full lifecycle fault tracing of the board's test data.

2. The method according to claim 1, characterized in that, In the step of reading the board identification information, the hardware identity recognition of the circuit board is performed, and the multi-dimensional identification information of the board is read. The multi-dimensional identification information includes at least two of the following identification sources: GPIO pin level combination information, board identity field written in the EEPROM non-volatile memory area, analog voltage sampling value corresponding to the ADC sampling voltage divider resistor, hardware serial number read by the CPU chip, VID / PID of the USB device tree and USB physical topology path, and hardware version tag file pre-stored in the system partition.

3. The method according to claim 2, characterized in that, The multi-dimensional identification information obtained is compared with a preset model matching table to identify the board model and hardware version number corresponding to the circuit board under test.

4. The method according to claim 3, characterized in that, Each record in the preset model matching table includes: a set of multi-dimensional identification features of the board, the corresponding board model string, the hardware version number, and the index path of the corresponding test configuration file.

5. The method according to claim 2, characterized in that, After reading is completed, the multi-dimensional identification information is verified and fused; when there is a conflict in the reading results of multiple identification sources, the higher priority identification source shall prevail according to the preset priority strategy. If the key identification source fails to read, an alarm is triggered, the test process is terminated, and an abnormal board identification message is output.

6. The method according to claim 1, characterized in that, In the process of collecting relevant status data, the system automatically collects multi-dimensional status raw data before, during, and after each test item is executed.

7. The method according to claim 6, characterized in that, The system's multidimensional state raw data includes global information and single test item binding information. The global information includes: UTC test timestamp, board unique serial number, board model, hardware version number, bootloader version, operating system firmware version, kernel version number, test station number, and / or operator number. The single test item binding information includes: test start timestamp, test end timestamp, test execution return code, device node existence detection result, driver module loading status, dmesg kernel log fragment, sysfs node read raw value, communication send and receive raw message, error code, test time, and / or peripheral register read snapshot.

8. The method according to claim 1, characterized in that, The interface tests for the multiple interfaces include at least two of the following: USB interface test, serial port test, Ethernet port test, display output interface test, audio interface test, communication module test, Type-C composite interface test, GPIO input / output test, and storage medium read / write test.

9. The method according to claim 6, characterized in that, In the interface testing steps, for each test item, the actual collected data and the preset judgment threshold are compared to obtain the preliminary result of the single test. When the test item is judged to be a failure, the fault judgment rule set is called to automatically classify the root cause of the fault based on the collected multi-dimensional state raw data, and output standardized fault classification labels and auxiliary explanatory text.

10. The method according to claim 9, characterized in that, When a test item is deemed to have passed, a "test normal" label is set. In each interface test task, all the multi-dimensional state raw data collected for this test are bound and associated with the test result.

Images