CN109669866B - Method for acquiring fault propagation path during software operation - Google Patents
Method for acquiring fault propagation path during software operation Download PDFInfo
- Publication number
- CN109669866B CN109669866B CN201811503761.3A CN201811503761A CN109669866B CN 109669866 B CN109669866 B CN 109669866B CN 201811503761 A CN201811503761 A CN 201811503761A CN 109669866 B CN109669866 B CN 109669866B
- Authority
- CN
- China
- Prior art keywords
- fault
- software
- function
- path
- propagation path
- 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.)
- Active
Links
Images
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/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
-
- 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/362—Software debugging
- G06F11/366—Software debugging using diagnostics
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)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a method for acquiring a fault propagation path during software operation, which comprises the following steps: step one, data collection during dynamic software runtime, specifically comprising: determining the type of data to be collected; performing code instrumentation on target software; monitoring and recording data during program operation; step two, a fault propagation path obtaining method based on data comparison and analysis specifically comprises the following steps: preprocessing data; and obtaining a fault propagation path by comparing and analyzing the data. The method can acquire the fault propagation path of the C language program in fault operation in the Linux environment. The method can help a software engineer to quickly and accurately locate the software fault by taking the path as a clue, thereby reducing the maintenance cost; by integrating analysis of a plurality of fault propagation paths of the same program, the module position of the program, which is easy to generate faults, can be obtained, a software engineer is facilitated to improve an error-prone module, and the software reliability is improved; the monitoring of the dynamic operation of the software can also provide the software with a failure warning function.
Description
Technical Field
The invention provides a method for acquiring a fault propagation path during software operation so as to improve software reliability, and belongs to the technical field of software maintenance.
Background
With the rapid development of computer and network technologies, the requirements of people on software functions and performances are increasingly improved, the software structure is increasingly complicated, and the formation of complex software-intensive systems is promoted. Such software systems often have complex internal logic, frequent information interaction between software and hardware, long service life, and correspondingly increased complexity of software faults. How to ensure the reliability of the operation of the complex system software becomes a hot problem in current research.
Researchers in the field of software engineering believe that errors introduced into a software product by the software development process are the root cause of software failures, and the failure eventually requires the propagation of a fault. The fault generated by the preorder software module is propagated through the connection with the subsequent software module, and finally the software is caused to generate the fault, and the process is the software fault propagation behavior.
Based on the software fault propagation path, a software developer can quickly locate the occurrence position of the fault, eliminate the fault and reduce software errors. In the software reliability design process, the software fault propagation path is analyzed, the software fault propagation path can be obtained, weak links of a complex software system are obtained, the software reliability design is improved, and prevention and early warning measures can be taken on faults in the propagation path.
The existing software fault technology at the code level is mainly used for positioning software faults and does not provide a path for propagating the software faults. Compared with fault positioning, the fault propagation path can better reflect the structure of software and the fault occurrence process, and can also position a faulted software module, strengthen weak modules which are easy to fault, help designers to improve the software structure design, and reduce the fault propagation behavior which may occur in the software use stage, thereby reducing the possible fault propagation influence, improving the software reliability design, and improving the software reliability level.
Disclosure of Invention
The invention aims to provide a method for acquiring a fault propagation path during software operation, which aims to solve the problems that the prior art lacks of research on the fault propagation path of the software and the like.
In the past research work on software reliability, the failures among software modules are assumed to be independent, and the failures of the software modules cause the failures of a system. But the real situation is: software errors can cause local failures, and software component failures never occur independently. As shown in fig. 1, a fault in a single component may affect a component with which the component has an interaction relationship, that is, a fault occurring in an upper component may be transferred to a lower component through an interface, and the lower component may transfer an error to a lower level after receiving an erroneous input, and may also hide the input error to generate a correct output; this transfer may continue through the output phase of the system or may stop in the middle (due to error recognition and recovery mechanisms present inside the components), which is the mechanism by which software failures propagate.
The invention mainly takes a C/C + + software program under Linux as an object (using a GCC compiler), and provides a method for acquiring a fault propagation path during software operation. The overall idea of the invention is as follows: collecting parameters related to fault propagation under two states of normal operation and fault injection, and providing a data comparison algorithm to analyze and process the collected data to finally obtain a fault propagation path.
The invention discloses a method for acquiring a fault propagation path during software operation, which comprises the following specific steps:
step one, collecting data during dynamic software runtime
S1.1, determining the type of data to be collected
Under Linux, the gdb debugger acquires register information, stack information, memory information and disassembling information through commands; the parameter entering, parameter exiting and return values can be obtained in a gdb debugger mode;
and (3) carrying out static analysis on the code to be monitored by using an SrcML static analysis tool, extracting a global variable name in an output xml file in a character retrieval mode, and further directly monitoring a corresponding global variable value in a gdb debugger.
S1.2, code instrumentation is carried out on target software
And marking the function inlet and outlet by using the pile inserting function of the gcc compiler, and adding breakpoints to the function inlet and outlet through the gdb debugger, so that variable information can be output in the running process.
S1.3, monitoring data and recording during program operation
Writing a gdb file, writing a breakpoint setting statement and a monitoring statement into the gdb file, performing stepping debugging, outputting display contents into a text document, and adding logic to enable the display contents to be output until the program is finished when running is terminated.
And compiling a shell script file, and writing the processes of compiling a pile inserting hook function by gcc and running gdb into an executable program, so that automation of pile inserting, monitoring and outputting can be realized.
Step two, fault propagation path obtaining method based on data comparison and analysis
S2.1, preprocessing data
Extracting key information of the data obtained in the previous step by using a character matching method; and the matched information is stored in the array in a nested array form, so that the final processing is facilitated.
S2.2, obtaining a fault propagation path by comparing and analyzing data
For the same function module, under the premise of the same input, the output is the same in theory no matter how many times the function module runs; based on this assumption, the output file obtained by inputting the normal test case is compared with the output file obtained by inputting the fault test case, and then the different part of the fault output relative to the normal output is the part through which the fault passes. Analyzing the output file, extracting the function names and the in-out labels in the array of the parts to obtain an execution path in a normal state and an execution path in a fault state, and extracting the part with parameter change in the path to obtain a fault propagation path.
Three changes of the execution path in the fault state are as follows: (1) the execution paths are completely the same, and the parameters in the paths are not changed; (2) the execution path is branched; (3) partial additions, deletions or substitutions of execution paths occur.
The method for acquiring the fault propagation path comprises the following steps:
s2.2.1, numbering the repeatedly called functions in consideration of the repeated calling condition, wherein the function is the called number of times, namely the function label; for the output file obtained in the step of preprocessing the data S2.1, respectively traversing the function names and the in-out labels of the two parameter arrays in the normal state and the fault state, numbering the function module names which are called for many times, and respectively labeling the function module names according to the sequence;
s2.2.2, taking the execution path in the normal state as a reference, corresponding each function module of the execution path in the fault state to the reference one by one, and recording the array position where the function name and the in-out label completely accord with each other, namely the marker post;
s2.2.3, according to the above array position, comparing the corresponding parameters of the normal state parameter array and the fault state parameter array, finding out the function module position where different parameters appear for the first time, namely the starting point of the fault propagation path.
S2.2.4, using the first changed function module as the starting point of the fault propagation path, then using each function module as the same as the execution path in the normal state as the mark post, if there is no other function module between the mark posts, directly connecting in sequence according to the path, if there is a function module different from the normal execution path between the mark posts, connecting the function modules between the mark posts in the execution sequence in the fault execution path, and finally connecting to the ending module of the fault execution path.
The invention discloses a method for acquiring a fault propagation path during software operation, which has the advantages and effects that: by applying the method, the fault propagation path of the C language program during fault operation can be acquired in the Linux environment. Compared with pure fault positioning and acquisition of a fault propagation path, the method can help a software engineer to quickly and accurately position the position of the software fault by taking the path as a clue, and reduce the maintenance cost; by integrating analysis of a plurality of fault propagation paths of the same program, the module position of the program, which is easy to generate faults, can be obtained, a software engineer is facilitated to improve an error-prone module, and the software reliability is improved; the monitoring of the dynamic operation of the software can also provide the software with a failure warning function.
Drawings
FIG. 1 is a schematic diagram illustrating a software fault propagation mechanism.
Fig. 2 shows the case where the execution paths are identical in the failure state.
Fig. 3 shows a case where the execution path branches in a failure state.
Fig. 4 shows a case where the execution path is changed in a failure state.
FIG. 5 shows a comparative example of a target.
FIG. 6 is a block diagram of the method of the present invention.
Detailed Description
The technical solution of the present invention is further described below with reference to the accompanying drawings and examples.
The invention discloses a method for acquiring a fault propagation path during software operation, which comprises the following specific steps as shown in fig. 6:
step one, collecting data during dynamic software runtime
S1.1, determining the type of data to be collected
The parameters in the C language are divided into actual parameters and form parameters. The parameters appear in the called function and can be used in the whole function body. The compiler system does not allocate memory space when defining, and only allocates memory units when calling the function. The actual parameters may be constants, variables, expressions, pointers, etc. These data are typically kept in stacks (stack), heaps (heap), static areas (static), registers (register), etc. Under Linux, the gdb debugger can obtain register information, stack information, memory information, disassembling information, and the like through commands. The entry parameter, the exit parameter and the return value can be obtained by a gdb debugger.
TABLE 1
Wherein, the global variable can not directly obtain the name through gdb. Here, a SrcML static analysis tool is used for carrying out static analysis on a code to be monitored, a global variable name is extracted from an output xml file in a character retrieval mode, and then a corresponding global variable value can be directly monitored in a gdb debugger.
S1.2, code instrumentation is carried out on target software
In order to monitor the above data in the function and obtain the relevant parameter information of the function entry and exit when the software is running, the function entry and exit need to be marked, so that the gdb debugger can set breakpoints at the function entry and exit. The specific marking mode is as follows: adding a definition-functions parameter when the gcc compiling is carried out on the function, and calling a _ cyg _ profile _ func _ enter function at the entrance of the function by the gcc; the _ cyg _ profile _ func _ exit function is called at the exit of the function, called the hook function. By the method, the function inlet and the function outlet can be conveniently positioned, the function name is recorded, the function address is stored, the function calling relation is recorded, and the subsequent processing is convenient. And (4) positioning the hook function related function code in an instruction.c file, and directly linking and compiling. And marking the function inlet and outlet by using the pile inserting function of the gcc compiler, and adding breakpoints to the function inlet and outlet through the gdb debugger, so that variable information can be output in the running process.
S1.3, monitoring data and recording during program operation
Writing a gdb file, writing a breakpoint setting statement and a monitoring statement into the gdb file, performing stepping debugging, outputting display contents into a text document, and adding logic to enable the display contents to be output until the program is finished when running is terminated.
And compiling a shell script file, and writing the processes of compiling a pile inserting hook function by gcc and running gdb into an executable program, so that automation of pile inserting, monitoring and outputting can be realized.
Step two, fault propagation path obtaining method based on data comparison and analysis
S2.1, preprocessing data
In order to process the text document containing the function module parameter information obtained through gdb output in the step S1.3, the key information of the text document is extracted by using a character matching method.
The key information in the output document is mainly as follows: function name, access label, parameter information, return value information. The function name is the part contained by the sharp brackets in the row where this _ func is located; after the access label is positioned in a breakpoint row-cyg-profile-func-entry represents an entry function, and exit represents an exit function; the parameter information is positioned in a part contained in a small bracket in the row # 1 and comprises information when local variables, input parameters and global variables are changed; the return value is located at the end of the rbx row, i.e., the exit information of the function block.
And the matched information is stored in the array in a nested array form, so that the final processing is facilitated.
S2.2, obtaining a fault propagation path by comparing and analyzing data
For the same function module, on the premise of the same input, the output is the same theoretically no matter how many times the function module is operated. Based on this assumption, the output file obtained by inputting the normal test case is compared with the output file obtained by inputting the fault test case, and then the different part of the fault output relative to the normal output is the part through which the fault passes. Analyzing the output file, extracting the function names and the in-out labels in the array of the parts to obtain an execution path in a normal state and an execution path in a fault state, and extracting the part with parameter change in the path to obtain a fault propagation path.
Three variations of the execution path in the fault state compared to the normal state are considered below.
(1) The execution paths are completely the same, and the parameters in the paths are not changed.
Under the condition that the execution paths are completely the same, only the parameter comparison of the corresponding module is needed to be carried out, and the fact that the module has no fault can be known.
As shown in fig. 2, the execution path of the program in the first behavior normal state is schematically illustrated, and the fault of the second behavior is injected at a certain module and then propagates backwards, affecting all the following modules, and the fault propagation path is the path between the modules having the fault function. The third row is a special fault-tolerant case, i.e. the failed module is sandwiched between two correct modules, since the fault does not affect the normal execution of the program in these two correct modules, and therefore the fault propagation path in the fault-tolerant situation is defined as the path between the failed functional modules.
Therefore, in the case where the execution paths are completely the same, a method of comparing the execution path in the normal state and the execution path in the failure state in a one-to-one correspondence is desirable.
(2) The execution path is branched
The execution path branches when a fault propagates to a certain position, and a function module behind the branch is completely different from that in a normal state and is another branch structure completely different from that in the normal state.
As shown in fig. 3, the fault is excited at B and then propagates to a new path of C1, D1, E1, F1. In this case, we define the fault propagation path as the whole execution path that the fault excitation point B passes through until the end of the program run.
(3) Partial addition, deletion or replacement of execution path
The execution path in the fault state may have partial addition, partial deletion, and partial replacement compared to the execution path in the normal state.
When a fault propagates to a module, the path becomes long. One possibility is to call other function modules, and the other possibility is to call a certain module repeatedly, which is added to the part.
Compared with the execution path in the normal state, when the fault is propagated to a certain module, the path is shortened, a section of path in the normal path is directly skipped from a certain position, and the path is skipped to a certain module in the subsequent state, which is a part of deletion.
Compared with the execution path in the normal state, when the fault is propagated to a certain module, the fault is selectively propagated to other function modules, and then propagated to a certain module behind the normal execution path, which is partial replacement.
As shown in fig. 4, intuitively, the fault trigger points are all B, and the fault propagation paths that we need are a segment of execution paths starting from B, which are bcmmndef, bcmmnmndef, BEF, and BMNEF, respectively.
Above are several basic ways of performing path change in fault conditions, from which complex fault propagation paths can be summed.
For the case where there is a fault trigger at the repeated call, taking fig. 5 as an example, when the fault trigger calls MN for the second time, intuitively, the fault propagation path at this time should be M2N2M3N3B, and with the existence of the time tag, the function module in the execution path becomes uniquely determined. The function module which completely accords with the access label according to the function name is a comparison benchmark and is called a mark post. The method is used for carrying out benchmarking contrast, and then correct results can be obtained.
To obtain the fault propagation path, the following algorithm is proposed:
1. considering the repeated calling situation, the repeatedly called functions need to be numbered, which represents the number of times the function is called, i.e. the function label. And (3) traversing the function names and the access labels of the two parameter arrays in the normal state and the fault state respectively for the output file obtained in the S2.1 and the data preprocessing step, numbering the function module names (assumed to be funcname) which are called for multiple times, and labeling funcname.1, funcname.2, funcname.3 and the like respectively according to the sequence.
2. And taking the execution path in the normal state as a reference, carrying out one-to-one correspondence between each function module of the execution path in the fault state and the reference, and recording the array positions of the function names and the in-out labels which completely accord with each other, namely the benchmarks.
3. And comparing the corresponding parameters of the normal state parameter array and the fault state parameter array according to the array positions, and finding out the position of the function module with different parameters appearing for the first time, namely the starting point of the fault propagation path.
4. And if function modules different from the normal execution path exist between the benchmarks, the function modules between the benchmarks are connected in the fault execution path according to the execution sequence and finally connected to the ending module of the fault execution path.
Claims (2)
1. A method for acquiring a fault propagation path during software operation is characterized in that: the method comprises the following specific steps:
step one, collecting data during dynamic software runtime
S1.1, determining the type of data to be collected
Under Linux, the gdb debugger acquires register information, stack information, memory information and disassembling information through commands; the parameter input value, the parameter output value and the return value are all obtained in a gdb debugger mode;
the method comprises the steps that a SrcML static analysis tool is used for carrying out static analysis on a code to be monitored, a global variable name is extracted from an output xml file in a character retrieval mode, and then a corresponding global variable value can be directly monitored in a gdb debugger;
s1.2, code instrumentation is carried out on target software
Marking the function inlet and outlet by using the pile inserting function of the gcc compiler, and adding breakpoints to the function inlet and outlet through the gdb debugger, namely outputting variable information in the running process;
s1.3, monitoring data and recording during program operation
Writing a gdb file, writing a breakpoint setting statement and a monitoring statement into the gdb file, performing stepping debugging, outputting display contents into a text document, and adding logic to enable the display contents to be output until the program is finished when running is terminated;
compiling a shell script file, and writing the processes of compiling a pile inserting hook function by gcc and running gdb into an executable program, namely realizing automation of pile inserting, monitoring and outputting;
step two, fault propagation path obtaining method based on data comparison and analysis
S2.1, preprocessing data
Extracting key information of the data obtained in the previous step by using a character matching method; the matched information is stored in the array in a nested array form, so that the final processing is facilitated;
s2.2, obtaining a fault propagation path by comparing and analyzing data
For the same function module, under the premise of the same input, the output is the same in theory no matter how many times the function module runs; based on the assumption, comparing an output file obtained by inputting the normal test case with an output file obtained by inputting the fault test case, wherein different parts of fault output relative to normal output are parts through which faults pass; analyzing the output file, extracting function names and access labels in the array of the parts to obtain an execution path in a normal state and an execution path in a fault state, and extracting the part with parameter change in the path to obtain a fault propagation path;
the method for acquiring the fault propagation path in step S2.2 is as follows:
s2.2.1, numbering the repeatedly called functions in consideration of the repeated calling condition, wherein the function is the called number of times, namely the function label; for the output file obtained in the step of preprocessing the data S2.1, respectively traversing the function names and the in-out labels of the two parameter arrays in the normal state and the fault state, numbering the function module names which are called for many times, and respectively labeling the function module names according to the sequence;
s2.2.2, taking the execution path in the normal state as a reference, corresponding each function module of the execution path in the fault state to the reference one by one, and recording the array position where the function name and the in-out label completely accord with each other, namely the marker post;
s2.2.3, comparing the corresponding parameters of the normal state parameter array and the fault state parameter array according to the array positions, and finding out the function module position where different parameters occur for the first time, namely the starting point of the fault propagation path;
s2.2.4, using the first changed function module as the starting point of the fault propagation path, then using each function module as the same as the execution path in the normal state as the mark post, if there is no other function module between the mark posts, directly connecting in sequence according to the path, if there is a function module different from the normal execution path between the mark posts, connecting the function modules between the mark posts in the execution sequence in the fault execution path, and finally connecting to the ending module of the fault execution path.
2. The method for acquiring the fault propagation path during the software runtime according to claim 1, wherein: three variations of the execution path in the fault state are: (1) the execution paths are completely the same, and the parameters in the paths are not changed; (2) the execution path is branched; (3) partial additions, deletions or substitutions of execution paths occur.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811503761.3A CN109669866B (en) | 2018-12-10 | 2018-12-10 | Method for acquiring fault propagation path during software operation |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811503761.3A CN109669866B (en) | 2018-12-10 | 2018-12-10 | Method for acquiring fault propagation path during software operation |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109669866A CN109669866A (en) | 2019-04-23 |
| CN109669866B true CN109669866B (en) | 2021-04-30 |
Family
ID=66144350
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811503761.3A Active CN109669866B (en) | 2018-12-10 | 2018-12-10 | Method for acquiring fault propagation path during software operation |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109669866B (en) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110213087B (en) * | 2019-05-16 | 2020-08-25 | 北京航空航天大学 | Complex system fault positioning method based on dynamic multilayer coupling network |
| CN110941528B (en) * | 2019-11-08 | 2022-04-08 | 支付宝(杭州)信息技术有限公司 | Log buried point setting method, device and system based on fault |
| CN112965892B (en) * | 2019-12-12 | 2024-06-21 | 大唐移动通信设备有限公司 | Abnormal information acquisition method and device of software system, electronic equipment and medium |
| CN111813668B (en) * | 2020-06-30 | 2023-03-24 | 烽火通信科技股份有限公司 | Method, storage medium, device and system for executing process of multi-disk software program |
| CN112306501B (en) * | 2020-11-30 | 2023-03-28 | 杭州网易云音乐科技有限公司 | Business data acquisition method and device, storage medium and computing equipment |
| CN113590463A (en) * | 2021-06-21 | 2021-11-02 | 中国人民解放军陆军装甲兵学院 | Software reliability measurement method based on non-intrusive dynamic monitoring |
| CN115033497B (en) * | 2022-08-11 | 2022-11-25 | 北京登临科技有限公司 | Kernel function testing method, device, equipment and storage medium |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101547128A (en) * | 2008-03-26 | 2009-09-30 | 阿瓦亚公司 | A failover/failback trigger using a SIP notify message in a SIP survivable network configuration |
| CN105893256A (en) * | 2016-03-30 | 2016-08-24 | 西北工业大学 | Software failure positioning method based on machine learning algorithm |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7627785B1 (en) * | 2004-07-12 | 2009-12-01 | Sun Microsystems, Inc. | Capturing machine state of unstable Java program |
| CN102789419B (en) * | 2012-07-20 | 2015-04-15 | 中国人民解放军信息工程大学 | Software fault analysis method based on multi-sample difference comparison |
| CN104360938B (en) * | 2014-10-21 | 2017-10-20 | 北京邮电大学 | A kind of fault recognition method and its system |
| CN106502907B (en) * | 2016-10-28 | 2018-11-30 | 中国科学院软件研究所 | A kind of distributed software abnormality diagnostic method based on execution track tracking |
| CN106775487A (en) * | 2016-12-27 | 2017-05-31 | 郑州云海信息技术有限公司 | A kind of multipath stores the treating method and apparatus of failure |
| CN108319555B (en) * | 2018-03-17 | 2021-03-09 | 成都大学 | Real-time debugging method based on embedded real-time system |
-
2018
- 2018-12-10 CN CN201811503761.3A patent/CN109669866B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101547128A (en) * | 2008-03-26 | 2009-09-30 | 阿瓦亚公司 | A failover/failback trigger using a SIP notify message in a SIP survivable network configuration |
| CN105893256A (en) * | 2016-03-30 | 2016-08-24 | 西北工业大学 | Software failure positioning method based on machine learning algorithm |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109669866A (en) | 2019-04-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109669866B (en) | Method for acquiring fault propagation path during software operation | |
| CN101739339B (en) | Program dynamic dependency relation-based software fault positioning method | |
| Jin et al. | Automated behavioral regression testing | |
| Chen et al. | Coverage prediction for accelerating compiler testing | |
| Wang et al. | Automated path generation for software fault localization | |
| Goseva-Popstojanova et al. | Large empirical case study of architecture-based software reliability | |
| CN102567164A (en) | Instruction set batch testing device and method for processor | |
| US10853051B2 (en) | Automated candidate repair patch generation | |
| Pacheco | Postmortem debugging in dynamic environments | |
| Sakamoto et al. | OCCF: A framework for developing test coverage measurement tools supporting multiple programming languages | |
| CN109002723B (en) | Sectional type symbol execution method | |
| Hassan et al. | C-REX: An evolutionary code extractor for C | |
| Huchant et al. | Parcoach extension for a full-interprocedural collectives verification | |
| Le et al. | Dynamic inference of change contracts | |
| CN113742252B (en) | Method and device for detecting memory disorder | |
| Elsner et al. | BinaryRTS: Cross-language Regression Test Selection for C++ Binaries in CI | |
| Kong et al. | Tracing error propagation in C/C++ applications | |
| Parravicini et al. | The Cost of Speculation: Revisiting Overheads in the V8 JavaScript Engine | |
| Li et al. | Research and Implementation of a Software Runtime Fault Propagation Path Acquisition Method | |
| Angerer et al. | An experiment comparing lifted and delayed variability-aware program analysis | |
| Korel | Identifying faulty modifications in software maintenance | |
| Li et al. | Effective fault localization based on minimum debugging frontier set | |
| Zhu | The application perspective of mutatoin testing. | |
| Lei et al. | Program Segment Testing for Software Fault Prevention | |
| Soomro et al. | A Framework for Debugging Java Programs in a Bytecode |
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 |