Method and device for automatically testing solid state disk, electronic equipment and storage medium

Abstract

The invention provides a solid state disk automatic testing method and device, electronic equipment and a storage medium. The method comprises the steps that a to-be-tested solid state disk and a load tool corresponding to the to-be-tested solid state disk are obtained through screening in solid state disks based on a first configuration file and a first command line parameter; specifying a performance test type based on the first configuration file; based on the performance test type and the second configuration file, combining with the second command line parameter, performing performance test on the to-be-tested solid state disk through the load tool; performing parameter mapping through the mapping relation to determine a load tool corresponding to the solid state disk to be tested so as to support performance testing of the SATA interface and the NVMe interface at the same time; determining a power failure type based on a preset third configuration file, and performing a power failure test based on the power failure type and the third command line parameter; and determining a specific function command based on a preset fourth configuration file, and performing a specific test based on the specific function command. The cross-protocol test is realized, and the test universality is improved.

Description

Technical Field

[0001] The present invention relates to the field of automated testing technology, and in particular to a method, device, electronic equipment, and storage medium for automated testing of solid-state hard drives. Background Art

[0002] Solid-state drives (SSDs), as key data storage devices, are attracting significant attention in today's digital age regarding their performance, reliability, and compatibility. Automated testing systems have emerged to address this need, with profound industry insights.

[0003] In the current field of automated SSD testing, most technical solutions have significant limitations and lack comprehensive consideration. This forces test methods to frequently switch back and forth between actual user scenarios, making them difficult to adapt to diverse application environments. For example, a test case designed for an NVMe interface is difficult to quickly migrate to a SATA interface, and vice versa, severely impacting the versatility and efficiency of testing. Summary of the Invention

[0004] In view of this, an object of the present invention is to provide a method, apparatus, electronic device and storage medium for automated testing of solid-state drives, so as to realize cross-protocol automated testing and improve the versatility of testing.

[0005] In the first aspect, an embodiment of the present invention provides a method for automated testing of solid-state hard drives, which is applied to automated testing tools, including: screening a solid-state hard drive to be tested and a load tool corresponding to the solid-state hard drive to be tested in the solid-state hard drive based on a pre-built first configuration file and a first command line parameter; the first configuration file is in YAML format; specifying a performance test type through an IO option based on the first configuration file; based on the performance test type and a pre-built second configuration file, in combination with the second command line parameter, performing a performance test on the solid-state hard drive to be tested through the load tool corresponding to the solid-state hard drive to be tested; determining the load tool corresponding to the solid-state hard drive to be tested through the mapping relationship in the second configuration file for performance testing that supports both SATA interface and NVMe interface; determining a power-off type based on a pre-set third configuration file and performing a power-off test based on the power-off type and the third command line parameter; determining a specific function command based on a pre-set fourth configuration file and performing a specific test based on the specific function command.

[0006] In a preferred embodiment of the present invention, the above-mentioned screening of the solid-state hard disk to obtain the solid-state hard disk to be tested and the load tool corresponding to the solid-state hard disk to be tested based on the pre-constructed first configuration file and the first command line parameter includes: determining the screening rules based on the first configuration file; determining the solid-state hard disk to be tested and the load tool corresponding to the solid-state hard disk to be tested based on the screening rules and the case of the single slash parameter in the first command line parameter.

[0007] In a preferred embodiment of the present invention, the method of constructing the first configuration file includes:

[0008] A first initial configuration file is constructed using a YAML format; a filtering rule is defined in the first initial configuration file to obtain a first configuration file; wherein the filtering rule includes: a mode name, a load tool, and a rule for excluding a system solid-state drive.

[0009] In a preferred embodiment of the present invention, the above-mentioned performance test type and the pre-constructed second configuration file are combined with the second command line parameters to perform a performance test on the solid-state hard disk to be tested through the load tool corresponding to the solid-state hard disk to be tested, including: when the test type is the first type, determining the first block size, the first queue depth and the first number of jobs based on the second configuration file; based on the second command line parameters, combined with the first block size, the first queue depth and the first number of jobs, performing a performance test on the solid-state hard disk to be tested through the load tool corresponding to the solid-state hard disk to be tested; when the test type is the second type, determining the second block size, the second queue depth, the second number of jobs and special parameters based on the second configuration file; based on the second command line parameters, combined with the second block size, the second queue depth, the second number of jobs and special parameters, performing a performance test on the solid-state hard disk to be tested through the load tool corresponding to the solid-state hard disk to be tested.

[0010] In a preferred embodiment of the present invention, the above-mentioned determining the power failure type based on the preset third configuration file and performing the power failure test based on the power failure type and the third command line parameter includes:

[0011] The power-off timing is determined based on a preset third configuration file; and a power-off test is performed based on the power-off type, the power-off timing, and the third command line parameter.

[0012] In a preferred embodiment of the present invention, the above-mentioned determining the specific function command based on the pre-set fourth configuration file and performing the specific test based on the specific function command include: passing the specific function command through the Special option based on the fourth configuration file; determining the fourth command line parameter corresponding to the specific function command based on the fourth configuration file; and performing the specific test based on the fourth command line parameter.

[0013] In a preferred embodiment of the present invention, the second configuration file is configured with test type, block size, queue depth, number of jobs and / or special parameters; the third configuration file is configured with power-off type and power-off timing; power-off types include power-off restart and abnormal power-off; the fourth configuration file is configured with specific function commands and fourth command line parameters corresponding to the specific function commands.

[0014] In the second aspect, an embodiment of the present invention also provides an automated testing device for solid-state hard drives, which is applied to automated testing tools. The device includes: a screening module, which is used to screen the solid-state hard drives to be tested and the load tools corresponding to the solid-state hard drives to be tested in the solid-state hard drives based on a pre-built first configuration file and a first command line parameter; the first configuration file is in YAML format; a performance test type specification module, which is used to specify the performance test type through IO options based on the first configuration file; a performance testing module, which is used to perform a performance test on the solid-state hard drive to be tested through the load tool corresponding to the solid-state hard drive to be tested based on the performance test type and a pre-built second configuration file, combined with the second command line parameter; parameter mapping is performed through the mapping relationship in the second configuration file to determine the load tool corresponding to the solid-state hard drive to be tested, so as to provide performance testing that supports both SATA interface and NVMe interface; a power-off test module, which is used to determine the power-off type based on a pre-set third configuration file and perform a power-off test based on the power-off type and the third command line parameter; a specific test module, which is used to determine a specific function command based on a pre-set fourth configuration file and perform a specific test based on the specific function command.

[0015] In a third aspect, an embodiment of the present invention further provides an electronic device comprising a processor and a memory, wherein the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the method for automated testing of solid-state hard drives of the first aspect above.

[0016] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions prompt the processor to implement the method for automated testing of solid-state hard drives according to the first aspect above.

[0017] The embodiments of the present invention bring the following beneficial effects:

[0018] The embodiment of the present invention provides a method, device, electronic device and storage medium for automated testing of solid-state hard drives. The method obtains a solid-state hard drive to be tested and a load tool corresponding to the solid-state hard drive to be tested by screening the solid-state hard drive based on a pre-built first configuration file and a first command line parameter. The performance test type is specified through an IO option based on the first configuration file. The solid-state hard drive to be tested is subjected to a performance test through the load tool corresponding to the solid-state hard drive to be tested based on the performance test type and a pre-built second configuration file in combination with the second command line parameter. The load tool corresponding to the solid-state hard drive to be tested is determined by performing parameter mapping through the mapping relationship in the second configuration file to provide performance testing that supports both SATA interfaces and NVMe interfaces. The power-off type is determined based on a pre-set third configuration file and a power-off test is performed based on the power-off type and the third command line parameter. The specific function command is determined based on a pre-set fourth configuration file and a specific test is performed based on the specific function command. In this manner, cross-protocol automated testing is achieved, and the versatility of the test is improved.

[0019] Other features and advantages of the present disclosure will be set forth in the following description, or some features and advantages may be inferred or unambiguously determined from the description, or may be learned by practicing the above-mentioned technology of the present disclosure.

[0020] In order to make the above-mentioned objectives, features and advantages of the present disclosure more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0022] Figure 1 A flowchart of a method for automated testing of solid-state drives provided by an embodiment of the present invention;

[0023] Figure 2 A flowchart of another method for automated testing of solid-state drives provided by an embodiment of the present invention;

[0024] Figure 3 A schematic structural diagram of a solid-state drive automated testing device provided by an embodiment of the present invention;

[0025] Figure 4 A schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0027] Solid-state drives (SSDs), as key data storage devices, are attracting significant attention in today's digital age regarding their performance, reliability, and compatibility. Automated testing systems have emerged to address this need, with profound industry insights.

[0028] Driven by market demand: With exponential data growth, demand for SSDs continues to climb across various industries. Consumer electronics, from mobile phones and laptops to tablets, all require large-capacity, high-performance SSDs to store data and boost device speeds. Enterprise data centers rely even more heavily on SSDs to ensure rapid access to and write of massive amounts of data, meeting real-time business demands. To ensure SSDs operate stably and reliably in diverse scenarios, comprehensive and efficient testing is essential. Traditional manual testing methods are unable to meet these large-scale testing requirements, making automated testing systems the inevitable choice.

[0029] Increased technical complexity: SSD technology continues to evolve, and its internal architecture is becoming increasingly complex. From flash memory chip types like TLC (Triple-Level Cell), MLC (Multi-Level Cell), and QLC (Quad-Level Cell), to performance improvements in the main control chip, to various advanced technologies like the transition from SATA to NVMe protocols, SSD performance and functionality are continuously being optimized. However, this also increases the difficulty and complexity of testing, requiring compatibility with SATA and NVMe, precise control of test conditions, and monitoring of numerous parameters. Manual testing is not only inefficient but also prone to human error. Therefore, it is necessary to build an abstract automated testing system that, with its high precision, stability, and repeatability, can better handle these complex testing requirements.

[0030] Shorten product time-to-market: In the fiercely competitive storage market, SSD manufacturers need to quickly launch new products to capture market share. The shorter the product development to market cycle, the greater the market advantage. Automated testing systems can operate 24 / 7, significantly shortening testing time and accelerating product iterations. This allows manufacturers to more quickly bring SSDs with improved performance and enhanced functionality to market, meeting evolving user needs.

[0031] Consistency and reliability requirements: For SSDs, product quality consistency and reliability are crucial. SSDs produced in different batches must maintain the same performance and reliability standards to maintain brand reputation and user trust. Automated testing systems perform tests according to pre-set standard procedures and parameters, eliminating test variations caused by human factors. This ensures that every SSD undergoes a rigorous and consistent testing process, thereby improving overall product reliability and stability.

[0032] In the current field of automated testing for solid-state drives, most technical solutions have significant limitations and lack comprehensive considerations. This forces testing methods to frequently switch back and forth between actual user scenarios, making it difficult to adapt to diverse application environments. For example, if a test case is designed for an NVME interface, it is difficult to quickly port it to a SATA interface, and vice versa, seriously affecting the versatility and efficiency of the test. In addition, when executing tests, the focus is only on performance, while insufficient attention is paid to reliability issues. This results in some products that pass the test remaining at the theoretical level, becoming so-called "PPT products." In actual application, they encounter numerous problems and cannot meet the strict requirements of the real market for product stability and consistency.

[0033] Based on this, an embodiment of the present invention provides a method, device, electronic device and storage medium for automated testing of solid-state hard drives. The method, device and electronic device can obtain the solid-state hard drive to be tested and the load tool corresponding to the solid-state hard drive to be tested by screening the solid-state hard drive based on a pre-built first configuration file and a first command line parameter. The performance test type is specified through the IO option based on the first configuration file. The solid-state hard drive to be tested is subjected to a performance test through the load tool corresponding to the solid-state hard drive to be tested based on the performance test type and the pre-built second configuration file in combination with the second command line parameter. The load tool corresponding to the solid-state hard drive to be tested is determined by performing parameter mapping through the mapping relationship in the second configuration file, so as to provide performance testing that supports both SATA interface and NVMe interface. The power-off type is determined based on a pre-set third configuration file and a power-off test is performed based on the power-off type and the third command line parameter. The specific function command is determined based on the pre-set fourth configuration file and a specific test is performed based on the specific function command. In this way, cross-protocol automated testing is achieved, and the versatility of the test is improved.

[0034] To facilitate understanding of this embodiment, a method for automated testing of a solid-state drive disclosed in an embodiment of the present invention is first introduced in detail.

[0035] Example 1

[0036] An embodiment of the present invention provides a method for automated testing of a solid-state drive, which is applied to an automated testing tool named pytool.

[0037] Figure 1 The flowchart of a method for automatic testing of a solid state drive provided by an embodiment of the present invention is as follows. Figure 1 As shown, the method for automated testing of a solid-state drive may include the following steps:

[0038] Step S101 : Screening solid-state drives to be tested and load tools corresponding to the solid-state drives to be tested based on a pre-built first configuration file and a first command line parameter.

[0039] The first configuration file is in YAML format.

[0040] Step S102: specifying a performance test type through an IO option based on the first configuration file.

[0041] Step S103 : Based on the performance test type and the pre-built second configuration file, and in combination with the second command line parameters, a performance test is performed on the solid state drive to be tested by using a load tool corresponding to the solid state drive to be tested.

[0042] Among them, parameter mapping is performed through the mapping relationship in the second configuration file to determine the load tool corresponding to the solid-state hard drive to be tested, so as to provide performance testing that supports both SATA interface and NVMe interface.

[0043] Step S104 : determining the power-off type based on a preset third configuration file and performing a power-off test based on the power-off type and a third command line parameter.

[0044] Step S105 : determining a specific function command based on a preset fourth configuration file and performing a specific test based on the specific function command.

[0045] Among them, the second configuration file is configured with test type, block size, queue depth, number of jobs and / or special parameters; the third configuration file is configured with power-off type and power-off timing; power-off types include power-off restart and abnormal power-off; the fourth configuration file is configured with specific function commands and fourth command line parameters corresponding to the specific function commands.

[0046] The method for automated testing of solid-state hard drives provided by an embodiment of the present invention can obtain a solid-state hard drive to be tested and a load tool corresponding to the solid-state hard drive to be tested by screening in the solid-state hard drive based on a pre-built first configuration file and a first command line parameter, specify the performance test type through IO options based on the first configuration file, perform a performance test on the solid-state hard drive to be tested through the load tool corresponding to the solid-state hard drive to be tested based on the performance test type and a pre-built second configuration file in combination with the second command line parameter, perform parameter mapping through the mapping relationship in the second configuration file to determine the load tool corresponding to the solid-state hard drive to be tested, so as to provide performance testing that supports both SATA interface and NVMe interface, determine the power-off type based on a pre-set third configuration file and perform a power-off test based on the power-off type and the third command line parameter, determine a specific function command based on a pre-set fourth configuration file and perform a specific test based on the specific function command. In this way, cross-protocol automated testing is achieved, and the versatility of the test is improved.

[0047] Example 2

[0048] The embodiment of the present invention also provides another method for automated testing of solid-state drives; this method is implemented based on the method of the above embodiment.

[0049] Figure 2 A flowchart of another method for automated testing of solid-state drives provided by an embodiment of the present invention is shown in FIG. Figure 2 As shown, the method for automated testing of a solid-state drive may include the following steps:

[0050] Step S201: determining a screening rule based on a pre-built first configuration file.

[0051] Specifically, the construction method of the first configuration file may include: constructing a first initial configuration file using the YAML format; defining filtering rules in the first initial configuration file to obtain the first configuration file; wherein the filtering rules include: mode name, load tool, and rules for excluding system solid-state drives.

[0052] For example, by encapsulating ENV options, pytool can accurately map SSD devices in different environments. The example of configuring the first configuration file (EVN.config) is as follows:

[0053]

[0054]

[0055] In practice, a first configuration file in YAML format is used to define filtering rules, including the mode name, load tool, and rules for excluding system SSDs. YAML format is highly readable and maintainable, making it easy for users to customize filtering rules based on their specific needs, thereby improving the tool's scalability and flexibility.

[0056] Step S202 : Determine the solid-state drive to be tested and the load tool corresponding to the solid-state drive to be tested based on the screening rule and the capitalization of the single-slash parameter in the first command line parameter.

[0057] For example, the following are the first command line parameters: pytool env --list-dt, which tests all disks and all load tools on the system disk; pytool env --list-dt, which tests the disks and load tools to be tested on the system disk. Single-slash parameters are, for example, -D, -T, -d, and -t.

[0058] In practice, the first configuration file and the first command line parameter, combined with the case-sensitive nature of single-slash parameters within double-slash parameters, are used to exclude system SSDs and accurately identify the target SSDs and test tools to be tested. This screening method not only considers the physical characteristics of the device (such as the interface type) but also allows for flexible screening based on user-defined rules, adapting to different test scenarios and requirements.

[0059] Step S203: specifying a performance test type through an IO option based on the first configuration file.

[0060] To simplify the testing process, pytool encapsulates the parameters of two commonly used testing tools, FIO and Vdbench, into a unified parameter system. Users only need to specify the performance test type through the IO option.

[0061] Step S204 : Based on the performance test type and the pre-built second configuration file, and in combination with the second command line parameters, a performance test is performed on the solid state drive to be tested by using a load tool corresponding to the solid state drive to be tested.

[0062] Among them, parameter mapping is performed through the mapping relationship in the second configuration file to determine the load tool corresponding to the solid-state hard drive to be tested, so as to provide performance testing that supports both SATA interface and NVMe interface.

[0063] Specifically, based on the performance test type and a pre-built second configuration file, combined with the second command line parameters, a performance test is performed on the solid-state hard drive to be tested through a load tool corresponding to the solid-state hard drive to be tested, which may include: when the test type is the first type, determining the first block size, the first queue depth and the first number of jobs based on the second configuration file; based on the second command line parameters, combined with the first block size, the first queue depth and the first number of jobs, performing a performance test on the solid-state hard drive to be tested through the load tool corresponding to the solid-state hard drive to be tested; when the test type is the second type, determining the second block size, the second queue depth, the second number of jobs and special parameters based on the second configuration file; based on the second command line parameters, combined with the second block size, the second queue depth, the second number of jobs and special parameters, performing a performance test on the solid-state hard drive to be tested through the load tool corresponding to the solid-state hard drive to be tested.

[0064] Where bs represents the block size, qd represents the queue depth, and numjobs represents the number of jobs.

[0065] Illustratively, the second command line parameter is as follows: Pytool IO --perf-bs 4k-qd 8-numjobs 4—config, representing a general performance test; Pytool IO --perf-bs 4k-qd 8-numjobs 4 --extral "--offset14%", representing a special parameter IO test.

[0066] In order to make the second configuration file have good readability and easy-to-maintain structure, you can use the YAML format to write the second configuration file. The second configuration file will be divided into two parts: fio and vdbench, which correspond to the parameter settings of the FIO test tool and the Vdbench test tool respectively.

[0067] Exemplarily, an example of configuring the second configuration file (IO.config) is as follows:

[0068]

[0069]

[0070]

[0071] The second configuration file explains:

[0072] FIO part:

[0073] base_settings: defines the basic parameters of the FIO test, such as read and write mode, I / O engine, test time, etc. These parameters usually remain unchanged in each test.

[0074] parameter_mapping: Maps Pytool’s bs, qd, and numjobs parameters to their FIO counterparts so that the parameters are passed correctly when running the tests.

[0075] extral_mapping: Process special parameters of Pytool and map them to corresponding parameters of FIO.

[0076] Vdbench part:

[0077] base_settings: defines the basic parameters of the Vdbench test, including the definition of the disk, file system, and read and write operations. Again, these parameters usually remain unchanged in each test.

[0078] parameter_mapping: Maps the bs, qd, and numjobs parameters of Pytool to the corresponding parameters of Vdbench.

[0079] extral_mapping: Processes special parameters of Pytool and maps them to corresponding parameters of Vdbench.

[0080] Directions:

[0081] When running Pytool IO --perf -bs 4k-qd 8-numjobs 4 --config , Pytool reads the io.config file and passes the parameters to FIO or Vdbench for testing based on the mappings in it. For Pytool IO --perf -bs 4k-qd 8-numjobs 4 --extral "--offset 14%", the special parameter --offset 14% is also passed to the corresponding test tool based on the mappings in the configuration file. The runtime selects the load tool to be tested based on the information in ENV.config.

[0082] In practice, the parameters of the two testing tools, FIO and Vdbench, are encapsulated into a unified parameter system. Users simply specify the performance test type through IO options and combine them with a few parameters such as bs, qd, and numjobs to meet general performance testing needs. This parameter encapsulation simplifies the testing process and lowers the user barrier to entry, greatly improving testing convenience for users unfamiliar with the specific parameter settings of FIO and Vdbench.

[0083] Step S205 : determining the power failure type based on a preset third configuration file and performing a power failure test based on the power failure type and the third command line parameter.

[0084] For reliability testing, pytool's Cycle option implements various default power-down tests. Users can customize specific power-down methods through a third-party configuration file and use the time parameter to precisely control the timing of power-downs.

[0085] Specifically, determining the power-off type based on a preset third configuration file and performing a power-off test based on the power-off type and a third command line parameter may include: determining the power-off timing based on the preset third configuration file; and performing a power-off test based on the power-off type, the power-off timing, and the third command line parameter.

[0086] Exemplarily, the third command line parameter is as follows: Pytool Cycle --por-reboo --time IO:10, which means rebooting 10 seconds after IO startup; Pytool Cycle --spor-ipmi --time IO:10, which means powering off ipmi 10 seconds after IO startup; Pytool Cycle --por config --time IO:20, which means powering off as specified in the configuration file 20 seconds after IO startup.

[0087] The following is an example of a third configuration file for pytool Cycle options, written in YAML format, which is convenient for customizing the specific method of special power-down.

[0088]

[0089]

[0090]

[0091] The third configuration file explains:

[0092] power_cycle_types: is a top-level key that contains the configuration of different power-down types. Each power-down type (such as por, spor_ipmi, por_config) has its own configuration items.

[0093] Configuration for each power-down type:

[0094] base_settings: Contains the basic settings for this power-off type, such as power-off duration, restart delay, IPMI-related information, etc. These settings can be referenced in the commands of custom steps using template variables (such as: {{power_off_duration}}).

[0095] custom_steps: is a list of steps, each step contains the following information:

[0096] step: A description of the step, used to explain the operation content of the step.

[0097] command: The command to be executed, which can be a system command, script call, etc. Template variables can be used to reference parameters in base_settings.

[0098] delay_before: The time (in seconds) to wait before executing this step.

[0099] Example usage:

[0100] When running PytoolCycle --por-config --timeIO:20, pytool will read the configuration of the por_config part of the cycle.config file and perform power-down operations according to the configured steps 20 seconds after the IO is started.

[0101] In practice, pytool's Cycle option supports various default power-off tests, including normal power-off restart (POR) and abnormal power-off (SPOR) using IPMI. It also allows users to customize specific power-off methods through configuration files. This diverse power-off testing support simulates different real-world application scenarios and more comprehensively tests the reliability of SSDs under various power-off conditions.

[0102] Precise power-off timing control: Users can use the time parameter to precisely control power-off timing. By integrating the timing of I / O testing and power-off testing, various complex real-world application scenarios can be simulated. In actual use, SSDs may experience power outages under different operating conditions. Precise power-off timing control can more realistically simulate these scenarios and improve the accuracy of test results.

[0103] Configuration file-driven power-off operation customization: YAML-formatted configuration files are used to define basic settings and customized operation steps for different power-off types. Users can modify parameters such as power-off duration, restart delay, and IPMI-related information as needed, and can also customize power-off operation commands and steps. This configuration file-driven approach makes power-off test customization more flexible and can meet the specific needs of different users.

[0104] Step S206 : determining a specific function command based on a preset fourth configuration file and performing a specific test based on the specific function command.

[0105] To meet more specialized testing needs, pytool provides the "Special" option for passing in specific function commands. By integrating I / O testing, power-down testing (Cycle), and special function commands (Special), it is possible to implement specialized test sequences, ensuring that the performance and reliability of SSDs under various extreme or complex conditions can be fully verified.

[0106] Specifically, determining a specific function command based on a pre-set fourth configuration file and performing a specific test based on the specific function command may include: passing the specific function command through the Special option based on the fourth configuration file; determining a fourth command line parameter corresponding to the specific function command based on the fourth configuration file; and performing a specific test based on the fourth command line parameter.

[0107] For example, the fourth command line parameter is as follows: Pytool Special --longterm --count Cycle: 200 --time IO: 100, which represents a function sequence of the special sequence longterm defined in the configuration file, and the tool defined in the fourth configuration file performs 100 seconds of IO and 200 power cycles.

[0108] Assuming our special function sequence only includes smart logging, the following configuration example is available. For more complex use cases, multiple statements can be combined. Negative values can be used in time to overlap I / O and cycles.

[0109] The following is an example of a configuration file for the Special option, in YAML format. This configuration file meets the test requirements such as Pytool Special --longterm --count Cycle: 200 --time IO: 100 and includes a special function sequence for reading SMART logs.

[0110]

[0111]

[0112] In practical applications, the Special option integrates I / O testing, power-off testing (Cycle), and special function commands to implement special test sequences. In actual testing, SSDs may require comprehensive testing under different operating conditions and environments. By integrating multiple test types, the performance and reliability of SSDs can be more comprehensively evaluated under various extreme or complex conditions.

[0113] Special parameter pass-through mechanism: Extral special parameters are provided for transparently transmitting some special settings. In actual testing, you may encounter some specific test scenarios that require the use of special parameters of FIO or Vdbench. Through extral parameters, users can easily pass these special parameters to the test tool, enhancing the flexibility and adaptability of the tool.

[0114] Configuration file mapping mechanism: Pytool's unified parameter system is mapped to the parameter settings of FIO and Vdbench through the configuration file. This mapping mechanism enables Pytool to seamlessly switch between different test tools while ensuring the accuracy and consistency of parameter transfer, improving the reliability of test results.

[0115] Time Overlap Simulation: Supports overlapping I / O and Cycle times by introducing negative numbers, more realistically simulating the timing relationships between different operations in real-world application scenarios. In real-world use, I / O operations and power outages may overlap in time. Time Overlap Simulation allows for more accurate testing of SSD performance and reliability in such complex situations.

[0116] Configuration file-driven special sequence definition: Use YAML-formatted configuration files to define the operation steps and time overlap configuration of special sequences. Users can customize the test process and parameters of special sequences as needed. This configuration file-driven approach makes special sequence definition more flexible and maintainable, meeting the specific testing needs of different users.

[0117] The automated SSD testing method provided by the present invention has cross-protocol capabilities and can support testing of SSDs with both SATA and NVMe interfaces. This cross-protocol support greatly enhances the tool's versatility and applicability, eliminating the need for testers to use separate testing tools for SSDs with different interfaces, thereby improving testing efficiency.

[0118] Example 3

[0119] Corresponding to the above method embodiment, the embodiment of the present invention provides a solid state hard disk automatic testing device, which is applied to an automatic testing tool. Figure 3 A schematic diagram of the structure of a solid state drive automated testing device provided by an embodiment of the present invention is shown in FIG. Figure 3 As shown, the solid state drive automated testing device may include:

[0120] The screening module 301 is used to screen the solid-state drive to be tested and the load tool corresponding to the solid-state drive to be tested in the solid-state drive based on the pre-built first configuration file and the first command line parameter; the first configuration file is in YAML format.

[0121] The performance test type specifying module 302 is configured to specify a performance test type through an IO option based on the first configuration file.

[0122] The performance testing module 303 is used to perform a performance test on the solid-state hard drive to be tested based on the performance test type and a pre-built second configuration file, combined with the second command line parameters, through the load tool corresponding to the solid-state hard drive to be tested; and to determine the load tool corresponding to the solid-state hard drive to be tested by performing parameter mapping through the mapping relationship in the second configuration file, so as to provide performance testing that supports both SATA interface and NVMe interface.

[0123] The power failure test module 304 is configured to determine a power failure type based on a preset third configuration file and perform a power failure test based on the power failure type and a third command line parameter.

[0124] The specific test module 305 is configured to determine a specific function command based on a preset fourth configuration file and perform a specific test based on the specific function command.

[0125] The solid-state hard disk automation test device provided by the embodiment of the present invention can obtain the solid-state hard disk to be tested and the load tool corresponding to the solid-state hard disk to be tested by screening in the solid-state hard disk based on a pre-built first configuration file and a first command line parameter, specify the performance test type through the IO option based on the first configuration file, perform a performance test on the solid-state hard disk to be tested through the load tool corresponding to the solid-state hard disk to be tested based on the performance test type and the pre-built second configuration file in combination with the second command line parameter, perform parameter mapping through the mapping relationship in the second configuration file to determine the load tool corresponding to the solid-state hard disk to be tested, so as to provide performance testing that supports both SATA interface and NVMe interface, determine the power-off type based on the pre-set third configuration file and perform a power-off test based on the power-off type and the third command line parameter, determine a specific function command based on the pre-set fourth configuration file and perform a specific test based on the specific function command. In this way, cross-protocol automated testing is achieved, and the versatility of the test is improved.

[0126] In some embodiments, the screening module is further used to determine screening rules based on the first configuration file; and determine the solid-state drive to be tested and the load tool corresponding to the solid-state drive to be tested based on the screening rules and the case of the single-slash parameter in the first command line parameter.

[0127] In some embodiments, the filtering module is further used to construct a first initial configuration file using the YAML format; define filtering rules in the first initial configuration file to obtain a first configuration file; wherein the filtering rules include: pattern name, load tool, and rules for excluding system solid-state drives.

[0128] In some embodiments, the performance testing module is further used to determine the first block size, the first queue depth and the first number of jobs based on the second configuration file when the test type is the first type; based on the second command line parameters, in combination with the first block size, the first queue depth and the first number of jobs, perform a performance test on the solid-state hard drive to be tested through a load tool corresponding to the solid-state hard drive to be tested; when the test type is the second type, determine the second block size, the second queue depth, the second number of jobs and special parameters based on the second configuration file; based on the second command line parameters, in combination with the second block size, the second queue depth, the second number of jobs and special parameters, perform a performance test on the solid-state hard drive to be tested through the load tool corresponding to the solid-state hard drive to be tested.

[0129] In some embodiments, the power-off test module is further configured to determine a power-off timing based on a preset third configuration file; and perform a power-off test based on the power-off type, the power-off timing, and a third command line parameter.

[0130] In some embodiments, the specific test module is further used to pass in a specific function command through the Special option based on a fourth configuration file; determine that the specific function command corresponds to a fourth command line parameter based on the fourth configuration file; and perform a specific test based on the fourth command line parameter.

[0131] In some embodiments, the second configuration file is configured with test type, block size, queue depth, number of jobs and / or special parameters; the third configuration file is configured with power-off type and power-off timing; power-off types include power-off restart and abnormal power-off; the fourth configuration file is configured with specific function commands and fourth command line parameters corresponding to the specific function commands.

[0132] The device provided in the embodiment of the present invention has the same implementation principle and technical effects as those in the aforementioned method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference can be made to the corresponding content in the aforementioned method embodiment.

[0133] Example 4

[0134] The embodiment of the present invention also provides an electronic device for running the above-mentioned method for automated testing of solid state drives; see Figure 4 A structural diagram of an electronic device is shown, which includes a memory 400 and a processor 401, wherein the memory 400 is used to store one or more computer instructions, and the one or more computer instructions are executed by the processor 401 to implement the above-mentioned method of automated testing of solid-state drives.

[0135] Furthermore, Figure 4 The electronic device shown further includes a bus 402 and a communication interface 403 , and the processor 401 , the communication interface 403 and the memory 400 are connected via the bus 402 .

[0136] The memory 400 may include a high-speed random access memory (RAM), and may also include a non-volatile memory, such as at least one disk storage. The communication connection between the system network element and at least one other network element is achieved through at least one communication interface 403 (which may be wired or wireless), and the Internet, wide area network, local area network, metropolitan area network, etc. may be used. The bus 402 may be an ISA bus, a PCI bus, or an EISA bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0137] The processor 401 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits in the processor 401 or by software instructions. The above processor 401 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in conjunction with the embodiments of the present invention can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in memory 400, and processor 401 reads the information in memory 400 and, in conjunction with its hardware, completes the steps of the method of the aforementioned embodiment.

[0138] An embodiment of the present invention also provides a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions prompt the processor to implement the above-mentioned method of automated testing of solid-state drives. The specific implementation can be found in the method embodiment and will not be repeated here.

[0139] The computer program product of the method for performing automated testing of solid-state hard drives provided in an embodiment of the present invention includes a computer-readable storage medium storing non-volatile program code executable by a processor. The instructions included in the program code can be used to execute the methods described in the previous method embodiments. For specific implementation, please refer to the method embodiments and will not be repeated here.

[0140] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0141] In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. There may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed may be through some communication interface, indirect coupling or communication connection of devices or units, which may be electrical, mechanical or other forms.

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

[0143] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0144] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0145] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the above-described embodiments, those skilled in the art should understand that any person skilled in the art can modify or easily conceive of changes to the technical solutions described in the above-described embodiments within the technical scope disclosed by the present invention, or replace some of the technical features therein with equivalents. Such modifications, changes, or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A method for automated testing of solid-state drives, characterized in that: Applied to automated testing tools, the method includes: Screening the solid-state drive to be tested and the load tool corresponding to the solid-state drive to be tested in the solid-state drive based on a pre-built first configuration file and a first command line parameter; the first configuration file is in YAML format; Specifying a performance test type through an IO option based on the first configuration file; Based on the performance test type and the pre-built second configuration file, in combination with the second command line parameter, the performance test of the solid-state drive to be tested is performed through the load tool corresponding to the solid-state drive to be tested; parameter mapping is performed through the mapping relationship in the second configuration file to determine the load tool corresponding to the solid-state drive to be tested, so as to provide performance testing that supports both SATA interface and NVMe interface; determining a power-off type based on a preset third configuration file and performing a power-off test based on the power-off type and a third command line parameter; A specific function command is determined based on a preset fourth configuration file, and a specific test is performed based on the specific function command.

2. The method according to claim 1, characterized in that The method of screening the solid-state hard disk to obtain the solid-state hard disk to be tested and the load tool corresponding to the solid-state hard disk to be tested based on the pre-built first configuration file and the first command line parameter includes: determining a screening rule based on the first configuration file; The solid-state hard disk to be tested and the load tool corresponding to the solid-state hard disk to be tested are determined based on the screening rule and the capitalization of the single-slash parameter in the first command line parameter.

3. The method according to claim 2, characterized in that The first configuration file is constructed in the following manner: Construct the first initial configuration file using YAML format; Defining the screening rule in the first initial configuration file to obtain the first configuration file; The screening rules include: mode name, load tool, and rules for excluding system solid-state drives.

4. The method according to claim 1, wherein The performing of a performance test on the solid-state drive to be tested by using a load tool corresponding to the solid-state drive to be tested based on the performance test type and the pre-built second configuration file in combination with a second command line parameter includes: When the test type is a first type, determining a first block size, a first queue depth, and a first number of jobs based on the second configuration file; Based on the second command line parameter, in combination with the first block size, the first queue depth, and the first number of jobs, a performance test is performed on the solid-state drive to be tested using a load tool corresponding to the solid-state drive to be tested; When the test type is a second type, determining a second block size, a second queue depth, a second number of jobs, and special parameters based on the second configuration file; Based on the second command line parameter, combined with the second block size, the second queue depth, the second number of jobs and the special parameters, a performance test is performed on the solid-state drive to be tested using a load tool corresponding to the solid-state drive to be tested.

5. The method according to claim 1, wherein The determining the power-off type based on a preset third configuration file and performing a power-off test based on the power-off type and a third command line parameter includes: determining a power-off timing based on a preset third configuration file; A power-off test is performed based on the power-off type, the power-off timing, and the third command line parameter.

6. The method according to claim 1, characterized in that The determining of a specific function command based on a preset fourth configuration file and performing a specific test based on the specific function command includes: Passing the specific function command via the Special option based on the fourth configuration file; Determining, based on the fourth configuration file, that the specific function command corresponds to a fourth command line parameter; A specific test is performed based on the fourth command line parameter.

7. The method according to any one of claims 1 to 6, characterized in that The second configuration file is configured with the test type, block size, queue depth, number of jobs and / or special parameters; the third configuration file is configured with the power-off type and power-off timing; the power-off types include power-off restart and abnormal power-off; the fourth configuration file is configured with specific function commands and the fourth command line parameters corresponding to the specific function commands.

8. A device for automated testing of solid-state hard disks, characterized in that: Applied to automated testing tools, the device comprises: A screening module, configured to screen the solid-state drives for a test solid-state drive and a load tool corresponding to the test solid-state drive based on a pre-built first configuration file and a first command line parameter; the first configuration file is in YAML format; A performance test type specifying module, configured to specify a performance test type through an IO option based on the first configuration file; A performance testing module is configured to perform a performance test on the solid-state drive to be tested based on the performance test type and a pre-built second configuration file in combination with a second command line parameter through a load tool corresponding to the solid-state drive to be tested; and to determine the load tool corresponding to the solid-state drive to be tested by performing parameter mapping through a mapping relationship in the second configuration file, so as to provide performance testing that supports both SATA and NVMe interfaces. a power-off test module, configured to determine a power-off type based on a preset third configuration file and perform a power-off test based on the power-off type and a third command line parameter; The specific test module is used to determine a specific function command based on a preset fourth configuration file and perform a specific test based on the specific function command.

9. An electronic device, characterized in that: The method comprises a processor and a memory, wherein the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the method for automated testing of a solid-state hard disk according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions. When the computer-executable instructions are called and executed by the processor, the computer-executable instructions prompt the processor to implement the method for automated testing of solid-state drives according to any one of claims 1 to 7.

Images