A reliability reboot testing method, system, device and storage medium

Abstract

The application provides a reliability restart test method, comprising: collecting hardware parameters on a server through multiple rounds of restarts and performing a repair check on abnormal parameters in each round of restarts; and determining a server state of the server after multiple rounds of restarts based on the hardware parameters. The application provides a reliability restart test method, which compares parameters obtained in each round of restart test in server test with standard parameters, and initiates a repair check to detect hardware parameters of corresponding hardware again when the comparison result is different, so as to correct data abnormalities caused by bugs or abnormalities on a software layer such as an operating system or a driver on the server due to multiple restarts. The application effectively improves the accuracy and reliability of data collection in the server restart test process.

Description

Technical Field

[0001] This invention belongs to the field of computer science, and specifically relates to a reliability restart test method, system device, and readable storage medium. Background Technology

[0002] In the hardware testing phase of storage devices, overall system reliability testing is a crucial step. During the test case design phase of overall system reliability testing, key scenarios for external card testing include slot traversal, maximum specification, and exceeding specification limits, with dozens of detailed test scenarios involved. In the overall system reliability testing process, the collection, analysis, and statistical analysis of logs and test results are particularly important for identifying the root causes of problems during the testing phase. However, in traditional reliability restart testing, during the hardware testing phase, the collection, analysis, and statistical analysis of test results for overall system reliability restart testing requires test engineers to manually collect relevant test logs after the test is completed. They then manually count the number of errors, failures, warnings, pcierrdiff, sdrerr, and hdderr messages in the logs and record the frequency to output the test results.

[0003] Therefore, traditional implementation methods are inefficient to some extent, and an effective technical solution is urgently needed to solve this problem. Summary of the Invention

[0004] To address the above problems, this invention proposes a reliability restart test method, comprising:

[0005] The hardware parameters on the server are collected through multiple restarts, and corrective verification is performed on abnormal parameters in each restart.

[0006] The server status after multiple restarts is statistically analyzed based on the hardware parameters.

[0007] In some embodiments of the present invention, analyzing the hardware status of the server after multiple restarts based on the hardware parameters includes:

[0008] The hardware parameters of the server collected from multiple restarts are classified according to the hardware type to which the hardware parameters belong;

[0009] The test results for various types of server hardware are presented based on the aforementioned classification.

[0010] In some embodiments of the present invention, the corrective verification of abnormal parameters in each restart and the analysis of the server's hardware status after multiple restarts based on the hardware parameters further include:

[0011] The hardware parameters obtained in each restart are compared with the standard parameters;

[0012] In response to the comparison result being different, determine the function type of the hardware parameters that are different and the hardware state to which the hardware parameters belong;

[0013] In response to the hardware parameter being a performance parameter, a performance test is performed on the hardware to which the hardware parameter belongs.

[0014] In some embodiments of the present invention, in response to the hardware parameter being a performance parameter, performing a performance test on the hardware to which the hardware parameter belongs includes:

[0015] In response to the completion of the performance test, it is determined whether the performance test result matches the hardware parameters;

[0016] In response to the performance test results matching the hardware parameters, the hardware parameters are recorded as the restart test results for the current round.

[0017] In some embodiments of the present invention, the method further includes:

[0018] In response to the mismatch between the performance test results and the hardware parameters, the hardware parameters corresponding to the performance test results are taken as the hardware parameters of the hardware, and the hardware parameters are classified as logical data anomalies.

[0019] In some embodiments of the present invention, analyzing the hardware status of the server after multiple restarts based on the hardware parameters further includes:

[0020] In response to the hardware parameters being functional parameters, the driver for the hardware with the specified hardware parameters is reloaded, and the hardware parameters of the hardware after the driver reload are recorded; and

[0021] Determine whether the hardware parameters obtained after reloading the driver are the same as the standard hardware parameters;

[0022] If the hardware parameters obtained after reloading the driver are different from the standard parameters but the same as the standard parameters, then the re-obtained hardware parameters are used as the hardware parameters for the current round, and the hardware parameters are classified as logical data anomalies.

[0023] In some embodiments of the present invention, the corrective verification of abnormal parameters in each restart also includes:

[0024] If the hardware parameters obtained after reloading the driver are still different from the standard parameters, the hardware parameters are used as the hardware parameters for the current round and classified as hardware parameter anomalies.

[0025] Another aspect of the present invention provides a reliability restart testing system, comprising:

[0026] The testing module is configured to collect hardware parameters on the server through multiple restarts and perform corrective checks on abnormal parameters in each restart.

[0027] An analysis module is configured to statistically analyze the server status after multiple restarts based on the hardware parameters.

[0028] Another aspect of the present invention provides a computer device comprising:

[0029] At least one processor; and

[0030] A memory storing computer instructions executable on the processor, which, when executed by the processor, implement the steps of any of the methods described in the above embodiments.

[0031] Another aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the methods described in the above embodiments.

[0032] This invention proposes a reliability restart testing method that compares the parameters obtained in each round of server restart testing with standard parameters. When the comparison results differ, a corrective check is initiated to re-detect the corresponding hardware parameters. This corrects data anomalies caused by bugs or exceptions in the operating system or drivers on the server after multiple restarts. This effectively improves the accuracy and reliability of data collected during server restart testing. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 A flowchart illustrating an embodiment of a reliability restart test method provided by this invention;

[0035] Figure 2 This is a schematic diagram of the structure of a reliability restart test system provided in an embodiment of the present invention;

[0036] Figure 3 A schematic diagram of the structure of a computer device provided in an embodiment of the present invention;

[0037] Figure 4 This is a schematic diagram of the structure of a computer-readable storage medium provided in an embodiment of the present invention. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to specific examples and the accompanying drawings.

[0039] This invention is applied to the factory testing phase after server design is completed, especially for verifying the reliability of server restart direction. Traditional restart reliability testing involves repeatedly restarting the server and collecting runtime server status data during each restart, including parameters and operating status of various components. Numerous and frequent restarts are used to verify whether design flaws will cause malfunctions in the server as a whole or specific components during repeated power-on and power-off cycles. Research shows that the damage to electronic components on a server at the moment of power-on is greater than the damage from prolonged normal operation (excluding overload conditions, where users run the server outside its specified performance range to achieve higher performance). Therefore, considering the stability of server products after sale, high-intensity, repeated restart tests are necessary to verify the stability of various components after multiple restarts. Traditional server restart reliability testing schemes simply obtain information parameters of various components by frequently restarting and executing preset scripts after each restart. The traditional method involves immediately restarting the server after data acquisition and repeating this process in predetermined rounds to collect parameters from various components after restart. However, since a server is a complex system comprising both software and hardware, directly attributing data anomalies detected during repeated restart tests to server hardware failure is highly inaccurate. Consequently, the data collected using this traditional approach may lack accuracy, leading to an imbalance in the overall performance evaluation of the server.

[0040] like Figure 1 As shown, to solve the above problems, this invention proposes a reliability restart test method, including:

[0041] Step S1: Collect hardware parameters on the server through multiple restarts and perform corrective checks on abnormal parameters in each restart.

[0042] Step S2: Based on the hardware parameters, statistically analyze the server status after multiple restarts.

[0043] In an embodiment of the present invention, in step S1, the present invention still collects parameter information of each hardware component on the server during each round of restarts through multiple restarts. However, when the collected hardware parameter information is abnormal, a corrective check is performed on the hardware with abnormal parameters. For example, the relevant underlying software of the corresponding hardware is updated, or data interaction is performed with the hardware with abnormal parameters to verify whether it is truly abnormal. Furthermore, the result of the corrective check is used as the correct result as the hardware parameter collected in the corresponding round.

[0044] In step S2, multiple sets of hardware parameter data are obtained through multiple rounds of server restarts. These hardware parameters are then statistically analyzed and used as the results of the server restart reliability test to reflect the corresponding server restart reliability.

[0045] In some embodiments of the present invention, analyzing the hardware status of the server after multiple restarts based on the hardware parameters includes:

[0046] The hardware parameters of the server collected from multiple restarts are classified according to the hardware type to which the hardware parameters belong;

[0047] The test results for various types of server hardware are presented based on the aforementioned classification.

[0048] In this embodiment, the collected hardware parameters are categorized and statistically analyzed according to the types of hardware present on the server, and a data table corresponding to each hardware type is constructed. For example, a separate data table is constructed for CPU-related hardware parameters, with each field representing a hardware parameter type of the CPU. Similarly, corresponding data tables are constructed for other hardware on the server in the same manner. The data tables can be stored using common relational databases for easy subsequent calculation and analysis of the collected data. Furthermore, the server's hardware parameters are displayed using specific hardware-specific data tables, facilitating analysis of the overall server status or the status of a particular hardware component by testers or designers.

[0049] In some embodiments of the present invention, the corrective verification of abnormal parameters in each restart and the analysis of the server's hardware status after multiple restarts based on the hardware parameters further include:

[0050] The hardware parameters obtained in each restart are compared with the standard parameters;

[0051] In response to the comparison result being different, determine the function type of the hardware parameters that are different and the hardware state to which the hardware parameters belong;

[0052] In response to the hardware parameter being a performance parameter, a performance test is performed on the hardware to which the hardware parameter belongs.

[0053] In this embodiment, in each round of restart test, the hardware parameters of the corresponding hardware on the server obtained in each round are compared with the standard parameters. If the specific hardware parameters of a certain hardware do not correspond to the standard parameters, it is determined whether the hardware parameter is a functional hardware parameter or a performance hardware parameter. The performance parameter refers to the parameters of the hardware's performance indicators, such as the hardware's interface I / O bandwidth, the specific cache frequency in the hardware, or the clock frequency of the internal chip of the hardware, etc., which are hardware parameters that identify the hardware's processing capabilities.

[0054] Furthermore, when the hardware parameters are performance-related parameters, performance tests are performed on the hardware. For example, if an abnormality is detected in the bus bandwidth of a certain storage device, the read and write speed of the stored data is tested by writing and reading certain data to the storage device to verify whether its corresponding bandwidth is normal.

[0055] In some embodiments of the present invention, in response to the hardware parameter being a performance parameter, performing a performance test on the hardware to which the hardware parameter belongs includes:

[0056] In response to the completion of the performance test, it is determined whether the performance test result matches the hardware parameters;

[0057] In response to the performance test results matching the hardware parameters, the hardware parameters are recorded as the restart test results for the current round.

[0058] In this embodiment, the aforementioned hardware parameters refer to the hardware parameters obtained by the corresponding detection program after the current round of restart. These differ from the standard hardware parameters. Therefore, after the performance test is completed, the performance test results are matched with these hardware parameters. For example, if the network card's adapted bandwidth changes from 1Gbps to 100Mbps (the standard network card bandwidth parameter is 1Gbps, but only 100Mbps is detected after the restart), a performance test is performed on the network card. If the test result shows a rate of 120MB / s, it indicates that the network card is normal, because 12MB / s is equivalent to a network card bandwidth of 96Mbps. This indicates a stability issue with the hardware, and the test result matches the bandwidth of the 100Mbps network card. If the network card performance is abnormal, and the detected data is correct but does not match the standard parameters, then the network card is indeed faulty. The detected hardware parameters or performance test results are then used as the hardware parameters of the network card during the current round of restart testing and recorded in the data table. In other words, the network card bandwidth parameter for this round of testing is considered to be 100Mbps (the network card itself is a 1Gbps network card).

[0059] In some embodiments of the present invention, the method further includes:

[0060] In response to the mismatch between the performance test results and the hardware parameters, the hardware parameters corresponding to the performance test results are taken as the hardware parameters of the hardware, and the hardware parameters are classified as logical data anomalies.

[0061] In this embodiment, if the performance test results do not match the standard hardware parameters, it indicates a mismatch between the detected hardware parameters and the tested performance data. For example, if the detected network card bandwidth is 100Mbps, and the standard parameter is 1Gbps, and a performance test is performed, but the result is 120MB / s, it means the actual tested bandwidth of the network card is 960Mbps. This bandwidth speed meets the requirement of gigabit bandwidth, i.e., it matches 1Gbps. The previously detected 100Mbps was incorrect. Therefore, 1Gbps can be used as the bandwidth of the network card in this round of testing, or 960Mbps can be used as the bandwidth of the network card in this round of testing. At the same time, the detection error (detecting 100Mbps) is recorded as a logical data anomaly. There are many reasons for logical data anomalies, such as abnormal data detected by the system, or software or system-related reasons such as bugs in certain hardware drivers. These reasons can only be determined whether they are true anomalies or software anomalies through actual hardware performance testing.

[0062] In some embodiments of the present invention, analyzing the hardware status of the server after multiple restarts based on the hardware parameters further includes:

[0063] In response to the hardware parameters being functional parameters, the driver for the hardware with the specified hardware parameters is reloaded, and the hardware parameters of the hardware after the driver reload are recorded; and

[0064] Determine whether the hardware parameters obtained after reloading the driver are the same as the standard hardware parameters;

[0065] If the hardware parameters obtained after reloading the driver are different from the standard parameters but the same as the standard parameters, then the re-obtained hardware parameters are used as the hardware parameters for the current round, and the hardware parameters are classified as logical data anomalies.

[0066] In this embodiment, if the detected abnormal hardware parameter is a functional parameter, the model number of the hardware to which the abnormal parameter belongs is obtained, and the corresponding driver is installed according to the model. After the driver is installed, the hardware parameters of the hardware are obtained again and compared with the standard parameters. If the hardware parameters obtained after driver installation are the same as the standard hardware parameters, it means that the hardware itself is not abnormal, and the abnormality lies in the software layer driver or related settings of the operating system. The abnormal hardware parameter is then marked as a logical data abnormality.

[0067] In some embodiments of the present invention, the corrective verification of abnormal parameters in each restart also includes:

[0068] If the hardware parameters obtained after reloading the driver are still different from the standard parameters, the hardware parameters are used as the hardware parameters for the current round and classified as hardware parameter anomalies.

[0069] In this embodiment, if the hardware parameters obtained after reinstalling the driver are still different from the standard parameters, it indicates that the software-level driver or operating system data is not incorrect; the problem lies with the hardware itself. Therefore, these hardware parameters are directly used as the hardware parameters for the current test round.

[0070] Example:

[0071] 1. Initialization check

[0072] Use a shell script to check the information of the external cards in slots 1-7 of the storage device, including bandwidth (x1 / x2 / x4 / x8 / x16), speed (5 / 8 / 16GT / s), and presence status, and record it to the PCIe log file;

[0073] The same shell script is used to check the hard drive information of 25 slots in the storage device, including the size, model and presence status of the hard drives, and record it to the hdd log file;

[0074] The same shell script is used to check the memory information of 24 slots, including memory size, model, and status, and record it in the memory log file.

[0075] 2. Repeatedly reboot the storage device 500 times, while simultaneously enabling background monitoring.

[0076] A shell script is used to repeatedly restart the storage system 500 times.

[0077] Each loop checks the information of the external cards in the 7 slots again and records it to a new PCIe log file;

[0078] Each cycle checks the hard drive information of all 25 slots again and records it to a new HDD log file;

[0079] Each loop checks the memory information of the 24 slots again and records it to a new memory log file;

[0080] 3. If an exception occurs during the loop, enable short-time testing.

[0081] If the background monitoring detects data showing a decrease in speed and bandwidth of the external card information during the 500th loop, the loop mechanism is paused and a short-term test mechanism is started. The external card with performance degradation or other abnormalities is continuously accessed for 30 minutes to obtain test data on performance degradation. After the short-term test is completed, the interrupted loop mechanism is resumed.

[0082] 4. Collect and analyze logs

[0083] After the loop ends, all PCIe, HDD, memory, and short-term test log files are retrieved through the log collection interface and written to the database;

[0084] The PCIe logs were analyzed using the log interface, including the number of lost cards, information about lost cards, the number of times speed and bandwidth were reduced, and information about cards that experienced speed and bandwidth reduction. This information was then written to the database.

[0085] The HDD logs are analyzed using the log analysis interface to determine the number of disk failures and failure information, and then written to the database.

[0086] The memory logs were analyzed using the log analysis interface, including the number of times memory could not be identified and memory information, which was then written to the database.

[0087] The short-term test data during abnormal scenarios is analyzed through the log analysis interface and written to the database;

[0088] 5. Generate visualized test results with one click

[0089] The analysis data can be exported with one click through the generation interface, and the dimensions of the analysis data can be customized.

[0090] This invention proposes a reliability restart testing method that compares the parameters obtained in each round of server restart testing with standard parameters. When the comparison results differ, a corrective check is initiated to re-detect the corresponding hardware parameters. This corrects data anomalies caused by bugs or exceptions in the operating system or drivers on the server after multiple restarts. This effectively improves the accuracy and reliability of data collected during server restart testing.

[0091] like Figure 2 As shown, another aspect of the present invention provides a reliability restart testing system, comprising:

[0092] Test module 1 is configured to collect hardware parameters on the server through multiple rounds of restarts and perform corrective checks on abnormal parameters in each round of restarts.

[0093] Analysis module 2 is configured to statistically analyze the server status after multiple restarts based on the hardware parameters.

[0094] In some embodiments of the present invention, analyzing the hardware status of the server after multiple restarts based on the hardware parameters includes:

[0095] The hardware parameters of the server collected from multiple restarts are classified according to the hardware type to which the hardware parameters belong;

[0096] The test results for various types of server hardware are presented based on the aforementioned classification.

[0097] In some embodiments of the present invention, the corrective verification of abnormal parameters in each restart and the analysis of the server's hardware status after multiple restarts based on the hardware parameters further include:

[0098] The hardware parameters obtained in each restart are compared with the standard parameters;

[0099] In response to the comparison result being different, determine the function type of the hardware parameters that are different and the hardware state to which the hardware parameters belong;

[0100] In response to the hardware parameter being a performance parameter, a performance test is performed on the hardware to which the hardware parameter belongs.

[0101] In some embodiments of the present invention, in response to the hardware parameter being a performance parameter, performing a performance test on the hardware to which the hardware parameter belongs includes:

[0102] In response to the completion of the performance test, it is determined whether the performance test result matches the hardware parameters;

[0103] In response to the performance test results matching the hardware parameters, the hardware parameters are recorded as the restart test results for the current round.

[0104] In some embodiments of the present invention, the method further includes:

[0105] In response to the mismatch between the performance test results and the hardware parameters, the hardware parameters corresponding to the performance test results are taken as the hardware parameters of the hardware, and the hardware parameters are classified as logical data anomalies.

[0106] In some embodiments of the present invention, analyzing the hardware status of the server after multiple restarts based on the hardware parameters further includes:

[0107] In response to the hardware parameters being functional parameters, the driver for the hardware with the specified hardware parameters is reloaded, and the hardware parameters of the hardware after the driver reload are recorded; and

[0108] Determine whether the hardware parameters obtained after reloading the driver are the same as the standard hardware parameters;

[0109] If the hardware parameters obtained after reloading the driver are different from the standard parameters but the same as the standard parameters, then the re-obtained hardware parameters are used as the hardware parameters for the current round, and the hardware parameters are classified as logical data anomalies.

[0110] In some embodiments of the present invention, the corrective verification of abnormal parameters in each restart also includes:

[0111] If the hardware parameters obtained after reloading the driver are still different from the standard parameters, the hardware parameters are used as the hardware parameters for the current round and classified as hardware parameter anomalies.

[0112] like Figure 3 As shown, another aspect of the present invention also provides a computer device comprising:

[0113] At least one processor 21; and

[0114] Memory 22 stores computer instructions 23 that can be executed on processor 21, and the instructions 23 are implemented when executed by processor 21.

[0115] In some embodiments of the present invention, analyzing the hardware status of the server after multiple restarts based on the hardware parameters includes:

[0116] The hardware parameters of the server collected from multiple restarts are classified according to the hardware type to which the hardware parameters belong;

[0117] The test results for various types of server hardware are presented based on the aforementioned classification.

[0118] In some embodiments of the present invention, the corrective verification of abnormal parameters in each restart and the analysis of the server's hardware status after multiple restarts based on the hardware parameters further include:

[0119] The hardware parameters obtained in each restart are compared with the standard parameters;

[0120] In response to the comparison result being different, determine the function type of the hardware parameters that are different and the hardware state to which the hardware parameters belong;

[0121] In response to the hardware parameter being a performance parameter, a performance test is performed on the hardware to which the hardware parameter belongs.

[0122] In some embodiments of the present invention, in response to the hardware parameter being a performance parameter, performing a performance test on the hardware to which the hardware parameter belongs includes:

[0123] In response to the completion of the performance test, it is determined whether the performance test result matches the hardware parameters;

[0124] In response to the performance test results matching the hardware parameters, the hardware parameters are recorded as the restart test results for the current round.

[0125] In some embodiments of the present invention, the method further includes:

[0126] In response to the mismatch between the performance test results and the hardware parameters, the hardware parameters corresponding to the performance test results are taken as the hardware parameters of the hardware, and the hardware parameters are classified as logical data anomalies.

[0127] In some embodiments of the present invention, analyzing the hardware status of the server after multiple restarts based on the hardware parameters further includes:

[0128] In response to the hardware parameters being functional parameters, the driver for the hardware with the specified hardware parameters is reloaded, and the hardware parameters of the hardware after the driver reload are recorded; and

[0129] Determine whether the hardware parameters obtained after reloading the driver are the same as the standard hardware parameters;

[0130] If the hardware parameters obtained after reloading the driver are different from the standard parameters but the same as the standard parameters, then the re-obtained hardware parameters are used as the hardware parameters for the current round, and the hardware parameters are classified as logical data anomalies.

[0131] In some embodiments of the present invention, the corrective verification of abnormal parameters in each restart also includes:

[0132] If the hardware parameters obtained after reloading the driver are still different from the standard parameters, the hardware parameters are used as the hardware parameters for the current round and classified as hardware parameter anomalies.

[0133] like Figure 4 As shown, another aspect of the present invention provides a computer-readable storage medium 401, which stores a computer program 402, which, when executed by a processor, implements...

[0134] In some embodiments of the present invention, analyzing the hardware status of the server after multiple restarts based on the hardware parameters includes:

[0135] The hardware parameters of the server collected from multiple restarts are classified according to the hardware type to which the hardware parameters belong;

[0136] The test results for various types of server hardware are presented based on the aforementioned classification.

[0137] In some embodiments of the present invention, the corrective verification of abnormal parameters in each restart and the analysis of the server's hardware status after multiple restarts based on the hardware parameters further include:

[0138] The hardware parameters obtained in each restart are compared with the standard parameters;

[0139] In response to the comparison result being different, determine the function type of the hardware parameters that are different and the hardware state to which the hardware parameters belong;

[0140] In response to the hardware parameter being a performance parameter, a performance test is performed on the hardware to which the hardware parameter belongs.

[0141] In some embodiments of the present invention, in response to the hardware parameter being a performance parameter, performing a performance test on the hardware to which the hardware parameter belongs includes:

[0142] In response to the completion of the performance test, it is determined whether the performance test result matches the hardware parameters;

[0143] In response to the performance test results matching the hardware parameters, the hardware parameters are recorded as the restart test results for the current round.

[0144] In some embodiments of the present invention, the method further includes:

[0145] In response to the mismatch between the performance test results and the hardware parameters, the hardware parameters corresponding to the performance test results are taken as the hardware parameters of the hardware, and the hardware parameters are classified as logical data anomalies.

[0146] In some embodiments of the present invention, analyzing the hardware status of the server after multiple restarts based on the hardware parameters further includes:

[0147] In response to the hardware parameters being functional parameters, the driver for the hardware with the specified hardware parameters is reloaded, and the hardware parameters of the hardware after the driver reload are recorded; and

[0148] Determine whether the hardware parameters obtained after reloading the driver are the same as the standard hardware parameters;

[0149] If the hardware parameters obtained after reloading the driver are different from the standard parameters but the same as the standard parameters, then the re-obtained hardware parameters are used as the hardware parameters for the current round, and the hardware parameters are classified as logical data anomalies.

[0150] In some embodiments of the present invention, the corrective verification of abnormal parameters in each restart also includes:

[0151] If the hardware parameters obtained after reloading the driver are still different from the standard parameters, the hardware parameters are used as the hardware parameters for the current round and classified as hardware parameter anomalies.

[0152] The above are exemplary embodiments disclosed in this invention. However, it should be noted that various changes and modifications can be made without departing from the scope of the embodiments of this invention as defined by the claims. The functions, steps, and / or actions of the methods according to the disclosed embodiments described herein do not need to be performed in any particular order. Furthermore, although the elements disclosed in the embodiments of this invention may be described or claimed individually, they may be understood as multiple unless explicitly limited to a singular number.

[0153] It should be understood that, as used herein, the singular form “a” is intended to include the plural form as well, unless the context clearly supports an exception. It should also be understood that, as used herein, “and / or” refers to any and all possible combinations of one or more of the associated listed items.

[0154] The embodiment numbers disclosed in the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0155] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0156] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of the invention (including the claims) is limited to these examples. Within the framework of the invention, technical features of the above embodiments or different embodiments can be combined, and many other variations of the different aspects of the invention as described above exist, which are not provided in the details for the sake of brevity. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the protection scope of the invention.

Claims

1. A method of reliability reboot testing, the method comprising: include: The hardware parameters on the server are collected through multiple restarts, and corrective verification is performed on abnormal parameters in each restart. The corrective verification of abnormal parameters in each restart includes: comparing the hardware parameters obtained in each restart with standard parameters to obtain a comparison result; in response to the comparison result being different, determining the function type of the hardware parameter with the different comparison result and the hardware state to which the hardware parameter belongs; in response to the hardware parameter being a performance parameter, performing a performance test on the hardware to which the hardware parameter belongs; in response to the performance test being completed, determining whether the performance test result matches the hardware parameter; in response to the performance test result matching the hardware parameter, recording the hardware parameter as the restart test result of the current round; in response to the performance test result not matching the hardware parameter, recording the hardware parameter corresponding to the performance test result as the hardware parameter of the hardware, and classifying the hardware parameter as a logical data anomaly; if the check... If the detected abnormal hardware parameter is a functional parameter, the model number of the hardware to which the abnormal hardware parameter belongs is obtained, and the corresponding driver is installed according to the model. After the driver is installed, the hardware parameter of this hardware is obtained again and compared with the standard parameter. If the hardware parameter obtained after driver installation is the same as the standard parameter, it means that the hardware itself is not abnormal, and the abnormality lies in the software layer driver or related settings of the operating system. In this case, the hardware parameter is marked as logical data abnormal. If the hardware parameter obtained after reinstalling the driver is still different from the standard parameter, it means that the software layer driver or related data of the operating system is not wrong, and the error lies in the hardware itself. In this case, the hardware parameter is directly used as the hardware parameter for the current round of testing, and the hardware parameter is classified as hardware parameter abnormal. Based on the hardware parameter, the server status after multiple restarts is statistically analyzed.

2. The method according to claim 1, characterized in that, The analysis of the server's hardware status after multiple restarts based on the hardware parameters includes: The hardware parameters of the server collected from multiple restarts are classified according to the hardware type to which the hardware parameters belong; The test results for various types of server hardware are presented based on the aforementioned classification.

3. A reliability restart testing system, characterized in that, include: The testing module is configured to collect hardware parameters on the server through multiple rounds of restarts and perform corrective checks on abnormal parameters in each round of restarts. An analysis module is configured to statistically analyze the server status after multiple restarts based on the hardware parameters. The corrective verification of abnormal parameters in each restart includes: comparing the hardware parameters obtained in each restart with standard parameters to obtain a comparison result; in response to a difference in the comparison result, determining the function type of the hardware parameter and the hardware state to which the hardware parameter belongs; in response to a performance parameter, performing a performance test on the hardware to which the hardware parameter belongs; in response to the completion of the performance test, determining whether the performance test result matches the hardware parameter; in response to a match between the performance test result and the hardware parameter, recording the hardware parameter as the restart test result for the current round; in response to a mismatch between the performance test result and the hardware parameter, recording the hardware parameter corresponding to the performance test result as the hardware parameter of the hardware, and classifying the hardware parameter as a logical data anomaly; for example... If the detected abnormal hardware parameter is a functional parameter, the model number of the hardware to which the abnormal hardware parameter belongs is obtained, and the corresponding driver is installed according to the model. After the driver is installed, the hardware parameter of the hardware is obtained again and compared with the standard parameter. If the hardware parameter obtained after driver installation is the same as the standard parameter, it means that the hardware itself is not abnormal, and the abnormality lies in the software layer driver or related settings of the operating system. In this case, the hardware parameter is marked as logical data abnormal. If the hardware parameter obtained after reinstalling the driver is still different from the standard parameter, it means that the software layer driver or related data of the operating system is not wrong, and the error lies in the hardware itself. In this case, the hardware parameter is directly used as the hardware parameter for the current round of testing of the hardware, and the hardware parameter is classified as hardware parameter abnormal. Based on the hardware parameter, the server status after multiple restarts is statistically analyzed.

4. A computer device, characterized in that, include: At least one processor; as well as A memory storing computer instructions executable on the processor, which, when executed by the processor, implement the steps of the method of claim 1 or 2.

5. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method of claim 1 or 2.

Images