A firmware testing method, device, equipment and storage medium

Abstract

The present invention provides a firmware testing method, apparatus, device and storage medium. The method includes: defining expected input parameters and expected output results of each Vendor command according to testing requirements; encapsulating the adapted test commands according to the expected input parameters and the adapted test commands corresponding to the firmware version parameters to obtain encapsulated test commands, where the adapted test commands are localized adaptation commands corresponding to different firmware versions; generating target test commands according to the encapsulated test commands and the expected input parameters; and sending the target test commands to the firmware for testing through a standard protocol testing tool. By defining unified input parameters for Vendor commands and then adapting them to different firmware version parameters, the present invention realizes the inheritance and use of Vendor commands and their corresponding test cases in the testing of different version firmwares, achieving the purpose of improving testing efficiency and reducing the development costs of test cases and test scripts.

Description

Technical Field

[0001] The present invention relates to the technical field of solid state drives, and particularly to a firmware testing method, device, equipment and storage medium. Background Art

[0002] Solid State Drive (SSD) manufacturers will test various functions of the firmware during the R & D stage of SSD firmware. Some of these tests require the use of some Vendor commands. For SSD firmware with different host controller solutions, or even different versions of the same host controller, when implementing Vendor commands for the same requirement, their command parameters and command organizational structures may be very different, resulting in the difficulty of reusing Vendor commands in different firmware versions. It is necessary to develop test interfaces again, which increases the workload of test development, wastes test time and raises costs. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to overcome the deficiencies in the prior art and provide a firmware testing method, device, equipment and storage medium.

[0004] The present invention provides the following technical solutions:

[0005] In a first aspect, the present application provides a firmware testing method, including:

[0006] Defining the expected input parameters and expected output results of each Vendor command according to the test requirements;

[0007] Encapsulating the adaptation test commands according to the expected input parameters and the adaptation test commands corresponding to the firmware version parameters to obtain encapsulated test commands; the adaptation test commands are localized adaptation commands corresponding to different firmware versions;

[0008] Generating target test commands according to the encapsulated test commands and the expected input parameters;

[0009] Sending the target test commands to the firmware for testing through a standard protocol test tool.

[0010] In an implementation, after defining the input parameters and expected output results of each Vendor command according to the test requirements, it includes:

[0011] Generating a first test interface according to the expected input parameters and preset firmware version parameters; the output result of the first test interface is the expected output result corresponding to the preset input parameters and the preset version parameters;

[0012] Using the first test interface to obtain the parameters to be tested;

[0013] Split the parameter to be tested to obtain an input parameter and a firmware version parameter.

[0014] In one implementation, the splitting of the parameter to be tested to obtain an input parameter and a firmware version parameter includes:

[0015] Split the parameter to be tested to obtain an initial input parameter and an initial firmware version parameter;

[0016] Determine whether the initial input parameter is the expected input parameter and whether the initial firmware version parameter is the preset firmware version parameter;

[0017] If the initial input parameter is not the expected input parameter or the initial firmware version parameter is not the preset firmware version parameter, generate an error prompt;

[0018] If the initial input parameter is the expected input parameter and the initial firmware version parameter is the preset firmware version parameter, use the initial input parameter as the input parameter and the initial firmware version parameter as the firmware version parameter.

[0019] In one implementation, the encapsulation of the adaptation test command includes:

[0020] Obtain adaptation parameters corresponding to different firmware versions, bind the adaptation parameters to the test command, and generate the adaptation test command;

[0021] Encapsulate the adaptation test command to obtain a second test interface.

[0022] In one implementation, the generation of the target test command according to the encapsulated test command and the expected input parameter includes:

[0023] Use the second test interface to obtain the expected input parameter and the firmware version parameter;

[0024] According to the firmware version parameter, determine the corresponding target encapsulated test command from the encapsulated test command;

[0025] Generate the target test command according to the input parameter and the target encapsulated test command.

[0026] In one implementation, the generation of the target test command according to the expected input parameter and the target encapsulated test command includes:

[0027] Import the interface function of the standard protocol test tool;

[0028] A target buffer is formed according to the expected input parameters and the target field of the target encapsulation test command according to a preset rule;

[0029] The target test command is generated according to the interface function and the target buffer.

[0030] In one implementation, the step of sending the target test command to the firmware for testing through a standard protocol test tool includes:

[0031] Call an NVMe or SATA protocol test tool to send the target test command to the firmware for testing.

[0032] In a second aspect, the present application provides a firmware testing device, including:

[0033] An acquisition module, configured to define expected input parameters and expected output results of each Vendor command according to test requirements;

[0034] An encapsulation module, configured to encapsulate the adaptation test command according to the expected input parameters and the adaptation test command corresponding to the firmware version parameter to obtain an encapsulated test command; the adaptation test command is a localization adaptation command corresponding to different firmware versions;

[0035] A generation module, configured to generate a target test command according to the encapsulated test command and the expected input parameters;

[0036] A sending module, configured to send the target test command to the firmware for testing through a standard protocol test tool.

[0037] In a third aspect, the present application provides an electronic device, including a memory and at least one processor, the memory stores a computer program, and the processor is configured to execute the computer program to implement the firmware testing method as described in the first aspect.

[0038] In a fourth aspect, the present application provides a computer-readable storage medium, the computer-readable storage medium stores a computer program, and when the computer program is executed, the firmware testing method as described in the first aspect is implemented.

[0039] The embodiments of the present invention have the following beneficial effects:

[0040] The firmware testing method provided by the present invention automatically generates target test commands corresponding to different versions through unified input parameters and firmware version parameters, realizes hierarchical management of the test interface, with a unified standard command input and output interface at the upper layer, and then performs secondary encapsulation of the test command according to the characteristics of different projects at the lower layer, thereby shielding the problem that it is difficult to inherit and reuse the test interface due to differences in different firmware versions, improving the test efficiency and reducing the test cost.

[0041] In order to make the above - mentioned objects, features and advantages of the present invention more obvious and understandable, the following specifically gives preferred embodiments and, in conjunction with the accompanying drawings, detailed descriptions are as follows. Brief Description of the Drawings

[0042] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as limiting the scope. For those of ordinary skill in the art, without creative efforts, other relevant drawings can also be obtained based on these drawings.

[0043] Figure 1 Shows a schematic flow diagram of a firmware testing method;

[0044] Figure 2 Shows a schematic flow diagram of a parameter acquisition method;

[0045] Figure 3 Shows a schematic flow diagram of a second test interface acquisition method;

[0046] Figure 4 Shows a schematic flow diagram of a target test command generation method;

[0047] Figure 5 Shows a schematic framework structure diagram of a firmware testing device.

[0048] Main Element Symbol Explanation:

[0049] 500, firmware testing device; 501, acquisition module; 502, encapsulation module; 503, generation module; 504, distribution module. Detailed Embodiments

[0050] The following details the embodiments of the present invention. The examples of the embodiments are shown in the drawings, where the same or similar reference numerals represent the same or similar elements or elements with the same or similar functions throughout. The embodiments described below by referring to the drawings are exemplary and are only used to explain the present invention and should not be construed as limiting the present invention.

[0051] The terms "first" and "second" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the present invention, "a plurality" means two or more unless otherwise specifically defined.

[0052] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the technical field to which this application belongs. The terms used in the specification of the template herein are for the purpose of describing specific embodiments only and are not intended to limit the present invention. The term "and / or" used herein includes any and all combinations of one or more of the related listed items.

[0053] Embodiment 1

[0054] Refer to Figure 1 , Figure 1 which is a schematic flowchart of a firmware testing method provided for this embodiment. This method can be used for testing different versions of solid-state drives. The method includes:

[0055] S101. Define the expected input parameters and expected output results of each Vendor command according to the test requirements.

[0056] Specifically, the input parameters of Vendor commands for different firmware versions are usually different, which requires users to write different input parameters of Vendor commands according to different firmware versions in order to perform tests and obtain correct output results. To reduce the workload of testing, the unified input parameters and expected command return results can be defined in advance according to the test requirements and the characteristics of Vendor commands, so that when users test different versions of firmware, they can use unified input parameters for testing. This can reduce the complexity of input parameters and the learning difficulty of users, and also reduce the workload of test development.

[0057] The types of Vendor commands are usually divided into three types: query-type Vendor commands, setting-type Vendor commands, and injection-type Vendor commands, which respectively correspond to three different operations when using Vendor commands for SSD firmware function testing.

[0058] Therefore, a set of standard Vendor commands (including query-type, setting-type, and injection-type) can be sorted out in advance according to the test requirements and the characteristics of Vendor commands, and the command input parameters and expected output results of this set of Vendor commands can be fixed, so that this set of commands and output results can be directly inherited and reused in different firmware versions.

[0059] The following is a brief description of these three types of commands:

[0060] (1) Definition of requirements for query-type Vendor commands.

[0061] Query-type Vendor commands are mainly used to query some key information of the SSD disk or obtain some temporary states of the SSD disk. The following are examples to illustrate:

[0062] ① Test requirement description: Query whether the SSD disk is currently performing a GC task.

[0063] Input parameter: None (this command does not require additional input parameters).

[0064] Expected command return result: 0 or 1. 0 indicates that the current GC task (garbage collection) process is not in progress, and 1 indicates that the GC task is currently in progress.

[0065] ② Test requirement description: Specify the ID of a physical block and query its current read count.

[0066] Input parameter: Physical block ID.

[0067] Expected command return result: The read count of this physical block.

[0068] (2) Definition of Vendor command requirements for setting

[0069] Vendor commands for setting are mainly used to set the functions and status of the SSD disk, as follows:

[0070] ① Test requirement description: Specify the ID of a physical block and set its current read count.

[0071] Input parameter: Physical block ID, read count

[0072] Expected command return result: The execution status of this command, success or error code for command execution failure.

[0073] ② Test requirement description: Specify the ID of a physical block and set its current erase count.

[0074] Input parameter: Physical block ID, erase count.

[0075] Expected command return result: The execution status of this command, success or error code for command execution failure.

[0076] (3) Definition of Vendor command requirements for injection

[0077] Vendor commands for injection are mainly used to inject a certain error or abnormal state into the SSD and are used when testing various exception handling processes of the SSD firmware, as follows:

[0078] Test requirement description: Specify the ID of a physical block and inject a UNC (Unrecovered Read Error) error into it.

[0079] Input parameters: Physical block ID, error injection type

[0080] Expected command return result: The execution status of the command, success or the error code for command execution failure.

[0081] ② Test requirement description: Specify the ID of a physical block and inject Program Fail (Nand programming error) into it.

[0082] Input parameters: Physical block ID, error injection type

[0083] Expected command return result: The execution status of the command, success or the error code for command execution failure.

[0084] Since the focus and scope of this application are a test interface framework for a set of Vendor commands and the API interface design method within its framework, and do not include the specific implementation methods of the Vendor commands themselves, the descriptions of all Vendor commands and the specific implementation logics of the Vendor command functions will not be elaborated here in detail.

[0085] Therefore, according to the different keywords and different version information corresponding to different Vendor commands, unified preset input parameters and preset firmware version parameters can be determined. When the user inputs test information, as long as it conforms to the preset input parameters and preset firmware version parameters, the normal test process can be carried out without the need to input different test commands according to different versions.

[0086] See Figure 2 , step S101 includes:

[0087] S1011. Generate a first test interface according to the expected input parameters and preset firmware version parameters; the output result of the first test interface is the expected output result corresponding to the expected input parameters and the preset version parameters.

[0088] Specifically, when the host issues a Vendor command, it only needs to pass in the expected input parameters agreed in the Vendor command requirement definition, and then pass in the drive letter of the SSD disk to be tested and the project number corresponding to the preset firmware version to be tested, and the expected output result can be obtained. Therefore, this first test interface is unified. For different firmware versions, when performing the same test, the input parameters input by the user to the first test interface are the same, only the firmware version parameters are different, and the first test interface will output the same expected output result according to the input parameters and firmware version information according to the pre-set rules.

[0089] For example: When constructing the first test interface, the input parameters can be fixed, and then the disk drive letter (e.g., / dev / sdb) and project number (e.g., project_1) are added. Determine the input parameters of the command according to the defined Vendor command, and then determine how to implement the underlying encapsulation of the Vendor command based on the firmware version to be tested, i.e., the project ID. The biggest feature of this layer of interface is that no matter how different the specific implementation methods of the specified Vendor command are for different firmware versions, it is unified for the upper layer of the command, i.e., the test case script developers.

[0090] Take, for example, setting the current read count of a specified physical block ID in the requirements definition of the set-type Vendor command.

[0091] In the vu_command.py (the first test interface) function, only the input parameters of the Vendor command (physical block ID and the read count to be set) need to be passed in.

[0092] S1012. Use the first test interface to obtain the parameters to be tested.

[0093] The first test interface can play a screening role. After obtaining the parameters to be tested, filter out the parameters that meet the standards from the parameters to be tested for testing. If the parameters to be tested are not the expected parameters, the first test interface will not output the test result or will output an error result.

[0094] S1013. Split the parameters to be tested to obtain the input parameters and the firmware version parameters.

[0095] Use the first test interface to split the input parameters to be tested entered by the user into input parameters and firmware version parameters.

[0096] Since the parameters entered by the user may or may not comply with the regulations, corresponding judgments are required. When inputting, the user usually inputs the parameters to be tested and the firmware version parameters together as input data. The first test interface needs to divide the input data and then determine which part is the parameter to be tested and which part is the firmware version parameter. Therefore, after splitting the parameters to be tested through the first test interface, the obtained parameters can be defined as the initial input parameters and the initial firmware version parameters.

[0097] Then, it is determined whether the initial input parameters are the preset input parameters and whether the initial firmware version parameters are the preset firmware version parameters. Since the input parameters and the firmware version parameters are necessary conditions for testing, the lack or error of any one of them may cause the test to not proceed normally. Therefore, if the initial input parameters are not the preset input parameters or the initial firmware version parameters are not the preset firmware version parameters, an error prompt is generated.

[0098] Only when the initial input parameters are the preset input parameters and the initial firmware version parameters are the preset firmware version parameters, the initial input parameters are used as the input parameters, and the initial firmware version parameters are used as the firmware version parameters. Then, subsequent test operations are performed.

[0099] S102. Package the adaptation test command according to the adaptation test command corresponding to the expected input parameters and firmware version parameters to obtain a packaged test command; the adaptation test command is a localization adaptation command corresponding to different firmware versions.

[0100] See Figure 3 , step S102 includes:

[0101] S1021. Obtain the adaptation parameters corresponding to different firmware versions, bind the adaptation parameters to the test command, and generate the adaptation test command.

[0102] Specifically, as the firmware version changes, the corresponding test command also changes. The traditional method is that a complete test command needs to be input to perform a normal test. After the present application uses a unified test interface to obtain the input parameters, it is also necessary to obtain the corresponding adaptation parameters according to the firmware version, and then bind the adaptation parameters and the test command to generate an adaptation test command, so as to achieve the effect of version isolation. That is, regardless of which test version it is, the input parameters of the same test command are the same, and only different firmware version parameters need to be input to automatically generate a test command matching the version.

[0103] S1022. Package the adaptation test command to obtain a second test interface.

[0104] Specifically, after packaging the adaptation test command, a unified test interface can be obtained. The second test interface only needs to obtain the correct input parameters and firmware version parameters from the first test interface to automatically generate a test command.

[0105] S103. Generate a target test command according to the packaged test command and the expected input parameters.

[0106] See Figure 4 , step S103 includes:

[0107] S1031. Obtain the expected input parameter and the firmware version parameter by using the second test interface.

[0108] Specifically, the input parameter and the firmware version parameter obtained by the second test interface are directly obtained from the first interface. Since the input parameter and the firmware version parameter have been judged at the first interface after splitting, it can be confirmed that both the received input parameter and the firmware version parameter are one of the expected parameters. Therefore, the next operation can be directly performed after obtaining them.

[0109] S1032. Determine the corresponding target encapsulation test command from the encapsulation test commands according to the firmware version parameter.

[0110] Specifically, the encapsulation test command can be a test command template corresponding to different firmware versions, and the corresponding target template can be queried by using the firmware version parameter.

[0111] S1033. Generate the target test command according to the expected input parameter and the target encapsulation test command.

[0112] After querying the corresponding target template, only need to fill the input parameter into the response position in the target template, and then the target encapsulation test command matching the firmware version can be quickly generated.

[0113] Specifically, the generation of the target encapsulation test command can be achieved through project.py (a specific test command encapsulation interface for a certain version) under vu_project (the directory for placing the second-layer test interface). This directory encapsulates the Vendor command interfaces for each firmware version. Whether it is a query-type Vendor command, a setting-type Vendor command, or an injection-type command, according to the parameter requirements and command format requirements within the firmware version, it is converted into a standard protocol command.

[0114] Take the example of setting the read count of a specified physical block in version A:

[0115] First, import the interface function of the standard protocol test tool and initialize the project interface.

[0116] Then, form a target buffer according to the input parameter and the target field of the target encapsulation test command according to a preset rule.

[0117] According to the characteristics of version A, assemble the special field of the firmware vendor command and the Vendor command input parameter together into a buffer of a standard protocol command.

[0118] Then, generate the target test command based on the interface function and the target buffer, and send it to the firmware.

[0119] S104. Use a standard protocol test tool to send the target test command to the firmware for testing.

[0120] Specifically, after obtaining the target test command, directly call the NVMe or SATA protocol test tool to send the target test command to the firmware for testing. For the convenience of calling, the protocol test tool can also be encapsulated as an interface and defined as the third test interface.

[0121] In this embodiment, through three layers of test interfaces, users can input unified input parameters and version parameters through the interfaces to achieve unified testing of different versions of firmware, with high testing efficiency, and there is no need to re-develop new interfaces according to different firmware versions, thus reducing the testing cost.

[0122] Embodiment 2

[0123] See Figure 5 , this application also provides a firmware testing device 500, including:

[0124] An acquisition module 501, configured to define the expected input parameters and expected output results of each Vendor command according to the test requirements;

[0125] An encapsulation module 502, configured to encapsulate the adaptation test command according to the expected input parameters and the adaptation test command corresponding to the firmware version parameter to obtain an encapsulated test command; the adaptation test command is a localized adaptation command corresponding to different firmware versions;

[0126] A generation module 503, configured to generate a target test command according to the encapsulated test command and the expected input parameters;

[0127] A sending module 504, configured to send the target test command to the firmware for testing through a standard protocol test tool.

[0128] It can be understood that the implementation manners in the firmware testing method described in the above Embodiment 1 are equally applicable to this embodiment, so they will not be repeated here.

[0129] Embodiment 3

[0130] The embodiments of the present application further provide a computer device. For example, the computer device may be, but is not limited to, a desktop computer, a notebook, etc. Its form of existence is not limited, mainly depending on whether it needs to support the interface display function of browser web pages, etc. Exemplarily, the computer device includes a memory and at least one processor. The memory stores a computer program, and the processor is configured to execute the computer program to implement the firmware testing method described in Embodiment 1 above.

[0131] Among them, the processor may be an integrated circuit chip with signal processing capabilities. The processor may be a general-purpose processor, including at least one of a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), 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, and discrete hardware components. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc., which can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application.

[0132] Among them, the memory may be, but is not limited to, a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), etc. Among them, the memory is used to store a computer program, and after receiving an execution instruction, the processor can execute the computer program accordingly.

[0133] Furthermore, the memory may include a program storage area and a data storage area. Among them, the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created according to the use of the computer device (such as iterative data, version data, etc.). In addition, the memory may include a high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage devices.

[0134] Embodiment 4

[0135] An embodiment of the present application also provides a computer-readable storage medium storing computer-executable instructions, which, when called and executed by a processor, cause the processor to execute the firmware testing method described in Embodiment 1 above.

[0136] It can be understood that the implementation manners in the firmware testing method described in Embodiment 1 above are equally applicable to this embodiment, and thus will not be described repeatedly herein.

[0137] The computer-readable storage medium may be either a non-volatile storage medium or a volatile storage medium. For example, the computer-readable storage medium may include, but is not limited to, a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc, etc., all of which can store program codes.

[0138] In several embodiments provided by the present application, it should be understood that the disclosed devices and methods may also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions, and operations of devices, methods, and computer program products according to multiple embodiments of the present application. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, and the module, program segment, or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in an alternative implementation, the functions marked in the blocks may occur in a different order than marked in the accompanying drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, may be implemented by a dedicated hardware-based system for performing the specified functions or actions, or may be implemented by a combination of dedicated hardware and computer instructions.

[0139] In addition, in each embodiment of the present application, each functional module or unit may be integrated together to form an independent part, or each module may exist alone, or two or more modules may be integrated to form an independent part.

[0140] When the above-mentioned functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a smart phone, a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs.

[0141] The above is only the specific implementation manner of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in this application, and all of them should be covered by the protection scope of this application.

[0142] In all the examples shown and described here, any specific value should be interpreted as merely exemplary, rather than as a limitation. Therefore, other examples of the exemplary embodiments can have different values.

[0143] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings.

[0144] The above-described embodiments only represent several implementation manners of the present invention. The description is relatively specific and detailed, but it should not be construed as a limitation on the scope of the present invention. It should be pointed out that for those of ordinary skill in the art, without departing from the concept of the present invention, several modifications and improvements can still be made, and all of these belong to the protection scope of the present invention.

Claims

1. A firmware testing method, characterized in that, It includes: Define the same expected input parameters and expected output results corresponding to each Vendor command according to the test requirements of different firmware. Generate a first test interface based on the expected input parameters and preset firmware version parameters. The output result of the first test interface is the expected output result corresponding to the expected input parameters and the preset firmware version parameters. Use the first test interface to obtain the parameter to be tested. Split the parameter to be tested to obtain an input parameter and a firmware version parameter. Encapsulate the adaptation test command according to the adaptation test command corresponding to the expected input parameter and the firmware version parameter to obtain an encapsulated test command. The adaptation test command is a localization adaptation command corresponding to different firmware versions. Generate a target test command according to the encapsulated test command and the expected input parameter. Send the target test command to the firmware for testing through a standard protocol test tool.

2. The firmware testing method according to claim 1, wherein The splitting of the parameter to be tested to obtain an input parameter and a firmware version parameter includes: Split the parameter to be tested to obtain an initial input parameter and an initial firmware version parameter. Judge whether the initial input parameter is the expected input parameter and whether the initial firmware version parameter is the preset firmware version parameter. If the initial input parameter is not the expected input parameter or the initial firmware version parameter is not the preset firmware version parameter, generate an error prompt. If the initial input parameter is the expected input parameter and the initial firmware version parameter is the preset firmware version parameter, use the initial input parameter as the input parameter and the initial firmware version parameter as the firmware version parameter.

3. The firmware testing method according to claim 1, characterized in that The encapsulation of the adaptation test command includes: Obtain the adaptation parameters corresponding to different firmware versions, bind the adaptation parameters to the test command to generate the adaptation test command. Encapsulate the adaptation test command to obtain a second test interface.

4. The firmware testing method according to claim 3, wherein: The generation of the target test command according to the encapsulated test command and the expected input parameter includes: Use the second test interface to obtain the expected input parameter and the firmware version parameter. Determine the corresponding target encapsulated test command from the encapsulated test command according to the firmware version parameter. Generate the target test command according to the expected input parameter and the target encapsulated test command.

5. The firmware testing method according to claim 4, wherein: The generation of the target test command according to the expected input parameter and the target encapsulated test command includes: Import the interface function of the standard protocol test tool. Form a target buffer according to the expected input parameter and the target field of the target encapsulated test command according to a preset rule. Generate the target test command according to the interface function and the target buffer.

6. The firmware testing method according to claim 1, wherein: The sending of the target test command to the firmware for testing through a standard protocol test tool includes: Call the NVMe or SATA protocol test tool to send the target test command to the firmware for testing.

7. A firmware testing device, characterized in that: It includes: A definition module, configured to define the same expected input parameters and expected output results corresponding to each Vendor command according to the test requirements of different firmware; generate a first test interface according to the expected input parameters and preset firmware version parameters; The output result of the first test interface is the expected output result corresponding to the expected input parameters and the preset firmware version parameters; Utilize the first test interface to obtain the parameter to be tested; Split the parameter to be tested to obtain an input parameter and a firmware version parameter; An encapsulation module, configured to encapsulate the adaptation test command corresponding to the expected input parameter and the firmware version parameter to obtain an encapsulated test command; The adaptation test command is a localization adaptation command corresponding to different firmware versions; A generation module, configured to generate a target test command according to the encapsulated test command and the expected input parameter; A sending module, configured to send the target test command to the firmware for testing through a standard protocol test tool.

8. An electronic device, characterized in that, It includes a memory and at least one processor, the memory stores a computer program, and the processor is configured to execute the computer program to implement the firmware test method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed, it implements the firmware test method according to any one of claims 1 to 6.

Images