Software fault analysis method and device, computer equipment, readable storage medium and program product

Abstract

The application relates to a software fault analysis method and device, computer equipment, a readable storage medium and a program product. The method comprises the following steps: in response to detecting that a software interface of to-be-tested software is abnormal, acquiring interface fault description data; according to a pre-constructed mapping relationship between an interface phenomenon and a software function component, determining target function component information; inputting the interface fault description data and the target function component information into a fine-tuned large model to output fault symptom context information; the fault symptom context information is used for indicating a fault cause and effect chain causing a fault phenomenon; inputting the fault symptom context information into an expert system integrated with a knowledge graph to output a function fault positioning result; the function fault positioning result is obtained by the expert system according to information associated with the fault symptom context information searched in the knowledge graph. The method can efficiently and intelligently analyze software faults.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and in particular to a software fault analysis method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] In the process of basic software testing, the analysis and handling of software faults has always been a crucial step. Currently, software systems are becoming increasingly complex, with diverse interface forms and intricate interaction logic, leading to a growing variety of functional failure modes. This presents numerous challenges to traditional fault analysis methods. For example, rule-based analysis methods struggle to adapt to diverse interface types and complex interaction logic, while existing fault diagnosis systems based on knowledge bases or machine learning suffer from difficulties in knowledge updates, limited generalization capabilities, and a lack of interpretability. These problems severely impact the efficiency and quality of software testing, increasing the costs of software development and maintenance.

[0003] Therefore, developing a new method that can efficiently and intelligently analyze and handle software faults has become an important issue that urgently needs to be addressed in the field of software engineering. Summary of the Invention

[0004] Therefore, it is necessary to provide a software fault analysis method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can efficiently and intelligently analyze software faults, addressing the aforementioned technical problems.

[0005] Firstly, this application provides a software fault analysis method, including:

[0006] In response to the detection of an anomaly in the software interface of the software under test, interface fault description data is obtained; the interface fault description data is used to describe the fault phenomenon of the software interface.

[0007] Based on the pre-constructed mapping relationship between interface phenomena and software functional components, the target functional component information is determined; the target functional component information includes information about the functional components associated with the fault phenomenon.

[0008] The interface fault description data and the target functional component information are input into the fine-tuned large model, and fault symptom context information is output. The fault symptom context information is used to indicate the fault causal chain that causes the fault phenomenon. The fault symptom context information is obtained by the fine-tuned large model based on the software domain knowledge obtained by fine-tuning and the zero-initialization attention mechanism, by analyzing the interface fault description data and the target functional component information.

[0009] The contextual information of the fault symptoms is input into an expert system integrated with a knowledge graph, and the functional fault location result is output. The knowledge graph uses entities of the basic software as nodes and the relationships between the entities as edges between the nodes. The functional fault location result is obtained by the expert system through reasoning based on information retrieved from the knowledge graph that is associated with the contextual information of the fault symptoms.

[0010] In one embodiment, the method further includes:

[0011] The front-end interface code and back-end function code of the basic software are analyzed using a large language model to extract the component tree structure;

[0012] Based on the component tree structure, a mapping table between interface components and backend functional modules is constructed, and the component types and interaction logic are labeled to obtain the labeled mapping table.

[0013] Based on historical software fault data, fault mode feature vectors of the interface components are generated, and the labeled mapping table and the fault mode feature vectors are stored in the fault knowledge base to form the mapping relationship.

[0014] In one embodiment, the method further includes:

[0015] Obtain a dataset of interface faults in the basic software;

[0016] A learnable cue vector is inserted at the input of the Transformer layer of the pre-trained large model; the length of the learnable cue vector is related to the complexity of the fault analysis task.

[0017] Based on the interface fault dataset of the basic software, the pre-trained large model with the inserted learnable cue vectors is fine-tuned to obtain the fine-tuned large model.

[0018] In one embodiment, the step of fine-tuning the pre-trained large model with the learnable cue vector inserted based on the interface fault dataset of the basic software to obtain the fine-tuned large model includes:

[0019] During the fine-tuning process, the interface fault clues contained in the interface fault dataset are used as new instruction signals and dynamically injected into the pre-trained large model in combination with zero-gating technology to eliminate the interference of invalid or noisy features on the instruction following ability.

[0020] In one embodiment, the pre-trained large model is fine-tuned using a hierarchical, cascaded multi-task adapter group structure; the fine-tuning of the pre-trained large model with the learnable cue vector inserted based on the interface fault dataset of the underlying software to obtain the fine-tuned large model includes:

[0021] For the pre-trained large model with the inserted learnable cue vector, the weights are incrementally updated through low-rank matrix factorization based on low-rank adaptive technology, and the multi-task routing layer is configured to automatically allocate adapter branches according to the fault type.

[0022] A dual-stream attention mechanism is constructed to separate the pre-trained knowledge stream from the fault feature stream. Orthogonal constraints are used to ensure feature decoupling, and dynamic gradient masks are used to suppress noise interference.

[0023] Based on the adapter branches allocated by the multi-task routing layer and the dual-stream attention mechanism, a two-stage optimization strategy is adopted for fine-tuning: the first stage trains the multi-task adapter group structure with fixed master model parameters; the second stage performs full parameter fine-tuning with a preset learning rate and injects adversarial samples containing node confusion or attribute missing during the fine-tuning process.

[0024] After fine-tuning the two-stage optimization strategy, the fine-tuned large model is obtained.

[0025] In one embodiment, the entity of the basic software includes at least one of the components, interfaces, and functions of the basic software; the association relationship includes at least one of logical connection relationship and functional relationship;

[0026] The step of inputting the contextual information of the fault symptoms into an expert system integrated with a knowledge graph and outputting the functional fault location result includes:

[0027] Extract the contextual information of the fault symptoms and the information associated with the entity, and use it as the target retrieval entity;

[0028] In the knowledge graph, starting from the target retrieval entity, a topological traversal is performed along the logical connection relationship and / or interaction relationship to obtain a connected subgraph that is directly adjacent to or indirectly connected to the target retrieval entity.

[0029] Based on the set of associated entities contained in the connected subgraph, determine the information associated with the context information of the fault symptoms.

[0030] In one embodiment, the method further includes:

[0031] Based on the test result report corresponding to the software under test, new fault keywords and new fault mode features are extracted; the test result report is a feedback report generated based on the functional fault location results.

[0032] The expert system feeds back the new fault keywords and the new fault mode features to the knowledge graph.

[0033] Based on the feedback, perform at least one of the following operations on the knowledge graph: add new knowledge, correct error information, or delete outdated information, so as to achieve dynamic self-updating of the knowledge graph.

[0034] Secondly, this application also provides a software fault analysis apparatus, comprising:

[0035] The acquisition module is used to acquire interface fault description data in response to the detection of an anomaly in the software interface of the software under test; the interface fault description data is used to describe the fault phenomenon of the software interface.

[0036] The determination module is used to determine the target functional component information based on the pre-built mapping relationship between interface phenomena and software functional components; the target functional component information includes information about the functional components associated with the fault phenomenon;

[0037] The information output module is used to input the interface fault description data and the target functional component information into the fine-tuned large model and output fault symptom context information; the fault symptom context information is used to indicate the fault causal chain that causes the fault phenomenon; the fault symptom context information is obtained by the fine-tuned large model based on the software domain knowledge obtained by fine-tuning and the zero-initialization attention mechanism, analyzing the interface fault description data and the target functional component information;

[0038] The result output module is used to input the fault symptom context information into an expert system integrated with a knowledge graph and output the functional fault location result. The knowledge graph uses entities of the basic software as nodes and the relationships between the entities as edges between the nodes. The functional fault location result is obtained by the expert system through reasoning based on the information retrieved from the knowledge graph that is associated with the fault symptom context information.

[0039] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program that, when executed by the processor, implements the steps of the method described above.

[0040] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps of the above-described method.

[0041] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps of the above-described method.

[0042] The aforementioned software fault analysis method, apparatus, computer equipment, computer-readable storage medium, and computer program product, in response to the detection of anomalies in the software interface of the software under test, acquire interface fault description data; the interface fault description data is used to describe the fault phenomena of the software interface; based on the pre-constructed mapping relationship between interface phenomena and software functional components, target functional component information is determined; the target functional component information includes information about functional components associated with the fault phenomena; the interface fault description data and target functional component information are input into a fine-tuned large model, and fault symptom context information is output; the fault symptom context information is used to indicate the fault causal chain that causes the fault phenomena; the fault symptom context information is obtained by the fine-tuned large model based on the software domain knowledge obtained through fine-tuning and a zero-initialization attention mechanism, analyzing the interface fault description data and target functional component information; the fault symptom context information is input into an expert system integrated with a knowledge graph, and the functional fault localization result is output; the knowledge graph uses entities of the basic software as nodes, and the relationships between entities as edges between nodes; the functional fault localization result is obtained by the expert system through reasoning based on information retrieved from the knowledge graph that is associated with the fault symptom context information.

[0043] In this way, by responding to the detection of anomalies in the software interface of the software under test, interface fault description data is obtained. Based on the pre-built mapping relationship between interface phenomena and software functional components, the target functional component information is determined. This allows direct association of interface fault phenomena with specific functional components, avoiding blind matching in the entire codebase and thus adapting to diverse interface types. Subsequently, the interface fault description data and target functional component information are input into a fine-tuned large model. Utilizing the software domain knowledge obtained through fine-tuning and a zero-initialization attention mechanism, the contextual information of the fault symptoms that caused the fault phenomena is accurately derived. This overcomes the shortcomings of rule-based methods in related technologies, which struggle to handle complex interactive logic, and reduces reliance on manually written rules. Finally, the contextual information of the fault symptoms is input into an expert system integrated with a knowledge graph. Based on the entities of the basic software and the relationships between entities, fault mode and cause reasoning is performed, providing an explicit, structured reasoning path for the fault analysis process and enhancing the interpretability of the fault location results. Thus, through the coordinated efforts of the above steps, comprehensive and accurate analysis of complex software faults is achieved, significantly improving the automation level and testing efficiency of software fault analysis. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 This is a flowchart illustrating a software fault analysis method in one embodiment;

[0046] Figure 2 This is a schematic diagram illustrating an example of an interface fault analysis process based on a large language model in one embodiment.

[0047] Figure 3 This is a schematic diagram illustrating another interface fault analysis process based on a large language model in one embodiment;

[0048] Figure 4 This is a schematic diagram of the analysis process for a functional failure in one embodiment;

[0049] Figure 5 This is a schematic diagram of the analysis process for another functional failure in one embodiment;

[0050] Figure 6 This is a logical relationship architecture diagram of interface fault analysis and functional fault analysis in one embodiment;

[0051] Figure 7 This is a structural block diagram of a software fault analysis device in one embodiment;

[0052] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0054] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0055] In one embodiment, such as Figure 1 As shown, a software fault analysis method is provided, which can be applied to computer equipment. It is understood that the computer equipment can be a terminal, a server, or a system including both a terminal and a server. This embodiment illustrates the application of this method to a computer equipment, and the method includes the following steps:

[0056] Step S110: In response to detecting an anomaly in the software interface of the software under test, obtain interface fault description data.

[0057] The software to be tested refers to the basic software system that is undergoing automated testing or actual operation monitoring.

[0058] Among them, software interface abnormalities refer to situations where the interface deviates from the expected design during rendering or interaction, including but not limited to unresponsive buttons, disordered page layout, pop-up errors, display abnormalities, interaction failures, response delays, and other fault phenomena that users can directly perceive.

[0059] The interface fault description data is used to describe the fault phenomena of the software interface. In some embodiments, the interface fault description data is a data record that describes these fault phenomena in a structured or natural language manner. It includes not only visual perception data such as interface screenshots and video streams, but also operation logs that trigger the interface abnormality, front-end console error information (such as JavaScript error stack traces), and the corresponding DOM tree node status.

[0060] In practice, during the evaluation of the software under test, if testers or automated test scripts detect an anomaly in the software interface while executing test cases—for example, a grayed-out, unclickable "Submit" button on a web page, a blank chart component failing to load, or a misaligned list box in a mobile application—the computer will automatically trigger a fault analysis process to obtain interface fault description data. Specifically, this interface fault description data consists of structured or unstructured data describing the fault phenomena of the software interface. It includes not only visual perception data such as screenshots and video streams, but also operation logs triggered by the interface anomaly, front-end console error messages (such as JavaScript error stack traces), and the corresponding DOM tree node states. This multi-dimensional data collection ensures a complete record of the fault phenomena, providing a data foundation for subsequent analysis.

[0061] In the above embodiments, by responding to the detection of an anomaly in the software interface of the software under test and obtaining interface fault description data, the computer device can capture the apparent anomalies at the interface level in real time during the test and convert them into structured description data, providing an accurate data source for subsequent automated analysis. This effectively solves the problem that traditional methods rely on manual observation and recording of fault phenomena, resulting in low efficiency and easy omission of key information.

[0062] Step S120: Determine the target functional component information based on the mapping relationship between the pre-built interface phenomena and software functional components.

[0063] The target functional component information includes information about the functional components associated with the fault phenomenon.

[0064] The pre-built mapping relationship between interface phenomena and software functional components refers to the dictionary established during the offline preparation phase, which connects front-end interface elements with back-end business logic modules. Specifically, the target functional component information refers to the identifiers of back-end functional modules, interface names, or front-end component identifiers that may be related to the observed fault phenomenon by querying the aforementioned mapping dictionary.

[0065] In basic software systems, interface failures can significantly impact user experience and potentially mislead users, causing them to misunderstand the software's functions and operations. For example, inaccurate or incomplete information displayed on the interface may lead users to make incorrect operations or judgments. Therefore, it is necessary to conduct intelligent analysis of software interface failures to identify the causes and promptly fix them, thereby enhancing software reliability. In this application, the computer device can determine the target functional component information based on a pre-built mapping relationship between interface phenomena and software functional components. Since there are often complex call relationships between the software interface and underlying functions, an anomaly in one interface component may originate from failures in multiple backend functional modules. The pre-built mapping relationship establishes the association between UI (User Interface) elements (such as buttons and input boxes with specific IDs) and backend business logic modules, interface services, or data tables. For example, when the interface failure description data shows "Order Submission Button Unresponsive," the computer device can determine the target functional component information, including information on associated functional components such as "Order Submission Controller" and "Payment Service," by querying the mapping relationship table. This step maps the front-end interface phenomena to specific backend code entities, providing a foundation for subsequent in-depth analysis.

[0066] In the above embodiments, by determining the target functional component information based on the pre-built mapping relationship, the computer device can directly associate the interface failure phenomenon with the specific functional component, avoiding blind matching in the entire code, thereby adapting to diverse interface types and effectively solving the technical problems of poor adaptability and difficulty in handling complex interaction logic of existing rule-based methods.

[0067] Step S130: Input the interface fault description data and target functional component information into the fine-tuned large model, and output the fault symptom context information.

[0068] Among them, the fine-tuned large model refers to a large language model that has been specifically trained on the interface fault dataset of basic software and has the ability to understand software domain knowledge and code logic.

[0069] Among them, the fault symptom context information is used to indicate the fault causal chain that causes the fault phenomenon.

[0070] Among them, the fault symptom context information is obtained by analyzing the interface fault description data and target functional component information based on the software domain knowledge obtained from the fine-tuning of the large model and the zero-initialization attention mechanism.

[0071] In some embodiments, fault symptom context information is a structured intermediate result output after large model analysis. It not only indicates the fault type of the fault phenomenon, but also indicates the causal chain from the interface fault phenomenon to the backend functional defect.

[0072] In practice, the computer device can input interface fault description data and target functional component information into a fine-tuned large model, outputting fault symptom context information. This fine-tuned large model is a foundational model with software domain knowledge, fine-tuned using software domain data. Upon receiving input data, the large model performs deep semantic analysis and logical reasoning on the input information based on the software domain knowledge acquired through fine-tuning and a zero-initialization attention mechanism. The zero-initialization attention mechanism adaptively filters out redundant information unrelated to the fault (such as normal UI layout code) during model processing, focusing attention on the key instructions and features that trigger the anomaly. Finally, the large model outputs fault symptom context information, which indicates the fault causal chain that caused the fault phenomenon.

[0073] In the above implementation, by inputting interface fault description data and target functional component information into the fine-tuned large model, the software domain knowledge obtained from the fine-tuning and the zero-initialization attention mechanism are used to analyze and obtain the context information of the fault symptoms. This overcomes the shortcomings of traditional machine learning in parsing deep code call logic, reduces the dependence on manually written rules, realizes intelligent deduction of complex interaction logic, and improves the generalization ability of unknown fault modes.

[0074] Step S140: Input the fault symptom context information into the expert system integrated with the knowledge graph, and output the functional fault location result.

[0075] In this knowledge graph, entities of the basic software are used as nodes, and the relationships between entities are used as edges between nodes.

[0076] Among them, the functional fault location result is obtained by the expert system based on the information retrieved from the knowledge graph that is associated with the contextual information of the fault symptoms, and by reasoning about the pattern and cause of the functional fault.

[0077] In some embodiments, nodes represent entities that are components, interfaces, functions, or configuration items of the software, and edges represent relationships or logical connections between entities. An expert system is a diagnostic system that integrates knowledge graph querying and rule-based reasoning engines. Functional fault location results may include the expert system's final output: the root cause of the functional defect leading to the interface anomaly, the fault mode, and repair suggestions.

[0078] In basic software systems, intelligent analysis of functional faults plays a crucial role in timely identifying potential risks, quickly locating the source of faults, formulating effective repair strategies, and improving overall system reliability and operational efficiency. Knowledge graph-based methods can extract correlation information between different things; however, in practical analysis, they often face challenges such as diverse functional fault modes and complex analytical information, making functional fault analysis difficult.

[0079] Therefore, in this application, the computer device can input fault symptom context information into an expert system integrated with a knowledge graph, and output functional fault location results. After receiving the fault symptom context information, the expert system searches the knowledge graph for information associated with the fault symptom context information. Using preset reasoning rules, the expert system traverses the edges of the knowledge graph, performing pattern and cause reasoning for the functional fault, and deriving possible fault modes and root causes. For example, the reasoning might yield the functional fault location result as: "Fault mode: Resource leak; Fault cause: Database connection not closed in exception handling block," along with code repair suggestions.

[0080] In the above implementation, by inputting the contextual information of the fault symptoms into an expert system integrated with a knowledge graph, pattern and causal reasoning is performed based on the entities of the basic software and the relationships between entities. This provides an explicit and structured reasoning path for the fault analysis process, making the final fault location result highly interpretable. This significantly improves the automation level of basic software testing, the accuracy of fault location, and the overall testing efficiency.

[0081] In the aforementioned software fault analysis method, in response to the detection of anomalies in the software interface of the software under test, interface fault description data is obtained. This data describes the fault phenomena of the software interface. Based on a pre-constructed mapping relationship between interface phenomena and software functional components, target functional component information is determined. This information includes information about functional components associated with the fault phenomena. The interface fault description data and target functional component information are input into a fine-tuned large model, outputting fault symptom context information. This context information indicates the causal chain that caused the fault phenomena. The fault symptom context information is obtained by analyzing the interface fault description data and target functional component information using the fine-tuned large model based on the software domain knowledge obtained through fine-tuning and a zero-initialization attention mechanism. The fault symptom context information is input into an expert system integrated with a knowledge graph, outputting functional fault localization results. The knowledge graph uses entities of the basic software as nodes and the relationships between entities as edges between nodes. The functional fault localization results are obtained by the expert system through reasoning based on information retrieved from the knowledge graph that is associated with the fault symptom context information.

[0082] In this way, by responding to the detection of anomalies in the software interface of the software under test, interface fault description data is obtained. Based on the pre-built mapping relationship between interface phenomena and software functional components, the target functional component information is determined. This allows direct association of interface fault phenomena with specific functional components, avoiding blind matching in the entire codebase and thus adapting to diverse interface types. Subsequently, the interface fault description data and target functional component information are input into a fine-tuned large model. Utilizing the software domain knowledge obtained through fine-tuning and a zero-initialization attention mechanism, the contextual information of the fault symptoms that caused the fault phenomena is accurately derived. This overcomes the shortcomings of rule-based methods in related technologies, which struggle to handle complex interactive logic, and reduces reliance on manually written rules. Finally, the contextual information of the fault symptoms is input into an expert system integrated with a knowledge graph. Based on the entities of the basic software and the relationships between entities, fault mode and cause reasoning is performed, providing an explicit, structured reasoning path for the fault analysis process and enhancing the interpretability of the fault location results. Thus, through the coordinated efforts of the above steps, comprehensive and accurate analysis of complex software faults is achieved, significantly improving the automation level and testing efficiency of software fault analysis.

[0083] Interface fault analysis based on large language models relies on the large model's dialogue memory and knowledge association capabilities to analyze the code of each interface component and autonomously establish connections between interface faults and components using the model's existing knowledge. Building on this, learnable adaptive prompts are inserted into the large-scale language model to guide interface fault analysis from an instruction-adaptive perspective, allowing for corresponding fine-tuning.

[0084] In some embodiments, taking a large language model as an example, such as... Figure 2 The diagram illustrates an example of a user interface fault analysis process based on a large language model. The software fault analysis method further includes: parsing the front-end interface code and back-end functional code of the basic software using a large language model to extract the component tree structure; constructing a mapping table between interface components and back-end functional modules based on the component tree structure, and labeling the component types and interaction logic to obtain the labeled mapping table; comparing historical software fault data to generate fault mode feature vectors for interface components; and storing the labeled mapping table and fault mode feature vectors in a fault knowledge base to form a mapping relationship.

[0085] The front-end interface code of the basic software can include code files such as HTML, CSS, and JavaScript used to build the user interface. The back-end functional code can include server-side code files such as Java and Python used to handle business logic. The component tree structure is a tree-like data structure that reflects the hierarchical nesting of interface elements and the front-end and back-end call relationships.

[0086] In practical software engineering, front-end interfaces and back-end functionalities are often developed separately. To accurately trace interface failures, it's essential to establish a relationship between the two. During the offline preparation phase, computer equipment can use a large language model to parse key components of the basic software, such as the front-end interface code and back-end functional code. Specifically, for front-end interface code (e.g., HTML, CSS, JavaScript), the large language model can identify the structural definitions, style rules, and event binding logic of various UI elements; for back-end code (e.g., business logic code written in Java, Python, etc.), the large language model parses out class, method, and interface definitions and their calling relationships. Through this cross-language code parsing, a component tree structure encompassing front-end interface components and back-end functional modules is extracted, enabling the model to understand the data flow paths and functional support logic behind the interface elements.

[0087] Based on the extracted component tree structure, the computer device can construct a mapping table between interface components and backend functional modules. During the construction process, the computer device not only records the correspondence between interface component identifiers and backend interface paths, but also further annotates component types and interaction logic. Component types include, but are not limited to, buttons, text boxes, dropdown lists, and radio buttons; interaction logic annotations include synchronous submission, asynchronous loading (AJAX), frontend validation, and dynamic rendering. For example, for a submit button on a "user registration" interface, the mapping table not only records the backend method it calls, but also annotates it as "asynchronous loading" interaction logic, as well as the pre-validation conditions required to trigger the button. Through detailed annotation, the mapping table possesses rich contextual information, enabling it to address fault analysis needs in complex interaction scenarios, resulting in an annotated mapping table.

[0088] In this way, based on the annotated mapping table, the mapping relationship between interface phenomena and software functional components can be generated.

[0089] Specifically, to enable the mapping relationship to predict faults and match features, the computer device also compares historical software fault data to generate fault mode feature vectors for interface components. Historical software fault data contains records of various interface faults that have occurred in the past and their root causes. The fault mode feature vector is a vector representation that digitally encodes the fault patterns of components, used to characterize the types of faults that components are prone to (such as timeouts, incorrect return values, and style errors). The computer device uses feature extraction algorithms to transform historical fault data into multi-dimensional feature vectors. For example, the feature vector of a certain type of button component might contain values ​​for dimensions such as "frequency of no response to clicks," "probability of request timeout," and "error rate for specific browser compatibility." When a new interface component is parsed, the computer device matches it with similar components in the historical software fault data based on its component type and interaction logic, generating a corresponding fault mode feature vector.

[0090] Finally, the computer device stores the labeled mapping table and fault mode feature vectors into the fault knowledge base to form the aforementioned mapping relationship. The fault knowledge base, as a structured data storage center, supports efficient querying and retrieval. When an interface anomaly is detected, the computer device can directly retrieve the relevant mapping relationships and feature vectors from this fault knowledge base to quickly locate the target functional component and preliminarily predict possible fault modes.

[0091] The technical solution of this embodiment utilizes the code understanding capabilities of a large language model to automatically construct a multi-dimensional mapping relationship that includes component types, interaction logic, and historical fault characteristics. This eliminates the inefficient mode of relying on manual rule writing and mapping relationship sorting in related technologies, improves adaptability to diverse interface types and complex interaction logic, and provides high-quality data support for subsequent large model fine-tuning.

[0092] In some embodiments, such as Figure 3 As shown, another schematic diagram of the interface fault analysis process based on a large language model is provided. The software fault analysis method also includes: obtaining the interface fault dataset of the basic software; inserting learnable cue vectors into the input of the Transformer layer of the pre-trained large model; the length of the learnable cue vectors is related to the complexity of the fault analysis task; and fine-tuning the pre-trained large model with the inserted learnable cue vectors according to the interface fault dataset of the basic software to obtain the fine-tuned large model.

[0093] The interface failure dataset for basic software can be a specialized dataset collected and labeled specifically for training and fine-tuning large language models. This dataset may include screenshots of interface anomalies, corresponding front-end and back-end code snippets, annotations of the causes of the failures, and repair solutions.

[0094] The pre-trained large model refers to a foundational large language model with massive parameters and general language understanding capabilities. The Transformer layer is the core feature extraction network layer within the large model. Learnable cue vectors are a set of tensor parameters that are continuously updated during model fine-tuning but remain fixed during inference. Task complexity is related to the number of lines of code involved in the failure and the depth of the call chain.

[0095] In practice, while general-purpose large language models possess powerful natural language processing capabilities, they often lack specialized domain knowledge when facing software fault analysis tasks in specific domains, making it difficult to accurately understand code logic and fault terminology. Therefore, domain-specific fine-tuning of the large model is necessary. First, a dataset of interface faults in the basic software is acquired using computer equipment. This dataset is constructed by collecting numerous real-world fault cases from historical software testing processes, including descriptions of interface fault phenomena, corresponding front-end and back-end code snippets, and manually annotated fault causes and repair solutions. To ensure the effectiveness of fine-tuning, the samples in the dataset undergo cleaning and noise reduction to ensure the accuracy and representativeness of the data.

[0096] After acquiring the UI fault dataset, the computing device inserts learnable cue vectors into the input of the Transformer layers of a pre-trained large model. Specifically, learnable cue vectors are a set of tensor parameters that are continuously updated during model training but remain fixed during inference. The computing device can concatenate these learnable cue vectors to the front of the input sequence of specific Transformer layers (e.g., layers 6 to 12) of the pre-trained large model. It's important to note that the length of the learnable cue vectors is related to the complexity of the fault analysis task. The computing device can adaptively adjust the length of the cue vectors based on the complexity of the current input UI fault data (e.g., the number of components involved, lines of code, exception stack depth, etc.), dynamically varying it between 10 and 50 token dimensions. For simple UI misalignment faults, shorter cue vectors are assigned to speed up processing; for complex cross-module interaction faults, longer cue vectors are assigned to provide more learnable capacity.

[0097] Subsequently, the computer equipment can fine-tune the pre-trained large model with inserted learnable cue vectors based on the interface fault dataset of the underlying software, resulting in a fine-tuned large model. During the fine-tuning process, most parameters of the pre-trained large model itself remain fixed, with gradient updates performed only on the inserted learnable cue vectors and a small number of adapter parameters. By continuously minimizing the loss function between the predicted fault causes and the ground truth labels, the model gradually learns the domain knowledge and reasoning patterns of the software fault analysis task. Through this method of fine-tuning only a small number of parameters, the model not only avoids the high computational cost of full-parameter fine-tuning and can quickly adapt to the software fault analysis task, but also effectively avoids the catastrophic forgetting problem caused by full-parameter updates, i.e., it does not lose the natural language understanding and basic logical reasoning capabilities of the original general-purpose large model.

[0098] The technical solution of this embodiment achieves domain adaptation of a large model with extremely low computational resources and storage overhead by inserting dynamically adjustable learnable cue vectors into the key layers of the large model. This significantly reduces the threshold and resource overhead of model training, while ensuring high accuracy of the model in specific fault analysis tasks.

[0099] like Figure 3 As shown, based on the interface fault dataset of the basic software, the pre-trained large model with inserted learnable cue vectors is fine-tuned to obtain the fine-tuned large model. This includes: during the fine-tuning process, combining zero-gating technology, the interface fault cues contained in the interface fault dataset are used as new instruction signals and dynamically injected into the pre-trained large model to eliminate the interference of invalid or noisy features on the instruction following ability.

[0100] Zero-gating is a control mechanism that initializes gating parameters to zero during the initial training phase of the model and gradually enables them as training progresses. Interface fault cues are key information in the dataset that indicates the root cause of a fault (such as "null pointer exception" or "interface timeout"). Invalid or noisy features refer to comments, variable names, UI style code, etc., that are unrelated to the current fault.

[0101] When fine-tuning a model by inputting an interface fault dataset, a key issue is how to effectively absorb newly injected domain knowledge of interface faults while retaining the original massive pre-trained knowledge. Directly introducing new instruction signals during fine-tuning may affect the model's original weight distribution, leading to unstable model output or deviation from the task objective.

[0102] Therefore, in this embodiment, during fine-tuning, a zero-gating technique is used to dynamically inject interface fault cues from the interface fault dataset as new instruction signals into the pre-trained large model. Specifically, the zero-initialization attention mechanism introduces additional attention branches or gating units in the Transformer layer. In the initial stage of fine-tuning, the weights of these gating units are initialized to zero (i.e., zero-gating), meaning that the new instruction signals have almost no impact on the model's original forward propagation process initially, and the model continues to run according to its pre-trained state, thus ensuring stability in the initial stage. As fine-tuning progresses, the model gradually learns and updates the weights of the gating units based on the gradient backpropagation of the loss function.

[0103] During weight updates, zero-gating adaptively adjusts the injection ratio of new instruction signals (i.e., interface fault clues). When the input interface fault clues contain crucial information that is decisive for fault analysis (such as specific error codes, null pointer exceptions of key variables, etc.), the gating weights increase accordingly, enabling these new instruction signals to be effectively integrated into the model's feature representation. Conversely, when the input data contains invalid or noisy features (such as irrelevant annotation information, redundant style code, normal business logs, etc.), the gating weights remain at a low level or even approach zero, thereby eliminating the interference of invalid or noisy features on the model's instruction following ability. This mechanism is similar to a causal intervention method, where the model automatically selects key causal features that truly contribute to instruction execution during training, filtering out non-causal correlation features.

[0104] The technical solution in this embodiment combines zero-gating technology during fine-tuning to dynamically inject interface fault clues as new instruction signals into the pre-trained large model. This achieves the fusion of new knowledge injection and existing pre-trained knowledge, effectively eliminating the interference of invalid or noisy features on the model's instruction-following ability. Similar to causal intervention, it filters out truly crucial information that contributes to instruction execution, avoiding catastrophic forgetting and improving the model's ability to accurately locate fault causal chains in complex code logic.

[0105] like Figure 3 As shown, in some embodiments, the pre-trained large model is fine-tuned using a hierarchical cascaded multi-task adapter group structure. Based on the interface fault dataset of the underlying software, the pre-trained large model with inserted learnable cue vectors is fine-tuned to obtain the fine-tuned large model. This includes: for the pre-trained large model with inserted learnable cue vectors, incremental weight updates are performed using low-rank matrix factorization based on low-rank adaptive technology, and the multi-task routing layer is configured to automatically allocate adapter branches according to the fault type; a dual-stream attention mechanism is constructed to separate the pre-trained knowledge stream from the fault feature stream, ensuring feature decoupling through orthogonal constraints, and suppressing noise interference with dynamic gradient masks; based on the adapter branches allocated by the multi-task routing layer and the dual-stream attention mechanism, a two-stage optimization strategy is used for fine-tuning: the first stage trains the multi-task adapter group structure with fixed master model parameters; the second stage performs full parameter fine-tuning with a preset learning rate, and injects adversarial examples containing node confusion or attribute missingness during the fine-tuning process; after fine-tuning using the two-stage optimization strategy, the fine-tuned large model is obtained.

[0106] Among them, low-rank adaptive technique is an efficient parameter fine-tuning method that approximates large model weight update amounts through low-rank matrix factorization. The multi-task routing layer is a dynamic scheduling module located within the adapter group, capable of routing input fault data to the most suitable adapter network for processing based on the type label of the fault data.

[0107] The dual-stream attention mechanism involves designing two parallel attention paths within the network: one for extracting general language grammar knowledge inherent in the large model (pre-training knowledge stream), and the other for extracting specific patterns strongly correlated with software faults (fault feature stream). Orthogonality constraints are mathematical penalty terms that force the feature vectors extracted by the two streams to remain spatially perpendicular. Dynamic gradient masking is a technique that randomly masks part of the gradient channels during backpropagation.

[0108] The two-stage optimization strategy divides the fine-tuning process into two stages: local adapter training and global joint fine-tuning. The preset learning rate refers to a learning rate used in the second stage that is significantly lower than that in the first stage (e.g., 0.1 times). Adversarial examples are malicious samples generated by making minor perturbations to normal input code (e.g., obfuscating DOM node names or deleting key attributes), used to enhance model robustness.

[0109] To further improve the performance of the large model in handling various types of software faults and achieve more efficient parameter utilization, this embodiment designs a highly optimized adapter architecture. First, the pre-trained large model is fine-tuned using a hierarchical, cascaded multi-task adapter group structure. Specifically, for the pre-trained large model with inserted learnable cue vectors, the computer device can perform incremental weight updates through low-rank matrix factorization based on Low-Rank Adaptive Reduction (LoRA) technology. LoRA technology introduces two low-rank matrices into the attention mechanism of the Transformer layer or the feedforward neural network to simulate the effect of updating all parameters, with the parameter proportion being only 0.1% to 1% of the original model. Simultaneously, the computer device configures a multi-task routing layer to automatically allocate adapter branches according to the fault type. Different branches focus on handling specific types of fault characteristics (such as UI rendering fault branches and network communication fault branches), achieving a balance between cross-task parameter sharing and task specialization.

[0110] Furthermore, to prevent the introduction of fault features during fine-tuning from confusing with the model's original pre-trained knowledge, the computer device employs a dual-stream attention mechanism to separate the pre-trained knowledge stream from the fault feature stream. In this dual-stream architecture, the original pre-trained parameters handle the general pre-trained knowledge stream, while the newly added adapter parameters handle the specific fault feature stream. The two feature streams flow independently between network layers, and orthogonal constraints ensure feature decoupling, forcing the two types of features to maintain an orthogonal relationship in the feature space, minimizing information overlap. Additionally, dynamic gradient masks dynamically mask gradient channels that are insensitive to the current task during backpropagation, further suppressing noise interference.

[0111] In this way, based on the adapter branching and dual-stream attention mechanism allocated by the multi-task routing layer, the pre-trained large model with inserted learnable cue vectors can be fine-tuned to obtain the fine-tuned large model.

[0112] Specifically, based on the adapter branches allocated by the multi-task routing layer and the aforementioned dual-stream attention mechanism, a two-stage optimization strategy is employed for fine-tuning. In the first stage, the main model parameters (i.e., the original parameters of the pre-trained large model) are fixed, and only the multi-task adapter group structure and learnable cue vectors are trained. This stage aims to allow the adapters to quickly learn domain fault features without compromising the general capabilities of the main model. In the second stage, full parameter fine-tuning is performed with a small learning rate (e.g., 0.1x). Because the learning rate is extremely small, this stage allows for subtle adjustments to the entire network while maintaining model stability, achieving global optimization. Simultaneously, adversarial examples containing node obfuscation or missing attributes are injected during the fine-tuning process. For example, deliberately disrupting the hierarchical relationships of the front-end DOM tree nodes or randomly deleting certain attribute values ​​from code snippets forces the model to correctly infer fault causes even with incomplete or interfered input, forming an adaptive architecture that balances knowledge preservation and task adaptation. After fine-tuning using the two-stage optimization strategy, the fine-tuned large model is obtained.

[0113] The technical solution in this embodiment employs a hierarchical, cascaded multi-task adapter group structure, updates weights and configures multi-task routes based on low-rank adaptive technology, constructs a dual-stream attention mechanism and applies orthogonal constraints and gradient masks, and uses a two-stage optimization strategy with adversarial examples injected for fine-tuning. Thus, efficient domain adaptation of large models can be achieved with minimal labeled data, automatically distinguishing and emphasizing causal features crucial for instruction compliance, significantly reducing training resource overhead, and effectively improving the model's robustness and generalization ability in complex and ever-changing software testing environments.

[0114] Knowledge graph-based functional fault analysis primarily involves constructing a knowledge graph of the underlying software domain, representing software structure, functions, and fault modes in graphical form. Then, in conjunction with an expert system, the information from the knowledge graph is used for intelligent fault analysis and reasoning. Based on test result reports, fault modes and root causes are identified. Ultimately, the expert system provides accurate fault analysis results and corresponding handling suggestions, helping developers quickly locate software faults and improve software reliability and operational efficiency. Figure 4 A schematic diagram illustrating the analysis process for a functional failure is shown. Figure 5 This illustrates a different functional failure analysis flowchart. For example... Figure 4 and Figure 5 As shown, the following details the structural definition of knowledge graphs and the reasoning process of expert systems based on knowledge graphs. Expert systems integrating knowledge graphs can also be named intelligent fault analysis systems.

[0115] Specifically, the entities of the basic software include at least one of the components, interfaces, and functions of the basic software; the relationships include at least one of logical connection relationships and action relationships; the fault symptom context information is input into an expert system integrated with a knowledge graph, and the functional fault localization result is output, including: extracting information related to the entities from the fault symptom context information as the target retrieval entity; in the knowledge graph, starting from the target retrieval entity, performing a topological traversal along logical connection relationships and / or action relationships to obtain connected subgraphs that are directly adjacent to or indirectly connected to the target retrieval entity; and determining the information related to the fault symptom context information based on the set of associated entities contained in the connected subgraph.

[0116] The information associated with the entity refers to the names of backend functional modules, interface function names, or frontend component identifiers that are explicitly identified as potentially defective in the fault symptom context information output by the large model. The target retrieval entity is the set of starting nodes used for subgraph matching in the knowledge graph.

[0117] Logical connectivity refers to the relationships between entities at the code level, such as calls, inheritance, and implementation. Functional relationships refer to the relationships between entities at the business logic level, such as data flow and state dependencies. A connected subgraph is a local graph region traversed with a finite number of hops, centered on the target retrieval entity. The set of associated entities is the collection of all nodes within this subgraph region, representing all candidate components that could potentially cause the current failure.

[0118] In the field of basic software, functional failures often involve multiple levels of inefficiency, and simple string matching is insufficient to reveal the underlying logic of the failure. Therefore, in the knowledge graph constructed in this embodiment, the entities of the basic software include at least one of the following: components, interfaces, and functions. The relationships between entities include at least one of logical connection relationships and functional relationships. Logical connection relationships include, for example, component A calling interface B, and function C depending on component D; functional relationships include, for example, interface E performing a write operation on data table F, and component G being controlled by configuration parameters H. Through this definition of entities and edges, the knowledge graph transforms the static architecture and dynamic behavior of the basic software into a structured graph network. Based on the information in the knowledge graph, a series of functional failure analysis rules can be formulated. These rules cover various failure scenarios that may occur in the basic software and corresponding diagnostic methods, describing the characteristics of different failure modes, the probability of failure root causes, and corresponding diagnostic methods. The rules can be formulated through the experience of domain experts. Expert systems can utilize the information in the knowledge graph to perform pattern and cause reasoning for functional failures, and identify the patterns and causes of functional failures according to the pre-defined rules.

[0119] Specifically, after the large model outputs the contextual information of the fault symptoms and inputs it into the expert system, the expert system first extracts the information associated with the entities in the contextual information of the fault symptoms as the target retrieval entities. For example, using regular expressions or named entity recognition technology, noun entities related to basic software components, such as backend functional module names, interface function names, or frontend component identifiers, are extracted from the contextual information of the fault symptoms.

[0120] Subsequently, the expert system performs a topological traversal of the knowledge graph, starting with the target entity and following the corresponding logical connections and / or interaction relationships. Specifically, the expert system can employ breadth-first search (BFS) or depth-first search (DFS) algorithms, expanding layer by layer from the target entity along its downstream interface nodes, dependent database connection pool nodes, and related configuration parameter nodes. During the traversal, the expert system obtains connected subgraphs that are directly adjacent to or indirectly connected to the target entity, as well as the set of associated entities contained within these connected subgraphs, as information associated with the contextual information of the fault symptoms.

[0121] For example, if the context information of the fault symptoms includes "payment service call timed out," the expert system can extract "payment service" as the target retrieval entity using technologies such as named entity recognition. The retrieved connected subgraph can contain not only the payment service that directly reported the error, but also its indirectly dependent data source connection pool components and the configuration parameter entities of the data source connection pool.

[0122] The technical solution of this embodiment extracts the target retrieval entity from the context information of fault symptoms and performs topological traversal along logical connections and relationships in the knowledge graph to obtain a connected subgraph. In this way, by utilizing the structured topological characteristics of the knowledge graph, the fuzzy clues provided by the large model are transformed into precise local graph regions, providing a clear retrieval path and candidate range for expert systems to perform reverse causal chain tracing, effectively solving the problem of tracing the root cause when information is abundant in complex fault modes.

[0123] In some embodiments, a dynamic self-updating mechanism for the knowledge graph is provided. As the software system iterates continuously, its functionality, code structure, and failure modes also evolve. If a static knowledge graph is not updated in a timely manner, it will gradually become invalid. Therefore, this embodiment constructs a rolling update mechanism based on a feedback loop.

[0124] like Figure 5As shown, the software fault analysis method also includes: extracting new fault keywords and new fault mode features based on the test result report corresponding to the software under test; the test result report is a feedback report generated based on the functional fault location results; feeding the new fault keywords and new fault mode features back to the knowledge graph through an expert system; and performing at least one of the following operations on the knowledge graph according to the feedback: adding new knowledge, correcting error information, and deleting outdated information, so as to realize the dynamic self-updating of the knowledge graph.

[0125] The test result report is a comprehensive document automatically generated after fault localization, containing the fault phenomenon, localization process, root cause, and repair suggestions. New fault keywords refer to component names, error types, or abnormal pattern descriptions discovered during this fault analysis that are not yet included in the knowledge graph. New fault mode features are vectorized or rule-based representations of the fault phenomenon and causal chain.

[0126] Adding new knowledge refers to adding new nodes or edges to the graph to enrich the knowledge network. Correcting error messages refers to updating the attributes of existing nodes or edges (such as correcting the call path of an interface). Deleting outdated information refers to removing obsolete component or interface nodes after software version updates.

[0127] In practice, after the computer equipment outputs the functional fault location results and generates a test result report, the computer equipment parses the test result report to extract new fault keywords and new fault mode features. Subsequently, the new fault keywords and new fault mode features are fed back to the knowledge graph through an expert system.

[0128] Based on this feedback, the expert system performs at least one of the following operations on the knowledge graph: adding new knowledge, correcting error information, and deleting outdated information to achieve dynamic self-updating of the knowledge graph. For example, if the test result report indicates a new "memory leak" fault, the expert system adds a new fault mode node to the knowledge graph and establishes its association with related code component nodes (adding new knowledge); if the test result report indicates that a component is no longer used after the software version upgrade, the expert system deletes the entity node corresponding to the outdated component and its connections to avoid invalid reasoning (deleting outdated information); if it finds that an existing reasoning rule has a deviation in actual application, for example, it was originally thought that the timeout of interface A was only caused by cause B, but the feedback shows that cause C is also an important factor, the expert system adjusts the weight of the rule node or adds new logical conditions based on the feedback results (correcting error information).

[0129] The technical solution in this embodiment extracts new fault keywords and fault mode features based on test result reports, which are then fed back to the knowledge graph by the expert system, where addition, correction, or deletion operations are performed. This enables the knowledge graph to be continuously updated and dynamically self-learned, solving the problems of existing knowledge-based systems struggling to update knowledge and adapt to rapid software iteration. It ensures the timeliness and accuracy of fault analysis knowledge, allowing the system to continuously evolve autonomously to cope with unknown fault modes.

[0130] In yet another embodiment, such as Figure 6 As shown, a logical relationship architecture diagram for interface fault analysis and functional fault analysis is provided. Figure 6 It clearly presents the fault analysis process from interface phenomena to functional causes.

[0131] During the interface fault analysis process, the following steps are executed sequentially: software system interface component mapping (parsing HTML / CSS / JS and other interface code to extract the component tree structure), construction of fine-tuning dataset (constructing an interface fault dataset for targeted fine-tuning of the large model), and large model adaptation and fine-tuning (combining zero-initialization attention mechanism, low-rank adaptive adapter, zero-gating technique and other strategies to complete fine-tuning). The output is the interface fault analysis result containing fault symptom context information (the fault symptom context information indicates the fault causal chain that causes the fault phenomenon, which is obtained by the fine-tuned large model based on software domain knowledge and zero-initialization attention mechanism to analyze the interface fault description data and target functional component information).

[0132] During the functional failure analysis process, the following steps are executed sequentially: knowledge acquisition and knowledge graph construction (representing knowledge as entities (components / interfaces / functions, etc.) and relationships (logical connections / functional relationships, etc.)), formulating functional failure analysis rules (formulating failure analysis rules and diagnostic logic based on the knowledge graph), expert system integration and feedback optimization (integrating the reasoning engine, receiving the contextual information of failure symptoms transmitted by the interface failure analysis, and updating the knowledge graph in conjunction with feedback), and outputting the functional failure localization result (inferred by the expert system based on the associated information in the knowledge graph). The two are connected through the symptom transmission link and finally collaboratively output a comprehensive diagnosis (report)—the interface failure analysis focuses on UI layer failure analysis and transmits the symptom context, while the functional failure analysis relies on the knowledge graph to locate backend functional defects, complementing each other to complete the full-link analysis from interface anomalies to the root cause of functional failures.

[0133] The software fault analysis method based on knowledge graphs and large model adaptation proposed in this application can effectively overcome the limitations of existing technologies and provide more comprehensive, accurate, and dynamic fault diagnosis capabilities. Its efficient fault handling capabilities will significantly reduce software maintenance costs, shorten repair time, improve the reliability and user experience of software systems, and promote the intelligent development of the software industry.

[0134] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0135] Based on the same inventive concept, this application also provides a software fault analysis apparatus for implementing the software fault analysis method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more software fault analysis apparatus embodiments provided below can be found in the limitations of the software fault analysis method described above, and will not be repeated here.

[0136] In one exemplary embodiment, such as Figure 7 As shown, a software fault analysis device is provided, including: an acquisition module 710, a determination module 720, an information output module 730, and a result output module 740, wherein:

[0137] The acquisition module 710 is used to acquire interface fault description data in response to detecting an anomaly in the software interface of the software under test; the interface fault description data is used to describe the fault phenomenon of the software interface.

[0138] The determination module 720 is used to determine the target functional component information based on the pre-constructed mapping relationship between interface phenomena and software functional components; the target functional component information includes information about the functional components associated with the fault phenomenon.

[0139] The information output module 730 is used to input the interface fault description data and the target functional component information into the fine-tuned large model and output fault symptom context information; the fault symptom context information is used to indicate the fault causal chain that causes the fault phenomenon; the fault symptom context information is obtained by the fine-tuned large model based on the software domain knowledge obtained by fine-tuning and the zero-initialization attention mechanism, analyzing the interface fault description data and the target functional component information.

[0140] The result output module 740 is used to input the fault symptom context information into an expert system integrated with a knowledge graph and output the functional fault location result; the knowledge graph uses entities of the basic software as nodes and the relationships between the entities as edges between the nodes; the functional fault location result is obtained by the expert system through reasoning based on the information retrieved in the knowledge graph that is associated with the fault symptom context information.

[0141] In one embodiment, the apparatus further includes: a construction module, configured to parse the front-end interface code and back-end function code of the basic software using a large language model, and extract a component tree structure; based on the component tree structure, construct a mapping relationship table between interface components and back-end function modules, and label the component types and interaction logic to obtain the labeled mapping relationship table; generate a fault mode feature vector of the interface components according to historical software fault data, and store the labeled mapping relationship table and the fault mode feature vector into a fault knowledge base to form the mapping relationship.

[0142] In one embodiment, the apparatus further includes: a fine-tuning module for acquiring an interface fault dataset of the underlying software; inserting a learnable cue vector into the input of the Transformer layer of the pre-trained large model; the length of the learnable cue vector being correlated with the complexity of the fault analysis task; and fine-tuning the pre-trained large model with the inserted learnable cue vector based on the interface fault dataset of the underlying software to obtain the fine-tuned large model.

[0143] In one embodiment, the fine-tuning module is specifically used to dynamically inject the interface fault clues contained in the interface fault dataset as new instruction signals into the pre-trained large model during the fine-tuning process, in conjunction with zero-gating technology, so as to eliminate the interference of invalid or noisy features on the instruction following ability.

[0144] In one embodiment, the pre-trained large model is fine-tuned using a hierarchical, cascaded multi-task adapter group structure. Specifically, the fine-tuning module, for the pre-trained large model with inserted learnable cue vectors, performs incremental weight updates based on low-rank adaptive techniques using low-rank matrix factorization, and configures the multi-task routing layer to automatically allocate adapter branches according to fault type. A dual-stream attention mechanism is constructed to separate the pre-trained knowledge stream from the fault feature stream, ensuring feature decoupling through orthogonal constraints, and suppressing noise interference with dynamic gradient masks. Based on the adapter branches allocated by the multi-task routing layer and the dual-stream attention mechanism, a two-stage optimization strategy is employed for fine-tuning: the first stage trains the multi-task adapter group structure with fixed master model parameters; the second stage performs full parameter fine-tuning with a preset learning rate, injecting adversarial examples containing node confusion or attribute missingness during the fine-tuning process; after fine-tuning using the two-stage optimization strategy, the fine-tuned large model is obtained.

[0145] In one embodiment, the entity of the basic software includes at least one of the components, interfaces, and functions of the basic software; the association relationship includes at least one of logical connection relationship and functional relationship; the result output module 740 is specifically used to extract the information associated with the entity of the fault symptom context information as the target retrieval entity; in the knowledge graph, starting from the target retrieval entity, a topological traversal is performed along the logical connection relationship and / or functional relationship to obtain a connected subgraph that is directly adjacent to or indirectly connected to the target retrieval entity; based on the set of associated entities contained in the connected subgraph, the information associated with the fault symptom context information is determined.

[0146] In one embodiment, the apparatus further includes: an update module, configured to extract new fault keywords and new fault mode features based on the test result report corresponding to the software under test; the test result report is a feedback report generated based on the functional fault location results; the new fault keywords and the new fault mode features are fed back to the knowledge graph through the expert system; and at least one of the following operations is performed on the knowledge graph according to the feedback: adding new knowledge, correcting error information, and deleting outdated information, so as to realize the dynamic self-updating of the knowledge graph.

[0147] Each module in the aforementioned software fault analysis device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0148] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a software fault analysis method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0149] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0150] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0151] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0152] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0153] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0154] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0155] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0156] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A software fault analysis method, characterized in that, The method includes: In response to the detection of an anomaly in the software interface of the software under test, interface fault description data is obtained; the interface fault description data is used to describe the fault phenomenon of the software interface. Based on the pre-constructed mapping relationship between interface phenomena and software functional components, the target functional component information is determined; the target functional component information includes information about the functional components associated with the fault phenomenon. The interface fault description data and the target functional component information are input into the fine-tuned large model, and fault symptom context information is output. The fault symptom context information is used to indicate the fault causal chain that causes the fault phenomenon. The fault symptom context information is obtained by the fine-tuned large model based on the software domain knowledge obtained by fine-tuning and the zero-initialization attention mechanism, by analyzing the interface fault description data and the target functional component information. The contextual information of the fault symptoms is input into an expert system integrated with a knowledge graph, and the functional fault location result is output. The knowledge graph uses entities of the basic software as nodes and the relationships between the entities as edges between the nodes. The functional fault location result is obtained by the expert system through reasoning based on information retrieved from the knowledge graph that is associated with the contextual information of the fault symptoms.

2. The method according to claim 1, characterized in that, The method further includes: The front-end interface code and back-end function code of the basic software are analyzed using a large language model to extract the component tree structure; Based on the component tree structure, a mapping table between interface components and backend functional modules is constructed, and the component types and interaction logic are labeled to obtain the labeled mapping table. Based on historical software fault data, fault mode feature vectors of the interface components are generated, and the labeled mapping table and the fault mode feature vectors are stored in the fault knowledge base to form the mapping relationship.

3. The method according to claim 1, characterized in that, The method further includes: Obtain a dataset of interface faults in the basic software; A learnable cue vector is inserted at the input of the Transformer layer of the pre-trained large model; the length of the learnable cue vector is related to the complexity of the fault analysis task. Based on the interface fault dataset of the basic software, the pre-trained large model with the inserted learnable cue vectors is fine-tuned to obtain the fine-tuned large model.

4. The method according to claim 3, characterized in that, The pre-trained large model is fine-tuned using a hierarchical, cascaded multi-task adapter group structure; the fine-tuning of the pre-trained large model, which incorporates the learnable cue vectors, based on the interface fault dataset of the underlying software, to obtain the fine-tuned large model, includes: For the pre-trained large model with the inserted learnable cue vector, the weights are incrementally updated through low-rank matrix factorization based on low-rank adaptive technology, and the multi-task routing layer is configured to automatically allocate adapter branches according to the fault type. A dual-stream attention mechanism is constructed to separate the pre-trained knowledge stream from the fault feature stream. Orthogonal constraints are used to ensure feature decoupling, and dynamic gradient masks are used to suppress noise interference. Based on the adapter branches allocated by the multi-task routing layer and the dual-stream attention mechanism, a two-stage optimization strategy is adopted for fine-tuning: the first stage trains the multi-task adapter group structure with fixed master model parameters; the second stage performs full parameter fine-tuning with a preset learning rate and injects adversarial samples containing node confusion or attribute missing during the fine-tuning process. After fine-tuning the two-stage optimization strategy, the fine-tuned large model is obtained.

5. The method according to claim 1, characterized in that, The entities of the basic software include at least one of the components, interfaces, and functions of the basic software; the associations include at least one of logical connection relationships and functional relationships. The step of inputting the contextual information of the fault symptoms into an expert system integrated with a knowledge graph and outputting the functional fault location result includes: Extract the contextual information of the fault symptoms and the information associated with the entity, and use it as the target retrieval entity; In the knowledge graph, starting from the target retrieval entity, a topological traversal is performed along the logical connection relationship and / or interaction relationship to obtain a connected subgraph that is directly adjacent to or indirectly connected to the target retrieval entity. Based on the set of associated entities contained in the connected subgraph, determine the information associated with the context information of the fault symptoms.

6. The method according to claim 1, characterized in that, The method further includes: Based on the test result report corresponding to the software under test, new fault keywords and new fault mode features are extracted; the test result report is a feedback report generated based on the functional fault location results. The expert system feeds back the new fault keywords and the new fault mode features to the knowledge graph. Based on the feedback, perform at least one of the following operations on the knowledge graph: add new knowledge, correct error information, or delete outdated information, so as to achieve dynamic self-updating of the knowledge graph.

7. A software fault analysis device, characterized in that, The device includes: The acquisition module is used to acquire interface fault description data in response to the detection of an anomaly in the software interface of the software under test; the interface fault description data is used to describe the fault phenomenon of the software interface. The determination module is used to determine the target functional component information based on the pre-built mapping relationship between interface phenomena and software functional components; the target functional component information includes information about the functional components associated with the fault phenomenon; The information output module is used to input the interface fault description data and the target functional component information into the fine-tuned large model and output fault symptom context information; the fault symptom context information is used to indicate the fault causal chain that causes the fault phenomenon; the fault symptom context information is obtained by the fine-tuned large model based on the software domain knowledge obtained by fine-tuning and the zero-initialization attention mechanism, analyzing the interface fault description data and the target functional component information; The result output module is used to input the fault symptom context information into an expert system integrated with a knowledge graph and output the functional fault location result. The knowledge graph uses entities of the basic software as nodes and the relationships between the entities as edges between the nodes. The functional fault location result is obtained by the expert system through reasoning based on the information retrieved from the knowledge graph that is associated with the fault symptom context information.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images