Solid state disk testing method and device, electronic equipment and storage medium
The method and apparatus for testing SSDs in normal and abnormal scenarios enhance reliability by objectively verifying self-diagnostic functions, reducing failure risks and improving SSD maintainability through automated testing.
Patent Information
- Application Number
- CN202510564450.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-30
- Publication Date
- 2025-07-15
AI Technical Summary
The failure rate of solid-state drives is high, and it is difficult for the existing technology to effectively detect and prevent failures.
By constructing conventional and abnormal scenarios, sending self-test trigger instructions to the carrier device, generating self-test logs, obtaining and analyzing self-test logs to verify whether the self-test function of the solid-state hard disk is normal, and performing automated testing with a physically isolated test device.
It improves the reliability of the solid-state drive, reduces the risk of failure, realizes reliable detection and timely feedback of the self-test function, reduces manual operation errors, and improves the comprehensiveness and efficiency of the test.
Smart Images
Figure CN120319293A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular, to a method for testing a solid-state drive, a device for testing a solid-state drive, an electronic device, and a computer-readable storage medium. Background Art
[0002] A solid-state drive has a self-check function. Through the self-check function, it can detect its own health status, feedback the abnormalities detected during the self-check process, and discover solid-state drive failures in a timely manner, thereby reducing the risk of fault expansion. However, in the actual working process, problems with solid-state drive failures often still occur, that is, the failure rate of solid-state drives should be at a relatively high level. Summary of the Invention
[0003] This application provides a method for testing a solid-state drive, a device for testing a solid-state drive, an electronic device, and a computer-readable storage medium, so as to at least solve the problem that the solid-state drive still has a relatively high failure rate in the related art.
[0004] This application provides a method for testing a solid-state drive. The method for testing a solid-state drive includes: locating a carrier device carrying a hard disk to be tested; respectively constructing a normal scenario and an abnormal scenario as target scenarios; sending a self-check trigger instruction to the carrier device in the target scenario, so that the carrier device schedules the hard disk to be tested to start the self-check function and generate a self-check log; obtaining the self-check logs of the normal scenario and the abnormal scenario to verify whether the self-check function of the hard disk to be tested is normal.
[0005] This application also provides a device for testing a solid-state drive. The device for testing a solid-state drive includes: a communication module and a testing module; the communication module is used to connect to the carrier device; the testing module is connected to the communication module and is used to implement any of the above methods for testing a solid-state drive.
[0006] This application also provides an electronic device. The electronic device includes: a memory and a processor; the memory is used to store a computer program; the processor is used to execute the computer program to implement the steps of any of the above methods for testing a solid-state drive.
[0007] This application also provides a computer-readable storage medium. A computer program is stored in the computer-readable storage medium. Wherein, when the computer program is executed by the processor, the steps of any of the above methods for testing a solid-state drive are implemented.
[0008] Through this application, since the self-check function of the solid-state drive can be verified, the self-check function of the solid-state drive can be objectively analyzed through objective self-check logs. When the solid-state drive is abnormal, it can be detected and discovered in time through a reliable self-check function, reducing the risk of solid-state drive failures and improving the reliability of the solid-state drive. Moreover, the hard drive to be tested can be carried on a carrier device to physically isolate the test device of the solid-state drive and the hard drive to be tested. By constructing the normal scenario and the abnormal scenario respectively and verifying the self-check function of the hard drive to be tested through the interaction with the carrier device, the verification of the self-check function in both the normal scenario and the abnormal scenario can be taken into account. At the same time, it is beneficial to ensure reliable testing and the impact of the test control of the test device for the solid-state drive in the construction of the abnormal scenario. Therefore, the technical problem of the still relatively high failure rate of the solid-state drive can be solved, the self-check function of the solid-state drive can be verified, which is conducive to ensuring reliable abnormal feedback of the solid-state drive through a reliable self-check function, and further improving the technical effect of the reliability of the solid-state drive. BRIEF DESCRIPTION OF THE DRAWINGS
[0009] To more clearly illustrate the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.
[0010] Figure 1 Schematic structural diagram of an embodiment of the test system for the solid-state drive of the present application;
[0011] Figure 2 Schematic structural diagram of an embodiment of the test device for the solid-state drive of the present application;
[0012] Figure 3 Schematic flow diagram of an embodiment of the test method for the solid-state drive of the present application;
[0013] Figure 4 Schematic flow diagram of another embodiment of the test method for the solid-state drive of the present application;
[0014] Figure 5 Schematic structural diagram of an embodiment of the electronic device of the present application;
[0015] Figure 6 Schematic structural diagram of an embodiment of the computer-readable storage medium of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0016] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts belong to the protection scope of the present application.
[0017] It should be noted that in the description of the present application, the terms "include", "comprise" or any other variant thereof are intended to cover a non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in the present application are used to distinguish similar objects, rather than to describe a specific order or sequence.
[0018] In order to enable those skilled in the art of the present technology to better understand the solutions of the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0019] To solve the technical problem that solid-state drives still have a relatively high failure rate in related technologies, the present application provides a testing method for a solid-state drive, a testing device for a solid-state drive, an electronic device, and a computer-readable storage medium. The testing method for the solid-state drive includes: locating a carrier device carrying the hard drive to be tested; respectively constructing a normal scenario and an abnormal scenario as target scenarios; sending a self-test trigger instruction to the carrier device in the target scenario to cause the carrier device to schedule the hard drive to be tested to start the self-test function and generate a self-test log; obtaining the self-test logs of the normal scenario and the abnormal scenario to verify whether the self-test function of the hard drive to be tested is normal. The detailed working principle of the present application is illustrated by way of example below.
[0020] Combined with the specific application environment architecture or specific hardware architecture on which the execution of the testing method for the solid-state drive depends, the specific application environment architecture or specific hardware architecture is described herein.
[0021] Please refer to Figure 1 , Figure 1 which is a schematic structural diagram of an embodiment of the testing system for the solid-state drive of the present application.
[0022] In one embodiment, the testing system for the solid-state drive may include a testing device 10 for the solid-state drive and a carrier device 20, which are communicatively connected to each other.
[0023] For example, Figure 1It is exemplified that the test device 10 of the solid-state drive and the carrier device 20 are connected via a local area network; alternatively, the test device 10 of the solid-state drive and the carrier device 20 can be physically connected synchronously through a data cable or the like, which is not limited herein.
[0024] Among them, a local area network (LAN) realizes the connection of multiple electronic devices based on local area network technology. A local area network can connect electronic devices at different physical locations within a few kilometers, and can communicate with each other and share resources under the support of network software. That is to say, a local area network is a network system that can connect a group of computers and their peripheral devices through a transmission medium within a relatively small geographical area. In this embodiment, the local area network can connect the test device 10 of the solid-state drive and the carrier device 20.
[0025] As the name implies, the test device 10 of the solid-state drive is a test control device that can test the solid-state drive, and its working principle will be elaborated in detail later.
[0026] The carrier device 20 is a device that carries the solid-state drive to be tested, that is, the hard disk to be tested. Optionally, the number of hard disks to be tested in the carrier device 20 is at least one, that is, the number of hard disks to be tested can be one, or the number of hard disks to be tested can be multiple (as Figure 1 exemplified). For example, the hard disk to be tested can be an NVMe SSD or the like. Among them, NVMe represents the Non-Volatile Memory Host Controller Interface Specification; SSD (Solid State Disk or Solid State Drive) represents a solid-state drive.
[0027] An embodiment of the present application also provides a test device for a solid-state drive. Please refer to Figure 2 , Figure 2 which is a schematic structural diagram of an embodiment of the test device for the solid-state drive of the present application.
[0028] In one embodiment, the test device 10 of the solid-state drive may include a communication module 11 and a test module 12.
[0029] The communication module 11 is used to connect to the carrier device.
[0030] The test module 12 is connected to the communication module 11 and is used to implement the test method of the solid-state drive.
[0031] For the description of the features in the corresponding embodiment of the test device of the solid-state drive, reference can be made to the relevant description of the corresponding embodiment of the test method of the solid-state drive, which will not be elaborated herein one by one.
[0032] Embodiments of the present application provide a method for testing a solid-state drive. In combination with the execution process of the method for testing a solid-state drive, the working principle of the method is described in detail.
[0033] Please refer to Figure 3 , Figure 3 which is a schematic flowchart of an embodiment of the method for testing a solid-state drive of the present application.
[0034] S101: Locate the carrier device that holds the hard disk to be tested.
[0035] In this embodiment, the carrier device that holds the hard disk to be tested is located, so as to realize the connection with the hard disk to be tested, so that the solid-state drive test can be performed on the hard disk to be tested.
[0036] S102: Construct a normal scenario and an abnormal scenario as target scenarios respectively; send a self-test trigger instruction to the carrier device in the target scenarios, so that the carrier device schedules the hard disk to be tested to start the self-test function and generate a self-test log.
[0037] In this embodiment, the solid-state drive test can be compatible with both normal scenarios and abnormal scenarios.
[0038] When constructing a normal scenario as the target scenario, send a self-test trigger instruction to the carrier device in the normal scenario, so that the carrier device schedules the hard disk to be tested to start the self-test function and generate a self-test log, so as to verify the reliability of the self-test function of the hard disk to be tested in the normal scenario.
[0039] When constructing an abnormal scenario as the target scenario, send a self-test trigger instruction to the carrier device in the abnormal scenario, so that the carrier device schedules the hard disk to be tested to start the self-test function and generate a self-test log, so as to verify the reliability of the self-test function of the hard disk to be tested in the abnormal scenario.
[0040] S103: Obtain the self-test logs of the normal scenario and the abnormal scenario, so as to verify whether the self-test function of the hard disk to be tested is normal.
[0041] In this embodiment, the self-test logs when the normal scenario and the abnormal scenario are respectively used as target scenarios are obtained. By parsing and analyzing the self-test logs, it is evaluated whether the self-test function of the hard disk to be tested operates correctly in the target scenario, and whether the hard disk to be tested accurately identifies the abnormal scenario when the abnormal scenario is used as the target scenario. Among them, the abnormal scenario is to construct the hard disk to be tested in an abnormal state.
[0042] That is to say, in this embodiment, the self-check function of the solid-state drive can be verified, so as to objectively analyze the self-check function of the solid-state drive through objective self-check logs, so as to select a solid-state drive with a relatively reliable self-check function to participate in business activities, so that when the solid-state drive is abnormal, it can be detected and found in time through a reliable self-check function, and the efficiency of handling solid-state drive abnormalities can be improved through timely abnormal feedback, thereby reducing the risk of solid-state drive failures and improving the reliability of solid-state drives.
[0043] Moreover, the hard disk to be tested can be carried on the carrier device, and the normal scenario and the abnormal scenario are respectively constructed, and the self-check function of the hard disk to be tested is verified through the interaction with the carrier device, so that the verification of the self-check functions of the normal scenario and the abnormal scenario can be taken into account.
[0044] At the same time, physically isolating the test device of the solid-state drive and the hard disk to be tested is conducive to ensuring reliable testing and the impact of the test control of the test device of the solid-state drive in building the abnormal scenario. In other words, the self-check function of the solid-state drive can be verified, which is conducive to ensuring reliable abnormal feedback of the solid-state drive through a reliable self-check function, thereby improving the technical effect of the reliability of the solid-state drive. It can also solve the problem that the traditional method relying on manual operation and subjective judgment of whether the self-check function is reliable is prone to errors, further improving the automation of solid-state drive testing. When compatible with other types of solid-state drive testing, it can also improve the comprehensiveness of solid-state drive testing.
[0045] Please refer to Figure 4 , Figure 4 which is a schematic flowchart of another embodiment of the test method for the solid-state drive of this application.
[0046] S201: Read the configuration file and connect to the hard disk to be tested and the carrier device based on the configuration file.
[0047] In this embodiment, the configuration file may include the device information of the carrier device and the hard disk information of the hard disk to be tested.
[0048] Thus, the carrier device in the same local area network can be accessed based on the device information. For example, the device information may include the Internet Protocol address, the carrier device identifier, etc., which will be specifically exemplified later.
[0049] S202: Determine whether the hard disk to be tested is in place.
[0050] In this embodiment, when it is determined that the hard disk to be tested is in place, step S203 is executed. When it is determined that the hard disk to be tested is not in place, the out-of-place information can be fed back or refreshed, etc. By feeding back the out-of-place information, the relevant test personnel can physically plug and unplug the hard disk to be tested to ensure the reliability of the test process.
[0051] The hard disk to be tested can be subjected to in-place detection and status detection based on hard disk information.
[0052] In response to the hard disk to be tested passing the in-place detection and status detection, it is determined to verify the self-check function of the hard disk to be tested.
[0053] S203: Locate the carrier device carrying the hard disk to be tested.
[0054] S204: Send a hard disk initialization instruction to the carrier device.
[0055] In this embodiment, a hard disk initialization instruction can be sent to the carrier device to cause the carrier device to initialize the hard disk to be tested.
[0056] S205: Take the normal scenario as the target scenario, send a self-check trigger instruction to the carrier device, verify the self-check function of the hard disk to be tested, and obtain the self-check log of the normal scenario.
[0057] In this embodiment, in response to the hard disk to be tested completing the initialization and determining that the normal scenario is constructed, the normal scenario is taken as the target scenario, and the hard disk to be tested enables the self-check function in response to the self-check trigger instruction in the normal scenario, that is, the hard disk to be tested can perform a hard disk self-check. When the hard disk to be tested completes the hard disk self-check, the carrier device can integrate the self-check results to form a self-check log.
[0058] Optionally, the self-check log may include identification information for analyzing whether the self-check runs correctly. For example, the identification information may include a diagnostic test sequence, the current diagnostic operation type, Reserve, and the latest self-check result data structure. The latest self-check result data structure contains two items: Operation Result (error result) and SegmentNumber (segment number).
[0059] Among them, Reserved is usually used to analyze the operating system. It can work because in some systems, "0" is an invalid port, and different results will be generated when trying to connect to it using a normally closed port, which is equivalent to a typical scan. The latest self-check result data structure contains two items: Operation Result (error result) and Segment Number.
[0060] Further, the self-check log may also include the self-check result. That is, while the carrier device feeds back the identification information, it can also synchronously feed back the self-check result of the hard disk under test. In response to obtaining the self-check log, the self-check log is parsed to obtain the identification information and the self-check result respectively. The identification information is analyzed to evaluate whether the hard disk under test is currently reliable for self-check in the target scenario. The self-check result can also be analyzed to analyze the self-check conclusion of the hard disk under test to confirm whether its self-check result is complete and accurate. In this way, it is possible to synchronously evaluate whether the hard disk under test is normal for self-check in the target scenario and whether the self-check result is accurate, which is beneficial to improving the reliability of verifying the self-check function of the hard disk under test.
[0061] S206: Verify whether the self-check function of the hard disk under test in the normal scenario is normal.
[0062] In this embodiment, when it is determined that the self-check function of the hard disk under test in the normal scenario is normal, step S207 is executed. When it is determined that the self-check function of the hard disk under test in the normal scenario is abnormal, step S213 is executed.
[0063] Specifically, the function test information in the self-check log can be parsed. It is determined whether the function test information conforms to the expected information preset for the target scenario. In response to the function test information conforming to the expected information preset for the target scenario, it is determined that the self-check function of the target scenario is reliable; in response to the function test information not conforming to the expected information preset for the target scenario, it is determined that there are defects in the reliability of the self-check function of the target scenario.
[0064] S207: Construct an abnormal scenario and use the abnormal scenario as the target scenario, send a self-check trigger instruction to the carrier device, verify the self-check function of the hard disk under test, and obtain the self-check log of the abnormal scenario.
[0065] In this embodiment, in response to completing the verification of the self-check function of the hard disk under test in the normal scenario, an abnormal scenario is constructed to trigger the hard disk under test to determine that it is in the abnormal scenario, and the abnormal scenario is used as the target scenario.
[0066] That is to say, in this embodiment, the verification of the self-check function in the normal scenario can be performed in advance, and then the verification of the self-check function in the abnormal scenario can be performed. In this way, the solid-state drive test can be carried out after initializing the hard disk under test. When it is confirmed that the self-check function in the normal scenario is normal, the verification of the self-check function in the abnormal scenario can be performed. By reasonably planning the test sequence and reducing the process of restoring to the normal scenario after the verification of the abnormal scenario, the test efficiency can be improved. At the same time, when it is determined that the self-check function of the hard disk under test is abnormal in the normal scenario, it can be considered that the self-check function of the hard disk under test is abnormal, and there is no need to continue the test, which can also improve the test efficiency.
[0067] Furthermore, in some abnormal scenarios, it may be necessary to damage the sectors of the hard disk to be tested. In this embodiment, when the solid-state drive test is completed and the hard disk to be tested passes the test (i.e., the test is successful), the damaged sectors in the hard disk to be tested are restored to solve the solid-state drive resources, so that the solid-state drive can also participate in other types of solid-state drive tests or participate in the actual business process. Specifically, the hard disk to be tested can be low-level formatted first, and then the hard disk to be tested can be reset to complete the restoration of the damaged sectors. For example, the command for low-level formatting can be nvme format / dev / nvmeX -n 1 -s 1 -l 0 -f; where nvmeX is the hard disk identifier of the hard disk to be tested with damaged sectors. The command for resetting can be nvme reset / dev / nvmeX.
[0068] S208: Verify whether the self-check function of the hard disk to be tested in the abnormal scenario is normal.
[0069] In this embodiment, when it is determined that the self-check function of the hard disk to be tested in the abnormal scenario is normal, step S209 is executed. When it is determined that the self-check function of the hard disk to be tested in the abnormal scenario is abnormal, step S213 is executed.
[0070] S209: Trigger the hard disk to be tested to start the self-check function and construct a power-off scenario.
[0071] In this embodiment, a power-on instruction is sent to the carrier device through the management tool to cause the carrier device to power on again in response to the power-on instruction.
[0072] S210: Determine whether the hard disk to be tested has restored the self-check function and gives an abnormal feedback.
[0073] In this embodiment, when it is determined that the hard disk to be tested has restored the self-check function and gives an abnormal feedback, step S211 is executed. Otherwise, step S213 is executed, that is, when the hard disk to be tested has not restored the self-check function and / or has not given an abnormal feedback, step S213 is executed.
[0074] In response to the hard disk to be tested restoring the self-check function and giving an abnormal feedback, it is determined that the self-check function of the hard disk to be tested is reliable; otherwise, that is, when the hard disk to be tested has not restored the self-check function and / or has not given an abnormal feedback, it is determined that there are defects in the reliability of the self-check function of the hard disk to be tested.
[0075] That is to say, in this embodiment, the further verification of the reliability of the solid-state drive self-check function is also realized. When the power is off, the self-check of the hard disk to be tested will be interrupted, but after the power is restored, the self-check progress should be automatically restored and finally the device self-check should be completed. If the reliability is verified to be okay under such extreme conditions, usually the reliability in other scenarios can also be guaranteed, so that the reliability of the solid-state drive self-check function during abnormal power-off can be ensured.
[0076] S211: Determine whether the actual number of tests has reached the preset number of tests.
[0077] In this embodiment, when it is determined that the actual number of tests has reached the preset number of tests, step S212 is executed; when the actual number of tests has not reached the preset number of tests, step S207 is executed.
[0078] For example, the preset number of tests can be 50 times, 100 times, 200 times, 300 times, etc., which is not limited here. When performing the solid-state drive test with the preset number of tests, each round is regarded as an independent test. If a round of test fails, the test is considered failed, which improves the strictness of the solid-state drive test and further ensures the reliability of the solid-state drive.
[0079] S212: Determine that the test is successful and the self-check function of the hard disk to be tested is reliable.
[0080] S213: Determine that the test fails and there are defects in the reliability of the self-check function of the hard disk to be tested.
[0081] Furthermore, the number of abnormal types in the abnormal scenario can be multiple. Multiple solid-state drives can be selected as the hard disks to be tested, so as to realize parallel solid-state drive tests through multi-threading, distributed technology, etc., in order to simultaneously perform solid-state drive tests on multiple hard disks to be tested and verify the reliability of the self-check function of the solid-state drive in parallel, thereby improving the efficiency and flexibility of the solid-state drive test. That is, the number of hard disks to be tested can be multiple. Select the hard disk to be tested for the current test as the current hard disk. Perform the self-check function test of at least one abnormal scenario on the current hard disk. Among them, during the current self-check function test process, the current hard disk constructs an abnormal scenario. In this way, it is also possible to reliably verify the reliability of the self-check function of a single abnormal scenario, reduce the interference of the abnormal scenario with reliable self-check function on the results of the abnormal scenario with unreliable self-check function, and thereby improve the test reliability of the solid-state drive and the trustworthiness of the test results.
[0082] The following elaborates on the pre-test process, that is, building the physical environment required for the solid-state drive test.
[0083] Two electronic devices such as servers can be prepared and used as the control machine and the controlled machine respectively.
[0084] Among them, the control machine is the test device of the solid-state drive, which is used for sending test instructions and analyzing the returned test results.
[0085] The controlled machine is the carrier device, which is used to execute test instructions, collect test results and feedback them to the control machine. For example, four NVMe SSDs can be prepared and inserted into the controlled machine as the hard disks to be tested for self-check function verification.
[0086] Deploy the tested network environment. A local area network can be set up to connect the control machine and the controlled machine to the local area network, which can verify and ensure that the control machine and the controlled machine can access each other.
[0087] The configuration information can be sorted out to form a configuration file, and the configuration file can be saved on the control machine. The IP (Internet Protocol) address, username, and login password of the controlled machine can be written into the configuration file, and then the NVMe SSDs can be numbered, with each NVMe SSD set with a specific ID (Identity document). For example, they can be defined as NVMe SSDA, NVMe SSD B, NVMe SSD C, and NVMe SSD D respectively, and the ID information can be written into the configuration file.
[0088] Check the physical environment to ensure the reliability of the test. The control machine reads the configuration file, queries the information such as the IP of the controlled machine recorded in the configuration file, and executes commands such as the sshpass command to determine that the controlled machine can be connected. Among them, sshpass represents a command-line tool that can be used to connect to a remote host via SSH (Secure Shell) and execute commands without interacting to input the password.
[0089] After the control machine establishes a connection with the controlled machine, it can check the NVMe SSD information according to the ID of the NVMe SSD recorded in the configuration file. Check whether the NVMe SSD is present via the nvme list command, and check that the status of the NVMe SSD is normal via the nvmesmart-log command. Among them, the nvme list command is used to detect whether the NVMe SSD is present, and the nvmesmart-log command is used to detect the status of the NVMe SSD.
[0090] In response to completing the confirmation of the connection reliability of the hard disk to be tested (i.e., the NVMe SSD), the hard disk to be tested can be initialized, with the initial state as the normal scenario, and the reliability of the self-check function of the hard disk to be tested can be verified.
[0091] The execution of the NVMe SSD initialization operation can include: the control machine reads the configuration file, connects to the controlled machine via the sshpass command, and initializes the NVMe SSD via the nvme format command. That is, the nvme format command is used to indicate the initialization of the hard disk to be tested. Combining the implementation of the foregoing four NVMe SSDs, the initialization command can be as follows:
[0092] nvme format / dev / nvmeA -n 1 -l 0 -f -r
[0093] nvme format / dev / nvmeB -n 1 -l 0 -f -r
[0094] nvme format / dev / nvmeC -n 1 -l 0 -f -r
[0095] nvme format / dev / nvmeD -n 1 -l 0 -f -r
[0096] In this way, it is possible to implement the indication for initializing the four NVMe SSD A, NVMe SSD B, NVMe SSD C, and NVMe SSD D.
[0097] Perform NVMe SSD device self - test on the four hard disks to be tested in the initial state. Specifically, the control machine can read the configuration file, connect to the controlled machine through the sshpass command, and control the four NVMe SSDs to enable the self - test function. The specific commands can be as follows:
[0098] nvme device - self - test / dev / nvmeA -n -1 -s 0x2h
[0099] nvme device - self - test / dev / nvmeB -n -1 -s 0x2h
[0100] nvme device - self - test / dev / nvmeC -n -1 -s 0x2h
[0101] nvme device - self - test / dev / nvmeD -n -1 -s 0x2h
[0102] In this way, it is possible to implement the indication for performing hard disk self - test by enabling the self - test function on the four NVMe SSD A, NVMe SSD B, NVMe SSD C, and NVMe SSD D.
[0103] The controlled machine can generate the NVMe SSD device self - test Logpage (i.e., self - test log) and send it back to the control machine for parsing by the control machine.
[0104] Specifically, the control machine reads the configuration file, connects to the controlled machine through the sshpass command, executes the command to generate the NVMe SSD device self - test Logpage, and sends the Logpage back to the control machine for detection. The specific commands can be as follows:
[0105] nvme set-test-log / dev / nvmeA >> Logpage-A.txt
[0106] nvme set-test-log / dev / nvmeB >> Logpage-B.txt
[0107] nvme set-test-log / dev / nvmeC >> Logpage-C.txt
[0108] nvme set-test-log / dev / nvmeD >> Logpage-D.txt
[0109] In this way, it is possible to implement the indication to generate the self-test logs of NVMe SSD A, NVMe SSD B, NVMe SSD C, and NVMe SSD D.
[0110] The control machine can check the correctness of the self-test function of the NVMe SSD device in the initial state. Specifically, the control machine can parse the returned Logpage, and the various index items that need to be checked according to the NVMe protocol are as follows:
[0111] byte 00, Current Device Self-Test Operation
[0112] byte 01, Current Device Self-Test Completion
[0113] byte 03:02, Reserved
[0114] byte 31:04, Newest Self-test Result Data Structure
[0115] Among them, byte represents a byte; Current Device Self-Test Operation represents a diagnostic test sequence; Current Device Self-Test Completion represents the current diagnostic operation type; Reserved is usually used for analyzing the operating system. It can work because "0" is an invalid port in some systems, and different results will be generated when trying to connect it using the usual closed port, which is equivalent to a typical scan. The Newest Self-test Result Data Structure contains two checks: Operation Result (error result) and Segment Number (segment number).
[0116] In the initial state, the NVMe SSD is in normal condition, and there are no error reports in the Logpage obtained from the self-test of the NVMe SSD device. The ideal values for the corresponding four items are required as follows:
[0117] Current Device Self-Test Operation = 0h
[0118] Current Device Self-Test Completion = 100%
[0119] Operation Result = 0h
[0120] SegmentNumber = 0h
[0121] If the self-test log returned by the controlled machine meets the requirements, it is determined that the hard disk under test passes the current test. If at least one item does not meet the requirements, the test is determined to fail.
[0122] In response to the self-test function verification of the hard disk under test passing the conventional scenario, an abnormal scenario can be constructed for self-test function verification. The control machine obtains the configuration file information, connects to the controlled machine according to the configuration file information, and can allocate different abnormal scenarios to different disks according to the NVMe SSD configuration information.
[0123] Specifically, the abnormal types of the abnormal scenarios in this embodiment can include at least one of Smart status abnormality, capacitance abnormality, Media abnormality, and Drive Life abnormality. That is to say, this embodiment can also be compatible with special detection interfaces such as NVMe solid-state drives. The above abnormal scenarios are usually not easy to trigger during the actual application of solid-state drives and need to be triggered after long-term use of the solid-state drive or when the disk reaches the later stage of its life. It is even more difficult to trigger in conventional tests. This embodiment can construct and be compatible with the aforementioned abnormal scenarios to almost cover various possible scenarios in the actual use scenario during the test process of the solid-state drive, improve the test integrity, and ensure the comprehensiveness of the test coverage.
[0124] For example, in this embodiment, the self-test function verification of the abnormal scenario of Smart status abnormality can be compatible; or, the self-test function verification of the two abnormal scenarios of capacitance abnormality and Media abnormality can be compatible in this embodiment; or, the self-test function verification of the three abnormal scenarios of Smart status abnormality, capacitance abnormality, and Drive abnormality can be compatible in this embodiment; or, the self-test function verification of the four abnormal scenarios of Smart status abnormality, capacitance abnormality, Media abnormality, and Drive abnormality can be compatible in this embodiment.
[0125] The processes of constructing various abnormal scenarios and analyzing self-check logs are elaborated in detail below.
[0126] Taking the currently constructed abnormal scenario of Smart anomaly as an example:
[0127] In response to the abnormal scenario being a smart status anomaly, a temperature acquisition instruction can be sent to the carrier device to obtain the current temperature of the hard disk under test that responds to the temperature acquisition instruction of the carrier device. Select a temperature lower than the current temperature as the temperature threshold and send the temperature threshold to the hard disk under test as the new temperature threshold for triggering the smart status anomaly.
[0128] For example, select the method of constructing a Smart anomaly scenario. According to the NVMe SSD protocol, trigger the Smart anomaly by reducing the high-temperature warning threshold. Specifically, the command nvme smart-log / dev / nvmeA can be executed to view the current temperature of the NVMe SSD, and then the command nvme set-feature / dev / nvmeAn1 -f0x4 -v 0x111 can be executed to set the high-temperature warning threshold to 0°C, ensuring that the threshold is lower than the current temperature of the NVMe SSD. Check whether the Smart anomaly scenario is successfully constructed by executing the command nvme smart-log / dev / nvmeA and view the Critical warning value in the output as 0x2 to confirm the successful construction of the Smart anomaly test scenario.
[0129] Taking the currently constructed abnormal scenario of capacitor anomaly as an example:
[0130] In response to the abnormal scenario being a capacitor anomaly, a data verification instruction is sent to the carrier device to control the hard disk under test to perform data verification. During the data verification process, a firmware restart instruction is sent to the carrier device to restart the carrier device firmware until the data verification gives an abnormal feedback to determine the trigger of the capacitor anomaly, and then the firmware restart instruction is aborted.
[0131] For example, select the method of constructing a capacitor anomaly scenario. According to the NVMe SSD protocol, construct a scenario where the NVMe SSD data verification fails by repeatedly restarting the firmware during the NVMe SSD data verification process, so as to achieve the capacitor anomaly test scenario. Specifically, 128k (1k is 1024 bytes) data verification can be performed on the NVMe SSD, and the specific execution commands can be as follows:
[0132] fio --name=128ksw_precondition --rw=write --direct=1 --thread --norandommap --ioengine=libaio --numjobs=1 --group_reporting --filename= / dev / nvmeBn1 --loops=1
[0133] --bs=128k --iodepth=128 --do_verify=1
[0134] Then, the operation of repeatedly restarting the firmware of the NVMe SSD can be performed, such as the nvme reset / dev / nvmeB command. The operation of restarting the firmware needs to be repeated without any time interval in between. During the repeated execution of the firmware restart operation, check whether the NVMe SSD data verification reports an error. It may take a relatively long time, and it is necessary to wait until the NVMe SSD data verification reports an error before stopping the firmware restart action. After stopping the firmware restart action when the data verification reports an error, execute the command nvme smart-log / dev / nvmeB to view that the Critical warning value in the output is 0x8, and confirm that the construction of the capacitor anomaly test scenario is successful.
[0135] Taking the currently constructed anomaly scenario as the Media anomaly as an example:
[0136] In response to the anomaly scenario being a media anomaly, locate the storage block of the hard disk to be tested, read the data in the storage block and save it to a preset file, construct a damaged sector in the storage block, and read the data in the storage block again to trigger a media anomaly.
[0137] For example, select the method of constructing a Media anomaly scenario. According to the NVMe SSD protocol, by creating bad sectors on the selected block and repeatedly reading the bad sectors, a scenario where the read information fails is constructed, so as to trigger the NVMe SSD Media error scenario.
[0138] Specifically, 1 Block can be selected from the NVMe SSD C, such as selecting the first block, and reading the data of this block. Execute the command nvme read-s 1 -c 1 -z 1024 / dev / nvmeCn1 -d read.bin to read the data of one block starting from the first Block of the NVMeSSD C and save the data in the read.bin file (i.e., the preset file mentioned above).
[0139] Next, a damaged sector can be created on this Block by executing the command "nvme write-uncor-s 1 -c 1 / dev / nvmeCn1", that is, constructing a damaged sector on the first Block of the NVMe SSD C through the NVMe write command. Since one sector of this Block is damaged, the corresponding data will also be damaged, and an error will be reported when reading again.
[0140] Execute the data reading command "nvme read-s 1 -c 1 -z 1024 / dev / nvmeCn1 -d read1.bin" again to read the data of one Block starting from the first Block of the NVMe SSD C and save the data in the read1.bin file. Since a damaged sector has been constructed in this Block in the previous step, an error will be reported when reading the data again. When reading repeatedly, the error will continue to increase, thus implementing the construction of the Media error scenario.
[0141] It is also possible to check whether the Media exception test scenario is successfully constructed. For example, the command "nvme smart-log / dev / nvmeC" can be executed to check if the media error log value in the output increases, confirming the successful construction of the NVMe SSD Media exception test scenario.
[0142] Take the currently constructed exception scenario as the Drive Life exception as an example:
[0143] In response to the exception scenario being a drive exception, send a life acquisition instruction to the carrier device to obtain the current life parameter of the hard disk under test that responds to the life acquisition instruction. Send the life calibration parameter as a new life threshold to the carrier device so that when the current life parameter is lower than the new life threshold, the hard disk under test triggers a drive exception. Among them, in response to the current life parameter being equal to the life calibration parameter, a target number of damaged sectors are created on the hard disk under test.
[0144] For example, select to construct the Drive Life exception test scenario. According to the NVMe SSD protocol, trigger the Drive Life exception test scenario by increasing the life warning threshold.
[0145] Specifically, "nvme smart-log / dev / nvmeD" can be executed to view the life warning threshold and the current life value of the NVMe SSD. Then the command "nvme set-feature / dev / nvmeAn1 -f 0x7 -v 0x64" can be executed to set the life warning threshold to 100. Since the current life value is at most 100, the warning threshold will not be lower than the current life value.
[0146] Meanwhile, if the current life value of the NVMe SSD D is 100, the command nvmewrite-uncor-s 1 - c 1000 / dev / nvmeDn1 needs to be executed on the NVMe SSD to construct 1000 bad sectors starting from the first blok of the NVMe SSD D, so as to reduce the life value and make it lower than 100.
[0147] Then, it is also possible to check whether the Drive Life abnormal test scenario is successfully constructed. The command nvmesmart-log / dev / nvmeD can be executed to check that the Critical warning value in the output is 0x8, and confirm that the NVMe SSD D enters the Readonly state, indicating that the Drive Life abnormal test scenario is successfully constructed.
[0148] The following elaborates on the detailed process of enabling and verifying the self-check function for abnormal scenarios in combination with the above examples.
[0149] Perform device self-check on the NVMe SSD. Specifically, the control machine can read the configuration file, connect to the controlled machine through the sshpass command, and perform device self-check on four NVMe SSDs. The specific commands can be as follows:
[0150] nvme device-self-test / dev / nvmeA - n - 1 - s 0x2h
[0151] nvme device-self-test / dev / nvmeB - n - 1 - s 0x2h
[0152] nvme device-self-test / dev / nvmeC - n - 1 - s 0x2h
[0153] nvme device-self-test / dev / nvmeD - n - 1 - s 0x2h
[0154] The controlled machine can generate the Logpage for the NVMe SSD device self-check and send it back to the control machine for parsing. Specifically, the control machine reads the configuration file, connects to the controlled machine through the sshpass command, executes the command to generate the Logpage for the NVMe SSD device self-check, and sends the Logpage back to the control machine for detection. The specific commands can be as follows:
[0155] nvme set-test-log / dev / nvmeA >> Special-Logpage-A.txt
[0156] nvme set-test-log / dev / nvmeB >> Special-Logpage-B.txt
[0157] nvme set-test-log / dev / nvmeC >> Special-Logpage-C.txt
[0158] nvme set-test-log / dev / nvmeD >> Special-Logpage-D.txt
[0159] Next, the correctness of the self-test of the NVMe SSD device in the Smart exception test scenario can be verified based on the Logpage. Specifically, the control machine can parse the self-test Logpage (Special-Logpage-A.txt) of the NVMe SSD device transmitted back, check whether each value meets the protocol requirements, and the corresponding values according to the protocol regulations are as follows:
[0160] Current Device Self-Test Operation = 02h
[0161] Current Device Self-Test Completion = 100%
[0162] Operation Result = 0x7
[0163] SegmentNumber = 0x2
[0164] That is, if the values in the Logpage meet the corresponding values specified in the above-displayed protocol, it can be considered that the self-test function of the current test is reliable. Similarly, it will not be elaborated later.
[0165] The correctness of the self-test of the NVMe SSD device in the capacitor anomaly test scenario can be verified. Specifically, the control machine parses the self-test Logpage (Special-Logpage-B.txt) of the NVMe SSD device transmitted back, checks whether each value meets the protocol requirements, and the corresponding values according to the protocol regulations are as follows:
[0166] Current Device Self-Test Operation = 02h
[0167] Current Device Self-Test Completion = 100%
[0168] Operation Result = 0x7
[0169] SegmentNumber = 0x3
[0170] When verifying the correctness of the self - test of the NVMe SSD device in the Media exception test scenario, the controller can parse the self - test Logpage (Special - Logpage - C.txt) of the NVMe SSD device returned, check whether each value meets the protocol requirements, and the corresponding values according to the protocol are as follows:
[0171] Current Device Self - Test Operation = 02h
[0172] Current Device Self - Test Completion = 100%
[0173] Operation Result = 0x7
[0174] SegmentNumber = 0x6
[0175] When verifying the correctness of the self - test of the NVMe SSD device in the Drive Life exception test scenario, the controller can parse the self - test Logpage (Special - Logpage - D.txt) of the NVMe SSD device returned, check whether each value meets the protocol requirements, and the corresponding values according to the protocol are as follows:
[0176] Current Device Self - Test Operation = 02h
[0177] Current Device Self - Test Completion = 100%
[0178] Operation Result = 0x7
[0179] SegmentNumber = 0x8
[0180] When verifying the reliability of the self - test function through the analysis of the test results, the controller can parse the self - test Logpage of the NVMe SSD device returned. The test results in the four special scenarios must all meet the protocol requirements. If any one does not meet, the test can be considered a failure.
[0181] As described in the previous text, it is also possible to verify the reliability of the NVMe SSD device self - test function during abnormal power - off.
[0182] Generally speaking, if there is an abnormal power-off during the self-test of an NVMe SSD device, the self-test of the NVMe SSD device will be interrupted. However, after the device is powered on again, the self-test can be resumed and successfully completed. If the self-test function of the NVMe SSD device cannot be resumed and / or reports an error after being powered on again in the case of abnormal power-off, there are defects in the reliability of the self-test function of the NVMe SSD device.
[0183] Specifically, the self-test function of the NVMe SSD can be controlled. The control machine reads the configuration file, connects to the controlled machine through the sshpass command, and controls four NVMe SSDs to perform device self-tests. The specific commands can be exemplified as follows:
[0184] nvme device-self-test / dev / nvmeA-n-1-s 0x2h
[0185] nvme device-self-test / dev / nvmeB-n-1-s 0x2h
[0186] nvme device-self-test / dev / nvmeC-n-1-s 0x2h
[0187] nvme device-self-test / dev / nvmeD-n-1-s 0x2h
[0188] In response to the NVMe SSD performing a self-test, an abnormal power-off is performed on the NVMe SSD. Specifically, when the self-test of the NVMe SSD device is not completed, the control machine reads the configuration file, connects to the controlled machine through commands such as management tools, and executes the poweroff command to power off the controlled machine.
[0189] After the power-off is completed, a power-on operation is also performed on the NVMe SSD, and it is rechecked whether the self-test of the NVMe SSD device is resumed. Specifically, the control machine can read the configuration file, power on the controlled machine through the power on command, check the self-test status of the NVMe SSD device, execute the following commands, and check whether the value of Current Device Self-Test Completion in the Logpage is non-zero. Each NVMe SSD needs to be checked. If the value becomes 0 in the Logpage of the self-test of any NVMe SSD device, the test is considered failed. The specific commands can be exemplified as follows:
[0190] nvme set-test-log / dev / nvmeA
[0191] nvme set-test-log / dev / nvmeB
[0192] nvme set-test-log / dev / nvmeC
[0193] nvme set-test-log / dev / nvmeD
[0194] In summary, it can be seen that the present application provides a test method that can verify the correctness and reliability of the self-check function of a solid-state drive. This test method can verify the correctness of the self-check function of the solid-state drive, and can also verify the reliability of the self-check function when the solid-state drive has an abnormal power-off. It comprehensively verifies the reliability of the self-check function of the solid-state drive, and can also achieve automated testing and improve testing efficiency. It can also test multiple solid-state drive devices simultaneously, parallelly test multiple scenarios, improve testing efficiency while reducing errors caused by manual operations. At the same time, the test method can also enhance the comprehensiveness of the covered test scenarios, can construct various scenarios that are difficult to encounter in actual use, and automatically and repeatedly tests the reliability and improves the integrity of the test, thereby being beneficial to ensuring the correctness and reliability of the self-check function of the solid-state drive, improving the security and usability of the solid-state drive in actual applications, and being beneficial to reducing the maintenance cost of the solid-state drive, and further being able to improve the maintainability and reliability of the solid-state drive and its carrier device.
[0195] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation method.
[0196] Please refer to Figure 5 , Figure 5 , which is a schematic structural diagram of an embodiment of an electronic device of the present application.
[0197] In one embodiment, the embodiment of the present application also provides an electronic device 30.
[0198] The electronic device 30 includes a memory 31 and a processor 32. A computer program is stored in the memory 31, and the processor 32 is configured to run the computer program to execute the steps in any of the above embodiments of the test method for the solid-state drive.
[0199] Please refer to Figure 6 , Figure 6 , which is a schematic structural diagram of an embodiment of a computer-readable storage medium of the present application.
[0200] In one embodiment, the embodiment of the present application also provides a computer-readable storage medium 40.
[0201] A computer program 41 is stored in the computer-readable storage medium 40. Among them, the computer program 41 is set to execute the steps in any of the above-described embodiments of the testing method for a solid-state drive when running.
[0202] In an exemplary embodiment, the above computer-readable storage medium 40 may include, but is not limited to: various media such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), mobile hard disks, magnetic disks, or optical discs that can store the computer program 41.
[0203] An embodiment of the present application also provides a computer program product. The above computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above-described embodiments of the testing method for a solid-state drive.
[0204] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above-described embodiments of the testing method for a solid-state drive.
[0205] Those skilled in the art can further realize that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of the present application.
[0206] The above has introduced in detail a testing method for a solid-state drive, a testing device for a solid-state drive, an electronic device, and a computer-readable storage medium provided by the present application. Specific examples are used in this article to elaborate on the principle and implementation manner of the present application. The description of the above embodiments is only used to help understand the method and its core idea of the present application. It should be noted that for those of ordinary skill in the art in the technical field, without departing from the principle of the present application, several improvements and modifications can still be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.
Claims
1. A testing method for a solid state drive, characterized in that, The test method for the solid-state drive includes: Locate the carrier device carrying the hard disk to be tested; Construct a normal scenario and an abnormal scenario respectively as the target scenarios; send a self-test trigger instruction to the carrier device in the target scenarios, so that the carrier device schedules the hard disk to be tested to start the self-test function and generate a self-test log; Obtain the self-test logs of the normal scenario and the abnormal scenario to verify whether the self-test function of the hard disk to be tested is normal.
2. The testing method according to claim 1, characterized in that, The abnormal types of the abnormal scenario include at least one of intelligent state abnormality, capacitance abnormality, medium abnormality, and drive abnormality; constructing the abnormal scenario includes: In response to the abnormal scenario being an intelligent state abnormality, send a temperature acquisition instruction to the carrier device to obtain the current temperature of the hard disk to be tested when the carrier device responds to the temperature acquisition instruction; select a temperature lower than the current temperature as the temperature threshold, and send the temperature threshold to the hard disk to be tested as a new temperature threshold for triggering the intelligent state abnormality; and / or, In response to the abnormal scenario being a capacitance abnormality, send a data verification instruction to the carrier device to control the hard disk to be tested to perform data verification; send a firmware restart instruction to the carrier device during the data verification process to cause the carrier device firmware to restart until the data verification gives an abnormal feedback to determine the triggering of the capacitance abnormality, and then abort sending the firmware restart instruction; and / or, In response to the abnormal scenario being a medium abnormality, locate the storage block of the hard disk to be tested, read the data in the storage block and save it to a preset file, construct a damaged sector in the storage block, and read the data in the storage block again to trigger the medium abnormality; and / or, In response to the abnormal scenario being a drive abnormality, send a life acquisition instruction to the carrier device to obtain the current life parameter of the hard disk to be tested when the carrier device responds to the life acquisition instruction; send the life calibration parameter to the carrier device as a new life threshold, so that when the current life parameter is lower than the new life threshold, the hard disk to be tested triggers the drive abnormality; wherein, in response to the current life parameter being equal to the life calibration parameter, create a target number of damaged sectors in the hard disk to be tested.
3. The test method according to claim 2, wherein The number of hard disks to be tested is multiple, and the number of abnormal types of the abnormal scenario is multiple; constructing the abnormal scenario as the target scenario includes: Select the hard disk to be tested for the current test as the current hard disk; Conduct a self-test function test for at least one abnormal scenario on the current hard disk; wherein, during the current self-test function test, the current hard disk constructs one abnormal scenario.
4. The test method according to claim 1, characterized in that The test method further includes: In response to the hard disk to be tested starting the self-test function, send a power-off instruction to the carrier device to cause the carrier device to power off in response to the power-off instruction; Send a power-on instruction to the carrier device through the management tool to cause the carrier device to power on again in response to the power-on instruction; Judge whether the hard disk to be tested resumes the self-test function and gives an abnormal feedback; In response to the hard disk under test resuming the self - test function and giving an abnormal feedback, it is determined that the self - test function of the hard disk under test is reliable; otherwise, it is determined that there are defects in the reliability of the self - test function of the hard disk under test.
5. The test method according to claim 1, characterized in that The steps of separately constructing a normal scenario and an abnormal scenario as target scenarios include: Sending a hard disk initialization instruction to the carrier device to schedule the carrier device to initialize the hard disk under test; In response to the hard disk under test completing initialization, it is determined that the construction of the normal scenario is completed, and the normal scenario is used as the target scenario; In response to completing the verification of the self - test function of the hard disk under test in the normal scenario, an abnormal scenario is constructed, triggering the hard disk under test to determine that it is in the abnormal scenario, and the abnormal scenario is used as the target scenario.
6. The testing method according to claim 1, wherein The self - test log includes function test information and self - test result information; Obtaining the self - test log to verify whether the self - test function of the hard disk under test is normal includes: Parsing the function test information in the self - test log; Judging whether the function test information conforms to the expected information preset for the target scenario; In response to the function test information conforming to the expected information preset for the target scenario, it is determined that the self - test function of the target scenario is reliable; in response to the function test information not conforming to the expected information preset for the target scenario, it is determined that there are defects in the reliability of the self - test function of the target scenario.
7. The test method according to claim 1, characterized in that Before locating the carrier device carrying the hard disk under test, it includes: Reading a configuration file; wherein, the configuration file includes the device information of the carrier device and the hard disk information of the hard disk under test; Accessing the carrier device in the same local area network based on the device information; Performing an in - position detection and a status detection on the hard disk under test based on the hard disk information; In response to the hard disk under test passing the in - position detection and the status detection, it is determined to verify the self - test function of the hard disk under test.
8. A test device for a solid-state drive, characterized in that, The test device for the solid - state hard disk includes: A communication module for connecting to the carrier device; A test module connected to the communication module for implementing the test method of the solid - state hard disk according to any one of claims 1 to 7.
9. An electronic device, characterized in that, It includes: A memory for storing a computer program; A processor for implementing the steps of the test method of the solid - state hard disk according to any one of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium, characterized in that, A computer program is stored in the computer - readable storage medium, wherein the computer program implements the steps of the test method of the solid - state hard disk according to any one of claims 1 to 7 when executed by a processor.