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

Abstract

The invention discloses a memory error injection test method and device, an interface, a storage medium and electronic equipment. The method comprises the following steps: acquiring a basic test case, a hardware error injection test object and a test condition; whether a hardware error injection test needs to be executed or not is judged, if yes, the hardware error injection test object is tested according to test conditions and a basic test case, and a hardware test result is obtained; if not, skipping the hardware error injection test; obtaining software error injection test items and all function test cases corresponding to each software error injection test item; receiving an error injection parameter corresponding to the software error injection test item, and sequentially executing all the function test cases corresponding to the software error injection test item based on the error injection parameter to obtain a software test result; and obtaining a firmware test result according to the hardware test result and the software test result. Based on hardware error injection and software error injection, defects in firmware design can be covered, and firmware algorithm stability and self-recovery capability detection is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of solid state drive firmware algorithm development, and in particular to a memory injection error testing method, interface, device, storage medium and electronic equipment. Background Art

[0002] With the continuous development of solid-state drive storage media and computer technology, the complexity of firmware algorithms has increased, and the reliability requirements for software have also continued to increase. In particular, for solid-state storage algorithms such as EMMC (Embedded Multi Media Card) and SD (Secure Digital) cards that lack hardware real-time debugging methods, it is difficult to ensure that all exception branch processing is executed as expected during the code design phase.

[0003] At present, the firmware algorithm of solid-state memory generally includes basic functions such as garbage collection, power-on recovery and reconstruction, logical read-write erase, address mapping management, etc. A good firmware algorithm can judge various abnormal situations and ensure fault-tolerant recovery as much as possible. Through error injection testing, it can effectively detect whether the firmware's processing mechanism in various abnormal scenarios meets the design expectations, thereby improving the quality of firmware algorithm design.

[0004] However, it is difficult for traditional test cases to cover all code branches of firmware design, and they have certain black box characteristics. At the same time, based on the rapid growth of memory capacity, the test time also increases synchronously based on traditional test methods, resulting in low test efficiency. Summary of the invention

[0005] The technical problem to be solved by the present invention is to provide a memory injection error test method, interface, device, storage medium and electronic equipment to realize the detection of firmware algorithm stability and self-recovery ability and improve the test efficiency.

[0006] In order to solve the above technical problems, the technical solution adopted by the present invention is: A memory injection error testing method, comprising: 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; A firmware test result is obtained according to the hardware test result and the software test result.

[0007] In order to solve the above technical problems, another technical solution adopted by the present invention is: An error injection test interface is applied to each step of the above-mentioned memory error injection test method, including error injection points, error injection response functions, error injection parameter data structures, and error injection parameter transmission functions, and is 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.

[0008] In order to solve the above technical problems, another technical solution adopted by the present invention is: A memory injection error testing device, comprising: 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; The output module outputs the firmware test result according to the hardware test result and the software test result.

[0009] In order to solve the above technical problems, another technical solution adopted by the present invention is: A computer-readable storage medium stores a computer program, which implements the steps of the memory injection error testing method as described above when executed by a processor.

[0010] In order to solve the above technical problems, another technical solution adopted by the present invention is: An electronic device comprises a memory, a processor and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, each step in the memory injection error testing method as described above is implemented.

[0011] The beneficial effects of the present invention are as follows: after selecting the hardware error injection test object and the software error injection test item corresponding to the firmware to be tested, the hardware error injection test object is tested in turn through the test conditions and the basic test cases, and the software error injection test item is tested through the error injection parameters and the functional test cases, based on the hardware error injection and software error injection can cover the defects in the firmware design, realize the stability and self-recovery ability detection of the firmware algorithm, and improve the robustness of the firmware algorithm; at the same time, it is also judged whether the hardware error injection test needs to be performed, so that when the firmware to be tested does not need to perform the hardware error injection test, the hardware error injection test is skipped, thereby improving the test efficiency in the firmware development process. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 A flowchart of a memory injection error testing method according to an embodiment of the present invention; Figure 2 A principle block diagram of a memory injection error testing method according to an embodiment of the present invention; Figure 3 A hardware error injection test flow chart of a memory error injection test method in an embodiment of the present invention; Figure 4 A software error injection test flow chart of a memory error injection test method in an embodiment of the present invention; Figure 5 It is a principle block diagram of the error injection test interface in an embodiment of the present invention; Figure 6 A schematic diagram of the structure of a memory injection error testing device according to an embodiment of the present invention; Figure 7 FIG. 4 is a schematic diagram of the structure of an electronic device in an embodiment of the present invention. DETAILED DESCRIPTION

[0013] In order to explain the technical content, achieved objectives and effects of the present invention in detail, the following is an explanation in conjunction with the implementation modes and the accompanying drawings.

[0014] Please refer to Figure 1 , a memory injection error testing method, comprising: 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; A firmware test result is obtained according to the hardware test result and the software test result.

[0015] From the above description, it can be seen that the beneficial effects of the present invention are: after selecting the hardware error injection test object and the software error injection test item corresponding to the firmware to be tested, the hardware error injection test object is tested in turn through test conditions and basic test cases, and the software error injection test item is tested through error injection parameters and functional test cases. Based on hardware error injection and software error injection, defects in firmware design can be covered, and the stability and self-recovery ability of the firmware algorithm can be detected, thereby improving the robustness of the firmware algorithm. At the same time, it is also judged whether it is necessary to perform the hardware error injection test, so that when the firmware to be tested does not need to perform the hardware error injection test, the hardware error injection test is skipped, thereby improving the testing efficiency in the firmware development process.

[0016] Further, the determining whether it is necessary to perform a hardware error injection test 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.

[0017] From the above description, it can be seen that when different software error injection tests are performed on the same firmware to be tested according to the test requirements, if the current firmware has executed at least one complete hardware simulation error injection test and the firmware has not changed the relevant hardware code, the hardware error injection test step can be skipped to speed up the test; conversely, if there are any changes to the hardware to be tested in the firmware, at least one round of complete hardware error injection testing is required.

[0018] Further, the testing of the hardware error injection test object according to the test conditions and 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.

[0019] From the above description, it can be seen that hardware error injection testing of the firmware to be tested is performed through single automated testing with a single test parameter change and mixed random testing with a random combination of test parameters, which can effectively cover the hardware defects in the firmware design.

[0020] Further, the adjusting the test parameters corresponding to the traversed target hardware error injection test object and executing the basic test case includes: 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 parameter is adjusted to the upper limit value.

[0021] From the above description, it can be seen that 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 the basic test case is completed, and the remaining test parameters are set to the default values ​​to avoid other test parameters from affecting the test results of the target test parameter, so that the test process can cover the different values ​​of the target test parameter that may appear in actual use.

[0022] Furthermore, 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.

[0023] From the above description, it can be seen that after the object to be tested is obtained by random sampling, it is randomly assigned a value, and then combined with the hardware error test object that has not been sampled to form a mixed random test parameter group, that is, a mixed random test parameter group composed of hardware error test objects with different parameter values ​​can be obtained, so by testing multiple different mixed random test parameter groups, the defects in the firmware design can be more effectively covered.

[0024] Further, the receiving of the error injection parameter corresponding to the software error injection test item includes: 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; Traverse each of the functional test cases to determine whether the error point is entered when executing the target functional test case, and if so, execute the error response function.

[0025] From the above description, it can be seen that by setting the error injection test interface and using the error injection test interface to set the error injection point, transmit the error injection parameters, save the error injection parameters and trigger the error injection response function, the test of the software error injection test items can be effectively completed.

[0026] Further, 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.

[0027] From the above description, it can be seen that after all functional test cases of the target software error test item are completed, the control firmware is powered off and restarted once and the error parameter data structure is cleared to avoid the test parameters of the previous software error test item affecting the test results of the current software error test item.

[0028] Another embodiment of the present invention provides an error injection test interface, which is applied to each step of the above-mentioned memory error injection test method, including error injection points, error injection response functions, error injection parameter data structures, and error injection parameter transmission functions, and is 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.

[0029] Furthermore, 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.

[0030] From the above description, it can be seen that based on the error point, the error number and the error address are assigned to the error point parameter. By setting the error number of each error point to be different, different error points can be distinguished, and the error address is set so that the corresponding error response function is triggered when the program runs to the error point at the corresponding position.

[0031] Furthermore, adding an error response function in 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.

[0032] From the above description, we can see that by placing the contents related to the injection error response function in the code segment of the firmware algorithm resident RAM and using macros to surround and isolate it from the original firmware, we can avoid interference between the contents related to the injection error response function and the original firmware, thereby improving program stability. Furthermore, 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.

[0033] From the above description, it can be seen that the error number is set to distinguish different error positions; the error type is set to distinguish different error types, such as event-type errors and position-type errors; the trigger count is set to indicate how many times the error point can be triggered; the restart valid flag is used to determine whether the error point continues to be valid after power failure and restart.

[0034] Furthermore, the error injection parameter transmission function saves the error injection test parameters selected by the user into the error injection parameter data structure.

[0035] It can be seen from the above description that by assigning values ​​to the error injection parameter data structure through the error injection parameter transfer function, the error injection test parameters selected by the user can be effectively saved in the error injection parameter data structure.

[0036] Another embodiment of the present invention provides a memory injection error testing device, comprising: 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; The output module outputs the firmware test result according to the hardware test result and the software test result.

[0037] Another embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the memory injection error testing method described above are implemented.

[0038] Another embodiment of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps in the above-mentioned memory injection error testing method when executing the computer program.

[0039] The memory injection error test method, device, readable storage medium and electronic device provided by the present invention can be applied to the test scenario of solid-state memory firmware algorithm, and are described below through specific implementation methods: Embodiment 1 Please refer to Figure 1 , a memory injection error testing method; please refer to Figure 2 , which 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 constructing an error injection test.

[0040] Among them, the simulation program used by the target firmware should include the main controller simulation program, the storage medium simulation program, and the 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 the data access, address index, and medium status of the storage medium, and the medium status should at least include normal, data error, and medium damage. The communication protocol simulation program should be able to simulate the 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 firmware algorithm to be tested also needs to support simulated power off and power on restart.

[0041] 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 module use cases of the error injection test simulation control program are as follows: (1) The error injection test case configuration module is used to configure the error injection test items. For example, in the hardware error injection process, the error injection test object is set, the relevant range parameters of the test object are set, and the number of mixed random tests is specified. In the software error injection process, the error injection point composition of each test item is specified, the error injection parameters corresponding to the error injection points are set, and the functional test case composition and parameters corresponding to the test item are set.

[0042] (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 errors, this embodiment uses software errors to describe the error injection test items implemented by the error injection test interface.

[0043] (3) The simulation program parameter adjustment module calls the interface or global variables of the main controller simulation program to modify the values ​​of related registers and memory segments to complete the 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 storage medium exception injection.

[0044] (4) The test case execution module executes a series of test items set by the test case configuration module in sequence. When executing hardware error injection, the hardware parameter adjustment is divided into two categories: main control parameter adjustment and medium status adjustment. This is achieved by calling the simulation program parameter adjustment module, and the basic test cases are split into simulation environment interface functions for execution. When executing software error injection, the parameter sending module is used to complete the parameter sending, and the functional test cases are split into simulation environment interface functions for execution.

[0045] (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 result is 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 the firmware log has no output for a certain period of time, it is judged as a timeout exception; when the firmware simulation program judges that the read data and the written data are different when performing a 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 is printed normally, it is judged as success.

[0046] The method performs the following steps: S1. Obtain basic test cases, hardware error injection test objects, and test conditions; that is, when performing error injection testing, you need to complete the following: S11. Configure basic test cases, including parameters such as the number of executions of each logical operation in the basic test cases, and configure the logical operation sequence of the minimum test cases.

[0047] S12. Configure the hardware error injection test case, select the hardware error injection test object, set the expected parameter range or expected possible state of the error injection test object, and specify the number of mixed random test executions.

[0048] S13, configure software error injection test cases and their functional test cases, select the software error injection test items to be tested, configure the error injection point composition and error injection parameters in each error injection test item, and configure the functional test cases paired with each error injection test item. At the same time, the minimum basic test case needs to be executed before executing the hardware error injection test.

[0049] S2. Determine whether it is necessary to perform hardware error injection testing. If so, test the hardware error injection test object according to the test conditions and basic test cases to obtain the hardware test results; if not, skip the hardware error injection testing. Among them, when it is determined that the target test firmware has performed at least one hardware error injection test, and the target test firmware has not changed the hardware code after completing the hardware error injection test, it is not necessary to perform the hardware error injection test. The hardware error injection test includes: S21. Execute single-item automated error injection test of the hardware test object: according to the selected hardware test object, traverse the test object to adjust parameters and execute the minimum basic test case.

[0050] S22. Execute a mixed random error injection test on the hardware test object: generate random test parameters according to the mixed random parameter generation rules and the number of executions and execute the minimum basic test case.

[0051] S3, obtaining software error-notation test items and all functional test cases corresponding to each software error-notation test item, that is, obtaining relevant test content based on step S13.

[0052] S4. Receive the error annotation parameters corresponding to the software error annotation test items, and execute all functional test cases corresponding to the software error annotation test items in sequence based on the error annotation parameters to obtain the software test results; specifically: send the error annotation parameters of the software error annotation test items, and execute the functional test cases corresponding to the test items. If there are multiple software error annotation test items, they are executed in the order configured in step S13.

[0053] Among them, after completing an error injection test case item and its functional test case, if the functional test case is normal, the firmware algorithm is powered off and restarted and the error injection parameter data structure is cleared; then the next set of software error injection tests is switched, and step S4 is repeated until all software error injection test items are tested.

[0054] S5. Obtain the firmware test results according to the hardware test results and the software test results; wherein, when executing all (minimum) basic test cases and functional test cases, the test result reporting module determines the firmware algorithm log output in real time and gives the test results.

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

[0056] Please refer to Figure 3 , the hardware error injection test includes the following steps: 1. Initialize the initial values ​​of the objects to be tested in the simulation environment, and set the status of the main controller registers and storage media to the default values. In this embodiment, the objects to be tested include the voltage registers of the main controller simulated by the firmware algorithm to be tested, the key memory segments of the main controller, and the status of the storage media; among them, the registers and memory segments actively queried by the firmware algorithm should be selected as the test objects for the main controller function, and the parameter attributes of the register objects need to specify the upper limit of the theoretical working value range H. MAX , lower limit H MIN and the default value H0. The parameter attributes of the memory segment object need to specify the initial value. The error annotation of the storage medium function should select the medium state and medium physical address actively controlled and queried by the firmware algorithm as the test object. The parameter attributes of the medium state include at least two categories: available and unavailable. The parameter attributes of the medium physical address need to specify the range of all medium physical addresses operated by the firmware. All test objects and their data are stored 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 status, etc. The specific test objects should be arranged according to the usage of the firmware to be tested. In other optional implementations, the objects that can be used for testing for different firmware algorithms and simulation environments include but are not limited to the above two items, which need to be flexibly adjusted according to the test requirements.

[0057] 2. Execute the basic test case in the simulation environment to ensure that the simulation is initialized normally.

[0058] 3. After the basic test case is completed, determine whether the firmware algorithm output log is normal. If normal, enter the hardware error injection test process.

[0059] 4. Adjust the parameters of the object to be tested; the parameter adjustment stage is divided into single-item automated error injection test and mixed random error injection test. At the same time, the adjustment of the parameters of the object to be tested is implemented based on the above-mentioned simulation program parameter adjustment module.

[0060] Single-item automated injection error test: Single-item automated test traverses all registers selected as test objects in the simulation program, and only modifies the parameters of a single register each time, while the parameters of the other registers remain at the default values. When modifying, the parameters are stepped from the specified lower limit to the specified upper limit in sequence, and objects other than registers are not considered in single-item automated test. The specific test method is as follows: Traverse each hardware error injection test object, adjust the test parameters corresponding to the traversed target hardware error injection test object, 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 error injection test objects to the default value; executing the basic test case with the lower limit value as the initial value of the target test parameter, and adjusting the target test parameter with the parameter step value after completing each basic test case until the target parameter is adjusted to the upper limit value. For example: for the voltage register of the simulated main controller, the theoretical upper limit H within the firmware design range is given MAX and the lower limit H MIN , set the parameter step value range to 1. When testing single-item automated injection errors, each parameter adjustment is from the theoretical lower limit H MIN At the beginning, adjust the parameters and perform a minimum basic test case. If the test passes, continue to adjust the parameters plus 1, and repeat the minimum basic test case until the parameters are adjusted to the upper limit H MAX The test object is considered to have completed a single test. In this example, there is only one register, so the automated test only performs one cycle. If there are multiple registers to be tested, only one register parameter is adjusted each time, and the remaining registers keep the default value H0. After completing a single test of a register, switch to the next register and repeat the above single test until all registers to be tested are traversed.

[0061] Mixed random injection test: By specifying the number of tests Cnt and the sampling ratio, and each parameter adjustment will adjust the parameters of multiple test objects, Cnt groups of test parameters will be generated before the test starts. One group of parameters corresponds to one parameter adjustment. For each group of parameters, all test objects are first sorted, and a part of the test objects are randomly and independently sampled according to the normal distribution as sampling objects according to the sampling ratio, and the remaining unselected objects use the default values. For the sampling objects within a given parameter range, a value within a range is randomly generated using the normal distribution as the test value. For the sampling objects in a given state, all possible states are sorted using the serial number and one of the states is randomly selected using the normal distribution as the test state. After completing the single automated injection test, continue to loop the mixed random injection test. Before the test starts, generate random mixed test parameters, complete the sampling of test objects and assign their random parameters. The specific test method is as follows: Obtain the hybrid random parameter generation rule; process all 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; traverse each hybrid random test parameter group, and execute the minimum basic test case for the traversed target hybrid random test parameter group. In an optional implementation, the sampling number is obtained according to the number of hardware error injection test objects; randomly and non-repeatedly extract the objects to be tested from all hardware error injection test objects until the objects to be tested reach the sampling number; randomly assign values ​​to the test parameters of all objects to be tested, and use default values ​​for the test parameters of the hardware error injection test objects that are not sampled to obtain a hybrid random test parameter group.

[0062] 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 test object sampling value T within the value range to be sampled. The specific calculation relationship between T and t is as follows, where the settlement result of T is rounded down to an integer value, H MAX is the maximum value of the sampling range, H MIN The minimum value of the sampling range is:

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

[0064] If there are Rn items to be tested, and in a mixed random test, it is assumed that a 40% sampling ratio is used and n tests are performed, then n independent samplings are required. Each time, a value Ri is selected as the sampling object in the range of 1 to Rn using the above sampling method, and the number of samples is repeated. If Ri is repeated, it will be re-sampled; each sampled object takes its own T value according to the above random method, and the default value is used for the test objects that are not sampled.

[0065] Among them, in the mixed random test of the storage medium object state, the random error injection address is first determined. Specifically: according to the physical address CE number, Block number, and Page number range specified by the storage medium adapted by the firmware to be tested, a random value T is extracted within the valid numerical range as the physical address value of the injected error according to the above method. The three parameters of CE number, Block number, and Page number need to be sampled independently. After determining the address, the normal, read data ECC abnormal, and block damaged storage medium states are further numbered as 0, 1, and 2. A value is randomly selected from them, and the state corresponding to the value is set to the physical state of the position specified by the above random address.

[0066] After completing Cnt independent samplings, a mixed random test parameter group is obtained. Each time the mixed random test parameters are adjusted, a minimum basic test case is executed to determine whether it passes. If normal, the next set of mixed random test parameters is switched and repeated until all mixed random test parameters of the Cnt group are traversed. If all the minimum basic test cases are normal, the hardware error injection test is judged to have passed. If an abnormality occurs in any of the above basic test cases, including but not limited to firmware algorithm interruption, abnormal unresponsiveness, fatal error log output, etc., the test is judged to have failed and the test process log is saved and the test is exited.

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

[0068] The simulation program of the firmware to be tested should provide the operating environment of the firmware to be tested, including at least main controller simulation, storage medium simulation and support for power-off and restart operations of the simulated firmware algorithm. Specifically, the simulation environment requires that the main controller simulation can at least partially simulate the registers and memory segments that the firmware algorithm can read and write, and the storage medium simulation can at least simulate data access, address indexing, and media 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 error test cases include: 1. Basic test case configuration, including random read, write and erase of 4kB, 8kB, 32kB, 64kB, 128kB, 512kB, 1MB length data, continuous read and write of 4kB, 8kB, 32kB, 64kB, 128kB, 512kB, 1MB length data, full disk erase, full disk read and write, random timed power off and restart, random logical address random length continuous read, write and erase and other test steps. The basic test case includes at least all of the above steps and each step is executed at least once. The minimum basic test case includes all of the above steps and each step is repeated only once. At the same time, this basic test case is also applicable to the above-mentioned embodiment 2.

[0069] Among them, in the simulation environment, the basic test cases are split into simulation environment interface functions for execution in turn. 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 complete the reading of 4kB length data at the starting position of the logical address 100. Similarly, the function Host_Read(200,1024) can be used to read 1MB length data at the starting position of the logical address 200; in the write operation, the function Host_Write(300,4,0x5A) can be used to write 4kB length data with content 0x5A at the starting position of the logical address 300, and the function Host_Erase(100,300) is used in the erase operation to erase the data in the range of logical addresses 100 to 300. The basic test case is composed of a series of functions or variables that can realize the above functions. This embodiment provides a basic test case composition structure: (1) After power failure, power on after a delay of 5 seconds; (2) Erase the entire disk, from logical address 0 to the maximum logical address, erasing all data on the entire disk; (3) Write the entire disk from logical address 0 to the maximum logical address, using a 4kB write length; (4) Read the entire disk from logical address 0 to the maximum logical address, using a 4kB read length; (5) Switch the logical length to 8kB, 32kB, 64kB, 128kB, 512kB, and 1MB in sequence, and repeat steps 2), 3), and 4). Repeat N1 times and end; (6) Erase the entire disk, from logical address 0 to the maximum capacity, erasing all data on the entire disk; (7) Randomly select 30% from logical address 0 to the maximum logical address, and write each logical address with a length of 32kB; (8) Use the logical address selected in step (7) to read 4kB in length; (9) After randomly selecting a length from 4kB, 8kB, 64kB, 128kB, 512kB, and 1MB to replace the length in step (7), repeat steps (6) to (8) and end after repeating N2*6 times; (10) Erase the entire disk, use the logical sector size designed by the firmware to be tested as the read and write length, write data from logical address 0 to the maximum logical address, and then read the data; (11) Randomly select a number from 0 to N3, use the integer as the timing duration, start timing, and start executing steps (2)-(5); (12) When the timing time is up, execute step (1); (13) Repeat steps (11) and (12) N4 times and then end; Among them, in the above steps, N1, N2, N3, and N4 should be integers greater than or equal to 1, and the specific sizes are not limited and can be flexibly arranged according to test requirements.

[0070] 2. Select the error points and configure the error point parameters to form an error test case. According to the functional design of the firmware to be tested, the expected error points can be divided into four types of error points, namely, reconstruction and recovery type, logical read-write and erase type, garbage collection type, and address mapping table item management type. In this embodiment, each type of error point is divided into an error test case, and each error test case can be executed as a separate test. For example, the error points of the reconstruction and recovery type focus on injecting read failure errors when reading system information during the power-on restart phase, the error points of the logical read-write and erase type focus on injecting failure errors at the end of the logical operation process, the error points of the garbage collection type focus on injecting block movement failure errors, and the address mapping table item management type focuses on injecting abnormal address mapping table data and abnormal block status table data. When configuring each error test case, it is necessary to specify the error parameters corresponding to each error point. Usually, the trigger count in the error parameters of each error point is 1 by default, and the restart valid flag bit of the reconstruction and recovery type error point is set to the set state by default; the specific positions and numbers of error points need to be flexibly arranged according to the firmware design scheme.

[0071] When configuring the functional test cases of the above four error injection test cases, the functional test cases supporting the reconstruction and recovery cases are composed of basic test cases and random timed power off and restart cycles. The functional test cases supporting the logical read, write and erase cases are composed of random / continuous logical addresses plus random / fixed-length continuous read, write and erase cycles. The functional test cases supporting the garbage collection cases are composed of continuous writing of the entire disk plus basic test cases. The address mapping table entry management cases are composed of basic test cases for cyclic execution.

[0072] 3. Before starting to execute the error injection test case, start from the first item according to the selected error injection test case, call the error injection parameter transfer function in the simulation environment and send the error injection point error parameters contained in the selected test case to the error injection parameter data structure in sequence for incremental storage.

[0073] 4. Execute the functional test case of the error injection test case: traverse each functional test case to determine whether the error injection point is entered when executing the target functional test case. If so, execute the error injection response function; that is, when the firmware algorithm executes to a certain error injection point in the program, enter the error injection response function execution process to inject errors; if not, determine whether the functional test case is ended.

[0074] 5. After determining that the functional test case has finished testing, the firmware algorithm determines whether there is an abnormality in the log output when executing the functional test case process. If the firmware log is abnormally terminated, the test fails, the test process is interrupted, and the process log is saved. If the test log ends normally, the test is successful and the process log is saved.

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

[0076] Embodiment 4 This embodiment discloses an error injection test interface, wherein the interface can be used as a solid-state hard disk simulation error injection test interface, the interface includes four modules: error injection point, error injection response function, error injection parameter data structure, and error injection parameter transmission function. The interface can be used for the error injection test method in the above-mentioned embodiments one to three. The error injection test method can be implemented in an error injection test device, and the interface can be used in a simulation environment / real environment; and the error injection test interface is adapted in the firmware to be tested, and all error injection test interface programs are isolated from the original code using macros. The interface principle block diagram is shown in FIG. Figure 5 As shown, the interface includes: 1. Add an error annotation parameter data structure to the firmware to be tested. The data structure consists of multiple groups of error annotation parameters. Each group of error annotation parameters includes five items: error annotation number, error annotation address, error type, trigger count, and restart valid flag. For example, the structure array is Sn, including error annotation parameters S0, S1, S2...Sn; error annotation parameter S0 includes five items: error annotation number, error annotation address, etc. Among them, the error annotation number is used to distinguish different error annotation locations; the error annotation address is used to describe the physical address of the error injection location of the object to be tested on the storage medium; the error type includes two types: event type error and position type error, and each type of error includes three types: write error, block erase error, and data read ECC check failure; the trigger count indicates how many times the error annotation point can be triggered, and it can be repeatedly triggered multiple times for a specific error annotation point; the restart valid flag is used to determine whether the error annotation point continues to be valid after power failure and restart. For example, the data structure is implemented using a structure array, where the error address includes the CE number, Block number, and Page number of the error physical address. Each error point number is replaced with a macro to facilitate adjustment of the error test case. The error parameter data structure can be saved to the Flash along with the system information and read out again after power failure and restart. The length and structure of the structure array can be flexibly set according to actual conditions.

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

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

[0079] In this embodiment, the error point parameter can be defined using the following macro: define0x01000001INJECT_EXAME_1 define0x02000002INJECT_EXAME_2 define0x11000003INJECT_EXAME_3 define0x14000003INJECT_EXAME_4 The upper 8 bits in the error point number indicate the error type, for example: 0x12, 1 is the upper four bits, and 2 is the lower four bits. When the upper four bits are 0, it indicates an event-type injection, such as "INJECT_EXAME_1 / INJECT_EXAME_2", when the upper four bits are 1, it indicates a position-type injection, such as "INJECT_EXAME_3 / INJECT_EXAME_4", when the lower four bits are 1, it indicates a read error, such as "INJECT_EXAME_1", when it is 2, it indicates an erase error, such as "INJECT_EXAME_2", when it is 4, it indicates a write error, such as "INJECT_EXAME_4", the lower 24 bits of the error point number indicate the error number, each error point has a unique error number, and the arrangement order of the error numbers is not specifically limited and can be flexibly arranged according to specific circumstances.

[0080] In this embodiment, the event-type error point parameter assignment method can be defined by the following code: userCode … InjectPoint_C.Num = INJECT_EXAME_1 InjectPoint_C.CE = InjectPoint_C.Block = InjectPoint_C.Page= 0xFFFF InjectERR_Function() … userCode Among them, userCode represents the firmware algorithm code context of the injection error point. When performing event-type injection error, only the injection error point number is correctly assigned, such as "INJECT_EXAME_1". At this time, the specific address-related parameters are not concerned and the default initial value is assigned. After the assignment, jump to the injection error response function 'InjectERR_Function()' for the next step of processing; In this embodiment, the positional error point parameter assignment method can be defined by the following code: userCode … InjectPoint_C.Num = INJECT_EXAME_3 InjectPoint_C.CE = FW_GetCE() InjectPoint_C.Block = FW_GetBlock() InjectPoint_C.Page = FW_GetPage() InjectERR_Function() … userCode Among them, userCode represents the firmware algorithm code context of the error point position. When performing positional error annotation, it is necessary to correctly assign the error point parameters and the error address at the same time. For example, the "INJECT_EXAME_3" function "FW_GetCE()", "FW_GetBlock()", and "FW_GetPage()" are functions in the firmware algorithm used to obtain the current CE, Block, and Page. According to the specific firmware, they can be replaced by global variables and other methods with the same effect. After assignment, they jump to the error injection response function "InjectERR_Function()" for the next step of processing. Among them, it is necessary to add the initial value error injection point after loading the error injection parameter data structure in the firmware power-off restart process. This error injection point is the only error injection point that must be added in this embodiment, and the remaining error injection points need to be flexibly added according to test needs.

[0081] 3. Add an error response function to the firmware to be tested. The function and the global variables used by the function should be placed in the code segment of the firmware algorithm resident RAM. The function should be surrounded by macros to isolate it from the original firmware. The error response function includes two functions: error parameter matching and error status setting. When the firmware algorithm executes to the error point, it assigns a value to the error point parameter C, and then jumps to the error response function. The error response function traverses to find whether all the error parameters in the current error parameter data structure Sn are the same as the error number of the error point parameter C. If it is found that the error parameter of Si is the same as C and the number of errors of Si is greater than 0, then the corresponding error status register value in the firmware algorithm is changed to an abnormal value according to the error type of Si, and the error injection is completed. The number of errors of Si is reduced by one.

[0082] 4. Add an error parameter transmission function in the firmware to be tested, which is used to assign values ​​to the error parameter data structure, that is, the error parameter transmission function saves the error test parameters selected by the user into the error parameter data structure to form the above Sn. There are two types of implementation methods for this function: (1) If the error test is performed through a simulation environment, the function is called in the simulation control program to directly complete the assignment. (2) If in the actual solid-state hard disk test scenario, it is necessary to match a special command implementation. Among them, this embodiment provides an implementation method in a simulated error test environment: for example, add an error parameter transmission function in the firmware, the function is placed in the code segment of the firmware algorithm resident RAM, the function interface is set to be callable in the full simulation environment, and when the simulation execution of the error test needs to send the error parameter, the function is directly called to append a new error parameter to the error parameter data structure. In particular, in the actual solid-state hard disk test scenario, the custom communication interaction between the firmware and the host is completed by special commands by default, and its specific implementation method is not limited.

[0083] Embodiment 5 Please refer to Figure 6 , a memory injection error testing device, comprising: 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 it is necessary to perform a hardware error injection test. 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; The second acquisition module is used to acquire the software error test items and all functional test cases corresponding to each software error test item; The second test module receives the error annotation parameters corresponding to the software error annotation test items, and executes all functional test cases corresponding to the software error annotation test items in sequence based on the error annotation parameters to obtain the software test results; The output module outputs the firmware test result according to the hardware test result and the software test result.

[0084] Embodiment 6 A computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the computer program implements the steps of the memory injection error testing method described in Embodiments 1 to 3.

[0085] Embodiment 7 Please refer to Figure 7 An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the processor implements the steps of the memory error injection test method described in Embodiments 1 to 3, as well as an error injection test interface for implementing the error injection test interface described in Embodiment 4.

[0086] Among them, the processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including 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 at least one of other programmable logic devices, discrete gates 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., which can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present application.

[0087] 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 electric erasable programmable read-only memory (EEPROM), etc. The memory is used to store a computer program, and the processor may execute the computer program accordingly after receiving an execution instruction.

[0088] In summary, the present invention provides an error injection test interface adapted to a firmware algorithm, and gives an error injection method implemented using a firmware simulation program. In the method, after selecting a hardware error injection test object and a software error injection test item corresponding to the firmware to be tested, the hardware error injection test object is tested in turn through test conditions and basic test cases, and the software error injection test item is tested through error injection parameters and functional test cases. Based on the fact that hardware error injection and software error injection can cover defects in firmware design, the stability and self-recovery ability of the firmware algorithm can be detected, thereby improving the robustness of the firmware algorithm. At the same time, it is also judged whether it is necessary to perform a hardware error injection test, so that when the firmware to be tested does not need to perform a hardware error injection test, the hardware error injection test is skipped, thereby improving the testing efficiency during the firmware development process.

[0089] In the above embodiments provided in 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 only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as 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 mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or components or modules, which can be electrical, mechanical or other forms.

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

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

[0092] If the integrated module is implemented in the form of a software function 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, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0093] It should be noted that, for the convenience of description, the aforementioned method embodiments are all described as a series of action combinations, but those skilled in the art should be aware 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 be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present invention.

[0094] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0095] The above descriptions are merely embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent transformations made using the contents of the present invention's specification and drawings, or directly or indirectly applied in related technical fields, are also 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; A firmware test result is obtained according to the hardware test result and the software test result.

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 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 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; Traverse each of the functional test cases to determine whether the error point is entered when executing the target functional test case, and if so, execute the error response function.

7. A memory injection error testing method according to claim 6, 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.

8. 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-7, including error injection points, error injection response functions, error injection parameter data structures, and error injection parameter transmission functions, which are 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.

9. The injection error test interface according to claim 8, 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.

10. The injection error test interface according to claim 8, characterized in that: 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.

11. The injection error test interface according to claim 8, 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.

12. The injection error test interface according to claim 8, 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.

13. 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; The output module outputs the firmware test result according to the hardware test result and the software test result.

14. 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 7 is implemented.

15. 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 7 is implemented.

Images