Data analysis method and device of hard disk, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a hard disk data analysis method and device, electronic equipment and storage medium, the method comprises: in response to the test instruction for the hard disk, the test parameter corresponding to the hard disk is acquired, and the performance test is carried out on the test parameter, and the test log corresponding to each test parameter in the performance test process of the hard disk is captured through the log capture unit;The parameter detection log is converted into a CSV file through the log conversion unit;Through the data processing unit, each test parameter is extracted from the CSV file, and the test parameter is input into the corresponding standard statistical table for parameter detection, and the test result corresponding to each parameter detection log is generated;If the abnormal item appearing in the performance test process is contained in the performance test log by the log checking output unit, the reference test case corresponding to the abnormal item is determined, and the fault item corresponding to the test log is located in the electronic equipment based on the reference test case, and the prompt information for the fault item is output.

Description

Technical Field

[0001] This invention relates to the field of equipment testing technology, and in particular to a hard disk data analysis method, a hard disk data analysis device, an electronic device, and a computer-readable storage medium. Background Technology

[0002] Hard drive testing is a crucial part of the current electronics industry. As a primary storage medium, the stability and reliability of hard drives are increasingly important. Therefore, ensuring the reliability and quality of hard drives used in electronic devices is essential. With the increasing volume of data, the workload of hard drive testing—including data processing and checking various log files—also increases. Accurate and rapid data processing and log file inspection have become urgent problems to solve. Manually processing this data would be an enormous undertaking; therefore, a better solution is needed to address the issues of data processing and log file inspection. Summary of the Invention

[0003] This invention provides a data analysis method, apparatus, electronic device, and computer-readable storage medium for hard disks, to solve or partially solve the problems of large workload, error-proneness, and low testing efficiency caused by the large amount of data when testing hard disks in related technologies.

[0004] This invention discloses a hard disk data analysis method applied to an electronic device. The electronic device is equipped with a corresponding testing system and a testing device for testing the hard disk. The testing device includes at least a log capture unit, a log conversion unit, a data processing unit, and a log inspection and output unit. The method includes: In response to a test command for the hard drive, the test parameters corresponding to the hard drive are obtained, and performance tests are performed on the test parameters. The test logs corresponding to each test parameter during the performance test of the hard drive are captured by the log capture unit. The test logs include at least parameter detection logs and performance test logs. The parameter detection log is converted into a CSV file using the log conversion unit. The data processing unit extracts each test parameter from the CSV file and inputs the test parameters into the corresponding standard statistical table for parameter detection, generating test results for each parameter detection log. If the log inspection output unit detects that the performance test log contains an anomaly that occurred during the performance test, then a reference test case corresponding to the anomaly is determined, and based on the reference test case, the fault item corresponding to the test log is located in the electronic device, and a prompt message for the fault item is output.

[0005] Optionally, the step of extracting each test parameter from the CSV file through the data processing unit, inputting the test parameters into the corresponding standard statistical table for parameter detection, and generating test results corresponding to each parameter detection log includes: The data processing unit sequentially reads each of the CSV files to obtain the test parameters corresponding to each of the test items. The data processing unit inputs the test parameters into the corresponding standard statistical table and obtains the standard parameters corresponding to each test parameter in the standard statistical table. The test parameters are compared with the standard parameters to generate test results corresponding to the detection logs for each parameter.

[0006] Optionally, comparing the test parameters with the standard parameters to generate test results corresponding to the detection logs for each parameter includes: Obtain test variables for the test parameters, the test variables including at least queue depth and block size; Keeping other variables constant, the test parameters are grouped according to the queue depth and the block size, and the grouped data is written to a Tmp file; Each of the Tmp files is read sequentially, and while keeping the queue depth constant, the read and write bandwidth corresponding to the test parameters under each block specification level is obtained; The test parameters are compared with the read and write bandwidths corresponding to the block specifications of adjacent levels, and the test parameters whose first read and write bandwidth corresponding to the later block specification is less than 90% of the second read and write bandwidth corresponding to the earlier block specification are regarded as abnormal test items. Alternatively, while keeping the block specifications unchanged, obtain the read / write bandwidth corresponding to the test parameters at each queue depth level; The test parameters are compared with the read and write bandwidths corresponding to adjacent queue depths, and the test parameters in which the first read and write bandwidth corresponding to the next queue depth is less than 90% of the second read and write bandwidth corresponding to the previous queue depth are regarded as abnormal test items. Set the CSV file corresponding to the abnormal test item as an abnormal CSV file, and output the abnormal CSV file corresponding to each of the test logs.

[0007] Optionally, the step of comparing the test parameters with the standard parameters to generate test results corresponding to the detection logs for each parameter further includes: If the abnormal CSV file does not exist, the test pass result corresponding to each of the test logs is output, and the test pass result is used to indicate that the test parameters are qualified.

[0008] Optionally, determining the reference test case corresponding to the anomaly, locating the fault item corresponding to the test log in the electronic device based on the reference test case, and outputting a prompt message for the fault item includes: The log inspection output unit obtains the failed test cases, the first keyword corresponding to the failed test cases, and the historical analysis report of the hard drive during the historical testing process. Extract the corresponding second keyword from the abnormal performance test log containing anomalies that occurred during the performance test. The second keyword is information used to characterize the test parameter test anomalies in the abnormal performance test log. The historical analysis report corresponding to the failed test case to which the first keyword that successfully matches the second keyword belongs shall be used as the target analysis report of the abnormal performance test log; Based on the target analysis report, locate the fault item in the electronic device that corresponds to the abnormal performance test log, and output a prompt message for the fault item.

[0009] Optionally, the step of locating the fault item corresponding to the test log in the electronic device according to the target analysis report and outputting prompt information for the fault item includes: The target analysis includes extracting test failure items from the corresponding failed test cases, using the failure items as target failure items in the abnormal performance test log, and outputting prompt information for the target failure items and the test results.

[0010] Optionally, the abnormal performance test log includes at least one of the following: smart log, messages log, lspci log, and dmesg log.

[0011] This invention also discloses a hard disk data analysis device applied to electronic devices. The testing device includes at least a log capture unit, a log conversion unit, a data processing unit, and a log inspection and output unit; wherein... The log capture unit is used to respond to the test command for the hard disk, obtain the test parameters corresponding to the hard disk, perform performance tests on the test parameters, and capture the test logs corresponding to each test parameter during the performance test of the hard disk. The test logs include at least parameter detection logs and performance test logs. The log conversion unit is used to convert the parameter detection log into a CSV file; The data processing unit is used to extract each of the test parameters from the CSV file, input the test parameters into the corresponding standard statistical table for parameter detection, and generate test results corresponding to each of the parameter detection logs. The log inspection and output unit is used to determine the reference test case corresponding to the anomaly that occurred during the performance test if the performance test log is found to contain an anomaly. Based on the reference test case, the unit locates the fault item corresponding to the test log in the electronic device and outputs a prompt message for the fault item.

[0012] Optionally, the data processing unit is specifically used for: The data processing unit sequentially reads each of the CSV files to obtain the test parameters corresponding to each of the test items. The data processing unit inputs the test parameters into the corresponding standard statistical table and obtains the standard parameters corresponding to each test parameter in the standard statistical table. The test parameters are compared with the standard parameters to generate test results corresponding to the detection logs for each parameter.

[0013] Optionally, the data processing unit is specifically used for: Obtain test variables for the test parameters, the test variables including at least queue depth and block size; Keeping other variables constant, the test parameters are grouped according to the queue depth and the block size, and the grouped data is written to a Tmp file; Each of the Tmp files is read sequentially, and while keeping the queue depth constant, the read and write bandwidth corresponding to the test parameters under each block specification level is obtained; The test parameters are compared with the read and write bandwidths corresponding to the block specifications of adjacent levels, and the test parameters whose first read and write bandwidth corresponding to the later block specification is less than 90% of the second read and write bandwidth corresponding to the earlier block specification are regarded as abnormal test items. Alternatively, while keeping the block specifications unchanged, obtain the read / write bandwidth corresponding to the test parameters at each queue depth level; The test parameters are compared with the read and write bandwidths corresponding to adjacent queue depths, and the test parameters in which the first read and write bandwidth corresponding to the next queue depth is less than 90% of the second read and write bandwidth corresponding to the previous queue depth are regarded as abnormal test items. Set the CSV file corresponding to the abnormal test item as an abnormal CSV file, and output the abnormal CSV file corresponding to each of the test logs.

[0014] Optionally, the data processing unit is further used for: If the abnormal CSV file does not exist, the test pass result corresponding to each of the test logs is output, and the test pass result is used to indicate that the test parameters are qualified.

[0015] Optionally, the detection via the logs is specifically used for: The log inspection output unit obtains the failed test cases, the first keyword corresponding to the failed test cases, and the historical analysis report of the hard drive during the historical testing process. Extract the corresponding second keyword from the abnormal performance test log containing anomalies that occurred during the performance test. The second keyword is information used to characterize the test parameter test anomalies in the abnormal performance test log. The historical analysis report corresponding to the failed test case to which the first keyword that successfully matches the second keyword belongs shall be used as the target analysis report of the abnormal performance test log; Based on the target analysis report, locate the fault item in the electronic device that corresponds to the test log, and output a prompt message for the fault item.

[0016] Optionally, the detection via the logs is specifically used for: The target analysis includes extracting test failure items from the corresponding failed test cases, using the failure items as target failure items in the abnormal performance test log, and outputting prompt information for the target failure items.

[0017] Optionally, the test logs include at least one of the following: smart logs, messages logs, lspci logs, and dmesg logs.

[0018] This invention also discloses an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method described in the embodiments of the present invention.

[0019] This invention also discloses a computer-readable storage medium storing instructions that, when executed by one or more processors, cause the processors to perform the methods described in this invention.

[0020] The embodiments of the present invention have the following advantages: In this embodiment of the invention, a corresponding testing device can be deployed on an electronic device. This testing device may include a log capture unit, a log conversion unit, a data processing unit, and a log inspection and output unit. During the testing of the hard drive of the electronic device, in response to test commands for the hard drive, the corresponding test parameters can be obtained, and performance tests can be performed on these parameters. The log capture unit captures test logs corresponding to each test parameter during the performance test. The captured test logs may include parameter detection logs and performance test logs. Then, the log conversion unit converts the parameter detection logs into a CSV file. The data processing unit extracts each test parameter from the CSV file and inputs the test parameters into a corresponding standard statistical table for parameter detection, generating test results corresponding to each parameter detection log. Simultaneously, if... The log inspection output unit detects anomalies in the performance test logs that occurred during the performance test. It then identifies the corresponding reference test cases and, based on these cases, locates the fault items in the electronic device corresponding to the test logs. It outputs prompts for these fault items. By setting different units to perform different data processing operations, on the one hand, during the testing of the electronic device's hard drive, the data processing unit checks the parameter detection logs related to the test parameters, achieving fully automated hard drive performance testing and improving efficiency. On the other hand, during the hard drive performance testing process, the relevant performance test logs are analyzed, and the corresponding fault items are located, reducing the failure rate caused by misjudgment and facilitating timely handling of fault items by testers, further ensuring the stability of the electronic device's hard drive operation. Attached Figure Description

[0021] Figure 1 This is a flowchart of the steps of a hard disk data analysis method provided in an embodiment of the present invention; Figure 2 This is a structural block diagram of a hard disk data analysis device provided in an embodiment of the present invention; Figure 3 This is a block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0022] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] As an example, hard drive testing is a crucial part of the current electronics industry. As the primary storage medium, the stability and reliability of hard drives are increasingly important. Therefore, ensuring the reliability and quality of hard drives used in electronic devices is essential. With increasing volume, the workload of processing data and checking various log files during hard drive testing also increases. Accurate and rapid data processing and log file checking have become urgent problems to solve. Manually processing this data would be a massive undertaking, necessitating an automated solution to address data processing and log file checking. This would improve accuracy while saving time and effort.

[0024] Currently, the method for processing hard drive test data involves using automated plotting tools to create performance and bandwidth scatter plots. These scatter plots are then combined with the test data and processed using Excel spreadsheets to determine the final compliance status. Furthermore, the current method for collecting logs from hard drive tests primarily relies on manual inspection of error and fail entries. This is labor-intensive, error-prone, and makes it difficult to manually pinpoint faulty items within the log files, hindering problem-solving.

[0025] One of the core inventive points of this invention lies in deploying a corresponding testing device on the electronic device. This testing device may include a log capture unit, a log conversion unit, a data processing unit, and a log inspection and output unit. During the testing of the hard drive of the electronic device, in response to test commands for the hard drive, the corresponding test parameters can be obtained, and performance tests can be performed on these parameters. The log capture unit captures test logs corresponding to each test parameter during the performance test. The captured test logs may include parameter detection logs and performance test logs. Then, the log conversion unit converts the parameter detection logs into a CSV file. The data processing unit extracts each test parameter from the CSV file and inputs the test parameters into a corresponding standard statistical table for parameter detection, generating test results for each parameter detection log. Simultaneously, if... By checking the log output unit and identifying anomalies in the performance test logs, corresponding reference test cases are determined. Based on these reference test cases, the fault items corresponding to the test logs are located in the electronic device, and prompts are output for these fault items. By setting different units to perform different data processing operations, on the one hand, during the testing of the electronic device's hard drive, the data processing unit checks the parameter detection logs related to the test parameters, achieving fully automated hard drive performance testing and improving the efficiency of hard drive performance testing. On the other hand, during the hard drive performance testing process, the performance test logs are analyzed, and the corresponding fault items are located, reducing the failure rate caused by misjudgment of faults and facilitating timely handling of fault items by testers, further ensuring the stability of the electronic device's hard drive operation.

[0026] Reference Figure 1 This diagram illustrates a flowchart of a hard disk data analysis method provided in an embodiment of the present invention. The method is applied to an electronic device, which is equipped with a corresponding testing system and a testing device for testing the hard disk. The testing device includes at least a log capture unit, a log conversion unit, a data processing unit, and a log inspection and output unit. Specifically, it may include the following steps: Step 101: In response to the test command for the hard disk, obtain the test parameters corresponding to the hard disk, perform performance testing on the test parameters, and capture the test logs corresponding to each test parameter during the performance testing of the hard disk through the log capture unit. The test logs include at least parameter detection logs and performance test logs. Optionally, for electronic devices, the stability and reliability of hard drives, as the main carriers of electronic devices, are receiving increasing attention. Therefore, it is necessary to test the performance of hard drives of electronic devices regularly or irregularly to determine whether the hard drive can meet the daily operating needs of electronic devices.

[0027] In this embodiment of the invention, a corresponding testing device can be configured in an electronic device. This testing device may include a log capture unit, a log conversion unit, a data processing unit, and a log check and output unit. The log capture unit collects test logs during hard drive performance testing. These test logs may include parameter detection logs corresponding to test parameters, recording the corresponding test parameters, as well as performance test logs unrelated to the test parameters but related to the test results during the test process. These performance test logs may include information such as whether any test items are abnormal. The log conversion unit converts the corresponding parameter detection logs into a file of a specified format for analyzing the test parameters involved in that file. The data processing unit analyzes the file converted by the log conversion unit, extracting the corresponding test parameters from the file and comparing them with standard parameter values ​​to analyze the test parameters. After analysis, it outputs the corresponding test results. The log check and output unit detects and analyzes the performance test logs related to the performance test results captured by the log capture unit and outputs the corresponding detection results.

[0028] Optionally, due to the high failure rate of automated tasks during testing, a large number of automated analysis report tasks are generated during testing. Testers need to spend a lot of time analyzing these reports to find problems and solutions. Because of the large workload, unresolved issues can lead to long-term, repetitive analysis work. To address this, a corresponding reference template can be configured in the log inspection output unit to analyze the performance test logs during hard drive testing. Specifically, this can be achieved by obtaining failed test cases from historical testing processes, along with the corresponding historical test logs and analysis conclusions. Then, keywords can be extracted from the failed test cases, and a correspondence between keywords and historical analysis conclusions can be established to obtain the corresponding reference template. Thus, during the current performance test of the hard drive, once the test results are determined, the log inspection transmission unit can analyze the performance test logs. By selecting a reference template and using the test logs and analysis conclusions of the failed test cases as the reference template, the matching reliability and accuracy of the log inspection output unit can be improved.

[0029] In practice, testers can input corresponding test commands into electronic devices, and the testing device can respond to the test commands for the hard drive, obtain the corresponding test parameters of the hard drive, perform performance tests on the test parameters, and capture test logs corresponding to each test parameter during the performance test of the hard drive through the log capture unit.

[0030] In one example, a corresponding test environment can be set up on an electronic device, and the corresponding test system and test tools required for the test can be installed. Then, the test script can be copied to the electronic device, where the test script can be a test device. During the performance test of the hard drive, a full scan of the hard drive can be performed through the log capture unit to achieve a health check. After the health check is passed, the corresponding test parameters of the hard drive can be obtained. Then, the performance of the hard drive can be tested based on the test parameters, and the logs generated during the performance test can be collected.

[0031] Step 102: The parameter detection log is converted into a CSV file by the log conversion unit; In the specific implementation, after the hard drive performance test is completed, the log conversion unit can convert the parameter detection logs generated during the performance test into a CSV file (Comma-Separated Values). In this CSV file, the parameter data can be stored in plain text format, and the table format of the CSV file is consistent with the table format of the standard statistical table in the data processing unit. This allows the data processing unit to extract the corresponding test parameters from the CSV file and compare the test parameters with the standard parameter values ​​in the standard statistical table, thereby realizing the analysis of the hard drive performance test.

[0032] Step 103: Extract each test parameter from the CSV file through the data processing unit, input the test parameters into the corresponding standard statistical table for parameter detection, and generate test results corresponding to each parameter detection log; In this embodiment of the invention, the data processing unit can sequentially read each CSV file to obtain the test parameters corresponding to each test item; the data processing unit can input the test parameters into the corresponding standard statistical table and obtain the standard parameters corresponding to each test parameter in the standard statistical table; the test parameters can be compared with the standard parameters to generate the test results corresponding to each parameter detection log. Thus, by setting different units to perform different data processing operations, during the testing of the hard drive of electronic devices, test content that does not meet the test standards can be output, realizing fully automated performance testing of the hard drive and improving the efficiency of hard drive performance testing.

[0033] In a specific implementation, the data processing unit can obtain test variables for test parameters. The test variables at least include queue depth and block specification. Then, it can keep other variables unchanged, group the test parameters according to the queue depth and block specification, and write the grouped data into Tmp (Tmp files, garbage files). Then, it reads each Tmp file in turn. While keeping the queue depth unchanged, it obtains the read / write bandwidth corresponding to the test parameters under the block specifications of each level. Then, it compares the read / write bandwidths corresponding to the test parameters under the block specifications of adjacent levels, and takes the test parameters whose first read / write bandwidth corresponding to the block specification of the latter level is less than 90% of the second read / write bandwidth corresponding to the block specification of the previous level as abnormal test items. Alternatively, the data processing unit can, while keeping the block specification unchanged, obtain the read / write bandwidth corresponding to the test parameters under the queue depths of each level. Then, it compares the read / write bandwidths corresponding to the test parameters under the queue depths of adjacent levels, and takes the test parameters whose first read / write bandwidth corresponding to the queue depth of the latter level is less than 90% of the second read / write bandwidth corresponding to the queue depth of the previous level as abnormal test items. Finally, it sets the CSV file corresponding to the abnormal test items as an abnormal CSV file and outputs the abnormal CSV files corresponding to each parameter detection log. In addition, if there is no abnormal CSV file, it outputs the test pass results corresponding to each parameter detection log. The test pass results are used to indicate that the test parameters are qualified.

[0034] In one example, in the data processing unit, a standard parameter value statistical table is set up to determine whether the test parameters are consistent with the standard parameter values. Each CSV file of each test is read in turn, and all data is grouped in the way that only QD (Queue Depth) changes or only BS (Block Size) changes while keeping other items unchanged. Each group of data is written into a separate tmp file. Each tmp file is read once. With BS unchanged, it successively compares whether the read / write bandwidth of the latter QD is lower than 90% of the previous QD. If it is lower, it records the position lower than the standard and writes it into fail.csv. With QD unchanged, it successively compares whether the read / write bandwidth of the latter BS is lower than 90% of the previous BS. If it is lower, it records the position lower than the standard and writes it into fail.csv. The verification result is obtained, and all fail.csv files are output. If no fail file is output, it proves that the test data is qualified. For example, for QD, it can include different levels of queue depth such as QD1, QD2, QD4, QD8, QD16, QD32, QD64, and QD128. For BS, it can include different levels of block specification such as 4kb, 8kb, 16kb, etc. Then, based on the combination of the two, while keeping one test variable unchanged, performance analysis of the test parameters can be carried out based on different levels of the other variable. The present invention does not limit this.

[0035] Step 104: If the performance test log is found to contain an anomaly that occurred during the performance test through the log inspection output unit, a reference test case corresponding to the anomaly is determined, and based on the reference test case, the fault item corresponding to the test log is located in the electronic device, and a prompt message for the fault item is output.

[0036] In this embodiment of the invention, the performance test log may include at least one of the following: smart log, messages log, lspci log, and dmesg log. While the data processing unit performs performance analysis on the test parameters corresponding to the hard drive and outputs the corresponding test results, the log inspection and output unit can simultaneously detect and analyze the performance test log to determine whether there are any abnormal items during the performance test. Specifically, if the log inspection and output unit detects that the performance test log contains abnormal items that occurred during the performance test, a reference test case corresponding to the abnormal item is determined, and based on the reference test case, the fault item corresponding to the test log is located in the electronic device, and a prompt message for the fault item is output. Thus, during the hard drive performance test, the relevant performance test log is analyzed and the fault item corresponding to the performance test log is located, reducing the failure rate caused by misjudgment of faults and facilitating timely handling of fault items by testers, further ensuring the stability of the hard drive operation of the electronic device.

[0037] It should be noted that the log inspection output unit examines the performance test log files; it sets filter keywords to filter the performance test logs, and then uses the filtered content to locate faults. Different reference templates and filter keywords can be set for different logs in the test. If there is no output, it outputs "PASS"; if there is output, different reference templates are set for the output content to locate the cause of the fault.

[0038] In the specific implementation, the log inspection output unit can obtain the failed test cases, the first keyword corresponding to the failed test cases, and the historical analysis report corresponding to the hard drive in the historical testing process. When an anomaly is detected in the performance test log, the log inspection output unit can extract the corresponding second keyword from the abnormal performance test log containing the anomaly that occurred during the performance test. The second keyword is used to characterize the test parameter test anomaly in the abnormal performance test log. Then, the historical analysis report corresponding to the failed test case to which the first keyword that matches the second keyword belongs is used as the target analysis report of the abnormal performance test log. Then, based on the target analysis report, the fault item corresponding to the test log is located in the electronic device, and the prompt information for the fault item is output.

[0039] During the output prompt process, the log inspection output unit can employ target analysis, including extracting test failure items from the corresponding failed test cases and using these failure items as target failure items in the performance test logs. It then outputs prompt information for these target failure items. This allows for simultaneous analysis of the performance test logs during hard drive performance testing, locating the corresponding failure items, reducing the failure rate caused by misjudgments, and facilitating timely handling of failure items by testers. This further ensures the stability of the hard drive operation in electronic devices.

[0040] In one example, an electronic device is used as a server for illustrative purposes. It is understood that the electronic device may also include mobile terminals, PC terminals, etc. The process involved in testing the server's hard drive may include: 1. Set up the test environment: Select an electronic device as the test machine, install the test system and the test tools required for the test, and copy the test script to the test machine; 2. In the log capture unit, a full disk scan is performed to conduct a health check. After the health check passes, logs are collected and performance tests are conducted. 3. In the data processing unit, the test results are input into a standard statistical table for statistical processing. After processing, a result file is generated, which contains a detailed test analysis report for each item, presented in PASS and FAIL format for easy analysis. 4. In the data processing unit, the test results are input into a standard statistical table for statistical processing. After processing, a result file is generated, which contains a detailed test analysis report for each item, presented in PASS and FAIL format for easy analysis. 5. For performance test log files, the log inspection output unit will inspect the log files, compare them with the set reference template, and output the inspection results. For example, for hard drive performance testing, the logs that need to be inspected are usually smart logs, message logs, lspci logs, dmesg logs, etc. This invention will analyze these logs and output the results in the following format: The result is the output of pass: Smart logs: No new counts were added for information such as critical_warning, media_errors, num_err_log_entries, and WarningTemperature Time; smart log check passed. Messages logs: No exception logs such as controller reset, io cancel, or io error are printed; message check is passed. dmesg log: No errors reported, inspection passed; lspci log: LnkSta basic information check passed, UESta and CESta have no abnormalities, check passed.

[0041] When the log check results include a "fail" item, such as when checking the messages log and finding an error, the error content will be directly output. Based on the template in the log check output unit, the location of the error can be determined, and it can be seen which component is causing the error, such as the CPU, memory, BMC, etc. This helps testers to directly locate the module, communicate with the relevant R&D personnel, and resolve the problem in a timely manner.

[0042] The reliability and accuracy of this step are closely related to the reference template. The template needs to be updated in real time and continuously improved in order to make the analysis report more accurate.

[0043] In this embodiment of the invention, a corresponding testing device can be deployed on an electronic device. This testing device may include a log capture unit, a log conversion unit, a data processing unit, and a log inspection and output unit. During the testing of the hard drive of the electronic device, in response to test commands for the hard drive, the corresponding test parameters can be obtained, and performance tests can be performed on these parameters. The log capture unit captures test logs corresponding to each test parameter during the performance test. The captured test logs may include parameter detection logs and performance test logs. Then, the log conversion unit converts the parameter detection logs into a CSV file. The data processing unit extracts each test parameter from the CSV file and inputs the test parameters into a corresponding standard statistical table for parameter detection, generating test results corresponding to each parameter detection log. Simultaneously, if... The log inspection output unit detects anomalies in the performance test logs that occurred during the performance test. It then identifies the corresponding reference test cases and, based on these cases, locates the fault items in the electronic device corresponding to the test logs. It outputs prompts for these fault items. By setting different units to perform different data processing operations, on the one hand, during the testing of the electronic device's hard drive, the data processing unit checks the parameter detection logs related to the test parameters, achieving fully automated hard drive performance testing and improving efficiency. On the other hand, during the hard drive performance testing process, the relevant performance test logs are analyzed, and the corresponding fault items are located, reducing the failure rate caused by misjudgment and facilitating timely handling of fault items by testers, further ensuring the stability of the electronic device's hard drive operation.

[0044] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0045] Reference Figure 2 This diagram illustrates a structural block diagram of a hard disk data analysis device provided in an embodiment of the present invention, applied to electronic devices. The testing device includes at least a log capture unit 201, a log conversion unit 202, a data processing unit 203, and a log inspection and output unit; wherein, The log capture unit 201 is used to respond to a test command for the hard disk, obtain the test parameters corresponding to the hard disk, perform performance tests on the test parameters, and capture test logs corresponding to each test parameter during the performance test of the hard disk. The test logs include at least parameter detection logs and performance test logs. The log conversion unit 202 is used to convert the parameter detection log into a CSV file; The data processing unit 203 is used to extract each of the test parameters from the CSV file, input the test parameters into the corresponding standard statistical table for parameter detection, and generate test results corresponding to each of the parameter detection logs. The log inspection output unit 204 is used to determine a reference test case corresponding to the abnormal item if the performance test log contains an abnormal item that occurred during the performance test, and to locate the fault item corresponding to the test log in the electronic device based on the reference test case, and output a prompt message for the fault item.

[0046] In one alternative embodiment, the data processing unit 203 is specifically used for: The data processing unit 203 sequentially reads each of the CSV files to obtain the test parameters corresponding to each of the test items. The data processing unit 203 inputs the test parameters into the corresponding standard statistical table and obtains the standard parameters corresponding to each test parameter in the standard statistical table. The test parameters are compared with the standard parameters to generate test results corresponding to the detection logs for each parameter.

[0047] In one alternative embodiment, the data processing unit 203 is specifically used for: Obtain test variables for the test parameters, the test variables including at least queue depth and block size; Keeping other variables constant, the test parameters are grouped according to the queue depth and the block size, and the grouped data is written to a Tmp file; Each of the Tmp files is read sequentially, and while keeping the queue depth constant, the read and write bandwidth corresponding to the test parameters under each block specification level is obtained; The test parameters are compared with the corresponding read and write bandwidths under adjacent block specifications, and the test parameters whose first read and write bandwidth corresponding to the later block specification is less than 90% of the second read and write bandwidth corresponding to the earlier block specification are regarded as abnormal test items. Alternatively, while keeping the block specifications unchanged, obtain the read / write bandwidth corresponding to the test parameters at each queue depth level; The test parameters are compared with the read and write bandwidths corresponding to adjacent queue depths, and the test parameters in which the first read and write bandwidth corresponding to the next queue depth is less than 90% of the second read and write bandwidth corresponding to the previous queue depth are regarded as abnormal test items. Set the CSV file corresponding to the abnormal test item as an abnormal CSV file, and output the abnormal CSV file corresponding to each of the test logs.

[0048] In an optional embodiment, the data processing unit 203 is further used for: If the abnormal CSV file does not exist, the test pass result corresponding to each of the test logs is output, and the test pass result is used to indicate that the test parameters are qualified.

[0049] In one alternative embodiment, the detection via the log is specifically used for: The log inspection output unit 204 obtains the failed test cases, the first keyword corresponding to the failed test cases, and the historical analysis report of the hard drive during the historical testing process. Extract the corresponding second keyword from the abnormal performance test log containing anomalies that occurred during the performance test. The second keyword is information used to characterize the test parameter test anomalies in the abnormal performance test log. The historical analysis report corresponding to the failed test case to which the first keyword that successfully matches the second keyword belongs shall be used as the target analysis report of the abnormal performance test log; Based on the target analysis report, locate the fault item in the electronic device that corresponds to the test log, and output a prompt message for the fault item.

[0050] In one alternative embodiment, the detection via the log is specifically used for: The target analysis includes extracting test failure items from the corresponding failed test cases, using the failure items as target failure items in the abnormal performance test log, and outputting prompt information for the target failure items.

[0051] In one alternative embodiment, the test log includes at least one of the following: smart log, messages log, lspci log, and dmesg log.

[0052] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0053] In addition, this invention also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the above-described hard disk data analysis method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0054] This invention also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the aforementioned hard disk data analysis method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0055] Figure 3 A schematic diagram of the hardware structure of an electronic device for implementing various embodiments of the present invention. The electronic device 300 includes, but is not limited to, components such as: a radio frequency unit 301, a network module 302, an audio output unit 303, an input unit 304, a sensor 305, a display unit 306, a user input unit 307, an interface unit 308, a memory 309, a processor 310, and a power supply 311. Those skilled in the art will understand that the electronic device structure involved in the embodiments of the present invention does not constitute a limitation on the electronic device. An electronic device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of the present invention, the electronic device includes, but is not limited to, mobile phones, tablet computers, laptop computers, PDAs, in-vehicle terminals, wearable devices, and pedometers.

[0056] It should be understood that, in this embodiment of the invention, the radio frequency unit 301 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink data from the base station and processes it with the processor 310; additionally, it transmits uplink data to the base station. Typically, the radio frequency unit 301 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier, a duplexer, etc. Furthermore, the radio frequency unit 301 can also communicate with networks and other devices through a wireless communication system.

[0057] The electronic device provides users with wireless broadband internet access through network module 302, such as helping users send and receive emails, browse web pages, and access streaming media.

[0058] The audio output unit 303 can convert audio data received by the radio frequency unit 301 or the network module 302 or stored in the memory 309 into audio signals and output them as sound. Furthermore, the audio output unit 303 can also provide audio output related to specific functions performed by the electronic device 300 (e.g., call signal reception sound, message reception sound, etc.). The audio output unit 303 includes a speaker, a buzzer, and a receiver, etc.

[0059] Input unit 304 is used to receive audio or video signals. Input unit 304 may include a graphics processing unit (GPU) 3041 and a microphone 3042. The GPU 3041 processes image data of still images or videos acquired by an image capture device (such as a camera) in video capture mode or image capture mode. The processed image frames can be displayed on display unit 306. The image frames processed by GPU 3041 can be stored in memory 309 (or other storage media) or transmitted via radio frequency unit 301 or network module 302. Microphone 3042 can receive sound and process such sound into audio data. The processed audio data can be converted into a format that can be transmitted to a mobile communication base station via radio frequency unit 301 in telephone call mode.

[0060] The electronic device 300 also includes at least one sensor 305, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 3061 according to the ambient light level, and the proximity sensor can turn off the display panel 3061 and / or backlight when the electronic device 300 is moved to the ear. As a type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity and can be used to identify the posture of the electronic device (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc. The sensor 305 may also include a fingerprint sensor, pressure sensor, iris sensor, molecular sensor, gyroscope, barometer, hygrometer, thermometer, infrared sensor, etc., which will not be described in detail here.

[0061] The display unit 306 is used to display information input by the user or information provided to the user. The display unit 306 may include a display panel 3061, which may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like.

[0062] User input unit 307 can be used to receive input numerical or character information, and generate key signal inputs related to user settings and function control of electronic devices. Specifically, user input unit 307 includes touch panel 3071 and other input devices 3072. Touch panel 3071, also known as a touch screen, can collect touch operations on or near the user (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near touch panel 3071). Touch panel 3071 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to processor 310, which receives and executes commands from processor 310. In addition, touch panel 3071 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to touch panel 3071, user input unit 307 may also include other input devices 3072. Specifically, other input devices 3072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, joysticks, etc., which will not be described in detail here.

[0063] Furthermore, the touch panel 3071 can cover the display panel 3061. When the touch panel 3071 detects a touch operation on or near it, it transmits the information to the processor 310 to determine the type of touch event. Subsequently, the processor 310 provides corresponding visual output on the display panel 3061 according to the type of touch event. It is understood that in one embodiment, the touch panel 3071 and the display panel 3061 are implemented as two independent components to realize the input and output functions of the electronic device. However, in some embodiments, the touch panel 3071 and the display panel 3061 can be integrated to realize the input and output functions of the electronic device. The specific implementation is not limited here.

[0064] Interface unit 308 serves as an interface for connecting external devices to electronic device 300. For example, external devices may include a wired or wireless headphone port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device with an identification module, an audio input / output (I / O) port, a video I / O port, a headphone port, and so on. Interface unit 308 can be used to receive input from external devices (e.g., data, power, etc.) and transmit the received input to one or more components within electronic device 300, or it can be used to transmit data between electronic device 300 and external devices.

[0065] The memory 309 can be used to store software programs and various data. The memory 309 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback, image playback, etc.), etc.; the data storage area may store data created based on the use of the mobile phone (such as audio data, phonebook, etc.). Furthermore, the memory 309 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0066] The processor 310 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 309, and by calling data stored in the memory 309, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. The processor 310 may include one or more processing units; preferably, the processor 310 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 310.

[0067] The electronic device 300 may also include a power supply 311 (such as a battery) for supplying power to various components. Preferably, the power supply 311 can be logically connected to the processor 310 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system.

[0068] In addition, the electronic device 300 includes some functional modules not shown, which will not be described in detail here.

[0069] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0070] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0071] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

[0072] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0073] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0074] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0075] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0076] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0077] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0078] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A data analysis method for a hard disk, characterized in that, The method is applied to electronic devices, which are equipped with a corresponding testing system and a testing device for testing hard drives. The testing device includes at least a log capture unit, a log conversion unit, a data processing unit, and a log inspection and output unit. In response to a test command for the hard drive, the test parameters corresponding to the hard drive are obtained, and performance tests are performed on the test parameters. The test logs corresponding to each test parameter during the performance test of the hard drive are captured by the log capture unit. The test logs include at least parameter detection logs and performance test logs. The parameter detection log is converted into a CSV file using the log conversion unit. The data processing unit extracts each test parameter from the CSV file and inputs the test parameters into the corresponding standard statistical table for parameter detection, generating test results for each parameter detection log. If the log inspection output unit detects that the performance test log contains an anomaly that occurred during the performance test, then a reference test case corresponding to the anomaly is determined, and based on the reference test case, the fault item corresponding to the test log is located in the electronic device, and a prompt message for the fault item is output.

2. The method according to claim 1, characterized in that, The process involves extracting each test parameter from the CSV file using the data processing unit, inputting the test parameters into a corresponding standard statistical table for parameter detection, and generating test results for each parameter detection log, including: The data processing unit sequentially reads each of the CSV files to obtain the test parameters corresponding to each test item. The data processing unit inputs the test parameters into the corresponding standard statistical table and obtains the standard parameters corresponding to each test parameter in the standard statistical table. The test parameters are compared with the standard parameters to generate test results corresponding to the detection logs for each parameter.

3. The method according to claim 2, characterized in that, The step of comparing the test parameters with the standard parameters and generating test results corresponding to the detection logs for each parameter includes: Obtain test variables for the test parameters, the test variables including at least queue depth and block size; Keeping other variables constant, the test parameters are grouped according to the queue depth and the block size, and the grouped data is written to a Tmp file; Each of the Tmp files is read sequentially, and while keeping the queue depth constant, the read and write bandwidth corresponding to the test parameters under each block specification level is obtained; The test parameters are compared with the read and write bandwidths corresponding to the block specifications of adjacent levels, and the test parameters whose first read and write bandwidth corresponding to the later block specification is less than 90% of the second read and write bandwidth corresponding to the earlier block specification are regarded as abnormal test items. Alternatively, while keeping the block specifications unchanged, obtain the read / write bandwidth corresponding to the test parameters at each queue depth level; The test parameters are compared with the read and write bandwidths corresponding to adjacent queue depths, and the test parameters in which the first read and write bandwidth corresponding to the next queue depth is less than 90% of the second read and write bandwidth corresponding to the previous queue depth are regarded as abnormal test items. Set the CSV file corresponding to the abnormal test item as an abnormal CSV file, and output the abnormal CSV file corresponding to each of the test logs.

4. The method according to claim 3, characterized in that, The step of comparing the test parameters with the standard parameters and generating test results corresponding to the detection logs for each parameter further includes: If the abnormal CSV file does not exist, the test pass result corresponding to each of the test logs is output, and the test pass result is used to indicate that the test parameters are qualified.

5. The method according to claim 1, 3, or 4, characterized in that, The process of determining a reference test case corresponding to the anomaly, locating the fault item corresponding to the test log in the electronic device based on the reference test case, and outputting a prompt message for the fault item includes: The log inspection output unit obtains the failed test cases, the first keyword corresponding to the failed test cases, and the historical analysis report of the hard drive during the historical testing process. Extract the corresponding second keyword from the abnormal performance test log containing anomalies that occurred during the performance test. The second keyword is information used to characterize the test parameter test anomalies in the abnormal performance test log. The historical analysis report corresponding to the failed test case to which the first keyword that successfully matches the second keyword belongs shall be used as the target analysis report of the abnormal performance test log; Based on the target analysis report, locate the fault item in the electronic device that corresponds to the test log, and output a prompt message for the fault item.

6. The method according to claim 5, characterized in that, The step of locating the fault item corresponding to the test log in the electronic device according to the target analysis report and outputting prompt information for the fault item includes: The target analysis includes extracting test failure items from the corresponding failed test cases, using the failure items as target failure items in the abnormal performance test log, and outputting prompt information for the target failure items.

7. The method according to claim 1, characterized in that, The performance test logs include at least one of the following: smart logs, messages logs, lspci logs, and dmesg logs.

8. A hard disk data analysis device, characterized in that, This technology is applied to electronic devices, which are equipped with a corresponding testing system and a testing device for testing hard drives. The testing device includes at least a log capture unit, a log conversion unit, a data processing unit, and a log inspection and output unit. The log capture unit is used to respond to the test command for the hard disk, obtain the test parameters corresponding to the hard disk, perform performance tests on the test parameters, and capture the test logs corresponding to each test parameter during the performance test of the hard disk. The test logs include at least parameter detection logs and performance test logs. The log conversion unit is used to convert the parameter detection log into a CSV file; The data processing unit is used to extract each of the test parameters from the CSV file, input the test parameters into the corresponding standard statistical table for parameter detection, and generate test results corresponding to each of the parameter detection logs. The log inspection and output unit is used to determine the reference test case corresponding to the anomaly that occurred during the performance test if the performance test log is found to contain an anomaly. Based on the reference test case, the unit locates the fault item corresponding to the test log in the electronic device and outputs a prompt message for the fault item.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method as described in any one of claims 1-7.

10. A computer-readable storage medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the method as described in any one of claims 1-7.

Images