Fault injection method, test case issuing method and related device

Abstract

This application discloses a fault injection method, a test case distribution method, and related apparatus. The fault injection method includes: acquiring test cases, wherein the test cases instruct a fault simulation device to execute a corresponding fault; executing the test cases to inject a fault into the hardware device under test; receiving an error code, wherein the error code is generated by a fault detection device on the hardware under test based on a test signal generated by the fault; and determining that fault injection is successful when the error code matches a preset result. Using the method of this application, fully automated fault injection is achieved through a fault simulation device. Compared to manual fault debugging in traditional hardware testing, this method offers higher testing efficiency and significantly reduces labor costs.

Description

Technical Field

[0001] This invention relates to the field of fault testing technology, specifically to a fault injection method, a test case distribution method, and related devices. Background Technology

[0002] With the development of computer technology, the reliability requirements of computing systems are becoming increasingly stringent, leading to increasingly demanding testing requirements in hardware reliability testing. Hardware fault injection is an essential test item in hardware reliability testing. The traditional method involves manually soldering wires onto the hardware to simulate and inject hardware faults. The system then makes a judgment based on this, triggering a power alarm, ultimately achieving the desired reliability test result.

[0003] However, traditional testing methods are rather crude, requiring repeated wire bonding, resulting in cumbersome engineering, high labor costs, and low testing efficiency. Furthermore, hardware fault injection test cases are numerous, with a wide variety of hardware types and a large number of corresponding interfaces, leading to a massive testing workload. Traditional manual testing methods can no longer meet the ever-growing demand for hardware reliability testing. Summary of the Invention

[0004] This application provides a fault injection method, a test case distribution method, and related apparatus, which can improve testing efficiency while greatly reducing labor costs.

[0005] The embodiments of the present invention adopt the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a fault injection method, which is applied to a fault simulation device, the fault simulation device being installed on hardware under test, the method comprising:

[0007] Obtain test cases, whereby the test cases are used to instruct the fault simulation device to perform the corresponding fault;

[0008] Execute test cases to inject faults into the hardware device under test;

[0009] Receive error codes, where the error codes are generated by the fault detection device on the hardware under test based on the test signals;

[0010] When the error code matches the preset result, the fault injection is considered successful.

[0011] As can be seen, in this embodiment, the fault simulation device installed on the hardware under test runs the corresponding test cases, thereby injecting faults into the hardware device under test. The fault is then compared with the error codes generated by the fault detection device on the hardware under test based on the test signals, achieving fully automated fault injection and testing. Furthermore, the entire process requires no human intervention. Compared to manual fault debugging in traditional hardware testing, this method offers higher testing efficiency and significantly reduces labor costs.

[0012] In one possible implementation, the method further includes, before executing the test cases:

[0013] Identify the injection fault type corresponding to the test case based on the test case identifier;

[0014] Based on the type of injected fault, determine the first execution module corresponding to the test case in at least one execution module;

[0015] Send the test cases to the first execution module.

[0016] In one possible implementation, the execution module includes:

[0017] High-speed signal fault injection module, low-speed signal fault injection module and power signal fault injection module.

[0018] In one possible implementation, determining the first execution module corresponding to the test case in at least one execution module based on the injected fault type includes:

[0019] Determine the number of tasks in the second execution module, wherein the second execution module is at least one execution module whose fault type is the same as the injected fault type, and the number of tasks is the number of test cases waiting to be executed in the second execution module;

[0020] When the number of tasks exceeds the threshold, the third execution module is determined as the first execution module. The third execution module is any execution module among the remaining execution modules excluding the second execution module that has a number of tasks less than the threshold.

[0021] When the number of tasks is less than the threshold, the second execution module is determined to be the first execution module.

[0022] In one possible implementation, receiving an error code includes:

[0023] Error codes are received from the test terminal. These error codes are reported to the test terminal by the control circuit on the hardware under test and are used to identify the faults detected by the fault detection device.

[0024] In one possible implementation, receiving an error code includes:

[0025] Receive error codes from the hardware under test.

[0026] In one possible implementation, after determining that the fault injection was successful, the method further includes:

[0027] Execute the fault clearing command to inject a clearing signal to the hardware under test to clear the fault;

[0028] Receive the clearing result, wherein the clearing result is generated by the hardware device based on the clearing signal;

[0029] When the cleanup result shows no abnormalities, the fault injection test of the test case ends.

[0030] Secondly, this application provides a test case distribution method, which is applied to a test terminal and is communicatively connected to a fault simulation device. The method includes:

[0031] Receive model information of the hardware under test from the fault simulation device;

[0032] Obtain historical test information corresponding to the model information, whereby the historical test information is used to record the historical test records of the hardware device corresponding to the model information;

[0033] At least one test case is grouped according to the model information to obtain a necessary test case group and an unnecessary test case group, wherein at least one test case is stored in the test terminal;

[0034] Based on historical test information, identify at least one first test case from the non-essential test case group;

[0035] Send at least one first test case and all test cases in the necessary test case group to the fault simulation device.

[0036] As can be seen, in this embodiment, the historical test information corresponding to the model information of the hardware under test is obtained through the model information, and then the test cases that need to be sent to the fault simulation device are automatically determined based on the historical test information in at least one test case. This realizes the automatic screening and sending of test cases, which can improve testing efficiency, ensure the comprehensiveness of test items, and reduce labor costs.

[0037] In one possible implementation, at least one first test case is determined from the non-essential test case group based on historical test information, including:

[0038] Obtain the names of test cases that have been tested twice or more in historical test information, and get at least one first test name;

[0039] Based on at least one first test name, at least one first test case is determined in the non-essential test case group, wherein the at least one first test name includes the name of any one of the at least one first test cases.

[0040] In one possible implementation, the hardware to be tested is a hard drive backplane.

[0041] Thirdly, embodiments of this application provide a fault simulation device, comprising:

[0042] The test case input module is used to obtain test cases, whereby the test cases are used to instruct the fault simulation device to execute the corresponding fault.

[0043] The test case execution module is used to execute test cases to inject faults into the hardware device under test;

[0044] The test case input module is also used to receive error codes, which are generated by the fault detection device on the hardware under test based on the test signals generated by the fault.

[0045] The test case execution module is also used to determine if fault injection was successful when the error code matches the preset result.

[0046] In one possible implementation, the fault simulation device further includes:

[0047] The test case processing module is used to identify the injection fault type corresponding to the test case based on the test case identifier before the test case execution module executes the test case, determine the first execution module corresponding to the test case in at least one execution module in the test case execution module based on the injection fault type, and send the test case to the first execution module.

[0048] In one possible implementation, the execution module includes:

[0049] High-speed signal fault injection module, low-speed signal fault injection module and power signal fault injection module.

[0050] In one possible implementation, the use case input module includes:

[0051] One or more of the following: WiFi module, Universal Serial Bus module, Serial port module, and Ethernet module.

[0052] In one possible implementation, the use case processing module further includes:

[0053] The power supply module is used to provide electrical energy to the fault simulation device;

[0054] The firmware chip stores software version information and initializes the test case processing module when the fault simulation device starts.

[0055] In one possible implementation, the use case processing module includes a microcontroller processor.

[0056] Fourthly, embodiments of this application provide a computing device, including: a fault simulation device, a test terminal, hardware under test, a processor, and a memory. The fault simulation device is communicatively connected to the test terminal and the processor. The fault simulation device is installed on the hardware under test. The processor is coupled to the memory. The memory is used to store computer program instructions. When the computer program instructions are executed by the processor, the computing device performs the methods of the first aspect and / or the second aspect.

[0057] As can be seen, the third and fourth aspects are the apparatus and equipment corresponding to the methods of the first and / or second aspects. The descriptions of each step in the third and fourth aspects, the explanations of terms, the various implementation methods and the descriptions of beneficial effects are also applicable to the foregoing discussions. Please refer to the relevant content in the first and / or second aspects, which will not be repeated here.

[0058] Fifthly, embodiments of this application provide a computer-readable storage medium storing program code for execution by a device, which causes a computer to perform the methods of the first and / or second aspects. Regarding the descriptions of the steps involved in the fifth aspect, the explanations of terms, various implementation methods, and descriptions of beneficial effects, the foregoing discussions also apply, and can be found in the relevant foregoing content; they will not be repeated here.

[0059] Sixthly, embodiments of this application provide a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, operable by a computer to perform any possible implementation of the methods of the first and / or second aspects. Regarding the descriptions of the steps involved in the sixth aspect, the explanations of terms, the various implementations, and the descriptions of beneficial effects, the foregoing discussions also apply, and can be found in the relevant foregoing content, which will not be repeated here. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention.

[0061] Figure 1 A system architecture diagram of a computing device to which a fault simulation testing method is applicable, provided for an embodiment of the present invention;

[0062] Figure 2 A schematic diagram of the structure of a fault simulation device provided for an embodiment of the present invention;

[0063] Figure 3 This is a flowchart illustrating a fault injection method provided for an embodiment of the present invention. Detailed Implementation

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

[0065] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0066] In this document, the term "implementation" means that a specific feature, result, or characteristic described in connection with an implementation may be included in at least one implementation of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same implementation, nor is it a separate or alternative implementation mutually exclusive with other implementations. It will be explicitly and implicitly understood by those skilled in the art that the implementations described herein can be combined with other implementations.

[0067] First, refer to Figure 1 , Figure 1 The system architecture diagram of a computing device applicable to a fault simulation test method provided in this application embodiment is shown. The computing device may include a fault simulation device 110, a test terminal 120, hardware under test 130, a processor 140, and a memory 150.

[0068] Specifically, such as Figure 2As shown, the fault simulation device 110 may include a test case input module 210, a test case execution module 220, and a test case processing module 230. The test case input module 210 is used to establish a communication connection with the test terminal 120 and the hardware under test 130. For example, the test case input module 210 may include one or more of the following: a WiFi module 211, a Universal Serial Bus (USB) module 212, a serial port module 213, and a network port module 214, thereby establishing wired and / or wireless communication connections with the test terminal 120 and the hardware under test 130 through these modules.

[0069] In this embodiment, the test case execution module 220 is used to execute test cases to inject faults into the hardware under test 130. Specifically, the fault simulation device 110 can be installed on the hardware under test 130, and its installation method varies depending on the hardware under test 130. For example, when the hardware under test 130 is a hard disk backplane, the fault simulation device 110 can be inserted into the hard disk backplane slot through a device such as a hard disk interface adapter card to realize the installation between the fault simulation device 110 and the hardware under test 130.

[0070] In this embodiment, the test case execution module 220 may include: a high-speed signal fault injection module 221, a low-speed signal fault injection module 222, and a power signal fault injection module 223. The high-speed signal fault injection module 221 executes test cases for high-speed signal fault testing. Taking the hardware under test 130 as a hard drive backplane as an example, high-speed signal faults may include, for example, clock loss or high-speed signal short circuits. The corresponding hard drive backplane pins are SAS / SATA, PCIE, 100M_CLK, etc. The low-speed signal fault injection module 222 executes test cases for low-speed signal fault testing. Taking the hardware under test 130 as a hard drive backplane as an example, low-speed signal faults may include, for example, hard drive presence loss, NVME disk clock hangup, or data hangup. The corresponding hard drive backplane pins are I2C, etc. The power signal fault injection module 223 is used to execute test cases for power signal fault testing. Taking the hardware under test 130 as a hard disk backplane as an example, the power signal fault can be a power short circuit, power abnormality, etc., and the corresponding hard disk backplane pins are VCC_12V, VCC_5V, STBY_3V3, etc.

[0071] In this embodiment, the test case processing module 230 may include a microcontroller unit (MCU) processor 231, which is used to identify the injected fault type corresponding to the test case based on the test case identifier before the test case execution module 220 executes the test case. Based on the injected fault type, the test case execution module 220 determines the execution module corresponding to the test case and sends the test case to that execution module, causing the execution module to execute the test case. For example, the MCU processor 231 may send high-speed signal test cases to the high-speed signal fault injection module 221 for execution, low-speed signal test cases to the low-speed signal fault injection module 222 for execution, and power signal test cases to the power signal fault injection module 223 for execution.

[0072] In this embodiment, the use case processing module 230 may further include a power supply module 232 and a firmware chip 233. The power supply module 232 is used to provide power to the fault simulation device 110, and the firmware chip 233 is used to store software version information and initialize the use case processing module 230 when the fault simulation device 110 is started.

[0073] In this embodiment, the test terminal 120 is used to store pre-edited test cases and to send corresponding test cases to the fault simulation device 110. The processor 140 and the memory 150 are coupled. The memory 150 is used to store computer program instructions, and when the computer program instructions are executed by the processor 140, the computing device executes the fault injection method and / or test case sending method proposed in this application.

[0074] The following will describe a fault injection method provided in this application:

[0075] See Figure 3 , Figure 3 A flowchart illustrating a fault injection method provided in this application embodiment is shown. This method can be used for... Figure 1 The computing device in the process includes the following steps:

[0076] 301: The fault simulation device sends the model information of the hardware under test to the test terminal.

[0077] In this embodiment, the example of using a hard disk backplane as the hardware to be tested is continued. During testing, the fault simulation device needs to be inserted into the hard disk backplane socket to establish a connection with the hard disk backplane and obtain power to power on and initialize. Based on this, the fault simulation device 110 can read the device information of the hard disk backplane, obtain the model information from it, and send the model information to the test terminal 120 through the test case input module 210.

[0078] In the optional real-time mode, this model information can also be entered into the test terminal 120 by the tester.

[0079] 302: The test terminal obtains the corresponding historical test information based on the model information.

[0080] In this embodiment, the historical test information is used to record the historical test records of the hardware device corresponding to the model information. Specifically, the historical test database can be queried based on the model information to extract the historical test information that contains the same model information. That is, the database is searched to see if there are any historical tests of the same model; if so, their historical test information is retrieved.

[0081] 303: The test terminal groups at least one test case based on the model information to obtain a necessary test case group and an unnecessary test case group.

[0082] In this embodiment, the at least one test case can be written by the tester and pre-stored in the test terminal to instruct the fault simulation device to perform the corresponding fault. Specifically, after obtaining the model information, the test terminal 120 can determine the device type of the hardware device based on the model information, and then determine the test items that must be performed on this type of device. The test cases corresponding to these mandatory test items are then selected as the necessary test case group. The remaining test cases are classified as the non-necessary test case group.

[0083] In this embodiment, the development documents of the device model can be queried based on the signal information to determine its development purpose. Then, based on the development purpose, some necessary test items can be identified. For example, if the development purpose of the device corresponding to model information A is to provide a hardware device with more stable high-speed signals, then test items related to high-speed signal stability can also be included as necessary test items, and the test cases corresponding to the test items related to high-speed signal stability can be assigned to the necessary test case group.

[0084] 304: The test terminal determines at least one first test case from the non-essential test case group based on historical test information.

[0085] In this embodiment, the names of test cases that have been tested twice or more in historical test information can be obtained to obtain at least one first test name. Therefore, based on at least one first test name, at least one first test case can be determined from the group of non-essential test cases, wherein the at least one first test name includes the name of any one of the at least one first test cases.

[0086] Specifically, historical test information can be used to identify test cases that passed at least twice or failed altogether. These test cases are then compared with examples in the non-essential test case group, and the same test cases from the non-essential test case group are identified and used as the first test case for retesting.

[0087] 305: The test terminal sends at least one first test case and all test cases in the necessary test case group to the fault simulation device.

[0088] In this embodiment, the test terminal 120 can send at least one first test case and all test cases in the necessary test case group to the fault simulation device 110 through the test case input module 210 in the fault simulation device 110.

[0089] In optional implementations, the test terminal 120 may also select and distribute corresponding test cases based on the configuration information pre-set by the tester, or distribute all test cases, or display a list of test cases to the tester for real-time selection and distribution, or the fault simulation device 110 may actively request and distribute corresponding test cases. This application does not impose any restrictions on this. When the fault simulation device 110 actively requests corresponding test cases, the method described above for determining at least one first test case through type information may also be executed by the fault simulation device 110.

[0090] 306: The fault simulation device executes test cases.

[0091] In this embodiment, before executing step 306, the injection fault type of the test case can be identified based on the test case's identifier. Then, based on the injection fault type, the first execution module corresponding to the test case is determined in at least one execution module, and the test case is sent to that first execution module for execution.

[0092] For example, different identifiers can be assigned to test cases based on the test items. For instance, for a power failure test case, the first two digits of its identifier can be set to "A0", thus the identifier for a power failure test case is "A0xxx"; for a high-speed failure test case, the first two digits of its identifier can be set to "B0", thus the identifier for a high-speed failure test case is "B0xxx"; for a low-speed failure test case, the first two digits of its identifier can be set to "C0", thus the identifier for a low-speed failure test case is "C0xxx"; and for a clock failure test case, the first two digits of its identifier can be set to "D0", thus the identifier for a clock failure test case is "D0xxx".

[0093] Therefore, in this embodiment, the type of injected fault corresponding to the test case can be determined by identifying the first two digits of the test case identifier. Furthermore, in this embodiment, the execution module with the same fault type as the injected fault type is prioritized as the first execution module, and the test case is then executed by this first execution module. This improves testing efficiency and enables parallel testing of multiple faults.

[0094] Furthermore, when there are multiple test cases of a certain type, these test cases can be sorted and then executed sequentially. Specifically, the importance and test time of each test case can be determined first, along with the test strategy for this test. Then, the priority of each test case can be determined based on its importance, test time, and test strategy. Finally, these test cases are sorted in descending order of priority. Of course, the sorting can also be based on the release time of each test case, or by the testers themselves; this application does not impose any restrictions on this.

[0095] In this embodiment, after determining the execution order, the fault simulation device 110 executes the test cases sequentially according to the execution order, injecting test signals into the hardware under test. Specifically, taking the power failure test case as an example, the fault simulation device 110 first identifies the injected fault type of the test case with fault case code A00001 as a power failure, and then sends it to the power signal fault injection module 223 that executes the power failure test. The power signal fault injection module 223 executes the test case, short-circuits the corresponding circuit, and pulls the power supply of the hardware device low to simulate a short circuit fault.

[0096] In an optional implementation, the execution modules in the test case execution module 220 are reusable. That is, test cases can also be executed by execution modules with different fault types to ensure testing efficiency. Specifically, when determining the first execution module, the number of tasks in the second execution module can be determined first. The second execution module is at least one execution module whose fault type is the same as the injected fault type, and the number of tasks is the number of test cases waiting to be executed in the second execution module. In short, it determines the number of test cases waiting to be executed on the execution module whose fault type is the same as the injected fault type.

[0097] Then, when the number of tasks exceeds the threshold, it indicates that there are many accumulated test cases on the corresponding type of execution module. Continuing to assign them would require a long wait before execution, in which case the third execution module can be determined as the first execution module. Specifically, the third execution module is any execution module among at least one of the remaining execution modules (excluding the second execution module) whose number of tasks is less than the threshold. That is, any execution module with a number of tasks less than the threshold is selected for assignment, with priority given to the execution module with the smallest number of tasks. When no third execution module exists, the test case can be assigned to the second execution module, any execution module among all execution modules, or the execution module with the smallest number of tasks among all execution modules; this application does not impose any restrictions on this.

[0098] When the number of tasks is less than the threshold, the second execution module can be directly identified as the first execution module.

[0099] 307: Fault simulation device received error code.

[0100] In this embodiment, the error code is generated by the fault detection device on the hardware under test 130 based on the test signal generated by the fault, and is used to identify the fault identified by the fault detection device on the hardware under test 130. Specifically, after detecting the test signal, the fault detection device generates a corresponding error code reporting value to the fault simulation device 110. Continuing with the example of the fault case code A00001 described above, after the power supply of the hardware device is pulled low and short-circuited, the fault detection device on the hardware under test, such as a CPLD, detects that there is no power output and generates error code A00001 to report to the fault simulation device 110.

[0101] In an optional implementation, the generated error code A00001 can also be first reported by the control circuit of the hardware under test 130 to the test terminal 120, and then the test terminal 120 reports the error code A00001 to the fault simulation device 110. Specifically, when the test terminal 120 can report the error code A00001 to the fault simulation device 110, it indicates that the test terminal 120 has identified the fault and promptly reported it to the user, thereby achieving synchronous verification of the software reliability of the test terminal 120.

[0102] In an optional implementation, the test terminal 120 can be a server, thereby enabling the server's reliability to be verified synchronously through the aforementioned forwarding method.

[0103] 308: When the error code matches the preset result, the fault simulation device determines that the fault injection was successful.

[0104] In this embodiment, after receiving error code A00001, the fault simulation device 110 compares it with the preset expected result. If the result matches, it indicates that the fault injection was successful. At this time, a fault clearing command can be executed to inject a fault clearing signal into the hardware under test, clearing the simulated fault, and receiving the clearing result returned by the hardware under test. This clearing result can be directly reported to the fault simulation device 110 by the hardware under test, or it can be forwarded by the test terminal 120. When the clearing result shows no abnormality, the fault injection for this test case can be terminated, and the next test case can be executed.

[0105] In this implementation, if the error code does not match the expected result of the test case, the current test case can be executed again until the result matches or the preset number of repetitions is reached. The number of repetitions can be set by the tester. If no error code matching the expected result is obtained after the number of repetitions is reached, the current test case can be forcibly terminated, and the next test case can be executed.

[0106] As can be seen, in this embodiment, historical test information corresponding to the model information of the hardware under test is obtained. Then, based on this historical test information, test cases that need to be sent to the fault simulation device are automatically determined from at least one test case, achieving automatic screening and sending of test cases. Simultaneously, the fault simulation device installed on the hardware under test runs the corresponding test cases, injecting faults into the hardware device under test. By receiving error codes generated by the fault detection device on the hardware under test based on the test signals and comparing them, fully automatic fault injection and testing are achieved. Using the method provided in this embodiment, no human intervention is required throughout the process. Compared to manual fault debugging in traditional hardware testing, this method offers higher testing efficiency and significantly reduces labor costs.

[0107] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement some or all of the steps of any of the fault injection methods and / or test case distribution methods described in the above method embodiments.

[0108] This application also provides a computer program product that, when run on a computer or processor, causes the computer or processor to execute one or more steps of any of the fault injection methods and / or test case distribution methods described above. If the constituent modules of the aforementioned devices are implemented as software functional units and sold or used as independent products, they can be stored in the computer-readable storage medium.

[0109] It should be understood that the processor mentioned in the embodiments of this application can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0110] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), Synchlink Dynamic Random Access Memory (SLDRAM), and Direct Rambus RAM (DRRAM).

[0111] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory (storage module) is integrated into the processor.

[0112] It should be noted that, for the sake of simplicity, the aforementioned methods are described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps can be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0113] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0114] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.

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

[0116] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of a software program module.

[0117] If the integrated unit is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device. Based on this understanding, the technical solution of this application, 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. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application.

[0118] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware, and the program can be stored in a computer-readable storage medium. The storage medium may include: flash drive, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc.

[0119] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The above description of the embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method of fault injection, the method comprising: The method is applied to a fault simulation device, the fault simulation device being installed on the hardware under test, the method comprising: Obtain test cases, wherein the test cases are used to instruct the fault simulation device to perform the corresponding fault; Execute the test cases to inject the fault into the hardware device under test; Receive error codes, wherein the error codes are generated by the fault detection device on the hardware under test based on the test signals generated by the fault; When the error code matches the preset result, the fault injection is determined to be successful; Prior to executing the test case, the method further includes: Identify the injection fault type corresponding to the test case based on the test case identifier; The number of tasks in the second execution module is determined, wherein the second execution module is at least one execution module whose fault type is the same as the injected fault type, and the number of tasks is the number of test cases waiting to be executed in the second execution module; When the number of tasks is greater than the threshold, the third execution module is determined to be the first execution module, wherein the third execution module is any one of the execution modules remaining after excluding the second execution module among the at least one execution module, and the number of tasks is less than the threshold; When the number of tasks is less than the threshold, the second execution module is determined to be the first execution module; The test cases are sent to the first execution module.

2. The method according to claim 1, characterized in that, The execution module includes: High-speed signal fault injection module, low-speed signal fault injection module and power signal fault injection module.

3. The method according to claim 1 or 2, characterized in that, The received error codes include: The error code is received from the test terminal, wherein the error code is reported to the test terminal by the control circuit on the hardware under test, and the error code is used to identify the fault identified by the fault detection device.

4. The method according to claim 1 or 2, characterized in that, The received error codes include: Receive the error code from the hardware under test.

5. The method according to claim 1 or 2, characterized in that, After confirming successful fault injection, the method further includes: Execute a fault clearing command to inject a clearing signal to the hardware under test to clear the fault; Receive a clearing result, wherein the clearing result is generated by the hardware device based on the clearing signal; When the cleanup result is no abnormality, the fault injection test of the test case ends.

6. The method according to claim 1 or 2, characterized in that, The hardware to be tested is a hard drive backplane.

7. A method for distributing test cases, characterized in that, The method is applied to a test terminal, which is communicatively connected to a fault simulation device, and the method includes: Receive model information of the hardware to be tested from the fault simulation device; Obtain historical test information corresponding to the model information, wherein the historical test information is used to record the historical test records of the hardware device corresponding to the model information; At least one test case is grouped according to the model information to obtain a necessary test case group and an unnecessary test case group, wherein the at least one test case is stored in the test terminal; Based on the historical test information, at least one first test case is determined from the group of non-essential test cases. The at least one first test case and all test cases in the necessary test case group are distributed to the fault simulation device, so that the fault simulation device sends the test cases to the first execution module for execution. The first execution module is determined by the fault simulation device based on the following method: Identify the injection fault type corresponding to the test case based on the test case identifier; The number of tasks in the second execution module is determined, wherein the second execution module is at least one execution module whose fault type is the same as the injected fault type, and the number of tasks is the number of test cases waiting to be executed in the second execution module; When the number of tasks is greater than the threshold, the third execution module is determined to be the first execution module, wherein the third execution module is any one of the execution modules remaining after excluding the second execution module among the at least one execution module, and the number of tasks is less than the threshold; When the number of tasks is less than the threshold, the second execution module is determined to be the first execution module.

8. The method according to claim 7, characterized in that, The step of determining at least one first test case from the non-essential test case group based on the historical test information includes: Obtain the names of test cases that have been tested twice or more from the historical test information to obtain at least one first test name; Based on the at least one first test name, the at least one first test case is determined in the group of non-essential test cases, wherein the at least one first test name includes the name of any one of the at least one first test cases.

9. A fault simulation device, characterized in that, The fault simulation device includes: The test case input module is used to obtain test cases, wherein the test cases are used to instruct the fault simulation device to perform the corresponding fault; The test case execution module is used to execute the test cases to inject the fault into the hardware device under test; The test case input module is also used to receive error codes, wherein the error codes are generated by the fault detection device on the hardware under test based on the test signals generated by the fault; The test case execution module is also used to determine that the fault injection was successful when the error code matches the preset result; The fault simulation device further includes: The test case processing module is configured to, before the test case execution module executes the test case, identify the injection fault type corresponding to the test case based on the test case identifier, determine the number of tasks for the second execution module, wherein the second execution module is at least one execution module whose fault type is the same as the injection fault type, and the number of tasks is the number of test cases waiting to be executed in the second execution module. When the number of tasks is greater than a threshold, a third execution module is determined as the first execution module, wherein the third execution module is any execution module among the at least one execution module excluding the second execution module whose number of tasks is less than the threshold. When the number of tasks is less than the threshold, the second execution module is determined as the first execution module, and the test case is sent to the first execution module.

10. The fault simulation device according to claim 9, characterized in that, The execution module includes: High-speed signal fault injection module, low-speed signal fault injection module and power signal fault injection module.

11. The fault simulation device according to claim 9 or 10, characterized in that, The use case input module includes: One or more of the following: WiFi module, Universal Serial Bus module, Serial port module, and Ethernet module.

12. The fault simulation device according to claim 9 or 10, characterized in that, The use case processing module also includes: The power supply module is used to provide electrical energy to the fault simulation device; A firmware chip is used to store software version information and initialize the test case processing module when the fault simulation device is started.

13. The fault simulation device according to claim 9 or 10, characterized in that, The use case processing module includes a microcontroller processor.

14. A computing device, characterized in that, The device includes a fault simulation apparatus, a test terminal, hardware under test, a processor, and a memory. The fault simulation apparatus is communicatively connected to the test terminal and the processor. The fault simulation apparatus is installed on the hardware under test. The processor and the memory are coupled. The memory is used to store computer program instructions. When the computer program instructions are executed by the processor, the computing device performs the method as described in any one of claims 1-8.

15. A computer-readable medium, characterized in that, The computer-readable medium stores program code for execution by the device, the program code including the method for performing any one of claims 1-8.

Images