Method for testing functionality and stability of core board service component

Abstract

The invention relates to the technical field of embedded system testing, in particular to a method for testing functionality and stability of a core board service component, which comprises the following steps of: initializing a core board testing environment, ensuring that software and hardware parameters are consistent in a testing process, and aiming at the service component on a core board, testing the service component on the core board; the method comprises the following steps of: analyzing and generating a dependency relationship graph among components by utilizing a dependency graph model, optimizing a key dependency relationship through a deep learning model, performing functional testing on the components according to a priority based on the optimized dependency relationship graph, and testing the stability of a core board during high-concurrency and multi-task operation through multi-thread scheduling and concurrent task simulation. Abnormal, resource competition and deadlock problems are detected; and finally, in combination with an actual application scene, carrying out component hot plug, network abnormity, power-off recovery and other scene tests, and analyzing test data to generate a comprehensive test report. According to the method, the test coverage rate and efficiency are improved, and stable operation of the system under complex conditions is ensured.

Description

Technical Field

[0001] The present invention relates to the technical field of embedded system testing, and particularly to a method for testing the functionality and stability of core board service components. Background Art

[0002] With the development of embedded systems and intelligent devices, the core board, as the central control unit of the system, undertakes key processing and coordination tasks. Service components on the core board, such as processor management, memory management, device drivers, and network communication components, must operate reliably in complex and changing application scenarios. Therefore, the testing of functionality and stability has become an important link to ensure the overall reliability of the system. To ensure the normal operation of the core board in actual applications, comprehensive functionality and stability testing are required during the development stage. Especially in the case of multi-task concurrency, high load, and complex scenarios, the test coverage and effectiveness are particularly important.

[0003] In the prior art, although partial testing has been carried out on the functionality and stability of the core board, there are still the following main problems: First, the dependency relationships between service components are complex, and traditional testing methods cannot fully identify and optimize the key dependencies between components, resulting in incomplete test coverage and inability to accurately reflect the true operating conditions of the system. Second, in a high-concurrency and complex environment, the existing testing methods have limited capabilities in handling multi-thread scheduling, memory usage, and resource contention, and it is difficult to effectively detect and prevent abnormal situations such as deadlocks, memory leaks, and resource contention. In addition, the testing in complex scenarios (such as network anomalies, power-off recovery, etc.) is insufficient, resulting in the difficulty of ensuring the stability and reliability of the system under extreme conditions. Summary of the Invention

[0004] The present invention provides a method for testing the functionality and stability of core board service components.

[0005] The method for testing the functionality and stability of core board service components includes the following steps:

[0006] S1, Initialize the core board test environment: By loading the firmware and configuration files of the core board, establish a standardized test environment, and complete the initialization of the test environment using an automated test platform;

[0007] S2, Component dependency analysis: For the dependency relationships between different service components on the core board, adopt an analysis algorithm based on a dependency graph model to generate a dependency relationship graph between service components, and label and optimize the key dependency relationships through a deep learning model;

[0008] S3, Functional testing: Based on the dependency graph, activate each service component on the core board step by step in the order of dependency priority, and conduct functional tests on the components in turn. The test contents include the startup response time, task processing ability, and interface response of the components. During the test process, by setting three different load conditions of low, medium, and high, monitor and record the performance of the components at each load level;

[0009] S4, Stability testing: By introducing multithreaded scheduling and concurrent task simulation, examine the stability of the core board during high-concurrency and multi-task operation. The test contents include the monitoring of the running status of service components, exception capture, detection of resource competition and deadlock problems, and real-time tracking of the memory usage of components in combination with a dynamic memory analysis tool. When an exception is detected, record and execute the corresponding error handling mechanism;

[0010] S5, Scenario testing: Combine the actual application scenarios and design multiple complex scenario test cases. The multiple complex scenarios include component hot plugging, network anomalies, and power failure recovery, and analyze the behavior of service components under multiple complex scenarios;

[0011] S6, Test data analysis and feedback: Collect and analyze the data during all test processes, and generate a comprehensive functional and stability test report. The report contents include the functional performance of components, stability indicators, records of abnormal behaviors, and the impact of their dependencies.

[0012] Optionally, the S1 specifically includes:

[0013] S11, Firmware loading: Load the firmware program of the core board, and verify the integrity and version consistency of the firmware;

[0014] S12, Configuration file import: Import the hardware and software configuration files of the core board. The configuration contents include hardware resource allocation, communication interface configuration, and clock setting;

[0015] S13, Standardized test environment setup: Complete the initialization of the test environment of the core board through an automated test platform, including the connection of test equipment, the setting of simulators, and the configuration of data acquisition systems;

[0016] S14, Environment parameter verification: Verify the established test environment and verify whether the data transmission and communication between modules are normal.

[0017] Optionally, the S2 specifically includes:

[0018] S21, Dependency graph model generation: Analyze the dependency relationships of each service component on the core board through a dependency graph analysis algorithm, and generate a dependency graph between service components;

[0019] S22, Key Dependency Relationship Annotation: Use a deep learning model to annotate the key dependency relationships in the generated dependency graph. The deep learning model is trained through supervised learning, and based on previous data, the dependency weights are trained to optimize the dependency graph;

[0020] S23, Dependency Relationship Optimization: Optimize the key dependencies in the dependency graph through an optimization algorithm;

[0021] S24, Dependency Priority Sorting: Generate the dependency priority sorting of service components according to the optimized dependency weights.

[0022] Optionally, the specific steps of S3 include:

[0023] S31, Service Component Activation: Gradually activate each service component on the core board in the order of dependency priority;

[0024] S32, Startup Response Time Test: Record the startup response time required for each service component to fully run from activation;

[0025] S33, Task Processing Capacity Test: Under different load conditions, test the task processing capacity of the components. The test method includes setting three load conditions (low, medium, high) and calculating the task completion time of the components under each load respectively;

[0026] S34, Interface Response Test: Detect the response time and correctness of the component interfaces, and record the success rate and error rate of interface calls.

[0027] Optionally, the specific steps of S4 include:

[0028] S41, Concurrent Task Simulation: Simulate the high-concurrency running environment of the core board through multi-threaded scheduling to test the running stability of the components under multi-task concurrency;

[0029] S42, Exception Capture: Use an exception monitoring tool to capture the exception events of the components in real time under high-concurrency conditions. The exception events include deadlocks, resource contention, and memory leaks;

[0030] S43, Resource Contention Detection: Use a resource contention detection algorithm to analyze the resource contention situation of each thread, and detect whether there is a performance degradation or deadlock caused by resource contention;

[0031] S44, Memory Usage Monitoring: Combine a dynamic memory analysis tool to monitor the memory usage of the components in real time, and detect memory leaks and unreasonable memory occupancy.

[0032] Optionally, the specific steps of S5 include:

[0033] S51, Scenario-based Test Case Design: Design test cases for multiple complex scenarios according to the actual application scenarios. The test scenarios include component hot plugging, network anomalies, and power failure recovery;

[0034] S52, Component Hot Plugging Test: During the system operation, simulate the hot plugging operation of components and monitor whether the core board can handle the hot plugging event without affecting the operation of other components;

[0035] S53, Network Anomaly Test: Simulate network anomaly situations (such as network disconnection, network jitter), and record the reconnection time and recovery status of the core board service components after the network is restored;

[0036] S54, Power Failure Recovery Test: Simulate the scenario of sudden power failure, detect the startup situation of each service component on the core board after power failure recovery, and record the recovery time and data consistency.

[0037] Optionally, the S6 specifically includes:

[0038] S61, Test Data Collection: Collect data in each test step through an automated test platform. The data types include response time, task processing time, memory usage, and exception logs;

[0039] S62, Data Analysis: Analyze the collected test data to generate functional and stability indicators of components. Use statistical methods to perform regression analysis on the data to identify performance bottlenecks;

[0040] S63, Abnormal Behavior Analysis: Classify and analyze the abnormal behavior records, determine the causes of the anomalies and their impacts on component dependencies, and provide corresponding improvement suggestions;

[0041] S64, Report Generation: Generate a comprehensive test report based on the analysis results. The report content includes the functional performance of components, stability indicators, and the impacts of dependencies on the test results.

[0042] Optionally, the generation of the dependency graph model specifically includes:

[0043] Data Input: Collect the dependency data between service components and input it into a deep learning model. The dependency data includes interface calls, data streams, and resource sharing;

[0044] Model Training: Use a multi-layer perceptron model for training. The model formula is expressed as:

[0045] y = σ(Wx + b);

[0046] Among them, x is the input dependency feature vector, W is the weight matrix, B is the bias, σ is the activation function, and y is the output dependency weight;

[0047] Dependency graph generation: A dependency graph is generated based on the calculated dependency weights to represent the dependency relationships among service components.

[0048] Optionally, the memory usage monitoring in S44 further includes:

[0049] S441, Memory allocation monitoring: Monitor the memory allocation of service components through a dynamic memory analysis tool to detect whether there is memory leakage or memory fragmentation;

[0050] S442, Memory leakage detection formula: The memory leakage rate is calculated as:

[0051]

[0052] where L mem is the memory leakage rate, M allocated is the total allocated memory, and M freed is the released memory.

[0053] Optionally, in S41, a high-concurrency running environment of the core board is simulated through multi-threaded scheduling, and a multi-threaded scheduling algorithm is adopted, specifically including:

[0054] S411, Thread priority scheduling: Assign priorities to each thread to ensure that high-priority tasks can obtain processing resources first;

[0055] S412, Thread competition management: Use a resource competition manager to detect resource contention among threads and avoid deadlocks;

[0056] S413, Deadlock detection formula: Deadlock detection is calculated as:

[0057]

[0058] where D lock is the deadlock probability, P i is the priority of the i-th thread, and R i is the resource occupancy.

[0059] Advantages of the present invention:

[0060] In the present invention, by generating a dependency relationship graph among service components and using a deep learning model to label and optimize key dependency relationships, key components are ensured to be covered mainly during subsequent testing. The setting of the dependency priority order improves the testing efficiency and avoids waste of invalid resources. This process can effectively identify interface calls, data flows, resource sharing, and task scheduling dependencies among components, reduce potential conflicts during system operation, ensure the collaborative work of each component, and improve the reliability and resource utilization efficiency of the overall system.

[0061] In this invention, through functional and stability testing of service components, combined with multi-threaded scheduling and concurrent task simulation, the stable operation of the core board under various load conditions is ensured. Specifically, it includes monitoring the startup response time, task processing ability, and interface response time to ensure the functional performance of each component. In addition, through scenario-based testing to simulate complex scenarios in actual applications, such as component hot plugging, network anomalies, and power failure recovery, the anti-pressure ability and recovery ability of the system under extreme conditions are verified, further enhancing the robustness and reliability of the system.

[0062] In this invention, by collecting and analyzing various types of data during the testing process in real time, including memory usage, thread scheduling, and exception capture, a detailed test report is generated and intelligent feedback is provided. By detecting and handling memory leak, resource competition, and deadlock problems, the performance degradation that may occur during long-term operation of the system is effectively prevented. At the same time, relying on the iterative optimization of the deep learning model, the system can continuously improve the dependency graph, achieve reasonable resource allocation and efficient task scheduling, thereby significantly enhancing the long-term stability and performance of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] In order to more clearly illustrate the technical solutions in this invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings described below are only those of this invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0064] Figure 1 It is a schematic flowchart of the method according to an embodiment of this invention;

[0065] Figure 2 It is a schematic flowchart of the S4 process according to an embodiment of this invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0066] The following will describe this invention in detail in combination with the drawings and specific embodiments. At the same time, it should be noted here that in order to make the embodiments more detailed, the following embodiments are the best and preferred embodiments. For some well-known technologies, those skilled in the art can also adopt other alternative methods for implementation; and the drawing part is only for more specifically describing the embodiments, and is not intended to specifically limit this invention.

[0067] It should be noted that in the specification, the mention of "an embodiment", "embodiments", "exemplary embodiments", "some embodiments", etc. indicates that the described embodiments may include specific features, structures, or characteristics, but not necessarily every embodiment includes such specific features, structures, or characteristics. Additionally, when describing a specific feature, structure, or characteristic in combination with an embodiment, implementing such a feature, structure, or characteristic in combination with other embodiments (whether explicitly described or not) should be within the knowledge of those skilled in the relevant art.

[0068] Generally, terms can be understood at least in part from their use in context. For example, at least in part depending on the context, the term "one or more" as used herein can be used to describe any feature, structure, or characteristic in a singular sense, or can be used to describe a combination of features, structures, or characteristics in a plural sense. Additionally, the term "based on" can be understood as not necessarily intended to convey a set of exclusive factors, but rather can alternatively, at least in part depending on the context, allow for the existence of other factors that may not be explicitly described.

[0069] As Figure 1 - Figure 2 shown, a method for testing the functionality and stability of a core board service component includes the following steps:

[0070] S1, Initialize the core board test environment: By loading the firmware and configuration files of the core board, establish a standardized test environment to ensure the consistency of software and hardware parameters during the test, and use an automated test platform to complete the initialization of the test environment;

[0071] S2, Component dependency analysis: For the dependency relationships between different service components on the core board, use an analysis algorithm based on a dependency graph model to generate a dependency relationship graph between service components, and use a deep learning model to label and optimize the key dependency relationships. The dependency relationship graph will be used to determine priorities in subsequent tests to ensure that the functionality and stability tests can focus on covering the collaborative work situation between components. The key dependency relationships include interface call dependencies, data flow dependencies, resource sharing dependencies, and task scheduling dependencies;

[0072] S3, Functionality testing: Based on the dependency relationship graph, gradually activate each service component on the core board in the order of dependency priority, and sequentially perform functionality tests on the components. The test content includes the startup response time, task processing ability, and interface response of the components. During the test, by setting three different load conditions of low, medium, and high, monitor and record the performance of the components at each load level. Each service component includes a processor management component (such as a task scheduler, interrupt handling component), a memory management component (such as a memory allocator, memory allocator), a device driver component (such as an input / output driver, communication interface component), and a network communication component (such as a network protocol stack component, wireless communication component);

[0073] S4, Stability Test: By introducing multi-threaded scheduling and concurrent task simulation, the stability of the core board during high-concurrency and multi-task operation is investigated. The test content includes monitoring the running status of service components, capturing exceptions, detecting resource competition and deadlock issues, and combining with a dynamic memory analysis tool to track the memory usage of components in real time. When an exception is detected, the corresponding error handling mechanism is recorded and executed;

[0074] S5, Scenario-based Test: Combining with actual application scenarios, various complex scenario test cases are designed. The various complex scenarios include component hot plugging, network anomalies, and power-off recovery. Analyze the behavior of service components under various complex scenarios to ensure that they can maintain stable operation in extreme environments;

[0075] S6, Test Data Analysis and Feedback: Collect and analyze the data during all test processes, and generate a comprehensive functional and stability test report. The report content includes the functional performance of components, stability indicators, records of abnormal behaviors, and the impact of their dependencies.

[0076] S1 specifically includes:

[0077] S11, Firmware Loading: Load the firmware program of the core board, and verify the integrity and version consistency of the firmware to ensure the compatibility between the core board firmware and the test platform;

[0078] S12, Configuration File Import: Import the hardware and software configuration files of the core board. The configuration content includes hardware resource allocation, communication interface configuration, and clock setting to ensure that all software and hardware parameters are consistent with the actual test requirements;

[0079] S13, Standardized Test Environment Setup: Complete the initialization of the test environment for the core board through an automated test platform, including the connection of test devices, the setting of simulators, and the configuration of data acquisition systems;

[0080] S14, Environment Parameter Verification: Verify the established test environment, and verify whether the data transmission and communication between each module (each module refers to the software and hardware modules involved in the core board test environment, including the processor management module, memory management module, device driver module, and network communication module) are normal to ensure that the software and hardware parameters in the test environment remain consistent throughout the test process;

[0081] Through firmware loading, configuration file import, test environment setup, and environment parameter verification, the consistency and reliability during the test process are ensured, and the impact of environmental differences on test results is avoided.

[0082] S2 specifically includes:

[0083] S21, Dependency Graph Model Generation: Perform dependency analysis on each service component on the core board through a dependency graph analysis algorithm to generate a dependency graph among service components;

[0084] S22, Critical Dependency Relationship Annotation: Use a deep learning model to annotate the critical dependency relationships in the generated dependency graph. The deep learning model is trained through supervised learning, and based on previous data, it trains the dependency weights to optimize the dependency graph;

[0085] S23, Dependency Relationship Optimization: Optimize the critical dependencies in the dependency graph through an optimization algorithm. The optimization formula is expressed as:

[0086]

[0087] where, W opt is the optimized dependency weight, w i is the initial weight of each dependency relationship, d i is the dependency spacing, and f(d i ) is the dependency distance function;

[0088] S24, Dependency Priority Sorting: Generate a dependency priority sorting of service components according to the optimized dependency weights to ensure that components with high dependencies are preferentially tested in subsequent tests;

[0089] By generating a dependency graph, annotating critical dependencies, and performing optimization, it is ensured that the subsequent testing process focuses on covering the collaborative work between components, effectively improving the test coverage rate and efficiency.

[0090] S3 specifically includes:

[0091] S31, Service Component Activation: Gradually activate each service component on the core board in the order of dependency priority to ensure that each component starts in the correct order and avoid functional deficiencies caused by incorrect startup order;

[0092] S32, Startup Response Time Testing: Record the startup response time required for each service component to fully run from activation. Define the startup response time formula as:

[0093] T start = T end - T init ;

[0094] where, T start is the startup response time, T end is the time point when the component fully runs, and T init is the time point when the component is activated;

[0095] S33, Task Processing Ability Test: Under different load conditions, test the task processing ability of the component. The test method includes setting three load conditions (low, medium, and high) and calculating the task completion time of the component under each load respectively;

[0096] S34, Interface Response Test: Detect the response time and correctness of the component interface, record the success rate and error rate of interface calls, and ensure that the interface can respond stably when the load changes;

[0097] Through multi-faceted tests of startup response time, task processing ability, and interface response, ensure the functional performance of the component under various loads and verify the reliability of the component under different stress conditions.

[0098] S4 specifically includes:

[0099] S41, Concurrent Task Simulation: Simulate the high-concurrency operating environment of the core board through multi-threaded scheduling and test the operating stability of the component when multiple tasks are concurrent;

[0100] S42, Exception Capture: Use an exception monitoring tool to capture exception events of the component under high-concurrency conditions in real time. Exception events include deadlocks, resource contention, and memory leaks;

[0101] S43, Resource Contention Detection: Use a resource contention detection algorithm to analyze the resource contention situation of each thread and detect whether there is a performance degradation or deadlock caused by resource contention. The detection formula is expressed as:

[0102]

[0103] Among them, R comp is the resource contention rate, R i is the resource occupancy of the i-th thread, and R t otal is the total resources of the system;

[0104] S44, Memory Usage Monitoring: Combine a dynamic memory analysis tool to monitor the memory usage of the component in real time and detect memory leaks and unreasonable memory occupancy;

[0105] Through concurrent task simulation, exception capture, and memory monitoring, ensure the stability of the core board under high-concurrency conditions, and discover and solve potential resource contention and memory problems in advance.

[0106] S5 specifically includes:

[0107] S51, Design of Scenario-based Test Cases: According to the actual application scenario, design test cases for multiple complex scenarios. The test scenarios include component hot plugging, network anomalies, and power failure recovery;

[0108] S52, Component Hot Plug Test: During system operation, simulate the hot plug operation of components and monitor whether the core board can handle hot plug events without affecting the operation of other components;

[0109] S53, Network Abnormality Test: Simulate network abnormality situations (such as network disconnection, network jitter), and record the reconnection time and recovery status of the core board service components after network recovery;

[0110] S54, Power-off Recovery Test: Simulate a sudden power-off scenario, detect the startup situation of each service component on the core board after power-off recovery, and record the recovery time and data consistency;

[0111] Through the testing of complex scenarios, the stability and reliability of the core board in extreme environments are verified, ensuring that the system can handle various unforeseen situations.

[0112] S6 specifically includes:

[0113] S61, Test Data Collection: Collect data in each test step through an automated test platform. The data types include response time, task processing time, memory usage, and exception logs;

[0114] S62, Data Analysis: Analyze the collected test data to generate functional and stability indicators of components. Use statistical methods to perform regression analysis on the data to identify performance bottlenecks;

[0115] S63, Abnormal Behavior Analysis: Classify and analyze the abnormal behavior records, determine the causes of abnormalities and their impacts on component dependencies, and provide corresponding improvement suggestions;

[0116] S64, Report Generation: Generate a comprehensive test report based on the analysis results. The report content includes the functional performance of components, stability indicators, and the impacts of dependencies on test results;

[0117] Through the comprehensive collection and analysis of test data, generating a detailed test report helps to optimize the functions and stability of service components subsequently.

[0118] The generation of the dependency graph model specifically includes:

[0119] Data Input: Collect dependency data between service components and input it into the deep learning model. The dependency data includes interface calls, data streams, and resource sharing;

[0120] Model Training: Use a multi-layer perceptron model for training. The model formula is expressed as:

[0121] y = σ(Wx + b);

[0122] Among them, x is the input-dependent feature vector, W is the weight matrix, b is the bias, σ is the activation function, and y is the output-dependent weight;

[0123] Dependency graph generation: Generate a dependency graph through the calculated dependency weights to represent the dependency relationships between service components;

[0124] The dependency graph generated by the deep learning model can accurately identify the key dependency relationships between service components, optimizing the coverage scope and order of testing.

[0125] The memory usage monitoring in S44 further includes:

[0126] S441, Memory allocation monitoring: Monitor the memory allocation of service components through a dynamic memory analysis tool to detect whether there is memory leakage or memory fragmentation;

[0127] S442, Memory leakage detection formula: The memory leakage rate is calculated as:

[0128]

[0129] Where L mem is the memory leakage rate, M allocated is the total allocated memory, and M freed is the released memory.

[0130] In S41, a high-concurrency operating environment of the core board is simulated through multi-threaded scheduling. The multi-threaded scheduling algorithm specifically includes:

[0131] S411, Thread priority scheduling: Assign priorities to each thread to ensure that high-priority tasks can obtain processing resources first;

[0132] S412, Thread competition management: Use a resource competition manager to detect resource contention between threads and avoid deadlocks;

[0133] S413, Deadlock detection formula: Deadlock detection is calculated as:

[0134]

[0135] Where D lock is the deadlock probability, P i is the priority of the i-th thread, and R i is the resource occupancy.

[0136] The present invention covers any alternatives, modifications, equivalent methods, and solutions that are within the spirit and scope of the present invention. To enable the public to have a thorough understanding of the present invention, specific details are described in detail in the following preferred embodiments of the present invention. However, those skilled in the art can fully understand the present invention even without the description of these details. Additionally, well-known methods, processes, procedures, components, and circuits are not described in detail to avoid unnecessary confusion to the essence of the present invention.

[0137] The above are only the preferred embodiments of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present invention.

Claims

1. A method for testing the functionality and stability of a core board service component, characterized in that, It includes the following steps: S1. Initialize the core board test environment: By loading the firmware and configuration files of the core board, establish a standardized test environment, and complete the initialization of the test environment using an automated test platform; S2. Component dependency analysis: For the dependency relationships between different service components on the core board, use an analysis algorithm based on a dependency graph model to generate a dependency relationship graph between service components, and label and optimize the key dependency relationships through a deep learning model; S3. Functional testing: Based on the dependency relationship graph, gradually activate each service component on the core board in the order of dependency priority, and conduct functional tests on the components in turn. The test contents include the startup response time, task processing ability, and interface response of the components. During the test process, by setting three different load conditions of low, medium, and high, monitor and record the performance of the components at each load level; S4. Stability testing: By introducing multi-threaded scheduling and concurrent task simulation, examine the stability of the core board during high-concurrency and multi-task operation. The test contents include monitoring the running state of service components, capturing exceptions, detecting resource competition and deadlock problems, and combining a dynamic memory analysis tool to track the memory usage of components in real time. When an exception is detected, record and execute the corresponding error handling mechanism; S5. Scenario-based testing: Combine the actual application scenarios to design multiple complex scenario test cases. The multiple complex scenarios include component hot plugging, network anomalies, and power failure recovery, and analyze the behavior of service components in multiple complex scenarios; S6. Test data analysis and feedback: Collect and analyze the data during all test processes, and generate a comprehensive functional and stability test report. The report contents include the functional performance of components, stability indicators, records of abnormal behaviors, and the impact of their dependency relationships.

2. The functional and stability testing method of the core board service component according to claim 1, characterized in that, The specific content of S1 includes: S11. Firmware loading: Load the firmware program of the core board, and verify the integrity and version consistency of the firmware; S12. Configuration file import: Import the hardware and software configuration files of the core board. The configuration contents include hardware resource allocation, communication interface configuration, and clock setting; S13. Standardized test environment construction: Complete the initialization of the test environment of the core board through an automated test platform, including the connection of test devices, the setting of simulators, and the configuration of data acquisition systems; S14. Environment parameter verification: Verify the established test environment to verify whether the data transmission and communication between modules are normal.

3. The functional and stability testing method for the core board service component according to claim 2, characterized in that The specific content of S2 includes: S21. Dependency graph model generation: Analyze the dependency relationships of each service component on the core board through a dependency graph analysis algorithm to generate a dependency relationship graph between service components; S22. Key dependency relationship annotation: Use a deep learning model to annotate the key dependency relationships in the generated dependency graph. The deep learning model is trained through supervised learning, and based on previous data, the dependency weights are trained to optimize the dependency relationship graph; S23. Dependency relationship optimization: Optimize the key dependencies in the dependency relationship graph through an optimization algorithm; S24. Dependency priority sorting: Generate the dependency priority sorting of service components according to the optimized dependency weights.

4. The functional and stability testing method for the core board service component according to claim 3, characterized in that The specific content of S3 includes: S31, Service Component Activation: Gradually activate each service component on the core board in the order of dependency priority; S32, Startup Response Time Test: Record the startup response time required for each service component to go from activation to full operation; S33, Task Processing Capacity Test: Under different load conditions, test the task processing capacity of the components. The test methods include setting three load conditions and calculating the task completion time of the components under each load respectively; S34, Interface Response Test: Detect the response time and correctness of the component interfaces, and record the success rate and error rate of interface calls.

5. The functional and stability testing method of the core board service component according to claim 4, characterized in that, The specific steps of S4 include: S41, Concurrent Task Simulation: Simulate the high-concurrency operating environment of the core board through multi-threaded scheduling to test the running stability of the components under multi-task concurrency; S42, Exception Capture: Use an exception monitoring tool to capture exception events of the components in real time under high-concurrency conditions. Exception events include deadlocks, resource contention, and memory leaks; S43, Resource Contention Detection: Use a resource contention detection algorithm to analyze the resource contention situation of each thread to detect whether there is performance degradation or deadlock caused by resource contention; S44, Memory Usage Monitoring: Combine a dynamic memory analysis tool to monitor the memory usage of the components in real time to detect memory leaks and unreasonable memory occupation.

6. The functional and stability test method for the core board service component according to claim 5, characterized in that The specific steps of S5 include: S51, Scenario-based Test Case Design: According to the actual application scenarios, design test cases for various complex scenarios. The test scenarios include component hot plugging, network anomalies, and power outage recovery; S52, Component Hot Plugging Test: During the system operation, simulate the hot plugging operation of the components and monitor whether the core board can handle the hot plugging events without affecting the operation of other components; S53, Network Anomaly Test: Simulate network anomaly situations and record the reconnection time and recovery status of the core board service components after the network is restored; S54, Power Outage Recovery Test: Simulate a sudden power outage scenario, detect the startup situation of each service component on the core board after the power outage recovery, and record the recovery time and data consistency.

7. The functional and stability testing method for the core board service component according to claim 6, characterized in that The specific steps of S6 include: S61, Test Data Collection: Collect data in each test step through an automated test platform. The data types include response time, task processing time, memory usage, and exception logs; S62, Data Analysis: Analyze the collected test data to generate functional and stability indicators of the components. Use statistical methods to perform regression analysis on the data to identify performance bottlenecks; S63, Abnormal Behavior Analysis: Classify and analyze the abnormal behavior records, determine the causes of the anomalies and their impacts on the component dependency relationships, and provide corresponding improvement suggestions; S64, Report Generation: Generate a comprehensive test report based on the analysis results. The report content includes the functional performance of the components, stability indicators, and the impacts of dependency relationships on the test results.

8. The functional and stability testing method for the core board service component according to claim 3, characterized in that The generation of the specific dependency graph model includes: Data Input: Collect the dependency data between service components and input it into the deep learning model. The dependency data includes interface calls, data streams, and resource sharing; Model Training: Use a multi-layer perceptron model for training. The model formula is expressed as: y = σ(Wx + b); Among them, x is the input-dependent feature vector, W is the weight matrix, b is the bias, σ is the activation function, and y is the output-dependent weight; Dependency graph generation: Generate a dependency graph through the calculated dependency weights to represent the dependency relationships between service components.

9. The functional and stability testing method for the core board service component according to claim 5, characterized in that The memory usage monitoring in S44 further includes: S441, Memory allocation monitoring: Monitor the memory allocation of service components through a dynamic memory analysis tool to detect whether there is memory leakage or memory fragmentation; S442, Memory leakage detection formula: The memory leakage rate is calculated as: Among them, L mem is the memory leak rate, M allocated is the total allocated memory, and M freed is the released memory.

10. The functional and stability test method for the core board service component according to claim 5, characterized in that In S41, a high-concurrency running environment of the core board is simulated through multithreaded scheduling, and a multithreaded scheduling algorithm is adopted, specifically including: S411, Thread priority scheduling: Assign priorities to each thread to ensure that high-priority tasks can obtain processing resources first; S412, Thread competition management: Use a resource competition manager to detect resource contention between threads to avoid deadlocks; S413, Deadlock detection formula: Deadlock detection is calculated as: Among them, D lock is the deadlock probability, P i is the priority of the i-th thread, R i is the resource occupancy.

Images