CN117009252A - Fault injection testing method and device based on function replacement - Google Patents
Fault injection testing method and device based on function replacement Download PDFInfo
- Publication number
- CN117009252A CN117009252A CN202311285981.4A CN202311285981A CN117009252A CN 117009252 A CN117009252 A CN 117009252A CN 202311285981 A CN202311285981 A CN 202311285981A CN 117009252 A CN117009252 A CN 117009252A
- Authority
- CN
- China
- Prior art keywords
- function
- replaced
- fault
- code
- modified
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000002347 injection Methods 0.000 title claims abstract description 65
- 239000007924 injection Substances 0.000 title claims abstract description 65
- 238000012360 testing method Methods 0.000 title claims abstract description 36
- 238000000034 method Methods 0.000 claims abstract description 109
- 230000008569 process Effects 0.000 claims abstract description 66
- 230000006870 function Effects 0.000 claims description 348
- 230000004044 response Effects 0.000 claims description 36
- 230000003068 static effect Effects 0.000 claims description 23
- 238000004458 analytical method Methods 0.000 claims description 16
- 238000004590 computer program Methods 0.000 claims description 16
- 230000004048 modification Effects 0.000 claims description 6
- 238000012986 modification Methods 0.000 claims description 6
- 238000001514 detection method Methods 0.000 claims description 4
- 238000006467 substitution reaction Methods 0.000 claims description 2
- 238000010998 test method Methods 0.000 abstract description 8
- 238000010586 diagram Methods 0.000 description 11
- 230000001960 triggered effect Effects 0.000 description 9
- 230000006872 improvement Effects 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 7
- 238000012545 processing Methods 0.000 description 7
- 230000002159 abnormal effect Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 239000000243 solution Substances 0.000 description 3
- 230000005856 abnormality Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000003745 diagnosis Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000012216 screening Methods 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 229920001296 polysiloxane Polymers 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 239000010979 ruby Substances 0.000 description 1
- 229910001750 ruby Inorganic materials 0.000 description 1
- 238000013522 software testing Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
The description discloses a fault injection test method and device based on function replacement, which can acquire a code to be tested, determine a function call chain based on the code to be tested, determine a function to be replaced according to the function call chain, modify the function code of the function to be replaced to add the fault code to be injected into the function to be replaced to obtain a modified function, generate a dynamic link library corresponding to the modified function, further inject the dynamic link library into a process where the function to be replaced is located, replace the function to be replaced in the process with the modified function, finally trigger the modified function to complete fault triggering according to a preset triggering rule, complete fault injection test according to system related information obtained after the fault triggering, and achieve flexible and safe fault injection.
Description
Technical Field
The present disclosure relates to the field of software testing technologies, and in particular, to a fault injection testing method and apparatus based on function replacement.
Background
The fault injection test means of the current software system mainly comprises the following steps:
1. the fault injection system is deployed at the target server and is independent of the service system, and system level anomalies, including CPU high/memory leakage/network delay/disk write-full, etc., are injected by invoking operating system commands. The fault injection method has the problem of insufficient flexibility: system level failures are too extensive to simulate real application system anomalies such as specific process/component memory leaks, unreleased resources (excessive links, file handle occupation), etc.
2. The application system adds a fault use case library in the service source code before the deployment of the server, and triggers the fault to take effect through commands/messages when the service runs. The fault injection method has the following defects: the business system is required to be invaded, the codes of the business system are modified, a plurality of untriggered anomalies are buried, and the safety and the reliability are not enough. In addition, the method is not flexible enough, and if the fault use case library is to be modified, the service system needs to be redeployed.
Therefore, how to improve the flexibility and safety of fault injection is a problem to be solved.
Disclosure of Invention
The present disclosure provides a fault injection test method and device based on function replacement, so as to partially solve the above problems in the prior art.
The technical scheme adopted in the specification is as follows:
the specification provides a fault injection testing method based on function replacement, comprising the following steps:
acquiring a code to be tested, and determining a function call chain based on the code to be tested;
determining a function to be replaced according to the function call chain;
modifying the function code of the function to be replaced so as to add the fault code to be injected into the function to be replaced, obtaining a modified function, and generating a dynamic link library corresponding to the modified function;
injecting the dynamic link library into a process where the function to be replaced is located, so as to replace the function to be replaced in the process with the modified function;
and triggering the modified function to complete fault triggering in response to a preset triggering rule, and completing fault injection testing according to system related information obtained after the fault triggering, wherein the system related information at least comprises a system log and response information.
Optionally, determining a function call chain based on the code to be tested specifically includes:
and generating a static function call chain of the code to be tested through a Callgraph tool, and taking the static function call chain as the obtained function call chain.
Optionally, determining the function to be replaced according to the function call chain specifically includes:
determining each function in the function call chain;
and determining a function meeting preset conditions from the functions as a candidate function, wherein the preset conditions comprise: the function belongs to a user state function, the function does not belong to a multithreading function, and the function does not belong to at least one of a static function and a function contained in the static function;
and determining a function to be replaced from the candidate functions.
Optionally, the injecting the dynamic link library into the process where the function to be replaced is located specifically includes:
determining the process of the function to be replaced as a target process;
loading a process corresponding to the dynamic link library and distributing a memory space for the process corresponding to the dynamic link library;
acquiring an address corresponding to a function to be replaced in the target process and an address corresponding to the modified function in the process corresponding to the dynamic link library;
replacing the address corresponding to the function to be replaced in the register with the address corresponding to the modified function in the process corresponding to the dynamic link library;
the data and state of the register are saved to complete the injection.
Optionally, the triggering rule includes: and at least one of clicking a button in a service system corresponding to the code to be tested, inputting a preset instruction in a command line and sending a message in the service system.
Optionally, according to the system related information obtained after the fault triggering, the fault injection test is completed, which specifically comprises:
obtaining an error log in a system log, wherein the error log comprises a memory leakage log and a disk full log;
acquiring alarm information of the service system corresponding to the code to be tested for fault detection;
acquiring response information of the service system after different fault triggers, wherein the response corresponding to the response information comprises service timeout, a stuck phenomenon and system restarting;
performing phenomenon analysis through a diagnostic tool to obtain an analysis result;
and completing fault injection testing according to the error log, the alarm information, the response information and the analysis result.
Optionally, the method further comprises:
restoring the address corresponding to the function to be replaced in the register, and deleting the dynamic link library to restore the service system corresponding to the code to be tested.
The specification provides a fault injection testing device based on function replacement, which comprises:
The acquisition module is used for acquiring codes to be tested and determining a function call chain based on the codes to be tested;
the determining module is used for determining a function to be replaced according to the function call chain;
the modification module is used for modifying the function code of the function to be replaced so as to add the fault code to be injected into the function to be replaced, obtain a modified function and generate a dynamic link library corresponding to the modified function;
the injection module is used for injecting the dynamic link library into a process where the function to be replaced is located so as to replace the function to be replaced in the process with the modified function;
the triggering module is used for responding to a preset triggering rule, triggering the modified function to complete fault triggering, and completing fault injection testing according to system related information obtained after the fault triggering, wherein the system related information at least comprises a system log and response information.
The present specification provides a computer readable storage medium storing a computer program which when executed by a processor implements the above-described fault injection test method based on function replacement.
The present specification provides an electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the above-described fault injection test method based on function replacement when executing the program.
The above-mentioned at least one technical scheme that this specification adopted can reach following beneficial effect:
according to the fault injection test method based on function replacement, the method can acquire the code to be tested, determine a function call chain based on the code to be tested, determine a function to be replaced according to the function call chain, modify the function code of the function to be replaced to add the fault code to be injected into the function to be replaced to obtain a modified function, generate a dynamic link library corresponding to the modified function, further inject the dynamic link library into a process where the function to be replaced is located to replace the function to be replaced in the process with the modified function, finally trigger the modified function to complete fault triggering in response to a preset trigger rule, and complete fault injection test according to system related information obtained after the fault triggering, wherein the system related information at least comprises a system log and response information.
From the above, it can be seen that the method can determine the function of the fault code to be injected, and add the fault code, and then directly perform fault injection in a mode of generating a dynamic link library and injecting a corresponding process, compared with the prior art 1, the method can flexibly perform fault injection according to the required fault, and compared with the prior art 2, the method does not need to directly modify the service code of the service system, thereby achieving flexible and safe fault injection.
Drawings
The accompanying drawings, which are included to provide a further understanding of the specification, illustrate and explain the exemplary embodiments of the present specification and their description, are not intended to limit the specification unduly. In the drawings:
FIG. 1 is a schematic flow chart of a fault injection testing method based on function replacement provided in the present specification;
FIG. 2 is a schematic flow chart of selecting a function to be replaced according to the present disclosure;
FIG. 3 is a schematic diagram of a function call chain provided herein;
FIG. 4 is a schematic flow chart of injecting a dynamic link library provided in the present specification;
FIG. 5 is a schematic diagram of a fault injection testing device based on function replacement provided in the present specification;
Fig. 6 is a schematic view of the electronic device corresponding to fig. 1 provided in the present specification.
Detailed Description
For the purposes of making the objects, technical solutions and advantages of the present specification more apparent, the technical solutions of the present specification will be clearly and completely described below with reference to specific embodiments of the present specification and corresponding drawings. It will be apparent that the described embodiments are only some, but not all, of the embodiments of the present specification. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.
The following describes in detail the technical solutions provided by the embodiments of the present specification with reference to the accompanying drawings.
Fig. 1 is a schematic flow chart of a fault injection testing method based on function replacement provided in the present specification, which specifically includes the following steps:
s100: and acquiring the code to be tested, and determining a function call chain based on the code to be tested.
S102: and determining the function to be replaced according to the function call chain.
The fault injection test method based on function replacement in the specification can be applied to the scene of fault injection test.
First, the server may obtain the code to be tested and determine a function call chain based on the code to be tested.
Each service and function of the application program is composed of a plurality of function call chains, when the function is replaced, if a certain function in the call chain can be reserved with an original code and a fault code (the code which can simulate the fault in the running process) is inserted, the function of the original function is not destroyed when the program actually runs, the abnormal phenomenon of the service can be rapidly simulated, and the fault processing capability of the application program can be tested.
Fig. 2 is a schematic flow chart of selecting a function to be replaced provided in the present specification.
Thus, as shown in FIG. 2, a function call chain may be determined and a function that needs replacement may be selected, including the steps of:
s201: a chain of function calls for a module is generated.
S202: and (5) function screening.
S203: business impact analysis.
The code to be tested can be a code corresponding to a set of developed service system, at this time, a function call chain of the code to be tested (which can be a function call chain of a module needing fault injection test) can be determined by a static analysis mode, specifically, the static function call chain of the code to be tested can be generated through a Callgraph tool and used as the obtained function call chain.
The tool may specify a certain file or list of functions and specify the depth of function call to filter the results. A function calls another function, a plurality of functions are combined together to form a function call chain display, for example, function FuncA calls function FuncB, the display is FuncA- > FuncB, function FuncB calls function FuncC, the display is FuncB- > FuncC, and the function call chain is FuncA- > FuncB- > FuncC.
The static function call chain generated by the Callgraph tool for a directory may be as shown in fig. 2.
Fig. 3 is a schematic diagram of a function call chain provided in the present specification.
Different function call chains, such as the two call chains, can be analyzed from the function call graph illustrated in fig. 3: 1. a- > B- > C- > D- > E,2, A- > B- > G- > D- > E.
And then, determining the function to be replaced according to the determined function call chain. Each function in the function call chain can be determined, and a function meeting a preset condition is determined from each function and used as a candidate function, wherein the preset condition comprises: the function belongs to a user state function, the function does not belong to a multithreading function, and the function does not belong to at least one of a static function and a function contained in the static function, and then a function to be replaced can be determined from the candidate functions.
That is, function screening mainly considers these three aspects:
1. user state and kernel state functions.
The functions of each function call chain include these two classes: the method mainly considers the influence of the user mode function on the service program, and therefore, the system function such as D, E, H, L, M is not considered for function replacement.
2. Multithreading effects.
Function execution requires data and code, the data including function arguments, local variables, global variables, static local variables, etc. Some data is stored in the stack space of the threads, such as the shape parameters and the local variables, and the stack space of each thread is independent under the multithreading condition, so that function call is not affected. While some data is stored in a process heap memory, such as a global variable, and heap memory head addresses of the global variable are accessed together under a multithreading condition, a security problem exists, and although the problem is solved when a mutual exclusion lock is introduced, if a function under the multithreading is replaced, abnormal execution of the replaced function after locking is easily caused to cause lock waiting and deadlock.
The codes of the functions are stored in a common space and shared by all threads, when the functions under the multithreading are replaced, a part of threads execute old functions, and a part of threads execute new functions, so that the inconsistent local variables can cause unpredictable logic problems on the premise of not performing atomic operations.
In summary, from the aspects of data and code, a function under multi-thread execution cannot be selected for replacement, a multi-thread function mark is created through a pthread_create system function, and a parameter specifies a called function name during creation, and the function is a multi-thread function.
3. Static functions and functions within static functions.
The scope of a static function is limited to only the files that state it, its internal function address is invisible and cannot be referenced by other files, so that function replacement cannot take into account the static function and its internal functions.
S104: and modifying the function code of the function to be replaced so as to add the fault code to be injected into the function to be replaced, obtaining a modified function, and generating a dynamic link library corresponding to the modified function.
After the function to be replaced is determined, the function code of the function to be replaced can be modified, so that the fault code to be injected is added into the function to be replaced, a modified function is obtained, and a dynamic link library corresponding to the modified function is generated.
After determining the function to be replaced, a developer can manually modify the function code of the function to be replaced (certainly, the modified function can be automatically obtained by receiving the fault code to be injected), the modified function is stored locally, and then the server can generate a dynamic link library corresponding to the modified function.
The modification of the function code of the function to be replaced to obtain a modified function does not refer to directly modifying the original function to be replaced, but refers to obtaining the function code of the function to be replaced, and adding a fault code into the function code of the function to be replaced to obtain a modified function, that is, the modified function is another function except the function to be replaced, and the original function to be replaced still exists, so that the dynamic link library corresponding to the modified function is conveniently deleted later, and the service system corresponding to the code to be tested is restored.
(1) Writing a modified function for replacing a function to be replaced
Assuming that the function to be replaced is named original_func, the modified function is replaced_func.
The original_func code is exemplified as follows:
int original_func(int a, const char *b){
the// code omitting
...
return 0;
}
Assuming the injected fault is a simulated traffic memory leak, the modified function code is exemplified as follows:
int replaced_func(int a, const char *b){
The// original code remains unchanged
...
Code for adding memory leaks under/
char *temp = (char *)malloc(300* sizeof(char));
temp = b;
return 0;
}
After modification, a 300 byte memory is applied for in the function replaced_func, the memory address is transmitted to the pointer temp, and then the pointer temp points to b again until the function is finished. This results in a 300 byte memory address that has no pointer to it, cannot be retrieved, cannot free the memory address, and causes memory leaks. Each time the function is called, it causes a 300 byte memory leak, and this value can be changed according to the actual test requirements.
(2) Making dynamic link libraries
The dynamic link library is a.so file, which contains modified functions (including trigger fault codes) and can be compiled by gcc (linux c language compiler) to generate the dynamic link library.
Assuming that the file name of the function original_func is func_rep.c, the compilation command is as follows, and a library of libload.so dynamic links can be generated:
“gcc func_rep.c -shared -fPIC -o libload.so”
s106: and injecting the dynamic link library into a process where the function to be replaced is located, so as to replace the function to be replaced in the process with the modified function.
And then, the obtained dynamic link library corresponding to the modified function can be injected into the process where the function to be replaced is located, so that the function to be replaced in the process is replaced by the modified function.
The process where the function to be replaced is located can be determined as a target process, then, a process corresponding to a dynamic link library (including a modified function) can be loaded, a memory space is allocated for the process corresponding to the dynamic link library, then, an address corresponding to the function to be replaced in the target process and an address corresponding to the modified function in the process corresponding to the dynamic link library are obtained, finally, the address corresponding to the function to be replaced in the register (i.e. the super start address) can be replaced with the address corresponding to the modified function in the process corresponding to the dynamic link library, and the data and the state of the register are saved to complete injection.
Fig. 4 is a schematic flow chart of injecting a dynamic link library provided in the present specification.
The flow of injecting the dynamic link library can be as shown in fig. 4, and the detailed procedure of the steps is as follows:
s401: the process of the target function original_func is confirmed, and the process is instructed through gdb (debugging tool): the info original_func checks to see if the function exists in the process, and records the process number pid.
S402: the libload. So (i.e. the dynamically linked library file) process is loaded via the system interface ptrace and the system interface mmap is called to allocate memory space, so that the functions in the libload. So can be accessed via addresses.
S403: the addresses of these two functions are obtained through the system interface dlsym: original_func and replaced_func.
S404: the original_func function superstart address is replaced with the replaced_func function address in the register, modifying the machine instruction to jmp.
S405: register data and state are saved, and the injection process is ended.
The functions of the system interfaces are attached here as shown in table 1.
TABLE 1
S108: and triggering the modified function to complete fault triggering in response to a preset triggering rule, and completing fault injection test according to system related information obtained after the fault triggering, wherein the system related information at least comprises a system log and response information.
After the injection is completed, the server can respond to a preset triggering rule to trigger the modified function to complete fault triggering, and fault injection testing can be completed according to system related information obtained after the fault triggering, wherein the system related information at least comprises a system log and response information.
It should be noted that, the triggering rule may include: the service system corresponding to the code to be tested can be deployed in the server, after the triggering rule corresponding to the modified function is generated in the server, the server triggers the modified function, namely the fault code in the modified function can be triggered.
Wherein, according to the function call chain, a triggering rule, such as button clicking, command line, message, etc., capable of triggering the function call of the modified function can be found.
If the function replacement is not performed in the manner provided in the present specification, the execution to the original function code is performed when the code is executed, and after the injection of the dynamic link library is performed by the method, the execution will jump to the replaced_func function to be performed when the execution to the original_func function is performed.
That is, after the function is replaced, when the original_func function is called, the function head address operator is replaced, and the function head address operator directly jumps to the replaced_func function to be executed, at this time, the fault code in the replaced_func is triggered, and at this time, the exception can be quickly injected into the system. In some scenes needing to repeatedly inject the abnormality, such as memory leakage, resource occupation, and the like, the corresponding triggering rule can be triggered for a plurality of times, such as clicking a button for triggering the abnormality for a plurality of times.
After the fault is triggered, the fault injection test can be completed according to the system related information obtained after the fault is triggered, wherein the system related information at least comprises a system log and response information.
Specifically, an error log in the system log can be obtained, including a memory leakage log, a disk full log and the like, alarm information of the service system corresponding to the code to be tested for fault detection is obtained, response information of the service system after different faults are triggered is obtained, the response corresponding to the response information includes service timeout, a stuck phenomenon, system restarting and the like, and the phenomenon analysis can be performed through a diagnostic tool to obtain an analysis result, so that fault injection test can be completed according to the error log, the alarm information, the response information and the analysis result.
That is, after the fault is triggered, it may be determined whether the fault injection is successful or not and whether the service system has correctly responded to the injected fault through an error log, alarm information, response information, analysis results obtained by a diagnostic tool, and the like of the service system.
That is, after fault triggering, according to the fault type, the system can be observed, analyzed and detected in a targeted manner, and the system can comprise the following four points:
(1) The error log is checked. For example, when the replaced_func function is executed once, memory leakage occurs, and memory overflow occurs to a certain extent, and at this time, an abnormal error log is generated in the system application memory, namely java.
(2) The business system is checked for reaction to the fault. If the service system detects and alarms for some faults, checking whether the alarm information is consistent with the fault phenomenon or not, wherein the faults comprise: disk space, memory space, cpu, etc.
In this embodiment, there is a memory leak, and there is an alarm of insufficient memory space and an alarm of high CPU.
(3) The service response is checked. And checking whether the response (such as slow service response, restarting, capacity expansion and the like) of the service after different fault triggers is consistent with the expected response result. In this example, memory leakage occurs, which affects the response time of the service function, and the phenomenon of stuck and overtime occurs.
(4) System analysis, diagnosis and recording. Some phenomena after the fault triggering are not easy to visually see, and whether the fault is successfully injected or not needs to be judged through a diagnosis tool or a diagnosis program, such as network packet loss, database table lock timeout and the like.
It should be noted that, after the fault injection test is completed, the method can conveniently restore the service system corresponding to the code to be tested to the original state, that is, to the state before the fault injection test, that is, the address corresponding to the function to be replaced in the register can be restored, the state data of the register can be restored, and the dynamic link library can be directly deleted, so as to restore the service system corresponding to the code to be tested.
When the dynamic link library is loaded, the original function information is recorded, the address of the recorded instruction in the register is restored to the original data by the same method, and the process does not load the dynamic link library any more.
For convenience of description, the execution body for executing the method will be described as a server, and the execution body may be a desktop computer, a server, a large-sized service platform, or the like, which is not limited herein.
Compared with other fault injection testing methods, the embodiment of the invention has the following advantages:
fault injection is carried out based on the service system and the scene, and the process and the components acting on the service system can accurately simulate real service scene anomalies, and the anomalies are more real and accurate compared with system-level anomalies injected by other faults;
compared with the method that a fault use case library is added in a service source code before an application system is deployed in a server, and a fault is triggered to take effect through a command/message when the service is operated, the method has the advantages of not immersing and restarting the service system, functions are dynamically replaced when the service system is operated normally, fault code injection is completed, faults are triggered at any time according to requirements, in addition, the recovery of the faults is very convenient, only the address of the replacement function is rewritten to the address of the original function, the operation of the service is not influenced, and the fault injection mode has the characteristics of safety and flexibility;
Compared with the technology of dynamically replacing byte codes, the technology of dynamically replacing the byte code by rewriting a process class byte code file through a JVM interface, has a plurality of limitations, does not allow member variables and methods, does not allow the attribute of a class to be changed, does not allow the creation of an object, and can only call a static method.
The foregoing provides a fault injection testing method based on function replacement for one or more embodiments of the present specification, and based on the same thought, the present specification also provides a fault injection testing device based on function replacement, as shown in fig. 5.
FIG. 5 is a schematic diagram of a fault injection testing apparatus based on function replacement provided in the present specification, including;
the acquiring module 501 is configured to acquire a code to be tested, and determine a function call chain based on the code to be tested;
a determining module 502, configured to determine a function to be replaced according to the function call chain;
a modifying module 503, configured to modify a function code of the function to be replaced, so as to add a fault code to be injected into the function to be replaced, obtain a modified function, and generate a dynamic link library corresponding to the modified function;
An injection module 504, configured to inject the dynamic link library into a process where the function to be replaced is located, so as to replace the function to be replaced in the process with the modified function;
the triggering module 505 is configured to trigger the modified function to complete fault triggering in response to a preset triggering rule, and complete fault injection testing according to system related information obtained after fault triggering, where the system related information at least includes a system log and response information.
Optionally, the obtaining module 501 is specifically configured to generate, by using a Callgraph tool, a static function call chain of the code to be tested, as the obtained function call chain.
Optionally, the determining module 502 is specifically configured to determine each function in the function call chain; and determining a function meeting preset conditions from the functions as a candidate function, wherein the preset conditions comprise: the function belongs to a user state function, the function does not belong to a multithreading function, and the function does not belong to at least one of a static function and a function contained in the static function; and determining a function to be replaced from the candidate functions.
Optionally, the injecting module 504 is specifically configured to determine a process where the function to be replaced is located, as a target process; loading a process corresponding to the dynamic link library and distributing a memory space for the process corresponding to the dynamic link library; acquiring an address corresponding to a function to be replaced in the target process and an address corresponding to the modified function in the process corresponding to the dynamic link library; replacing the address corresponding to the function to be replaced in the register with the address corresponding to the modified function in the process corresponding to the dynamic link library; the data and state of the register are saved to complete the injection.
Optionally, the triggering rule includes: and at least one of clicking a button in a service system corresponding to the code to be tested, inputting a preset instruction in a command line and sending a message in the service system.
Optionally, the triggering module 505 is specifically configured to obtain an error log in the system log, including a memory leakage log and a disk full log; acquiring alarm information of the service system corresponding to the code to be tested for fault detection; acquiring response information of the service system after different fault triggers, wherein the response corresponding to the response information comprises service timeout, a stuck phenomenon and system restarting; performing phenomenon analysis through a diagnostic tool to obtain an analysis result; and completing fault injection testing according to the error log, the alarm information, the response information and the analysis result.
Optionally, the apparatus further comprises:
and the restoring module 506 is configured to restore the address corresponding to the function to be replaced in the register, and delete the dynamic link library to restore the service system corresponding to the code to be tested.
The present specification also provides a computer readable storage medium storing a computer program operable to perform the above-described fault injection test method based on function replacement.
The present specification also provides a schematic structural diagram of the electronic device shown in fig. 6. At the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile storage, as illustrated in fig. 6, although other hardware required by other services may be included. The processor reads the corresponding computer program from the nonvolatile memory to the memory and then runs the computer program to realize the fault injection test method based on function replacement.
Of course, other implementations, such as logic devices or combinations of hardware and software, are not excluded from the present description, that is, the execution subject of the following processing flows is not limited to each logic unit, but may be hardware or logic devices.
In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of each element may be implemented in one or more software and/or hardware elements when implemented in the present specification.
It will be appreciated by those skilled in the art that embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the present specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
The present description is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the specification. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.
It will be appreciated by those skilled in the art that embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the present specification may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
The description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments.
The foregoing is merely exemplary of the present disclosure and is not intended to limit the disclosure. Various modifications and alterations to this specification will become apparent to those skilled in the art. Any modifications, equivalent substitutions, improvements, or the like, which are within the spirit and principles of the present description, are intended to be included within the scope of the claims of the present description.
Claims (10)
1. A fault injection testing method based on function replacement, comprising:
acquiring a code to be tested, and determining a function call chain based on the code to be tested;
determining a function to be replaced according to the function call chain;
modifying the function code of the function to be replaced so as to add the fault code to be injected into the function to be replaced, obtaining a modified function, and generating a dynamic link library corresponding to the modified function;
injecting the dynamic link library into a process where the function to be replaced is located, so as to replace the function to be replaced in the process with the modified function;
and triggering the modified function to complete fault triggering in response to a preset triggering rule, and completing fault injection testing according to system related information obtained after the fault triggering, wherein the system related information at least comprises a system log and response information.
2. The method of claim 1, wherein determining a function call chain based on the code to be tested, comprises:
and generating a static function call chain of the code to be tested through a Callgraph tool, and taking the static function call chain as the obtained function call chain.
3. The method according to claim 1, wherein determining a function to be replaced from the function call chain comprises:
determining each function in the function call chain;
and determining a function meeting preset conditions from the functions as a candidate function, wherein the preset conditions comprise: the function belongs to a user state function, the function does not belong to a multithreading function, and the function does not belong to at least one of a static function and a function contained in the static function;
and determining a function to be replaced from the candidate functions.
4. The method of claim 1, wherein the injecting the dynamic link library into the process in which the function to be replaced is located specifically comprises:
determining the process of the function to be replaced as a target process;
loading a process corresponding to the dynamic link library and distributing a memory space for the process corresponding to the dynamic link library;
acquiring an address corresponding to a function to be replaced in the target process and an address corresponding to the modified function in the process corresponding to the dynamic link library;
replacing the address corresponding to the function to be replaced in the register with the address corresponding to the modified function in the process corresponding to the dynamic link library;
The data and state of the register are saved to complete the injection.
5. The method of claim 1, wherein the triggering rule comprises: and at least one of clicking a button in a service system corresponding to the code to be tested, inputting a preset instruction in a command line and sending a message in the service system.
6. The method of claim 1, wherein the fault injection test is completed according to the system related information obtained after the fault triggering, and specifically comprises:
obtaining an error log in a system log, wherein the error log comprises a memory leakage log and a disk full log;
acquiring alarm information of the service system corresponding to the code to be tested for fault detection;
acquiring response information of the service system after different fault triggers, wherein the response corresponding to the response information comprises service timeout, a stuck phenomenon and system restarting;
performing phenomenon analysis through a diagnostic tool to obtain an analysis result;
and completing fault injection testing according to the error log, the alarm information, the response information and the analysis result.
7. The method of claim 4, wherein the method further comprises:
Restoring the address corresponding to the function to be replaced in the register, and deleting the dynamic link library to restore the service system corresponding to the code to be tested.
8. A function substitution-based fault injection testing device, comprising:
the acquisition module is used for acquiring codes to be tested and determining a function call chain based on the codes to be tested;
the determining module is used for determining a function to be replaced according to the function call chain;
the modification module is used for modifying the function code of the function to be replaced so as to add the fault code to be injected into the function to be replaced, obtain a modified function and generate a dynamic link library corresponding to the modified function;
the injection module is used for injecting the dynamic link library into a process where the function to be replaced is located so as to replace the function to be replaced in the process with the modified function;
the triggering module is used for responding to a preset triggering rule, triggering the modified function to complete fault triggering, and completing fault injection testing according to system related information obtained after the fault triggering, wherein the system related information at least comprises a system log and response information.
9. A computer readable storage medium, characterized in that the storage medium stores a computer program which, when executed by a processor, implements the method of any of the preceding claims 1-7.
10. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the method of any of the preceding claims 1-7 when executing the program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311285981.4A CN117009252B (en) | 2023-10-07 | 2023-10-07 | Fault injection testing method and device based on function replacement |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311285981.4A CN117009252B (en) | 2023-10-07 | 2023-10-07 | Fault injection testing method and device based on function replacement |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117009252A true CN117009252A (en) | 2023-11-07 |
| CN117009252B CN117009252B (en) | 2024-01-02 |
Family
ID=88574741
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311285981.4A Active CN117009252B (en) | 2023-10-07 | 2023-10-07 | Fault injection testing method and device based on function replacement |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117009252B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117312040A (en) * | 2023-11-08 | 2023-12-29 | 之江实验室 | Remote self-service maintenance method and device for equipment, storage medium and equipment |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070136811A1 (en) * | 2005-12-12 | 2007-06-14 | David Gruzman | System and method for inspecting dynamically generated executable code |
| US7757215B1 (en) * | 2006-04-11 | 2010-07-13 | Oracle America, Inc. | Dynamic fault injection during code-testing using a dynamic tracing framework |
| CN105550080A (en) * | 2015-11-26 | 2016-05-04 | 广州华多网络科技有限公司 | Method, apparatus and system for performing server program fault injection based on Linux |
| CN105653979A (en) * | 2015-12-29 | 2016-06-08 | 银江股份有限公司 | Code injection based privacy information protection method |
| CN108614764A (en) * | 2016-12-12 | 2018-10-02 | 中国航空工业集团公司西安航空计算技术研究所 | IMA application software fault filling methods |
| CN110262972A (en) * | 2019-06-17 | 2019-09-20 | 中国科学院软件研究所 | A kind of failure testing tool and method towards micro services application |
| CN112714015A (en) * | 2020-12-23 | 2021-04-27 | 上海科梁信息工程股份有限公司 | Communication data fault injection method and system, communication device and storage medium |
| CN114064114A (en) * | 2021-11-19 | 2022-02-18 | 云控智行科技有限公司 | Dynamic library generation method and device |
| CN114691504A (en) * | 2022-03-28 | 2022-07-01 | 北京交通大学 | Fault injection method based on call instruction replacement |
-
2023
- 2023-10-07 CN CN202311285981.4A patent/CN117009252B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070136811A1 (en) * | 2005-12-12 | 2007-06-14 | David Gruzman | System and method for inspecting dynamically generated executable code |
| US7757215B1 (en) * | 2006-04-11 | 2010-07-13 | Oracle America, Inc. | Dynamic fault injection during code-testing using a dynamic tracing framework |
| CN105550080A (en) * | 2015-11-26 | 2016-05-04 | 广州华多网络科技有限公司 | Method, apparatus and system for performing server program fault injection based on Linux |
| CN105653979A (en) * | 2015-12-29 | 2016-06-08 | 银江股份有限公司 | Code injection based privacy information protection method |
| CN108614764A (en) * | 2016-12-12 | 2018-10-02 | 中国航空工业集团公司西安航空计算技术研究所 | IMA application software fault filling methods |
| CN110262972A (en) * | 2019-06-17 | 2019-09-20 | 中国科学院软件研究所 | A kind of failure testing tool and method towards micro services application |
| CN112714015A (en) * | 2020-12-23 | 2021-04-27 | 上海科梁信息工程股份有限公司 | Communication data fault injection method and system, communication device and storage medium |
| CN114064114A (en) * | 2021-11-19 | 2022-02-18 | 云控智行科技有限公司 | Dynamic library generation method and device |
| CN114691504A (en) * | 2022-03-28 | 2022-07-01 | 北京交通大学 | Fault injection method based on call instruction replacement |
Non-Patent Citations (4)
| Title |
|---|
| BARAZA J C 等: "Enhancement of fault injection techniques based on the modification of VHDL code", IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION SYSTEMS * |
| 史毅龙;薛长斌;: "基于"龙芯"的VxWorks系统函数在轨更新研究", 电子设计工程, no. 21 * |
| 朱晓燕;吴际;尚会波;: "模型驱动的VxWorks操作系统故障注入与鲁棒性测试研究", 科研信息化技术与应用, no. 03 * |
| 陈隽;蔡金燕;李刚;: "基于Pspice的电路仿真故障注入的方法研究", 信息技术, no. 01 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117312040A (en) * | 2023-11-08 | 2023-12-29 | 之江实验室 | Remote self-service maintenance method and device for equipment, storage medium and equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN117009252B (en) | 2024-01-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110554965B (en) | Automated fuzz testing method, related equipment and computer readable storage medium | |
| Yan et al. | Systematic testing for resource leaks in Android applications | |
| CN100547562C (en) | The method and system of the unit testing use-case of problem when generation can be reproduced operation automatically | |
| US8121824B2 (en) | Predicate checking for distributed systems | |
| CN117009252B (en) | Fault injection testing method and device based on function replacement | |
| CN106909498B (en) | Method and system for injecting fault into Java program | |
| CN110879781B (en) | Program debugging method, device, electronic equipment and computer readable storage medium | |
| TWI684916B (en) | Function selection method and server | |
| US20170075789A1 (en) | Method and apparatus for generating, capturing, storing, and loading debug information for failed tests scripts | |
| CN110928777B (en) | Test case processing method, device, equipment and storage medium | |
| CN114327776A (en) | Debugging method, debugging equipment and debugging system for intelligent contract | |
| Xie et al. | Automatic extraction of object-oriented observer abstractions from unit-test executions | |
| Farooq et al. | Livedroid: Identifying and preserving mobile app state in volatile runtime environments | |
| CN114840426A (en) | Code testing method and device | |
| Jiang et al. | Retestdroid: towards safer regression test selection for android application | |
| CN110765008B (en) | Data processing method and device | |
| CN116048977B (en) | Test method and device based on data reduction | |
| EP3921734A1 (en) | Using historic execution data to visualize tracepoints | |
| Toffalini et al. | Practical static analysis of context leaks in Android applications | |
| Tsai et al. | Low-overhead run-time memory leak detection and recovery | |
| Toffalini et al. | Static analysis of context leaks in android applications | |
| CN112015658A (en) | Method and device for generating software integration test case | |
| Jain et al. | Memory leakage testing using aspects | |
| CN117421208A (en) | Method, device, storage medium and equipment for determining unique page identifier | |
| Davydov | Detecting Memory Leaks in Long-Running Applications |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |