CN109669866A - A kind of acquisition methods of software run time fault propagation path - Google Patents
A kind of acquisition methods of software run time fault propagation path Download PDFInfo
- Publication number
- CN109669866A CN109669866A CN201811503761.3A CN201811503761A CN109669866A CN 109669866 A CN109669866 A CN 109669866A CN 201811503761 A CN201811503761 A CN 201811503761A CN 109669866 A CN109669866 A CN 109669866A
- Authority
- CN
- China
- Prior art keywords
- software
- function
- fault propagation
- propagation path
- execution route
- 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
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 present invention discloses a kind of acquisition methods of software run time fault propagation path: Step 1: data collection when software dynamic operation, specifically includes: determining the data type to be collected;Code pitching pile is carried out to target software;Monitoring programme runtime data simultaneously records;Step 2: the fault propagation method for obtaining path based on date comprision, specifically includes: data prediction;Fault propagation path is obtained by comparing analysis data.The present invention can obtain fault propagation path of the C programmer in failure operation under Linux environment.It can be quickly and accurately positioned at the place of software fault using helper applications engineer using path as clue, reduce maintenance cost;Multiple fault propagation path analysis of comprehensive same program, it can be deduced that program is easy to produce the module position of failure, facilitates software engineer and improves fallibility module, improves software reliability;The effect of Failure Alarm can also be provided for software to the monitoring of software dynamic operation.
Description
Technical field
The acquisition methods that the present invention provides a kind of software run time fault propagation path are belonged to promoting software reliability
Software maintenance technology field.
Background technique
With the fast development of computer and network technology, demand of the people to software function and performance is increasingly improved, soft
Part structure increasingly complicates, and has expedited the emergence of the formation of complex software intensive equipment system.Often internal logic is multiple for such software systems
Miscellaneous, the information interaction of software and hardware is frequent, and service life is very long, and the complexity of software fault is increase accordingly.How to guarantee multiple
Miscellaneous system software reliability of operation, becomes the hot issue studied now.
The researcher of field of software engineering thinks that the mistake that software development process is introduced into software product is that software is caused to be sent out
The basic reason of raw failure, and mistake eventually leads to failure and occurs then to need this necessary condition of fault propagation.Preamble software mould
The failure that block generates eventually leads to software and generates failure, this process is by contacting propagation between postorder software module
For software fault dissemination.
Based on software fault propagation path, software developer can promptly navigate to the generation position of failure, exclude event
Barrier reduces software error.During Design of Reliability, we are by analyzing software fault propagation path, energy
The propagation path of software fault is enough obtained, to obtain the weak link of complicated software system, helps the reliability for improving software
Design, can also take prevention, Forewarning Measures to failure in propagation path.
The software fault technology of existing code level is the positioning for software fault mostly, without providing software
The path of fault propagation.Compared to fault location, fault propagation path can preferably reflect the structure and failure hair of software
Raw process, while the software module to break down can be also positioned, reinforce the weak module for being easy to happen failure, helps to design
Personnel improve software structure design, the fault propagation behavior that reduction software service stage may occur, to reduce possible event
Hinder propagation effect, improve Design of Reliability, it is horizontal to improve software reliability.
Summary of the invention
The purpose of the present invention is to provide a kind of acquisition methods of software run time fault propagation path, to solve existing skill
Lack the problems such as research to software fault propagation path in art.
In the research work in the past for software reliability, often assume that the failure between software module is mutually indepedent
, the failure of software module will lead to the failure of system.But truth is: software error can cause local failure, soft
What the failure of part component never independently occurred.It, all may be to depositing therewith as shown in Figure 1, the failure in single component
It being had an impact in the component of interactive relation, i.e., the failure that upper level assembly occurs may pass to sub-ordinate components by interface, under
Mistake may be transmitted to next stage after the input of acceptance error by level assembly, it is also possible to be hidden this input error, be generated
One correctly output;This transmitting may continue up to the stage of system output, it is also possible to stop in midway (due to group
Wrong identification and Restoration Mechanism existing for inside part), here it is the mechanism that software fault is propagated.
The present invention mainly using C/C++ software program under Linux as object (using GCC compiler), proposes a kind of software fortune
The acquisition methods in fault propagation path when row.Integral Thought of the invention is as follows: in the case of collection normal operation and direct fault location
Run two states under with fault propagation relevant parameter, propose that a kind of comparison algorithm of data divides the data being collected into
Analysis processing, it is final to obtain fault propagation path.
A kind of acquisition methods of software run time fault propagation path of the present invention, the specific steps are as follows:
Step 1: data collection when software dynamic operation
S1.1, the data type to be collected is determined
Under linux, gdb debugger obtains register information, stack information, memory information, dis-assembling letter by order
Breath;Enter to join, go out ginseng, return value can be got by way of gdb debugger;
Monitor code is treated using SrcML static analysis tools and carries out static analysis, passes through word in the xml document of output
The mode of symbol retrieval extracts global variable title, so can in gdb debugger the corresponding global variable value of direct monitoring.
S1.2, code pitching pile is carried out to target software
Using the pitching pile function of gcc compiler, function entrance is marked, and is gone out by gdb debugger to function
Entrance adds breakpoint, can output variable information in the process of running.
S1.3, monitoring programme runtime data simultaneously record
Gdb file is write, setting breakpoint sentence and police statement are written wherein, stepping debugging is carried out, will show content
Into text document, addition logic makes its end of output when program runs abort for output.
Shell script file is write, executable program is written into gcc compiling pitching pile Hook Function and the process for running gdb
In, pitching pile, monitoring and the automation of output can be realized.
Step 2: the fault propagation method for obtaining path based on date comprision
S2.1, data prediction
Key message extraction is carried out to the data that abovementioned steps obtain using character match method;By the information matched with
In the form deposit array of nested array, facilitate final processing.
S2.2, fault propagation path is obtained by comparing analysis data
For the same function module, under the premise of identical input, how many times no matter are run, theoretically exporting all is phase
With;Based on this it is assumed that output file and fault test use-case that proper testing use-case inputs are inputted defeated
File is compared out, then failure output phase is part that failure is passed through for part different in normally exporting.Analysis
Output file extracts function name in the array of these parts and enters and leaves label, obtains the execution route and failure under normal condition
Execution route under state, then the part that Parameters variation occurs in path is extracted, fault propagation path can be obtained.
Wherein, there is three kinds of situations of change of execution route under malfunction: (1), execution route it is identical, join in path
Number does not change;(2), branch has occurred in execution route;(3), execution route has occurred part and increases, lacks or replace.
Wherein, the acquisition methods in fault propagation path are as follows:
S2.2.1, in view of there is the case where repetition calling, the function of counterweight polyphony is numbered, and representative function is called
Which time, the as label of function;To output file obtained in S2.1 data prediction step, normal condition is traversed respectively
The function name of two parameter arrays and discrepancy label, carry out the function module title repeatedly called under lower and malfunction
Number, marks respectively in sequence;
S2.2.2, on the basis of the execution route under normal condition, by each Function Modules of execution route under malfunction
Block is corresponded with benchmark, function name is recorded with the array position that label is consistent completely is entered and left, as mark post;
S2.2.3, according to array position above, compare pair of normal condition parameter array and malfunction parameter array
Parameter is answered, finds out and occurs the function module position of different parameters, as fault propagation path starting point for the first time.
S2.2.4, the function module to be changed using first as fault propagation path starting point, thereafter with each with just
The identical function module of execution route is mark post under normal state, if without other function modules between mark post, directly by path
It is sequentially connected with, if there is the function module different from normal execution route between mark post, by execution in failure execution route
Function module between sequential connection mark post is ultimately connected to the ending module of failure execution route.
A kind of acquisition methods of software run time fault propagation path of the present invention, advantage and effect are: using this hair
Bright method can obtain fault propagation path of the C programmer in failure operation under Linux environment.Compared to simple failure
Positioning, the acquisition in fault propagation path can be quickly and accurately positioned software fault using helper applications engineer using path as clue
Place at, reduce maintenance cost;Multiple fault propagation path analysis of comprehensive same program, it can be deduced that program is easy to produce
The module position of failure facilitates software engineer and improves fallibility module, improves software reliability;To the prison of software dynamic operation
Control can also provide the effect of Failure Alarm for software.
Detailed description of the invention
Fig. 1 show software fault mechanism of transmission schematic diagram.
Fig. 2 show the identical situation of execution route under malfunction.
Fig. 3 show execution route under malfunction, and there is a situation where branches.
Fig. 4 show the case where execution route changes under malfunction.
Fig. 5 show mark post control signal.
Fig. 6 show the method for the present invention flow diagram.
Specific embodiment
With reference to the accompanying drawings and examples, the following further describes the technical solution of the present invention.
A kind of acquisition methods of software run time fault propagation path of the present invention, as shown in Figure 6, the specific steps are as follows:
Step 1: data collection when software dynamic operation
S1.1, the data type to be collected is determined
Parameter in C language is divided into actual parameter and two kinds of formal parameter.Parameter appears in called function, whole
It can be used in a function body.Parameter compiling system in definition does not distribute memory space, only when calling the function
Just distribute internal storage location.Actual parameter can be constant, variable, expression formula, pointer etc..These data are generally held in stack
(stack), in heap (heap), static region (static), register (register) etc..Under linux, gdb debugger can
To obtain register information, stack information, memory information, dis-assembling information etc. by order.Enter to join, go out ginseng, return value all may be used
It is got in a manner of through gdb debugger.
Table 1
Wherein, global variable directly can not obtain title by gdb.Here we use SrcML static analysis work
Tool treats monitor code and carries out static analysis, and global variable is extracted by way of character retrieval in the xml document of output
Title, so can in gdb debugger the corresponding global variable value of direct monitoring.
S1.2, code pitching pile is carried out to target software
In order to monitor the above-mentioned data in function when software is run, the relevant parameter letter of function entrance and outlet is obtained
Breath, needs that function entrance and outlet is marked, so that gdb debugger is in function entrance and outlet setting breakpoint.Specifically
Mark mode are as follows: the addition-finstrument-functions parameter when function carries out gcc compiling, gcc will enter in function
Calling _ cyg_profile_func_enter function at mouthful;Calling _ cyg_profile_func_exit letter in function exit
Number, referred to as Hook Function.In this way, we can easily position the entrance and exit of function, record
Function name saves the address of function, records the call relation of function, facilitates subsequent processing.By Hook Function correlation function generation
Code bit directly links compiling in instrument.c file.Using the pitching pile function of gcc compiler, function is entered and left
It mouthful is marked, and breakpoint is added to function entrance by gdb debugger, it can output variable information in the process of running.
S1.3, monitoring programme runtime data simultaneously record
Gdb file is write, setting breakpoint sentence and police statement are written wherein, stepping debugging is carried out, will show content
Into text document, addition logic makes its end of output when program runs abort for output.
Shell script file is write, executable program is written into gcc compiling pitching pile Hook Function and the process for running gdb
In, pitching pile, monitoring and the automation of output can be realized.
Step 2: the fault propagation method for obtaining path based on date comprision
S2.1, data prediction
To handle the text document comprising function module parameter information exported in above-mentioned S1.3 by gdb, utilize
Character match method carries out key message extraction to this article this document.
Key message in output document mainly has following part: function name enters and leaves label, parameter information, return value
Information.Function name, that is, this_func is expert at the part that middle angle brackets are included;It enters and leaves label and is located at breakpoint row
In _ cyg_profile_func_ after, enter indicates entry into function, and function is exited in exit expression;Parameter information is located in #1 row
The round bracket part that is included, including local variable, enter ginseng and information when global variable changes;Return value is located at
Rbx row end, the i.e. outlet information of function module.
The information matched is stored in array in the form of nested array, facilitates final processing.
S2.2, fault propagation path is obtained by comparing analysis data
For the same function module, under the premise of identical input, how many times no matter are run, theoretically exporting all is phase
With.Based on this it is assumed that output file and fault test use-case that proper testing use-case inputs are inputted defeated
File is compared out, then failure output phase is part that failure is passed through for part different in normally exporting.Analysis
Output file extracts function name in the array of these parts and enters and leaves label, obtains the execution route and failure under normal condition
Execution route under state, then the part that Parameters variation occurs in path is extracted, fault propagation path can be obtained.
It is considered below compared with normal condition, three kinds of situations of change of execution route under malfunction.
(1), execution route is identical, and parameter does not change in path.
In the case that execution route is identical, the parameter that need to only carry out respective modules compares, you can learn that the module has
There is no failures.
As shown in Fig. 2, the first row is the execution route schematic diagram of program under normal condition, the second behavior failure is in certain module
Place's injection, and then back-propagation, influence all modules thereafter, and fault propagation path is as broken down between function module
Path.The third line is special fault-tolerant situation, that is, the module clip to break down is between two correct modules, because failure exists
It has no effect on program in the two correct modules normally to execute, therefore the fault propagation path defined under fault-tolerant situation remains as
The path between function module broken down.
Therefore, in the case where execution route is identical, holding under normal condition is compared by one-to-one mode
The method of execution route under walking along the street diameter and malfunction is desirable.
(2), branch has occurred in execution route
Branch has occurred at fault propagation to somewhere in execution route, under the function module and normal condition after bifurcation
It is completely different, it is another entirely different branched structure.
As shown in figure 3, failure ejects at B, backward C1, D1, E1, F1 this new propagated.This
In the case of, whole execution routes that our failure definition propagation paths are passed through by failure excitation point B until the end of the program.
(3), execution route has occurred part and increases, lacks or replace
Compared with the execution route under normal condition, the execution route under malfunction may occur part increase, part
Missing and partial replacement.
Occurs the elongated situation in path when fault propagation to certain module.One kind may be to have invoked other function modules,
Alternatively possible is to have invoked a certain module repeatedly, this increases for part.
Compared with the execution route under normal condition, there is the case where path shortening in when fault propagation to certain module, from
The stretch diameter in normal route is directly skipped in somewhere, skips to some module of postorder, this is excalation.
Compared with the execution route under normal condition, when fault propagation to certain module, select to propagate to other function modules,
Normal some module of execution route postorder is then propagated to, this is partial replacement.
As shown in figure 4, intuitively, failure excitation point is B, fault propagation path required for us is i.e. using B as starting point
One section of execution route, respectively BCMNDEF, BCMNMNMNDEF, BEF, BMNEF.
It is several basic modes that execution route changes under malfunction above, complicated fault propagation path can be by this
Several situations sum up to obtain.
For there are failure excitations the case where repeating at calling, by taking Fig. 5 as an example, failure excitation calls MN's at second
When, intuitively, fault propagation path at this time should be M2N2M3N3B, have a presence of number label, in execution route
Function module just at uniquely determining.Regard function name with enter and leave the function module that is consistent completely of label as according to benchmark,
Referred to as mark post.Mark post control is carried out using the above method, correct result can be obtained.
To obtain fault propagation path, it is proposed that following algorithm:
1, in view of there is the case where repetition calling, the function of counterweight polyphony is needed to be numbered, representative function is called
Which time, the as label of function.To output file obtained in S2.1, data prediction step, normal shape is traversed respectively
Under state and malfunction under two parameter arrays function name and enter and leave label, to the function module title repeatedly called
(being assumed to be funcname) is numbered, and marks funcname.1, funcname.2, funcname.3 etc. respectively in sequence.
2, on the basis of the execution route under normal condition, by each function module and base of execution route under malfunction
Standard is corresponded, and function name is recorded with the array position that label is consistent completely is entered and left, as mark post.
3, according to array position above, compare the corresponding ginseng of normal condition parameter array and malfunction parameter array
Number is found out and occurs the function module position of different parameters, as fault propagation path starting point for the first time.
4, the function module to be changed using first is fault propagation path starting point, thereafter with each and normal condition
The identical function module of lower execution route is mark post, if directly sequentially connecting by path between mark post without other function modules
It connects, if there is the function module different from normal execution route between mark post, connects in failure execution route by execution sequence
The function module between mark post is connect, the ending module of failure execution route is ultimately connected to.
Claims (3)
1. a kind of acquisition methods of software run time fault propagation path, it is characterised in that: specific step is as follows for this method:
Step 1: data collection when software dynamic operation
S1.1, the data type to be collected is determined
Under linux, gdb debugger obtains register information, stack information, memory information, dis-assembling information by order;Enter
Ginseng, ginseng, return value can be got by way of gdb debugger out;
Monitor code is treated using SrcML static analysis tools and carries out static analysis, is examined in the xml document of output by character
The mode of rope extracts global variable title, so can in gdb debugger the corresponding global variable value of direct monitoring;
S1.2, code pitching pile is carried out to target software
Using the pitching pile function of gcc compiler, function entrance is marked, and passes through gdb debugger to function entrance
Breakpoint is added, it can output variable information in the process of running;
S1.3, monitoring programme runtime data simultaneously record
Gdb file is write, setting breakpoint sentence and police statement are written wherein, stepping debugging is carried out, it will display content output
Into text document, addition logic makes its end of output when program runs abort;
Shell script file is write, by gcc compiling pitching pile Hook Function and is run in the process write-in executable program of gdb, i.e.,
Pitching pile, monitoring and the automation of output can be achieved;
Step 2: the fault propagation method for obtaining path based on date comprision
S2.1, data prediction
Key message extraction is carried out to the data that abovementioned steps obtain using character match method;By the information matched with nesting
In the form deposit array of array, facilitate final processing;
S2.2, fault propagation path is obtained by comparing analysis data
For the same function module, under the premise of identical input, how many times no matter are run, it is all identical for theoretically exporting
's;Based on this it is assumed that by the output file that proper testing use-case inputs and the output that fault test use-case inputs
File is compared, then failure output phase is part that failure is passed through for part different in normally exporting;It analyzes defeated
File out extracts function name in the array of these parts and enters and leaves label, obtains the execution route and failure shape under normal condition
Execution route under state, then the part that Parameters variation occurs in path is extracted, fault propagation path can be obtained.
2. a kind of acquisition methods of software run time fault propagation path according to claim 1, it is characterised in that: failure
There is three kinds of situations of change of execution route under state: (1), execution route it is identical, parameter does not change in path;(2),
Branch has occurred in execution route;(3), execution route has occurred part and increases, lacks or replace.
3. a kind of acquisition methods of software run time fault propagation path according to claim 1, it is characterised in that: described
The acquisition methods in fault propagation path are as follows in step S2.2:
S2.2.1, in view of there is the case where repetition calling, the function of counterweight polyphony is numbered, representative function it is called the
Several times, the as label of function;To output file obtained in S2.1 data prediction step, traverse under normal condition respectively and
The function name of two parameter arrays and discrepancy label, compile the function module title repeatedly called under malfunction
Number, it marks respectively in sequence;
S2.2.2, on the basis of the execution route under normal condition, by each function module of execution route under malfunction with
Benchmark is corresponded, and function name is recorded with the array position that label is consistent completely is entered and left, as mark post;
S2.2.3, according to array position above, compare the corresponding ginseng of normal condition parameter array and malfunction parameter array
Number is found out and occurs the function module position of different parameters, as fault propagation path starting point for the first time;
S2.2.4, the function module to be changed using first is fault propagation path starting points, thereafter with each and normal shape
The identical function module of execution route is mark post under state, if without other function modules between mark post, directly by path sequentially
Connection presses execution sequence if there is the function module different from normal execution route between mark post in failure execution route
The function module between mark post is connected, the ending module of failure execution route is ultimately connected to.
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 true CN109669866A (en) | 2019-04-23 |
CN109669866B 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) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110213087A (en) * | 2019-05-16 | 2019-09-06 | 北京航空航天大学 | A kind of complication system Fault Locating Method based on dynamic multilayer coupling network |
CN110941528A (en) * | 2019-11-08 | 2020-03-31 | 支付宝(杭州)信息技术有限公司 | Log buried point setting method, device and system based on fault |
CN111813668A (en) * | 2020-06-30 | 2020-10-23 | 烽火通信科技股份有限公司 | Method, storage medium, device and system for executing process of multi-disk software program |
CN112306501A (en) * | 2020-11-30 | 2021-02-02 | 杭州网易云音乐科技有限公司 | Business data acquisition method and device, storage medium and computing equipment |
CN112965892A (en) * | 2019-12-12 | 2021-06-15 | 大唐移动通信设备有限公司 | Abnormal information acquisition method and device for software system, electronic equipment and medium |
CN113590463A (en) * | 2021-06-21 | 2021-11-02 | 中国人民解放军陆军装甲兵学院 | Software reliability measurement method based on non-intrusive dynamic monitoring |
CN115033497A (en) * | 2022-08-11 | 2022-09-09 | 北京登临科技有限公司 | Kernel function testing method, device, equipment and storage medium |
Citations (8)
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 |
US20100042875A1 (en) * | 2004-07-12 | 2010-02-18 | Sun Microsystems, Inc. | Capturing machine state of unstable java program |
CN102789419A (en) * | 2012-07-20 | 2012-11-21 | 中国人民解放军信息工程大学 | Software fault analysis method based on multi-sample difference comparison |
CN104360938A (en) * | 2014-10-21 | 2015-02-18 | 北京邮电大学 | Fault confirmation method and system thereof |
CN105893256A (en) * | 2016-03-30 | 2016-08-24 | 西北工业大学 | Software failure positioning method based on machine learning algorithm |
CN106502907A (en) * | 2016-10-28 | 2017-03-15 | 中国科学院软件研究所 | A kind of distributed software abnormality diagnostic method that is followed the trail of based on perform track |
CN106775487A (en) * | 2016-12-27 | 2017-05-31 | 郑州云海信息技术有限公司 | A kind of multipath stores the treating method and apparatus of failure |
CN108319555A (en) * | 2018-03-17 | 2018-07-24 | 成都大学 | A kind of real-time adjustment method based on embedded real time system |
-
2018
- 2018-12-10 CN CN201811503761.3A patent/CN109669866B/en active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100042875A1 (en) * | 2004-07-12 | 2010-02-18 | Sun Microsystems, Inc. | Capturing machine state of unstable java program |
CN101547128A (en) * | 2008-03-26 | 2009-09-30 | 阿瓦亚公司 | A failover/failback trigger using a SIP notify message in a SIP survivable network configuration |
CN102789419A (en) * | 2012-07-20 | 2012-11-21 | 中国人民解放军信息工程大学 | Software fault analysis method based on multi-sample difference comparison |
CN104360938A (en) * | 2014-10-21 | 2015-02-18 | 北京邮电大学 | Fault confirmation method and system thereof |
CN105893256A (en) * | 2016-03-30 | 2016-08-24 | 西北工业大学 | Software failure positioning method based on machine learning algorithm |
CN106502907A (en) * | 2016-10-28 | 2017-03-15 | 中国科学院软件研究所 | A kind of distributed software abnormality diagnostic method that is followed the trail of based on perform track |
CN106775487A (en) * | 2016-12-27 | 2017-05-31 | 郑州云海信息技术有限公司 | A kind of multipath stores the treating method and apparatus of failure |
CN108319555A (en) * | 2018-03-17 | 2018-07-24 | 成都大学 | A kind of real-time adjustment method based on embedded real time system |
Non-Patent Citations (1)
Title |
---|
王学成等: "结合贝叶斯网与SFMEA技术的软件故障诊断框架", 《计算机科学》 * |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110213087A (en) * | 2019-05-16 | 2019-09-06 | 北京航空航天大学 | A kind of complication system Fault Locating Method based on dynamic multilayer coupling network |
CN110941528A (en) * | 2019-11-08 | 2020-03-31 | 支付宝(杭州)信息技术有限公司 | Log buried point setting method, device and system based on fault |
CN110941528B (en) * | 2019-11-08 | 2022-04-08 | 支付宝(杭州)信息技术有限公司 | Log buried point setting method, device and system based on fault |
CN112965892A (en) * | 2019-12-12 | 2021-06-15 | 大唐移动通信设备有限公司 | Abnormal information acquisition method and device for software system, electronic equipment and medium |
CN111813668A (en) * | 2020-06-30 | 2020-10-23 | 烽火通信科技股份有限公司 | Method, storage medium, device and system for executing process of multi-disk software program |
CN112306501A (en) * | 2020-11-30 | 2021-02-02 | 杭州网易云音乐科技有限公司 | Business data acquisition method and device, storage medium and computing equipment |
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 |
CN115033497A (en) * | 2022-08-11 | 2022-09-09 | 北京登临科技有限公司 | Kernel function testing method, device, equipment and storage medium |
Also Published As
Publication number | Publication date |
---|---|
CN109669866B (en) | 2021-04-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109669866A (en) | A kind of acquisition methods of software run time fault propagation path | |
Küçük et al. | Improving fault localization by integrating value and predicate based causal inference techniques | |
Alba et al. | Observations in using parallel and sequential evolutionary algorithms for automatic software testing | |
US20110145653A1 (en) | Method and system for testing complex machine control software | |
CN105302719B (en) | A kind of mutation testing method and device | |
CN107966648B (en) | A kind of embedded failure diagnosis method based on correlation matrix | |
CN102096410A (en) | Dynamic function test method of high-speed train operation control system | |
CN109936479A (en) | Control plane failure diagnostic system and its implementation based on Differential Detection | |
Ye et al. | Knowledge discovery and knowledge transfer in board-level functional fault diagnosis | |
CN115470138A (en) | Debugger defect detection method based on different debugging levels cross validation | |
Kim et al. | Predictive mutation analysis via the natural language channel in source code | |
Cabasino et al. | A comparison among tools for the diagnosability of discrete event systems | |
CN114253862A (en) | Asynchronous event-driven automatic analysis method for HDL (hardware description language) code simulation coverage rate | |
CN112416336B (en) | Software architecture design method for aerospace embedded system | |
CN111488276A (en) | Software reliability testing method and device based on code tracking | |
Valueian et al. | Constructing automated test oracle for low observable software | |
CN116107794A (en) | Ship software fault automatic diagnosis method, system and storage medium | |
CN113222164B (en) | Quantum calculation program generation method and expression form thereof | |
CN104615535A (en) | Method and device for generating test case based on extended data flow model | |
du Bousquet et al. | Towards mutation analysis for Lustre programs | |
Vilkomir et al. | From MC/DC to RC/DC: Formalization and analysis of control-flow testing criteria | |
Boussif et al. | Fault diagnosis of discrete-event systems based on the symbolic observation graph | |
Kong et al. | Tracing error propagation in C/C++ applications | |
CN109799425A (en) | Electric network failure diagnosis method and device | |
Merayo et al. | Formal testing of systems presenting soft and hard deadlines |
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 |