Solid State Drive Testing Methods and Apparatus

Abstract

This application discloses a solid-state drive (SSD) testing method and apparatus, relating to the field of computer technology. The method includes: adapting a test environment to a benchmark based on multiple SSD versions; generating test environment configuration information; decomposing the NVMe protocol tests of multiple SSD versions into multiple atomic test items and clustering them into multiple functional test items to generate a test case set for the SSD; identifying the actual version of the target SSD; calling the corresponding test environment configuration information from the test environment configuration information to execute the corresponding multiple functional test items called from the test case set; and generating structured test results for multiple functional test items. This method solves the problems in related technologies where testing is mostly focused on basic functional verification, with insufficient coverage of new protocol features and abnormal scenarios, long testing times, and inability to systematically analyze results. It achieves the technical effect of a unified test environment, full protocol feature coverage, one-click automated execution, and structured result output—a complete engineering solution.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a solid-state drive testing method and apparatus. Background Technology

[0002] As the NVMe (Non-Volatile Memory Express) protocol has evolved, the features supported by SSDs (Solid State Drives) have expanded from basic read and write operations to more than forty advanced features, including Format, Sanitize, SR-IOV (Single Root I / O Virtualization), Persistent Event Log, Telemetry, Directive Streams, and TCG Opal (TCG Opal Specification).

[0003] In related technologies, the testing and verification of SSD functionality often relies on test engineers manually entering commands or writing scattered scripts.

[0004] However, in related technologies, manual testing by test engineers mainly focuses on basic functional verification, and the coverage of new features and abnormal scenarios is seriously insufficient. Manual testing takes an average of 2-3 person-days, which cannot meet the needs of rapid iteration development. Moreover, the test results are easily affected by test conditions, are difficult to reproduce, and the test logs are also in different formats, making it difficult to conduct systematic analysis and horizontal comparison with competitors. These issues urgently need to be addressed. Summary of the Invention

[0005] This application provides a solid-state drive testing method and apparatus to at least solve the problems that rely on manual testing by test engineers, which is mostly focused on basic function verification, has insufficient coverage of new protocol features and abnormal scenarios, takes a long average time for item-by-item testing, cannot adapt to the development needs of rapid iteration, and the test results are easily affected by test conditions, are difficult to reproduce, and the test logs are in different formats, making it difficult to conduct systematic analysis and horizontal comparison with competitors.

[0006] This application provides a solid-state drive (SSD) testing method, comprising the following steps: generating test environment configuration information for the SSD based on test environment adaptation benchmarks for multiple versions of the SSD, and decomposing the non-volatile memory host controller interface specification test of the multiple versions of the SSD into multiple atomic test items; clustering the multiple atomic test items into multiple functional test items to generate a test case set for the SSD based on the multiple functional test items, and identifying the actual version of the target SSD; calling the test environment configuration information corresponding to the actual version from the test environment configuration information to execute the multiple functional test items corresponding to the actual version called from the test case set, and generating structured test results for the multiple functional test items.

[0007] This application also provides a solid-state drive (SSD) testing apparatus, comprising: a decomposition module, used to generate test environment configuration information for the SSD based on test environment adaptation benchmarks for multiple versions of the SSD, and decompose the non-volatile memory host controller interface specification test of the multiple versions of the SSD into multiple atomic test items; a clustering module, used to cluster the multiple atomic test items into multiple functional test items, so as to generate a test case set for the SSD based on the multiple functional test items, and identify the actual version of the target SSD; and a testing module, used to call test environment configuration information corresponding to the actual version from the test environment configuration information, so as to execute the multiple functional test items corresponding to the actual version called from the test case set, and generate structured test results for the multiple functional test items.

[0008] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described solid-state drive testing methods.

[0009] This application also provides a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described solid-state drive testing methods.

[0010] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described solid-state drive testing methods.

[0011] This application enables the decomposition of non-volatile memory host controller interface specification testing for multiple versions of solid-state drives into multiple atomic test items, which are then clustered into multiple functional test items. These functional test items are executed by calling the test environment configuration information corresponding to the actual version, generating structured test results. This addresses the technical problems in related technologies where manual testing by test engineers focuses primarily on basic functional verification, resulting in insufficient coverage of new protocol features and abnormal scenarios. The average time spent on item-by-item testing is long, failing to meet the demands of rapid iteration in development. Furthermore, test results are easily affected by test conditions, making them difficult to reproduce, and test logs are inconsistent in format, hindering systematic analysis and competitor comparison. This application achieves the goal of ensuring the reproducibility and comparability of test results through test environment solidification, providing a reliable data foundation for competitor analysis. By decomposing NVMe protocol testing into atomic test items, it achieves comprehensive coverage testing of various NVMe protocol features, avoiding the problem of missing new features in manual testing. This significantly shortens the average testing time, improves testing efficiency, and allows the structured output results to be directly imported into intelligent tools for systematic analysis and competitor comparison. Attached Figure Description

[0012] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of a solid-state drive testing method according to an embodiment of this application;

[0014] Figure 2 This is a schematic diagram of the architecture for a fully automated test of a solid-state drive based on the NVMe protocol according to one embodiment of this application;

[0015] Figure 3 This is a schematic diagram of a solid-state drive testing device provided in an embodiment of this application.

[0016] Figure label:

[0017] Among them, 10 is a solid-state drive testing device; 100 is a decomposition module; 200 is a clustering module; and 300 is a testing module. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

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

[0020] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] The embodiments of this application provide a solid-state drive (SSD) testing method, and the method is described in detail in conjunction with the execution flow of the SSD testing method.

[0022] Specifically, Figure 1 This is a flowchart of a solid-state drive testing method provided according to an embodiment of this application.

[0023] like Figure 1 As shown, the solid-state drive testing method includes the following steps:

[0024] In step S101, based on the test environment adaptation benchmarks of multiple versions of solid-state drives, test environment configuration information of solid-state drives is generated, and the non-volatile memory host controller interface specification test of multiple versions of solid-state drives is decomposed into multiple atomic test items.

[0025] It is understandable that solid-state drives (hereinafter referred to as SSDs) will have different versions with each generation, each with different functions, and the testing environment required for each version is also different. It should be noted that the multiple versions of SSDs in this application embodiment refer to SSD products with differences in core technical specifications or iteration versions, rather than simply different models of SSD products. For example, in terms of protocol version, there are SSDs that support NVMe 1.4 and SSDs that support NVMe 2.1 (which adds advanced features such as SR-IOV and Telemetry compared to NVMe 1.4); in terms of product iteration, SSD V1.0 of a certain product only has basic read and write functions, while SSD V2.0 adds features such as TCG Opal and Sanitize; in terms of function adaptation, consumer-grade SSDs generally only support basic functions, while enterprise-grade SSDs can support virtualization, persistent event logging, and other functions.

[0026] In order to automatically adapt to the testing requirements of all versions of solid-state drives, in some embodiments, this application can generate test environment configuration information corresponding to multiple versions of solid-state drives based on the test environment adaptation benchmark of multiple versions of solid-state drives.

[0027] In short, the embodiments of this application can generate test environment configuration information corresponding to each version of the solid-state drive that can be directly applied to the application, based on the test environment adaptation benchmark of each version of the solid-state drive.

[0028] Here, the test environment adaptation benchmark can be understood as the core basis / standardization principle for what test environment a certain version of SSD is suitable for. For example, the test environment adaptation benchmark for NVMe 2.1 SSD is: it must support PCIe (Peripheral Component Interconnect Express, a high-speed serial computer expansion bus standard) 4.0 interface, Linux (an operating system) 5.15+ kernel, and nvme-cli (NVMe Command Line Interface, NVMe command line interface tool) 2.0+ toolchain; while the test environment adaptation benchmark for NVMe 1.4 SSD only requires PCIe 3.0 interface, Linux 4.15+ kernel, and nvme-cli 1.10.

[0029] The test environment configuration information here can be understood as a list of specific test parameters that can be directly used to build a test environment for a certain version of SSD, based on the adaptation benchmark of a certain version of SSD test environment.

[0030] Furthermore, embodiments of this application can further decompose the testing of multiple versions of the Non-Volatile Memory Host Controller Interface Specification (hereinafter referred to as the NVMe protocol) for solid-state drives into multiple atomic test items. Here, an atomic test item can be understood as the smallest, indivisible test unit generated after decomposing the overall test objective of the NVMe protocol.

[0031] Each atomic test item tests a specific detail of a feature within the NVMe protocol actually supported by the SSD. For example, it might verify whether the SSD returns a value of 0 for the Format command. Here, "feature point" refers to the NVMe protocol functionality actually supported by different SSD versions.

[0032] Specifically, the embodiments of this application can decompose the NVMe protocol testing requirements into multiple atomic test items based on the NVMe protocol and industry standards, and then achieve the testing of multiple functions of the SSD through NVMe protocol testing.

[0033] In this context, the NVMe protocol testing requirements can be understood as the sum of all clearly defined test objectives, verification scope, and acceptance criteria for verifying whether the SSD can fully and correctly respond to commands and implement functions in accordance with the NVMe protocol requirements.

[0034] This application embodiment can generate targeted test environment configuration information based on the dedicated test environment adaptation benchmark for each version of SSD, which can effectively avoid test failure or test result distortion caused by test environment incompatibility in the subsequent process; furthermore, this application embodiment can also achieve complete coverage of NVMe protocol function testing by splitting NVMe protocol testing into multiple atomic test items, effectively meeting the NVMe protocol function testing of multiple versions of SSD.

[0035] Optionally, in one embodiment of this application, test environment configuration information corresponding to the solid-state drive is generated based on the test environment adaptation benchmarks of multiple versions of solid-state drives, including: obtaining operating system information, kernel version information, toolchain version information and hardware platform configuration information of multiple versions of solid-state drives; and constructing test environment configuration information corresponding to multiple versions of solid-state drives based on the operating system information, kernel version information, toolchain version information and hardware platform configuration information.

[0036] In actual implementation, when generating test environment configuration information for multiple versions of solid-state drives based on the test environment adaptation benchmark of multiple versions of solid-state drives, the generated test environment configuration information includes, but is not limited to, operating system information, kernel version information, toolchain version information, and hardware platform configuration information for multiple versions of solid-state drives.

[0037] Among them, operating system information, kernel version information, and toolchain version information are the core parameters of the software testing environment adapted to the functions and testing requirements of each version of SSD, such as Ubuntu (an operating system) 22.04, Linux 5.15, nvme-cli 2.0, etc.; hardware platform configuration information refers to the hardware environment parameters required for testing adapted to the functions and testing requirements of each version of SSD, such as motherboards supporting PCIe 4.0 interfaces, memory requirements, etc.

[0038] In practical applications, embodiments of this application may, but are not limited to, design the test environment configuration information corresponding to multiple versions of solid-state drives (SSDs) generated based on test environment adaptation benchmarks of multiple versions of SSDs as an environment solidification layer:

[0039] For example, this application can first ensure the consistency of the test environment by using the hardware specifications, software version, and automatic verification script in the config.ini configuration file (a configuration file in the SSD test environment).

[0040] Then, this embodiment of the application can, but is not limited to, use the ConfigParser (the core module in the Python standard library used to parse INI format configuration files) from the Python Standard Library (a collection of modules, functions, classes, and tools that come with the Python interpreter by default) to read the configuration file config.ini in the same directory as the script. Before testing, the script automatically compares the version information of the current environment with that of the standard environment. If, through Linux commands, it is determined that the hardware is not x86_64 (the hardware platform configuration information corresponding to this version of SSD), the test is immediately terminated and the user is prompted. If the kernel and OS (Operator System) are inconsistent, the test must also be stopped. If the software tool version is abnormal, Linux commands are used to attempt to automatically install the specified version through the package manager. If the installation fails, the test is immediately stopped and the user is prompted. Thus, automatic verification and repair of the environment solidification layer can be achieved.

[0041] The embodiments of this application can lock the operating system, kernel version, toolchain version and hardware platform configuration required for NVMe protocol testing in SSDs. This can ensure the uniqueness and reproducibility of the test environment, provide a reliable standardized basis for test compliance traceability, cross-version comparison and problem localization, and accurately adapt to the technical characteristics of various SSD versions, such as the advanced functions of different NVMe protocol versions, effectively ensuring the accuracy of NVMe functional testing in verifying functions and performance.

[0042] Step S102: Cluster multiple atomic test items into multiple functional test items to generate a test case set for the solid-state drive based on the multiple functional test items, and identify the actual version of the target solid-state drive.

[0043] As those skilled in the art will understand, each atomic test item tests a detail of a functional point. However, SSDs implement multiple functions. Therefore, when testing multiple functions of an SSD based on the NVMe protocol, each function of the SSD can correspond to multiple atomic test items decomposed from the NVMe protocol test.

[0044] Therefore, in some embodiments, after decomposing the NVMe protocol test of multiple versions of solid-state drives into multiple atomic test items, this application can cluster the multiple atomic test items into multiple functional test items according to certain criteria / specifications, and generate a test case set for each version of SSD based on the multiple functional test items and the actual functional test requirements of each version of SSD.

[0045] In this context, a functional test item refers to a functional-level test unit formed by clustering atomic test items. It corresponds to an independent functional module of the NVMe protocol, which is a functional point containing multiple atomic test items. For example, atomic item A (command reception) + atomic item B (result valid) + atomic item C (abnormal recovery) + atomic item D (erase time meets standard) together test the Sanitize secure erase function in the SSD.

[0046] The test case set here refers to a complete and executable test list consisting of all functional test items corresponding to the actual functional test requirements of any SSD version, containing multiple functional test items. The actual functional test requirements of the SSD here refer to the scope of functions that need to be verified by the SSD, which is generally determined by the technical specifications and application scenarios of that SSD version.

[0047] For example, atomic test item 1 verifies the SSD return code of the Format command; atomic test item 2 verifies the format of the Format command; atomic test item 3 verifies the mapping table reset information after the Format command is executed. Atomic test item 1 "Format command return code verification", atomic test item 2 "Format LBA format verification", and atomic test item 3 "Format execution mapping table reset verification" are clustered under "Format formatting function".

[0048] Subsequently, embodiments of this application can identify the actual version of the target solid-state drive, and thus perform corresponding tests based on the information of the actual version of the target solid-state drive.

[0049] The embodiments of this application can cluster atomic test items into functional test items, which facilitates the flexible combination, execution and problem localization of test cases, and finally generates a test case set for each version of SSD, which can meet the standardization requirements of testing multiple versions of SSD products and adapt to the needs of SSD testing in various scenarios.

[0050] Optionally, in one embodiment of this application, multiple atomic test items are clustered into multiple functional test items, including: determining the functional correlation between multiple atomic test items based on the functional points of multiple versions of solid-state drives; and clustering multiple atomic test items into multiple functional test items based on the functional correlation between multiple atomic test items.

[0051] Based on the descriptions of other embodiments, it is understood that each atomic test item can implement one function point of the SSD. Therefore, when decomposing the NVMe protocol test requirements into multiple atomic test items, this application may, but is not limited to, decompose the non-volatile memory host controller interface specification test into multiple atomic test items according to the function points of each version of the solid-state drive.

[0052] Then, embodiments of this application may, but are not limited to, determine the functional correlation between multiple atomic test items based on the function points of multiple versions of solid-state drives, and cluster the multiple atomic test items into multiple functional test items accordingly.

[0053] In this context, the functional correlation between multiple atomic test items can be understood as the commonality of the core functional attributes among the atomic test items, that is, whether the atomic test items belong to the same functional module in the NVMe protocol.

[0054] For example, SSD V1 supports features such as Identify (device identification) and Read / Write, while SSD V2 adds TCG Opal and Sanitize features on top of SSD V1. Among the disassembled atomic test items, "verify Identify reads manufacturer information" and "verify Identify reads protocol version" both belong to the "Identify" feature, so these two atomic test items are both basic management features corresponding to this feature. "verify TCG Opal key writing" and "verify TCG Opal encryption effective" both belong to the "TCG Opal" feature, so these two atomic test items are both security features corresponding to this feature.

[0055] Furthermore, embodiments of this application can also provide multiple test configurations based on the clustering combination of functional relevance and preset execution priority after decomposing test requirements into multiple atomic test items according to the NVMe protocol and industry standards. That is, by combining functional test items and preset execution priorities (e.g., basic function priority > security function > advanced function), multiple test configurations are provided for the clustered functional test item combinations. For example, if the functional test items are basic management, security features, and advanced function modules, the test configuration can be: basic function quick configuration = basic management module + data transmission module; full function configuration = all functional test items sorted by priority, etc.

[0056] The preset execution priority can be understood as the order in which atomic test items are executed, such as according to the rules of basic → core → advanced, etc., thereby ensuring that the logic in actual testing is reasonable, such as verifying the correctness of the device first, and then verifying data reading and writing.

[0057] This application embodiment can decompose the NVMe protocol test into multiple atomic test items according to the functional points of multiple versions of solid-state drives. This ensures that the atomic test items can accurately adapt to the functional differences of multiple versions of solid-state drives, while also fully covering the NVMe protocol test without redundancy or omissions. For example, it can achieve 100% coverage testing of more than 40 features of the NVMe 2.1 protocol, avoiding the problem of missing new features in manual testing.

[0058] Furthermore, embodiments of this application can also use functional correlation clustering and priority sorting to ensure that functional test items and test case sets composed of functional test items conform to the logic of the NVMe protocol, thereby ensuring a reasonable execution order of tests. This helps to achieve cross-version SSD reuse of test resources, reduce maintenance costs, and effectively improve test efficiency.

[0059] Optionally, in one embodiment of this application, based on the functional correlation between multiple atomic test items, multiple atomic test items are clustered into multiple functional test items, including: collecting device information interaction characteristics, data security characteristics, protocol extension characteristics, and data transmission characteristics of the non-volatile memory host controller interface specification test; and clustering multiple atomic test items into multiple functional test items based on device information interaction characteristics, data security characteristics, protocol extension characteristics, and data transmission characteristics.

[0060] In some embodiments, when this application clusters multiple atomic test items into multiple functional test items according to their functional correlation, it may collect, but is not limited to, various core functional characteristics of the NVMe protocol. These core functional characteristics include the functional correlation between various atomic test items, such as device information interaction characteristics, data security characteristics, protocol extension characteristics, data transmission characteristics, etc. Then, the multiple atomic test items are clustered into multiple functional test items according to these device information interaction characteristics, data security characteristics, protocol extension characteristics, and data transmission characteristics.

[0061] Among them, the information interaction characteristics correspond to the basic management modules of the NVMe protocol (Identify, SMART (device health status monitoring)), because the basic management modules focus on basic device information interaction; the data security characteristics correspond to the security feature modules of the NVMe protocol (Sanitize, TCG Opal), because the security feature modules mainly revolve around data security operations; the protocol extension characteristics correspond to the advanced function modules of the NVMe protocol (SR-IOV, NDU (Non-Disruptive Update)); and the data transmission characteristics correspond to the data integrity modules of the NVMe protocol (End-to-End PI (Protection Information), Compare), which mainly focus on data transmission verification.

[0062] For example, this application can set up a certain test case layer, which can decompose a certain NVMe protocol test requirement into 8 atomic test items: 1. Read device model, 2. Check health status (function related: basic management); 3. Basic read and write, 4. Data verification (function related: data transmission); 5. Secure erase, 6. Encryption verification (function related: security features); 7. Virtualization configuration, 8. Extended function test (function related: advanced functions).

[0063] Then, this test case layer sets up certain basic command modules (corresponding to information interaction characteristics), security feature modules (corresponding to data security characteristics), advanced function modules (corresponding to protocol extension characteristics), and data integrity modules (corresponding to data transmission characteristics) according to functional relevance. These 8 atomic test items can be clustered into 4 functional test items, and each function can be assigned an execution priority (P1 is the highest).

[0064] Functional test item A (basic management, P1): includes atomic items 1 and 2;

[0065] Functional test item B (data transmission, P2): includes atomic items 3 and 4;

[0066] Functional test item C (safety features, P3): includes atomic items 5 and 6;

[0067] Functional test item D (Advanced Functionality, P4): Includes atomic items 7 and 8.

[0068] Finally, various test configurations can be created by combining functional relevance and execution priority, but are not limited to:

[0069] Quickly verify the configuration: Select only the functional test items (A+B) of P1+P2, execute them in priority order (A first, then B), without running the full test;

[0070] Full compliance configuration: Includes all functional test items (A+B+C+D), strictly executed in the order of P1→P2→P3→P4, covering all protocol requirements;

[0071] Security-specific configuration: Select only the functional test items (A+C) of P1 (basic protection) + P3 (core requirements), prioritizing A and then C, focusing on security-related verification.

[0072] This application embodiment can cluster multiple atomic test items into multiple functional test items based on the device information interaction characteristics, data security characteristics, protocol extension characteristics, and data transmission characteristics of the NVMe protocol test. This allows the division of functional test items to accurately match the core functional dimensions of the NVMe protocol, ensuring a one-to-one correspondence between the test structure and the core characteristics of device interaction, data security, protocol extension, and data transmission between the SSD. This not only ensures that no atomic test items under each characteristic are missed, but also guarantees that the test module logic of the NVMe protocol is clear, facilitating the allocation of test tasks according to characteristics and the reuse of test resources across versions.

[0073] Step S103: Retrieve the test environment configuration information corresponding to the actual version from the test environment configuration information, so as to execute multiple functional test items corresponding to the actual version called from the test case set, and generate structured test results for multiple functional test items.

[0074] In other embodiments, after obtaining the test environment configuration information corresponding to multiple versions of solid-state drives and the actual version of the target solid-state drive, this application can call the test environment configuration information corresponding to the actual version of the target solid-state drive from the existing test environment configuration information (environment solidification module), and execute multiple functional test items corresponding to the actual version of the target solid-state drive called from the test case set under the test environment configuration information, thereby generating structured test results of multiple functional test items.

[0075] Here, the target solid-state drive can be understood as the solid-state drive object that is actually used for functional testing.

[0076] For example, there are two versions of SSD: SSD V1 (supports NVMe 1.4, basic functions) and SSDV2 (supports NVMe 2.1, including security / advanced functions).

[0077] The test environment configuration information stores the configurations of SSD V1 and SSD V2. The test environment configuration information for SSD V1 is Ubuntu 20.04, kernel 5.4, and nvme-cli 1.16, while the test environment configuration information for SSD V2 is Ubuntu 22.04, kernel 5.15, and nvme-cli 2.0.

[0078] The test case set includes the "basic management + data transfer" functional test items for SSD V1 and the "basic management + data transfer + security features + advanced functions" functional test items for SSD V2.

[0079] When actually testing the SSD V2, the system can first use tools such as nvme-cli and fio (Flexible I / O tester) to retrieve the corresponding hardware and software configuration for the SSD V2 (Ubuntu 22.04 + kernel 5.15, etc.) from the test environment configuration information to build a dedicated test environment. Then, it retrieves the four functional test items corresponding to the SSD V2 from the test case set. These functional test items and their corresponding test statuses are then returned to the script engine layer in the system. The script engine layer executes these functional test items and generates structured test results. For example, basic management: passed, time taken 2 minutes; security features: passed, time taken 5 minutes; advanced functions: passed, time taken 8 minutes, including the execution status, time taken, and key log links for each functional test item.

[0080] It should be noted that the SSD V1 and SSD V2 in this embodiment are for illustrative purposes only and are not intended to impose specific limitations. In practical applications, those skilled in the art can collect test environment configuration information for numerous SSD versions according to actual needs to build an environment solidification layer, and configure the test environment for all SSD versions in the environment solidification layer for testing.

[0081] Correspondingly, in practical applications, professionals in this field can also collect NVMe protocol test requirements for numerous versions of solid-state drives (SSDs) based on actual needs, and then prepare corresponding test case sets for each version of SSD. Thus, in practical applications, the test case sets can be directly called to perform functional tests on numerous versions of SSDs.

[0082] This application embodiment can ensure that the test environment is compatible during the actual testing process by accurately calling the test environment configuration and functional test items that match the actual SSD version. The test cases fully cover each SSD version, and the final structured test results not only facilitate quick viewing of test results and location of version-specific issues, but also reduce the average testing time from the traditional 2.5 person-days (about 20 hours) required manually to about 110 minutes, improving efficiency by more than 10 times. At the same time, it can also meet the compliance traceability requirements and improve the accuracy and efficiency of multi-version SSD testing.

[0083] Optionally, in one embodiment of this application, after retrieving the test environment configuration information corresponding to the actual version from the test environment configuration information, the method further includes: obtaining the actual environment configuration information of the target solid-state drive; verifying whether the actual environment configuration information matches the test environment configuration information corresponding to the actual version; and executing multiple functional test items corresponding to the actual version in response to the actual environment configuration information matching the test environment configuration information corresponding to the actual version.

[0084] In some embodiments, in addition to requiring that the test environment configuration information corresponding to the specific SSD version can be called when a specific SSD is actually used, this application can also detect whether the actual environment configuration information of the specific SSD meets the requirements of the test environment configuration information corresponding to the specific SSD version, that is, whether the two match.

[0085] Specifically, in this embodiment, the test environment configuration information corresponding to a certain SSD version can be called from the test environment configuration information of multiple versions of SSDs, and then the actual environment configuration information of the SSD can be obtained. By verifying whether the actual environment configuration information of the SSD is consistent with the test environment configuration information of the SSD called, it is determined whether to respond.

[0086] If the actual environment configuration information of the SSD is consistent with the test environment configuration information of the SSD being called (the test environment configuration information corresponding to the actual version of the SSD), the system can respond, that is, respond to the actual environment configuration information of a certain SSD matching the test environment configuration information corresponding to the actual version of the SSD, thereby executing multiple functional test items corresponding to the SSD (multiple functional test items corresponding to the actual version of the SSD).

[0087] This application embodiment can verify the consistency between the actual environment configuration information of the target SSD and the test environment configuration information of the corresponding version of the SSD, thereby avoiding the distortion of test results caused by environment incompatibility. This ensures that the functional test items of the target SSD can be executed in the adapted environment, guaranteeing the accuracy and reliability of multi-version SSD testing, and avoiding invalid test consumption in advance.

[0088] Optionally, in one embodiment of this application, before executing multiple functional test items corresponding to the actual version called from the test case set, the method further includes: generating an initialization strategy, task scheduling strategy, exception handling strategy, and logging strategy for multiple functional test items based on the test requirements of the multiple functional test items; and determining an abstract base class of test modules for executing the multiple functional test items by combining the initialization strategy, task scheduling strategy, exception handling strategy, and logging strategy.

[0089] As one possible approach, this application can unify the standard execution process for all functional test items, facilitating unified management and implementation of multiple functional test items.

[0090] Specifically, embodiments of this application can generate initialization strategies, task scheduling strategies, exception handling strategies, and logging strategies for multiple functional test items based on the test requirements of multiple functional test items, thereby constructing an abstract base class for test modules to execute multiple functional test items based on the initialization strategies, task scheduling strategies, exception handling strategies, and logging strategies.

[0091] The initialization strategy here can be understood as preparing test resources and other resources before testing all functional test items in this application embodiment to ensure the test environment is ready.

[0092] The task scheduling strategy here can be understood as requiring the sequential scheduling of different functional test items when testing all functional test items in this embodiment. Since the test case set in this embodiment already encompasses a certain execution priority, the task scheduling strategy can be, but is not limited to, being set to execute according to the order in the test case set. Specifically, it can be, but is not limited to, set by those skilled in the art according to actual needs; this embodiment is merely illustrative and does not impose specific limitations.

[0093] The exception handling strategy here can be understood as the handling strategy when encountering exceptions in functional test items.

[0094] The logging strategy here can be understood as recording all kinds of information during the testing process when testing functional test items.

[0095] For example, this application can set up a script engine layer. First, it defines an abstract base class TestModule (a general template for test modules) to unify the standard execution flow of all test modules, containing three abstract methods:

[0096] Setup(): Initializes before testing, responsible for preparing module-level resources (such as tool path verification and device initial status confirmation) to ensure the test environment is ready;

[0097] run(): Executes test cases, scheduled according to the test items enabled in config.ini (switches set to 1), and records test results (status, time taken, error information).

[0098] run(): Executes test cases, scheduled according to the test items enabled in config.ini (switches set to 1), and records test results (status, time taken, error information).

[0099] Additionally, certain module organization rules can be added to the script engine layer: each test module (such as the basic management module and the security feature module) corresponds to a separate Python file in the modules folder (used to implement the engineering splitting and management of test modules, such as splitting core functions such as Identify, SMART, and SR-IOV into independent module files). The file name is consistent with the module name (e.g., the basic management module corresponds to basic_manage.py). The file must define a TestClass class (a type of test class) that inherits from TestModule and implement these three abstract methods.

[0100] Furthermore, the dynamic loading and execution logic of the script engine layer can be, but is not limited to, represented as follows:

[0101] (1) The module loading mechanism can use the importlib library (the core library in the Python standard library responsible for dynamically importing modules and managing the life cycle of modules) to dynamically load the corresponding Python file according to the module priority configured in config.ini (such as basic management modules taking precedence over advanced function modules) and instantiate the TestClass class with modules.{module name} as the path. During the loading process, it automatically verifies whether the abstract methods are fully implemented. If they are not implemented, the module loading is terminated and the reason is displayed.

[0102] (2) Linking with other modules: When loading, the config.ini path is passed in so that the module can read the tool path of the environment solidification layer (such as nvme_cli_path) and the switch configuration of the test case layer (such as the test item enable status under [basic_test]); after the run() method is executed, the structured test results (including test item ID, status and time consumption) are output to the script engine layer for subsequent result aggregation and report generation.

[0103] Furthermore, in the embodiments of this application, a certain switch enable configuration can be set for each functional test item in the configuration file config.ini. That is, each functional test item can be set to on or off, with on being 1 and off being 0. When each functional test item is set to 1, the script engine layer will execute the corresponding test item. If it is set to 0, the test item will not be executed.

[0104] This application embodiment can unify the standard execution process of multi-version SSD functional testing by formulating strategies for initialization, scheduling, exception handling, and logging of functional test items and constructing an abstract base class. Thus, by combining dynamic loading, priority scheduling, and switch configuration mechanisms, it can achieve standardized management and flexible on-demand execution of test modules, while improving the automation, maintainability, and problem tracing efficiency of testing by standardizing exception handling and logging.

[0105] Optionally, in one embodiment of this application, executing multiple functional test items corresponding to the actual version called from the test case set, and generating structured test results for the multiple functional test items, includes: executing multiple functional test items corresponding to the actual version called from the test case set corresponding to multiple versions of solid-state drives, obtaining the pass status, execution time, execution command and execution result of the multiple functional test items; and determining the structured test results of the multiple functional test items based on the pass status, execution time, execution command and execution result of the single test step.

[0106] In some embodiments, when this application executes multiple functional test items corresponding to a certain actual SSD version by calling test case sets corresponding to multiple versions of solid-state drives, the structured test results of the multiple functional test items obtained include, but are not limited to, the pass status of multiple functional test items, execution time, execution commands and execution results of a single test step.

[0107] Here, the pass status can be understood as the overall test result of a single functional test item. It can be PASS to indicate pass and FAIL to indicate failure. If all atomic test items included in a functional test item pass the test, the pass status of the functional test item can be recorded as PASS, but is not limited to PASS. If one of them fails the test, the pass status of the basic management functional test item can be recorded as FAIL.

[0108] Execution time here can be understood as the total time from the start of a single functional test item to its complete termination. It can be used to evaluate test efficiency and SSD functional execution performance. For example, if an atomic test item of a certain functional test item includes basic read / write and data verification steps, and the entire process takes 2 minutes and 30 seconds, the execution time would be recorded as 150 seconds (or 2 minutes and 30 seconds).

[0109] The execution command for a single test step can be understood here as the specific operation instruction actually executed by each atomic test item in the functional test item (generally a command to call tools such as nvme-cli, fio, etc.). For example, the execution command for the "read device model" step in a functional test item is nvme id-ctrl / dev / nvme0 -o json, etc.

[0110] The execution result of a single test step here refers to the raw output returned after the execution command of a single test step. For example, after executing `nvme id-ctrl / dev / nvme0 -o json`, if the "mn" field (device model) in the returned JSON data is "SSD-V2-NVMe2.1", which is consistent with the specification, the execution result of this step is recorded as "Device model read result: SSD-V2-NVMe2.1"; if the data read after executing the fio write command does not match the write value, the execution result is recorded as "Write data 0x123, read data 0x456, data inconsistency".

[0111] For example, this application can set up a certain result output layer, which can automatically generate all test results into a structured CSV file (Comma-Separated Values). The core file includes, but is not limited to, the pass / fail status (PASS / FAIL) and execution time of each test item, as well as the specific commands executed in each test step and their original results.

[0112] This application embodiment can record the results of functional test items in a structured way as pass status, execution time, step commands and original results. This not only makes the test results quantifiable and traceable, which is convenient for quickly determining the test effectiveness and accurately locating the cause of failure, but also facilitates the statistical analysis of test efficiency and the review of the test process, meeting the needs of result analysis, compliance audit and problem investigation for multi-version SSD testing.

[0113] Optionally, in one embodiment of this application, executing multiple functional test items corresponding to the actual version called from the test case set, and generating structured test results for the multiple functional test items, includes: obtaining the test order of the multiple functional test items, and executing the multiple functional test items sequentially according to the test order; when a single functional test item in the multiple functional test items fails to execute, capturing the return code and error location result of the test instruction of the single functional test item, so as to generate a new test plan based on the return code of the test instruction and the error location result, and executing the new test plan; in response to the successful execution of the new test plan, executing the multiple functional test items sequentially according to the test order; otherwise, collecting fault diagnosis information of the single functional test item and feeding it back to the user.

[0114] Based on the descriptions of other embodiments, it is understood that when executing functional test items using the script engine layer, this application can set a certain task scheduling strategy so that multiple functional test items can be executed in a certain order. At the same time, this application also sets a certain exception handling strategy to deal with the situation where a certain functional test item fails.

[0115] In some embodiments, this application can schedule multiple functional test items based on the task scheduling strategy in the script engine layer to obtain the test order of the multiple functional test items, and then this application can execute these functional test items sequentially according to the scheduled test order.

[0116] In the process of executing these functional test items, if any functional test item fails or an error occurs, this embodiment of the application can capture the return code and error location result of the test instruction of the functional test item, and then call the corresponding processing strategy from the pre-set fault knowledge base based on these two, regenerate a new test plan, and execute the new test plan again. If the execution of the new test plan is successful, the remaining functional test items are tested in the original test order. If the execution of the new test plan fails, the fault diagnosis information of the functional test item is collected and fed back to the administrator or other upper-level / users.

[0117] Here, the return code refers to a numeric status indicator returned after the test command is executed. Typically, 0 represents successful execution, while non-zero values ​​correspond to different types of failure. For example, if a test command returns a code of 0, the command was executed successfully; if it returns a code of 1, the command parameters were incorrect; and if it returns a code of 2, the tool path configuration was incorrect, or the command was not found.

[0118] Error localization results here refer to the specific error details parsed from the captured return code and standard error output (such as the error message printed when the command is executed), combined with the NVMe protocol specifications and tool documentation. These details include, but are not limited to, the cause of the error, the stage in which it occurred, and the specific location. This allows for the processing and localization of error data, clearly indicating where the error is and why it occurred.

[0119] For example, Table 1 is a partial list of functional test items and their exception triggering examples from one embodiment of this application. Table 1 may, but is not limited to, represent the following:

[0120] Table 1

[0121]

[0122] During the testing of multiple functional test items, an exception in a single functional test item will not affect the overall process; the code will continue to execute the next test case unless a very serious error such as disk loss occurs. Specifically, when a single test item fails, the script engine layer will execute the following process:

[0123] 1) Real-time capture of test command return codes and standard error output;

[0124] 2) Built-in fault knowledge base, automatically matching error patterns with solutions;

[0125] 3) Automatically collect diagnostic information when the test fails:

[0126] PCIe (Peripheral Component Interconnect Express) bus information (which can be output via lspci -vvv, where lspci is the Linux command to query PCI / PCIe bus devices, and -vvv is the highest level of verbose parameter, which can output information such as device model, manufacturer, bus bandwidth, driver binding, etc. Here it is used to obtain the PCIe bus connection details corresponding to the SSD (such as PCIe 4.0 x4 specification, driver version, etc.)).

[0127] The controller register values ​​(which can be read via nvme admin-passthru, i.e. NVMe Admin CommandPassthru, NVMe management command pass-through) are the core subcommands of the NVMe protocol. NVMe is a dedicated tool for the NVMe protocol. Admin-passthru can directly send NVMe management commands to the SSD controller, bypassing the upper-layer driver to directly read the controller's internal register values ​​(such as status registers and function configuration registers) for underlying protocol compliance verification.

[0128] The system kernel logs can be obtained via dmesg|grep nvme(Display message buffer | globalregular expression print (filter NVMe-related logs), which displays the system kernel message buffer and global regular expression matching. Here, dmesg is used to read the message logs of the Linux kernel runtime, and | (pipe) passes the logs to grep nvme, retaining only the logs related to the NVMe device (such as driver loading status, instruction execution exceptions, bus connection logs), which are used to troubleshoot environmental or hardware failures during the testing process.

[0129] The pre-set fault knowledge base contains a built-in mapping relationship of "return code / error log - root cause - solution". Table 2 is an example table of return code / error log - root cause - solution in one embodiment of this application. Table 2 can be, but is not limited to, represented as follows:

[0130] Table 2

[0131]

[0132] This mapping relationship can be defined in a CSV file, which can be set or adjusted by technical professionals in this field according to actual needs, and can be viewed by operations and maintenance personnel or code maintenance personnel.

[0133] This application embodiment can generate a new test plan for retry by capturing return codes and locating errors and calling the fault knowledge base. This achieves automated processing of functional test item failures / anomalies, ensuring the continuity of the test process and accurately collecting fault diagnosis information feedback when retry fails. This reduces the cost of manual intervention and improves test execution efficiency and the accuracy of problem troubleshooting.

[0134] Optionally, in one embodiment of this application, after generating structured test results for multiple functional test items, the method further includes: generating interactive reports for multiple versions of the solid-state drive based on the structured test results; and determining the actual performance of the multiple versions of the solid-state drive based on the interactive reports.

[0135] In some embodiments, this application can generate interactive reports for multiple versions of solid-state drives based on structured test results of multiple functional test items for each version of the SSD, and determine the actual performance of multiple versions of the solid-state drives based on the interactive reports of multiple versions of the solid-state drives.

[0136] Here, structured test results can be understood as standardized and quantifiable test data of functional test items for multiple versions of SSDs. This includes, but is not limited to, the pass status, execution time, execution commands and results of individual test steps of the functional test items in the previous embodiments, as well as PCIe bus information, controller register values, etc., which can be stored in CSV format.

[0137] Interactive reports here can be understood as test reports that support human-computer interaction, generated from the structured results of multiple functional test items based on multiple versions of SSDs. These reports can be non-static documents such as web pages or interactive PDFs, and can perform functions such as filtering, searching, and comparing data. For example, users can filter by version / functional module or click to view the original logs of failed items.

[0138] For example, two versions of SSD were tested:

[0139] SSD V1 (NVMe 1.4): The structured results show "Basic Management: PASS / 120 seconds, Data Transfer: PASS / 150 seconds", with no other functional test items.

[0140] SSD V2 (NVMe 2.1): The structured results show "Basic Management: PASS / 110 seconds, Data Transfer: PASS / 140 seconds, Security Features: PASS / 300 seconds, Advanced Features: FAIL / 280 seconds, Return Code 3, Error Location: Illegal SR-IOV Configuration Command Parameters".

[0141] Based on these structured results, interactive reports for SSD V1 and SSD V2 can be generated: the reports can support switching between tabs for SSD V1 and SSD V2 versions, and can filter for security features. Clicking on the FAIL item in the V2 advanced features can expand to view the original command, return code, and kernel log.

[0142] This interactive report determines the actual performance of the two: SSD V1's basic functions are slightly less efficient but without any anomalies, making it fully suitable for consumer-grade scenarios; SSD V2's basic functions are more efficient and its security features meet the standards, but its advanced functions cannot be implemented normally.

[0143] This application embodiment can generate interactive reports based on structured results and determine the actual performance of multiple SSD versions. This makes the test results intuitive and interactive, facilitating quick comparison of the functional performance of different versions. It can also accurately identify the compliance shortcomings and performance advantages of each version, providing quantitative basis for SSD version optimization and scenario adaptation, and greatly improving the application value of test results.

[0144] The solid-state drive testing method of this application will be described in detail below with a specific embodiment.

[0145] Figure 2 This is a schematic diagram of the architecture for fully automated testing of a solid-state drive based on the NVMe protocol, according to one embodiment of this application. Figure 2 As shown:

[0146] Environment solidification layer: Used to lock the operating system, kernel version, toolchain version and hardware platform configuration required for testing, ensuring the uniqueness and reproducibility of the test environment.

[0147] Test case layer: Based on the NVMe protocol and industry standards, test requirements are broken down into more than 40 atomic test items, and various test configurations are provided according to the clustering combination of 'functional relevance + execution priority'.

[0148] Script engine layer: Implements the core scheduling logic based on a high-level programming language, and is responsible for the automatic scheduling of test tasks, exception handling and log collection.

[0149] Results output layer: Output all test results in a unified machine-readable format (such as CSV) and support HTML (HyperText Markup Language) visualization.

[0150] The flow process of the four layers is as follows:

[0151] (1) Triggering and verification: After the script engine layer starts, it first calls the automatic verification script of the environment solidification layer, and verifies the current environment based on the environment parameters in the read configuration file config.ini. If the verification is successful, the corresponding version of the test case set is loaded from the test case layer. Otherwise, the process is terminated and the reason for the environment difference is output.

[0152] (2) Test case loading and execution: After the environment verification is passed, the script engine reads the list of commands to be executed in the configuration file config.ini, loads the test case set of the corresponding version, and executes them in order.

[0153] (3) Data flow: After each test item is completed, the structured results (including test ID, status, time consumption, command, return code, etc.) are pushed to the script engine in real time, and the engine writes them into the local CSV file.

[0154] (4) Exception handling: If a test fails during execution, the exception handling mechanism is automatically triggered, and diagnostic data such as system status, register information, and kernel logs are collected and matched with the fault knowledge base to output root cause analysis suggestions.

[0155] (5) Report generation: After all tests are completed, the results output layer automatically aggregates the data to generate structured reports and visualization charts, supporting multi-dimensional filtering and analysis.

[0156] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0157] Embodiments of this application also provide a solid-state drive testing device. Figure 3 This is a schematic diagram of the solid-state drive testing apparatus provided according to an embodiment of this application. Figure 3 As shown, the solid-state drive testing device includes: a decomposition module 100, a clustering module 200, and a testing module 300.

[0158] The decomposition module 100 is used to generate test environment configuration information for SSDs based on test environment adaptation benchmarks for multiple versions of SSDs, and decompose the non-volatile memory host controller interface specification test of multiple versions of SSDs into multiple atomic test items; the clustering module 200 is used to cluster multiple atomic test items into multiple functional test items, so as to generate a test case set for SSDs based on multiple functional test items, and identify the actual version of the target SSD; the testing module 300 is used to call the test environment configuration information corresponding to the actual version from the test environment configuration information, so as to execute multiple functional test items corresponding to the actual version called from the test case set, and generate structured test results for multiple functional test items.

[0159] Optionally, in one embodiment of this application, the decomposition module 100 includes: a first acquisition unit, configured to acquire operating system information, kernel version information, toolchain version information, and hardware platform configuration information of multiple versions of solid-state drives; and a construction unit, configured to construct test environment configuration information corresponding to multiple versions of solid-state drives based on the operating system information, kernel version information, toolchain version information, and hardware platform configuration information.

[0160] Optionally, in one embodiment of this application, the clustering module 200 includes: a first determining unit, configured to determine the functional correlation between multiple atomic test items based on the function points of multiple versions of solid-state drives; and a clustering unit, configured to cluster the multiple atomic test items into multiple functional test items based on the functional correlation between the multiple atomic test items.

[0161] Optionally, in one embodiment of this application, the clustering unit includes: a collection subunit, used to collect device information interaction characteristics, data security characteristics, protocol extension characteristics, and data transmission characteristics of the non-volatile memory host controller interface specification test; and a clustering subunit, used to cluster multiple atomic test items into multiple functional test items based on the device information interaction characteristics, data security characteristics, protocol extension characteristics, and data transmission characteristics.

[0162] Optionally, in one embodiment of this application, it further includes: an acquisition module, used to acquire the actual environment configuration information of the target solid-state drive after retrieving the test environment configuration information corresponding to the actual version from the test environment configuration information; a verification module, used to verify whether the actual environment configuration information matches the test environment configuration information corresponding to the actual version; and a response module, used to execute multiple functional test items corresponding to the actual version in response to the actual environment configuration information matching the test environment configuration information corresponding to the actual version.

[0163] Optionally, in one embodiment of this application, it further includes: a first generation module, configured to generate an initialization strategy, task scheduling strategy, exception handling strategy, and logging strategy for multiple functional test items based on the test requirements of the multiple functional test items before executing multiple functional test items corresponding to the actual version called from the test case set; and a first determination module, configured to determine an abstract base class of test modules for executing the multiple functional test items by combining the initialization strategy, task scheduling strategy, exception handling strategy, and logging strategy.

[0164] Optionally, in one embodiment of this application, the test module 300 includes: an execution unit, configured to execute multiple functional test items corresponding to the actual version called from test case sets corresponding to multiple versions of solid-state drives, and obtain the pass status, execution time, execution command and execution result of the multiple functional test items; and a second determination unit, configured to determine the structured test results of the multiple functional test items based on the pass status, execution time, execution command and execution result of the single test step.

[0165] Optionally, in one embodiment of this application, the test module 300 includes: a second acquisition unit, configured to acquire the test order of multiple functional test items and execute the multiple functional test items sequentially according to the test order; a processing unit, configured to capture the return code and error location result of the test instruction of a single functional test item when the execution of a single functional test item among the multiple functional test items fails, so as to generate a new test plan based on the return code of the test instruction and the error location result, and execute the new test plan; and a collection unit, configured to execute the multiple functional test items sequentially according to the test order in response to the successful execution of the new test plan, otherwise, collect the fault diagnosis information of the single functional test item and feed it back to the user.

[0166] Optionally, in one embodiment of this application, it further includes: a second generation module, configured to generate an interactive report of multiple versions of the solid-state drive based on the structured test results of multiple functional test items after generating the structured test results; and a second determination module, configured to determine the actual performance of the multiple versions of the solid-state drive based on the interactive report.

[0167] For a description of the features in the embodiment corresponding to the solid-state drive testing device, please refer to the relevant description in the embodiment corresponding to the solid-state drive testing method, which will not be repeated here.

[0168] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above embodiments of the solid-state drive testing method.

[0169] Embodiments of this application also provide a non-volatile computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described solid-state drive testing method embodiments when running.

[0170] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0171] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the solid-state drive testing method.

[0172] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described solid-state drive testing method embodiments.

[0173] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0174] The present application provides a detailed description of a solid-state drive testing method and apparatus. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A solid state drive testing method, characterized by, The method comprises the following steps: a test environment adaptation benchmark of a plurality of versions of solid state disks is obtained, test environment configuration information of the solid state disks is generated, and non-volatile memory host controller interface specification tests of the plurality of versions of solid state disks are decomposed into a plurality of atomic test items, wherein the test environment adaptation benchmark is a core basis or a standardized criterion for a test environment applicable to the solid state disks, and the atomic test item is a minimum and indivisible test unit generated after the overall test target of the non-volatile memory host controller interface specification protocol is decomposed; the plurality of atomic test items are clustered into a plurality of functional test items, so as to generate a test case set of the solid state disks according to the plurality of functional test items, and an actual version of a target solid state disk is identified, wherein the functional test item is a functional level test unit generated by clustering the atomic test items; test environment configuration information corresponding to the actual version is called from the test environment configuration information, a plurality of functional test items corresponding to the actual version are called from the test case set, and structured test results of the plurality of functional test items are generated; wherein the non-volatile memory host controller interface specification test of the plurality of versions of solid state disks is decomposed into a plurality of atomic test items, comprising: based on each operation detail of each function point in the non-volatile memory host controller interface specification protocol function, decomposing the non-volatile memory host controller interface specification test to obtain the plurality of atomic test items; wherein the plurality of atomic test items are clustered into a plurality of functional test items, comprising: based on the function points of the plurality of versions of solid state disks, determining the functional correlation between the plurality of atomic test items; based on the functional correlation between the plurality of atomic test items, the plurality of atomic test items are clustered into the plurality of functional test items; wherein the plurality of atomic test items are clustered into the plurality of functional test items based on the functional correlation between the plurality of atomic test items, comprising: collecting device information interaction characteristics, data security characteristics, protocol expansion characteristics, and data transmission characteristics of the non-volatile memory host controller interface specification test; based on the device information interaction characteristics, data security characteristics, protocol expansion characteristics, and data transmission characteristics, the plurality of atomic test items are clustered into the plurality of functional test items.

2. The method of claim 1, wherein, The test environment adaptation benchmark of the plurality of versions of solid state disks is obtained, and the test environment configuration information of the solid state disks is generated, comprising: obtaining operating system information, kernel version information, tool chain version information, and hardware platform configuration information of the plurality of versions of solid state disks; based on the operating system information, the kernel version information, the tool chain version information, and the hardware platform configuration information, constructing test environment configuration information corresponding to the plurality of versions of solid state disks.

3. The method of claim 1, wherein, After the test environment configuration information corresponding to the actual version is called from the test environment configuration information, further comprising: obtaining actual environment configuration information of the target solid state disk; checking whether the actual environment configuration information matches the test environment configuration information corresponding to the actual version; in response to the actual environment configuration information matching the test environment configuration information corresponding to the actual version, performing the multiple functional test items corresponding to the actual version.

4. The method of claim 1, wherein, Before performing the multiple functional test items corresponding to the actual version called from the test case set, further comprising: generating an initialization strategy, a task scheduling strategy, an exception handling strategy and a log recording strategy of the multiple functional test items based on test requirements of the multiple functional test items; determining a test module abstract base class for performing the multiple functional test items in combination with the initialization strategy, the task scheduling strategy, the exception handling strategy and the log recording strategy.

5. The method of claim 1, wherein, The performing the multiple functional test items corresponding to the actual version called from the test case set generates a structured test result of the multiple functional test items, comprising: performing the multiple functional test items corresponding to the actual version called from the test case set to obtain a passing state, an execution time consumption, an execution command and an execution result of a single test step of the multiple functional test items; determining the structured test result of the multiple functional test items based on the passing state, the execution time consumption, the execution command and the execution result of the single test step.

6. The method of claim 1, wherein, The performing the multiple functional test items corresponding to the actual version called from the test case set generates a structured test result of the multiple functional test items, comprising: obtaining a test order of the multiple functional test items and sequentially performing the multiple functional test items according to the test order; when a single functional test item in the multiple functional test items executes abnormally, capturing a return code and an error positioning result of a test instruction of the single functional test item to generate a new test scheme according to the return code and the error positioning result of the test instruction and perform the new test scheme; in response to the new test scheme being successfully performed, sequentially performing the multiple functional test items according to the test order, otherwise, collecting fault diagnosis information of the single functional test item and feeding back to a user.

7. The method of claim 1, wherein, After generating the structured test result of the multiple functional test items, further comprising: generating an interactive report of the multiple versions of solid state disks according to the structured test result; determining actual performances of the multiple versions of solid state disks according to the interactive report.

8. An electronic device, comprising: comprising: a memory for storing a computer program; a processor for performing the computer program to realize steps of the solid state disk test method according to any one of claims 1 to 7.

Images