Development board automatic stability test method and system, terminal and storage medium

Abstract

The invention discloses an automatic stability test method and system for a development board, a terminal and a storage medium, and the method comprises the steps: synchronously applying a dynamically changing CPU load, an environment temperature gradient and various bus pressures to a tested development board in an automatic test environment, and obtaining the development board under multi-factor coupling; through a distributed monitoring system, software logs and hardware signals of the development board are collected and associated in real time, and state monitoring is carried out on the development board based on the software logs and the hardware signals; when it is monitored that the development board breaks down or has no response, a recovery mechanism is automatically triggered, system field information containing software logs and hardware signals is stored, and a test process is restarted; based on system field information and historical test data, test parameters are dynamically adjusted through a prediction algorithm, and the whole process from pressure application to system monitoring to fault analysis and recovery is automatically executed. According to the invention, a complete automatic test process of full-automatic precise positioning is realized, and a test closed loop is formed.

Description

Technical Field

[0001] This invention relates to the field of development board product testing technology, and in particular to an automated stability testing method, system, terminal, and computer-readable storage medium for development boards. Background Technology

[0002] A development board is a hardware platform that integrates components such as a processor, memory, and input / output interfaces, specifically designed for embedded system development, debugging, and prototyping. It serves as a bridge between software and hardware, enabling developers to quickly validate ideas and build prototypes of intelligent devices.

[0003] The stability testing of existing development board products mainly relies on manual operation, which results in long testing cycles, high labor costs, and an inability to fully cover all user-required functionalities.

[0004] Specifically, existing technologies suffer from the following problems: First, the testing scenarios are limited, mostly focusing on single-point functional testing, lacking verification of system stability under the combined effects of multiple factors, and unable to simulate stress conditions in real-world complex environments; second, the testing cycle is short, typically covering only 24-48 hours, making it difficult to detect stability issues that may arise during long-term operation; third, the testing process relies too heavily on manual processes, resulting in low testing efficiency and an inability to quickly respond to product iteration needs; fourth, fault recording is passive, lacking automated recovery mechanisms and fault prediction capabilities, leading to low efficiency in problem localization and resolution. These problems collectively make it difficult to efficiently and comprehensively ensure system robustness and stability during rapid iteration and product launches of development boards.

[0005] Therefore, existing technologies still need to be improved and developed. Summary of the Invention

[0006] The main objective of this invention is to provide an automated stability testing method, system, terminal, and computer-readable storage medium for development boards, aiming to solve the problems of insufficient efficiency and depth in the stability testing of development board products in the prior art, making it difficult to efficiently and comprehensively ensure the robustness and stability of the system.

[0007] To achieve the above objectives, the present invention provides an automated stability testing method for development boards, which includes the following steps: In an automated testing environment, dynamically changing CPU loads, ambient temperature gradients, and various bus pressures are synchronously applied to the development board under test, resulting in a development board under the coupling of multiple factors. A distributed monitoring system consisting of a host computer control terminal, a board-side agent module, and hardware debugging and monitoring equipment is used to collect and correlate the software logs and hardware signals of the development board in real time, and to monitor the status of the development board based on the software logs and hardware signals. When the development board is detected to be malfunctioning or unresponsive, the recovery mechanism is automatically triggered to save the system's on-site information, including the software logs and hardware signals, and restart the testing process. Based on the system's on-site information and historical test data, the test parameters are dynamically adjusted through a predictive algorithm, and the entire process from pressure application and system monitoring to fault analysis and recovery is automatically executed.

[0008] Optionally, the automated stability testing method for the development board, wherein the step of synchronously applying dynamically changing CPU load, ambient temperature gradient, and various bus stresses to the development board under test to obtain a development board under multi-factor coupling, specifically includes: Using a load generation tool, the CPU utilization of the development board under test is dynamically adjusted according to a preset sine wave or square wave pattern. The test board is placed in a temperature chamber to achieve a gradient change in ambient temperature between a preset low temperature value and a preset high temperature value. Apply continuous or periodic stress loads to at least two of the memory, network interface, USB interface, CAN bus, and GPU of the development board under test.

[0009] Optionally, in the automated stability testing method for the development board, the hardware signals include: kernel stack information and memory dump data obtained through the JTAG debugging interface when the system crashes, and power supply current ripple monitored by the programmable power supply.

[0010] Optionally, the automated stability testing method for the development board, wherein when a fault or unresponsiveness is detected on the development board, an automatic recovery mechanism is triggered to save system state information including the software logs and hardware signals and restart the testing process, specifically including: When the development board is detected to be faulty or unresponsive, the system's on-site information is captured and saved by the hardware debugging and monitoring equipment. The development board is restarted by performing a hard reset operation on the development board using the hardware debugging and monitoring equipment. After the development board restarts, the host computer control terminal automatically reloads the test cases to the development board and triggers their execution to continue the testing process.

[0011] Optionally, the automated stability testing method for the development board, wherein the step of dynamically adjusting the test parameters based on the system's on-site information and historical test data using a prediction algorithm specifically includes: Collect and organize the system's on-site information and historical test data to obtain organized data. Construct a training dataset based on the organized data and train a machine learning model based on the training dataset to obtain a trained machine learning model. During the test execution, the software logs and real-time monitoring data of the hardware signals are input into the trained machine learning model to obtain the system risk level; Based on the system risk level, at least one parameter among the following in subsequent tests—the CPU load application mode, the rate of change of the temperature gradient, or the load intensity of the bus pressure—is dynamically adjusted.

[0012] Optionally, the automated stability testing method for the development board, wherein the automated execution of the entire process from stress application and system monitoring to fault analysis and recovery specifically includes: Based on a preset test plan, the host computer control terminal schedules and coordinates the pressure application module, the board-side agent module, and the hardware debugging and monitoring equipment to sequentially trigger and collaboratively execute pressure application operations, system monitoring operations, and fault recovery operations. The pressure application parameters recorded during the pressure application operation, the monitoring data collected during the system monitoring operation, and the system field information saved during the fault recovery operation are stored in a unified database in real time. Fault analysis is performed based on the data stored in the unified database, and the analysis results are fed back into the prediction algorithm to form a closed-loop control process for dynamic adjustment of test parameters.

[0013] Optionally, the automated stability testing method for the development board further includes: Before starting the automated testing process on the development board, record the firmware version identification information loaded on the development board and the hardware version information of the development board; When the development board is detected to be malfunctioning or unresponsive, a binary search algorithm is automatically executed based on the recorded version identification information to determine whether the situation is related to a specific software code submission. Alternatively, cross-validation analysis can be performed on test data from development boards running the same firmware version but with different hardware versions based on the hardware version information to determine whether the situation is related to a specific hardware version. An attribution report is generated based on the judgment results, and the attribution report is sent to relevant personnel.

[0014] Furthermore, to achieve the above objectives, the present invention also provides an automated stability testing system for development boards, wherein the automated stability testing system for development boards includes: The pressure coupling and application module is used to synchronously apply dynamically changing CPU load, ambient temperature gradient and various bus pressures to the development board under test in an automated testing environment, so as to obtain the development board under multi-factor coupling. The software and hardware collaborative monitoring module is used to collect and correlate the software logs and hardware signals of the development board in real time through a distributed monitoring system consisting of a host computer control terminal, a board-side agent module, and hardware debugging and monitoring equipment, and to monitor the status of the development board based on the software logs and hardware signals. The fault recovery and saving module is used to automatically trigger the recovery mechanism when the development board is detected to have a fault or no response, save the system site information including the software logs and hardware signals, and restart the test process; The intelligent prediction and optimization module is used to dynamically adjust test parameters based on the system's on-site information and historical test data through prediction algorithms, and to automatically execute the entire process from pressure application and system monitoring to fault analysis and recovery.

[0015] In addition, to achieve the above objectives, the present invention also provides a terminal, wherein the terminal includes: a memory, a processor, and a development board automated stability testing program stored in the memory and executable on the processor, wherein when the development board automated stability testing program is executed by the processor, it implements the steps of the development board automated stability testing method as described above.

[0016] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores an automated stability testing program for a development board, and when the automated stability testing program for the development board is executed by a processor, it implements the steps of the automated stability testing method for the development board as described above.

[0017] In this invention, within an automated testing environment, dynamically changing CPU loads, ambient temperature gradients, and various bus pressures are synchronously applied to the development board under test, resulting in a development board subjected to multi-factor coupling. A distributed monitoring system, consisting of a host computer control terminal, a board-side agent module, and hardware debugging and monitoring equipment, collects and correlates the development board's software logs and hardware signals in real time, and monitors the development board's status based on these logs and signals. When a fault or unresponsiveness is detected on the development board, a recovery mechanism is automatically triggered, saving system context information containing the software logs and hardware signals and restarting the testing process. Based on the system context information and historical test data, test parameters are dynamically adjusted using a predictive algorithm, and the entire process from pressure application and system monitoring to fault analysis and recovery is automatically executed. This invention achieves a fully automated, precisely positioned, and complete automated testing process, with software and hardware combined to form a closed-loop testing system. Attached Figure Description

[0018] Figure 1 This is a flowchart of a preferred embodiment of the automated stability testing method for the development board of the present invention; Figure 2 This is a flowchart of the over-prediction algorithm dynamically adjusting test parameters in the automated stability testing method for the development board of this invention; Figure 3 This is a flowchart of the automated execution process from pressure application and system monitoring to fault analysis and recovery in the automated stability testing method for the development board of this invention; Figure 4 This is a structural diagram of a preferred embodiment of the automated stability testing system for development boards of the present invention; Figure 5 This is a structural diagram of a preferred embodiment of the terminal of the present invention. Detailed Implementation

[0019] This application provides an automated stability testing method, system, and terminal for development boards. To make the objectives, technical solutions, and effects of this application clearer and more explicit, the following detailed description is provided with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit the scope of this application.

[0020] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0021] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0022] The development board automated stability testing method described in the preferred embodiment of the present invention, such as... Figure 1 As shown, the automated stability testing method for the development board includes the following steps: Step S10: In an automated testing environment, dynamically changing CPU load, ambient temperature gradient, and various bus pressures are synchronously applied to the development board under test to obtain a development board under multi-factor coupling.

[0023] The process of synchronously applying dynamically changing CPU load, ambient temperature gradient, and various bus pressures to the development board under test results in a development board under multi-factor coupling, specifically including: Using a load generation tool, the CPU utilization of the development board under test is dynamically adjusted according to a preset sine wave or square wave pattern. The test board is placed in a temperature chamber to achieve a gradient change in ambient temperature between a preset low temperature value and a preset high temperature value. Apply continuous or periodic stress loads to at least two of the memory, network interface, USB interface, CAN bus, and GPU of the development board under test.

[0024] Understandably, to address the issue of existing test scenarios being too simplistic and unable to simulate complex environments, this embodiment employs a dynamic load, temperature gradient, and bus stress synchronous testing mechanism. It utilizes cpustress (a CPU stress testing tool) written in C to dynamically adjust the CPU load, implements a temperature cycle from -20°C to 70°C using a temperature chamber, and applies multi-dimensional, dynamically changing stress to various key modules and interfaces of the development board through methods such as injecting memory stress using memtester (an open-source memory fault detection tool), performing continuous Ethernet streaming using iperf3 (a network performance testing tool), repeatedly mounting and unmounting USB devices using scripts, simulating CAN bus data, and GPU stress. For example, it uses memtester for bit flip and block movement tests, iperf3 for continuous TCP / UDP streaming, repeatedly mounts and unmounts USB devices using scripts, and continuously plays 4K video or runs graphics rendering tasks. These stresses are not performed in isolation but are applied synchronously, thus simulating the complex operating conditions under the coupling of multiple factors in real-world usage scenarios, effectively exposing system stability issues under extreme conditions. By applying the above multiple factors simultaneously, the system can realistically simulate complex coupled environments, significantly improving test coverage and problem detection capabilities.

[0025] Step S20: Through a distributed monitoring system consisting of a host computer control terminal, a board-side agent module, and hardware debugging and monitoring equipment, the software logs and hardware signals of the development board are collected and associated in real time, and the status of the development board is monitored based on the software logs and hardware signals.

[0026] In this embodiment, to address the issues of passive fault recording and difficulty in fault location in existing systems, a distributed monitoring system combining hardware and software is constructed. The board-side agent module (based on Java managed code) is responsible for real-time monitoring of the development board's resources (temperature, memory, CPU) and executing tests. The host computer control terminal deploys an automated test server, connected to the cluster of development boards under test via a gigabit switch, and integrates a log storage database. Crucially, this system combines hardware signals such as the JTAG debugging interface and programmable power supply, enabling precise capture of kernel stack information, RAM dumps, and current ripple anomalies during system crashes. Combined with real-time parsing of software logs (such as kernel logs) and the DBSCAN clustering algorithm to identify outliers, it achieves accurate fault location, even tracing back to the driver or circuit level, thus overcoming the shortcomings of purely software monitoring.

[0027] Furthermore, the hardware signals include: kernel stack information and memory dump data obtained through the JTAG debugging interface at the time of system crash, and power supply current ripple monitored by the programmable power supply.

[0028] Specifically, the information obtained through the JTAG debugging interface includes kernel stack information and RAM dump data. Kernel stack information: the kernel call stack of the current task at the time of the system crash, used to locate the crash point; RAM dump data: a memory snapshot at the time of the system anomaly, which can be used for subsequent offline analysis. Signals monitored through the programmable power supply include power supply current ripple. Power supply current ripple: reflects power quality; abnormal ripple may be related to circuit design, load surges, or hardware failures. Combining software logs with the above hardware signals enables precise fault location from the driver layer to the circuit layer, greatly improving the depth of problem analysis.

[0029] Step S30: When the development board is detected to be faulty or unresponsive, the recovery mechanism is automatically triggered to save the system site information containing the software logs and hardware signals and restart the test process.

[0030] Specifically, when the development board is detected to be malfunctioning or unresponsive, the system's on-site information is captured and saved through the hardware debugging and monitoring equipment. The development board is restarted by performing a hard reset operation on the development board using the hardware debugging and monitoring equipment. After the development board restarts, the host computer control terminal automatically reloads the test cases to the development board and triggers their execution to continue the testing process.

[0031] In this embodiment, when the monitoring system detects a board failure or unresponsiveness, the automated scheduling logic immediately triggers an interrupt handling mechanism. It reads the kernel stack via JTAG, saves the RAM dump, hard resets the board, marks the fault, and automatically restarts the test, ensuring test continuity and enabling unattended testing for over 72 hours. Simultaneously, by establishing a fault mode library and recording the PC register values, stack backtracking, and power supply traces for each failure, combined with machine learning algorithms, fault prediction and dynamic adjustment of test parameters make the testing process more intelligent and efficient. This achieves full automation from stress application and monitoring to analysis, significantly reducing manual intervention and improving testing efficiency and product iteration speed.

[0032] Step S40: Based on the system's on-site information and historical test data, dynamically adjust the test parameters using a prediction algorithm, and automatically execute the entire process from pressure application and system monitoring to fault analysis and recovery.

[0033] like Figure 2 As shown, the dynamic adjustment of test parameters based on the system's on-site information and historical test data, using a prediction algorithm, is achieved through the following steps.

[0034] Step S101: Collect the system's on-site information and the historical test data and organize them to obtain organized data. Construct a training dataset based on the organized data and train the machine learning model based on the training dataset to obtain the trained machine learning model.

[0035] In this embodiment, historical fault data and on-site information are collected to construct a training dataset. Machine learning algorithms (such as DBSCAN clustering, decision trees, neural networks, etc.) are used to train the model and establish a fault mode recognition model.

[0036] Specifically, the first step is to collect and organize data. The system continuously collects two types of core data: real-time system field information and historical test data.

[0037] Real-time system field information: Data packets saved each time the automatic recovery mechanism is triggered by a fault, specifically including: PC register value at the time of the crash, kernel stack backtrace information, complete RAM dump, abnormal current / voltage ripple traces recorded by the programmable power supply, and system resource (CPU, memory, temperature) monitoring time-series data for a period of time before the crash.

[0038] Historical test data: complete logs of all successful and failed test cycles, resource monitoring curves, and final stability index results (such as memory leak rate and CPU downclocking ratio).

[0039] Furthermore, a training dataset is constructed, and the features in the above data (such as specific stack function call sequences, current ripple frequency features, and memory growth slope) are associated and labeled with fault labels (such as "driver memory leak", "power instability leading to deadlock", and "temperature-triggered thermal throttling") to form a structured training dataset.

[0040] Step S102: During the test execution, the software logs and the real-time monitoring data of the hardware signals are input into the trained machine learning model to obtain the system risk level.

[0041] Understandably, during the test execution process, the software logs and the real-time monitoring data of the hardware signals (i.e., the kernel stack information, memory dump data and current ripple information) are input into the trained model, and the system risk level (such as low risk, medium risk and high risk) is output.

[0042] Specifically, this invention employs a combination of unsupervised and supervised learning. Unsupervised learning (such as DBSCAN clustering) is used to detect outliers in massive monitoring logs. Even if certain system behaviors do not lead to crashes, if their monitoring metrics (such as a specific memory allocation pattern accompanied by slight current fluctuations) deviate from the normal cluster, they will be identified as potential risk patterns and added to the fault mode library. Supervised learning utilizes the labeled fault mode library to train classification or regression models (such as decision trees and random forests). This model can learn the feature patterns preceding different faults.

[0043] During test execution, the trained machine learning model analyzes the input monitoring data stream in real time. For example, when the model detects that the current memory release pattern is similar to the precursors of historical "memory leak" failures and is accompanied by a specific CPU scheduler state, it will output a high system risk level (such as "high memory risk").

[0044] Step S103: Based on the system risk level, dynamically adjust at least one parameter among the following in subsequent tests: the application mode of CPU load, the rate of change of temperature gradient, or the load intensity of bus pressure.

[0045] In this implementation, test parameters are dynamically adjusted according to the risk level. For example, CPU load may be reduced or the rate of temperature change may be slowed to avoid known risks; or the stress on a certain type of bus may be increased to further expose potential problems. By dynamically adjusting at least one parameter among the CPU load application mode, the rate of temperature gradient change, or the load intensity of the bus stress in subsequent tests based on the system risk level, intelligent test scheduling and risk warning can be achieved, improving the relevance and safety of the tests.

[0046] Specifically, based on the system risk level output by the model, the system does not passively wait for a crash, but actively intervenes and dynamically adjusts subsequent test parameters to form an intelligent testing strategy: Avoidance-based adjustments: If a high risk is predicted, the stress intensity will be automatically reduced or the stabilization observation period will be extended. For example, if a "high risk of overheating" is predicted, the rate of change of the temperature gradient will be automatically reduced or the CPU load will be temporarily reduced.

[0047] Exploratory / verification tuning: To verify a preliminary anomalous pattern, the system may dynamically increase the load intensity of a specific bus stress (such as increasing the USB mounting frequency) to observe whether the suspected fault is reproduced more quickly and definitively, thereby accelerating problem localization.

[0048] The closed loop of parameter adjustment: the new test data generated after adjusting the parameters is used as feedback input to the model to verify the accuracy of the prediction and iteratively optimize the model, so as to realize the continuous self-evolution of the testing process.

[0049] like Figure 3 As shown, the automated execution of the entire process from pressure application and system monitoring to fault analysis and recovery is essentially about building a highly collaborative, data-closed-loop automated test operating system, which is achieved through the following steps.

[0050] Step S201: Based on a preset test plan, the host computer control terminal schedules and coordinates the pressure application module, the board-side agent module, and the hardware debugging and monitoring equipment to sequentially trigger and collaboratively execute pressure application operations, system monitoring operations, and fault recovery operations.

[0051] In this embodiment, the host computer control terminal schedules and coordinates the pressure application module, board-side agent module, hardware monitoring equipment, etc., based on a preset test plan (such as smoke test, rising phase, peak pressure, and recovery phase) to ensure orderly collaboration among all links.

[0052] Specifically, the host computer control terminal acts as the scheduling hub: it uses a Python testing framework (such as PyTest) as the orchestration engine to execute preset test plans. For example, it sends commands to the board via SSH or Agent to start tools such as cpustress and iperf3, and controls the temperature chamber to start temperature cycling. It starts the board-side Agent and the host computer monitoring service, continuously pulling data from the Prometheus exporter, JTAG adapter, and programmable power supply API. When the monitoring service alarms, the scheduler calls the fault recovery script to perform operations such as JTAG fetching and hard reset.

[0053] Step S202: The pressure application parameters recorded in the pressure application operation, the monitoring data collected in the system monitoring operation, and the system field information saved in the fault recovery operation are stored in a unified database in real time.

[0054] Specifically, all data generated in all stages, including the stress parameters of cpustress, the monitoring data collected by Prometheus, and the system site information captured by JTAG, are stored in real time in a unified database (specified as the Prometheus time-series database in the technical briefing, and long-term logs can be stored in a relational database such as MySQL) via message queues or direct writing.

[0055] Data is read from a unified database through Grafana dashboards, which display CPU load curves, temperature gradient graphs, memory usage trends, fault event markers, etc. in real time, making the entire testing process completely transparent to engineers.

[0056] Step S203: Perform fault analysis based on the data stored in the unified database, and feed the analysis results back to the prediction algorithm to form a closed-loop control process for dynamic adjustment of test parameters.

[0057] Understandably, the endpoint of the testing process is not recovery testing, but automated analysis. The system uses stored data to run analysis scripts, such as calculating memory leak rate (whether the Slab 24h increment is >5%), calculating CPU throttling ratio, or running the DBSCAN clustering algorithm to find new abnormal patterns.

[0058] These analytical results (such as "new anomaly pattern A discovered" or "memory leak rate exceeded the standard in this test") are structured and fed back into the prediction algorithm. The prediction algorithm updates the model or adjusts the risk assessment strategy based on the analytical results, while the scheduler may also determine the intensity or focus of the next round of testing based on the analytical results. This forms a complete closed-loop control process of "execution-monitoring-recovery-analysis-optimization".

[0059] As can be seen, this invention achieves unmanned operation and data-driven continuous optimization of the entire testing process, integrating discrete testing tasks into an intelligent, adaptive, and measurable complete system, which greatly improves the operational efficiency and quality insight depth of the testing laboratory.

[0060] Furthermore, the automated stability testing method for the development board also includes: Before starting the automated testing process on the development board, record the firmware version identification information loaded on the development board and the hardware version information of the development board; When the development board is detected to be malfunctioning or unresponsive, a binary search algorithm is automatically executed based on the recorded version identification information to determine whether the situation is related to a specific software code submission. Alternatively, cross-validation analysis can be performed on test data from development boards running the same firmware version but with different hardware versions based on the hardware version information to determine whether the situation is related to a specific hardware version. An attribution report is generated based on the judgment results, and the attribution report is sent to relevant personnel.

[0061] It is understood that this embodiment proposes a change tracing and automatic attribution mechanism, which is a solution to the core problem in the prior art that "it is difficult to trace the fault to the specific change in high-frequency iteration scenarios".

[0062] This invention upgrades the testing system from a "problem finder" to a "problem attributor." Specifically, at the initialization of each test task, the system automatically injects and records precise version fingerprints, including software version identification information and hardware version information. This metadata is bound to the test ID, serving as proof of origin for all subsequent test data.

[0063] The software version identification information is obtained and recorded by calling the version control system (such as Git) API to obtain and record the precise Git commit hash, branch name, and build timestamp of the firmware or system under test. The hardware version information is recorded by scanning the onboard EEPROM or querying from the asset management system, including the PCB version number, the production batch number of the main IC (such as RK3588), and the serial number of key components.

[0064] When the monitoring system detects a new stability issue (such as the first occurrence of a crash type, or a significant increase in the failure rate of a certain indicator), the attribution engine is activated: the engine searches the database, locates the test record when the failure mode first appeared, and extracts the corresponding software submission hash A and hardware version information X.

[0065] After the attribution engine completes its search and location, it automatically generates a report that includes: a description of the fault, related test data, suspected issue submissions (with submitter and change summary link), and the range of affected hardware versions. The report is automatically sent to relevant developers and hardware engineers via email or collaboration tools.

[0066] As can be seen, this invention achieves full automation of the core automated test scenario design: from pressure application and monitoring to analysis, no manual monitoring is required throughout the entire process. By combining hardware signals (JTAG / power supply) and software logs, the problem is located at the driver / circuit level, enabling the distributed monitoring system in the test environment architecture design to achieve precise positioning. This realizes a complete automated test process with fully automated and precise positioning, forming a closed-loop test system through the integration of hardware and software. In another implementation, an anomaly analysis center and case library can be additionally built on top of this invention to continuously iterate and improve the robustness of each development board under stress scenarios.

[0067] Furthermore, such as Figure 4 As shown, based on the above-described automated stability testing method for development boards, the present invention also provides an automated stability testing system for development boards, wherein the automated stability testing system for development boards includes: The pressure coupling and application module 51 is used to synchronously apply dynamically changing CPU load, ambient temperature gradient and various bus pressures to the development board under test in an automated testing environment, so as to obtain the development board under multi-factor coupling. The software and hardware collaborative monitoring module 52 is used to collect and associate the software logs and hardware signals of the development board in real time through a distributed monitoring system consisting of a host computer control terminal, a board-side agent module, and hardware debugging and monitoring equipment, and to monitor the status of the development board based on the software logs and hardware signals. The fault recovery and storage module 53 is used to automatically trigger the recovery mechanism when the development board is detected to have a fault or no response, to save the system site information containing the software logs and hardware signals and to restart the test process. The intelligent prediction and optimization module 54 is used to dynamically adjust test parameters based on the system's on-site information and historical test data through a prediction algorithm, and to automatically execute the entire process from pressure application and system monitoring to fault analysis and recovery.

[0068] Furthermore, such as Figure 5 As shown, based on the above-mentioned automated stability testing method and system for development boards, the present invention also provides a terminal, which includes a processor 10, a memory 20 and a display 30. Figure 5 Only some of the terminal components are shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0069] In some embodiments, the memory 20 may be an internal storage unit of the terminal, such as a hard disk or memory. In other embodiments, the memory 20 may be an external storage device of the terminal, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc. Further, the memory 20 may include both internal and external storage devices. The memory 20 is used to store application software and various types of data installed on the terminal, such as the program code installed on the terminal. The memory 20 can also be used to temporarily store data that has been output or will be output. In one embodiment, the memory 20 stores a development board automated stability test program 40, which can be executed by the processor 10 to implement the development board automated stability test method of this application.

[0070] In some embodiments, the processor 10 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in the memory 20 or process data, such as executing the development board automated stability testing method.

[0071] In some embodiments, the display 30 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. The display 30 is used to display information on the terminal and to display a visual user interface. The components of the terminal communicate with each other via a system bus.

[0072] In one embodiment, when the processor 10 executes the development board automated stability test program 40 in the memory 20, the following steps are performed: In an automated testing environment, dynamically changing CPU loads, ambient temperature gradients, and various bus pressures are synchronously applied to the development board under test, resulting in a development board under the coupling of multiple factors. A distributed monitoring system consisting of a host computer control terminal, a board-side agent module, and hardware debugging and monitoring equipment is used to collect and correlate the software logs and hardware signals of the development board in real time, and to monitor the status of the development board based on the software logs and hardware signals. When the development board is detected to be malfunctioning or unresponsive, the recovery mechanism is automatically triggered to save the system's on-site information, including the software logs and hardware signals, and restart the testing process. Based on the system's on-site information and historical test data, the test parameters are dynamically adjusted through a predictive algorithm, and the entire process from pressure application and system monitoring to fault analysis and recovery is automatically executed.

[0073] Specifically, the process of synchronously applying dynamically changing CPU load, ambient temperature gradient, and various bus pressures to the development board under test to obtain a development board under multi-factor coupling includes: Using a load generation tool, the CPU utilization of the development board under test is dynamically adjusted according to a preset sine wave or square wave pattern. The test board is placed in a temperature chamber to achieve a gradient change in ambient temperature between a preset low temperature value and a preset high temperature value. Apply continuous or periodic stress loads to at least two of the memory, network interface, USB interface, CAN bus, and GPU of the development board under test.

[0074] The hardware signals include: kernel stack information and memory dump data obtained through the JTAG debugging interface when the system crashes, and power supply current ripple monitored by the programmable power supply.

[0075] Specifically, when a malfunction or unresponsiveness is detected on the development board, an automatic recovery mechanism is triggered to save system state information containing the software logs and hardware signals and restart the testing process. This includes: When the development board is detected to be faulty or unresponsive, the system's on-site information is captured and saved by the hardware debugging and monitoring equipment. The development board is restarted by performing a hard reset operation on the development board using the hardware debugging and monitoring equipment. After the development board restarts, the host computer control terminal automatically reloads the test cases to the development board and triggers their execution to continue the testing process.

[0076] Specifically, the step of dynamically adjusting test parameters based on the system's on-site information and historical test data using a prediction algorithm includes: Collect and organize the system's on-site information and historical test data to obtain organized data. Construct a training dataset based on the organized data and train a machine learning model based on the training dataset to obtain a trained machine learning model. During the test execution, the software logs and real-time monitoring data of the hardware signals are input into the trained machine learning model to obtain the system risk level; Based on the system risk level, at least one parameter among the following in subsequent tests—the CPU load application mode, the rate of change of the temperature gradient, or the load intensity of the bus pressure—is dynamically adjusted.

[0077] The automated execution of the entire process, from pressure application and system monitoring to fault analysis and recovery, specifically includes: Based on a preset test plan, the host computer control terminal schedules and coordinates the pressure application module, the board-side agent module, and the hardware debugging and monitoring equipment to sequentially trigger and collaboratively execute pressure application operations, system monitoring operations, and fault recovery operations. The pressure application parameters recorded during the pressure application operation, the monitoring data collected during the system monitoring operation, and the system field information saved during the fault recovery operation are stored in a unified database in real time. Fault analysis is performed based on the data stored in the unified database, and the analysis results are fed back into the prediction algorithm to form a closed-loop control process for dynamic adjustment of test parameters.

[0078] The automated stability testing method for the development board also includes: Before starting the automated testing process on the development board, record the firmware version identification information loaded on the development board and the hardware version information of the development board; When the development board is detected to be malfunctioning or unresponsive, a binary search algorithm is automatically executed based on the recorded version identification information to determine whether the situation is related to a specific software code submission. Alternatively, cross-validation analysis can be performed on test data from development boards running the same firmware version but with different hardware versions based on the hardware version information to determine whether the situation is related to a specific hardware version. An attribution report is generated based on the judgment results, and the attribution report is sent to relevant personnel.

[0079] The present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores an automated stability testing program for a development board, and the automated stability testing program for the development board, when executed by a processor, implements the steps of the automated stability testing method for the development board as described above.

[0080] In summary, this invention provides an automated stability testing method, system, terminal, and storage medium for development boards. The method includes: in an automated testing environment, synchronously applying dynamically changing CPU load, ambient temperature gradient, and various bus pressures to the development board under test, resulting in a development board under multi-factor coupling; through a distributed monitoring system consisting of a host computer control terminal, a board-side agent module, and hardware debugging and monitoring equipment, real-time collecting and correlating the software logs and hardware signals of the development board, and monitoring the status of the development board based on the software logs and hardware signals; when a fault or unresponsiveness is detected in the development board, an automatic recovery mechanism is triggered, saving system site information containing the software logs and hardware signals and restarting the testing process; based on the system site information and historical test data, test parameters are dynamically adjusted through a predictive algorithm, and the entire process from pressure application and system monitoring to fault analysis and recovery is automatically executed. This invention achieves a fully automated and precisely positioned complete automated testing process, with software and hardware combined to form a closed-loop testing system.

[0081] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes that element.

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

[0083] It should be understood that the application of the present invention is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. An automated stability testing method for development boards, characterized in that, The automated stability testing method for the development board includes: In an automated testing environment, dynamically changing CPU loads, ambient temperature gradients, and various bus pressures are synchronously applied to the development board under test, resulting in a development board under the coupling of multiple factors. A distributed monitoring system consisting of a host computer control terminal, a board-side agent module, and hardware debugging and monitoring equipment is used to collect and correlate the software logs and hardware signals of the development board in real time, and to monitor the status of the development board based on the software logs and hardware signals. When the development board is detected to be malfunctioning or unresponsive, the recovery mechanism is automatically triggered to save the system's on-site information, including the software logs and hardware signals, and restart the testing process. Based on the system's on-site information and historical test data, the test parameters are dynamically adjusted through a predictive algorithm, and the entire process from pressure application and system monitoring to fault analysis and recovery is automatically executed.

2. The automated stability testing method for development boards according to claim 1, characterized in that, The process of synchronously applying dynamically changing CPU load, ambient temperature gradient, and various bus pressures to the development board under test results in a development board under multi-factor coupling, specifically including: Using a load generation tool, the CPU utilization of the development board under test is dynamically adjusted according to a preset sine wave or square wave pattern. The test board is placed in a temperature chamber to achieve a gradient change in ambient temperature between a preset low temperature value and a preset high temperature value. Apply continuous or periodic stress loads to at least two of the memory, network interface, USB interface, CAN bus, and GPU of the development board under test.

3. The automated stability testing method for development boards according to claim 1, characterized in that, The hardware signals include: kernel stack information and memory dump data obtained through the JTAG debugging interface at the time of system crash, and power supply current ripple monitored by the programmable power supply.

4. The automated stability testing method for development boards according to claim 1, characterized in that, When a malfunction or unresponsiveness is detected on the development board, a recovery mechanism is automatically triggered to save system state information, including software logs and hardware signals, and restart the testing process. Specifically, this includes: When the development board is detected to be faulty or unresponsive, the system's on-site information is captured and saved by the hardware debugging and monitoring equipment. The development board is restarted by performing a hard reset operation on the development board using the hardware debugging and monitoring equipment. After the development board restarts, the host computer control terminal automatically reloads the test cases to the development board and triggers their execution to continue the testing process.

5. The automated stability testing method for development boards according to claim 1, characterized in that, The step of dynamically adjusting test parameters based on the system's on-site information and historical test data using a prediction algorithm specifically includes: Collect and organize the system's on-site information and historical test data to obtain organized data. Construct a training dataset based on the organized data and train a machine learning model based on the training dataset to obtain a trained machine learning model. During the test execution, the software logs and real-time monitoring data of the hardware signals are input into the trained machine learning model to obtain the system risk level; Based on the system risk level, dynamically adjust at least one parameter among the following in subsequent tests: the CPU load application mode, the rate of change of the temperature gradient, or the load intensity of the bus pressure.

6. The automated stability testing method for development boards according to claim 1, characterized in that, The automated execution encompasses the entire process from stress application and system monitoring to fault analysis and recovery, specifically including: Based on a preset test plan, the host computer control terminal schedules and coordinates the pressure application module, the board-side agent module, and the hardware debugging and monitoring equipment to sequentially trigger and collaboratively execute pressure application operations, system monitoring operations, and fault recovery operations. The pressure application parameters recorded during the pressure application operation, the monitoring data collected during the system monitoring operation, and the system field information saved during the fault recovery operation are stored in a unified database in real time. Fault analysis is performed based on the data stored in the unified database, and the analysis results are fed back into the prediction algorithm to form a closed-loop control process for dynamic adjustment of test parameters.

7. The automated stability testing method for development boards according to claim 1, characterized in that, The automated stability testing method for the development board also includes: Before starting the automated testing process on the development board, record the firmware version identification information loaded on the development board and the hardware version information of the development board; When the development board is detected to be malfunctioning or unresponsive, a binary search algorithm is automatically executed based on the recorded version identification information to determine whether the situation is related to a specific software code submission. Alternatively, cross-validation analysis can be performed on test data from development boards running the same firmware version but with different hardware versions based on the hardware version information to determine whether the situation is related to a specific hardware version. An attribution report is generated based on the judgment results, and the attribution report is sent to relevant personnel.

8. An automated stability testing system for development boards, characterized in that, The automated stability testing system for the development board includes: The pressure coupling and application module is used to synchronously apply dynamically changing CPU load, ambient temperature gradient and various bus pressures to the development board under test in an automated testing environment, so as to obtain the development board under multi-factor coupling. The software and hardware collaborative monitoring module is used to collect and associate the software logs and hardware signals of the development board in real time through a distributed monitoring system consisting of a host computer control terminal, a board-side agent module, and hardware debugging and monitoring equipment, and to monitor the status of the development board based on the software logs and hardware signals. The fault recovery and saving module is used to automatically trigger the recovery mechanism when the development board is detected to have a fault or no response, save the system site information including the software logs and hardware signals, and restart the test process; The intelligent prediction and optimization module is used to dynamically adjust test parameters based on the system's on-site information and historical test data through prediction algorithms, and to automatically execute the entire process from pressure application and system monitoring to fault analysis and recovery.

9. A terminal, characterized in that, The terminal includes: a memory, a processor, and an automated stability testing program for the development board stored in the memory and executable on the processor. When the automated stability testing program for the development board is executed by the processor, it implements the steps of the automated stability testing method for the development board as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an automated stability testing program for the development board, which, when executed by a processor, implements the steps of the automated stability testing method for the development board as described in any one of claims 1-7.

Images