Computing hardware system testing method based on chaos engineering

Abstract

The invention belongs to the technical field of server testing, and particularly relates to a computing hardware system testing method based on chaos engineering, which comprises the following steps of: constructing a fault mode library, and setting a testing target and a testing range; distributing a corresponding weight coefficient for each fault type in the fault mode library; establishing a chaos test network model reflecting system operation logic, and setting different fault injection priorities for nodes and links; generating a fault scene set according to the fault mode library and the chaos test network model; executing a chaos experiment; comparing the collected performance index data with an expected value set in a test target, and deeply analyzing the performance index data; and the actual influence degree of each fault type is evaluated, the weight coefficient of the corresponding fault type in the fault mode library is adjusted, the structure and parameters of the chaotic test network model are optimized, and a test report is generated. The problems of subjective parameter selection, uncontrollable influence on a test system, difficulty in delimiting a test result and lack of software and hardware combination scenes are solved.

Description

Technical Field

[0001] This invention belongs to the field of server testing technology, and in particular relates to a testing method for computing hardware systems based on chaos engineering. Background Technology

[0002] Chaos testing is a systematic software testing method. Its core idea is to test the behavior and resilience of the system under non-ideal and unexpected conditions by introducing random and uncertain faults into the test system. Its goal is to identify the system's tolerance boundaries and improve the system's self-healing ability, ensuring that the system can continue to operate normally or recover quickly when faced with unforeseen events or faults.

[0003] In current chaos testing projects, most tests are based on hardware faults to test the robustness of upper-layer business systems, without separate testing of computing hardware systems. Furthermore, simulations are typically built using a traversal approach, which comprehensively covers all possible scenarios the system may encounter. The selection of injected faults often depends on the tester's experience. When applied to more complex computer hardware systems, this leads to huge testing times, complex environment construction, and reduced validity of test results.

[0004] Among existing technologies, the implementation schemes most similar to this solution include the following: Automated testing methods based on fault simulation: Rating algorithm: Based on the rating algorithm, the safety level of the system under test is defined according to the impact of system failure. On the system with the corresponding safety level, only the corresponding level of failure can be injected. Although this method reduces the noise generated during the test, it cannot fully cover the uncertain failures that may occur during the test for chaotic testing.

[0005] A method for generating test cases based on chaos testing: List generation: A corresponding list is generated based on the faults and their impact, and then test cases are generated from the list. Although this method can improve test accuracy and play a role in defining the boundaries of test results, the initial list generation requires a lot of human resources, and the subsequent maintenance of the list also requires some investment. Furthermore, overly targeted testing of faults can limit the testing capabilities of chaotic systems.

[0006] System testing methods based on chaos testing: Indicator setting and evaluation: By defining various performance indicators of the system through requirements and generating test cases, this solution mainly uses chaos engineering to improve system test coverage. In addition to reliability and robustness testing of software, it can also be optimized based on user experience. However, it has limitations in computer hardware testing systems.

[0007] Therefore, there is an urgent need to improve the existing testing methods for computing hardware systems to address issues such as subjective parameter selection, uncontrollable impact on the test system, difficulty in defining test results, and lack of hardware-software integration scenarios. Summary of the Invention

[0008] The purpose of this invention is to provide a testing method for computing hardware systems based on chaos engineering, in order to solve the problems of subjective parameter selection, uncontrollable impact on the test system, difficulty in defining test results, and lack of software and hardware integration scenarios.

[0009] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A testing method for computing hardware systems based on chaos engineering includes the following steps: S1: Build a fault mode library containing various fault types, fault parameters, and fault injection methods, and set test objectives and scope; S2: Assign corresponding weight coefficients to each fault type in the fault mode library based on the probability of occurrence, the degree of impact, and the importance of the business; S3: Establish a chaotic test network model that reflects the system's operating logic, and set different fault injection priorities for nodes and links in the network model according to fault weights; S4: Generate a set of fault scenarios based on the fault mode library and the chaotic test network model; S5: Perform a chaos experiment: In a simulated environment, inject faults sequentially or randomly according to the set of fault scenarios and fault weights, and monitor the operating status of the computing hardware system in real time during the fault injection. S6: Compare the collected performance index data with the expected values ​​set in the test objectives, and conduct in-depth analysis of the performance index data; S7: Based on the experimental results analysis, assess the actual impact of each fault type, adjust the weight coefficients of the corresponding fault types in the fault mode library, optimize the structure and parameters of the chaotic test network model, and generate a test report.

[0010] Preferably, the specific process of constructing the fault mode library in step S1 is as follows: S11: Collect historical fault data, including information on fault occurrence time, fault symptoms, fault causes, and fault repair process; S12: Clean, classify, and extract features from historical fault data to construct fault feature vectors; S13: Use clustering algorithms to perform cluster analysis on fault feature vectors to form different fault mode categories; S14: Define the fault parameter range and fault injection method for each fault mode category, and establish a fault mode library.

[0011] Preferably, the specific process of cleaning, classifying, and extracting features from historical fault data in step S12 to construct fault feature vectors is as follows: S121: Identify and process outliers and missing values ​​in historical fault data, and standardize the data; S122: Divide historical fault data into different categories and build a hierarchical classification system. The first-level categories are hardware faults, software faults, and network faults. Under the various faults in the first-level categories, second-level categories are set up to further subdivide into specific fault categories, including storage faults or power faults. S123: Extract statistical features, text features, and time-series features from historical fault data, integrate the statistical features, text features, and time-series features into a unified feature vector, directly incorporate the statistical features into the feature vector, directly concatenate the text features with the statistical features, and incorporate the time-series features into the feature vector after one-hot encoding. S124: Perform L2 normalization on the feature vector to construct a fixed-length feature vector, padding with zeros if necessary.

[0012] Preferably, the specific process of step S2 is as follows; S21: Construct a three-dimensional evaluation index system: The evaluation dimensions include the probability of failure, the degree of impact, and the importance of business, and define and set corresponding quantification methods for each; S22: Construct a judgment matrix: Set up a three-dimensional scoring table, quantify based on objective data, and calculate the probability of occurrence and the degree of impact; S23: Compare the importance of the three dimensions pairwise and construct a dimension-level judgment matrix; S24: Normalize each column of the dimensional layer judgment matrix and calculate the row mean to obtain the weight vector of each dimension.

[0013] Preferably, the specific process of step S3 is as follows: S31: Define the nodes of the computing hardware system, including physical layer nodes and logical layer nodes, and perform relationship modeling and link definition, including data flow links and control dependency links. S32: Perform graph theory modeling, and represent it as a directed weighted graph: G=(V,E,W), where V A set of nodes, corresponding to system components. E This is a set of edges, representing the connection relationships between components. W The weight matrix has the following elements. w ij Represents a node i arrive j Link weights; S33: Perform hierarchical modeling, including the physical layer, intermediate layer, application layer, and inter-layer mapping rules; S34: Perform dynamic behavior modeling, including state transition models and traffic propagation models; S35: Perform node failure priority calculation, link failure priority calculation, and failure propagation path analysis; S36: Train a chaotic test network model using historical fault data.

[0014] Preferably, the specific process of generating the fault scenario set based on the fault mode library and the chaotic test network model in step S4 is as follows: S41: Decompose each fault type in the fault mode library into injectable atomic units and establish a mapping relationship between fault atoms and network model nodes / links; S42: Layer by fault weight, extract fault atoms from high to low, generate high-frequency fault combinations based on the Apriori algorithm of historical fault data, and generate cascaded fault paths along the network model dependency links; S43: Establish a three-level fault intensity model to cover different impact ranges, calculate the parameter differences between scenarios, delete duplicate scenarios, use the DBSCAN algorithm to cluster the scenario parameter vectors, and retain the cluster center scenarios.

[0015] Preferably, the specific process in step S5 is as follows: S51: Uses containerization technology to encapsulate computing hardware system components, establishes an environment configuration registry, ensures that node parameters are consistent with the real environment, defines a unified injection protocol, and performs parameterized fault injection. S52: Implant multi-dimensional monitoring probes in the simulation environment, including CPU temperature, voltage, and fan speed at the hardware layer; process status, file system I / O, and network socket statistics at the system layer; and transaction success rate and response time percentile at the application layer. S53: Arrange fault scenarios in descending order of scenario risk, inject high-priority faults in sequence, and manage fault injection time to prevent overload of the simulation environment; S54: Collect monitoring data.

[0016] Preferably, the specific process of step S7 is as follows: S71: Construct an evaluation model that includes three dimensions: technology, business, and recovery, and use the analytic hierarchy process (AHP) to calculate the weighted total score; S72: Use K-means to classify fault types into four impact levels, and dynamically adjust the weights of the fault mode library based on experimental results; S73: Based on the actual fault propagation paths observed in the experiment, adjust the dependency weights between nodes in the chaotic test network model and add newly discovered implicit dependencies. S74: Generate a test report according to the preset test report template.

[0017] The beneficial effects of this invention include: This invention provides a testing method for computing hardware systems based on chaos engineering. The method involves constructing a fault mode library and setting test objectives and scope; assigning corresponding weight coefficients to each fault type in the library; establishing a chaotic test network model reflecting the system's operational logic and setting different fault injection priorities for nodes and links; generating a set of fault scenarios based on the fault mode library and the chaotic test network model; executing chaotic experiments; comparing the collected performance index data with the expected values ​​set in the test objectives, and conducting in-depth analysis of the performance index data; evaluating the actual impact of each fault type; adjusting the weight coefficients of the corresponding fault types in the fault mode library; optimizing the structure and parameters of the chaotic test network model; and generating a test report. This method addresses the issues of subjective parameter selection, uncontrollable impact on the test system, difficulty in defining test results, and the lack of integrated hardware and software scenarios.

[0018] First, through cleaning, classifying, and clustering historical fault data, faults are categorized into a three-tiered system of hardware, software, and network faults. Statistical, textual, and time-series multi-dimensional features are extracted to form a standardized fault pattern library containing fault parameter ranges and injection methods. This ensures that testing covers high-frequency historical faults and potential risk scenarios, avoiding omissions of key fault types and solving the problems of traditional testing relying on manual experience and insufficient scenario coverage. Combining fault occurrence probability, impact, and business importance, a dimensional judgment matrix is ​​constructed using the analytic hierarchy process (AHP) to achieve quantitative assessment of fault risk. Compared to single-dimensional assessments, this prioritizes high-risk faults, making test resource allocation more aligned with actual business needs and improving testing efficiency.

[0019] Secondly, by defining physical / logical layer nodes, representing a directed weighted graph, and modeling dynamic behavior, the dependencies between system components and fault propagation paths are accurately mapped. Prioritization based on fault weights increases the injection frequency of high-impact faults, effectively simulating the fault propagation process in a real environment and overcoming the shortcomings of traditional testing that only focuses on single-point faults and ignores systemic risks. Atomized decomposition and the Apriori algorithm are used to generate high-frequency fault combinations, combined with a three-level strength model to cover the impact range of mild, moderate, and severe faults. The scenario set generated by this method not only includes single faults but can also simulate complex cascading scenarios such as network latency and CPU overload, improving the business relevance of the test scenarios and increasing coverage.

[0020] Finally, by using a containerized simulation environment and multi-dimensional monitoring probes, real-time hardware / system / application layer metric data is collected, and injection time window management prevents environmental overload. This improves the anomaly detection rate, while a loss mitigation strategy shortens system crash recovery time, ensuring the safety and accuracy of the testing process. A three-dimensional evaluation model encompassing technology, business, and recovery is constructed, using K-means clustering to classify fault impacts, dynamically adjusting fault weights, and optimizing network model dependencies. This closed-loop mechanism enables the testing system to automatically adapt to new fault modes, improving the alignment between the adjusted fault injection priority and actual business risks, thus forming a continuous evolutionary capability of "test-analysis-optimization." Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating the testing method for a computing hardware system based on chaos engineering according to the present invention.

[0022] Figure 2 This is a diagram of the overall hardware architecture of the test system of the present invention.

[0023] Figure 3 This is an example screenshot of the testing tool interface of the present invention. Detailed Implementation

[0024] The following is in conjunction with the appendix Figures 1-3 The present invention will be further described in detail below: See appendix Figures 1-3 As shown, a testing method for a computing hardware system based on chaos engineering includes the following steps: S1: Build a fault mode library containing various fault types, fault parameters, and fault injection methods, and set test objectives and scope; S2: Assign corresponding weight coefficients to each fault type in the fault mode library based on the probability of occurrence, the degree of impact, and the importance of the business; S3 establishes a chaotic test network model that reflects the system's operating logic, and sets different fault injection priorities for nodes and links in the network model according to fault weights. S4: Generate a set of fault scenarios based on the fault mode library and the chaotic test network model; S5: Perform a chaos experiment: In a simulated environment, inject faults sequentially or randomly according to the set of fault scenarios and fault weights, and monitor the operating status of the computing hardware system in real time during the fault injection. S6: Compare the collected performance index data with the expected values ​​set in the test objectives, and conduct in-depth analysis of the performance index data; S7: Based on the experimental results analysis, assess the actual impact of each fault type, adjust the weight coefficients of the corresponding fault types in the fault mode library, optimize the structure and parameters of the chaotic test network model, and generate a test report.

[0025] The specific process of building the fault mode library in step S1 is as follows: S11: Collect historical fault data, including fault occurrence time, fault symptoms, fault causes, and fault repair process. Divide the system into different components, such as drivers and hardware components based on computer hardware characteristics. Analyze historical faults of the computer hardware system. The most classic fault modes originate from incidents that have caused system failures. Review past faults and incidents, analyze their causes and effects, and include representative fault modes in the testing scope. Refer to fault modes and testing experience of similar systems in the same industry, and select those commonly occurring fault modes for testing. Archive the collected fault modes into a fault mode library for continuous use and maintenance.

[0026] S12: Clean, classify and extract features from historical fault data to construct fault feature vectors.

[0027] The specific process is as follows: S121: Identify and process outliers and missing values ​​in historical fault data, and standardize the data; S122: Divide historical fault data into different categories and build a hierarchical classification system. The first-level categories are hardware faults, software faults, and network faults. Under the various faults in the first-level categories, second-level categories are set up to further subdivide into specific fault categories, including storage faults or power faults. S123: Extract statistical features, text features, and time-series features from historical fault data, integrate the statistical features, text features, and time-series features into a unified feature vector, directly incorporate the statistical features into the feature vector, directly concatenate the text features with the statistical features, and incorporate the time-series features into the feature vector after one-hot encoding. S124: Perform L2 normalization on the feature vector to construct a fixed-length feature vector, padding with zeros if necessary.

[0028] S13: Clustering algorithms are used to perform cluster analysis on fault feature vectors to form different fault mode categories. Two key parameters are set: neighborhood radius ε and minimum number of samples MinPts. An unvisited sample point is randomly selected from the dataset, and all sample points within its ε-neighborhood are searched. If the number of sample points within the ε-neighborhood is greater than or equal to MinPts, then this sample point is a core point, and a new cluster is created, adding all sample points within its ε-neighborhood to this cluster. This process is repeated for each unvisited sample point within the ε-neighborhood of a core point, continuously expanding the clusters until no new sample points can be added. If a sample point is not a core point and does not belong to any existing cluster, it is marked as a noise point. After traversing all sample points, the clustering process ends, forming different clusters. After clustering, the results need to be evaluated to determine if the clustering effect meets expectations. Based on the final clustering results, each cluster is defined as a fault mode category. Each category is analyzed and summarized to extract its fault characteristics and patterns, forming a detailed fault mode description, including the fault's manifestation, possible causes, and scope of impact. Ultimately, a complete fault mode library is established to provide strong support for subsequent fault prediction, diagnosis, and handling.

[0029] S14: Define the fault parameter range and fault injection method for each fault mode category, and establish a fault mode library.

[0030] The specific process of step S2 is as follows; S21: Construct a three-dimensional evaluation index system: The evaluation dimensions include the probability of failure occurrence, the degree of impact, and business importance, each defined and quantified accordingly. The probability of failure occurrence refers to the frequency of a specific failure type occurring within a certain time period, reflecting the likelihood of the failure occurring during system operation. The degree of impact measures the extent to which a failure disrupts the performance, functionality, and availability of the computing hardware system. Business importance assesses the priority and criticality of the affected business within the overall business architecture, as well as its importance to enterprise operations and user experience.

[0031] The probability quantification process for a fault occurrence is as follows: collect historical fault data and count the number of times each fault type has occurred over a period of time. Calculate the fault occurrence frequency = number of occurrences of a certain fault type / total number of fault occurrences, and use the result as the quantified value of the fault occurrence probability, with a value range of [0, 1].

[0032] The process of quantifying the impact involves evaluating multiple sub-dimensions, including system performance, functional availability, and data integrity. These sub-dimensions may include: system performance degradation rate (percentage increase in CPU utilization, response time extension, etc.), percentage of time unavailable, and amount of data loss. A scoring standard is set for each sub-dimension; for example, 0-10% performance degradation is worth 1 point, 10-20% is worth 2 points, and so on. The scores from all sub-dimensions are then combined and a weighted average is used to calculate the quantified impact score. The weights can be determined by expert experience or historical data analysis based on the importance of each sub-dimension.

[0033] Business importance quantification: Evaluation is based on factors such as business type, user scale, and contribution to company revenue. A tiered scoring method is used, assigning different scores to core businesses, supporting businesses, and peripheral businesses; businesses serving a large number of users receive higher scores than businesses serving a small number of users, etc., ultimately resulting in a quantitative score for business importance.

[0034] S22: Constructing the Judgment Matrix: Set up a three-dimensional scoring table, quantify based on objective data, and calculate the probability of occurrence and the degree of impact. Design a scoring table containing three dimensions: probability of failure occurrence, degree of impact, and business importance. The horizontal axis of the table represents each failure type, and the vertical axis represents the three evaluation dimensions. Calculate the probability of occurrence: Following the quantification method of failure occurrence probability described above, fill in the corresponding positions of the scoring table with the statistically calculated probability of occurrence for each failure type. Calculate the degree of impact: Collect relevant data such as system performance and functionality when a failure occurs. Based on the quantification standard of impact degree and the weighted average calculation method, obtain the degree of impact score for each failure type and fill it in the table.

[0035] S23: Compare the importance of the three dimensions pairwise to construct a dimension-level judgment matrix.

[0036] The relative importance of the three dimensions—probability of failure occurrence, impact, and business importance—is compared pairwise. A 1-9 scale is used for scoring: 1 indicates that both dimensions are equally important; 3 indicates that one dimension is slightly more important than the other; 5 indicates that one dimension is significantly more important than the other; 7 indicates that one dimension is strongly more important than the other; 9 indicates that one dimension is extremely more important than the other; 2, 4, 6, and 8 are the median values ​​of these adjacent judgments. If the impact is considered significantly more important than the probability of failure occurrence, the score in the comparison between impact and probability is 5; otherwise, it is 1 / 5.

[0037] Based on the pairwise comparison scores, construct the dimension-level judgment matrix: ; in, a ij Indicates the first i The dimension relative to the firstj Importance rating of each dimension a ii =1, a ij =1 / a ji .

[0038] S24: Normalize each column of the dimensional layer judgment matrix and calculate the row mean to obtain the weight vector of each dimension.

[0039] For the dimension layer judgment matrix A For each column, calculate the sum of its elements. Divide each column's elements by the sum of its elements to obtain the normalized matrix. Calculate the normalized matrix. A The mean of each row's elements is used to obtain the weight vector for each dimension. W .

[0040] The specific process of step S3 is as follows: S31: Define the nodes of the computing hardware system, including physical layer nodes and logical layer nodes, and perform relationship modeling and link definition, including data flow links and control dependency links. S32: Perform graph theory modeling, and represent it as a directed weighted graph: G=(V,E,W), where V A set of nodes, corresponding to system components. E This is a set of edges, representing the connection relationships between components. W The weight matrix has the following elements. w ij Represents a node i arrive j Link weights; S33: Perform hierarchical modeling, including the physical layer, intermediate layer, application layer, and inter-layer mapping rules; S34: Perform dynamic behavior modeling, including state transition models and traffic propagation models; S35: Perform node failure priority calculation, link failure priority calculation, and failure propagation path analysis; S36: Train a chaotic test network model using historical fault data.

[0041] The specific process of generating the fault scenario set based on the fault mode library and the chaotic test network model in step S4 is as follows: S41: Decompose each fault type in the fault mode library into injectable atomic units and establish a mapping relationship between fault atoms and network model nodes / links.

[0042] The key characteristics of a fault atomic unit are: a single fault attribute, independent injection capability, and configurable parameters. For example, a "hard drive failure" can be broken down into atomic units such as "sudden increase in hard drive read error rate" and "decrease in hard drive write speed." Each unit includes elements such as fault type, impact indicators, and parameter range. Each fault type in the fault mode library is analyzed from the dimensions of fault manifestation, impact mechanism, and involved components. Server downtime failures can be broken down into atomic units such as "CPU overheating downtime" and "memory overflow downtime," with each atomic unit corresponding to specific triggering conditions and impact scope.

[0043] Identify the nodes and links in the chaotic test network model, clarifying the functions and interrelationships of each entity. Map hardware-related fault atoms to their corresponding physical server nodes; map software-related fault atoms to the logical nodes hosting database services. Map network-related fault atoms directly to network links; map fault atoms involving data interaction to service call links. Use tables or a database to store the mapping relationships between fault atoms and network model nodes / links for quick retrieval during subsequent scenario generation.

[0044] S42: Layer faults by fault weight, extract fault atoms from high to low, generate high-frequency fault combinations based on the Apriori algorithm of historical fault data, and generate cascading fault paths along the network model dependency links.

[0045] Based on the weight coefficients of each fault type in the fault mode library, all fault atoms are sorted in descending order. High-weight core database service interruption-related atoms are extracted first, followed by low-weight "edge interface occasionally returns errors" atoms. High-weight layer: Prioritize extracting the top 20% of fault atoms by weight to ensure test coverage of key risk points. Medium-weight layer: Extract atoms with weights between 20% and 70% to supplement common fault scenarios. Low-weight layer: Extract the remaining 30% of atoms by weight to cover low-frequency faults that may affect the system.

[0046] Historical fault data is preprocessed and transformed into a transaction dataset suitable for the Apriori algorithm. Each transaction represents a fault event, containing faulty atomic units that appear in that event. Minimum support and minimum confidence are set. The frequency of each individual faulty atom is counted, and atoms that meet the minimum support are selected to form frequent 1-itemsets. Through join and pruning operations, frequent 2-itemsets, frequent 3-itemsets, and so on are gradually generated until no longer frequent itemsets can be generated. Association rules that meet the minimum confidence are extracted from the frequent itemsets. Based on the generated association rules, related faulty atoms are combined into high-frequency fault scenarios. Based on the dependencies between nodes and links in the chaotic test network model, possible fault propagation paths are determined. Starting from the node / link where the selected initial faulty atom is located, a recursive search is performed along the dependent links to generate cascading fault paths. Based on the fault's impact range and weight, cascading fault paths with practical testing value are selected, and paths with too little impact or too complex and difficult to test are eliminated.

[0047] S43: Establish a three-level fault intensity model to cover different impact ranges, calculate the parameter differences between scenarios, delete duplicate scenarios, use the DBSCAN algorithm to cluster the scenario parameter vectors, and retain the cluster center scenarios.

[0048] Defining Fault Intensity Levels: Minor Faults: Have minimal impact on system performance and business operations, such as a brief increase in CPU utilization to 70% or a 10ms increase in network latency. The system can recover automatically or only experiences minor performance fluctuations. Moderate Faults: Cause limitation of some system functions or a significant performance degradation, such as a 50% increase in the response time of a service module or errors in some data transmissions, requiring manual intervention. Severe Faults: Cause unavailability of critical system functions, business interruption, or data loss, such as core server crashes or database failures, severely impacting business operations. Parameter ranges are set for the fault atomic units of each intensity level. The disk I / O error rate parameter range is 1%-5% for minor faults, 5%-20% for moderate faults, and greater than 20% for severe faults.

[0049] The specific process in step S5 is as follows: S51: Uses containerization technology to encapsulate computing hardware system components, establishes an environment configuration registry, ensures that node parameters are consistent with the real environment, defines a unified injection protocol, and performs parameterized fault injection.

[0050] S52: Implant multi-dimensional monitoring probes in the simulation environment, including CPU temperature, voltage, and fan speed at the hardware layer; process status, file system I / O, and network socket statistics at the system layer; and transaction success rate and response time percentile at the application layer. S53: Arrange fault scenarios in descending order of scenario risk, inject high-priority faults in sequence, and manage fault injection time to prevent overload of the simulation environment; S54: Collect monitoring data.

[0051] The specific process of step S7 is as follows: S71: Construct an evaluation model that includes three dimensions: technology, business, and recovery, and use the analytic hierarchy process (AHP) to calculate the weighted total score; S72: Use K-means to classify fault types into four impact levels, and dynamically adjust the weights of the fault mode library based on experimental results; S73: Based on the actual fault propagation paths observed in the experiment, adjust the dependency weights between nodes in the chaotic test network model and add newly discovered implicit dependencies, such as database connection pool exhaustion → application freeze. S74: Generate a test report according to the preset test report template.

[0052] In summary, the computing hardware system testing method based on chaos engineering provided by this invention constructs a fault mode library and sets test objectives and scope; assigns corresponding weight coefficients to each fault type in the fault mode library; establishes a chaotic test network model reflecting the system's operating logic and sets different fault injection priorities for nodes and links; generates a set of fault scenarios based on the fault mode library and the chaotic test network model; executes chaotic experiments; compares the collected performance index data with the expected values ​​set in the test objectives, and conducts in-depth analysis of the performance index data; evaluates the actual impact of each fault type, adjusts the weight coefficients of the corresponding fault types in the fault mode library, optimizes the structure and parameters of the chaotic test network model, and generates a test report. This addresses the issues of subjective parameter selection, uncontrollable impact on the test system, difficulty in defining test results, and lack of hardware-software integration scenarios.

[0053] By cleaning, classifying, and clustering historical fault data, faults are categorized into a three-tiered system of hardware, software, and network faults. Statistical, textual, and temporal-series multi-dimensional features are extracted to form a standardized fault pattern library containing fault parameter ranges and injection methods. This solves the problems of traditional testing relying on manual experience and insufficient scenario coverage. Combining fault occurrence probability, impact degree, and business importance, a dimensional layer judgment matrix is ​​constructed using the analytic hierarchy process (AHP) to achieve quantitative assessment of fault risk and improve testing efficiency. Through physical / logical layer node definition, directed weighted graph representation, and dynamic behavior modeling, system component dependencies and fault propagation paths are accurately mapped. A containerized simulation environment and multi-dimensional monitoring probes are used to collect hardware / system / application layer indicator data in real time, combined with injection time window management to prevent environmental overload. This improves the anomaly detection rate and shortens system crash recovery time through loss mitigation strategies, ensuring the safety and accuracy of the testing process. A three-dimensional evaluation model of technology, business, and recovery is constructed, using K-means clustering to classify fault impact, dynamically adjusting fault weights, and optimizing network model dependencies. This closed-loop mechanism enables the testing system to automatically adapt to new failure modes, and the priority of fault injection after weight adjustment is better matched with the actual business risks, forming a continuous evolution capability of "test-analysis-optimization".

Claims

1. A testing method for computing hardware systems based on chaos engineering, characterized in that, Includes the following steps: S1: Build a fault mode library containing various fault types, fault parameters, and fault injection methods, and set test objectives and scope; S2: Assign corresponding weight coefficients to each fault type in the fault mode library based on the probability of occurrence, the degree of impact, and the importance of the business; S3: Establish a chaotic test network model that reflects the system's operating logic, and set different fault injection priorities for nodes and links in the network model according to fault weights; S4: Generate a set of fault scenarios based on the fault mode library and the chaotic test network model; S5: Perform a chaos experiment: In a simulated environment, inject faults sequentially or randomly according to the set of fault scenarios and fault weights, and monitor the operating status of the computing hardware system in real time during the fault injection. S6: Compare the collected performance index data with the expected values ​​set in the test objectives, and conduct in-depth analysis of the performance index data; S7: Based on the experimental results analysis, assess the actual impact of each fault type, adjust the weight coefficients of the corresponding fault types in the fault mode library, optimize the structure and parameters of the chaotic test network model, and generate a test report.

2. The method for testing a computing hardware system based on chaos engineering according to claim 1, characterized in that, The specific process of building the fault mode library in step S1 is as follows: S11: Collect historical fault data, including information on fault occurrence time, fault symptoms, fault causes, and fault repair process; S12: Clean, classify, and extract features from historical fault data to construct fault feature vectors; S13: Use clustering algorithms to perform cluster analysis on fault feature vectors to form different fault mode categories; S14: Define the fault parameter range and fault injection method for each fault mode category, and establish a fault mode library.

3. The method for testing a computing hardware system based on chaos engineering according to claim 2, characterized in that, The specific process of cleaning, classifying, and extracting features from historical fault data in step S12 to construct fault feature vectors is as follows: S121: Identify and process outliers and missing values ​​in historical fault data, and standardize the data; S122: Divide historical fault data into different categories and build a hierarchical classification system. The first-level categories are hardware faults, software faults, and network faults. Under the various faults in the first-level categories, second-level categories are set up to further subdivide into specific fault categories, including storage faults or power faults. S123: Extract statistical features, text features, and time-series features from historical fault data, integrate the statistical features, text features, and time-series features into a unified feature vector, directly incorporate the statistical features into the feature vector, directly concatenate the text features with the statistical features, and incorporate the time-series features into the feature vector after one-hot encoding. S124: Perform L2 normalization on the feature vector to construct a fixed-length feature vector, padding with zeros if necessary.

4. The method for testing a computing hardware system based on chaos engineering according to claim 1, characterized in that, The specific process of step S2 is as follows; S21: Construct a three-dimensional evaluation index system: The evaluation dimensions include the probability of failure, the degree of impact, and the importance of business, and define and set corresponding quantification methods for each; S22: Construct a judgment matrix: Set up a three-dimensional scoring table, quantify based on objective data, and calculate the probability of occurrence and the degree of impact; S23: Compare the importance of the three dimensions pairwise and construct a dimension-level judgment matrix; S24: Normalize each column of the dimensional layer judgment matrix and calculate the row mean to obtain the weight vector of each dimension.

5. The method for testing a computing hardware system based on chaos engineering according to claim 1, characterized in that, The specific process of step S3 is as follows: S31: Define the nodes of the computing hardware system, including physical layer nodes and logical layer nodes, and perform relationship modeling and link definition, including data flow links and control dependency links. S32: Perform graph theory modeling, and represent it as a directed weighted graph: G=(V,E,W), where V A set of nodes, corresponding to system components. E This is a set of edges, representing the connection relationships between components. W The weight matrix has the following elements. w ij Represents a node i arrive j Link weights; S33: Perform hierarchical modeling, including the physical layer, intermediate layer, application layer, and inter-layer mapping rules; S34: Perform dynamic behavior modeling, including state transition models and traffic propagation models; S35: Perform node failure priority calculation, link failure priority calculation, and failure propagation path analysis; S36: Train a chaotic test network model using historical fault data.

6. The method for testing a computing hardware system based on chaos engineering according to claim 1, characterized in that, The specific process of generating the fault scenario set based on the fault mode library and the chaotic test network model in step S4 is as follows: S41: Decompose each fault type in the fault mode library into injectable atomic units and establish a mapping relationship between fault atoms and network model nodes / links; S42: Layer by fault weight, extract fault atoms from high to low, generate high-frequency fault combinations based on the Apriori algorithm of historical fault data, and generate cascaded fault paths along the network model dependency links; S43: Establish a three-level fault intensity model to cover different impact ranges, calculate the parameter differences between scenarios, delete duplicate scenarios, use the DBSCAN algorithm to cluster the scenario parameter vectors, and retain the cluster center scenarios.

7. A testing method for a computing hardware system based on chaos engineering according to claim 6, characterized in that, The specific process in step S5 is as follows: S51: Uses containerization technology to encapsulate computing hardware system components, establishes an environment configuration registry, ensures that node parameters are consistent with the real environment, defines a unified injection protocol, and performs parameterized fault injection. S52: Implant multi-dimensional monitoring probes in the simulation environment, including CPU temperature, voltage, and fan speed at the hardware layer; process status, file system I / O, and network socket statistics at the system layer; and transaction success rate and response time percentile at the application layer. S53: Arrange fault scenarios in descending order of scenario risk, inject high-priority faults in sequence, and manage fault injection time to prevent overload of the simulation environment; S54: Collect monitoring data.

8. The method for testing a computing hardware system based on chaos engineering according to claim 1, characterized in that, The specific process of step S7 is as follows: S71: Construct an evaluation model that includes three dimensions: technology, business, and recovery, and use the analytic hierarchy process (AHP) to calculate the weighted total score; S72: Use K-means to classify fault types into four impact levels, and dynamically adjust the weights of the fault mode library based on experimental results; S73: Based on the actual fault propagation paths observed in the experiment, adjust the dependency weights between nodes in the chaotic test network model and add newly discovered implicit dependencies. S74: Generate a test report according to the preset test report template.

Images