Software fault detection method based on software behavior analysis and intelligent reasoning

Abstract

The invention discloses a software fault detection method based on software behavior analysis and intelligent reasoning, belongs to the technical field of computer system software, and aims to solve the technical problems of low efficiency and poor accuracy of a current traditional software fault detection mode and improve the troubleshooting efficiency. According to the technical scheme, the method comprises the steps that firstly, software behaviors are defined, file access, memory operation and other types are covered, software codes are scanned, the behaviors are recorded in detail, recording formats are defined, including recording time, code positions and other information, and then a software behavior fault model is established; secondly, defining fault log information including fault time, register values and the like, and constructing an analysis mechanism; when the log is analyzed, the log is read and analyzed, the fault position and the initial reason are judged, the final reason is determined in combination with the fault code, and finally the fault code position and condition are determined according to the model. The software fault can be efficiently detected and positioned, manual intervention is greatly reduced, the software stability and reliability are improved, and the method is suitable for various software fault detection scenes.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer system software, and particularly relates to a software fault detection method based on software behavior analysis and intelligent reasoning. BACKGROUND

[0002] With the rapid development of computer technology, the scale and complexity of software systems are increasing, and software quality has become a key factor affecting system stability and reliability. Under the current technical background, traditional software fault detection methods mainly rely on manual review and code testing. Although these methods can find errors and defects in software to some extent, their limitations are increasingly evident when faced with highly complex software systems.

[0003] Existing software fault detection technologies can be roughly divided into two categories: static analysis technology and dynamic testing technology. Static analysis technology mainly discovers potential errors such as syntax errors and type mismatches by reviewing software source code. This method does not depend on the running environment of the software and can find problems in the early stages of software development, but its disadvantage is that it cannot detect errors related to the runtime environment, such as memory leaks and deadlocks. Dynamic testing technology discovers errors by monitoring the execution process of software during runtime, including unit testing, integration testing, system testing, and other forms. Dynamic testing can find runtime errors, but its efficiency is limited by the coverage of test cases and the selection of execution paths.

[0004] Specifically in the field of software log behavior recognition, existing log enhancement and recognition methods also face many challenges. For example, US2016132377A1 Automatic Defect Diagnosis of Machine Diagnostic Data and CN103824069A Intrusion Detection Method Based on Multi-Host Log Association disclose technologies that, although they achieve a certain degree of automation in log enhancement, still have problems of low efficiency and accuracy in recognizing existing log behaviors. These methods often require users to provide additional information (such as specifying log function names), resulting in insufficient automation and difficulty in ensuring the completeness and accuracy of the recognition results.

[0005] For example, CN106598843B discloses a software log behavior automatic recognition method based on program analysis. Although this method has made certain progress in log behavior recognition, it still has the following defects and shortcomings: 1. Dependence on specific information: The method in the comparative document requires users to provide some information (such as specifying possible log function names) when recognizing log behaviors, which limits the degree of automation of the method to some extent. In actual applications, users may not be able to accurately provide all relevant information, resulting in incomplete or incorrect recognition results.

[0006] 2. Recognition efficiency and accuracy: Although the comparative document improves the accuracy of log behavior recognition through data dependency and control dependency analysis, when dealing with large-scale software systems, the execution efficiency of the method may be affected due to the large amount of code and complex logic, making it difficult to meet the real-time or near real-time fault diagnosis requirements.

[0007] 3. Complex program logic processing: For software systems containing complex program logic (such as multi-layer nested conditional statements, loop statements, etc.), the method in the comparative document may have difficulty in accurately identifying all relevant log behaviors. Especially when dealing with cross-function, cross-module log behaviors, the accuracy of the method may be further reduced.

[0008] 4. Lack of unified standards: Currently, the recording of software logs lacks unified standards and specifications, and the log format and content differ greatly between different developers and projects. Although the method in the comparative document can identify some log behaviors for fault diagnosis, it is difficult to adapt to the log recording methods of all software systems, limiting its possibility of widespread application.

[0009] To solve the above problems, the present application proposes a more efficient, accurate and automated software log behavior recognition method. This method does not rely on specific information provided by the user, but through in-depth analysis of the data dependency and control dependency relationships between function calls, branch statements and log statements in the software source code, it automatically identifies all log behaviors for fault diagnosis. This innovation not only improves the efficiency and accuracy of log behavior recognition, but also significantly enhances the automation and universality of the method, providing more reliable technical support for software fault diagnosis. SUMMARY

[0010] The technical problem to be solved by the present application is to provide a software fault intelligent detection method based on software behavior analysis and intelligent reasoning, which solves the problems of traditional manual review and code testing that are difficult to detect complex software faults comprehensively and have low fault troubleshooting efficiency. By analyzing the software runtime logic behavior and fault phenomenon, a software behavior fault model is established, and the intelligent reasoning capability is used to realize automatic analysis of software faults, effectively improving the software fault detection efficiency and reducing the cost of manual intervention.

[0011] To achieve the above objectives, the present application adopts the following technical solutions, A software fault intelligent detection method based on software behavior analysis and intelligent reasoning, a software fault intelligent detection tool is designed, and the core function of the tool is to identify software behavior and analyze faults, specifically as follows: Definition of software behavior and fault: the software behavior refers to the execution flow and data flow of software runtime, specifically covering five categories of file access, memory operation, device read-write, software information communication, network communication; the software fault refers to the unexpected behavior generated by software runtime, including file fault, memory overflow, device resource unavailability, external communication exception, and the trigger condition and phenomenon of the fault are associated with the fault location, external condition and fault cause.

[0012] Recording content of model file: in the model file of the tool, the behavior, fault condition, fault phenomenon and fault location of the software are recorded in detail, providing data support for subsequent fault analysis.

[0013] Further, the present application determines the behavior, fault condition, fault phenomenon and fault location of the software by the following ways to complete the software behavior and fault modeling: Based on the software code scanning result, accurately identify various behaviors of the software; Combined with the identified software behavior, detect the fault trigger condition that the software may face; According to the fault trigger condition, define the corresponding fault phenomenon; When the fault occurs, output the fault log containing key information through the fault phenomenon; Deeply analyze the fault log to locate the specific position of the fault.

[0014] In order to guarantee the realization of the tool function, the present application designs three core modules, and the specific functions of each module are as follows: 1、Software behavior recognition module This module divides the software behavior into five categories of file access, memory operation, device read-write, software information communication and network communication. In the process of scanning software code, the code behavior will be classified according to the code logic, and the software code position will be identified and recorded at the same time, forming the record corresponding to the code position and behavior. In addition, the module will design exclusive fault trigger conditions according to different types of software behavior: Fault trigger condition of file access behavior: file error, read-write permission error, file damage; Fault trigger condition of memory operation behavior: memory overflow, memory permission error, insufficient memory space; Fault trigger condition of device read-write behavior: invalid device, device permission error, device state error; Fault trigger condition of software information communication behavior: semaphore error, message queue full, communication permission error; Fault trigger condition of network communication behavior: network connection error, network address error.

[0015] 2、Software fault detection module The module is designed to record fault log information of fault phenomena, and the log content covers fault categories, fault locations and software states at the time of fault. Among them, the fault category corresponds to the software behavior category one by one, including file access fault, memory operation fault, device read-write fault, software information communication fault and network communication fault; the fault location clearly indicates the execution position, code line and machine state of the software at the time of fault; and the software state at the time of fault includes software initialization, data input, data processing and data output.

[0016] 3. Software fault analysis module When the software fails, the fault detection module reads the fault log information, and the module is responsible for analyzing the fault location, fault category and fault software state in the log, and combining the established software behavior fault model to complete the reasoning analysis of the fault cause and the fault location, and finally output accurate fault analysis results.

[0017] Through the above design, the present application can identify potential fault risks in the software development stage, quickly locate faults in the software running stage, greatly improve the efficiency of software fault detection and troubleshooting, reduce manual intervention, reduce software maintenance cost, and is suitable for software systems of different complexity, and has wide application value.

[0018] The software fault detection method based on software behavior analysis and intelligent reasoning provided by the present application has the following beneficial effects: 1. The present application effectively solves the problems of traditional manual review and code testing that cannot comprehensively detect complex software faults and low fault troubleshooting efficiency, establishes a software behavior fault model by analyzing the software runtime logic behavior and fault phenomena, and realizes automatic analysis of software faults with the help of intelligent reasoning ability, thereby significantly improving the software fault detection efficiency.

[0019] 2. The present application classifies and comprehensively identifies software behaviors (including file access, memory operation, device read-write, software information communication and network communication) in detail, ensures the monitoring of all key execution paths of the software, and realizes comprehensive coverage of software behaviors.

[0020] 3. The present application defines detailed software behavior categories and fault triggering conditions, can finely identify software faults, greatly improves the accuracy of fault detection, and reduces false positives and false negatives.

[0021] 4. The present application constructs a software behavior fault model, which can automatically analyze fault causes and locations with intelligent reasoning ability, without the need for a large amount of manual intervention, thereby reducing detection cost and improving detection efficiency.

[0022] 5. This invention combines software behavior fault models and fault log analysis results to achieve automated reasoning and localization of software faults, significantly improving the efficiency and accuracy of fault detection and reducing the time and errors of manual analysis.

[0023] 6. By expanding the functionality of the tool, this invention achieves comprehensive support for cross-platform software systems. Regardless of the operating system on which the software runs, it can perform accurate fault detection, thus meeting the fault detection needs of complex software environments.

[0024] 7. This invention is also applicable to distributed software systems, enabling global fault monitoring and location on each node of a distributed environment, thereby improving the stability and reliability of the distributed system.

[0025] 8. This invention addresses the problem of highly concealed software faults (such as memory overflow, communication anomalies, etc.). Through intelligent detection tools, these hidden faults can be accurately identified and located, avoiding the problems of low efficiency and easy omission in manual analysis.

[0026] 9. This invention reduces reliance on human experience. Even personnel without extensive fault detection experience can accurately identify the cause and location of software faults through intelligent detection tools, thereby improving the accessibility and ease of use of fault detection.

[0027] 10. This invention is applicable to fault detection in various software systems. Whether it is a small application or a large and complex system, this method can improve the efficiency and quality of software maintenance, ensure the stable operation of the software system, and has broad application prospects.

[0028] 11. This invention reduces the uncertainty and subjectivity of manual operation through automated and intelligent fault detection methods, improves the objectivity and consistency of fault detection, and provides strong support for continuous improvement of software quality. Attached Figure Description

[0029] The present invention will be further described below with reference to the accompanying drawings and embodiments: Figure 1 This is a schematic diagram of the software behavior and fault type set of the present invention; Figure 2 This is a schematic diagram of the intelligent software fault detection method of the present invention. Detailed Implementation

[0030] The technical solutions of the present invention will be further described below with reference to the embodiments and accompanying drawings: Example 1 like Figures 1 to 2 As shown, this embodiment provides a software fault detection method based on software behavior analysis and intelligent reasoning, including the following steps: Step 1: Define Software Behavior As Figure 1 shown, the software behavior identification module of the software failure intelligent detection tool defines software behaviors for software systems on the cloud platform, including file access, memory operation, device read-write, software information communication, and network communication. For example, in a cloud storage-related software system, file access behavior involves reading, writing, and deleting operations on cloud storage files; memory operation behavior covers memory allocation and release during software runtime on the cloud server; device read-write may involve operations on virtual devices or physical devices (such as storage hardware devices) in the cloud platform; software information communication includes message passing between different software modules within the cloud platform; and network communication involves data transmission between the cloud platform software and external clients or other cloud services.

[0031] Step 2: Scan Software Code and Record Behavior After the development of the cloud platform software system, as Figure 2 shown, the software behavior identification module is used to scan its code. During the scanning process, the code's behavior is classified according to its logic, such as classifying code that handles cloud storage file upload functions as file access behavior, and identifying and recording the software code location to form a code location and behavior record. At the same time, unique identifier symbols are set for different types of software behavior, such as "FA-" at the beginning of file access behavior and "MO-" at the beginning of memory operation, to facilitate subsequent quick differentiation and invocation of corresponding types of software behavior data.

[0032] Step 3: Define Software Behavior Record Format The software behavior identification module defines the software behavior record format, which includes the record time (accurate to the millisecond, recording the specific time when the behavior occurs), software code location (clearly to the specific code file, function, and code line), software behavior (such as file access, memory operation, etc.), software behavior failure trigger condition (such as file access behavior may trigger a failure due to cloud storage file permission setting error), and software possible failure type (such as file access may cause a failure due to permission issues leading to data unreadable).

[0033] Step 4: Establish Software Behavior Failure Model Based on the recorded software behavior, failure trigger condition, and possible failure type, a software behavior failure model is established. For example, for the file access behavior of the cloud platform software, if the failure trigger condition is a cloud storage file permission error, the corresponding possible failure type is file access failure, which is recorded in the software behavior failure model.

[0034] Step 5: Define Failure Log Information The software fault detection module defines fault log information, including fault time (recording the specific time the fault occurred), processor register values ​​at the time of the fault (reflecting the processor's state at the time of the fault), fault code (a code that uniquely identifies the fault type), fault category (such as file access fault, memory operation fault, etc., corresponding to software behavior categories), and software state at the time of the fault (including states such as software initialization, data input, data processing, and data output; for example, when cloud platform software processes user-uploaded files, the fault may occur in the initial receiving stage or data verification stage of data input).

[0035] Step 6: Establish a fault log information parsing mechanism The software fault detection module establishes a fault log information parsing mechanism, which can accurately read and parse various information in the fault log. For example, for fault codes, it can parse the corresponding fault category and approximate fault cause according to preset encoding rules; for software state information at the time of the fault, it can determine the specific stage of the software's state when the fault occurred by combining the software's runtime timing information.

[0036] Step 7: Analyze software fault log information When the cloud platform software malfunctions, the software fault detection module reads the fault log information and parses it according to the established parsing mechanism. First, it reads the fault log information, then parses out the fault location (e.g., the specific code execution location on the cloud server), fault type (e.g., network communication failure), and faulty software state (e.g., the transmission stage during data output). When parsing the faulty software state, it combines the timing information of the cloud platform software's operation to determine the specific transmission steps in the data output stage when the fault occurred, refining the dimensions of the fault analysis.

[0037] Step 8: Determine the location of the fault and the initial cause of the fault. The software fault detection module determines the location and preliminary cause of the fault based on the processor's register values ​​at the time of the fault. For example, if the register values ​​indicate an anomaly during network data packet processing, combined with the network communication behavior of the cloud platform software, the initial judgment is that the fault location may be in the code segment for network data reception or transmission, and the preliminary cause may be an unstable network connection or an incorrect data packet format.

[0038] Step 9: Determine the final cause of the failure The software fault detection module combines fault codes to determine the final cause of the fault. For example, if the fault code corresponds to an error in cloud storage file permissions, combined with the preliminary judgment and the software behavior fault model, the final cause of the fault is determined to be improper access permission settings for specific files by the cloud platform.

[0039] Step 10: Determine the location and condition of the software fault code. The software fault detection module determines the location and condition of software fault codes based on the fault location, the ultimate cause of the fault, and the software behavior fault model. For example, based on the ultimate cause of a network communication fault and relevant records of network communication behavior in the software behavior fault model, the fault code is located in the function handling network connection initialization, and the fault condition is a network address configuration error. Simultaneously, during the judgment process, historical behavior data in the software behavior fault model is compared and analyzed with current fault data to improve the accuracy of the judgment.

[0040] Through the above steps, the software fault detection method based on software behavior analysis and intelligent reasoning can effectively detect and locate faults in software systems on cloud platforms, helping developers quickly resolve software faults and ensuring the stable operation of cloud platform software.

[0041] Example 2 In another preferred embodiment, based on Embodiment 1, this embodiment provides a software fault intelligent detection method based on software behavior analysis and intelligent reasoning. This method achieves automated detection and localization of software faults by constructing a software behavior fault model. The specific implementation process is as follows: 1. System Architecture and Tool Design First, design and implement an intelligent software fault detection tool, which consists of two core modules: a software behavior recognition module and a software fault detection module. (1) Software Behavior Recognition Module: Responsible for scanning software code, identifying software behavior, and classifying the behavior into five categories based on code logic: file access, memory operation, device read / write, software information communication, and network communication. At the same time, it records the code location, behavior type, fault triggering conditions, and possible fault types.

[0042] (2) Software Fault Detection Module: Responsible for capturing fault information during software runtime, establishing fault logs, and parsing fault logs to locate the fault location and cause. The fault log contains information such as fault time, processor register values ​​at the time of the fault, and fault codes.

[0043] 2. Implementation of the software behavior recognition module (1) Code scanning and behavior classification: The source code of the software under test is scanned using static code analysis tools to identify all code segments involving file access, memory operation, device read / write, software information communication, and network communication. Based on the code logic, these behaviors are classified and their code locations are recorded.

[0044] (2) Definition of fault triggering conditions: For each type of behavior, define its possible fault triggering conditions. For example, the fault triggering conditions for file access behavior include file error, read / write permission error, file corruption, etc.; the fault triggering conditions for memory operation behavior include memory overflow, memory permission error, insufficient memory space, etc.

[0045] (3) Behavior recording and model building: The identified software behaviors and their fault triggering conditions are recorded in the model file to form the initial framework of the software behavior fault model.

[0046] 3. Implementation of the software fault detection module (1) Fault Log Recording: During software operation, when a fault is detected, the fault information is immediately captured and recorded in the fault log. The fault log contains key information such as the fault time, the processor register value at the time of the fault, and the fault code.

[0047] (2) Fault Log Parsing: Develop a fault log parsing mechanism that can automatically read and parse the information in the fault log. By analyzing register values ​​and fault codes, the location of the fault and possible causes of the fault can be preliminarily determined.

[0048] (3) Fault location and cause analysis: Combining the software behavior fault model and the fault log analysis results, further analyze the specific location and cause of the fault. For example, if the fault log shows that a certain memory access operation caused the system to crash, and the operation is marked as a risk point that may cause memory overflow in the software behavior fault model, it can be inferred that the fault was caused by memory overflow.

[0049] 4. Example Verification Taking a complex software system as an example, the aforementioned intelligent software fault detection tool was applied for fault detection. After the software development was completed, the software behavior recognition module scanned the code, identified all key behaviors and their fault triggering conditions, and constructed a software behavior fault model. During software operation, when a network communication fault was detected, the fault detection module immediately recorded the fault information and generated a fault log. By parsing the fault log and combining it with the software behavior fault model, the fault location was successfully identified, and the cause of the fault was determined to be a network connection error.

[0050] Example 3 In another preferred embodiment, based on embodiments 1 and 2, this embodiment provides an intelligent software fault detection method based on software behavior analysis and intelligent reasoning. For cross-platform software (such as software that supports both Windows and Linux systems), this embodiment adds support for multi-platform code compatibility to the existing intelligent software fault detection tool. By expanding the functionality of the software behavior recognition module, it can identify and process specific behavior patterns and fault triggering conditions under different platforms. Simultaneously, the software fault detection module adds the ability to parse fault logs from multiple platforms, ensuring accurate detection and location of software faults in different operating system environments.

[0051] Example 4 In another preferred embodiment, based on embodiments 1 and 2, this embodiment provides a software fault intelligent detection method based on software behavior analysis and intelligent reasoning. For distributed software systems, this embodiment deploys the intelligent software fault detection tool on various nodes in the distributed environment to achieve global fault monitoring and location. Through inter-node communication mechanisms, fault information is shared in real time and the causes of faults are analyzed collaboratively. Support for distributed-specific behaviors (such as remote procedure calls and message queue communication) is added to the software behavior recognition module, and aggregated analysis and location of distributed faults are implemented in the software fault detection module.

[0052] Example 5 In another preferred embodiment, based on embodiments 1-4, this embodiment provides a software fault detection method based on software behavior analysis and intelligent reasoning. The detailed implementation steps and methods are as follows: I. Implementation Prerequisites and Tool Development In this embodiment, the intelligent software fault detection method is implemented using an intelligent software fault detection tool. This tool requires pre-completion of core module development and basic configuration, specifically including: Core module construction: Develop a software behavior recognition module and a software fault detection module. The software behavior recognition module is responsible for scanning software code, identifying software behavior, and establishing a software behavior fault model; the software fault detection module is responsible for defining fault logs, parsing log information, and locating the cause and location of faults.

[0053] Basic data definition: In the tool's model file, the basic attributes of software behavior and software faults are predefined—software behavior is divided into five categories: file access, memory operation, device read / write, software information communication, and network communication (e.g., ...). Figure 1 As shown, Figure 1(This is a schematic diagram of the software behavior and fault type set of the present invention). Software faults are defined as unexpected behaviors during software operation, including file faults, memory overflows, unavailable device resources, and abnormal external communication, and the correlation between the fault triggering conditions, phenomena and fault location, external conditions, and fault causes is clearly defined.

[0054] II. Specific Implementation Steps This embodiment uses a certain enterprise-level management software (hereinafter referred to as "target software") as the detection object, and follows the process of "behavior recognition - model building - fault detection - cause analysis". The specific steps are as follows (e.g. Figure 2 As shown, Figure 2 (This is a schematic diagram of the intelligent software fault detection method of the present invention) Step 1: Software Behavior Definition and Identification Configuration The software behavior recognition module of the intelligent software fault detection tool is activated. Based on the application scenario of the target software (involving file storage, data processing, peripheral device interaction, internal process communication, and remote server connection), the module confirms the classification rules of software behavior: file access behavior is associated with file operation functions such as fopen / fwrite in the code; memory operation behavior is associated with dynamic memory functions such as malloc / free and local / global variable read / write logic; device read / write behavior is associated with peripheral operation functions such as read / write; software information communication behavior is associated with semaphore and message queue functions such as sem_wait / msg_send; and network communication behavior is associated with network functions such as socket / connect.

[0055] The configuration module's code scanning parameters include the scan range (the source code directory of the target software, including application layer and data layer code files), scan depth (penetrating call relationships and identifying behavior in nested functions), and record format (the preset record fields are "record time - software code location (file path + line number) - software behavior type - fault triggering condition - possible fault type").

[0056] Step 2: Target software code scanning and behavior logging After the target software is developed and compiled, the software behavior recognition module is run to perform a full scan of the target software's source code. During the scan, the module automatically categorizes behaviors based on code logic: When the function call fopen(" / data / config.ini","r") is detected in the code, it is identified as a "file access behavior". The code location is recorded as " / src / utils / file.c:45". The fault triggering conditions of this behavior are matched (file error: config.ini file does not exist; read / write permission error: target software does not have read permission to the / data directory; file corruption: config.ini file format is abnormal). The possible fault type is "file access failure". When the code `int*buf=(int*)malloc(1024);` and subsequently `buf

[2048] =0;` is scanned, it is identified as "memory operation behavior", and the code location is recorded as " / src / data / process.c:120". It matches the fault triggering conditions (memory overflow: array out of bounds access; memory permission error: malloc returns a null pointer but still reads and writes; insufficient memory space: insufficient system memory causes malloc to fail), and the possible fault type is "memory operation fault". Similarly, the identification and recording of device read / write (e.g., calling read(" / dev / usb",buf,64)), software information communication (e.g., calling sem_post(&data_sem)), and network communication (e.g., calling connect("192.168.1.100",8080)) behaviors are completed, forming a complete association table of "code location-behavior-fault condition-fault type".

[0057] Step 3: Establishing a Software Behavior Fault Model The software behavior recognition module constructs a software behavior fault model based on the association table recorded in step 2: A tree structure model is established with "software behavior type" as the first-level index and "fault triggering condition" as the second-level index. For example, under the "file access behavior" index, there are three second-level indexes: "file error", "read / write permission error", and "file corruption". Each secondary index is associated with a corresponding "fault phenomenon" and "fault location characteristic": for example, "file error (config.ini does not exist)" is associated with the fault phenomenon "the target software prompts 'configuration file is missing' when starting up", and the fault location characteristic is "the line of code that calls the fopen function and the upstream configuration file path judgment logic"; "memory overflow (array out of bounds)" is associated with the fault phenomenon "the target software suddenly crashes during operation, and the system log prompts 'segmentation fault'", and the fault location characteristic is "the line of code that reads and writes data after dynamic memory allocation"; The model data is stored in the tool's model file, supporting rapid querying and matching during subsequent fault detection.

[0058] Step 4: Configure Fault Log Definition and Parsing Mechanism Start the software fault detection module and define the format and content of the fault log: The log includes "fault time (accurate to milliseconds) - processor register value at the time of the fault (such as EIP, ESP register value) - fault code (refer to the system error code of the target software running environment, such as ENOENT (2) and EACCES (13) under Linux) - fault category (corresponding to the software behavior category) - fault software status (software initialization / data input / data processing / data output)"; Configure log parsing mechanism: The module presets the mapping rules between register values ​​and fault locations (such as the memory address pointed to by the EIP register value corresponding to the code segment address of the target software, which can be traced back to the specific code line), and the matching rules between fault codes and fault causes (such as ENOENT corresponding to "file does not exist", EACCES corresponding to "insufficient permissions"). It also supports reading the symbol table file of the target software to achieve accurate mapping from register addresses to code lines.

[0059] Step 5: Target software operation and fault log collection Deploy the configured intelligent software fault detection tool and the target software in the same operating environment (in this example, a Linux CentOS7 system with 8GB of memory and an Intel i7-10700 CPU), and start the tool's log collection function; Run the target software to simulate different usage scenarios: including software startup (initialization scenario), importing Excel data (data input scenario), generating statistical reports (data processing scenario), exporting reports to printer (data output + device read / write scenario), and synchronizing data to a remote server (network communication scenario). When the target software malfunctions in the "Export Report to Printer" scenario (manifested as "Printer not responding, software prompts 'Device connection failed'"), the software fault detection module automatically collects fault information and generates a fault log, as shown in the following example: Fault time: 2024-05-20 14:30:25.123 Register values: EIP=0x004028a0, ESP=0xbfffdf80 Fault code: ENODEV (19, corresponding to "Device Not Found") Fault Category: Device Read / Write Fault Faulty software status: During data output Step 6: Fault Log Analysis and Fault Location The software fault detection module reads the fault log generated in step 5 and processes it according to the preset parsing mechanism: Parsing register values: By looking up the code location corresponding to EIP=0x004028a0 in the target software symbol table, we get " / src / device / printer.c:89", which calls the function open(" / dev / lp0", O_WRONLY) (printer device file); The fault code ENODEV (19) matches as "Device not found or not connected"; Analyze the fault category and status: Confirm that the fault belongs to "device read / write fault" and occurs "during data output" (i.e., during report export).

[0060] The module calls the software behavior fault model established in step 3 to perform multi-dimensional matching: Using "device read / write failure" as the index, the corresponding failure triggering conditions are queried in the model, and "device invalid (device file does not exist or is not connected)" is matched. By combining the code location " / src / device / printer.c:89" with the "fault location characteristics (device file open code line)" corresponding to "device invalid" in the model, the fault code location is confirmed to be this code line; Combining the fault symptom "printer not responding" with external conditions (checking the physical printer revealed it was not powered on and not connected to the host), the cause of the fault was finally determined: the printer not being powered on caused the device file / dev / lp0 to be inaccessible, triggering a "device invalid" fault when the target software called the open function.

[0061] Step 7: Output and Verification of Fault Results The software fault intelligent detection tool outputs the fault analysis results in the form of a report, including "fault code location ( / src / device / printer.c:89), fault cause (printer is not powered on, device file cannot be accessed), fault triggering condition (invalid device), and repair suggestions (check printer power and connection, restart printer service)". The technicians verified the report: after powering on and connecting the printer, restarting the target software, and re-executing the report export operation, the target software output the report normally, the fault was eliminated, proving that the fault detection and location results of the method of the present invention are accurate and effective.

[0062] Through the application of this embodiment, the efficiency of fault detection and troubleshooting of the target software is significantly improved: During the software development phase: By scanning the code through the software behavior recognition module, three potential faults (including one memory overflow risk and two file access permission risks) can be identified in advance to prevent the faults from flowing into the operation phase; Operational phase: The printer malfunction mentioned above took only 2 minutes from occurrence to location, which is more than 30 times more efficient than traditional manual troubleshooting (which requires checking codes, device connections, and system configurations one by one, taking an average of more than 1 hour). Cost control: Reduce manual intervention, lower the cost of fault maintenance of target software by 40%, and avoid business interruption losses caused by faults (such as business delays caused by report export failures).

[0063] Through the detailed description of the above five embodiments, the "early identification-rapid location-precise repair" of software faults is effectively realized. It is applicable to various complex software systems and has strong practicality and scalability.

[0064] In the preferred embodiment, the software behaviors in step 1 include file access, memory operations, device read / write, software information communication, and network communication. The above settings can comprehensively cover all kinds of operations during software operation, providing a solid foundation for accurate monitoring and analysis of software behaviors. Through meticulous control of these behaviors, anomalies can be effectively identified, potential security risks can be prevented in advance, and the stable operation of the system can be ensured.

[0065] In the preferred scheme, the specific fault triggering conditions for software behaviors are as follows: for file access behaviors, the fault triggering conditions are file error, read / write permission error, and file corruption; for memory operation behaviors, the fault triggering conditions are memory overflow, memory permission error, and insufficient memory space; for device read / write behaviors, the fault triggering conditions are invalid device, incorrect device permission, and incorrect device status; for software information communication behaviors, the fault triggering conditions are semaphore error, message queue full, and communication permission error; and for network communication behaviors, the fault triggering conditions are network connection error and incorrect network address. These settings effectively improve the accuracy of software fault detection and help developers quickly locate the root cause of problems. In practical applications, these triggering conditions can be flexibly adjusted and expanded according to the characteristics of different software to better meet diverse fault diagnosis needs.

[0066] In a preferred embodiment, during step 2, the software behavior recognition module categorizes code behavior based on code logic and identifies and records the location of the software code, forming a code location and behavior record. This setup ensures that problematic code can be quickly located in subsequent analysis, while also providing a clear understanding of code behavior patterns. This approach not only improves the efficiency of software security detection but also provides a strong basis for subsequent code optimization and security hardening.

[0067] In the preferred embodiment, during step 2, the software behavior recognition module sets unique identifiers for different types of software behavior when recording software behavior. This allows for rapid differentiation and retrieval of corresponding software behavior data during subsequent software behavior fault model building and fault analysis. This setting effectively improves the efficiency of fault model construction and reduces data processing time. The unique identifiers also enhance data readability, facilitating rapid problem location by technical personnel. Furthermore, it provides solid data support for subsequent software behavior optimization and security protection.

[0068] In the preferred embodiment, the software behavior recording format in step 3 includes recording time, software code location, software behavior, software behavior fault triggering conditions, and possible software fault types. The above settings can record various key information during software operation in detail and systematically. The recording time can accurately locate the moment when the behavior occurs, the software code location facilitates finding the source of the problem, the software behavior and fault triggering conditions can assist in analyzing the cause of the fault, and the possible fault types provide direction for subsequent repairs.

[0069] In the preferred embodiment, the fault log information defined by the software fault detection module in step 5 includes the fault time, the processor register value at the time of the fault, the fault code, the fault category, and the software state at the time of the fault. The fault category corresponds to the software behavior category, including file access fault, memory operation fault, device read / write fault, software information communication fault, and network communication fault. The software state at the time of the fault includes software initialization, data input, data processing, and data output. The above settings can more comprehensively and accurately record various key information when a software fault occurs. By clearly defining the fault category, the problem area can be quickly located. Knowing the software state at the time of the fault allows for in-depth analysis of the fault generation process, providing a strong basis for subsequent fault investigation and repair.

[0070] In the preferred embodiment, in step 7, when analyzing software fault log information, the software fault detection module first reads the fault log information and then parses the fault location, fault category, and faulty software status in the fault log. When parsing the faulty software status in the fault log, the software fault detection module combines the timing information of software operation to determine the specific stage the software was in when the fault occurred, including the initial receiving stage and data verification stage during data input, further refining the dimensions of fault analysis. These settings enable more accurate location of the specific link in the software fault, providing a clear direction for subsequent fault repair. Simultaneously, this meticulous analysis effectively avoids misjudgments of faults, improves the efficiency and accuracy of software fault handling, and ensures stable software operation.

[0071] In the preferred embodiment, the fault location determined by the software fault detection module in step 8 includes the software execution location, code line, and machine state at the time of the fault. Furthermore, when determining the location of the software fault code and the fault conditions, historical behavior data in the software behavior fault model is compared and analyzed with current fault data to improve the accuracy of the judgment. These settings can accurately pinpoint the specific stage where the software fault occurs, providing clear guidance for subsequent fault repair. Through comprehensive analysis of historical and current data, misjudgments are effectively reduced, enhancing the reliability and effectiveness of software fault detection and ensuring stable software operation.

[0072] In the preferred embodiment, the software behavior fault model in step 10 records the software behavior, fault conditions, fault phenomena, and fault locations. The behavior, fault conditions, fault phenomena, and fault locations of each piece of software are determined based on the following methods: identifying software behavior based on software code scanning results; detecting software fault triggering conditions through software behavior; defining fault phenomena based on fault triggering conditions; outputting fault logs based on fault phenomena; and locating fault locations by analyzing fault logs. This setup systematically tracks the entire software fault chain, forming a complete closed loop from behavior identification to location positioning. It not only improves fault troubleshooting efficiency but also optimizes the model through the accumulation of historical fault data, providing accurate fault prevention basis for subsequent software version iterations.

[0073] In a preferred embodiment, the intelligent software fault detection tool includes a software behavior recognition module and a software fault detection module. The software behavior recognition module is used to scan software code, identify software behavior, and establish a software behavior fault model. The software fault detection module is used to locate software faults and determine their causes based on the software behavior fault model and software fault logs. This configuration makes software fault detection more accurate and efficient, and can quickly pinpoint problematic code segments. At the same time, the modeling function of the behavior recognition module can predict potential faults in advance, and the fault detection module can respond quickly accordingly, greatly shortening the fault investigation time and improving the stability of software operation.

[0074] In the preferred embodiment, the software fault refers to unexpected behavior that occurs during software operation, including file failure, memory overflow, unavailable device resources, and abnormal external communication. The triggering conditions and phenomena of these faults are related to the fault location, external conditions, and fault causes. The above settings can accurately locate the problematic links in the software operation, making it easier for developers to quickly troubleshoot and repair. By recording fault triggering conditions, phenomena, and other information in detail, it can also provide a basis for subsequent software optimization, effectively improving the stability and reliability of the software.

[0075] In the preferred approach, during the software development phase, software fault phenomena and their corresponding triggering conditions are predefined. After software development is complete, the software code is scanned and its logical behavior analyzed. Based on the software behavior and fault triggering conditions, potential fault phenomena during software operation are identified, providing foundational data for establishing a software behavior fault model. This approach effectively improves the accuracy of software fault prediction and reduces software operation risks. By clearly defining the relationship between faults and triggering conditions in advance, the root cause of problems can be quickly located, providing a strong basis for subsequent software optimization and maintenance, and ensuring stable software operation.

[0076] In summary, this invention proposes a software fault detection method based on software behavior analysis and intelligent reasoning. This method effectively addresses the shortcomings of traditional manual review and code testing in comprehensively detecting complex software faults, as well as the low efficiency of fault diagnosis. By deeply analyzing the logical behavior and fault phenomena during software runtime, this invention successfully establishes a software behavior fault model and, with the help of intelligent reasoning capabilities, achieves automatic analysis of software faults, thereby significantly improving the efficiency of software fault detection while reducing the cost of manual intervention.

[0077] In terms of technical implementation, this invention is the first to deeply integrate software behavior analysis with intelligent reasoning technology, forming a unique and complete software fault detection method, providing a completely new perspective for the field of fault detection. By defining software behavior categories in detail, such as file access, memory operation, device read / write, software information communication, and network communication, and designing specific fault triggering conditions for each type of behavior, this invention achieves refined identification of software faults. Simultaneously, the constructed software behavior fault model can automatically infer possible fault phenomena during software operation based on software behavior and fault triggering conditions, providing a solid scientific basis for fault detection.

[0078] Furthermore, this invention creatively proposes using intelligent model computational reasoning capabilities to automatically analyze software faults. This method not only significantly improves the efficiency and accuracy of fault detection but also greatly reduces reliance on human experience. Through the collaborative design of the software behavior recognition module and the software fault detection module, this invention can comprehensively and systematically detect software faults, effectively solving the problem of low fault diagnosis efficiency in traditional methods. Simultaneously, by analyzing fault log information and combining it with the software behavior fault model, this invention can accurately determine the fault location and cause, providing developers with powerful fault repair support, thereby greatly improving the efficiency and quality of software maintenance.

Claims

1. A software fault detection method based on software behavior analysis and intelligent inference, characterized in that, The method comprises the following steps: Step 1: a software behavior identification module of the software fault intelligent detection tool defines the behavior of the software; Step 2: after the software to be detected is developed, the software behavior identification module scans the software code to be detected, and records the behavior of the software to be detected; Step 3: the software behavior identification module defines a software behavior record format; Step 4: the software behavior identification module establishes a software behavior fault model according to the recorded software behavior, a fault triggering condition and a possible fault type; Step 5: a software fault detection module of the software fault intelligent detection tool defines fault log information; Step 6: the software fault detection module establishes a fault log information analysis mechanism; Step 7: the software fault detection module analyzes the software fault log information; Step 8: the software fault detection module determines a fault position and a preliminary fault cause according to the register value of the processor at the time of the fault; Step 9: the software fault detection module determines a final fault cause in combination with a fault code; Step 10: the software fault detection module determines a software fault code position and a fault condition according to the fault position, the final fault cause and the software behavior fault model. 2.The software fault detection method based on software behavior analysis and intelligent reasoning according to claim 1, characterized in that: The software behavior in the step 1 comprises file access, memory operation, device read-write, software information communication and network communication. 3.The software fault detection method based on software behavior analysis and intelligent reasoning according to claim 2, characterized in that, The fault triggering condition corresponding to the software behavior is as follows: the fault triggering condition of the file access behavior is file error, read-write permission error and file damage; the fault triggering condition of the memory operation behavior is memory overflow, memory permission error and insufficient memory space; the fault triggering condition of the device read-write behavior is invalid device, device permission error and device state error; the fault triggering condition of the software information communication behavior is semaphore error, message queue full and communication permission error; and the fault triggering condition of the network communication behavior is network connection error and network address error.

4. The method of claim 1, wherein the method further comprises: In the step 2, the software behavior identification module classifies the behavior of the code according to the code logic in the process of scanning the software code, identifies and records the software code position, and forms a code position and behavior record.

5. The method of claim 1, wherein the method further comprises: determining a software fault based on the software behavior analysis and the intelligent inference. In the step 2, the software behavior identification module sets unique identifier symbols for different types of software behavior when recording the software behavior, so that the corresponding type of software behavior data can be quickly distinguished and called in the subsequent establishment of the software behavior fault model and the fault analysis process.

6. The method of claim 1, wherein the method further comprises: The software behavior record format in the step 3 comprises record time, software code position, software behavior, software behavior fault triggering condition and software possible fault type.

7. The method of claim 1, wherein the method further comprises: determining a software fault based on the software behavior analysis and the intelligent inference. The fault log information defined by the software fault detection module in the step 5 comprises fault time, register value of the processor at the time of the fault, fault code, fault category and software state at the time of the fault; the fault category corresponds to the software behavior category, and comprises file access fault, memory operation fault, device read-write fault, software information communication fault and network communication fault; and the software state at the time of the fault comprises software initialization, data input, data processing and data output. 8.The software fault detection method based on software behavior analysis and intelligent inference according to claim 1, characterized in that: In the step 7, the software fault detection module reads the fault log information, and then analyzes the fault position, fault category and fault software state in the fault log. The software fault detection module, when analyzing the fault software state in the fault log, combines the timing information of software running to determine the specific stage of the software in the corresponding state when the fault occurs, including the initial receiving stage of data input, the data verification stage, and further refines the fault analysis dimension.

9. The method of claim 7, wherein the method further comprises: The fault position determined by the software fault detection module in step 8 includes the software execution position, code line, and machine state at the time of the fault, and when determining the software fault code position and fault condition, the historical behavior data and current fault data in the software behavior fault model are compared and analyzed.

10. The method of claim 1, wherein the software behavior analysis and intelligent inference based software fault detection method is characterized by, In step 10, the software behavior fault model records the behavior, fault condition, fault phenomenon, and fault position of the software, and the behavior, fault condition, fault phenomenon, and fault position of each software are determined based on the following methods: identifying the behavior of the software based on the software code scanning result; detecting the software fault trigger condition through software behavior; Defining the fault phenomenon based on the fault trigger condition; outputting the fault log through the fault phenomenon; and positioning the fault position by analyzing the fault log.

Images