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 PDF

Info

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
Application number
CN201811503761.3A
Other languages
Chinese (zh)
Other versions
CN109669866B (en
Inventor
陆民燕
李松正
孔士溢
李璐祎
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beihang University
Original Assignee
Beihang University
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beihang University filed Critical Beihang University
Priority to CN201811503761.3A priority Critical patent/CN109669866B/en
Publication of CN109669866A publication Critical patent/CN109669866A/en
Application granted granted Critical
Publication of CN109669866B publication Critical patent/CN109669866B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3636Software debugging by tracing the execution of the program
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/366Software 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

A kind of acquisition methods of software run time fault propagation path
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.
CN201811503761.3A 2018-12-10 2018-12-10 Method for acquiring fault propagation path during software operation Active CN109669866B (en)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

Patent Citations (8)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
Title
王学成等: "结合贝叶斯网与SFMEA技术的软件故障诊断框架", 《计算机科学》 *

Cited By (9)

* Cited by examiner, † Cited by third party
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