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 in particular to a method for testing the functionality and stability of a core board service component. Background Art

[0002] With the development of embedded systems and smart 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, functionality and stability testing has become an important part of ensuring the overall reliability of the system. In order to ensure the normal operation of the core board in actual applications, comprehensive functionality and stability testing is required during the development phase, especially in multi-task concurrency, high load, and complex scenarios. The coverage and effectiveness of the test are particularly important.

[0003] In the prior art, although the functionality and stability of the core board have been partially tested, there are still several major problems: First, the dependencies 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 failure to accurately reflect the actual operating conditions of the system. Secondly, in high-concurrency and complex environments, existing testing methods have limited processing capabilities for multi-threaded scheduling, memory usage, and resource competition, making it difficult to effectively detect and prevent abnormal situations such as deadlocks, memory leaks, and resource contention. In addition, insufficient testing in complex scenarios (such as network anomalies, power outage recovery, etc.) makes it difficult to ensure the stability and reliability of the system under extreme conditions. Summary of the invention

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

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

[0006] S1, initialize the core board test environment: establish a standardized test environment by loading the firmware and configuration files of the core board, and use the automated test platform to complete the initialization of the test environment;

[0007] S2, component dependency analysis: for the dependency relationships between different service components on the core board, an analysis algorithm based on the dependency graph model is used to generate a dependency graph between service components, and key dependencies are annotated and optimized through a deep learning model;

[0008] S3, functional test: based on the dependency graph, each service component on the core board is gradually activated in the order of dependency priority, and the components are functionally tested in turn. The test content includes the component's startup response time, task processing capability, and interface response. During the test, three different load conditions of low, medium, and high are set to monitor and record the performance of the components under each load level;

[0009] S4, stability test: by introducing multi-threaded scheduling and concurrent task simulation, the stability of the core board under high concurrency and multi-task operation is examined. The test content includes the running status monitoring, exception capture, resource competition and deadlock problem detection of service components, and the dynamic memory analysis tool is used to track the memory usage of components in real time. When an exception is detected, the corresponding error handling mechanism is recorded and executed;

[0010] S5, scenario-based testing: Combined with actual application scenarios, design test cases for a variety of complex scenarios, including component hot swapping, network anomalies, and power failure recovery, and analyze the behavior of service components in a variety of complex scenarios;

[0011] S6, test data analysis and feedback: Collect and analyze data from all test processes to generate a comprehensive functional and stability test report. The report content includes the component's functional performance, stability indicators, abnormal behavior records and the impact of its dependencies.

[0012] Optionally, the S1 specifically includes:

[0013] S11, firmware loading: loading the firmware program of the core board and verifying 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 content includes hardware resource allocation, communication interface configuration and clock setting;

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

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

[0017] Optionally, the S2 specifically includes:

[0018] S21, dependency graph model generation: the dependency relationship of each service component on the core board is analyzed by a dependency graph analysis algorithm to generate a dependency graph between the service components;

[0019] S22, key dependency annotation: annotating key dependencies in the generated dependency graph using a deep learning model, wherein the deep learning model is trained through supervised learning to train dependency weights based on previous data and optimize the dependency graph;

[0020] S23, dependency optimization: optimize the key dependencies in the dependency graph through optimization algorithms;

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

[0022] Optionally, the S3 specifically includes:

[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: records the startup response time required for each service component from activation to full operation;

[0025] S33, task processing capability test: testing the task processing capability of the component under different load conditions. The test method includes setting three load conditions (low, medium, and high) and calculating the task completion time of the component under each load;

[0026] S34, interface response test: detect the response time and correctness of the component interface, and record the success rate and error rate of the interface call.

[0027] Optionally, the S4 specifically includes:

[0028] S41, concurrent task simulation: simulate the high concurrent operation environment of the core board through multi-threaded scheduling, and test the running stability of components in multi-tasking concurrency;

[0029] S42, exception capture: Use exception monitoring tools to capture abnormal events of components under high concurrency conditions in real time. Abnormal events include deadlock, resource competition and memory leak;

[0030] S43, resource contention detection: using a resource contention detection algorithm to analyze the resource contention of each thread, and detecting whether there is performance degradation or deadlock caused by resource contention;

[0031] S44, memory usage monitoring: Combined with dynamic memory analysis tools, it monitors the memory usage of components in real time and detects memory leaks and unreasonable memory usage.

[0032] Optionally, the S5 specifically includes:

[0033] S51, scenario-based test case design: Design test cases for a variety of complex scenarios based on actual application scenarios, including component hot swapping, network anomalies, and power failure recovery;

[0034] S52, component hot-swap test: During system operation, simulate the hot-swap operation of components to monitor whether the core board can handle hot-swap events without affecting the operation of other components;

[0035] S53, network anomaly test: simulate network anomalies (such as network disconnection, network jitter), and record the reconnection time and recovery status of the core board service component after the network is restored;

[0036] S54, power failure recovery test: simulates a sudden power failure scenario, detects the startup status of each service component of the core board after power failure recovery, and records the recovery time and data consistency.

[0037] Optionally, the S6 specifically includes:

[0038] S61, test data collection: collect data in each test step through the 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 component functionality and stability indicators, use statistical methods to perform regression analysis on the data, and identify performance bottlenecks;

[0040] S63, Abnormal Behavior Analysis: Classify and analyze abnormal behavior records, determine the cause of the abnormality and its impact 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 component's functional performance, stability indicators, and the impact of dependencies on the test results.

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

[0043] Data input: collect dependency data between service components and input them into the deep learning model. Dependency data includes interface calls, data flows, and resource sharing.

[0044] Model training: Multilayer perceptron model is used 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: Generate a dependency graph based on the calculated dependency weights to represent the dependency relationships between 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 dynamic memory analysis tools to detect whether there is memory leak or memory fragmentation;

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

[0051]

[0052] Among them, L mem is the memory leak rate, M allocated is the total memory allocated, M freed The memory released.

[0053] Optionally, in S41, a high concurrent operation environment of the core board is simulated by multi-thread scheduling, and a multi-thread scheduling algorithm is adopted, which specifically includes:

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

[0055] S412, thread contention management: using a resource contention manager to detect resource contention between threads to avoid deadlock;

[0056] S413, deadlock detection formula: Deadlock detection calculation is:

[0057]

[0058] Among them, D lock is the deadlock probability, P i is the priority of the i-th thread, R i The resource usage.

[0059] Beneficial effects of the present invention:

[0060] The present invention generates a dependency graph between service components and uses a deep learning model to annotate and optimize key dependencies, thereby ensuring that key components are covered in the subsequent testing process. The setting of dependency priorities improves the efficiency of testing and avoids ineffective waste of resources. This process can effectively identify the interface calls, data flows, resource sharing, and task scheduling dependencies between components, reduce potential conflicts in system operation, ensure that each component works in coordination, and improve the reliability and resource utilization efficiency of the overall system.

[0061] The present invention ensures the stable operation of the core board under various load conditions by testing the functionality and stability of service components, combined with multi-threaded scheduling and concurrent task simulation. Specifically, it monitors the startup response time, task processing capability, and interface response time to ensure the functional performance of each component. In addition, scenario-based testing simulates complex scenarios in actual applications, such as component hot swapping, network anomalies, and power failure recovery, verifying the system's stress resistance and recovery capabilities under extreme conditions, further enhancing the system's robustness and reliability.

[0062] The present invention generates a detailed test report and provides intelligent feedback by real-time collection and analysis of various data during the test process, including memory usage, thread scheduling and exception capture. By detecting and processing memory leaks, resource competition and deadlock problems, the performance degradation of the system during long-term operation 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, realize the reasonable allocation of resources and the efficient scheduling of tasks, thereby significantly improving 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 the present invention or the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings in the following description are only for the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0064] Figure 1 A schematic diagram of a method flow of an embodiment of the present invention;

[0065] Figure 2 Schematic diagram of S4 process according to an embodiment of the present invention. DETAILED DESCRIPTION

[0066] The present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. At the same time, it is explained here that in order to make the embodiments more detailed, the following embodiments are the best and preferred embodiments, and those skilled in the art may also adopt other alternatives to implement some known technologies; and the accompanying drawings are only for more specific description of the embodiments, and are not intended to specifically limit the present invention.

[0067] It should be noted that the references to "one embodiment", "an embodiment", "an exemplary embodiment", "some embodiments" and the like in the specification indicate that the embodiments described may include specific features, structures or characteristics, but not every embodiment may include the specific features, structures or characteristics. In addition, when a specific feature, structure or characteristic is described in conjunction with an embodiment, it should be within the knowledge of a person skilled in the art to implement such feature, structure or characteristic in conjunction with other embodiments (whether or not explicitly described).

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

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

[0070] S1, Initialize the core board test environment: Establish a standardized test environment by loading the core board's firmware and configuration files, 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 dependencies between different service components on the core board, an analysis algorithm based on the dependency graph model is used to generate a dependency graph between service components, and key dependencies are annotated and optimized through a deep learning model. The dependency graph will be used to determine priorities in subsequent tests to ensure that functional and stability tests can focus on the collaborative work between components. Key dependencies include interface call dependency, data flow dependency, resource sharing dependency, and task scheduling dependency.

[0072] S3, functional test: based on the dependency graph, each service component on the core board is gradually activated in the order of dependency priority, and the components are functionally tested in turn. The test content includes the startup response time, task processing capability and interface response of the components. During the test, three different load conditions of low, medium and high are set to monitor and record the performance of the components under each load level. Each service component includes a processor management component (such as a task scheduler and an interrupt processing component), a memory management component (such as a memory allocator and a memory distributor), a device driver component (such as an input and output driver and a communication interface component) and a network communication component (such as a network protocol stack component and a wireless communication component);

[0073] S4, stability test: by introducing multi-threaded scheduling and concurrent task simulation, the stability of the core board under high concurrency and multi-task operation is examined. The test content includes the running status monitoring, exception capture, resource competition and deadlock problem detection of service components, and the dynamic memory analysis tool is used 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 testing: Combined with actual application scenarios, we design a variety of complex scenario test cases, including component hot swapping, network anomalies, and power failure recovery. We analyze the behavior of service components in a variety of complex scenarios to ensure that they can maintain stable operation even in extreme environments.

[0075] S6, test data analysis and feedback: Collect and analyze data from all test processes to generate a comprehensive functional and stability test report. The report content includes the component's functional performance, stability indicators, abnormal behavior records and the impact of its dependencies.

[0076] S1 specifically includes:

[0077] S11, firmware loading: loading the firmware program of the core board and verifying the integrity and version consistency of the firmware to ensure the compatibility of the core board firmware with 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 construction: Complete the test environment initialization of the core board through the automated test platform, including the connection of test equipment, the setting of simulators, and the configuration of data acquisition systems;

[0080] S14, environmental parameter verification: verify the built test environment to verify whether the data transmission and communication between modules (modules refer to the software and hardware modules involved in the core board test environment, including processor management module, memory management module, device driver module and network communication module) are normal, and ensure that the software and hardware parameters in the test environment remain consistent throughout the test process;

[0081] By loading firmware, importing configuration files, setting up the test environment, and verifying environmental parameters, we ensure consistency and reliability during the test process, thus avoiding the impact of environmental differences on test results.

[0082] S2 specifically includes:

[0083] S21, dependency graph model generation: the dependency relationship of each service component on the core board is analyzed by a dependency graph analysis algorithm to generate a dependency graph between the service components;

[0084] S22, key dependency annotation: The key dependencies in the generated dependency graph are annotated using a deep learning model. The deep learning model is trained through supervised learning, and dependency weights are trained based on previous data to optimize the dependency graph.

[0085] S23, dependency optimization: The key dependencies in the dependency graph are optimized through the optimization algorithm. The optimization formula is expressed as:

[0086]

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

[0088] S24, dependency priority sorting: Generate dependency priority sorting of service components based on the optimized dependency weights to ensure that high-dependency components are tested first in subsequent tests;

[0089] By generating dependency graphs, marking key dependencies and optimizing them, we ensure that the collaborative work between components is covered during subsequent testing, effectively improving test coverage and efficiency.

[0090] S3 specifically includes:

[0091] S31, service component activation: gradually activate each service component on the core board according to the dependency priority order, ensuring that each component is started in the correct order to avoid functional loss due to the wrong startup order;

[0092] S32, startup response time test: record the startup response time required for each service component from activation to full operation, and define the startup response time formula as:

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

[0094] Among them, T start is the startup response time, T end is the time point when the component is fully running, T init Activate the component at a certain time.

[0095] S33, task processing capability test: testing the task processing capability of the component under different load conditions. The test method includes setting three load conditions (low, medium, and high) and calculating the task completion time of the component under each load;

[0096] S34, interface response test: detect the response time and correctness of the component interface, record the success rate and error rate of the interface call, and ensure that the interface can respond stably when the load changes;

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

[0098] S4 specifically includes:

[0099] S41, concurrent task simulation: simulate the high concurrent operation environment of the core board through multi-threaded scheduling, and test the running stability of components in multi-tasking concurrency;

[0100] S42, exception capture: Use exception monitoring tools to capture abnormal events of components under high concurrency conditions in real time. Abnormal events include deadlock, resource competition and memory leak;

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

[0102]

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

[0104] S44, memory usage monitoring: Combined with dynamic memory analysis tools, real-time monitoring of component memory usage, detection of memory leaks and unreasonable memory usage;

[0105] Through concurrent task simulation, exception capture and memory monitoring, the stability of the core board under high concurrency conditions is ensured, and potential resource competition and memory problems are discovered and resolved in advance.

[0106] S5 specifically includes:

[0107] S51, scenario-based test case design: Design test cases for a variety of complex scenarios based on actual application scenarios, including component hot swapping, network anomalies, and power failure recovery;

[0108] S52, component hot-swap test: During system operation, simulate the hot-swap operation of components to monitor whether the core board can handle hot-swap events without affecting the operation of other components;

[0109] S53, network anomaly test: simulate network anomalies (such as network disconnection, network jitter), and record the reconnection time and recovery status of the core board service component after the network is restored;

[0110] S54, power failure recovery test: simulates a sudden power failure scenario, detects the startup of each service component of the core board after power failure recovery, and records the recovery time and data consistency;

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

[0112] S6 specifically includes:

[0113] S61, test data collection: collect data in each test step through the 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 component functionality and stability indicators, use statistical methods to perform regression analysis on the data, and identify performance bottlenecks;

[0115] S63, Abnormal Behavior Analysis: Classify and analyze abnormal behavior records, determine the cause of the abnormality and its impact 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 the component, stability indicators, and the impact of dependencies on the test results.

[0117] By comprehensively collecting and analyzing test data, a detailed test report is generated, which helps to subsequently optimize the functionality and stability of service components.

[0118] Dependency graph model generation specifically includes:

[0119] Data input: collect dependency data between service components and input them into the deep learning model. Dependency data includes interface calls, data flows, and resource sharing.

[0120] Model training: Multilayer perceptron model is used for training. The model formula is expressed as:

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

[0122] 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;

[0123] Dependency graph generation: Generate a dependency graph based on 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 dependencies between service components and optimize the coverage and sequence of tests.

[0125] Memory usage monitoring in S44 further includes:

[0126] S441, memory allocation monitoring: monitor the memory allocation of service components through dynamic memory analysis tools to detect whether there is memory leak or memory fragmentation;

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

[0128]

[0129] Among them, L mem is the memory leak rate, M allocated is the total memory allocated, M freed The memory released.

[0130] S41 simulates the high concurrent operation environment of the core board through multi-thread scheduling, and adopts a multi-thread scheduling algorithm, which includes:

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

[0132] S412, thread contention management: using a resource contention manager to detect resource contention between threads to avoid deadlock;

[0133] S413, deadlock detection formula: Deadlock detection calculation is:

[0134]

[0135] Among them, D lock is the deadlock probability, P i is the priority of the i-th thread, R i The resource usage.

[0136] The present invention covers any substitution, modification, equivalent method and scheme made on the essence and scope of the present invention. In order to make the public have a thorough understanding of the present invention, specific details are described in detail in the following preferred embodiments of the present invention, but those skilled in the art can fully understand the present invention without the description of these details. In addition, in order to avoid unnecessary confusion about the essence of the present invention, well-known methods, processes, procedures, components and circuits are not described in detail.

[0137] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. Functionality and stability testing method of core board service components, characterized in that: The following steps are involved: S1, initialize the core board test environment: establish a standardized test environment by loading the firmware and configuration files of the core board, and use the automated test platform to complete the initialization of the test environment; S2, component dependency analysis: for the dependency relationships between different service components on the core board, an analysis algorithm based on the dependency graph model is used to generate a dependency graph between service components, and key dependencies are annotated and optimized through a deep learning model; S3, functional test: based on the dependency graph, each service component on the core board is gradually activated in the order of dependency priority, and the components are functionally tested in turn. The test content includes the component's startup response time, task processing capability, and interface response. During the test, three different load conditions of low, medium, and high are set to monitor and record the performance of the components under each load level; S4, stability test: by introducing multi-threaded scheduling and concurrent task simulation, the stability of the core board under high concurrency and multi-task operation is examined. The test content includes the running status monitoring, exception capture, resource competition and deadlock problem detection of service components, and the dynamic memory analysis tool is used to track the memory usage of components in real time. When an exception is detected, the corresponding error handling mechanism is recorded and executed; S5, scenario-based testing: Combined with actual application scenarios, design test cases for a variety of complex scenarios, including component hot swapping, network anomalies, and power failure recovery, and analyze the behavior of service components in a variety of complex scenarios; S6, test data analysis and feedback: Collect and analyze data from all test processes to generate a comprehensive functional and stability test report. The report content includes the component's functional performance, stability indicators, abnormal behavior records and the impact of its dependencies.

2. The method for testing the functionality and stability of the core board service component according to claim 1, characterized in that: The S1 specifically includes: S11, firmware loading: loading the firmware program of the core board and verifying 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 content includes hardware resource allocation, communication interface configuration and clock setting; S13, Standardized test environment construction: Complete the test environment initialization of the core board through the automated test platform, including the connection of test equipment, the setting of simulators, and the configuration of data acquisition systems; S14, environmental parameter verification: Verify the established test environment to verify whether the data transmission and communication between modules are normal.

3. The method for testing the functionality and stability of the core board service component according to claim 2, characterized in that: The S2 specifically includes: S21, dependency graph model generation: the dependency relationship of each service component on the core board is analyzed by a dependency graph analysis algorithm to generate a dependency graph between the service components; S22, key dependency annotation: annotating key dependencies in the generated dependency graph using a deep learning model, wherein the deep learning model is trained through supervised learning to train dependency weights based on previous data and optimize the dependency graph; S23, dependency optimization: optimize the key dependencies in the dependency graph through optimization algorithms; S24, dependency priority sorting: Generate dependency priority sorting of service components according to the optimized dependency weights.

4. The method for testing the functionality and stability of the core board service component according to claim 3 is characterized in that: The S3 specifically 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: records the startup response time required for each service component from activation to full operation; S33, task processing capability test: testing the task processing capability of the component under different load conditions, the test method includes setting three load conditions and calculating the task completion time of the component under each load; S34, interface response test: detect the response time and correctness of the component interface, and record the success rate and error rate of the interface call.

5. The method for testing the functionality and stability of the core board service component according to claim 4, characterized in that: The S4 specifically includes: S41, concurrent task simulation: simulate the high concurrent operation environment of the core board through multi-threaded scheduling, and test the running stability of components in multi-tasking concurrency; S42, exception capture: Use exception monitoring tools to capture abnormal events of components under high concurrency conditions in real time. Abnormal events include deadlock, resource competition and memory leak; S43, resource contention detection: using a resource contention detection algorithm to analyze the resource contention of each thread, and to detect whether there is performance degradation or deadlock caused by resource contention; S44, memory usage monitoring: Combined with dynamic memory analysis tools, it monitors the memory usage of components in real time and detects memory leaks and unreasonable memory usage.

6. The method for testing the functionality and stability of the core board service component according to claim 5, characterized in that: The S5 specifically includes: S51, scenario-based test case design: Design test cases for a variety of complex scenarios based on actual application scenarios, including component hot swapping, network anomalies, and power failure recovery; S52, component hot-swap test: During system operation, simulate the hot-swap operation of components to monitor whether the core board can handle hot-swap events without affecting the operation of other components; S53, network anomaly test: simulate network anomalies and record the reconnection time and recovery status of the core board service components after network recovery; S54, power failure recovery test: simulates a sudden power failure scenario, detects the startup status of each service component of the core board after power failure recovery, and records the recovery time and data consistency.

7. The method for testing the functionality and stability of the core board service component according to claim 6, characterized in that: The S6 specifically includes: S61, test data collection: collect data in each test step through the 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 component functionality and stability indicators, use statistical methods to perform regression analysis on the data, and identify performance bottlenecks; S63, Abnormal Behavior Analysis: Classify and analyze abnormal behavior records, determine the cause of the abnormality and its impact on component dependencies, and provide corresponding improvement suggestions; S64, report generation: Generate a comprehensive test report based on the analysis results. The report content includes the component's functional performance, stability indicators, and the impact of dependencies on the test results.

8. The method for testing the functionality and stability of the core board service component according to claim 3, characterized in that: The dependency graph model generation specifically includes: Data input: collect dependency data between service components and input them into the deep learning model. Dependency data includes interface calls, data flows, and resource sharing. Model training: Multilayer perceptron model is used for training. The model formula is expressed as: y = σ(Wx + b); 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; Dependency graph generation: Generate a dependency graph based on the calculated dependency weights to represent the dependency relationships between service components.

9. The method for testing the functionality and stability of 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 dynamic memory analysis tools to detect whether there is memory leak or memory fragmentation; S442, Memory leak detection formula: The memory leak rate is calculated as: Among them, L mem is the memory leak rate, M allocated is the total memory allocated, M freed The memory released.

10. The method for testing the functionality and stability of the core board service component according to claim 5, characterized in that: In S41, the high concurrent operation environment of the core board is simulated by multi-thread scheduling, and a multi-thread scheduling algorithm is adopted, which specifically includes: S411, thread priority scheduling: assigning a priority to each thread to ensure that high-priority tasks can obtain processing resources first; S412, thread contention management: using a resource contention manager to detect resource contention between threads to avoid deadlock; S413, deadlock detection formula: Deadlock detection calculation is: Among them, D lock is the deadlock probability, P i is the priority of the i-th thread, R i The resource usage.

Images