A server adaptive restart test method and apparatus

Abstract

This application provides a server adaptive restart testing method and apparatus. The method includes: determining a first reliability of the test platform's test software environment and a second reliability of the server's hardware components under test; calculating the number of adaptive test cycles corresponding to the server under test based on the product of the first and second reliability with their corresponding weights, wherein the number of adaptive test cycles is not exactly the same for different servers under test; determining a target restart strategy based on the first and second reliability; and performing a restart test on the server according to the number of adaptive test cycles and the target restart strategy. The method provided in this application dynamically determines the corresponding number of test cycles and the restart strategy based on the test platform's test software environment and the state of the server's hardware components, enabling different test configurations for different servers under test, thereby improving resource utilization efficiency, test flexibility, and test adaptability during server restart testing.

Description

Technical Field

[0001] This application relates to the field of server testing technology, and in particular to a server adaptive restart testing method and apparatus. Background Technology

[0002] With the widespread application of servers in data centers, cloud computing, and enterprise-level business scenarios, servers typically require numerous restart tests during factory verification, stability testing, and aging testing to verify their stability and reliability under different operating conditions. Currently, server restart testing commonly employs a pre-set fixed number of test cycles, performing soft restarts, cold restarts, or power cycle restarts on the servers under test. However, existing testing solutions often use the same number of test cycles and restart methods for different servers under test, failing to fully consider the differences between different test objects. This results in excessively long testing cycles and high test resource consumption for some servers, while insufficient test coverage for others, affecting fault detection. Furthermore, existing testing solutions use static test configurations, lacking adjustments based on server operating conditions and historical test data during testing. This leads to a low degree of matching between the testing solution and the actual server operating conditions, affecting testing efficiency and the accuracy of results. Summary of the Invention

[0003] In view of this, this application provides a server adaptive restart testing method to solve the problems of low test resource utilization and insufficient test scheme flexibility in the prior art.

[0004] Specifically, this application is implemented through the following technical solution:

[0005] The first aspect of this application provides a server adaptive restart testing method, the method comprising:

[0006] Determine the primary reliability of the test platform's test software environment and the secondary reliability of the hardware components of the server under test;

[0007] The number of adaptive test cycles for the server under test is calculated based on the product of the first reliability and the second reliability with their corresponding weights. The number of adaptive test cycles for different servers under test is not exactly the same.

[0008] The target restart strategy is determined based on the first reliability and the second reliability.

[0009] A restart test is performed on the server according to the adaptive test cycle number and the target restart strategy.

[0010] A second aspect of this application provides a server adaptive restart testing apparatus, the apparatus comprising a determining module, a calculating module, and an executing module, wherein:

[0011] The determining module is used to determine the first reliability of the test platform test software environment and the second reliability of the hardware components of the server under test;

[0012] The calculation module is used to calculate the number of adaptive test cycles corresponding to the server under test based on the product of the first reliability and the second reliability with the corresponding weights. The number of adaptive test cycles for different servers under test is not exactly the same.

[0013] The calculation module is used to determine the target restart strategy based on the first reliability and the second reliability;

[0014] The execution module is used to perform a restart test on the server according to the adaptive test cycle number and the target restart strategy.

[0015] The server adaptive restart testing method and apparatus provided in this application, compared with the existing technology that uses a fixed number of test cycles and a fixed restart strategy, achieves differentiated restart test configurations for different servers under test by separately determining the first reliability of the test platform's test software environment and the second reliability of the hardware components of the server under test, and determining the corresponding adaptive number of test cycles and target restart strategy based on the first reliability and the second reliability. The first reliability characterizes the stability and test reliability of the test platform's test software environment, while the second reliability characterizes the fault risk status at the hardware level of the server under test. Since test failures during server restart testing may originate from either test platform anomalies or server hardware anomalies, adjusting the test intensity based on only a single dimension can easily lead to inaccurate fault source differentiation, insufficient test coverage, or wasted test resources. This application, by simultaneously introducing reliability evaluation results from both the test platform and server hardware dimensions, ensures that the determination of the number of test cycles reflects the actual fault risk of the server hardware and can be dynamically adjusted based on the current test environment's reliability, thereby achieving a match between the test intensity and the actual operating state of the server. When the test platform has low stability or the server hardware failure risk is high, the corresponding number of test cycles and the intensity of restart tests are increased to increase the probability of potential failure exposure. When both the test platform and the server are in a high reliability state, the number of test cycles is reduced and a milder restart strategy is adopted to reduce unnecessary test resource consumption. Furthermore, this application determines the corresponding target restart strategy based on a first reliability level and a second reliability level, matching servers in different reliability states with restart methods of varying severity. This achieves coordinated adaptive adjustment of the number of test cycles and the restart strategy, improving fault coverage and test result accuracy under different risk scenarios. Without adding additional test hardware, it enhances the test relevance, test reliability, and resource utilization efficiency during server restart testing. Attached Figure Description

[0016] Figure 1 A flowchart of Embodiment 1 of the server adaptive restart test method provided in this application;

[0017] Figure 2 This is a schematic diagram of the structure of an embodiment of the server adaptive restart test device provided in this application. Detailed Implementation

[0018] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0019] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0020] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0021] The following specific embodiments are given to illustrate the technical solution of this application in detail.

[0022] Figure 1 This is a flowchart of Embodiment 1 of the server adaptive restart test method provided in this application. Please refer to... Figure 1 The method provided in this embodiment may include:

[0023] S101. Determine the first reliability of the test platform's test software environment and the second reliability of the hardware components of the server under test.

[0024] Specifically, the server adaptive restart testing method provided in this application can be applied to scenarios such as server production testing, factory verification, stability aging testing, and server maintenance testing. The server adaptive restart testing system may include a testing platform, a server under test, and a test management module. The testing platform is used to issue restart test tasks to the server under test and obtain corresponding test results; the server under test is used to respond to the corresponding test tasks and execute a restart operation; the test management module is used to determine corresponding test parameters and target restart strategies based on the operating status of the testing platform and the hardware status of the server under test. The testing platform may include a test control server, a test network environment, power control equipment, test scripts, and a log collection system, etc., to achieve unified test control and test result management of the server under test. Since the operating status of the testing platform itself affects the stability and reliability of the test results, this application determines the first reliability characterizing the overall stability of the testing platform's test software environment based on historical test data, product stage data, customer site fault data, and review data.

[0025] Furthermore, the server under test refers to the server device that needs to perform a restart test, which can be a single server or a server cluster composed of multiple servers. Each server under test may include hardware components such as a central processing unit (CPU), memory, hard disk, power module, PCIe card, graphics processing unit (GPU), fan, and network components. Different hardware components correspond to different operating states and reliability levels, and different hardware components perform different functions during server operation, resulting in differences in their operating states and fault sensitivities. To uniformly quantify and characterize the fault risk at the server hardware level, this application determines the corresponding component reliability value based on historical fault data and evaluation data of each hardware component, and then weights and aggregates these component reliability values ​​according to preset weights to obtain a second reliability value used to characterize the overall reliability of the server hardware under test.

[0026] Specifically, in some implementations, the server under test can correspond to different test tasks, with different test requirements and intensity. When the same server under test corresponds to multiple test tasks, the test parameters for each test task can be determined separately, and the multiple test parameters can be fused to obtain the final test parameters for the corresponding server under test.

[0027] Specifically, the target restart strategy refers to the specific method by which the server under test is restarted, which may include different restart methods such as soft restart, cold restart, and power cycle restart. Different restart methods correspond to different system recovery methods and different levels of test coverage. The test management module can determine the corresponding target restart strategy based on the first reliability and the second reliability, so that the server under test in different reliability states uses different restart methods to execute the corresponding test tasks.

[0028] Specifically, in this application, the logical relationship between the various technical objects is as follows: the test platform and the server under test respectively provide a first reliability and a second reliability as input parameters in the test decision-making process; the test management module determines the adaptive test cycle number and target restart strategy for the corresponding server under test based on the first reliability and the second reliability; then, the corresponding restart test is executed according to the adaptive test cycle number and target restart strategy; after the test is completed, the first reliability and the second reliability can be updated based on the test results, thereby forming a dynamic adaptive restart test mechanism for different servers under test. The adaptive test cycle number for different servers under test may not be exactly the same.

[0029] Specifically, the first reliability is used to characterize the overall stability of the test platform's test software environment, while the second reliability is used to characterize the overall reliability of the hardware components of the server under test. The operating status of the test platform and the hardware status of the server under test both affect the accuracy and validity of the restart test results. Therefore, this application constructs corresponding reliability systems from the test platform side and the server hardware side, respectively, as input parameters in the subsequent test decision-making process. In some implementations, different servers under test correspond to different hardware configurations, operating statuses, and historical operating conditions; therefore, the second reliability for different servers under test may not be entirely the same.

[0030] Optionally, in one possible implementation, the calculation of the first reliability includes:

[0031] (1) Obtain historical test data, product stage data, customer site failure data and review data related to the test platform's operating status.

[0032] Specifically, the data related to the test platform's operational status comes from multiple data collection sources, reflecting the test platform's performance across different time dimensions and application scenarios. Historical test data records the execution results of the test platform during historical server restart tests, including the number of successful tests, the number of failed tests, and records of abnormal interruptions. For example, the total number of tests and the number of failures can be calculated based on a preset time window. Product stage data characterizes the product lifecycle stage of the test platform, with different stages corresponding to different stability levels, such as the engineering verification stage, the production verification stage, and the mass production stage. Customer site fault data reflects abnormal operational situations of the test platform in the actual deployment environment, such as false alarms, missed alarms, and execution anomaly records reported on-site. Review data records the comprehensive scoring results of the test platform's stability and reliability during quality reviews, such as evaluation results based on scorecards from dimensions such as test process standardization, defect detection capability, and test coverage.

[0033] (2) Determine the historical test failure rate based on the historical test data, determine the corresponding stage score based on the product stage data, determine the customer site failure rate based on the customer site failure data, and determine the review score based on the review data.

[0034] Specifically, different types of raw data are processed into metrics to transform them into unified and calculable evaluation indicators for subsequent reliability calculations. The historical test failure rate characterizes the probability of a test platform failing during historical testing. It is determined by the ratio of failed tests to the total number of tests within a preset time window. For example, if 1000 tests are performed and 20 fail within a preset period, the failure rate is 0.02. Product stage data is mapped to stage scores to characterize the stability level of the test platform at each stage of its lifecycle. Different stages correspond to different preset scores; for example, 0.4 for the engineering verification stage, 0.7 for the production verification stage, and 1.0 for the mass production stage. The customer site failure rate characterizes the probability of a test platform failing in actual operating environments. It is determined by the ratio of the number of reported failures to the deployment scale. For example, 50 failure reports out of 1000 deployed devices correspond to a failure rate of 0.05. The review score characterizes the comprehensive evaluation result obtained based on the quality review system, typically using a percentage-based scoring method. For example, a review score of 85 points.

[0035] (3) Normalize the historical test failure rate, the stage score, the customer site failure rate and the review score.

[0036] Specifically, due to the different dimensions and numerical ranges of the various indicators, normalization is necessary to ensure comparability between them. This can be achieved through linear normalization or piecewise mapping, converting historical test failure rates and customer field failure rates into a reverse scoring format, where lower failure rates correspond to higher scores, and all scores are uniformly mapped to the 0-1 range. This normalization process ensures comparability of the indicators within the same evaluation system, providing a unified input basis for subsequent weighted calculations.

[0037] (4) The normalized evaluation index is weighted based on the preset weights to obtain the first reliability.

[0038] Specifically, to reflect the varying degrees of impact of different indicators on the reliability of the testing platform, each normalized evaluation indicator is assigned a corresponding preset weight, with the sum of all weights being 1. These preset weights are set based on historical test statistics or engineering experience and can be adjusted according to the product stage. A first reliability score is obtained through a weighted summation method. This score characterizes the overall reliability of the testing platform's software environment and serves as the basis for subsequent adaptive test cycle calculations and target restart strategy selection. The first reliability score is obtained by weighted summation of each normalized indicator and its corresponding weight. This first reliability score characterizes the overall reliability of the testing platform's software environment and serves as the input parameter for determining the number of adaptive test cycles and selecting the target restart strategy.

[0039] Specifically, historical test data, product stage data, customer site failure data, and review data are selected as the primary sources of reliability input because the reliability of the test platform is not only affected by its real-time operating status during the current testing process, but also closely related to its stability performance under different life cycle stages, different deployment environments, and different quality assessment systems. Historical test data is used to characterize the operational stability of the test platform during repeated server restart tests, reflecting its real-time execution reliability when actually performing test tasks, avoiding the problem of insensitivity to changes in operational status caused by relying solely on static configuration parameters; product stage data is used to introduce the differentiated stability characteristics of the test platform at different product lifecycle stages, enabling reliability assessment to adapt to different maturity conditions such as engineering verification, production verification, and mass production stages, thereby reducing evaluation bias caused by relying solely on short-term historical test data; customer field failure data is used to supplement the abnormal performance of the test platform in real deployment environments, covering operational differences between laboratory and field environments, and improving the robustness of reliability assessment to complex external factors; review data is used to introduce structured evaluation information based on the engineering quality system, to compensate for the inadequacy of pure operational data in covering dimensions such as process standardization, test coverage, and defect detection capabilities, thereby improving the completeness of the first reliability rating in representing the overall capabilities of the test platform. By uniformly quantifying and fusing the aforementioned multi-source heterogeneous data, the first reliability can simultaneously reflect the comprehensive performance of the test platform in multiple dimensions, such as operational stability, lifecycle stability, field environment stability, and engineering quality stability. This avoids the bias in evaluation caused by a single data source and improves the comprehensiveness and robustness of the test platform reliability assessment results.

[0040] Optionally, in one possible implementation, the calculation of the second reliability includes:

[0041] (1) Obtain historical fault data and evaluation data for each hardware component.

[0042] Specifically, the server under test includes multiple key hardware components supporting its operation, such as a central processing unit (CPU), memory modules, storage devices, power supply modules, PCIe expansion cards, and cooling fans. These components collectively form the hardware foundation for the server's operation. The total number of runs for each hardware component is pre-configured based on its type; for example, the CPU uses test cycles, storage devices use I / O cycles, and the power supply module uses power-on cycles. Historical fault data characterizes the actual failures of each hardware component during historical operation or testing, including the number of failures, failure types, failure times, and failure recovery records. For example, for storage devices, the number of read / write failures or unrecoverable errors during historical testing can be counted. Evaluation data characterizes the reliability evaluation results of each hardware component during the design verification or quality review phase. This evaluation data comes from design verification test results, supplier quality ratings, and engineering experience evaluations; for example, a comprehensive evaluation value can be formed based on the power supply module's output stability and overload capacity. Through this method, unified collection of operational and evaluation data for each hardware component is achieved, providing fundamental data support for subsequent reliability calculations.

[0043] (2) Determine the historical failure rate of the corresponding hardware component based on the historical failure data of each hardware component, and determine the evaluation score of the corresponding hardware component based on the evaluation data.

[0044] Specifically, to achieve a unified representation of reliability levels across different types of hardware components, raw data is converted into standardized evaluation metrics. Historical failure rate is used to characterize the probability of failure of a single hardware component during historical operation. It is calculated by dividing the number of failures by the total number of runs within a preset statistical period. For example, if a central processing unit experiences 5 anomalies in 1000 test cycles, its historical failure rate is 0.005. The statistical benchmark for the number of runs can differ for different hardware components: storage devices use the number of input / output operations or test cycles; power modules use power-on cycles or load switching cycles; and memory modules use read / write test rounds. Evaluation score is used to characterize the overall reliability level of hardware components during the design or review phase. It is obtained by normalizing indicators such as supplier quality level, design redundancy, and test pass rate, and mapping them to a unified numerical range. Through the above processing, data from different sources and with different dimensions are converted into standardized metrics with a unified scale.

[0045] (3) Based on the historical failure rate and the evaluation score, determine the component reliability value corresponding to each hardware component.

[0046] Specifically, for each hardware component, a component reliability value is introduced to characterize the reliability level of that component. For the first... Each hardware component, its component reliability value The following method is used to determine: ,in The inverse score is based on the historical failure rate and is obtained by subtracting the failure rate from 1 or by normalization mapping. The lower the failure rate, the higher the score. To evaluate the normalization results of the scores; and Let be the weight coefficient, and satisfy... The weighting coefficients can be determined based on historical failure contribution statistics and can be adjusted according to the product stage. In some implementations, It can be greater than For example, μ=0.6 and ν=0.4 are used to increase the weight of historical operating data in reliability evaluation. Through this method, each hardware component is uniformly mapped to a comparable component reliability value.

[0047] (4) Based on the reliability values ​​of each component and their corresponding weights, the reliability values ​​of each component are weighted and calculated to obtain the second reliability.

[0048] Specifically, the second reliability metric characterizes the overall reliability level of the server's hardware, and is obtained by weighted aggregation of the reliability values ​​of each hardware component. The weights are set based on historical test statistics or experience and can be adjusted according to the product stage. For example, different hardware components are assigned corresponding weights based on their functional importance in the server system; for instance, the CPU and power module, as core components, are given higher weights, memory modules and storage devices are given medium weights, and PCIe expansion cards and cooling fans are given lower weights. Second Reliability The calculation formula is: ,in For the second level of reliability, For the first The component reliability value of each hardware component. For the corresponding weight and satisfying Through the above weighted calculation, the reliability information of multiple hardware components is uniformly mapped to a single reliability index to characterize the overall reliability level of the server hardware layer.

[0049] Specifically, server hardware reliability is broken down into multiple key hardware components and modeled separately, rather than being directly characterized by the overall hardware failure rate. This is because different hardware components play significantly different functional roles and have different failure impact paths within the server system. For example, the CPU and memory modules primarily affect computing and data processing capabilities, belonging to the core computing link; storage devices primarily affect data persistence and read / write reliability, belonging to the storage link; power modules and cooling fans primarily affect power supply stability and thermal management capabilities, belonging to the basic operational support link; and PCIe expansion cards primarily affect peripheral expansion and high-speed communication capabilities, belonging to the I / O expansion link. The failure modes and system impact levels of different links are fundamentally different. If only a uniform overall failure rate is used for characterization, it will be impossible to distinguish the different impacts of key component failures and non-key component failures on system reliability, thus reducing the discriminative power and decision-making accuracy of reliability assessment. Therefore, this application constructs component reliability values ​​separately for different types of hardware components and introduces a weighted aggregation method based on functional importance. This makes the impact weight of key hardware components on the second reliability level higher than that of non-key components, thereby more accurately reflecting the overall reliability level of the server under different hardware failure scenarios. By adopting the above-mentioned hierarchical modeling approach, the second reliability can not only reflect the overall hardware failure level, but also reflect the differentiated risk contribution of different hardware subsystems, thereby improving the sensitivity and accuracy of expressing the reliability changes of complex hardware systems.

[0050] S102. Calculate the number of adaptive test cycles for the server under test based on the product of the first reliability and the second reliability with their corresponding weights. The number of adaptive test cycles for different servers under test is not exactly the same.

[0051] Specifically, the adaptive test lap count is used to characterize the number of restart tests required to be performed on the corresponding server under test. In this application, the test lap count is not configured in a fixed way, but is dynamically determined based on the first reliability and the second reliability. Since different test platform environments and different reliability levels of the servers under test vary, the adaptive test lap count for different servers under test can change dynamically.

[0052] Optionally, in one possible implementation, the method for calculating the number of adaptive test cycles includes: performing a weighted operation on the first reliability and the second reliability with their corresponding weights to obtain an influence factor that characterizes the degree of influence of reliability, wherein the influence factor has a negative correlation with both the first reliability and the second reliability.

[0053] Specifically, an intermediate parameter, called the influence factor, is established to map the first and second reliability levels to the number of test cycles. The influence factor characterizes the combined impact of the first and second reliability levels on the restart test intensity, serving as a bridge between the reliability assessment system and the test cycle number decision system. By introducing the influence factor, reliability information from different sources can be uniformly mapped to a single test intensity adjustment parameter, thereby avoiding the parameter coupling problem caused by multiple dimensions of reliability participating separately in the cycle number decision, and improving the consistency and interpretability of the subsequent test cycle number determination process.

[0054] Specifically, corresponding weight parameters are configured for the first reliability and the second reliability. The weight corresponding to the first reliability reflects the impact of the test platform's reliability on the test intensity, and the weight corresponding to the second reliability reflects the impact of the server hardware reliability on the test intensity. The sum of the two weights is 1. In one implementation, the influence factor F is obtained through a weighted calculation, specifically expressed as follows:

[0055] ;

[0056] in, For the highest reliability, For the second level of reliability, and These are the corresponding weights, and they satisfy... , This represents the influence factor. As shown in the above relationships, the influence factor is negatively correlated with both the first and second reliability levels; that is, when the first or second reliability level increases, the influence factor decreases; when the first or second reliability level decreases, the influence factor increases. In other words, the more reliable the test platform and the more reliable the server hardware components, the lower the required restart test intensity; conversely, for test platforms or servers with lower reliability, the test intensity needs to be increased to increase the probability of exposing potential faults.

[0057] Specifically, the weighting parameters corresponding to the first and second reliability can be configured according to the actual testing scenario. For example, during the R&D verification phase, the weight of the second reliability can be appropriately increased to enhance the testing intensity of hardware component stability; during the mass production testing phase, the weight of the first reliability can be appropriately increased to balance the impact of the test platform's stability on the overall test results. With both the first and second reliability values ​​normalized, the influence factor can range from 0 to 1. When both the first and second reliability are high, the influence factor value is small, corresponding to lower testing intensity; when either the first or second reliability is low, the influence factor value is large, corresponding to higher testing intensity.

[0058] It should be noted that the impact factor itself does not directly participate in the restart test execution process. Instead, it serves as an intermediate parameter between the reliability system and the test cycle system, used to characterize the degree of influence of reliability on test intensity, and as an input parameter for the subsequent adaptive test cycle determination process.

[0059] Optionally, in one possible implementation, the method for calculating the adaptive test lap count further includes:

[0060] (1) Calculate the initial adaptive test number of laps based on the preset base number of laps and the influence factor.

[0061] Specifically, after obtaining the impact factor, it is necessary to further determine the corresponding test intensity based on the impact factor to form an initial adaptive test cycle number that matches the current reliability level. To this end, this application introduces a base cycle number as the benchmark number of restart tests and dynamically adjusts the test intensity in conjunction with the impact factor. The base cycle number characterizes the basic test intensity of the server under standard test conditions, and it can be preset according to the server product level, application scenario, historical testing experience, and reliability requirements. For example, a lower base cycle number can be set for entry-level servers; a medium base cycle number can be set for enterprise-level servers; and a higher base cycle number can be set for servers used in high-reliability or high-load scenarios. In some implementations, the base cycle number can also be dynamically determined based on historical test data. For example, the distribution of fault exposure cycles for different server categories during historical testing can be statistically analyzed, and the base cycle number for the corresponding server category can be determined based on the statistical results. Specifically, the test cycle number corresponding to the first occurrence of a critical fault in historical testing can be used as reference data, and statistical analysis can be performed on multiple historical test samples to determine the basic test intensity for the corresponding server category. Critical faults are at least one of a preset set of fault categories, such as inability to start, system crash, or data corruption. In some implementations, the base number of cycles can be determined using quantile values. For example, the 70th, 75th, or 80th percentile of the historical fault exposure cycle distribution can be selected as the base number of cycles for the corresponding server category, so that the base number of cycles better matches the actual engineering testing requirements.

[0062] Furthermore, after obtaining the base number of test cycles and the influence factor, the initial adaptive test cycle number can be determined based on the correspondence between the two. Specifically, the influence factor characterizes the level of test intensity required under the current reliability conditions. Therefore, a larger influence factor indicates a relatively low current reliability level, requiring increased test intensity; a smaller influence factor indicates a higher current reliability level, allowing for a more appropriate reduction in test intensity. This is because servers or test platforms with lower reliability are more prone to potential anomalies, necessitating an increase in the number of tests to improve the probability of fault exposure. Therefore, the initial adaptive test cycle number can be determined based on the combination of the base number of test cycles and the influence factor. For example, a multiplicative approach can be used to scale the base test intensity to the reliability adjustment factor, allowing the initial adaptive test cycle number to dynamically adjust as the reliability level changes.

[0063] By using the above methods, the testing intensity can be dynamically adjusted according to the current reliability level, thereby avoiding the waste of testing resources or insufficient testing caused by using a fixed number of test cycles.

[0064] (2) Compare the initial adaptive test lap number with the preset minimum lap number and the preset maximum lap number, and perform interval constraint processing based on the comparison result to obtain the adaptive test lap number.

[0065] Specifically, since the initial adaptive test cycle count is a theoretical value dynamically calculated based on reliability, in some extreme cases, the number of test cycles may be too low or too high. For example, when both the first and second reliability are high, the influence factor may be small, resulting in an excessively low initial adaptive test cycle count. If the test cycle count is too low, it may not adequately cover potential anomalies during server restart, leading to statistically insignificant test results. Conversely, when both the first and second reliability are low, the influence factor may be large, resulting in an excessively high initial adaptive test cycle count. If the test cycle count is too high, it may lead to excessively long test cycles, excessive test resource consumption, or even exceed the actual engineering execution range. To avoid these problems, this application introduces an interval constraint processing mechanism, which limits the range of the initial adaptive test cycle count by setting a minimum and a maximum number of cycles.

[0066] Specifically, the preset minimum number of laps ensures the testing process has basic fault exposure capabilities and statistical validity; the preset maximum number of laps ensures the testing process is feasible in terms of time cost, resource consumption, and engineering implementation. Specifically, the preset minimum number of laps can be determined based on the minimum number of tests required to expose a fault in historical testing. For example, the minimum number of tests required to successfully expose the target fault in historical testing can be statistically analyzed, and the preset minimum number of laps can be determined based on the statistical results to ensure the test has basic fault detection capabilities. The preset maximum number of laps can be determined based on test resource limitations, test cycle requirements, and device concurrency capabilities. For example, the corresponding preset maximum number of laps can be determined based on the maximum test time allowed per server, the number of concurrent tests that the test platform can support simultaneously, and the preset delivery cycle.

[0067] Specifically, in some implementations, the initial adaptive test lap count can be compared with a preset minimum lap count. If the initial adaptive test lap count is less than the preset minimum lap count, the preset minimum lap count is used as the final adaptive test lap count; if the initial adaptive test lap count is greater than the preset maximum lap count, the preset maximum lap count is used as the final adaptive test lap count; if the initial adaptive test lap count is between the two, the corresponding initial adaptive test lap count is directly used as the final adaptive test lap count. In some implementations, for initial adaptive test lap counts within a reasonable range, further rounding can be performed to facilitate actual test execution. For example, rounding up, rounding down, or rounding to the nearest whole number can be used to obtain the final adaptive test lap count.

[0068] By using the above interval constraint processing, the final number of adaptive test cycles is always kept within a reasonable engineering range, thus balancing test sufficiency and test execution efficiency. This avoids the problem of potential faults not being exposed due to insufficient test intensity, while also avoiding the problem of test resource waste and excessively long test cycles due to excessive test intensity.

[0069] Optionally, in one possible implementation, after obtaining the adaptive test lap count, the method further includes:

[0070] (1) Based on the server category corresponding to the server to be tested, determine the reference maximum number of laps for the corresponding category.

[0071] Specifically, different types of servers differ in application scenarios, workloads, reliability requirements, and testing resource investment, thus their corresponding testing intensity requirements are not entirely the same. To ensure that the adaptive test cycle count can adapt to the actual testing needs of different types of servers, server categories and corresponding maximum reference cycle counts are introduced. Server categories can be divided according to the server's application purpose, hardware configuration scale, or business positioning. For example, they can be divided into general-purpose computing servers, storage servers, AI training servers, edge computing servers, and high-reliability business servers. Among them, AI training servers typically require long-term high-load operation and have high stability requirements; storage servers focus more on data read / write stability and continuous operation capabilities; and edge computing servers focus more on environmental adaptability and deployment flexibility.

[0072] Specifically, the reference maximum lap count characterizes the maximum allowable test intensity range for a particular server category under standard test conditions. It can be determined based on historical test data, industry standards, product reliability goals, or engineering experience. For example, the distribution of test lap counts corresponding to critical failures exposed during historical testing of a particular server category can be statistically analyzed, and the reference maximum lap count can be determined based on the statistical results. Alternatively, the reference maximum lap count for a specific category can be pre-configured in conjunction with product quality goals. In some implementations, the reference maximum lap counts corresponding to different server categories can be pre-stored in a category configuration table or test strategy database. For example, AI training servers may correspond to a higher reference maximum lap count, general-purpose computing servers to a medium reference maximum lap count, and edge computing servers to a relatively lower reference maximum lap count.

[0073] Specifically, after obtaining the server to be tested, you can first identify its server category, and then query the corresponding maximum reference number of laps based on the server category, which can be used as a reference benchmark for the subsequent lap number correction process.

[0074] (2) Determine the corresponding limit coefficient based on the ratio between the actual maximum number of laps of the current server under test and the reference maximum number of laps.

[0075] Specifically, even within the same server category, the testing requirements for different servers under test may still differ. For example, within the same server category, some servers may be used for core business scenarios, requiring more intensive testing; while others may be used for ordinary business scenarios, with relatively lower testing requirements. Therefore, based on server category, the actual maximum number of loops is further introduced to reflect the individualized testing requirements of the server under test.

[0076] Specifically, the actual maximum number of loops can be determined based on the current server's business importance, deployment scenario, customer testing requirements, historical operational stability, or quality level. For example, a higher actual maximum number of loops can be set for servers undertaking critical business operations; a relatively lower actual maximum number of loops can be set for servers with lower testing risks or less business impact. In some implementations, the actual maximum number of loops is set within a preset range, for example, not exceeding twice the reference maximum number of loops for that category. The limiting factor is used to characterize the degree of deviation between the current server's actual testing requirements and the standard testing requirements of its category, and it can be determined based on the proportional relationship between the actual maximum number of loops and the reference maximum number of loops. In some implementations, the limiting factor can be determined using the following relationship:

[0077] ;

[0078] in, As a limiting factor, This represents the actual maximum number of laps for the current server being tested. This represents the reference maximum number of laps for this server category. When the actual maximum number of laps is greater than the reference maximum number of laps, the limitation coefficient is greater than 1, indicating that the current server requires a higher testing intensity than the category standard; when the actual maximum number of laps is less than the reference maximum number of laps, the limitation coefficient is less than 1, indicating that the current server can appropriately reduce the testing intensity; when both are equal, the limitation coefficient is equal to 1, indicating that the current server adopts the standard testing intensity corresponding to this category. This method allows for differentiated testing configurations within the same server category based on the actual needs of different servers.

[0079] (3) Based on the constraint coefficient, the number of adaptive test cycles after interval constraint processing is corrected to obtain the final number of adaptive test cycles.

[0080] Specifically, after obtaining the adaptive test lap count after interval constraint processing, the test lap count is further adjusted based on a constraint coefficient to form the final adaptive test lap count. The adaptive test lap count after interval constraint processing is used to ensure that the test lap count is within a reasonable engineering range, while the constraint coefficient is used to further reflect differences in server categories and individualized testing needs. Therefore, by introducing a constraint coefficient, more refined adjustment of test intensity can be achieved while ensuring the reasonableness of the test lap count.

[0081] Specifically, the number of adaptive test cycles after interval constraint processing is multiplied by the constraint coefficient to obtain the final number of adaptive test cycles. Specifically, when the constraint coefficient is greater than 1, the final number of adaptive test cycles increases accordingly to improve test intensity; when the constraint coefficient is less than 1, the final number of adaptive test cycles decreases accordingly to reduce test resource consumption; when the constraint coefficient is equal to 1, the original number of test cycles remains unchanged. For example, for an AI training server, the number of adaptive test cycles after interval constraint processing is 3000, the reference maximum number of cycles for its server category is 8000, and the actual maximum number of cycles determined by the current server according to business requirements is 10000. In this case, the constraint coefficient is 1.25, and the final number of adaptive test cycles can be further increased to meet more stringent stability verification requirements.

[0082] It should be noted that categorized dynamic correction is a further optimization process performed after the basic adaptive test lap count is determined. Its purpose is to achieve a balance between "unified rules at the category level" and "individual server-specific needs." By introducing server categories, reference maximum lap counts, and constraint coefficients, a unified mapping between category-level test intensity benchmarks and individual server differences is achieved, improving the adaptability of testing strategies and engineering consistency.

[0083] Optionally, in one possible implementation, when the object to be tested includes multiple servers to be tested, the determination of the adaptive test lap number further includes:

[0084] (1) Based on the test task and server category of each server to be tested, determine the corresponding number of adaptive test cycles.

[0085] Specifically, when the test object includes multiple servers, the corresponding adaptive test lap count needs to be determined for each server. Different servers may correspond to different test tasks or belong to different server categories, so the corresponding test intensity requirements may differ.

[0086] Specifically, for each server under test, the first step is to obtain its corresponding test task information and server category. Test tasks can include various types of tests such as CPU stress testing, memory stability testing, hard disk read / write testing, PCIe link stability testing, power cycle testing, and overall system aging testing. Server categories can be divided according to the server's application, hardware configuration, or business positioning, such as general-purpose computing servers, AI training servers, storage servers, and edge computing servers.

[0087] Specifically, different tasks under test correspond to different stability verification objectives, and therefore the corresponding test intensity parameters can also differ. For example, power cycle testing typically requires a high restart impact intensity, thus requiring a higher base number of cycles or a higher maximum number of cycles constraint; PCIe link stability testing typically requires more repeated restart processes to verify link recovery capability, thus requiring a higher test cycle correction factor; and general functional verification testing has relatively low test intensity requirements, thus requiring a lower base number of cycles configuration. Furthermore, different server categories may correspond to different business scenarios and reliability requirements, thus requiring different category rule parameters. For example, AI training servers typically have higher reliability requirements, so their reference maximum number of cycles, upper limit of interval constraints, and limit coefficient thresholds can be set higher; general computing servers have relatively moderate test intensity requirements, so their corresponding cycle limit parameters can be appropriately reduced.

[0088] Specifically, when determining the number of adaptive test cycles, the number of adaptive test cycles for each server under test can be determined by combining the test intensity parameters corresponding to the task under test, the category rule parameters corresponding to the server category, and the first and second reliability of the corresponding server, following the adaptive test cycle calculation process determined in the aforementioned embodiments. Since the task types, category rules, hardware reliability, and test platform states of different servers under test may differ, the final number of adaptive test cycles may vary even using the same calculation process. For example, an AI training server, due to its high-load training tasks and historically high failure rate, may have a relatively high number of adaptive test cycles; while a general-purpose computing server, due to its high overall reliability and only performing ordinary functional verification tasks, may have a relatively low number of adaptive test cycles.

[0089] The above method enables differentiated test configurations based on task requirements, server type, and reliability status in multi-server scenarios, thereby embodying the adaptive testing concept of "one policy per server".

[0090] (2) For servers under test within the same server category, the corresponding adaptive test cycle number is determined using shared category parameters.

[0091] Specifically, to improve test configuration efficiency in multi-server scenarios and ensure consistency of test rules for servers of the same category, shared category parameters can be used to determine the corresponding adaptive test lap count for servers belonging to the same server category. Category parameters characterize the general test rules for the corresponding server category and may include parameters such as the reference maximum lap count, default category weight, constraint coefficient calculation rules, interval constraint thresholds, and test intensity levels. In some implementations, category parameters can be determined based on historical test data, fault exposure patterns, reliability level requirements, and engineering testing experience for the corresponding server category. For example, the distribution of test lap counts when a critical fault is first exposed during historical testing for the corresponding server category can be statistically analyzed, and the reference maximum lap count and interval constraint threshold for the corresponding category can be determined based on the statistical results. These category parameters can be pre-configured and stored in a category configuration table, test strategy database, or test rule template for use by servers of the same category in subsequent adaptive test lap count calculations.

[0092] Specifically, when multiple servers under test are identified as belonging to the same server category, the shared parameters of the corresponding category can be directly invoked to participate in the determination of the adaptive test lap number, without the need to configure complete category parameters for each server separately. For example, for multiple servers under test belonging to the "AI training server" category, the reference maximum lap number and limit coefficient rules corresponding to that category can be uniformly adopted; for multiple servers under test belonging to the "storage server" category, the corresponding data stability test parameters can be uniformly adopted.

[0093] It's important to note that sharing category parameters does not mean that all servers under test within the same category will have the same final adaptive test lap count. Because the first reliability, second reliability, and test tasks may differ for each server, even using the same category parameters, the final adaptive test lap count may still vary between servers. In other words, what is shared is the test rules and category baseline, not the final test results. This sharing mechanism ensures consistency in testing servers within the same category while reducing redundant configuration work and improving test management efficiency in multi-server batch testing scenarios.

[0094] (3) When the same server under test corresponds to multiple tasks under test, the adaptive test lap numbers corresponding to the multiple tasks under test are averaged and fused to obtain the final adaptive test lap number corresponding to the server under test.

[0095] Specifically, the same server under test may simultaneously correspond to multiple test tasks. For example, the same server may need to perform CPU stress testing, memory stability testing, and hard disk read / write testing. Since the stability verification objectives corresponding to different test tasks are different, their corresponding adaptive test lap counts may also be different. In this case, the adaptive test lap count corresponding to each test task can be determined separately according to the method in the aforementioned embodiments. For example, the CPU stress test lap count for a certain server is 500 laps, the memory stability test lap count is 300 laps, and the hard disk read / write test lap count is 400 laps. Subsequently, the adaptive test lap counts corresponding to multiple test tasks are merged to obtain the final adaptive test lap count corresponding to the server under test.

[0096] Specifically, in some implementations, an average fusion method can be used, which involves averaging the adaptive test cycles corresponding to multiple tasks under test. For example, for the three test tasks mentioned above, the final merged adaptive test cycle count could be: (500 + 300 + 400) / 3 = 400 cycles. The average fusion method can achieve a balance in test intensity among different test tasks, avoiding excessive overall test resource consumption due to an excessively high cycle count for a single task, while also preventing insufficient overall testing due to a single low-intensity task. In some implementations, other fusion methods can also be used according to actual needs. For example, for test tasks related to critical business operations, a maximum value fusion method can be used to ensure that critical tasks receive sufficient test intensity; for scenarios with limited test resources, a minimum value fusion method can be used to prioritize shortening the test cycle; alternatively, corresponding fusion weights can be configured according to the importance of the tasks, and a weighted average method can be used to determine the final adaptive test cycle count.

[0097] By integrating multiple tasks as described above, multiple test requirements corresponding to the same server under test can be unified into a single executable final test cycle, avoiding the redundant resource consumption and time overhead caused by executing independent restart tests for different tasks, thereby improving test execution efficiency in complex test scenarios.

[0098] It should be noted that the multi-server task fusion mechanism in this embodiment is a further extension of the basic adaptive test cycle determination method, which is applicable to complex test scenarios such as multiple servers and multiple tasks; for single-server single-task scenarios, the adaptive test cycle determined in the aforementioned embodiment can be used directly to execute the corresponding test.

[0099] S103. Determine the target restart strategy based on the first reliability and the second reliability.

[0100] Specifically, the target restart strategy is used to characterize the restart method adopted by the server under test. Different restart methods correspond to different system recovery depths and different test coverage. Therefore, this application dynamically determines the corresponding target restart strategy based on the first reliability and the second reliability, so that the server under test in different reliability states can perform the corresponding test tasks using a restart method that matches the current risk level.

[0101] Optionally, in one possible implementation, the determination of the target restart strategy includes:

[0102] (1) Compare the first reliability and the second reliability with the corresponding thresholds respectively, and determine the corresponding target restart strategy based on the comparison results.

[0103] Specifically, different restart strategies correspond to different system impact intensities, and the types of faults they can expose and their applicable scenarios also differ. Therefore, differentiated selection is required based on the evaluation results of the first reliability and the second reliability. The first reliability is used to characterize the reliability level of the test platform, and the second reliability is used to characterize the reliability level of the server hardware. Since the stability of the test platform and the stability of the server hardware correspond to different types of risk sources, corresponding thresholds need to be set for judgment. The first reliability corresponds to the first threshold, and the second reliability corresponds to the second threshold. The first and second thresholds can be preset based on historical test data statistics, engineering experience, product reliability requirements, or industry standards; for example, they can be set to 0.8. In some implementations, the thresholds can also be dynamically adjusted according to the server type, test stage, or business importance. For example, the threshold requirement can be appropriately increased for AI training servers, and the threshold requirement can be appropriately decreased for ordinary functional verification scenarios.

[0104] Furthermore, the first reliability is compared with the first threshold, and the second reliability is compared with the second threshold. Based on the comparison results, the corresponding target restart strategy is determined. The target restart strategies include three types: soft restart, cold restart, and power cycle restart, corresponding to low, medium, and high impact levels, respectively. Through this method, a mapping relationship between reliability status and restart strategy is established, allowing different risk levels to correspond to different test intensities.

[0105] (2) Wherein, when the second reliability is lower than the corresponding threshold, the target restart strategy is determined to be power cycle restart.

[0106] Specifically, when the second reliability is lower than the second threshold, it indicates that the overall reliability of the server's hardware is low, and key hardware components in the server have a high potential risk of failure. In this case, the restart method with the highest impact intensity needs to be used to fully expose potential hardware anomalies. Power cycle restart refers to a restart method in which the server is completely powered off and then powered on again through the power control module. During this process, the server undergoes a complete power outage, power restoration, motherboard re-initialization, and hardware re-enumeration process, which can additionally verify hardware-related functions such as power module stability, motherboard power-on timing, PCIe device re-enumeration, storage device power-off recovery capability, and memory retraining process. Therefore, when the second reliability is lower than the corresponding threshold, regardless of the level of the first reliability, power cycle restart is preferred to improve the exposure capability of potential hardware failures. In some implementations, the power-off waiting time can be further extended, for example from 5 seconds to 30 seconds, to simulate a complete power outage scenario in the actual field.

[0107] (3) When the second reliability is not lower than the corresponding threshold and the first reliability is lower than the corresponding threshold, the target restart strategy is determined to be a cold restart.

[0108] Specifically, when the second reliability is not lower than the second threshold, but the first reliability is lower than the first threshold, a cold reboot is adopted as the target reboot strategy. A low first reliability usually means that the test platform has a high failure rate in historical testing, such as test process interruption, control anomalies, log collection anomalies, or insufficient stability of automated execution. In this case, if power cycle reboot is continued, additional misjudgments may be introduced due to the instability of the test platform itself. A cold reboot refers to triggering a system reset through the motherboard control logic or baseboard management controller, causing the server to re-execute the hardware initialization and startup process, but without performing a complete power-off operation. A cold reboot usually triggers processes such as BIOS reloading, CPU re-initialization, memory retraining, PCIe link re-establishment, and firmware reboot, which can effectively verify the stability of the server under hardware reset scenarios, while avoiding the excessive impact of power cycle reboot. Compared with power cycle reboot, cold reboot has a shorter execution time and lower hardware impact, which can improve test efficiency while ensuring test effectiveness.

[0109] (4) When both the first reliability and the second reliability are not lower than the corresponding threshold, the target restart strategy is determined to be a soft restart.

[0110] Specifically, when the first reliability is not lower than the first threshold and the second reliability is not lower than the second threshold, it indicates that both the test platform and server hardware are in a high reliability state, the overall risk level of the server is low, and there is no need to adopt a high-impact testing strategy. Stability verification can be completed using a soft reboot. A soft reboot refers to triggering a server restart through a restart command at the operating system level, such as executing the reboot command through the operating system or triggering a system restart through the system management interface. Soft reboots typically do not trigger a complete power outage process. They mainly verify the stability of software-level aspects such as the ability of operating system services to shut down and resume, the ability of drivers to reload, the ability of system processes to resume, the ability of file systems to remount, and the ability of network services to resume. Because soft reboots do not involve a complete hardware power outage, they have higher execution efficiency and less impact on hardware, making them more suitable for large-scale stability verification in high-reliability scenarios. They can effectively reduce hardware wear and tear during testing and improve overall test throughput efficiency.

[0111] The aforementioned restart strategy mapping mechanism based on reliability thresholds achieves dynamic matching between different risk levels and different test intensities: the higher the hardware risk, the more stringent the corresponding restart strategy; the higher the overall reliability, the more lenient the corresponding restart strategy. By incorporating both primary and secondary reliability into the restart strategy decision-making process, not only can the exposure capability of potential faults be improved, but also the waste of test resources and additional hardware wear caused by uniformly adopting high-intensity restart methods can be avoided, thereby achieving a more reasonable and efficient server restart testing process.

[0112] S104. Perform a restart test on the server according to the adaptive test cycle number and the target restart strategy.

[0113] Specifically, the testing system performs restart tests on the server under test according to the corresponding test parameters. The adaptive test lap count represents the number of restarts required for the current server under test, and the target restart strategy represents the corresponding restart execution method.

[0114] Specifically, before the test begins, the test system first establishes a communication connection with the server under test. This communication connection can be established through the baseboard management controller interface, intelligent platform management interface, Redfish interface, secure shell protocol interface, or operating system remote management interface, and is used to send restart control commands to the server under test and obtain running status information.

[0115] Furthermore, the corresponding restart execution method is selected based on the target restart strategy. When the target restart strategy is a soft restart, the test system triggers the server restart through operating system commands, such as executing the reboot command, shutdown command, or calling the system management interface to complete the restart operation. During this process, the server mainly performs the operating system-level shutdown and restart process. When the target restart strategy is a cold restart, the test system triggers a system reset through the baseboard management controller control logic or motherboard reset control logic, causing the server to re-execute the hardware initialization process, including reloading the BIOS, re-initializing the CPU and memory, and re-establishing the PCIe link connection. When the target restart strategy is a power cycle restart, the test system controls the server to perform a complete power-off and power-on operation through the power management module. The server can be powered off first, and then power restored after a preset waiting time. The preset waiting time can be set according to the server type or test objective. For example, the power-off waiting time can be appropriately extended for high reliability verification scenarios.

[0116] Specifically, during each restart test, the test system monitors the server's startup process, including BIOS startup status, operating system startup status, CPU initialization status, memory training status, PCIe device enumeration status, storage device mounting status, network interface recovery status, and service process recovery status. The test system can collect the corresponding status information in real time through a log acquisition module, serial port output module, baseboard management controller status monitoring module, or operating system monitoring module.

[0117] Specifically, after the server completes a restart, the testing system records the test results, including the current test cycle number, current restart strategy, restart start time, restart completion time, startup time, whether the startup was successful, whether any abnormal interruptions occurred, whether any hardware failures occurred, whether any system errors occurred, and corresponding fault log information. The testing system can also classify anomalies that occur during the test, such as startup failures, BIOS freezes, PCIe link training failures, operating system crashes, storage device identification anomalies, network recovery failures, or power supply anomalies, and store the corresponding fault information in the test log database or fault analysis database.

[0118] Specifically, in some implementations, the current test task can be terminated early when a serious anomaly is detected during testing. For example, if multiple restarts fail, the server cannot come back online, or a critical hardware failure is detected, subsequent tests can be stopped and an anomaly alarm message can be output. In other implementations, the test can be allowed to continue and the frequency of anomalies can be counted to evaluate the server's stability performance under abnormal scenarios.

[0119] Specifically, after completing all restart tests for the corresponding adaptive test cycles, the test system generates corresponding test result information, including the actual number of test cycles completed, test success rate, average startup time, number of failures, failure type statistics, restart strategy execution results, and final stability assessment results.

[0120] The above method enables a server restart test execution process based on adaptive test cycles and a target restart strategy. This allows the test system to dynamically execute restart tests of appropriate intensity according to the actual reliability status of the server, thereby improving fault exposure capabilities and test resource utilization efficiency. The results recorded during test execution will serve as input data for subsequent reliability update steps.

[0121] Optionally, in one possible implementation, the method further includes incrementally updating the first reliability and the second reliability based on the adaptive restart test results; wherein:

[0122] (1) Construct a sliding window dataset based on historical restart test results.

[0123] Specifically, the first and second reliability levels are dynamically updated based on historical test results, forming a closed-loop testing mechanism of continuous learning and dynamic adjustment. To this end, a sliding window dataset is first constructed based on historical restart test results to store historical test result data within a preset time range or a preset quantity range, reflecting the recent operational status changes of the server and test platform.

[0124] Specifically, the sliding window dataset can include the following data: number of successful restart tests, number of failed restart tests, restart time information, startup exception records, fault log information, hardware failure events, test platform exception events, corresponding test timestamps, corresponding server categories, and corresponding restart policy types. The sliding window can be constructed using a "fixed time window" approach, such as only counting historical test results from the last 30, 60, or 90 days; or it can be constructed using a "fixed number window" approach, such as retaining only the results from the last 1000, 5000, or 10000 restart tests. When new test results are added to the sliding window dataset, the oldest historical data is simultaneously deleted, keeping the data size within the window relatively stable. Through this method, the reliability update process can effectively reflect the recent real-time operating status of the server and test platform, avoiding the excessive influence of premature historical data on the current reliability assessment.

[0125] (2) Update the first reliability based on the restart success results and failure results in the data set.

[0126] Specifically, the first reliability metric characterizes the overall reliability of the test platform. This first reliability metric is dynamically updated based on the successful restart results and failure results in the sliding window dataset. Specifically, the number of successful and failed restart tests performed by the test platform within the sliding window is counted, and the corresponding historical test failure rate of the test platform is recalculated. Failure results can include automated test process anomalies, log collection failures, test task interruptions, misjudgments of test results, control command sending failures, test platform communication anomalies, and test script execution anomalies, etc.

[0127] Specifically, updates can employ a quantification method based on the failure ratio. The number of abnormal events occurring on the test platform within a sliding window is counted, and the proportion of these abnormal events to the total number of tests is calculated. When this proportion exceeds a preset abnormality ratio threshold, the historical test failure rate index in the first reliability is adjusted downwards by a preset step size; when the abnormality ratio is lower than a preset normality ratio threshold, the historical test failure rate index is adjusted upwards. For continuous abnormalities, when a preset number of test platform abnormalities occur consecutively within the sliding window, the weight coefficient of the corresponding failure event can be increased, allowing the first reliability to reflect the declining trend in platform stability more quickly. For example, when the number of corresponding abnormal events occurring in a preset number of restart tests within the sliding window is lower than a preset abnormality number threshold, the first reliability can be gradually increased; when the number of corresponding abnormal events occurring within the sliding window is higher than the preset abnormality number threshold, or when a preset number of consecutive test interruptions, test misjudgments, or communication anomalies occur, the first reliability is decreased. In some implementations, the preset abnormality number threshold and the consecutive abnormality number threshold can be preset based on historical test statistics, test platform stability requirements, and engineering experience. For example, the average number of abnormal events occurring on the test platform during historical testing can be statistically analyzed, and a corresponding threshold can be determined based on the statistical results. Alternatively, the corresponding threshold can be dynamically configured according to different server types, testing phases, or reliability requirements. Through this dynamic update method, the primary reliability can continuously change with the actual operating status of the test platform, avoiding the evaluation distortion problem caused by using fixed reliability parameters for a long time.

[0128] (3) Update the component reliability value of the corresponding hardware component based on the restart success result, fault result and fault event of the corresponding hardware component in the data set, and update the second reliability based on the updated component reliability value.

[0129] Specifically, the second reliability is used to characterize the overall reliability at the server hardware level. It dynamically adjusts the component reliability value of the corresponding hardware component based on hardware failure events in the sliding window dataset. These hardware failure events can include CPU initialization failure, memory training failure, storage device disk failure, PCIe device enumeration failure, power supply abnormality, fan failure, network interface abnormality, BIOS boot failure, and firmware loading failure, among others.

[0130] Specifically, firstly, the number of failure events corresponding to each hardware component within the sliding window is counted, and the proportion of failure event occurrences to the total number of tests is calculated to obtain the failure percentage of the corresponding hardware component. When the failure percentage of a certain hardware component exceeds a preset failure percentage threshold, the component reliability value of that component is reduced accordingly; the reduction magnitude is related to the deviation of the failure percentage from the threshold, so as to achieve the adjustment effect that the more severe the failure, the more significant the decrease in reliability. In some implementations, for hardware components that have not experienced failures for a long period of time, if no failure events occur within a preset number of consecutive test cycles within the sliding window, the component reliability value of that component is gradually increased to reflect its stable operating state; the preset number of test cycles threshold can be set according to the length of historical test cycles or the test frequency. In some implementations, different types of hardware components can be configured with different failure percentage thresholds and adjustment sensitivities. For example, for critical components such as the central processing unit and power module, since they have a significant impact on the overall operation of the server, their failure percentage thresholds can be set to lower values ​​to increase the sensitivity to changes in their reliability; for non-critical components, their thresholds can be relatively increased to reduce the impact of occasional failures on the overall evaluation.

[0131] Furthermore, based on the updated reliability values ​​of each hardware component, the second reliability is recalculated according to a preset weighted aggregation rule. This dynamic update mechanism ensures that the second reliability continuously reflects changes in server hardware status based on historical test results, thereby improving the real-time performance and accuracy of the overall reliability assessment.

[0132] (4) Based on the updated first and second reliability, the number of adaptive test cycles for the corresponding server to be tested is re-determined.

[0133] Specifically, after the first and second reliability are updated, the adaptive test cycle number for the corresponding server under test is re-determined based on the updated reliability results. Specifically, the influencing factor calculation, basic cycle number calculation, interval constraint processing, and categorical dynamic correction process are re-executed to obtain the updated adaptive test cycle number. In some implementations, reliability updates can be performed at a preset cycle, such as daily or weekly; or updates can be triggered only when the change in the first or second reliability exceeds a preset threshold, to avoid frequent adjustments to test parameters due to minor fluctuations. In some implementations, the updated adaptive test cycle number is used for subsequent newly initiated restart test tasks, while the currently executing test task continues to execute with the test cycle number before the update, to avoid inconsistent test results caused by dynamic changes in the cycle number during the test process. For example, when the server completes a reliability update during a predetermined number of restart tests, the test task still executes with the original cycle number until completion, and the updated test cycle number only takes effect in the next round of test tasks.

[0134] Through the above mechanism, a closed-loop update is achieved between test results, reliability assessment and test strategy, enabling the system to continuously optimize test intensity configuration based on historical test results, thereby improving the adaptability and stability of long-term testing.

[0135] The server adaptive restart testing method provided in this application introduces a first reliability corresponding to the test platform's operating state and a second reliability corresponding to the server hardware component's operating state to achieve a joint reliability assessment of the server restart testing process. Based on this, the adaptive test cycle number and target restart strategy are determined collaboratively, enabling the test intensity to be dynamically adjusted according to changes in the test platform's state and hardware reliability level. This avoids the problem of unreasonable test intensity configuration in traditional fixed test cycle number and fixed restart strategy schemes, thereby improving the efficiency of test resource utilization and test targeting. Meanwhile, by weighting and fusing the first and second reliability scores to obtain an influence factor, and using this as an intermediate quantity for adjusting the number of test cycles, reliability information from different sources can have a comprehensive effect on test intensity under a unified scale, thereby enhancing the interpretability and consistency of test cycle adjustment. By introducing server category-differentiated parameters, different types of servers are differentiated in terms of cycle constraints and test intensity configuration, thereby improving the adaptability of the test strategy to different application scenarios. By establishing a restart strategy mapping relationship based on reliability threshold comparison, different reliability levels correspond to different impact levels of restart methods, thereby achieving a balance between fault exposure capability and test efficiency. Furthermore, through a sliding window-based incremental reliability update mechanism, the first and second reliability scores can be continuously iterated and updated with historical test results, thereby achieving a dynamic closed loop between the test process and evaluation results, improving the adaptability and evaluation accuracy in long-term testing. In summary, this application achieves synergistic linkage between test cycle determination and restart strategy selection, improving the flexibility, coverage, and engineering adaptability of server restart testing without additional hardware investment.

[0136] Corresponding to the aforementioned embodiment of a server adaptive restart test method, this application also provides an embodiment of a server adaptive restart test apparatus.

[0137] Figure 2 This is a schematic diagram of the structure of Embodiment 1 of the server adaptive restart test device provided in this application. Please refer to... Figure 2 The apparatus provided in this embodiment includes a determining module 201, a calculating module 202, and an execution module 203, wherein:

[0138] The determining module 201 is used to determine the first reliability of the test platform test software environment and the second reliability of the hardware components of the server under test;

[0139] The calculation module 202 is used to calculate the number of adaptive test cycles corresponding to the server under test based on the product of the first reliability and the second reliability with the corresponding weights. The number of adaptive test cycles for different servers under test is not exactly the same.

[0140] The calculation module 202 is used to determine a target restart strategy based on the first reliability and the second reliability;

[0141] The execution module 203 is used to perform a restart test on the server according to the adaptive test cycle number and the target restart strategy.

[0142] The apparatus of this embodiment can be used to perform... Figure 1 The steps of the method embodiment shown are similar in principle and process, and will not be repeated here.

[0143] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0144] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0145] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for server adaptive restart testing, the method comprising: include: Determine the primary reliability of the test platform's test software environment and the secondary reliability of the hardware components of the server under test; The number of adaptive test cycles for the server under test is calculated based on the product of the first reliability and the second reliability with their corresponding weights. The number of adaptive test cycles for different servers under test is not exactly the same. The target restart strategy is determined based on the first reliability and the second reliability. A restart test is performed on the server according to the adaptive test cycle number and the target restart strategy.

2. The method according to claim 1, characterized in that, When the test object includes multiple test servers, the determination of the adaptive test cycle number also includes: Based on the test task and server category of each server under test, determine the corresponding number of adaptive test cycles; For servers under test within the same server category, the corresponding adaptive test lap number is determined using shared category parameters; When the same server under test corresponds to multiple tasks under test, the adaptive test lap counts corresponding to the multiple tasks under test are averaged and fused to obtain the final adaptive test lap count corresponding to the server under test.

3. The method according to claim 1, characterized in that, The calculation of the first reliability includes: Acquire historical test data, product stage data, customer site failure data, and review data related to the test platform's operational status; The historical test failure rate is determined based on the historical test data, the corresponding stage score is determined based on the product stage data, the customer site failure rate is determined based on the customer site failure data, and the review score is determined based on the review data. The historical test failure rate, the stage score, the customer site failure rate, and the review score are normalized. The normalized evaluation index is weighted and calculated based on preset weights to obtain the first reliability.

4. The method according to claim 1, characterized in that, The calculation of the second reliability includes: Acquire historical fault data and evaluation data for each hardware component; The historical failure rate of each hardware component is determined based on the historical failure data of each hardware component, and the evaluation score of the corresponding hardware component is determined based on the evaluation data. Based on the historical failure rate and the evaluation score, the component reliability value corresponding to each hardware component is determined; Based on the reliability values ​​of each component and their corresponding weights, the reliability values ​​of each component are weighted and calculated to obtain the second reliability.

5. The method according to claim 1, characterized in that, The method for calculating the number of adaptive test cycles includes: performing a weighted operation on the first reliability and the second reliability with their corresponding weights to obtain an influence factor that characterizes the degree of influence of reliability, wherein the influence factor has a negative correlation with both the first reliability and the second reliability.

6. The method according to claim 5, characterized in that, The method for calculating the number of adaptive test laps also includes: Calculate the initial adaptive test lap number based on the preset base number of laps and the aforementioned influencing factor; The initial adaptive test lap count is compared with the preset minimum lap count and the preset maximum lap count, and interval constraint processing is performed based on the comparison result to obtain the adaptive test lap count.

7. The method according to claim 1, characterized in that, After obtaining the adaptive test lap count, the following is also included: Based on the server category corresponding to the server under test, determine the reference maximum number of laps for the corresponding category; The corresponding limitation coefficient is determined based on the ratio between the actual maximum number of laps of the current server under test and the reference maximum number of laps; The adaptive test lap count after interval constraint processing is corrected based on the aforementioned constraint coefficient to obtain the final adaptive test lap count.

8. The method according to claim 1, characterized in that, The target restart strategy includes: The first reliability and the second reliability are compared with the corresponding thresholds, and the corresponding target restart strategy is determined based on the comparison results. Wherein, when the second reliability is lower than the corresponding threshold, the target restart strategy is determined to be power cycle restart; When the second reliability is not lower than the corresponding threshold and the first reliability is lower than the corresponding threshold, the target restart strategy is determined to be a cold restart; When both the first reliability and the second reliability are not lower than the corresponding threshold, the target restart strategy is determined to be a soft restart.

9. The method according to claim 1, characterized in that, The method further includes: incrementally updating the first reliability and the second reliability based on the adaptive restart test results; wherein: A sliding window dataset was constructed based on historical restart test results; The first reliability is updated based on the restart success results and failure results in the data set; Based on the restart success results, failure results, and corresponding hardware component failure events in the data set, the component reliability value of the corresponding hardware component is updated, and the second reliability is updated based on the updated component reliability value. Based on the updated first and second reliability, the number of adaptive test cycles for the corresponding server under test is re-determined.

10. A server adaptive restart testing device, characterized in that, It includes a determination module, a calculation module, and an execution module, wherein: The determining module is used to determine the first reliability of the test platform test software environment and the second reliability of the hardware components of the server under test; The calculation module is used to calculate the number of adaptive test cycles corresponding to the server under test based on the product of the first reliability and the second reliability with the corresponding weights. The number of adaptive test cycles for different servers under test is not exactly the same. The calculation module is used to determine the target restart strategy based on the first reliability and the second reliability; The execution module is used to perform a restart test on the server according to the adaptive test cycle number and the target restart strategy.

Images