Memory injection error test method, interface, device, storage medium and electronic device

Abstract

The present invention discloses a memory misinjection test method, interface, device, storage medium and electronic device, including: obtaining a basic test case, a hardware misinjection test object and test conditions; determining whether it is necessary to perform a hardware misinjection test, if so, testing the hardware misinjection test object according to the test conditions and the basic test case to obtain a hardware test result; if not, skipping the hardware misinjection test; obtaining software misinjection test items and all function test cases corresponding to each software misinjection test item; receiving misinjection parameters corresponding to the software misinjection test items, and sequentially executing all the function test cases corresponding to the software misinjection test items based on the misinjection parameters to obtain a software test result; obtaining a firmware test result according to the hardware test result and the software test result. Based on hardware misinjection and software misinjection, defects in firmware design can be covered, and the stability and self-recovery ability of the firmware algorithm can be detected.

Description

Technical Field

[0001] The present invention relates to the technical field of solid-state drive firmware algorithm development, and particularly to a method, interface, device, storage medium and electronic device for memory misinjection testing. Background Art

[0002] With the continuous development of solid-state drive storage media and computer technology, the complexity of firmware algorithms has become increasingly high, and thus the requirements for software reliability have also been continuously improved. Especially for solid-state memory algorithms such as EMMC (Embedded Multi Media Card) and SD (Secure Digital) cards that lack hardware real-time debugging means, it is difficult to ensure that all exception branch processing is executed as expected during the code design phase.

[0003] Currently, the firmware algorithms of solid-state memories generally include basic functions such as garbage collection, power-on recovery and reconstruction, logical read / write / erase, and address mapping management. A good firmware algorithm can judge various abnormal situations and ensure as much fault tolerance and recovery as possible. Through misinjection testing, it is possible to effectively detect whether the processing mechanism of the firmware in various abnormal scenarios meets the design expectations, thereby improving the design quality of the firmware algorithm.

[0004] However, traditional test cases are difficult to ensure coverage of all code branches in firmware design and have certain black-box characteristics. At the same time, based on traditional test means, under the condition of rapid growth of memory capacity, the test time also increases synchronously, resulting in low test efficiency. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a method, interface, device, storage medium and electronic device for memory misinjection testing, which can realize the detection of the stability and self-recovery ability of firmware algorithms and improve the test efficiency.

[0006] To solve the above technical problem, the technical solution adopted by the present invention is as follows:

[0007] A method for memory misinjection testing includes:

[0008] Obtaining a basic test case, a hardware misinjection test object, and test conditions;

[0009] Judging whether it is necessary to perform a hardware misinjection test. If so, testing the hardware misinjection test object according to the test conditions and the basic test case to obtain a hardware test result; if not, skipping the hardware misinjection test;

[0010] Obtaining software misinjection test items and all function test cases corresponding to each software misinjection test item;

[0011] Receive error injection parameters corresponding to the software error injection test items, and sequentially execute all the function test cases corresponding to the software error injection test items based on the error injection parameters to obtain software test results;

[0012] Obtain firmware test results based on the hardware test results and the software test results.

[0013] To solve the above technical problems, another technical solution adopted by the present invention is:

[0014] An error injection test interface, which is applied to each step of the above-mentioned memory error injection test method, includes an error injection point, an error injection response function, an error injection parameter data structure, and an error injection parameter transmission function, and is used to add an error injection point, an error injection response function, an error injection parameter data structure, and an error injection parameter transmission function to the firmware to be tested.

[0015] To solve the above technical problems, another technical solution adopted by the present invention is:

[0016] A memory error injection test device, comprising:

[0017] A first acquisition module, configured to acquire basic test cases, hardware error injection test objects, and test conditions;

[0018] A first test module, configured to determine whether it is necessary to perform a hardware error injection test. If so, test the hardware error injection test object according to the test conditions and the basic test cases to obtain hardware test results; if not, skip the hardware error injection test;

[0019] A second acquisition module, configured to acquire software error injection test items and all function test cases corresponding to each software error injection test item;

[0020] A second test module, which receives error injection parameters corresponding to the software error injection test items, and sequentially executes all the function test cases corresponding to the software error injection test items based on the error injection parameters to obtain software test results;

[0021] An output module, which outputs firmware test results according to the hardware test results and the software test results.

[0022] To solve the above technical problems, another technical solution adopted by the present invention is:

[0023] A computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, each step of the above-mentioned memory error injection test method is implemented.

[0024] To solve the above technical problems, another technical solution adopted by the present invention is:

[0025] An electronic device includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, each step in the memory misinjection test method as described above is implemented.

[0026] The beneficial effects of the present invention are as follows: After selecting the hardware misinjection test object and software misinjection test items corresponding to the firmware to be tested, the hardware misinjection test object is tested in sequence through test conditions and basic test cases, and the software misinjection test items are tested through misinjection parameters and function test cases. Based on hardware misinjection and software misinjection, defects in firmware design can be covered, the stability and self-recovery ability of the firmware algorithm can be detected, and the robustness of the firmware algorithm can be improved. At the same time, it is also determined whether it is necessary to perform hardware misinjection testing, so that when the firmware to be tested does not require hardware misinjection testing, the hardware misinjection testing is skipped, improving the testing efficiency in the firmware development process. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 It is a flowchart of the steps of a memory misinjection test method in an embodiment of the present invention;

[0028] Figure 2 It is a principle block diagram of a memory misinjection test method in an embodiment of the present invention;

[0029] Figure 3 It is a hardware misinjection test flowchart of a memory misinjection test method in an embodiment of the present invention;

[0030] Figure 4 It is a software misinjection test flowchart of a memory misinjection test method in an embodiment of the present invention;

[0031] Figure 5 It is a principle block diagram of a misinjection test interface in an embodiment of the present invention;

[0032] Figure 6 It is a structural schematic diagram of a memory misinjection test device in an embodiment of the present invention;

[0033] Figure 7 It is a structural schematic diagram of an electronic device in an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0034] To describe the technical content, achieved objectives, and effects of the present invention in detail, the following is described in conjunction with the embodiments and accompanied by the drawings.

[0035] Please refer to Figure 1 , a memory misinjection test method includes:

[0036] Obtain basic test cases, hardware misinjection test objects, and test conditions;

[0037] Determine whether it is necessary to perform a hardware fault injection test. If so, test the hardware fault injection test object according to the test conditions and basic test cases to obtain a hardware test result; if not, skip the hardware fault injection test;

[0038] Obtain software fault injection test items and all function test cases corresponding to each software fault injection test item;

[0039] Receive fault injection parameters corresponding to the software fault injection test item, and sequentially execute all the function test cases corresponding to the software fault injection test item based on the fault injection parameters to obtain a software test result;

[0040] Obtain a firmware test result according to the hardware test result and the software test result.

[0041] As can be seen from the above description, the beneficial effects of the present invention are as follows: After selecting the hardware fault injection test object and software fault injection test items corresponding to the firmware to be tested, the hardware fault injection test object is tested sequentially through the test conditions and basic test cases, and the software fault injection test items are tested through the fault injection parameters and function test cases. Based on the hardware fault injection and software fault injection, the defects in the firmware design can be covered, the stability and self-recovery ability of the firmware algorithm can be detected, and the robustness of the firmware algorithm can be improved; at the same time, it is also judged whether it is necessary to perform a hardware fault injection test, so that when the firmware to be tested does not need to perform a hardware fault injection test, the hardware fault injection test is skipped, and the test efficiency in the firmware development process is improved.

[0042] Further, the determination of whether it is necessary to perform a hardware fault injection test includes:

[0043] Determine whether the target test firmware has been subjected to the hardware fault injection test at least once, and the hardware code has not been modified after the hardware fault injection test of the target test firmware. If so, it is not necessary to perform the hardware fault injection test.

[0044] As can be seen from the above description, when different software fault injection tests are performed on the same firmware to be tested according to the test requirements, if the current firmware has been subjected to at least one complete hardware simulation fault injection test and the firmware has not modified the relevant hardware code, the hardware fault injection test step can be skipped to speed up the test; on the contrary, if there are any changes to the hardware test object in the firmware, at least one round of complete hardware fault injection test is required.

[0045] Further, the testing of the hardware fault injection test object according to the test conditions and basic test cases includes:

[0046] Traverse each of the hardware error injection test objects, adjust the test parameters corresponding to the target hardware error injection test object traversed, and execute the basic test case;

[0047] Obtain the hybrid random parameter generation rule;

[0048] Process all the hardware error injection test objects according to the hybrid random parameter generation rule to obtain at least one set of hybrid random test parameter groups;

[0049] Traverse each of the hybrid random test parameter groups, and execute the basic test case for the target hybrid random test parameter group traversed.

[0050] As can be seen from the above description, by performing single-item automated testing with a single test parameter change and hybrid random testing with a random combination of test parameter changes on the firmware under test for hardware error injection testing, the hardware defects in the firmware design can be effectively covered.

[0051] Further, the adjusting the test parameters corresponding to the target hardware error injection test object traversed and executing the basic test case includes:

[0052] Obtain the upper limit value, lower limit value, and parameter step value of the target test parameter, and set the test parameters in the remaining hardware error injection test objects to default values;

[0053] Execute the basic test case with the lower limit value as the initial value of the target test parameter, and each time after completing the basic test case, adjust the target test parameter by the parameter step value until the target parameter is adjusted to the upper limit value.

[0054] As can be seen from the above description, after obtaining the upper limit value, lower limit value, and parameter step value of the target test parameter, the target test parameter is adjusted by the parameter step value each time after completing the basic test case, and the remaining test parameters are set to default values, avoiding the influence of other test parameters on the test results of the target test parameter, so that different values that the target test parameter may appear in the actual use process can be covered during the test process.

[0055] Further, the processing all the hardware error injection test objects according to the hybrid random parameter generation rule to obtain at least one set of hybrid random test parameter groups includes:

[0056] Obtain the sampling quantity according to the number of the hardware error injection test objects;

[0057] Randomly and without repetition select the objects to be tested from all the hardware error injection test objects until the number of the objects to be tested reaches the sampling quantity;

[0058] Randomly assign test parameters to all the objects to be tested, and use default values for the test parameters of the hardware misinjection test objects that are not sampled, to obtain the mixed random test parameter group.

[0059] As can be seen from the above description, after obtaining the objects to be tested by random sampling, randomly assign values to the objects to be tested, and then form a mixed random test parameter group with the hardware misinjection test objects that are not sampled. That is, a mixed random test parameter group composed of hardware misinjection test objects with different parameter values can be obtained. Therefore, by testing multiple different mixed random test parameter groups, the defects in the firmware design can be covered more effectively.

[0060] Further, the misinjection parameters corresponding to the software misinjection test items received include:

[0061] Transmit the misinjection parameters through the misinjection test interface, and the misinjection test interface includes a misinjection point, a misinjection response function, a misinjection parameter data structure, and a misinjection parameter transmission function;

[0062] The sequentially executing all the function test cases corresponding to the software misinjection test items based on the misinjection parameters includes:

[0063] Send the misinjection parameters to the misinjection parameter data structure for storage through the misinjection parameter transmission function;

[0064] Traverse each function test case, and determine whether to enter the misinjection point when executing the target function test case. If so, execute the misinjection response function.

[0065] As can be seen from the above description, by setting up the misinjection test interface, and using the misinjection test interface to set the misinjection point, transmit the misinjection parameters, store the misinjection parameters, and trigger the misinjection response function, the test of the software misinjection test items can be effectively completed.

[0066] Further, the sequentially executing all the function test cases corresponding to the software misinjection test items based on the misinjection parameters further includes:

[0067] Judge whether all the function test cases of the target software misinjection test item have completed the test. If so, power off and restart and clear the misinjection parameter data structure, and then switch to the next software misinjection test item for testing.

[0068] As can be seen from the above description, when all the function test cases of the target software misinjection test item have completed the test, control the firmware to power off and restart once and clear the misinjection parameter data structure, so as to avoid the test parameters of the previous software misinjection test item affecting the test results of the current software misinjection test item.

[0069] Another embodiment of the present invention provides a misinjection test interface, which is applied to each step of the above-mentioned memory misinjection test method, including misinjection points, misinjection response functions, misinjection parameter data structures, and misinjection parameter transfer functions, and is used to add misinjection points, misinjection response functions, misinjection parameter data structures, and misinjection parameter transfer functions to the firmware to be tested.

[0070] Further, adding misinjection points to the firmware to be tested includes:

[0071] Placing the misinjection point at a preset position in the function or code segment to be tested, and using a single misinjection point parameter in the firmware algorithm;

[0072] The misinjection point is used for misinjection numbering and obtaining the misinjection address;

[0073] Each misinjection point assigns a misinjection number and a misinjection address to the misinjection point parameter.

[0074] As can be seen from the above description, based on the misinjection point assigning a misinjection number and a misinjection address to the misinjection point parameter, by setting the misinjection numbers of each misinjection point to be different, different misinjection points can be distinguished, and by setting the misinjection address, when the program runs to the misinjection point at the corresponding position, the corresponding misinjection response function is triggered.

[0075] Further, adding misinjection response functions to the firmware to be tested includes:

[0076] The misinjection response function and the global variables used by the function should be placed in the code segment of the firmware algorithm's resident RAM and isolated from the original firmware using a macro;

[0077] The misinjection response function is used to perform misinjection parameter matching and set the error status.

[0078] As can be seen from the above description, by placing the content related to the misinjection response function in the code segment of the firmware algorithm's resident RAM and isolating it from the original firmware using a macro, interference between the content related to the misinjection response function and the original firmware is avoided, improving the program stability.

[0079] Further, the misinjection parameter data structure is composed of multiple groups of misinjection parameters, and each group of misinjection parameters includes a misinjection number, a misinjection address, an error type, a trigger count, and a restart valid flag bit.

[0080] As can be seen from the above description, by setting the misinjection number to distinguish different misinjection positions; setting the error type to distinguish different error types, such as including event-type errors and position-type errors, etc.; setting the trigger count to indicate how many times the misinjection point can be triggered; and the restart valid flag bit is used to determine whether the misinjection point remains valid after a power-off restart.

[0081] Further, the misinjection parameter transfer function saves the misinjection test parameters selected by the user into the misinjection parameter data structure.

[0082] As can be seen from the above description, by assigning values to the misinjection parameter data structure through the misinjection parameter transfer function, the misinjection test parameters selected by the user can be effectively saved into the misinjection parameter data structure.

[0083] Another embodiment of the present invention provides a memory misinjection test device, including:

[0084] A first acquisition module, configured to acquire a basic test case, a hardware misinjection test object, and test conditions;

[0085] A first test module, configured to determine whether a hardware misinjection test needs to be performed. If so, the hardware misinjection test object is tested according to the test conditions and the basic test case to obtain a hardware test result; if not, the hardware misinjection test is skipped;

[0086] A second acquisition module, configured to acquire software misinjection test items and all function test cases corresponding to each software misinjection test item;

[0087] A second test module, which receives misinjection parameters corresponding to the software misinjection test items and sequentially executes all the function test cases corresponding to the software misinjection test items based on the misinjection parameters to obtain a software test result;

[0088] An output module, which outputs a firmware test result according to the hardware test result and the software test result.

[0089] Another embodiment of the present invention provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, each step of the memory misinjection test method as described above is implemented.

[0090] Another embodiment of the present invention provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, each step of the memory misinjection test method as described above is implemented.

[0091] The memory misinjection test method, device, readable storage medium, and electronic device provided by the present invention can be applied to the test scenario of the firmware algorithm of the solid-state memory, which will be described below through specific embodiments:

[0092] Embodiment 1

[0093] Please refer to Figure 1 , a memory misinjection test method; please refer to Figure 2, is the principle block diagram corresponding to the method; the method includes constructing a simulation environment for error injection testing, a firmware to be tested, and a basic simulation environment for the firmware to be tested. The simulation environment includes a target firmware simulation program and a simulation control program for error injection testing.

[0094] Among them, the simulation program used by the target firmware should include a main controller simulation program, a storage medium simulation program, and a communication protocol simulation program. The main controller simulation program should be able to simulate necessary peripheral functions such as hardware registers, main controller memory, and timers. The storage medium simulation program should be able to simulate data access, address indexing, and medium status of the storage medium, and the medium status should include at least three states: normal, data error, and medium damage. The communication protocol simulation program should be able to simulate CMD and ACMD commands defined by standard protocols such as SD cards or EMMC cards and send commands to the main controller simulation program. The simulation program of the algorithm of the firmware to be tested also needs to support simulating power-off and restarting.

[0095] The error injection simulation control program includes an error injection test case configuration module, an error injection parameter sending module, a simulation program parameter adjustment module, a test case execution module, and a test result reporting module. Specifically, the main modules of the error injection test simulation control program are as follows:

[0096] (1) The error injection test case configuration module is used to configure error injection test items. For example, in the hardware error injection process, set the error injection test object, set the relevant range parameters of the test object, and specify the number of mixed random tests. In the software error injection process, specify the error injection points of each test item, set the error injection parameters corresponding to the error injection points, and set the composition and parameters of the function test cases corresponding to the test items.

[0097] (2) The error injection parameter sending module calls the error injection parameter transmission module of the error injection test interface to send the error injection parameters selected by the error injection test case configuration module to the error injection parameter data structure of the error injection test interface for storage. To distinguish hardware error injection, in this embodiment, software error injection is used to describe the error injection test items implemented by the error injection test interface.

[0098] (3) The simulation program parameter adjustment module modifies the values of relevant registers and memory segments by calling the interface or global variables of the main controller simulation program to complete hardware exception parameter injection. Similarly, it calls the program interface or global variables of the storage medium simulation program to modify the data or physical state of the specified physical address to complete the exception injection of the storage medium.

[0099] (4)The test case execution module sequentially executes a series of test items set by the test case configuration module. When performing hardware fault injection, the hardware parameter adjustment is divided into two categories: main control parameter adjustment and medium state adjustment, which is achieved by calling the simulation program parameter adjustment module. The basic test cases are sequentially split into the execution of simulation environment interface functions. When performing software fault injection, the parameter sending is completed through the fault injection parameter sending module, and the functional test cases are sequentially split into the execution of simulation environment interface functions.

[0100] (5)The test result reporting module receives the log output of the firmware algorithm and judges the test result according to the log output result. The results are divided into four categories: timeout exception, data exception, fatal exception, and success. In this embodiment, when it is judged that the test case execution module is working normally and there is no output in the firmware log for a certain period of time, it is judged as a timeout exception. When the firmware simulation program judges that the read data is different from the written data during the read operation, it is judged as a data exception. When the firmware log outputs a fatal error, it is judged as a fatal exception. When all test cases are executed and the log printing is normal, it is judged as a success.

[0101] The method executes the following steps:

[0102] S1. Obtain basic test cases, hardware fault injection test objects, and test conditions; that is, when performing fault injection tests, it is necessary to complete:

[0103] S11. Configure basic test cases, including parameters such as the execution times of each logical operation in the basic test cases, and configure the logical operation order of the minimum test cases.

[0104] S12. Configure hardware fault injection test cases, select hardware fault injection test objects, and set the expected parameter range or expected possible states of the fault injection test objects, and specify the execution times of the mixed random test.

[0105] S13. Configure software fault injection test cases and their functional test cases, select the software fault injection test items to be tested, configure the composition of the fault injection points and the fault injection parameters in each fault injection test item, and configure the functional test cases paired with each fault injection test item. At the same time, it is also necessary to execute the minimum basic test cases before performing the hardware fault injection test.

[0106] S2. Judge whether it is necessary to perform a hardware fault injection test. If so, test the hardware fault injection test object according to the test conditions and the basic test cases to obtain the hardware test result; if not, skip the hardware fault injection test. Among them, when it is judged that the target test firmware has been subjected to at least one hardware fault injection test and the hardware code has not been modified after the target test firmware completes the hardware fault injection test, then there is no need to perform the hardware fault injection test. The hardware fault injection test includes:

[0107] S21. Perform single-item automated error injection testing on the hardware test object: Based on the selected hardware test object, traverse the test object to adjust parameters and execute the minimum basic test cases.

[0108] S22. Perform mixed random error injection testing on the hardware test object: Generate random test parameters according to the mixed random parameter generation rule and the number of executions, and execute the minimum basic test cases.

[0109] S3. Obtain the software error injection test items and all function test cases corresponding to each software error injection test item. That is, obtain the relevant test content based on step S13.

[0110] S4. Receive the error injection parameters corresponding to the software error injection test items, and sequentially execute all function test cases corresponding to the software error injection test items based on the error injection parameters to obtain the software test results; specifically: send the error injection parameters of the software error injection test items and execute the function test cases corresponding to the test items. If there are multiple software error injection test items, execute them according to the order of configuration in step S13.

[0111] Among them, when a set of error injection test cases and their function test cases are completed, if the function test cases are normal, perform a power-off restart on the firmware algorithm and clear the error injection parameter data structure; then switch to the next set of software error injection tests, and repeat step S4 until all software error injection test items are completed.

[0112] S5. Obtain the firmware test results based on the hardware test results and the software test results; among them, when executing all (minimum) basic test cases and function test cases, the test result reporting module judges the output situation of the firmware algorithm log in real time and gives the test results.

[0113] Embodiment 2

[0114] The difference between this embodiment and Embodiment 1 is that the method of hardware error injection testing is specifically defined.

[0115] Please refer to Figure 3 , the hardware error injection testing includes the following steps:

[0116] 1. Initialize the initial value of the object to be tested in the simulation environment, and set the main controller register and the storage medium status to the default values. In this embodiment, it is determined that the object to be tested includes the voltage register of the main controller for simulating the firmware algorithm to be tested, the key memory segment of the main controller, and the status of the storage medium; among them, for error injection of the main controller function, the registers and memory segments actively queried by the firmware algorithm should be selected as the test objects, and the parameter attributes of the register objects need to specify the upper limit H of the theoretical working value range MAX , lower limit H MINWith the default value H0, the parameter attributes of the memory segment object need to specify the initial value. For the misoperation of the storage medium function, the medium state and the physical address of the medium actively controlled and queried by the firmware algorithm should be selected as the test objects. The parameter attributes of the medium state at least include two categories: available and unavailable. The parameter attributes of the physical address of the medium need to specify the range of all physical addresses of the medium for firmware operations. All test objects and their data are saved in the simulation program parameter adjustment module. The test objects include but are not limited to the main control temperature register, the main control power supply voltage detection register, the storage medium drive control register, the storage medium block state, etc. The specific test objects should be arranged according to the usage of the firmware to be tested. In other alternative embodiments, the objects that can be used for testing for different firmware algorithms and simulation environments include but are not limited to the above two, and need to be flexibly adjusted according to the test requirements.

[0117] 2. Execute this basic test case in the simulation environment to ensure normal simulation initialization.

[0118] 3. After the basic test case ends, judge whether the output log of the firmware algorithm is normal. If it is normal, enter the hardware misoperation test process.

[0119] 4. Adjust the parameters of the object to be tested; among them, in the parameter adjustment stage, it is divided into single-item automated misoperation test and mixed random misoperation test. At the same time, adjusting the parameters of the object to be tested is implemented based on the above-mentioned simulation program parameter adjustment module.

[0120] Single-item automated misoperation test: The single-item automated test traverses all registers selected as test objects in the simulation program. Each time, only the parameters of a single register are modified, and the parameters of the remaining registers remain the default values. When modifying, the parameters step from the specified lower limit to the specified upper limit in sequence. In the single-item automated test, objects other than registers are not considered. The specific test method is as follows:

[0121] Traverse each hardware misoperation test object, adjust the test parameters corresponding to the target hardware misoperation test object traversed, and execute the minimum basic test case. The specific adjustment process includes: obtaining the upper limit value, lower limit value, and parameter step value of the target test parameter, and setting the test parameters in the remaining hardware misoperation test objects to the default values; execute the basic test case with the lower limit value as the initial value of the target test parameter, and each time after completing the basic test case, adjust the target test parameter with the parameter step value until the target parameter is adjusted to the upper limit value. For example: for the simulation main controller voltage register, given the theoretical upper limit H MAX and the lower limit H MIN , set the parameter step value range to 1. During the single-item automated misoperation test, each time the parameter is adjusted from the theoretical lower limit H MINStart by performing a minimum basic test case after adjusting the parameters. If the test passes, continue to increase the parameter by 1 and repeat the minimum basic test case until the parameter reaches the upper limit H. MAX This is regarded as the completion of a single test for the test object. In this example, there is only one register, so the automated test only goes through one round of loop. If there are multiple registers to be tested, only the parameters of one register are adjusted each time, and the remaining registers maintain the default value H0. After completing the single test for one register, switch to the next register and repeat the above single test until all registers to be tested are traversed.

[0122] Mixed random fault injection test: By specifying the number of test times Cnt and the sampling ratio, and each parameter adjustment will adjust the parameters of multiple test objects. Before the test starts, Cnt groups of test parameters will be generated. One group of parameters corresponds to one parameter adjustment. For each group of parameters, all test objects are sorted first. According to the sampling ratio, a part of the test objects are randomly and independently sampled according to the normal distribution as the sampling objects, and the remaining unselected objects use the default values. For the sampled objects within the given parameter range, a value within the range is randomly generated using the normal distribution as the test value. For the sampled objects in the given state, all possible states are sorted by serial number and one of them is randomly selected using the normal distribution as the test state. After completing the single automated fault injection test, continue to loop and execute the mixed random fault injection test. Before the test starts, randomly generate mixed test parameters, and complete the sampling of test objects and assign them random parameters. The specific test method is as follows:

[0123] Obtain the generation rule of mixed random parameters; process all hardware fault injection test objects according to the generation rule of mixed random parameters to obtain at least one group of mixed random test parameter groups; traverse each group of mixed random test parameter groups, and execute the minimum basic test case for the target mixed random test parameter group traversed. In an optional implementation manner, obtain the sampling quantity according to the number of hardware fault injection test objects; randomly and non-repeatedly select the objects to be tested from all hardware fault injection test objects until the number of objects to be tested reaches the sampling quantity; randomly assign test parameters to all objects to be tested, and use the default values for the test parameters of the hardware fault injection test objects that are not sampled to obtain the mixed random test parameter groups.

[0124] For example: When generating random parameters, first extract a random floating-point number t that conforms to the normal distribution and has a distribution range between 0 and 1, and then calculate the sampling value T of the test object within the numerical range to be sampled. The specific calculation relationship between T and t is as follows, where the calculation result of T is rounded down to an integer value, H MAX is the maximum value of the sampling range, H MIN is the minimum value of the sampling range:

[0125]

[0126] The above steps for calculating T are valid for any other test object that can specify a range.

[0127] If there are a total of Rn items in the object to be tested, assuming a 40% sampling ratio and performing n tests in the mixed random test, then n independent samplings are required. Each sampling selects a value Ri within the range of 1 to Rn as the sampling object using the above sampling method, and repeat times. If Ri is repeated, re-sample; each sampling object takes its respective T value according to the above random method, and the un-sampled test objects use the default value.

[0128] Among them, for the state of the storage medium object in the mixed random test, first determine the random mis-injection address. Specifically: according to the physical address CE number, Block number, and Page number range defined by the storage medium adapted by the firmware to be tested, extract a random value T within the valid value range as the physical address value for injecting errors using the above method. The three parameters of CE number, Block number, and Page number need to be independently sampled. After determining the address, further set the normal state of the storage medium, read data ECC exception, block damage number as 0, 1, 2, and randomly select a value from them, and set the state corresponding to this value as the physical state at the position specified by the above random address.

[0129] After completing Cnt independent samplings, a mixed random test parameter group is obtained. Each time the mixed random test parameters are adjusted once, a minimum basic test case is executed, and it is judged whether it passes. If it is normal, switch to the next group of mixed random test parameters and repeat until all Cnt groups of mixed random test parameters are traversed. If all the minimum basic test cases are normal, it is judged that the hardware mis-injection test passes. If any abnormality occurs in the above basic test case link, including but not limited to firmware algorithm interruption, abnormal non-response, fatal error log output, etc., it is judged that the test fails, and the test process log is saved and the test is exited.

[0130] Embodiment 3

[0131] The difference between this embodiment and the above embodiment is that the method of software mis-injection test is specifically defined. In the software mis-injection test, a mis-injection test interface is used and the mis-injection test interface is expanded to form a mis-injection test case. In this embodiment, NAND Flash is used as the storage medium and is implemented according to the usage rules of NAND Flash; at the same time, the described storage medium can be replaced with other storage media and implemented according to specific usage rules.

[0132] Among them, the simulation program of the firmware to be tested should provide the operating environment of the firmware to be tested, including at least the main controller simulation, storage medium simulation, and support for power-off and restart operations of the simulated firmware algorithm. Specifically, in the simulation environment, it is required that the main controller simulation can at least partially simulate the registers and memory segments that the firmware algorithm will read and write, and the storage medium simulation can at least simulate data access, address indexing, and medium status. The simulation program of the firmware to be tested needs to meet the above minimum requirements. Please refer to Figure 4 As shown, the software injection error test cases include:

[0133] 1. Basic test case configuration, including random read, write, and erase of data with lengths of 4 kB, 8 kB, 32 kB, 64 kB, 128 kB, 512 kB, and 1 MB, continuous read and write of data with lengths of 4 kB, 8 kB, 32 kB, 64 kB, 128 kB, 512 kB, and 1 MB, full disk erase, full disk read and write, random timed power-off and restart, continuous read, write, and erase of random logical addresses with random lengths, etc. The basic test cases should include at least all of the above steps and each step should be executed at least once. The minimum basic test cases include all of the above steps and each step is repeated only once. At the same time, the basic test cases are also applicable to the second embodiment above.

[0134] Among them, in the simulation environment, the basic test cases are sequentially split into the execution of simulation environment interface functions. Each test step in the above basic test cases is a logical operation and should be able to call the functions or variables provided by the simulation environment to run. For example, in the read operation, the function Host_Read(100, 4) is used to read 4 kB of data starting from the logical address 100. Similarly, to read 1 MB of data starting from the logical address 200, the function Host_Read(200, 1024) can be used; in the write operation, the function Host_Write(300, 4, 0x5A) can be used to write data with a length of 4 kB and a content of 0x5A starting from the logical address 300. In the erase operation, the function Host_Erase(100, 300) is used to erase the data in the range from the logical address 100 to 300. The basic test cases are composed of a series of functions or variables that can achieve the above functions. This embodiment gives a composition structure of the basic test cases:

[0135] (1). After power-off, delay for 5 seconds and then power on and start;

[0136] (2). Erase the entire disk, from the logical address 0 to the maximum logical address, and erase all data on the entire disk;

[0137] (3). Write to the entire disk from the logical address 0 to the maximum logical address, using a 4 kB length for writing;

[0138] (4) Read the entire disk from logical address 0 to the maximum logical address, reading in 4 kB lengths;

[0139] (5) Sequentially switch the logical length to 8 kB, 32 kB, 64 kB, 128 kB, 512 kB, and 1 MB, and then repeat steps (2), (3), and (4). End after repeating N1 times;

[0140] (6) Erase the entire disk, erasing all data on the entire disk from logical address 0 to the maximum capacity;

[0141] (7) Randomly select 30% from logical address 0 to the maximum logical address, and write at each logical address using a 32 kB length;

[0142] (8) Read using a 4 kB length at the logical addresses selected in step (7);

[0143] (9) Randomly select one length from 4 kB, 8 kB, 64 kB, 128 kB, 512 kB, and 1 MB to replace the length in step (7), and then repeat steps (6)-(8). End after repeating N2 * 6 times;

[0144] (10) Erase the entire disk, use the logical sector size designed by the firmware under test as the read / write length, write data from logical address 0 to the maximum logical address, and then read out the data;

[0145] (11) Randomly select a number from 0 to N3, use this integer as the timing duration, start timing, and start executing steps (2)-(5);

[0146] (12) When the timing is up, execute step (1);

[0147] (13) End after repeating steps (11) and (12) N4 times;

[0148] Among them, in the above steps, N1, N2, N3, and N4 should be integers greater than or equal to 1. Their specific sizes are not limited and can be flexibly arranged according to test requirements.

[0149] 2. Select the mis-injection points and configure the parameters of the mis-injection points to form mis-injection test cases. For the function design of the firmware to be tested, the expected mis-injection points can be divided into four categories: reconstruction and recovery, logical read / write / erase, garbage collection, and address mapping table entry management. In this embodiment, each category of mis-injection points is divided into one mis-injection test case, and each mis-injection test case can be executed as an independent test. For example, the mis-injection points of the reconstruction and recovery category inject read failure errors when reading system information during the power-on and restart phases. The mis-injection points of the logical read / write / erase category inject failure errors at the end of the logical operation process. The mis-injection points of the garbage collection category inject block migration failure errors. The address mapping table entry management category focuses on injecting abnormal address mapping table data and abnormal block status table data. When configuring each mis-injection test case, it is necessary to specify the mis-injection parameters corresponding to each mis-injection point. Usually, the default value of the trigger count in the mis-injection parameters of each mis-injection point is 1, and the restart valid flag of the mis-injection points in the reconstruction and recovery category is default set to the enabled state. The specific mis-injection point positions and quantities need to be flexibly arranged according to the firmware design scheme.

[0150] When configuring the functional test cases for the above four mis-injection test cases, the functional test cases supporting the reconstruction and recovery category use two loops of the basic test case and random timed power-off and restart to execute continuously. The functional test cases supporting the logical read / write / erase category use loops of random / continuous logical addresses plus random / fixed-length continuous read / write / erase to execute continuously. The functional test cases supporting the garbage collection category use continuous writing of the entire disk plus the basic test case to execute. The functional test cases supporting the address mapping table entry management category use the basic test case to execute in a loop.

[0151] 3. Before starting to execute the mis-injection test cases, starting from the first item according to the selected mis-injection test cases, call the mis-injection parameter transfer function in the simulation environment for the mis-injection parameters of the mis-injection points included in the selected test cases and send them to the mis-injection parameter data structure in sequence for incremental storage.

[0152] 4. Execute the functional test cases of the mis-injection test cases: Traverse each functional test case, and determine whether it enters the mis-injection point when executing the target functional test case. If so, execute the mis-injection response function; that is, when the firmware algorithm executes to a certain mis-injection point in the program, it enters the mis-injection response function execution process for error injection. If not, determine whether the functional test case ends.

[0153] 5. After determining that the functional test case ends the test, determine whether there is abnormal freezing in the log output during the execution of the functional test case by the firmware algorithm. If the firmware log abnormally terminates, the test fails, interrupt the test process, and save the process log. If the test log ends normally, the test is successful, and save the process log.

[0154] 6. After completing a test case, determine whether there are still mis-injected test items. If so, clear all parameters in the current mis-injected test interface, switch to the next set of mis-injected test cases, and continue to execute in a loop. After all test cases are executed, the test ends, and a test pass log is output.

[0155] Embodiment 4

[0156] This embodiment discloses a mis-injected test interface, which can be used as a mis-injected test interface for solid-state drive emulation. The interface includes four modules: a mis-injection point, a mis-injection response function, a mis-injection parameter data structure, and a mis-injection parameter transfer function. This interface can be used for the mis-injected test methods in the above Embodiments 1 to 3. The mis-injected test method can be implemented in a mis-injected test device, and at the same time, this interface can be used in a simulation environment / real environment; and the mis-injected test interface is adapted in the firmware to be tested, and all mis-injected test interface programs are isolated from the original code using macros. The principle block diagram of the interface is as Figure 5 shown, and this interface includes:

[0157] 1. Add a mis-injection parameter data structure to the firmware to be tested. This data structure is composed of multiple groups of mis-injection parameters. Each group of mis-injection parameters sequentially includes five items: a mis-injection number, a mis-injection address, an error type, a trigger count, and a restart valid flag bit. For example, the structure array is Sn, including mis-injection parameters S0, S1, S2... Sn; the mis-injection parameter S0 includes five items such as a mis-injection number and a mis-injection address. Among them, the mis-injection number is used to distinguish different mis-injection positions; the mis-injection address is used to describe the physical address of the error injection position of the object to be tested on the storage medium; the error type includes two categories: event-type errors and location-type errors, and each category of error includes three types: write error, block erase error, and data read ECC check failure; the trigger count indicates how many times this mis-injection point can be triggered, and a specific mis-injection point can be triggered multiple times; the restart valid flag bit is used to determine whether this mis-injection point remains valid after a power-off restart. For example, this data structure is implemented using a structure array, where the mis-injection address includes the CE number, Block number, and Page number of the mis-injection physical address. Each mis-injection point number is replaced using a macro to facilitate adjusting the mis-injected test cases. The mis-injection parameter data structure can be saved to Flash along with the system information and read out again after a power-off restart. The length and structure of the structure array can be flexibly set according to the actual situation.

[0158] In this embodiment, an implementation method of misinjection parameters is given. A memory variable of a specific length is used to store misinjection parameter data. For example, different bits of a variable are used to represent different functions. Specifically, a 32-bit member variable is used to describe the misinjection number and error type at the same time. The high 8 bits represent the error type, and the low 24 bits represent the misinjection number. A 32-bit member variable is used to describe the trigger count and restart valid flag bit at the same time, that is, the highest bit represents the restart valid flag bit, and the low 31 bits represent the trigger count. A 32-bit member variable is used to describe the misinjection address at the same time. The specific number of bits of the address composition should be set according to the storage medium capacity and addressing method. For example, the NAND Flash physical address includes CE number, Plane number, Block number, Plane number, etc., and the disk should include head number, cylinder number, sector number, etc.

[0159] 2. Add misinjection points to the firmware to be tested; the misinjection points are placed at the beginning of the function or code segment to be tested. A misinjection point parameter C is used separately in the firmware algorithm. Each misinjection point needs to assign two parameters, the misinjection number and the misinjection address, to the misinjection point parameter C; the misinjection point includes two functions: misinjection number assignment and obtaining the target physical address of the current operation of the firmware algorithm. The misinjection number of each misinjection point should be different, and the target address is obtained in real time during the operation of the firmware algorithm. For example, the misinjection address stores the physical address of the storage medium pointed to by the current firmware algorithm. When the code executes to the misinjection point, first assign the misinjection number of the misinjection point parameter C and obtain the real-time physical address of the current firmware algorithm. If the misinjection point is an event-based misinjection, the specific address is not concerned and the address of the misinjection point parameter is assigned a default initial value.

[0160] In this embodiment, the misinjection point parameters can be defined using the following macro:

[0161] define 0x01000001 INJECT_EXAME_1

[0162] define 0x02000002 INJECT_EXAME_2

[0163] define 0x11000003 INJECT_EXAME_3

[0164] define 0x14000003 INJECT_EXAME_4

[0165] The high 8 bits in the injection error point number represent the error type. For example, in 0x12, 1 is the high four bits and 2 is the low four bits. When the high four bits are 0, it represents event - type injection, such as "INJECT_EXAME_1 / INJECT_EXAME_2"; when the high four bits are 1, it represents position - type injection, such as "INJECT_EXAME_3 / INJECT_EXAME_4". When the low four bits are 1, it represents a read error, such as "INJECT_EXAME_1"; when it is 2, it represents an erase error, such as "INJECT_EXAME_2"; when it is 4, it represents a write error, such as "INJECT_EXAME_4". The low 24 bits of the injection error point number represent the injection error number. The injection error number of each injection error point is unique, and the arrangement order of the injection error number is not specifically restricted and can be flexibly arranged according to specific situations.

[0166] In this embodiment, the parameter assignment method for event - type injection error points can be defined by the following code:

[0167] userCode

[0168] ……

[0169] InjectPoint_C.Num = INJECT_EXAME_1

[0170] InjectPoint_C.CE = InjectPoint_C.Block = InjectPoint_C.Page = 0xFFFF

[0171] InjectERR_Function()

[0172] ……

[0173] userCode

[0174] Among them, userCode represents the firmware algorithm code context of the injection error point position. When performing event - type injection error, only the injection error point number needs to be correctly assigned, such as "INJECT_EXAME_1". At this time, the specific address - related parameters are not concerned and are assigned with default initial values. After assignment, it jumps to the injection error response function 'InjectERR_Function()' for the next step of processing;

[0175] In this embodiment, the parameter assignment method for position - type injection error points can be defined by the following code:

[0176] userCode

[0177] ……

[0178] InjectPoint_C.Num = INJECT_EXAME_3

[0179] InjectPoint_C.CE = FW_GetCE()

[0180] InjectPoint_C.Block = FW_GetBlock()

[0181] InjectPoint_C.Page = FW_GetPage()

[0182] InjectERR_Function()

[0183] ……

[0184] userCode

[0185] Among them, userCode represents the firmware algorithm code context at the misinjection point location. When performing location-based misinjection, it is necessary to correctly assign the misinjection point parameters and the misinjection address at the same time. For example, the functions "FW_GetCE()", "FW_GetBlock()", and "FW_GetPage()" in the "INJECT_EXAME_3" function are functions used in the firmware algorithm to obtain the current CE, Block, and Page, and can be replaced by methods with the same effect such as global variables according to the specific firmware. After assignment, it jumps to the misinjection response function "InjectERR_Function()" for further processing. Among them, it is necessary to add a misinjection point for reconstructing the initial value after the misinjection parameter data structure is loaded in the firmware power-off restart process. This misinjection point is the only misinjection point that must be added in this embodiment, and the remaining misinjection points need to be added flexibly according to the test requirements.

[0186] 3. Add a misinjection response function to the firmware to be tested. This function and the global variables used by the function should be placed in the code segment of the firmware algorithm's resident RAM, and the function is surrounded by a macro to isolate it from the original firmware. The misinjection response function includes two functions: misinjection parameter matching and error status setting; when the firmware algorithm executes to the misinjection point location, it assigns a value to the misinjection point parameter C, and then jumps to the misinjection response function. The misinjection response function traverses and checks whether all the misinjection parameters in the current misinjection parameter data structure Sn are the same as the misinjection number of the misinjection point parameter C. If it is found that there is a misinjection parameter of Si that is the same as C and the misinjection count of Si is greater than 0, then change the value of the corresponding error status register in the firmware algorithm to an abnormal value according to the error type of Si to complete the error injection, and the misinjection count of Si is decremented by one.

[0187] 4. Add a mis-injection parameter transfer function to the firmware to be tested, which is used to assign values to the mis-injection parameter data structure. That is, the mis-injection parameter transfer function saves the mis-injection test parameters selected by the user into the mis-injection parameter data structure to form the above-mentioned Sn. There are two implementation methods for this function: (1) If the mis-injection test is carried out through the simulation environment, this function is called in the simulation control program to directly complete the assignment. (2) If it is in the actual solid-state drive test scenario, special commands need to be matched for implementation. Among them, this embodiment gives an implementation method in the simulation mis-injection test environment: for example, add a mis-injection parameter transfer function to the firmware. This function is placed in the code segment of the firmware algorithm resident in RAM, and the function interface is set to be callable in the full simulation environment. When it is necessary to send mis-injection parameters during the simulation execution of the mis-injection test, this function is directly called to append a new mis-injection parameter to the mis-injection parameter data structure. Specifically, in the actual solid-state drive test scenario, the custom communication interaction between the firmware and the host through special commands is defaultly implemented, and its specific implementation method is not limited.

[0188] Embodiment Five

[0189] Please refer to Figure 6 , a memory mis-injection test device, including:

[0190] The first acquisition module is used to acquire basic test cases, hardware mis-injection test objects, and test conditions;

[0191] The first test module is used to judge whether it is necessary to perform a hardware mis-injection test. If so, the hardware mis-injection test object is tested according to the test conditions and the basic test cases to obtain a hardware test result; if not, the hardware mis-injection test is skipped;

[0192] The second acquisition module is used to acquire software mis-injection test items and all function test cases corresponding to each software mis-injection test item;

[0193] The second test module receives the mis-injection parameters corresponding to the software mis-injection test item, and sequentially executes all function test cases corresponding to the software mis-injection test item based on the mis-injection parameters to obtain a software test result;

[0194] The output module outputs the firmware test result according to the hardware test result and the software test result.

[0195] Embodiment Six

[0196] A computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements each step of the memory mis-injection test method described in Embodiments One to Three.

[0197] Embodiment Seven

[0198] Please refer to Figure 7, An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements each step of the memory error injection test method described in Embodiments 1 to 3, and a error injection test interface for implementing the one described in Embodiment 4.

[0199] Among them, the processor can be an integrated circuit chip with signal processing capabilities. The processor can 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 can be a microprocessor or the processor can also be any conventional processor, etc., and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application.

[0200] The memory can 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 the computer program, and after receiving the execution instruction, the processor can execute the computer program accordingly.

[0201] In summary, the present invention provides a misinjection test interface adapted to the firmware algorithm, and presents a misinjection method implemented using a firmware simulation program. In this method, after selecting the hardware misinjection test object corresponding to the firmware under test and the software misinjection test items, the hardware misinjection test object is tested successively through test conditions and basic test cases, and the software misinjection test items are tested through misinjection parameters and function test cases. Based on hardware misinjection and software misinjection, the defects in the firmware design can be covered, the stability and self-recovery ability of the firmware algorithm can be detected, and the robustness of the firmware algorithm can be improved. At the same time, it is also determined whether it is necessary to perform the hardware misinjection test, so that when the firmware under test does not require the hardware misinjection test, the hardware misinjection test is skipped, improving the test efficiency in the firmware development process.

[0202] In the above embodiments provided by the present application, it should be understood that the disclosed methods, devices, computer-readable storage media, and electronic devices can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules is only a logical function division. In actual implementation, there may be other division methods. For example, multiple components or modules can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces. The indirect coupling or communication connection of the device, component, or module may be in an electrical, mechanical, or other form.

[0203] The components described as separate components may or may not be physically separated. The components displayed as components may or may not be physical modules, that is, they may be located in one place, or they may be distributed to multiple network modules. Some or all of the components can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0204] In addition, in each embodiment of the present invention, the functional modules can be integrated in a processing module, or each component can exist physically alone, or two or more modules can be integrated in one module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules.

[0205] When the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. 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.

[0206] It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that the present invention is not limited by the described action sequence, because according to the present invention, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily all essential to the present invention.

[0207] In the above embodiments, the descriptions of the various embodiments have their own focuses. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0208] The above are only the embodiments of the present invention, and do not limit the patent scope of the present invention. Any equivalent transformation made by using the content of the specification and drawings of the present invention, or directly or indirectly applied in the relevant technical fields, shall be equally included in the patent protection scope of the present invention.

Claims

1. A memory injection error testing method, characterized in that: include: Obtain basic test cases, hardware error injection test objects, and test conditions; Determine whether a hardware error injection test needs to be performed. If so, test the hardware error injection test object according to the test conditions and basic test cases to obtain a hardware test result; if not, skip the hardware error injection test; Obtain software error test items and all functional test cases corresponding to each of the software error test items; Receiving an error annotation parameter corresponding to the software error annotation test item, and sequentially executing all the functional test cases corresponding to the software error annotation test item based on the error annotation parameter to obtain a software test result; Obtaining a firmware test result according to the hardware test result and the software test result; The receiving of the error injection parameter corresponding to the software error injection test item comprises: Transmitting the error injection parameter through an error injection test interface, wherein the error injection test interface includes an error injection point, an error injection response function, an error injection parameter data structure, and an error injection parameter transmission function; The sequentially executing all the functional test cases corresponding to the software error injection test items based on the error injection parameters includes: Sending the error injection parameter to the error injection parameter data structure through the error injection parameter transmission function for storage; Traversing each of the functional test cases, determining whether the error point is entered when executing the target functional test case, and if so, executing the error response function; The error injection response function and the global variables used by the function should be placed in the code segment of the firmware algorithm resident RAM and isolated from the original firmware using macro enclosers; the error injection response function is used to perform error injection parameter matching and set the error state.

2. A memory injection error testing method according to claim 1, characterized in that: The determining whether to perform hardware error injection testing includes: Determine whether the target test firmware has executed the hardware error injection test at least once, and the target test firmware has not modified the hardware code after completing the hardware error injection test. If so, there is no need to execute the hardware error injection test.

3. A memory injection error testing method according to claim 1, characterized in that: The testing of the hardware error injection test object according to the test conditions and the basic test cases includes: Traversing each of the hardware error injection test objects, adjusting the test parameters corresponding to the traversed target hardware error injection test object and executing the basic test case; Get the mixed random parameter generation rules; Processing all the hardware error injection test objects according to the mixed random parameter generation rule to obtain at least one group of mixed random test parameter groups; Each of the mixed random test parameter groups is traversed, and the basic test case is executed on the traversed target mixed random test parameter group.

4. A memory injection error testing method according to claim 3, characterized in that: The step of adjusting the test parameters corresponding to the traversed target hardware error injection test object and executing the basic test case comprises: Obtaining the upper limit value, the lower limit value and the parameter step value of the target test parameter, and setting the test parameters in the remaining hardware error injection test objects to default values; The basic test case is executed with the lower limit value as the initial value of the target test parameter, and the target test parameter is adjusted with the parameter step value after each completion of the basic test case until the target test parameter is adjusted to the upper limit value.

5. The memory injection error testing method according to claim 3, characterized in that: The processing of all the hardware error injection test objects according to the hybrid random parameter generation rule to obtain at least one set of hybrid random test parameter groups includes: Obtaining a sampling quantity according to the quantity of the hardware error injection test objects; Randomly and non-repetitively extracting objects to be tested from all the hardware error injection test objects until the number of objects to be tested reaches the sampling number; The test parameters of all the objects to be tested are randomly assigned, and the default values ​​are used for the test parameters of the hardware error injection test objects that are not sampled, to obtain the mixed random test parameter group.

6. A memory injection error testing method according to claim 1, characterized in that: The sequentially executing all the functional test cases corresponding to the software error injection test items based on the error injection parameters also includes: Determine whether all functional test cases of the target software error test item have completed the test. If so, after powering off and restarting and clearing the error parameter data structure, switch the software error test item for testing.

7. An injection error test interface, characterized in that: Applied to each step of the memory error injection test method as described in any one of claims 1 to 6, including error injection points, error injection response functions, error injection parameter data structures, and error injection parameter transmission functions, used to add error injection points, error injection response functions, error injection parameter data structures, and error injection parameter transmission functions in the firmware to be tested; Adding error response functions to the firmware to be tested includes: The error response function and the global variables used by the function should be placed in the code segment of the firmware algorithm resident RAM and isolated from the original firmware using macro enclosers; The error injection response function is used to perform error injection parameter matching and set an error state.

8. The injection error test interface according to claim 7, characterized in that: Adding error annotation points in the firmware to be tested includes: The error point is placed at a preset position of the function or code segment to be tested, and a single error point parameter is used in the firmware algorithm; The error point is used to record the error number and obtain the error address; Each of the error points assigns an error number and an error address to the error point parameters.

9. The injection error test interface according to claim 7, characterized in that: The error annotation parameter data structure is composed of multiple groups of error annotation parameters, and each group of error annotation parameters includes an error annotation number, an error annotation address, an error type, a triggering number, and a restart validity flag.

10. The injection error test interface according to claim 7, characterized in that: The error injection parameter transmission function saves the error injection test parameters selected by the user into the error injection parameter data structure.

11. A memory injection error testing device, characterized in that: include: The first acquisition module is used to acquire basic test cases, hardware error injection test objects and test conditions; The first test module is used to determine whether a hardware error injection test needs to be performed. If so, the hardware error injection test object is tested according to the test conditions and basic test cases to obtain a hardware test result; if not, the hardware error injection test is skipped; A second acquisition module is used to acquire software error-injection test items and all functional test cases corresponding to each of the software error-injection test items; A second testing module receives an error annotation parameter corresponding to the software error annotation test item, and sequentially executes all the functional test cases corresponding to the software error annotation test item based on the error annotation parameter to obtain a software test result; An output module, outputting firmware test results according to the hardware test results and software test results; The receiving of the error injection parameter corresponding to the software error injection test item comprises: Transmitting the error injection parameter through an error injection test interface, wherein the error injection test interface includes an error injection point, an error injection response function, an error injection parameter data structure, and an error injection parameter transmission function; The sequentially executing all the functional test cases corresponding to the software error injection test items based on the error injection parameters includes: Sending the error injection parameter to the error injection parameter data structure through the error injection parameter transmission function for storage; Traversing each of the functional test cases, determining whether the error point is entered when executing the target functional test case, and if so, executing the error response function; The error injection response function and the global variables used by the function should be placed in the code segment of the firmware algorithm resident RAM and isolated from the original firmware using macro enclosers; the error injection response function is used to perform error injection parameter matching and set the error state.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, each step of the memory error testing method according to any one of claims 1 to 6 is implemented.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, each step of the memory injection error testing method as described in any one of claims 1 to 6 is implemented.

Images