Server system testing method, storage medium, electronic device, and program product

Abstract

The present application discloses a testing method, storage medium, electronic device and program product for a server system, and relates to the field of computer technology, wherein the method comprises: first obtaining a device feature vector of the server system to be tested; then fuzzy matching the device feature vector with a feature description vector in a driver library that can be used to test the server system; if the match is successful, collecting the hardware feature parameters of the server system to be tested, and dynamically determining the test threshold of the hardware status of the server system to be tested based on the environmental parameters monitored in real time; then testing the hardware status of the server system to be tested based on the hardware feature parameters and the dynamically determined test threshold. Compared with the current related technologies, the present application realizes automatic identification and adaptation of hardware devices from multiple manufacturers, significantly reducing the time for manual intervention and the complexity of driver configuration, thereby reducing testing costs, improving testing efficiency, and improving the accuracy and flexibility of testing.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a data processing method, a storage medium, an electronic device, and a program product. Background Art

[0002] With the rapid development of information technology, data exchange through server systems has become a common business requirement. The performance, stability, and reliability of server systems are directly related to the normal operation of the business and user experience. Therefore, comprehensive testing of server systems is a key step in ensuring stable operation and performance compliance.

[0003] However, when faced with server hardware from different manufacturers and with different architectures, the relevant server system testing methods have poor compatibility and require a lot of manual adaptation work, which increases testing costs and time. Summary of the Invention

[0004] The present disclosure provides a server system testing method, storage medium, electronic device, and program product. Its main purpose is to address the problem of poor compatibility of server system testing methods in related technologies, requiring a large amount of manual adaptation work, and increasing testing costs and time.

[0005] In a first aspect, the present application provides a method for testing a server system, comprising:

[0006] Obtaining the device feature vector of the server system under test;

[0007] Perform fuzzy matching on the device feature vector and the feature description vector in the driver library that can be used for server system testing;

[0008] If the match is successful, the hardware characteristic parameters of the server system to be tested are collected, and the test threshold of the hardware status of the server system to be tested is dynamically determined based on the environmental parameters monitored in real time;

[0009] The hardware status of the server system to be tested is tested based on the hardware characteristic parameters and the dynamically determined test threshold.

[0010] In a second aspect, the present application provides a testing device for a server system, comprising:

[0011] an acquisition module, configured to acquire a device feature vector of the server system to be tested;

[0012] a matching module configured to perform fuzzy matching between the device feature vector and a feature description vector in a driver library that can be used for server system testing;

[0013] a determination module configured to collect hardware characteristic parameters of the server system to be tested if the match is successful, and dynamically determine a test threshold value of the hardware status of the server system to be tested based on the environmental parameters monitored in real time;

[0014] The testing module is configured to test the hardware status of the server system to be tested based on the hardware characteristic parameters and the dynamically determined test threshold.

[0015] In a third aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which implements the method of the first aspect when the computer program is executed by a processor.

[0016] In a fourth aspect, the present application provides an electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the method of the first aspect when executing the computer program.

[0017] In a fifth aspect, the present application provides a computer program product having a computer program stored thereon, which implements the method of the first aspect when the computer program is executed by a processor.

[0018] The present disclosure provides a testing method, storage medium, electronic device and program product for a server system, wherein the method comprises: first obtaining a device feature vector of the server system to be tested; then fuzzy matching the device feature vector with a feature description vector in a driver library that can be used for server system testing; if the match is successful, collecting the hardware feature parameters of the server system to be tested, and dynamically determining the test threshold of the hardware state of the server system to be tested based on the real-time monitored environmental parameters; then testing the hardware state of the server system to be tested based on the hardware feature parameters and the dynamically determined test threshold. Compared with the current related technologies, the present application realizes automatic identification and adaptation of hardware devices from multiple manufacturers by obtaining the device feature vector of the server system to be tested and fuzzy matching it with the feature description vector in the driver library, significantly reducing the time for manual intervention and the complexity of driver configuration, thereby reducing testing costs and improving testing efficiency. After the match is successful, the hardware feature parameters are collected and the test threshold is dynamically adjusted in combination with the real-time environmental parameters, so that the test strategy can adapt to the current hardware and environmental status, thereby improving the accuracy and flexibility of the test.

[0019] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present application, nor is it intended to limit the scope of the present application. Other features of the present application will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0021] Figure 1 A schematic diagram showing a flow chart of a method for testing a server system provided in an embodiment of the present application is shown;

[0022] Figure 2 A schematic diagram showing an example provided by an embodiment of the present application is shown;

[0023] Figure 3 A schematic diagram showing an example provided by an embodiment of the present application is shown;

[0024] Figure 4 A schematic diagram showing an example provided by an embodiment of the present application is shown;

[0025] Figure 5 A schematic diagram showing an example provided by an embodiment of the present application is shown;

[0026] Figure 6 A flow chart showing another method for testing a server system provided in an embodiment of the present application is shown;

[0027] Figure 7 A schematic diagram showing an example provided by an embodiment of the present application is shown;

[0028] Figure 8 A schematic diagram showing an example provided by an embodiment of the present application is shown;

[0029] Figure 9 A schematic structural diagram of a testing device for a server system provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0030] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0031] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0032] In order to improve the technical problem that the server system testing method in the related art has poor compatibility, requires a lot of manual adaptation work, and increases the testing cost and time. This embodiment provides a server system testing method, such as Figure 1 As shown, the method comprises the following steps:

[0033] Step 101: Obtain a device feature vector of the server system to be tested.

[0034] Exemplarily, the device feature vector of the server system under test can be obtained through information collection, where the device feature vector includes but is not limited to key hardware parameters such as CPU model, memory capacity and frequency, storage type and interface, and network card configuration.

[0035] For example, during the testing process, you can first collect detailed hardware parameters through the interface provided by the server system to be tested, including but not limited to the processor model and number of cores, memory capacity and speed, storage device type and its interface specifications, motherboard model, and the configuration of expansion cards (such as network cards and graphics cards).

[0036] Step 102: Perform fuzzy matching on the device feature vector and the feature description vector in the driver library that can be used for server system testing.

[0037] In some examples, by fuzzy matching the feature vectors of the device under test (including hardware model, interface type, performance parameters, etc.) with the feature description vectors pre-stored in the driver library that can be used for server system testing, automatic identification and adaptation of hardware devices from multiple manufacturers can be achieved, thereby effectively improving the compatibility and flexibility of the test system and reducing the adaptation difficulty and testing costs caused by device differences.

[0038] Step 103: If the match is successful, the hardware characteristic parameters of the server system to be tested are collected, and the test threshold of the hardware status of the server system to be tested is dynamically determined based on the environmental parameters monitored in real time.

[0039] For example, after a successful match, the system will collect the hardware characteristic parameters of the server under test and, combined with the real-time monitored environmental parameters (including temperature T, humidity H, and air pressure P), dynamically calculate the test threshold required for hardware status evaluation through the nonlinear mapping model in the adaptive test module. The model expression is:

[0040] (Formula 1)

[0041] The coefficient 、 、 The time constant τ is calibrated online through the gradient descent method to achieve real-time optimization and adjustment of the test threshold, thereby improving the accuracy and adaptability of server hardware status assessment.

[0042] Step 104: Test the hardware status of the server system to be tested based on the hardware characteristic parameters and the dynamically determined test threshold.

[0043] For example, in the intelligent fault prediction and optimization process for server systems, this embodiment employs multiple advanced learning models to improve system reliability and operational stability. First, a Gradient Boosting Decision Tree (GBDT) model is used to predict potential server system failures. Based on historical test data from the server system, the GBDT model can accurately identify potential issues such as hard drive life degradation, achieving a prediction accuracy of 95%. Furthermore, the intelligent analysis module employs a Long Short-Term Memory (LSTM) model to perform time series analysis on sensor data, enabling real-time monitoring and detection of hardware anomalies, such as sudden temperature rises and voltage fluctuations.

[0044] By combining multiple advanced learning models (such as LSTM time series anomaly detection and GBDT fault prediction), it not only provides early warning of impending failures but also generates specific optimization recommendations based on historical data. For example, based on analysis results, fan speed thresholds can be adjusted to better control internal server temperatures, or power load distribution can be optimized to mitigate the impact of voltage fluctuations. These measures effectively reduce the incidence of hardware failures, estimated to reduce the risk by over 30%, significantly improving server operational stability and efficiency.

[0045] In some examples, you can use Figure 2The intelligent evaluation system shown improves the testing efficiency of server systems. Specifically, the heterogeneous data acquisition module uses the IPMI / BMC dual protocol stack to support real-time collection and fusion of multi-source sensor data, ensuring the comprehensiveness and accuracy of the data. The dynamic scheduling module uses a multi-core task allocation algorithm based on reinforcement learning to achieve load-balanced task scheduling, improving resource utilization and processing speed. The intelligent analysis module has a built-in LSTM-GBDT hybrid model architecture for hardware status prediction and fault diagnosis, combining the advantages of time series analysis and decision tree models to provide accurate prediction and diagnosis results. The adaptive testing module includes an environment-aware dynamic threshold adjustment mechanism and a fuzzy matching function for a multi-vendor driver library, which can dynamically adjust test standards according to the actual operating environment and is compatible with drivers from different vendors, enhancing the flexibility and adaptability of the system. The blockchain-based report generation module is used to generate tamper-proof test reports to ensure the authenticity and credibility of test results. The security audit module uses blockchain solidification of operation logs and trusted execution environment protection to achieve full monitoring and auditing of system operations, ensuring system security and compliance. The intelligent evaluation system in this embodiment integrates multiple functional modules to achieve comprehensive performance monitoring and optimization, achieving safe and efficient server system testing.

[0046] Compared with related technologies, this embodiment first obtains the device feature vector of the server system to be tested; then fuzzy matches the device feature vector with the feature description vector in the driver library that can be used to test the server system; if the match is successful, the hardware feature parameters of the server system to be tested are collected, and the test threshold of the hardware status of the server system to be tested is dynamically determined based on the real-time monitored environmental parameters; then, based on the hardware feature parameters and the dynamically determined test threshold, the hardware status of the server system to be tested is tested. By obtaining the device feature vector of the server system to be tested and fuzzy matching it with the feature description vector in the driver library, automatic recognition and adaptation of hardware devices from multiple manufacturers are achieved, which significantly reduces the time for manual intervention and the complexity of driver configuration, thereby reducing testing costs and improving testing efficiency. After the match is successful, the hardware feature parameters are collected and the test threshold is dynamically adjusted in combination with the real-time environmental parameters, so that the test strategy can adapt to the current hardware and environmental status, thereby improving the accuracy and flexibility of the test.

[0047] Further, as a refinement and extension of the above embodiment, in order to specifically illustrate the testing process of the server system, optionally, step 102 may specifically include: calculating the cosine similarity between the device feature vector and the feature description vector; if the cosine similarity exceeds the similarity threshold, determining that the match is successful.

[0048] For example, during the fuzzy matching process of multi-vendor driver libraries, if the cosine similarity between the calculated device feature vector and the driver description vector exceeds a similarity threshold (such as 0.85), the candidate driver is automatically loaded and a compatibility test is triggered, thereby dynamically evaluating and adapting the compatibility between the device and the driver. This ensures that even in the absence of an exact match, the appropriate driver can be found through similarity analysis, improving device compatibility and user experience.

[0049] Optionally, the method of this embodiment may further specifically include: obtaining a first hash value of the device identifier of the server system to be tested, and a second hash value of the device identifier that can be used to test the server system; if there is a second hash value that successfully matches the first hash value, determining that the match is successful; correspondingly, step 102 may further specifically include: if there is no second hash value that successfully matches the first hash value, fuzzy matching the device feature vector with the feature description vector in the driver library that can be used to test the server system.

[0050] For example, Figure 3 As shown in the figure, during the matching process of multi-vendor driver libraries, the adaptive test module can build an environment mapping model through dynamic threshold adjustment to reflect changes in the system operating environment in real time; at the same time, the driver fuzzy matching mechanism uses hash comparison and cosine matching technology to accurately identify and match the performance of different drivers in specific environments, thereby realizing comprehensive monitoring and intelligent diagnosis of server hardware status, ensuring system stability and reliability.

[0051] For example, the hash value of the device identifier can be first extracted and compared with the driver fingerprint library to attempt an exact match. Specifically, the first hash value of the device identifier of the server under test is obtained and compared with the second hash value in the device identifier library available for testing. If the second hash value successfully matches the first hash value, it is determined to be a match, and the subsequent testing process is executed. If an exact match is not found, the cosine similarity between the device feature vector and the driver description vector is calculated to perform a fuzzy match.

[0052] Optionally, the method of this embodiment may further include: obtaining the importance of hardware characteristic parameters; accordingly, step 104 may further include: testing the hardware status of the server system to be tested based on the hardware characteristic parameters and the dynamically determined test threshold, and in combination with the importance of the hardware characteristic parameters.

[0053] For example, during hardware testing, the hardware characteristic parameters of the server system under test are first obtained, and the importance of each parameter is assessed. Then, during the testing phase, test tasks are scheduled based on the hardware characteristic parameters and dynamically adjusted test thresholds. Furthermore, the test priority and test accuracy requirements are dynamically adjusted based on the importance of each parameter, thereby focusing on testing key hardware modules and improving the relevance and effectiveness of the overall test.

[0054] Optionally, the hardware characteristic parameters include: hard disk monitoring parameters, frequency domain characteristics of power supply ripple coefficient and bit error rate; accordingly, the above-mentioned test thresholds based on the hardware characteristic parameters and dynamically determined, and combined with the importance of the hardware characteristic parameters, test the hardware status of the server system to be tested, which may specifically include: determining the weights corresponding to the hard disk monitoring parameters, frequency domain characteristics of the power supply ripple coefficient and bit error rate according to the importance; using the weights to perform timing analysis on the server system to be tested to obtain timing analysis results; comparing the timing analysis results with the test thresholds to obtain test results of the hardware status of the server system to be tested.

[0055] For example, we can first use Figure 4 The heterogeneous data acquisition module uses the IPMI / BMC dual protocol stack to support real-time collection and fusion of multi-source sensor data (such as temperature, voltage, and fan speed). It also determines the weighting of hard drive monitoring parameters, the frequency domain characteristics of the power supply ripple coefficient, and the bit error rate based on the importance of hardware characteristic parameters. The heterogeneous data acquisition module supports both IPMIv2.0 and the BMC Redfish API, and is compatible with sensor data collection based on Intel, AMD, and ARM architectures.

[0056] For example, during the data fusion process, different processing methods can be applied to different types of sensor data. These methods may include: Sliding window mean filtering for voltage data to reduce noise and ensure the stability of voltage measurements; exponentially weighted moving average processing for temperature data to effectively capture temperature trends and smooth short-term fluctuations; and timestamp alignment and correlation analysis for discrete events (such as fan failures) to accurately track the time of event occurrence and its impact. This data is input into the intelligent analysis module and adaptive testing module for hardware status prediction, fault diagnosis, and dynamic adjustment of test thresholds. Furthermore, some data (such as CPU core load rate and memory usage) is used by the dynamic scheduling module to construct a core load matrix to support load-balancing task scheduling decisions. Sensor data can also be used to construct a multidimensional feature mapping model to dynamically adjust environment-sensitive test thresholds. For example, sensor trigger conditions can be modified based on temperature changes, thereby improving test accuracy and adaptability. In this way, the heterogeneous data acquisition module provides fundamental data support for the entire intelligent evaluation system.

[0057] For example, the collected sensor data is input into Figure 5 The LSTM-GBDT hybrid model architecture of the intelligent analysis module shown can be used for hardware status prediction and fault diagnosis. This data is analyzed through an LSTM network for time series analysis, detecting hardware anomalies in real time. Combined with the GBDT model, it predicts potential failures, such as hard drive life degradation.

[0058] In some examples, the LSTM network input dimension in the LSTM-GBDT hybrid model architecture is [time step × number of features]. The time step is dynamically configured to 12 to 72 hours based on the hardware type to accommodate different hardware characteristics. The GBDT model uses a feature importance weighting mechanism. Key features include the dynamic change rate of the hard drive's SMART parameters (dynamic change rate = (current value - baseline value) / number of operating hours), the frequency domain characteristics of the power supply ripple coefficient (using fast Fourier transform (FFT) to extract the energy contribution in the 1kHz-10MHz frequency band), and the second-order derivative of the PCIe bit error rate.

[0059] In some examples, weighted hardware feature parameters can be used to perform timing analysis using methods suitable for processing time series data (such as LSTM networks). After the timing analysis is completed, the results are compared with test thresholds that are dynamically adjusted based on environmental perception. These thresholds can be set based on historical data and environmental operating conditions to determine whether the hardware status is normal, thereby obtaining the hardware status test results of the server system under test, identifying possible risk components, or confirming the health of the system, thereby improving the stability and reliability of the system.

[0060] Optionally, the method of this embodiment may further include: determining an idle processor core based on the workload of the server system to be tested; correspondingly, step 104 may further include: executing the hardware test task of the server system to be tested on the idle processor core based on the hardware characteristic parameters and the dynamically determined test threshold.

[0061] For example, based on the workload of the server system under test, the system can dynamically identify currently idle processor cores and, based on hardware characteristic parameters (such as CPU frequency, cache configuration, instruction set support, etc.) and real-time adjusted test thresholds, execute the corresponding hardware test tasks on the selected idle cores. This not only improves resource utilization and parallel processing capabilities during the test process, but also enables adaptive scheduling based on the characteristics of different hardware platforms, thereby improving test efficiency and accuracy.

[0062] As a refinement of this embodiment, in the relevant steps of testing the hardware status of the server system to be tested based on the hardware characteristic parameters and the dynamically determined test threshold, the hardware test tasks of the server system to be tested can be dynamically scheduled on multiple cores in the following manner, but not limited to: Figure 6 As shown, Figure 6 A flowchart of a server system testing method provided in an embodiment of the present disclosure includes:

[0063] Step 201: Split the hardware test task into a subtask set that can be processed in parallel. The granularity of the subtask set is dynamically determined by the task type and resource occupancy of the hardware test task.

[0064] For example, Figure 7 The dynamic scheduling module shown can achieve efficient task management and resource allocation by working together with the task decomposition unit, resource monitoring unit, scheduling policy unit, and shared memory communication unit. The task decomposition unit is responsible for decomposing complex tasks into a set of subtasks {T1, T2, ..., Tn} that can be processed in parallel.

[0065] Step 202: Identify idle processor cores by real-time monitoring of resource usage of the server system to be tested.

[0066] Exemplarily, the resource monitoring unit in the dynamic scheduling module monitors the status of system resources in real time to ensure efficient use of resources.

[0067] Optionally, step 202 may specifically include: determining the load levels of the multiple processor cores by collecting the load rates, memory occupancy rates, and input and output data volumes of the multiple processor cores in real time; and determining idle processor cores based on the load levels.

[0068] For example, by collecting key performance indicators such as the load rate, memory occupancy rate, and input and output data volume (I / O throughput) of each processor core (CPU core) in real time, a core load matrix L=[l1,l2,...,lm] in a unified format is constructed, where the CPU core load rate reflects the busyness of each processor core in executing tasks. The higher the value, the heavier the task processing burden of the core; the memory occupancy rate indicates the percentage of used memory in the system to the total memory capacity, reflecting the intensity of memory resources; the I / O throughput measures the speed and efficiency of input and output operations, including disk reading and writing and network transmission, and represents the system's data exchange capability.

[0069] For example, each element li∈[0,100%] in the core load matrix represents the utilization ratio of the corresponding CPU core. Combined with memory and I / O status, it can more comprehensively reflect the real-time load of system resources and can be reflected as the load level of multiple processor cores. By analyzing the core load matrix, we can dynamically understand the operating status of the server, providing data support for optimization decisions such as task scheduling, load balancing, bottleneck prediction, and fault warning, thereby improving system operating efficiency and stability.

[0070] Step 203: Based on the subtask set, dynamically allocate the hardware test tasks of the server system to be tested to idle processor cores for execution.

[0071] For example, the scheduling strategy unit in the dynamic scheduling module adopts an improved Q-learning algorithm to optimize the task scheduling strategy by defining the state space, adjusting the attenuation exploration rate and processing task preemption, so as to achieve the purpose of load balancing and improving system performance; the shared memory communication unit ensures the rapid exchange and synchronization of information between units, and can adopt a double buffering mechanism to realize cross-core data exchange. The buffer size is dynamically allocated according to the amount of task data to ensure the coordination and consistency of the entire scheduling process.

[0072] In some examples, the modified Q-learning algorithm reward function is defined as:

[0073] (Formula 2)

[0074] Among them, α, β, and γ are dynamic adjustment coefficients, which are optimized by analyzing the sliding window mean of historical task completion time to improve the real-time performance of scheduling decisions and resource utilization efficiency.

[0075] Optionally, step 203 may specifically include: determining a task scheduling decision based on the improved reinforcement learning algorithm according to the state space and decay exploration rate of the server system under test; and dynamically allocating the hardware test tasks of the server system under test to idle processor cores for execution based on the task scheduling decision and the subtask set.

[0076] In some examples, the state space S in the improved Q-learning algorithm can be defined as a set of CPU core load levels {low, medium, high}, which is used to characterize the current resource usage of each core; the action space A is defined as a set of instructions for assigning tasks to target cores, representing the task scheduling decisions that the agent can take. In terms of policy exploration, the algorithm uses an exploration rate ε based on count decay:

[0077] (Formula 3)

[0078] Among them, N is the number of tasks that have been successfully assigned, so that the exploration rate gradually decreases with the accumulation of task scheduling experience, thereby achieving a smooth transition from exploration to utilization.

[0079] Optionally, the method of this embodiment may further include: when a target hardware test task with a priority higher than a priority threshold is detected, triggering the preemption mechanism of the target hardware test task, saving the currently being processed hardware test task to temporary storage, and re-executing the task dynamic allocation process of the currently being processed hardware test task.

[0080] For example, when the system detects the arrival of a high-priority task, the dynamic scheduling module immediately triggers the task preemption mechanism. It first interrupts the currently executing low-priority task and places the high-priority task at the front of the execution queue for priority processing. Simultaneously, the system saves the interrupted task's execution environment (such as state information and data context) to a temporary storage area to ensure accurate subsequent resumption of execution. After the task switch is complete, the improved Q-learning algorithm re-evaluates and calculates the optimal scheduling strategy based on the current system state (including CPU core load and task queue length), prioritizing the rapid response and efficient execution of the high-priority task. The system then updates the corresponding state-action pair values in the Q-table based on the new strategy, reflecting the expected benefits of the latest scheduling decision, thereby continuously optimizing the allocation logic for future tasks. The Q-table records the reward values obtained from taking different actions under different states and serves as a key basis for the reinforcement learning algorithm's decision-making. Once the high-priority task completes, the system automatically loads the previously saved low-priority task environment and resumes execution from the point of interruption, ensuring task processing continuity and data integrity.

[0081] Optionally, the method of this embodiment may further include: aggregating the test data corresponding to the server system to be tested into a leaf node set; performing layer-by-layer hash calculation on the test data in the leaf node set to generate a tree root hash value; and writing the tree root hash value into the Ethereum blockchain.

[0082] In some examples, such as Figure 8 To achieve secure blockchain-based evidence storage of test data, the blockchain evidence module aggregates the test data of the server system under test into a set of leaf nodes. This data is hashed layer by layer according to the Merkle tree structure to generate a final root hash value. This root hash value is written to the Ethereum blockchain via a smart contract, ensuring that the data cannot be tampered with and is traceable. Furthermore, the generated test report contains multiple verifiable fields: a timestamp chain, generated by serially concatenating the hash values of the execution time of each test module, used to verify the temporal integrity of the test process; and a digital signature, signed using the national secret SM2 algorithm, to ensure the authenticity and legitimacy of the report's source.

[0083] Optionally, the method of this embodiment may further include: packaging the test operation log blocks of the server system to be tested in a trusted execution environment based on a preset time period, and verifying the validity of the test operation log blocks through a consensus mechanism, and the session keys in the trusted execution environment are dynamically generated through a key derivation function.

[0084] In some examples, such as Figure 8 In the security audit module, test operation logs from the server system under test are periodically packaged into blocks within the trusted execution environment (TEE). The collected log data is organized into a new block at a preset interval (e.g., every 10 seconds). The validity of each block is verified using an improved Practical Byzantine Fault Tolerance (PBFT) consensus mechanism, ensuring the accuracy and integrity of the operation logs. The TEE utilizes hardware-enhanced security technologies (such as Intel SGX) to ensure the security of the processing process. The root key is generated within the memory area (SGX Enclave) and is never disclosed, further enhancing data protection. Session keys are dynamically generated based on specific needs using a key derivation function (KDF) to maintain secure and flexible communication. This ensures the security and reliability of the blockchain-based storage of test operation logs while also meeting high-level key management requirements, effectively preventing data tampering and unauthorized access.

[0085] In some embodiments, the heterogeneous data acquisition module integrates the IPMI / BMC dual protocol stack, supports real-time acquisition and fusion of multi-source sensor data, uses Python to implement multi-threaded asynchronous data acquisition, is compatible with both IPMI v2.0 and BMC Redfish API specifications, and writes an adapter middle layer to adapt to the characteristics of different hardware series from different manufacturers.

[0086] In some embodiments, the dynamic scheduling module adopts a multi-core task allocation algorithm based on reinforcement learning to achieve load-balanced task scheduling, constructs a core load matrix L=[l, l, ..., l], where l∈[0, 100%], sets the high threshold of the overall system load to 70%, and makes a comprehensive judgment on whether it is overloaded based on the load rate of each core. An improved Q-learning algorithm is used to dynamically allocate tasks to idle CPU cores, and limits the timeout time and number of runs of tasks to prevent resource deadlock. The scheduling strategy is designed as follows: define the state space S as the load level set of CPU cores {low, medium, high}, and the action space A as the instruction for assigning tasks to the target core, where the state s∈S, the action a∈A, the exploration rate ε randomly selects actions according to the formula, and the code block represents the specific action content. When a high-priority task is detected, the task preemption mechanism is triggered, the current task environment is saved to temporary storage, and the search process is re-executed.

[0087] In some embodiments, the intelligent analysis module incorporates a hybrid LSTM-GBDT model architecture for hardware status prediction and fault diagnosis. This module employs an LSTM network for sequence prediction, with predictions updated on a 24-hour cycle. During the diagnostic process, it integrates multi-dimensional data such as temperature, voltage, and fan speed for collaborative analysis, designing a 13-dimensional covariance function. The sample dataset is divided into training, test, and validation sets in a 2:8:2 ratio. Outliers are calculated based on the mean and standard deviation of the most recent 24-hour sampling period.

[0088] In some embodiments, the adaptive test module includes a dynamic threshold adjustment mechanism for environmental perception and a fuzzy matching function for a multi-vendor driver library, constructs a multi-dimensional feature mapping model F(X), feature space X∈R, target space Y∈R, uses the nearest neighbor algorithm for cluster fitting, sets the neighborhood radius R=2, and in the testing phase, calculates the difference between the real sample point and the model estimated output as the loss function L(F), continuously iterates and optimizes the fitting parameters C, F and W, divides the threshold into intervals according to the least squares result, and uses the statistical probability P as the basis for weighting. For the access of new devices, the classifier is trained in the form of softmax regression output.

[0089] In some embodiments, a report generation module for blockchain evidence storage is used to generate tamper-proof test reports; a security audit module is used to implement blockchain solidification of operation logs and trusted execution environment protection, perform offline backup of root keys, and implement software-level security protection through snapshot comparison of static and dynamic analysis of the current program control flow. Blockchain technology is used to record sensitive information such as environmental parameters, system software and hardware versions, root keys, etc. to ensure the accuracy and integrity of the information.

[0090] Compared to existing technologies, this embodiment improves server system testing efficiency, fault prediction accuracy, and cross-platform compatibility by integrating dynamic multi-core scheduling, intelligent analysis, and adaptive testing mechanisms. A dynamic scheduling strategy based on reinforcement learning intelligently allocates tasks to idle CPU cores, achieving load balancing and optimal resource utilization. The intelligent analysis module uses an LSTM network to perform time series modeling on sensor data, enabling real-time detection of anomalies (such as temperature spikes and voltage fluctuations). It also incorporates the GBDT model to predict potential faults such as hard drive life degradation and power supply stability with high accuracy (up to 95%). The adaptive testing module dynamically adjusts test thresholds based on environmental parameters (such as temperature, humidity, and air pressure), integrates driver libraries from multiple vendors, and uses hash comparison and cosine similarity matching to enable rapid driver adaptation and compatibility verification. This embodiment forms a closed-loop technology from multiple levels, encompassing system architecture, scheduling algorithms, machine learning model application, and adaptive testing methods. This highly innovative and robust solution is suitable for intelligent testing and maintenance of high-reliability server systems.

[0091] The embodiment of the present application also provides a testing device for a server system, as Figure 1 The specific implementation of the method shown is as follows Figure 9 As shown, the device includes: an acquisition module 31, a matching module 32, a determination module 33, and a testing module 34.

[0092] An acquisition module 31 is configured to acquire a device feature vector of the server system to be tested;

[0093] A matching module 32 is configured to perform fuzzy matching between the device feature vector and a feature description vector in a driver library that can be used for server system testing;

[0094] The determination module 33 is configured to collect hardware characteristic parameters of the server system to be tested if the match is successful, and dynamically determine the test threshold of the hardware status of the server system to be tested based on the environmental parameters monitored in real time;

[0095] The testing module 34 is configured to test the hardware status of the server system to be tested based on the hardware characteristic parameters and the dynamically determined test threshold.

[0096] In some examples of this embodiment, the matching module 32 is specifically configured to calculate the cosine similarity between the device feature vector and the feature description vector; if the cosine similarity exceeds a similarity threshold, it is determined that the match is successful.

[0097] In some examples of this embodiment, a first hash value of the device identifier of the server system to be tested and a second hash value of the device identifier for the server system test are obtained; if there is a second hash value that successfully matches the first hash value, it is determined that the match is successful; accordingly, the matching module 32 is further configured to fuzzy match the device feature vector with the feature description vector for the server system test in the driver library if there is no second hash value that successfully matches the first hash value.

[0098] In some examples of this embodiment, the importance of the hardware characteristic parameters is obtained; accordingly, the test module 34 is specifically configured to test the hardware status of the server system to be tested based on the hardware characteristic parameters and the dynamically determined test threshold, and in combination with the importance of the hardware characteristic parameters.

[0099] In some examples of this embodiment, the hardware characteristic parameters include: hard disk monitoring parameters, frequency domain characteristics of the power supply ripple coefficient and bit error rate; accordingly, the test module 34 is further configured to determine the weights corresponding to the hard disk monitoring parameters, the frequency domain characteristics of the power supply ripple coefficient and the bit error rate according to the importance; use the weights to perform timing analysis on the server system to be tested to obtain timing analysis results; compare the timing analysis results with the test threshold to obtain the test results of the hardware status of the server system to be tested.

[0100] In some examples of this embodiment, an idle processor core is determined based on the workload of the server system to be tested; accordingly, the test module 34 is further configured to execute the hardware test task of the server system to be tested on the idle processor core based on the hardware characteristic parameters and the dynamically determined test threshold.

[0101] In some examples of this embodiment, the test module 34 is further configured to split the hardware test task into a set of subtasks that can be processed in parallel, and the granularity of the subtask set is dynamically determined by the task type and resource occupancy of the hardware test task; identify the idle processor cores by real-time monitoring of the resource usage of the server system to be tested; and dynamically allocate the hardware test task of the server system to be tested to the idle processor cores for execution based on the subtask set.

[0102] In some examples of this embodiment, the test module 34 is further configured to determine the load levels of the multiple processor cores by collecting the load rates, memory occupancy rates, and input and output data volumes of the multiple processor cores in real time; and determine the idle processor cores based on the load levels.

[0103] In some examples of this embodiment, the test module 34 is further configured to determine a task scheduling decision based on an improved reinforcement learning algorithm according to the state space and decay exploration rate of the server system to be tested; based on the task scheduling decision and the subtask set, dynamically allocate the hardware test task of the server system to be tested to the idle processor core for execution.

[0104] In some examples of this embodiment, the test module 34 is further configured to trigger the preemption mechanism of the target hardware test task when a target hardware test task having a priority higher than a priority threshold is detected, save the currently being processed hardware test task to temporary storage, and re-execute the task dynamic allocation process of the currently being processed hardware test task.

[0105] In some examples of this embodiment, the test module 34 is further configured to aggregate the test data corresponding to the server system to be tested into a leaf node set; perform layer-by-layer hash calculation on the test data in the leaf node set to generate a tree root hash value; and write the tree root hash value into the Ethereum blockchain.

[0106] In some examples of this embodiment, the test module 34 is further configured to package the test operation log block of the server system to be tested in a trusted execution environment based on a preset time period, and verify the validity of the test operation log block through a consensus mechanism. The session key in the trusted execution environment is dynamically generated through a key derivation function.

[0107] It should be noted that for other corresponding descriptions of the functional units involved in the testing device for a server system provided in this embodiment, please refer to Figure 1 The corresponding description in will not be repeated here.

[0108] Based on the above Figure 1 and Figure 6 The method shown in FIG. 1 is a method for performing the above-mentioned steps. Accordingly, this embodiment further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program can realize the above-mentioned steps. Figure 1 and Figure 6 The method shown.

[0109] Based on the above Figure 1 and Figure 6 The method shown in FIG. 1 is a method for performing the above-mentioned operations. Accordingly, this embodiment further provides a computer program product having a computer program stored thereon. When the computer program is executed by a processor, the above-mentioned Figure 1 and Figure 6 The method shown.

[0110] Based on this understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, USB flash drive, mobile hard disk, etc.), and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of the present application.

[0111] Based on the above Figure 1 and Figure 6 The method shown, and Figure 9 In order to achieve the above-mentioned purpose, the embodiment of the present application further provides an electronic device, such as a personal computer or a server, which includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to achieve the above-mentioned Figure 1 and Figure 6 The method shown.

[0112] In some embodiments, the physical device may further include a user interface, a network interface, a camera, a radio frequency (RF) circuit, a sensor, an audio circuit, a Wi-Fi module, and the like. The user interface may include a display, an input unit such as a keyboard, and the like. Optional user interfaces may also include a USB interface and a card reader interface. In some embodiments, the network interface may include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0113] Those skilled in the art will understand that the above-mentioned physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or a combination of certain components, or different component arrangements.

[0114] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the physical device, supporting the execution of information processing programs and other software and / or programs. The network communication module is used to enable communication between components within the storage medium, as well as with other hardware and software within the physical information processing device.

[0115] Through the description of the above implementation methods, those skilled in the art can clearly understand that the present application can be implemented by means of software plus the necessary general hardware platform, or by hardware. By applying the solution of this embodiment, compared with the current related technologies, this embodiment realizes the intelligent decomposition and load balancing distribution of hardware testing tasks through the multi-core parallel computing framework and reinforcement learning algorithm of the dynamic scheduling module, and uses shared memory or Unix domain sockets to achieve low-latency communication, so that the parallel testing efficiency of thousands of servers is improved by more than 40%, significantly shortening the test cycle. The intelligent analysis module integrates LSTM timing modeling and GBDT fault prediction model. The former detects abnormalities such as sudden temperature rise and voltage fluctuation in real time, and the latter predicts potential faults such as hard disk life attenuation with an accuracy of 95%, and generates optimization suggestions based on historical data (such as adjusting fan thresholds and optimizing power loads), effectively reducing the hardware failure rate by more than 30% and improving system stability. The adaptive testing module improves the matching degree of test conditions through a dynamic threshold adjustment mechanism driven by environmental parameters. At the same time, it integrates multi-vendor driver libraries to support plug-and-play testing of mainstream interfaces such as PCIe and NVMe. The compatibility coverage rate is increased by 30%, and the adaptive matching time of test scripts is shortened by 50%, which greatly reduces the cross-platform adaptation cost and realizes an efficient, intelligent and compatible server hardware testing system as a whole.

[0116] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device that includes the element.

[0117] The above are merely specific embodiments of the present application, which are intended to enable those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to these embodiments herein, but rather is intended to conform to the widest scope consistent with the principles and novel features of the present application.

Claims

1. A method for testing a server system, characterized in that: include: Obtaining a device feature vector of the server system to be tested, wherein the device feature vector includes: central processing unit model, memory capacity and frequency, storage type and interface, and network card configuration; Performing fuzzy matching on the device feature vector and a feature description vector in a driver library capable of performing server system testing, including: calculating a cosine similarity between the device feature vector and the feature description vector; and determining that the match is successful if the cosine similarity exceeds a similarity threshold; If the match is successful, the hardware characteristic parameters of the server system under test are collected, and the test threshold of the hardware status of the server system under test is dynamically determined based on the real-time monitored environmental parameters. The hardware characteristic parameters include: hard disk monitoring parameters, frequency domain characteristics of power supply ripple coefficient, and bit error rate; The hardware status of the server system to be tested is tested based on the hardware characteristic parameters and the dynamically determined test threshold.

2. The method according to claim 1, characterized in that Before fuzzy matching the device feature vector with a feature description vector in a driver library capable of performing server system testing, the method further includes: Obtaining a first hash value of a device identifier of the server system to be tested and a second hash value of a device identifier capable of performing server system testing; If there is a second hash value that successfully matches the first hash value, then it is determined that the match is successful; The fuzzy matching of the device feature vector with a feature description vector in a driver library capable of performing server system testing includes: If there is no second hash value that successfully matches the first hash value, fuzzy matching is performed on the device feature vector and a feature description vector in the driver library that can be used for server system testing.

3. The method according to claim 1, characterized in that Before testing the hardware status of the server system to be tested based on the hardware characteristic parameters and the dynamically determined test threshold, the method further includes: Obtaining the importance of the hardware characteristic parameters; The step of testing the hardware status of the server system to be tested based on the hardware characteristic parameters and the dynamically determined test threshold comprises: Based on the hardware characteristic parameters and the dynamically determined test threshold, and in combination with the importance of the hardware characteristic parameters, the hardware status of the server system to be tested is tested.

4. The method according to claim 3, characterized in that The testing of the hardware status of the server system to be tested based on the hardware characteristic parameters and the dynamically determined test threshold, and in combination with the importance of the hardware characteristic parameters, includes: Determining weights corresponding to the hard disk monitoring parameter, the frequency domain characteristics of the power supply ripple coefficient, and the bit error rate, respectively, based on the importance; Performing a timing analysis on the server system to be tested using the weights to obtain a timing analysis result; The timing analysis result is compared with the test threshold to obtain a test result of the hardware status of the server system to be tested.

5. The method according to claim 1, wherein Before testing the hardware status of the server system to be tested based on the hardware characteristic parameters and the dynamically determined test threshold, the method further includes: Determining idle processor cores according to the workload of the server system to be tested; The step of testing the hardware status of the server system to be tested based on the hardware characteristic parameters and the dynamically determined test threshold comprises: Based on the hardware characteristic parameters and the dynamically determined test threshold, the hardware test task of the server system to be tested is executed on the idle processor core.

6. The method according to claim 5, characterized in that The step of determining an idle processor core according to the workload of the server system to be tested includes: Splitting the hardware test task into a set of subtasks that can be processed in parallel, wherein the granularity of the subtask set is dynamically determined by the task type and resource occupancy of the hardware test task; Identifying the idle processor cores by real-time monitoring of resource usage of the server system to be tested; The step of executing the hardware test task of the server system to be tested on the idle processor core based on the hardware characteristic parameters and the dynamically determined test threshold comprises: Based on the subtask set, the hardware test task of the server system to be tested is dynamically allocated to the idle processor core for execution.

7. The method according to claim 6, characterized in that The identifying the idle processor core by real-time monitoring of resource usage of the server system to be tested includes: Determining load levels of the multiple processor cores by collecting load rates, memory occupancy rates, and input and output data volumes of the multiple processor cores in real time; Based on the load level, the idle processor core is determined.

8. The method according to claim 6, characterized in that The dynamically allocating the hardware test task of the server system to be tested to the idle processor core for execution based on the subtask set includes: Based on the improved reinforcement learning algorithm, the task scheduling decision is determined according to the state space and the decaying exploration rate of the server system under test; Based on the task scheduling decision and the subtask set, the hardware test task of the server system to be tested is dynamically allocated to the idle processor core for execution.

9. The method according to claim 6, characterized in that The method further comprises: When a target hardware test task with a priority higher than the priority threshold is detected, the preemption mechanism of the target hardware test task is triggered, and the currently processed hardware test task is saved to temporary storage, and the task dynamic allocation process of the currently processed hardware test task is re-executed.

10. The method according to claim 1, characterized in that After testing the hardware status of the server system to be tested based on the hardware characteristic parameters and the dynamically determined test threshold, the method further includes: Aggregating the test data corresponding to the server system to be tested into a leaf node set; Performing layer-by-layer hash calculation on the test data in the leaf node set to generate a tree root hash value; Write the tree root hash value to the Ethereum blockchain.

11. The method according to claim 1, wherein The method further comprises: The test operation log blocks of the server system under test are packaged in a trusted execution environment based on a preset time period, and the validity of the test operation log blocks is verified through a consensus mechanism. The session key in the trusted execution environment is dynamically generated through a key derivation function.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 11 is implemented.

13. An electronic device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 11 is implemented.

14. A computer program product having a computer program stored thereon, characterized in that: When the computer program product is executed by a processor, the method according to any one of claims 1 to 11 is implemented.

Images