Fault injection method and apparatus, fault testing method and apparatus, computer device, and medium

Abstract

The present application relates to a fault injection method and apparatus, a fault testing method and apparatus, a computer device, and a medium. The fault injection method comprises: acquiring a fault modification request, parameters of the fault modification request at least comprising a target signature, a target identifier, a fault type, modification content, and an injection validity period; calling a fault injector to generate a fault program corresponding to the fault modification request; and using the fault injector to inject the fault program into a target function, wherein when the target function is called by a target process, the fault program is used for processing an input parameter and / or a return parameter of the target function, the target function is a function corresponding to the target signature, and the target process is a service process corresponding to the target identifier.

Description

Fault injection methods, fault testing methods, apparatus, computer equipment and media

[0001] Related applications

[0002] This application claims priority to Chinese patent application filed on November 27, 2024, application number 2024117163974, entitled "Fault Injection Method, Fault Testing Method, Apparatus, Computer Equipment and Media", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the technical field of fault testing, and in particular to a fault injection method, fault testing method, apparatus, computer equipment, and medium. Background Technology

[0004] In the field of software development and operations, in order to improve the reliability and stability of developed products, developers will actively inject faults into the product during the testing phase to test the product's ability to handle faults.

[0005] In related technologies, hot patching is typically used to replace the Syscall instruction in the Libc library to hook system calls and simulate system call failures. As shown in Figure 1, the fault injection method in related technologies requires embedding the fault injection library into the product's source code, and the corresponding fault injection library must be compiled and linked. When adjustments or modifications are needed to the injected faults, not only must the fault programs in the fault library be modified, but the product's source code also needs to be recompiled, resulting in low efficiency in fault testing.

[0006] Therefore, how to improve the efficiency of fault testing is an urgent problem to be solved. Summary of the Invention

[0007] Based on this, this application provides a fault injection method, a fault testing method, an apparatus, a computer device, and a medium.

[0008] Firstly, this application provides a fault injection method, including:

[0009] Obtain a fault modification request, wherein the parameters of the fault modification request include at least the target signature, target identifier, fault type, modification content, and injection period;

[0010] The fault injector is invoked to generate the fault program corresponding to the fault modification request.

[0011] The fault injector is used to inject the fault program into the target function, wherein when the target function is called by the target process, the fault program is used to process the input parameters and / or return parameters of the target function; the target function is the function corresponding to the target signature, and the target process is the service process corresponding to the target identifier.

[0012] In one embodiment, the step of invoking the fault injector to generate the fault program corresponding to the fault modification request includes:

[0013] The fault injector is invoked to match the parameters in the fault modification request and determine the program content corresponding to each parameter.

[0014] Fill the program content corresponding to each of the parameters into the program template to obtain the fault program corresponding to the fault modification request.

[0015] In one embodiment, injecting the fault program into the target function using the fault injector includes:

[0016] The target compiler and target compilation type are determined based on at least one parameter in the fault modification request;

[0017] The faulty program is compiled based on the target compiler and the target compilation type to obtain the compiled faulty bytecode;

[0018] The fault bytecode is injected into the target function using the fault injector.

[0019] In one embodiment, injecting the fault bytecode into the target function using the fault injector includes:

[0020] Based on the target signature, determine the target address where the target function is stored;

[0021] The fault bytecode is injected into the target function corresponding to the target address using the fault injector.

[0022] In one embodiment, the method further includes: receiving a fault clearing request, wherein the parameters of the fault clearing request include at least a clearing signature and a clearing identifier;

[0023] The fault injector is invoked to determine the storage address of the function to be cleared based on the clearing signature, wherein the function to be cleared is the function corresponding to the clearing signature;

[0024] The program to be cleared is determined based on the parameters in the clearing request, and the program to be cleared is deleted. The program to be cleared includes at least one faulty program that has been injected with the function to be cleared.

[0025] In one embodiment, the method further includes:

[0026] Receive a query request, and based on the query request, obtain the status information of each injected fault program, the status information including fault type, running status and running number;

[0027] The status information of each injected fault program is sent to the target device.

[0028] Secondly, this application provides a fault testing method, the method comprising:

[0029] When the current process calls the target function, it is determined whether the target program corresponding to the current process exists among the fault programs injected into the target function; the target program is used to process the input parameters or output parameters of the target function when the current process calls the target function;

[0030] If it is determined that the target program corresponding to the current process exists, then the fault parameters are fed back to the current process. The fault parameters are the parameters obtained by the target program after processing the input parameters and / or output parameters of the target function.

[0031] Thirdly, this application also provides a fault testing device, the device comprising a request acquisition module, a program generation module, and an injection module, wherein:

[0032] The request acquisition module is used to acquire fault modification requests. The parameters of the fault modification request include at least the target signature, target identifier, fault type, modification content, and injection period.

[0033] The program generation module is used to call the fault injector to generate the fault program corresponding to the fault modification request;

[0034] An injection module is used to inject the fault program into a target function using the fault injector, wherein when the target function is called by a target process, the fault program is used to process the input parameters and / or return parameters of the target function; the target function is the function corresponding to the target signature, and the target process is the service process corresponding to the target identifier.

[0035] Fourthly, this application also provides a fault testing device, the device comprising a determination module and a feedback module, wherein:

[0036] The determination module is used to determine, when the current process calls the target function, whether there is a target program corresponding to the current process among the faulty programs injected into the target function; the target program is used to process the input parameters or output parameters of the target function when the current process calls the target function;

[0037] If the feedback module determines that the target program corresponding to the current process exists, it feeds back the fault parameters to the current process. The fault parameters are the parameters obtained by the target program after processing the input parameters and / or output parameters of the target function.

[0038] Fifthly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any one of the methods described in the first or second aspect above.

[0039] Sixthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any one of the methods described in the first or second aspect above.

[0040] In a seventh aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any one of the methods described in the first or second aspect above.

[0041] The aforementioned fault injection method, fault testing method, apparatus, computer equipment, and medium involve a fault injector that generates a corresponding fault program based on an acquired fault modification request. This fault program is not inserted into the source code of the target process under test, but rather injected into the target function called by the target process. This allows the fault program to process the input and / or return parameters of the target function when it is called by the target process, resulting in incorrect parameters being returned to the target process, thus simulating a fault in the target process's operation. Furthermore, whenever the injected fault program needs modification, a fault modification request is input, causing the fault injector to generate a new fault program to inject into the function called by the target process, eliminating the need to readjust and compile the target product's source code, thereby improving the efficiency of fault testing. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of this application or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the disclosed drawings without creative effort.

[0043] Figure 1 is a logical diagram of fault injection in related technologies;

[0044] Figure 2 is a flowchart illustrating a fault injection method in one embodiment;

[0045] Figure 3 is a schematic diagram of the steps for generating a fault program in one embodiment;

[0046] Figure 4 is a schematic diagram of the compilation process for a faulty program in one embodiment;

[0047] Figure 5 is a schematic diagram of the fault clearing steps in one embodiment;

[0048] Figure 6 is a schematic diagram of the monitoring process for the injected fault program in one embodiment;

[0049] Figure 7 is a flowchart illustrating the fault injection method in another embodiment;

[0050] Figure 8 is a schematic diagram of a fault injection scenario according to another embodiment;

[0051] Figure 9 is a code diagram of fault injection in another embodiment;

[0052] Figure 10 is a flowchart illustrating a fault testing method in one embodiment;

[0053] Figure 11 is a schematic diagram of a fault injection and fault testing scenario in one embodiment;

[0054] Figure 12 is a structural block diagram of a fault injection device in one embodiment;

[0055] Figure 13 is a structural block diagram of a fault testing device in one embodiment;

[0056] Figure 14 is an internal structure diagram of a computer device in one embodiment. Detailed Implementation

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

[0058] In one exemplary embodiment, a fault injection method is provided, illustrated by applying the method to a computer device. The computer device can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. The server can be a standalone server or a server cluster consisting of multiple servers.

[0059] This section provides explanations of some terms and concepts used in the fault injection method of this application:

[0060] EBPF (Extended Berkeley Packet Filter): It is a powerful virtual machine technology in the Linux kernel that provides a set of secure runtime constraints and verification mechanisms, ensuring system stability while extending kernel functionality.

[0061] Fault injection is a method used to test and verify the behavior and recovery capabilities of computer systems or software programs under fault conditions. It involves intentionally introducing errors or anomalies to simulate various failure scenarios, thereby observing the system's response, detecting potential problems, and assessing the system's reliability and robustness.

[0062] Kprobe (Kernel Probe): is a mechanism for inserting probes at arbitrary locations in the Linux kernel. It allows developers to insert EBPF probes at specific kernel functions or instructions to capture, record, and modify runtime information at those locations.

[0063] Kretprobe (Kernel Return Probe): An extension of Kprobe that allows you to insert EBPF probes when a function returns, thereby capturing, recording, and modifying runtime information at those locations.

[0064] Uprobe (User-space Probe): is a mechanism for inserting probes into user-space programs. It allows developers to insert EBPF probes at any location in a user-space program without modifying the program's source code.

[0065] Uretprobe (User-space Return Probe): is an extension of Uprobe, similar to Kretprobe, which can insert an EBPF probe when a user-space function returns.

[0066] EBPF_MAP (Extended Berkeley Packet Filter Map): is a data structure used by EBPF programs and user processes to store and share data.

[0067] The fault injection method provided in this application embodiment may include steps 110-130, as shown in Figure 2, wherein:

[0068] Step 110: Obtain the fault modification request. The parameters of the fault modification request shall include at least the target signature, target identifier, fault type, modification content, and injection period.

[0069] In the embodiments of this application, the fault modification request can be user-inputted or pre-configured and acquired by the computer device under corresponding triggering conditions. In one possible implementation, the fault modification request is acquired by the computer device at a preset time; in another possible implementation, the fault modification request can be matched with the product's development progress, that is, the fault modification requests corresponding to different development stages of the product are pre-set. When the product's development progress is updated, the computer device obtains the latest product development progress and then obtains the corresponding fault modification request based on the development progress.

[0070] In this application, during product runtime, certain processes need to call functions pre-stored in the target function library. The target signature is the function signature of the target function into which the fault needs to be injected. The function signature is unique and represents the function's identity and implemented functionality. The target identifier is the identifier of one or more processes in the product. Based on actual testing needs, it may be necessary to test all processes that call the target function, or it may be necessary to test only one or a few processes that call the target function. The target identifier represents the process to be tested. The fault type refers to the type of fault being added. For example, the fault type could be modifying the input parameters of the target function and / or modifying the return parameters of the target function. The classification of fault types is not specifically limited in this embodiment. The modification content refers to the specific logic to be injected with the fault, that is, the specific content of modifying the corresponding data in the process. The injection period is the duration of the injected fault. For example, the injection period can be permanently valid or only valid once.

[0071] Step 120: Call the fault injector to generate the fault program corresponding to the fault modification request.

[0072] In this embodiment, the fault injector is a pre-built component capable of generating a corresponding fault program based on a fault modification request. In one possible implementation, the fault injector is configured to parse each parameter in the fault modification request to obtain parsing information corresponding to each parameter, then match this parsing information with a pre-built program mapping table to obtain the program content corresponding to each parameter in the fault modification request, and finally construct the fault program based on the program content corresponding to each parameter. The program mapping table includes the probe type and program content corresponding to each parameter type.

[0073] In another possible implementation, the fault injector can be built based on a pre-trained LLM (Large Language Model). That is, after parsing the fault modification request, the parsing information corresponding to each parameter in the fault modification request is obtained. Then, the parsing information is organized into the input template of the LLM model and input into the fault injector to obtain the fault program output by the fault injector.

[0074] The specific logic of the fault injector generating fault programs based on fault injection requests is not specifically limited in this embodiment.

[0075] Step 130: Inject the fault program into the target function using the fault injector. When the target function is called by the target process, the fault program is used to process the input parameters and / or return parameters of the target function. The target function is the function corresponding to the target signature, and the target process is the service process corresponding to the target identifier.

[0076] In this embodiment of the application, the fault injector is further configured to inject the generated fault program into the target function corresponding to the target signature, so that when the target process corresponding to the target identifier in the product calls the target function, the injected fault program can process the input parameters and / or return parameters of the target function, thereby causing the target process to receive the erroneous return parameters returned by the target function, thereby simulating the fault.

[0077] In the aforementioned fault injection method, the fault injector generates a corresponding fault program based on the acquired fault modification request. The fault program is not inserted into the source code of the target process under test, but rather injected into the target function called by the target process. This allows the fault program to process the input and / or return parameters of the target function when it is called by the target process, resulting in incorrect parameters being returned to the target process, thus simulating a fault in the target process's operation. Furthermore, whenever the injected fault program needs modification, only a fault modification request needs to be input, causing the fault injector to generate a new fault program to inject into the function called by the target process, without needing to readjust and compile the source code of the target product, thereby improving the efficiency of fault testing.

[0078] In one embodiment, referring to FIG3, step 120 may include steps 121 and 122, wherein:

[0079] Step 121: Call the fault injector to match the parameters in the fault modification request and determine the corresponding program content for each parameter.

[0080] In this embodiment, the fault injector is configured to parse the parameters in the fault modification request to obtain the parsing information corresponding to each parameter. Then, based on the parsing information, it matches the parameters in a pre-built program mapping table to obtain the program content corresponding to each parameter in the fault modification request. Finally, it constructs a fault program based on the program content corresponding to each parameter. The program mapping table includes the probe type and program content corresponding to each parameter type.

[0081] The data carried in the fault modification request may be encoded data or natural language. Therefore, the fault injector is first called to parse the fault modification request to obtain the parsing information of each parameter. The parsing information is a pre-formatted structural parameter or code parameter. The specific type of parsing information is not specifically limited in this embodiment.

[0082] After the target signature is parsed, the parsed information is the target function and the target address where the target parameters are stored; after the target identifier is parsed, the parsed information is the PID (Process Identifier) ​​of the target process; after the fault type is parsed, the parsed information is the modification of the input parameters and / or return parameters of the target parameters; after the modification content is parsed, the parsed information is the logic of the parameter modification or the modified content; after the injection period is parsed, the parsed information is the validity period of the injected fault program, or the number of times it can be used. Furthermore, the mapping table stores the program content (program code) corresponding to each parameter. Based on the parsed information of each parameter, the fault injector matches from the mapping table to determine the program content corresponding to each parameter.

[0083] Furthermore, the target function could be a function called by a service process within the product's kernel, or it could be a function called by a process within a user-space program. Therefore, after parsing the target signature information, the function type of the target function is determined. The function type indicates whether the function is called by a process within the kernel or by a process within user space. Then, the program content corresponding to the target signature is determined based on the type of the target function. For example, if the target function is a function called by a service process within the kernel, then the program content matching the Kprobe kernel probe can be used.

[0084] Step 122: Fill the program content corresponding to each parameter into the program template to obtain the fault program corresponding to the fault modification request.

[0085] The program template can be a pre-defined fixed template or a target template determined based on the target process or target function. In one possible implementation, the target function could be a function called by a service process in the product's kernel or a function called by a process in a user-space program. Therefore, the function type of the target function determined in the above steps is used to match the target template from the pre-defined program templates. For example, if the target function is a function called by a service process in the kernel, the target template matched based on the function type should be the program template matching the kernel probe Kprobe. In another possible implementation, the process type of the target process can be directly determined. The process type indicates whether the process is a service process in the kernel or a service process in user space, and the target template is then matched from the pre-defined program templates based on the type of the target process.

[0086] In one embodiment, referring to FIG4, step 130 may include steps 131-133, wherein:

[0087] Step 131: Determine the target compiler and target compilation type based on at least one parameter in the fault modification request;

[0088] Step 132: Compile the faulty program based on the target compiler and target compilation type to obtain the compiled faulty bytecode.

[0089] In this embodiment, the faulty program generated based on the fault modification request needs to be compiled into a corresponding format before it can be loaded and run. The target compiler and target compilation type required to compile the faulty program can be preset compilers and compilation types, such as the compilation type being Elf (Executable and Linkable Format). Further, the target compiler and target compilation type can be determined from a plurality of preset compilers and compilation types based on at least one parameter in the request. In one possible implementation, the target compilation type can be a type matching the function type or programming language of the target function, and the target compilation type can also be a type matching the process type of the target process. The target compiler is then determined based on the determined target compilation type. This embodiment does not specifically limit the method for determining the target compilation type and target compiler, as long as the compiled faulty bytecode can run stably.

[0090] Step 133: Inject fault bytecode into the target function using a fault injector.

[0091] Based on the target signature, the target address for storing the target function is determined. Then, a fault injector is used to inject fault bytecode into the target function corresponding to the target address. The destination address for storing the target function can be obtained from the parsed information obtained after parsing the target signature in step 121.

[0092] The above describes how to generate a fault program corresponding to a fault modification request, and how to inject the generated fault program into the corresponding target function. In fact, a fault modification request is equivalent to a fault injection request. Furthermore, the target function injected for a fault modification request can be either a target function that has already been injected with a fault program, or a target function that has not been injected with a fault program.

[0093] In one embodiment, a method for clearing faulty procedures that have already been injected with functions is further described, referring to Figure 5, including steps 140-160, wherein:

[0094] Step 140: Receive a fault clearing request. The parameters of the fault clearing request include at least a clearing signature and a clearing identifier.

[0095] In one possible scenario, product fault testing might be performed on the complete product after all the service modules have been built, or it might be performed when only some of the product's service modules have been built. A topology graph is pre-built based on the product's module / service architecture. Each node in the topology graph represents a service process or a service process tree (containing multiple related process sets), and the variables between nodes represent data input and output relationships. Then, corresponding fault injection and fault clearing requests are configured for each node.

[0096] When it is necessary to perform fault testing on an incomplete product, the current product is traversed to obtain each built service process. Then, based on each built service process, the product's topology graph is matched to determine the product's development progress. Finally, the fault injection request and / or fault clearing request corresponding to each built development process in the topology graph are obtained.

[0097] Step 150: Invoke the fault injector and determine the storage address of the function to be cleared based on the clear signature. The function to be cleared is the function corresponding to the clear signature.

[0098] Step 160: Determine the program to be cleared based on the parameters in the clearing request, and delete the program to be cleared. The program to be cleared includes at least one faulty program that has been injected with the function to be cleared.

[0099] A fault cleanup request includes at least a cleanup signature and / or a cleanup identifier. The cleanup signature is the signature of the function (the function to be cleaned) injected by the faulty program. When the process corresponding to the cleanup identifier (the process to be cleaned) calls the function corresponding to the cleanup signature, the injected faulty program is executed. Further, when the fault cleanup request only includes a cleanup signature, the fault injector is invoked to determine the storage address of the function to be cleaned based on the cleanup signature, and then all faulty programs injected into the function to be cleaned are deleted. When the fault cleanup request only includes a cleanup identifier, the fault injector is invoked to determine all functions that the process to be cleaned can call based on the cleanup identifier, and then the faulty programs injected into these functions are deleted. When the fault cleanup request includes both a cleanup signature and a cleanup identifier, the fault injector is invoked to determine the storage address of the function to be cleaned based on the cleanup signature, then the program to be cleaned is determined based on the parameters in the cleanup request, and the program to be cleaned is deleted. The program to be cleaned includes at least one of the faulty programs injected into the function to be cleaned.

[0100] Furthermore, when the fault injector injects the fault program into the corresponding function for any fault modification request, and when it injects the fault program into the function corresponding to any fault clearing request parameter, it will generate a corresponding execution log. The execution log records the time when the fault program is injected into the function or the time when the fault program is deleted from the injected function.

[0101] In one embodiment, to facilitate the management and monitoring of the injected fault programs, this embodiment further includes a monitoring process for the injected fault programs. Referring to FIG6, this process may include steps 170 and 180, wherein:

[0102] Step 170: Receive a query request. Based on the query request, obtain the status information of each injected fault program. The status information includes the fault type, running status, and number of runs.

[0103] Step 180: Send the status information of each injected fault program to the target device.

[0104] The query request can be sent by the user, automatically generated at preset intervals, or generated in response to the injection of a new fault program. This application does not specifically limit the generation process of the query request. Each injected fault program can send its status information to the target device through the PERF_EVENT mechanism. The status information includes the fault type, running status, and number of runs, and may also include information such as whether the fault injection was successful; this application does not specifically limit the specific content of the status information. By receiving the status information of each fault program, the fault injector can monitor the running status of each injected fault program in real time and provide feedback to the developers.

[0105] In one exemplary embodiment, this application provides a fault injection method, including steps S1-S6.

[0106] in:

[0107] Step S1: Start the fault management program.

[0108] In step S1, the fault management program is a resident user process that provides services to the outside world through HTTP (Hypertext Transfer Protocol) or API (Application Programming Interface). Users can submit fault injection requests, fault clearing requests, and query requests through this interface.

[0109] Step S2: Dynamically generate the EBPF program.

[0110] In step S2, when the fault management service receives a user's fault modification request or fault injection request, it dynamically generates an EBPF program based on the parameters in the request (such as function entry point, fault type, and modification content). The function entry point is the signature of the function to be injected with the fault, i.e., the target signature. The generated EBPF program (fault program) can modify the input parameters and / or return parameters of the corresponding function to simulate different types of faults.

[0111] Step S3: Compile the EBPF program.

[0112] In step S3, the generated EBPF program code is compiled into Elf format bytecode so that it can be loaded and executed by the kernel. During the compilation process, an appropriate compiler and compilation options are determined to ensure that the generated faulty bytecode can run correctly.

[0113] Step S4: Mount the EBPF program to the probe point.

[0114] In step S4, the compiled fault bytecode is attached to a specified probe point, which can be any one of Kprobe, Kretprobe, Uprobe, or Uretprobe. The probe point is determined based on the function type of the target function to which the fault is inserted. The function type indicates whether the target function is called by the system kernel or by user space. Kprobe, Kretprobe, Uprobe, or Uretprobe correspond to the entry and return points of system-called functions and user-defined called functions, respectively. When the target function is called, the corresponding EBPF program is triggered and executed, thereby modifying the behavior of the target function.

[0115] Step S5: Process limitation and status monitoring.

[0116] In step S5, to ensure the accuracy of fault injection, for each injected EBPF program (fault program), the EBPF_MAP is used to restrict each fault program to only affect the specified PID process (target process). This means that for an injected fault program, only a specific process will be affected by it. The EBPF program reports its running status (status information), including whether the fault injection was successful, to the fault management service through the PERF_EVENT (performance analysis tool) mechanism. By receiving this status information, the fault management service can monitor the running status of each injected EBPF program in real time and provide feedback to the user.

[0117] Step S6: Fault Clearing and Query.

[0118] In step S6, users can submit fault clearing requests via HTTP or API. Upon receiving the clearing request, the fault management service will unmount the corresponding EBPF program, allowing the corresponding function to be correctly called and its parameters processed by the corresponding process. Simultaneously, users can query the current fault injection status of the faulty program; the fault management service will provide detailed status information, including which processes are being injected with faults and the fault type.

[0119] In the aforementioned fault injection method, the fault injector generates a corresponding fault program based on the acquired fault modification request. The fault program is not inserted into the source code of the target process under test, but rather injected into the target function called by the target process. This allows the fault program to process the input and / or return parameters of the target function when it is called by the target process, resulting in incorrect parameters being returned to the target process, thus simulating a fault in the target process's operation. Furthermore, whenever the injected fault program needs modification, only a fault modification request needs to be input, causing the fault injector to generate a new fault program to inject into the function called by the target process, without needing to readjust and compile the source code of the target product, thereby improving the efficiency of fault testing.

[0120] This application provides an example of fault injection:

[0121] Figure 8 illustrates a scenario using a fault injector in testing. The test suite sends a fault injection (modification) request to the fault injection management program. This request includes the PID of the process to be injected, the function signature of the injected fault, the injection method (input parameters or return value), and the injection strategy (single injection or permanent effect, etc.). Upon receiving the request, the fault injection management program converts it into an EBPF program (fault program) and calls the Clang compiler to compile it into an Elf format binary file. The compiled binary file (bytecode) is then mounted onto the corresponding function in Kprobe or Uprobe. The test suite sends a fault test request to the service under test (product). The service under test process executes the request. When the service under test calls the function of the fault-injected program, the fault program is executed, modifying the function's input parameters and return value to achieve the fault injection purpose. The test suite uses the service under test's response to determine whether the service under test can recover as expected after a fault occurs.

[0122] Figure 9 shows a code example of injecting a fault. When process ID 12345 calls the Open function to open a disk file named Filename, this filename will be replaced with ". / not_exist.data" before the actual open operation is performed. Since this file does not exist, the Open function call will fail. Of course, the EBPF program (fault program) generated in actual fault testing will be much more complex than this example, because the EBPF program will contain a lot of logic that interacts with the fault management program, which will not be elaborated here.

[0123] The fault injection method described in this application completely decouples the injected fault program from the product's source code, forming a non-intrusive fault injection. Furthermore, since the injected fault program uses EBPF technology, it modifies function input parameters and return values ​​by mounting Kprobe, Kretprobe, Uprobe, and Uretprobe. This allows for fault injection and modification without modifying the product's source code, ensuring the integrity and stability of the product's source code.

[0124] The fault injector allows users to finely control the fault injection strategy by inputting fault modification requests. For example, the number of fault injections can be set, or fault injection can be specified to target only specific functions. This flexibility makes fault testing of the product more precise and meets different testing needs. Furthermore, the fault injection method of this application allows for flexible adjustment of the fault injection strategy. When modifying the fault injection strategy, it is not necessary to recompile the source code corresponding to the product's process; only the test suite (fault program) needs to be adjusted. This greatly improves testing efficiency, reduces the time cost incurred by recompiling the product's process source code, and makes fault injection testing more convenient and efficient. Developers can independently choose to perform fault injection on every potentially failing function in the product, including not only kernel calls in the system but also user-defined functions. This allows for coverage of a wider range of fault scenarios during the product development and testing phases to discover more potential problems and improve the product's robustness.

[0125] In one embodiment, this application provides a fault testing method. Referring to FIG10, the method may include steps 210 and 220, wherein:

[0126] Step 210: When the current process calls the target function, determine whether there is a target program corresponding to the current process among the faulty programs injected into the target function; the target program is used to process the input parameters or output parameters of the target function when the current process calls the target function;

[0127] Step 220: If it is determined that there is a target program corresponding to the current process, then the fault parameters are fed back to the current process. The fault parameters are the parameters obtained after the target function processes the input parameters or output parameters of the target function.

[0128] For the method of injecting the target program (faulty program), please refer to the limitation of the target function for injecting the faulty program in the above fault injection method embodiment, which will not be repeated here. When the product is executed by a computer device, if the target function is injected with a faulty program when the current process calls the target function, the faulty program will be executed, thereby modifying the input parameters and / or output parameters of the target function. The target function will feed back the erroneous parameters processed by the faulty program to the current process, thereby causing the parameters obtained by the current process to be faulty.

[0129] Figure 11 illustrates the process of injecting a fault into the target function and testing the current process using a fault injection procedure. The test suite sends a fault injection (modification) request to the fault injection manager. This request includes the PID of the injected process, the function signature of the injected fault, the fault injection method (input parameters or return value), and the injection strategy (single injection or permanent effect, etc.). Upon receiving the request, the fault injection manager (fault injector) converts it into an EBPF program (fault program) and calls the Clang compiler to compile it into an Elf format binary file. The compiled binary file (bytecode) is then mounted onto the corresponding function in Kprobe or Uprobe. The test suite sends a fault test request to the service under test (product). When the process under test calls the function of the fault-injected program, the fault program is executed, modifying the function's input parameters and return value to achieve the fault injection purpose. The test suite uses the service under test's response to determine whether the service under test can recover as expected after a fault occurs.

[0130] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0131] Based on the same inventive concept, this application also provides a fault injection apparatus for implementing the fault injection method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more fault injection apparatus embodiments provided below can be found in the limitations of the fault injection method described above, and will not be repeated here.

[0132] In an exemplary embodiment, as shown in FIG12, a fault injection device is provided, including a request acquisition module 1201, a program generation module 1202, and an injection module 1203, wherein:

[0133] The request acquisition module 1201 is used to acquire fault modification requests. The parameters of the fault modification request include at least the target signature, target identifier, fault type, modification content, and injection period.

[0134] Program generation module 1202 is used to call the fault injector to generate the fault program corresponding to the fault modification request;

[0135] The injection module 1203 is used to inject a fault program into the target function using a fault injector. When the target function is called by the target process, the fault program is used to process the input parameters and / or return parameters of the target function. The target function is the function corresponding to the target signature, and the target process is the service process corresponding to the target identifier.

[0136] In the aforementioned fault injection device, the fault injector generates a corresponding fault program based on the acquired fault modification request. The fault program is not inserted into the source code of the target process under test, but rather injected into the target function called by the target process. This allows the fault program to process the input and / or return parameters of the target function when it is called by the target process, resulting in incorrect parameters being returned to the target process, thus simulating a fault in the target process's operation. Furthermore, whenever the injected fault program needs modification, a fault modification request is input, causing the fault injector to generate a new fault program and inject it into the function called by the target process. This eliminates the need to readjust and recompile the source code of the target product, thereby improving the efficiency of fault testing.

[0137] In one embodiment, the program generation module 1202 is specifically used for:

[0138] The fault injector is invoked to match the parameters in the fault modification request and determine the corresponding program content for each parameter.

[0139] Fill the program content corresponding to each parameter into the program template to obtain the fault program corresponding to the fault modification request.

[0140] In one embodiment, the injection module 1203 is specifically used for:

[0141] The target compiler and target compilation type are determined based on at least one parameter in the fault modification request;

[0142] The faulty program is compiled based on the target compiler and target compilation type to obtain the compiled faulty bytecode;

[0143] A fault injector is used to inject faulty bytecode into the target function.

[0144] In one embodiment, the injection module 1203 is specifically used for:

[0145] Based on the target signature, determine the target address for storing the target function;

[0146] The fault bytecode is injected into the target function corresponding to the target address using a fault injector.

[0147] In one embodiment, the fault injection device further includes a fault clearing module, which is specifically used for:

[0148] Receive a fault clearing request. The parameters of the fault clearing request must include at least a clearing signature and a clearing identifier.

[0149] The fault injector is invoked, and the storage address of the function to be cleared is determined based on the clear signature. The function to be cleared is the function corresponding to the clear signature.

[0150] The program to be cleaned is determined based on the parameters in the cleanup request, and then deleted. The program to be cleaned includes at least one faulty program that has been injected with the function to be cleaned.

[0151] In one embodiment, the fault injection device further includes a monitoring module, which is specifically used for:

[0152] Receive query requests, and based on the query requests, obtain the status information of each injected fault program. The status information includes fault type, running status, and number of runs.

[0153] The status information of each injected fault program is sent to the target device.

[0154] Based on the same inventive concept, this application also provides a fault testing apparatus for implementing the fault testing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more fault testing apparatus embodiments provided below can be found in the limitations of the fault testing method described above, and will not be repeated here.

[0155] In an exemplary embodiment, as shown in FIG13, a fault testing apparatus is provided, including a determination module 1301 and a feedback module 1302, wherein:

[0156] The determination module 1301 is used to determine whether the target program corresponding to the current process exists among the faulty programs injected into the target function when the current process calls the target function; the target program is used to process the input parameters or output parameters of the target function when the current process calls the target function;

[0157] Feedback module 1302, if it is determined that there is a target program corresponding to the current process, will feed back the fault parameters to the current process. The fault parameters are the parameters obtained by the target program after processing the input parameters and / or output parameters of the target function.

[0158] Each module in the aforementioned fault injection device and fault testing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0159] In an exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as shown in Figure 14. The computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are connected to the system bus via the input / output interface. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface of the computer device is used for exchanging information between the processor and external devices. The communication interface of the computer device is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a fault injection method and / or a fault testing method. The display unit of the computer device is used to form a visually visible image and may be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0160] Those skilled in the art will understand that the structure shown in Figure 14 is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or may combine certain components, or may have different component arrangements.

[0161] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the fault injection method embodiment and / or fault testing method embodiment described above.

[0162] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the fault injection method embodiments and / or fault testing method embodiments described above.

[0163] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the fault injection method embodiments and / or fault testing method embodiments described above.

[0164] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0165] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0166] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0167] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A fault injection method, wherein, The method includes: Obtain a fault modification request, wherein the parameters of the fault modification request include at least the target signature, target identifier, fault type, modification content, and injection period; The fault injector is invoked to generate the fault program corresponding to the fault modification request. The fault injector is used to inject the fault program into the target function, wherein when the target function is called by the target process, the fault program is used to process the input parameters and / or return parameters of the target function; the target function is the function corresponding to the target signature, and the target process is the service process corresponding to the target identifier.

2. The method according to claim 1, wherein, The step of invoking the fault injector to generate the fault program corresponding to the fault modification request includes: The fault injector is invoked to match the parameters in the fault modification request and determine the program content corresponding to each parameter. Fill the program content corresponding to each of the parameters into the program template to obtain the fault program corresponding to the fault modification request.

3. The method according to claim 1, wherein, The step of injecting the fault program into the target function using the fault injector includes: The target compiler and target compilation type are determined based on at least one parameter in the fault modification request; The faulty program is compiled based on the target compiler and the target compilation type to obtain the compiled faulty bytecode; The fault bytecode is injected into the target function using the fault injector.

4. The method according to claim 3, wherein, The step of injecting the fault bytecode into the target function using the fault injector includes: Based on the target signature, determine the target address where the target function is stored; The fault bytecode is injected into the target function corresponding to the target address using the fault injector.

5. The method according to any one of claims 1-4, wherein, The method further includes: Receive a fault clearing request, wherein the parameters of the fault clearing request include at least a clearing signature and a clearing identifier; The fault injector is invoked to determine the storage address of the function to be cleared based on the clearing signature, wherein the function to be cleared is the function corresponding to the clearing signature; The program to be cleared is determined based on the parameters in the clearing request, and the program to be cleared is deleted. The program to be cleared includes at least one faulty program that has been injected with the function to be cleared.

6. The method according to claim 1, wherein, The method further includes: Receive a query request, and based on the query request, obtain the status information of each injected fault program, the status information including fault type, running status and running number; The status information of each injected fault program is sent to the target device.

7. A fault testing method, wherein, The method includes: When the current process calls the target function, it is determined whether the target program corresponding to the current process exists among the fault programs injected into the target function; the target program is used to process the input parameters or output parameters of the target function when the current process calls the target function; If it is determined that the target program corresponding to the current process exists, then the fault parameters are fed back to the current process. The fault parameters are the parameters obtained by the target program after processing the input parameters and / or output parameters of the target function.

8. A fault injection device, wherein, The device includes a request acquisition module, a program generation module, and an injection module, wherein: The request acquisition module is used to acquire fault modification requests. The parameters of the fault modification request include at least the target signature, target identifier, fault type, modification content, and injection period. The program generation module is used to call the fault injector to generate the fault program corresponding to the fault modification request; An injection module is used to inject the fault program into a target function using the fault injector, wherein when the target function is called by a target process, the fault program is used to process the input parameters and / or return parameters of the target function; the target function is the function corresponding to the target signature, and the target process is the service process corresponding to the target identifier.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, wherein, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images