Software defect confirmation method and system based on code semantic feature extraction

Abstract

This application provides a software defect confirmation method and system based on code semantic feature extraction, relating to the field of software defect handling technology. The method includes: deploying an analysis agent to receive and parse input data, obtaining a high-dimensional semantic feature vector based on a semantic defect analysis module; retrieving matching historical defect cases from a long-term memory and generating a defect analysis report; deploying a repair agent to generate real-time repair solutions and retrieving historical repair solutions from the long-term memory; testing each solution sequentially, and outputting a stable repair patch if successful; and deploying a management agent to store defect handling cases in the long-term memory and automatically reviewing high-frequency defect cases to update the repair solutions. This application achieves a closed loop from defect analysis and automatic repair to proactive prevention, reducing the frequency of high-frequency defects.

Description

Technical Field

[0001] This application relates to the field of code detection technology, specifically to a method and system for confirming software defects based on code semantic feature extraction. Background Technology

[0002] In software development and maintenance, defect discovery, location, and repair are core aspects of ensuring software quality. Traditional software defect handling methods mainly rely on manual review and static analysis tools, which suffer from inefficiency, strong dependence on developer experience, and difficulty in handling complex semantic relationships. With the continuous expansion of software scale and the acceleration of iteration speed, traditional methods can no longer meet the needs of efficient and accurate defect handling.

[0003] In recent years, although machine learning-based code defect detection methods have emerged, most existing technologies only focus on defect identification and classification, lacking a complete closed loop from analysis and remediation to knowledge accumulation and continuous optimization. Specifically, existing solutions typically cannot automatically generate and verify remediation plans, nor can they effectively utilize historical defect data to proactively prevent the recurrence of high-frequency defects, leading to the repeated occurrence of similar defects and persistently high maintenance costs. Therefore, how to automate and intelligently process software defects and build a defect handling system capable of continuous learning and self-optimization has become a pressing technical problem in this field. Summary of the Invention

[0004] In view of this, this application provides a software defect identification method and system based on code semantic feature extraction, which can realize automated and intelligent processing of software defects and can continuously learn and self-optimize against code defects.

[0005] Firstly, this application provides a software defect confirmation method based on code semantic feature extraction, comprising: step S100, deploying an analysis agent to receive and parse input data, and obtaining a high-dimensional semantic feature vector corresponding to the target code segment based on a semantic defect analysis module; step S200, calling the analysis agent to retrieve multiple historical defect cases matching the high-dimensional semantic feature vector from a preset long-term memory based on vector similarity; step S300, comparing the target code segment and the historical defect cases to generate a defect analysis report; the defect analysis report includes abnormal code lines, defect types, and confidence scores; step S400, deploying a repair agent to read the context of the target code segment from the defect analysis report, and based on the defect type and context... A real-time repair plan is generated, and multiple historical repair plans corresponding to multiple historical defect cases are obtained from the long-term memory. Step S500: The real-time repair plan and multiple historical repair plans are tested sequentially. Step S600: If the test passes, a stable repair patch is output according to the corresponding repair plan and imported into the long-term memory. Step S700: The deployment manager agent collects the defect analysis report and the stable repair patch to form a complete defect handling case, and stores the defect handling case as a historical defect case in the long-term memory. Step S800: The manager agent is called to automatically review the historical defect cases in the long-term memory to obtain high-frequency defect cases, and the repair plan for the high-frequency defect cases is configured to update the corresponding historical repair plan.

[0006] In conjunction with the first aspect, in one possible implementation, step S100 includes: step S101, calling the analysis agent to generate structured task description data based on the input data; the input data includes code change content and error logs, and the structured task description data includes target files, code scope, and problem type; step S102, based on the structured task description data, calling the analysis agent to import the target code fragment in the input data into a preset semantic defect analysis module; step S103, in the semantic defect analysis module, analyzing the vector parameters of the target code fragment to obtain the high-dimensional semantic feature vector.

[0007] In conjunction with the first aspect, in one possible implementation, step S103 includes: step S1031, generating a control flow graph of the target code segment in the semantic defect analysis module; step S1032, extracting defect paths of the target code segment based on the control flow graph; step S1033, converting the defect paths into vector representation data using the path2vec algorithm; step S1034, importing an ABCNN network with a preset self-attention mechanism into the semantic defect analysis module; and step S1035, generating high-dimensional semantic feature vectors based on the semantic dependencies between paths using the ABCNN network.

[0008] In conjunction with the first aspect, in one possible implementation, step S500 includes: step S501, writing the real-time repair scheme and multiple historical repair schemes into the first isolated sandbox of the code file system, compiling them, and running the test process sequentially; wherein, the method further includes: step S510, if the test fails, analyzing the error log and rotating to the next repair scheme.

[0009] In conjunction with the first aspect, one possible implementation further includes: step S410, combining the specified real-time repair scheme with the specified historical repair scheme to generate a fused repair scheme; step S420, writing the fused repair scheme into the second isolated sandbox of the code file system, compiling it, and running the test process sequentially; and after step S420, determining whether step S600 is triggered.

[0010] In conjunction with the first aspect, in one possible implementation, step S410 includes: step S411, dividing the specified real-time repair scheme and the specified historical repair scheme according to a set ratio; step S412, combining the divided real-time repair scheme and the historical repair scheme to obtain the fused repair scheme; and step S413, obtaining an adjustment command to adjust the set ratio.

[0011] In conjunction with the first aspect, in one possible implementation, step S800 includes: step S801, calling the manager agent to periodically review the historical defect cases accumulated in the long-term memory; step S802, if the manager agent identifies a historical defect case that occurs within a preset frequency range, it is marked as a high-frequency defect case.

[0012] In conjunction with the first aspect, in one possible implementation, step S800 further includes: step S803, calling the manager agent to analyze the high-frequency defect cases in the background based on a preset repair database to obtain a reference repair scheme; step S804, updating the corresponding historical repair scheme based on the reference repair scheme.

[0013] In conjunction with the first aspect, in one possible implementation, step S800 further includes: step S805, calling the manager agent to send the high-frequency defect cases to the expert experience database and obtaining a reference repair solution; step S806, updating the corresponding historical repair solution based on the reference repair solution.

[0014] Secondly, this application provides a software defect confirmation system based on code semantic feature extraction, comprising: an analysis module configured to execute: step S100, deploying an analysis agent to receive and parse input data, and obtaining a high-dimensional semantic feature vector corresponding to the target code segment based on the semantic defect analysis module; step S200, calling the analysis agent to retrieve multiple historical defect cases matching the high-dimensional semantic feature vector from a preset long-term memory based on vector similarity; step S300, comparing the target code segment and the historical defect cases to generate a defect analysis report; the defect analysis report includes abnormal code lines, defect types, and confidence scores; and a repair module, communicatively connected to the analysis module, the repair module configured to execute: step S400, deploying a repair agent to read the context of the target code segment from the defect analysis report, and obtaining a high-dimensional semantic feature vector corresponding to the target code segment based on the defect type and... The context generates a real-time repair plan and obtains multiple historical repair plans corresponding to multiple historical defect cases from the long-term memory; Step S500: Test the real-time repair plan and multiple historical repair plans in sequence; Step S600: If the test passes, output a stable repair patch according to the corresponding repair plan and import it into the long-term memory; The management update module is connected to the repair module and is configured to execute: Step S700: Deploy the manager agent to collect the defect analysis report and the stable repair patch to form a complete defect handling case, and store the defect handling case as the historical defect case in the long-term memory; Step S800: Call the manager agent to automatically review the historical defect cases in the long-term memory to obtain high-frequency defect cases, configure the repair plan for the high-frequency defect cases to update the corresponding historical repair plan.

[0015] When applied, this application utilizes an analysis agent to automatically parse input data and perform similarity retrieval using semantic feature vectors. This enables rapid matching of historical defect cases, resulting in the efficient and accurate generation of defect analysis reports containing abnormal code lines, defect types, and confidence scores. The remediation agent can automatically generate multiple remediation solutions based on the analysis report, such as modifying algorithms or adding anomaly detection. These solutions are then tested in an isolated environment alongside historical ones, ultimately outputting a validated and stable remediation patch, thus automating the process from analysis to remediation. A management agent stores successful remediation cases in a long-term memory and automatically reviews historical cases in the database to identify high-frequency defects, thereby optimizing remediation solutions accordingly. This allows the system to continuously accumulate experience, proactively reducing the frequency of high-frequency defects and moving from reactive remediation to proactive prevention. Attached Figure Description

[0016] Figure 1 The diagram shows the steps of a software defect identification method based on code semantic feature extraction according to an embodiment of this application.

[0017] Figure 2 The diagram illustrates the steps of how this application obtains high-dimensional semantic feature vectors.

[0018] Figure 3 The diagram shows the steps involved in obtaining high-dimensional semantic feature vectors based on the semantic defect analysis module.

[0019] Figure 4 The diagram shown illustrates the testing method.

[0020] Figure 5 The diagram shows a test method based on the fusion repair scheme.

[0021] Figure 6 The diagram shows a method for determining the fusion repair scheme based on proportions.

[0022] Figure 7 The diagram shows a statistical case study and a method for identifying high-frequency defect cases.

[0023] Figure 8 The diagram shows a method for analyzing repair solutions for high-frequency defect cases.

[0024] Figure 9 The diagram shows a method for analyzing repair solutions for high-frequency defect cases based on expert experience.

[0025] Figure 10 The figure shown is a schematic diagram of the system structure of a software defect confirmation system based on code semantic feature extraction according to an embodiment of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0027] Figure 1 The diagram illustrates the steps of a software defect identification method based on code semantic feature extraction, according to an embodiment of this application. This application provides a software defect identification method based on code semantic feature extraction. In one embodiment, as shown... Figure 1 As shown, the method includes: Step S100: The deployment analysis agent receives and parses the input data, and obtains the high-dimensional semantic feature vector corresponding to the target code fragment based on the semantic defect analysis module.

[0028] Step S200: Call the analysis agent to retrieve multiple historical defect cases that match the high-dimensional semantic feature vectors in the preset long-term memory based on vector similarity.

[0029] Step S300: Compare the target code snippet with historical defect cases to generate a defect analysis report; the defect analysis report includes the abnormal code line, defect type, and confidence score.

[0030] Step S400: The Deployment Repair Agent reads the context of the target code snippet from the defect analysis report, generates a real-time repair plan based on the defect type and context, and obtains multiple historical repair plans corresponding to multiple historical defect cases from the long-term memory.

[0031] In this step, real-time repair solutions include the following options: Option A, modify the algorithm logic; Option B, add exception handling; Option C, adjust the data structure.

[0032] Step S500: Test the real-time repair scheme and multiple historical repair schemes in sequence.

[0033] Step S600: If the test passes, output a stable repair patch according to the corresponding repair scheme and import it into the long-term memory.

[0034] Step S700: The deployment manager Agent collects defect analysis reports and stability patch to form a complete defect handling case, and stores the defect handling case as a historical defect case in the long-term memory.

[0035] Step S800: Call the manager agent to automatically review historical defect cases in the long-term memory to obtain high-frequency defect cases, and configure the repair plan for the high-frequency defect cases to update the corresponding historical repair plan.

[0036] In this embodiment, the analysis agent automatically parses the input data and uses semantic feature vectors for similarity retrieval, enabling rapid matching of historical defect cases. This allows for the efficient and accurate generation of defect analysis reports containing abnormal code lines, defect types, and confidence scores. The remediation agent can automatically generate multiple remediation plans based on the analysis report, such as modifying algorithms or adding anomaly detection. These plans are then tested in an isolated environment along with historical plans, ultimately outputting a validated and stable remediation patch, thus automating the process from analysis to remediation. The managing agent stores successful remediation cases in a long-term memory and automatically reviews historical cases in the database to identify high-frequency defects, thereby optimizing remediation plans accordingly. This allows the system to continuously accumulate experience, proactively reducing the frequency of high-frequency defects and moving from passive remediation to proactive prevention.

[0037] Figure 2 The diagram illustrates the method steps for obtaining high-dimensional semantic feature vectors according to this application. In one embodiment, as shown... Figure 2 As shown, step S100 includes: Step S101: Call the analysis agent to generate structured task description data based on the input data; the input data includes code change content and error logs, and the structured task description data includes target files, code scope and problem type.

[0038] Step S102: Based on the structured task description data, call the analysis agent to import the target code fragment in the input data into the preset semantic defect analysis module.

[0039] Step S103: In the semantic defect analysis module, analyze the vector parameters of the target code fragment to obtain a high-dimensional semantic feature vector.

[0040] In this embodiment, by introducing structured task description data, precise guidance and automation of the software defect analysis process are achieved. The analysis agent can automatically parse the input code change content and error logs, generating structured task description data containing the target file, code scope, and problem type. This allows subsequent semantic analysis to precisely focus on the problem-related code fragments, avoiding the resource waste caused by full-scale code analysis. Based on this structured data, the analysis agent automatically imports the target code fragments into the preset semantic defect analysis module without manual intervention, achieving full automation of the analysis process. Finally, the semantic defect analysis module performs in-depth analysis on the target code fragments, extracting their vector parameters and ultimately generating high-dimensional semantic feature vectors that characterize the semantic features of the code, providing high-quality input data for subsequent defect matching and repair.

[0041] Figure 3 The diagram illustrates the steps involved in deriving a high-dimensional semantic feature vector based on a semantic defect analysis module. In one embodiment, as shown... Figure 3 As shown, step S103 includes: Step S1031: Generate the control flow graph of the target code fragment in the semantic defect analysis module.

[0042] Step S1032: Extract the defect path of the target code segment based on the control flow graph.

[0043] Step S1033: Use the path2vec algorithm to convert the defect path into vector representation data.

[0044] Step S1034: Import the ABCNN network with the preset self-attention mechanism into the semantic defect analysis module.

[0045] Step S1035: Generate high-dimensional semantic feature vectors based on the semantic dependencies between paths using the ABCNN network.

[0046] In this embodiment, code semantic feature extraction is performed based on control flow graphs and deep learning, enabling deep semantic analysis and accurate characterization of software defects. First, a control flow graph of the target code fragment is generated and defect paths are extracted. The structural information of the code is combined with the defect-oriented path information, providing a structured input foundation for subsequent analysis. Then, the path2vec algorithm is used to convert the defect paths into vector representation data, achieving a numerical representation of the code paths. Finally, by importing an ABCNN network with a pre-defined self-attention mechanism, this network can deeply mine the semantic dependencies between paths, thereby generating high-dimensional semantic feature vectors that comprehensively represent the semantic features of the code. This provides high-quality, context-rich input data for subsequent defect matching, retrieval, and repair.

[0047] Figure 4 The diagram shows a test method. In one embodiment, as shown... Figure 4 As shown, step S500 includes: Step S501: Write the real-time repair plan and multiple historical repair plans into the first isolated sandbox of the code file system, compile them, and run the test process in sequence.

[0048] Based on step S501, the software defect confirmation method based on code semantic feature extraction further includes: Step S510: If the test fails, analyze the error log and rotate to the next repair solution.

[0049] This embodiment achieves secure verification and automated selection of repair solutions by introducing an isolated sandbox testing and automatic rotation mechanism. First, the real-time repair solution and multiple historical repair solutions are written into the first isolated sandbox of the code file system for compilation and sequential execution of the test process. This verifies the feasibility of each solution in an isolated environment, avoiding the risks that might be introduced by directly modifying production code and ensuring the security of the testing process. Second, when a repair solution fails to test, the system can automatically analyze the error log and rotate to the next repair solution. This achieves automated iteration and selection of repair solutions, continuously trying until a stable solution that passes the tests is found without manual intervention, significantly improving the efficiency and robustness of the repair process.

[0050] Figure 5 The diagram illustrates a test method based on the fusion repair scheme. In one embodiment, as shown... Figure 5 As shown, software defect identification methods based on code semantic feature extraction also include: Step S410: Combine the specified real-time repair scheme with the specified historical repair scheme to generate a fused repair scheme.

[0051] Step S420: Write the fusion repair solution into the second isolated sandbox of the code file system, compile it, and run the test process sequentially.

[0052] After step S420, determine whether step S600 is triggered.

[0053] In this embodiment, the fusion and independent verification of repair schemes are achieved during application. First, a fused repair scheme is generated by combining a specified real-time repair scheme with a specified historical repair scheme. This leverages the advantages of repair strategies from different sources, potentially producing a better repair effect than a single scheme. Subsequently, the fused repair scheme is written into a dedicated second isolated sandbox for compilation and testing. Its feasibility and effectiveness are independently evaluated in a completely isolated environment, avoiding interference with the original scheme's testing process and ensuring accurate verification of the innovative combined scheme. Finally, based on the test results, it is determined whether to trigger the subsequent step S600 (outputting a stable repair patch). This achieves adaptive decision-making based on verification results, incorporating only verified and effective fused schemes into the final output process, thereby improving the reliability and upper limit of the repair effect of the entire repair system.

[0054] Figure 6 The diagram illustrates a method for determining a fusion repair scheme based on a ratio. In one embodiment, as shown... Figure 6 As shown, step S410 includes: Step S411: Divide the specified real-time repair scheme and the specified historical repair scheme according to the set ratio.

[0055] Step S412: Combine the real-time repair scheme and the historical repair scheme after segmentation to obtain the fused repair scheme.

[0056] Step S413: Obtain adjustment instructions to adjust the set ratio.

[0057] In application, this embodiment implements an adjustable ratio segmentation and combination mechanism for repair schemes, enabling flexible construction and dynamic optimization of fused repair schemes. First, by segmenting specified real-time and historical repair schemes according to a set ratio, the core components of repair schemes from different sources can be structurally decomposed. Then, the segmented parts are combined to generate a fused repair scheme, thereby integrating the advantages of different repair strategies and potentially producing a repair effect superior to a single scheme. Finally, by obtaining adjustment commands to adjust the set ratio, users or the system can dynamically adjust the fusion weight of the two schemes based on actual test feedback or specific needs, achieving fine-grained control and adaptive optimization of the fused repair scheme, further enhancing the flexibility and specificity of the repair scheme.

[0058] Specifically, the code can first be split proportionally based on lines of code. This method divides the code of the real-time fix and the historical fix according to the proportion of lines. For example, a ratio of 70% : 30% could be set, extracting the first 70% of the code lines from the real-time fix and the last 30% from the historical fix; or 70% could be the core logic and 30% the supplementary logic. Then, the two can be combined to form a merged fix.

[0059] Another approach is to segment the solution based on functional modules. This method divides the repair plan into functional modules, such as error handling, data verification, and algorithm core modules, and sets a weight ratio for each module. For example, the ratio could be set as 20% for error handling, 20% for data verification, and 60% for the algorithm core module. Then, the code lines for the algorithm core module are extracted from the real-time repair plan, while the code lines for the error handling and data verification modules are extracted from historical repair plans. These are then combined to obtain the fused repair plan. This method retains the optimal specific functional parts of each plan, resulting in better fusion performance.

[0060] The segmentation ratio can also be dynamically adjusted based on the confidence score generated in step S18. For example, if the confidence score of the real-time repair solution is 0.8 and the confidence score of the historical repair solution is 0.6, the segmentation ratio is automatically calculated to be 80%:20%, meaning the real-time solution dominates. If the confidence score of the historical solution is higher, its proportion will increase accordingly. This method allows the system to automatically adjust the fusion weights according to the solution quality without manual intervention, thus automating the adjustment instructions in step S413.

[0061] The segmentation ratio can also be adjusted based on the test results of step S420. For example, if the initial ratio is set to 50% : 50%, and the test fails, the system automatically adjusts the ratio to 60% : 40%, with 60% extracted from the real-time repair solution and 40% extracted from the historical repair solution to increase the proportion of the real-time repair solution. If the test fails again after adjustment, the ratio is adjusted to 40% : 60% to increase the proportion of the historical solution, with 40% extracted from the real-time repair solution and 60% extracted from the historical repair solution.

[0062] Figure 7 The diagram illustrates a method for statistical analysis and identification of high-frequency defect cases. In one embodiment, as shown... Figure 7 As shown, step S800 includes: Step S801: Call the manager agent to periodically review historical defect cases accumulated in the long-term memory.

[0063] Step S802: If the main manager Agent identifies historical defect cases that occur within a preset frequency range, mark them as high-frequency defect cases.

[0064] In this embodiment, the manager agent periodically reviews and automatically identifies historical defect cases, achieving proactive monitoring and precise labeling of high-frequency defects. First, the manager agent periodically reviews historical defect cases accumulated in the long-term memory, continuously tracking the distribution and trends of defects, avoiding the lag and omissions of manual review. Second, when the manager agent identifies a historical defect case occurring within a preset frequency range, it automatically labels it as a high-frequency defect case, accurately identifying high-frequency defects. This provides a clear target for subsequent targeted optimization and updates of remediation plans, enabling the system to shift from passive remediation to proactive prevention, effectively reducing the frequency of high-frequency defects.

[0065] Figure 8 The diagram illustrates a method for analyzing repair solutions for high-frequency defect cases. In one embodiment, as shown... Figure 8 As shown, step S800 further includes: Step S803: Call the manager agent in the background to analyze high-frequency defect cases based on the preset repair database to obtain reference repair solutions.

[0066] Step S804: Update the corresponding historical repair scheme based on the reference repair scheme.

[0067] In this embodiment, the manager agent automatically analyzes and updates repair plans in the background based on a preset repair database, achieving intelligent optimization and continuous iteration of repair strategies for high-frequency defect cases. First, the manager agent can perform in-depth analysis of marked high-frequency defect cases in the background based on the preset repair database, automatically generating or matching more targeted reference repair plans without manual intervention, thus improving optimization efficiency. Subsequently, based on this reference repair plan, the corresponding historical repair plans are updated, allowing the repair plans in the long-term memory to dynamically evolve. This ensures that when encountering similar high-frequency defects in the future, the system can call upon better repair plans, thereby effectively reducing the frequency of this defect type.

[0068] Figure 9 The diagram illustrates a method for analyzing repair solutions for high-frequency defect cases based on expert experience. In one embodiment, as shown... Figure 9 As shown, step S800 further includes: Step S805: Call the manager agent to send high-frequency defect cases to the expert experience database and obtain reference repair solutions.

[0069] Step S806: Update the corresponding historical repair scheme based on the reference repair scheme.

[0070] In this embodiment, the mechanism of sending high-frequency defect cases to the expert experience database through the manager agent to obtain and update repair solutions achieves the fusion and continuous optimization of expert knowledge for high-frequency defect repair strategies. The manager agent sends automatically identified high-frequency defect cases to the expert experience database, thereby introducing expert knowledge and experience, overcoming the potential limitations of purely automated systems, and obtaining more in-depth and targeted reference repair solutions. Subsequently, based on this reference repair solution, the corresponding historical repair solutions are updated, allowing the repair solutions in the long-term memory to incorporate expert experience and dynamically evolve. This ensures that when encountering similar high-frequency defects in the future, the system can call upon better repair solutions, thereby effectively reducing the frequency of this type of defect and realizing the combination of automated systems and human expert experience.

[0071] Figure 10 The diagram shown is a schematic representation of a software defect verification system based on code semantic feature extraction, according to an embodiment of this application. This application also provides a software defect verification system based on code semantic feature extraction, such as... Figure 10 As shown, in one embodiment, the system includes: an analysis module 1001, a repair module 1002, and a management update module 1003.

[0072] The analysis module 1001 is configured to execute the following steps: Step S100: Deploy the analysis agent to receive and parse the input data, and obtain the high-dimensional semantic feature vector corresponding to the target code fragment based on the semantic defect analysis module; Step S200: Call the analysis agent to retrieve multiple historical defect cases that match the high-dimensional semantic feature vector in the preset long-term memory based on vector similarity; Step S300: Compare the target code fragment and historical defect cases to generate a defect analysis report; The defect analysis report includes abnormal code lines, defect types, and confidence scores.

[0073] The repair module 1002 is communicatively connected to the analysis module 1001. The repair module 1002 is configured to execute the following steps: Step S400: Deploy the repair agent to read the context of the target code fragment from the defect analysis report, generate a real-time repair plan based on the defect type and context (Plan A: Modify the algorithm logic; Plan B: Add exception capture; Plan C: Adjust the data structure), and obtain multiple historical repair plans corresponding to multiple historical defect cases from the long-term memory; Step S500: Test the real-time repair plan and multiple historical repair plans in sequence; Step S600: If the test passes, output a stable repair patch according to the corresponding repair plan and import it into the long-term memory.

[0074] The management update module 1003 is connected to the repair module 1002. The management update module 1003 is configured to execute the following steps: Step S700: The deployment manager agent collects defect analysis reports and stable repair patches to form a complete defect handling case, and stores the defect handling case as a historical defect case in the long-term memory; Step S800: The manager agent automatically reviews the historical defect cases in the long-term memory to obtain high-frequency defect cases, and configures the repair scheme for the high-frequency defect cases to update the corresponding historical repair scheme.

[0075] In this embodiment, the analysis agent automatically parses the input data and uses semantic feature vectors for similarity retrieval, enabling rapid matching of historical defect cases. This allows for the efficient and accurate generation of defect analysis reports containing abnormal code lines, defect types, and confidence scores. The remediation agent can automatically generate multiple remediation plans based on the analysis report, such as modifying algorithms or adding anomaly detection. These plans are then tested in an isolated environment along with historical plans, ultimately outputting a validated and stable remediation patch, thus automating the process from analysis to remediation. The managing agent stores successful remediation cases in a long-term memory and automatically reviews historical cases in the database to identify high-frequency defects, thereby optimizing remediation plans accordingly. This allows the system to continuously accumulate experience, proactively reducing the frequency of high-frequency defects and moving from passive remediation to proactive prevention.

[0076] The basic principles of this application have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this application are merely examples and not limitations, and should not be considered as essential features of each embodiment of this application. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the application to the necessity of employing the aforementioned specific details for implementation.

[0077] The block diagrams of devices, apparatuses, devices, and systems involved in this application are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0078] It should also be noted that in the apparatus, equipment, and methods of this application, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions of this application.

[0079] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this application. Therefore, this application is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features of the invention herein.

[0080] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications or equivalent substitutions made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A software defect identification method based on code semantic feature extraction, characterized in that, include: Step S100: The deployment analysis agent receives and parses the input data, and obtains the high-dimensional semantic feature vector corresponding to the target code fragment based on the semantic defect analysis module; Step S200: Call the analysis agent to retrieve multiple historical defect cases that match the high-dimensional semantic feature vector in the preset long-term memory based on vector similarity; Step S300: Compare the target code snippet with the historical defect cases to generate a defect analysis report; the defect analysis report includes abnormal code lines, defect types, and confidence scores; Step S400: The deployment repair agent reads the context of the target code fragment from the defect analysis report, generates a real-time repair plan based on the defect type and context, and obtains multiple historical repair plans corresponding to multiple historical defect cases from the long-term memory. Step S500: Test the real-time repair scheme and multiple historical repair schemes in sequence; Step S600: If the test passes, output a stable repair patch according to the corresponding repair scheme and import it into the long-term memory. Step S700: The deployment manager Agent collects the defect analysis report and the stability patch to form a complete defect handling case, and stores the defect handling case as the historical defect case in the long-term memory. Step S800: Call the manager agent to automatically review the historical defect cases in the long-term memory to obtain high-frequency defect cases, and configure the repair scheme for the high-frequency defect cases to update the corresponding historical repair scheme.

2. The software defect confirmation method based on code semantic feature extraction according to claim 1, characterized in that, Step S100 includes: Step S101: Invoke the analysis agent to generate structured task description data based on the input data; the input data includes code change content and error logs, and the structured task description data includes target file, code scope and problem type; Step S102: Based on the structured task description data, call the analysis agent to import the target code fragment in the input data into the preset semantic defect analysis module; Step S103: In the semantic defect analysis module, the vector parameters of the target code segment are analyzed to obtain the high-dimensional semantic feature vector.

3. The software defect confirmation method based on code semantic feature extraction according to claim 2, characterized in that, Step S103 includes: Step S1031: Generate the control flow graph of the target code fragment in the semantic defect analysis module; Step S1032: Extract the defect path of the target code segment based on the control flow graph; Step S1033: Use the path2vec algorithm to convert the defect path into vector representation data; Step S1034: Import the ABCNN network with a preset self-attention mechanism into the semantic defect analysis module; Step S1035: Generate high-dimensional semantic feature vectors based on the semantic dependencies between paths using the ABCNN network.

4. The software defect confirmation method based on code semantic feature extraction according to claim 1, characterized in that, Step S500 includes: Step S501: Write the real-time repair scheme and multiple historical repair schemes into the first isolated sandbox of the code file system, compile them, and run the test process sequentially; The method further includes: Step S510: If the test fails, analyze the error log and rotate to the next repair solution.

5. The software defect confirmation method based on code semantic feature extraction according to claim 1, characterized in that, Also includes: Step S410: Combine the specified real-time repair scheme with the specified historical repair scheme to generate a fused repair scheme; Step S420: Write the fusion repair scheme into the second isolated sandbox of the code file system, compile it, and run the test process sequentially; After step S420, determine whether step S600 is triggered.

6. The software defect confirmation method based on code semantic feature extraction according to claim 5, characterized in that, Step S410 includes: Step S411: Divide the specified real-time repair scheme and the specified historical repair scheme according to the set ratio; Step S412: Combine the segmented real-time repair scheme and the historical repair scheme to obtain the fused repair scheme; Step S413: Obtain adjustment instructions to adjust the set ratio.

7. The software defect confirmation method based on code semantic feature extraction according to claim 1, characterized in that, Step S800 includes: Step S801: Call the manager agent to periodically review the historical defect cases accumulated in the long-term memory; Step S802: If the manager Agent identifies a historical defect case that occurs within a preset frequency range, mark it as a high-frequency defect case.

8. The software defect confirmation method based on code semantic feature extraction according to claim 7, characterized in that, Step S800 further includes: Step S803: Call the manager agent in the background to analyze the high-frequency defect cases based on the preset repair database to obtain a reference repair solution; Step S804: Update the corresponding historical repair scheme based on the reference repair scheme.

9. The software defect confirmation method based on code semantic feature extraction according to claim 7, characterized in that, Step S800 further includes: Step S805: Call the manager agent to send the high-frequency defect cases to the expert experience database and obtain reference repair solutions; Step S806: Update the corresponding historical repair scheme based on the reference repair scheme.

10. A software defect confirmation system based on code semantic feature extraction, characterized in that, include: The analysis module is configured to execute the following steps: Step S100: Deploy the analysis agent to receive and parse the input data, and obtain the high-dimensional semantic feature vector corresponding to the target code fragment based on the semantic defect analysis module; Step S200: Call the analysis agent to retrieve multiple historical defect cases that match the high-dimensional semantic feature vector from a preset long-term memory based on vector similarity; Step S300: Compare the target code fragment and the historical defect cases to generate a defect analysis report; The defect analysis report includes abnormal code lines, defect types, and confidence scores. The repair module is communicatively connected to the analysis module. The repair module is configured to execute the following steps: Step S400: Deploy the repair agent to read the context of the target code fragment from the defect analysis report, generate a real-time repair plan based on the defect type and context, and obtain multiple historical repair plans corresponding to multiple historical defect cases from the long-term memory; Step S500: Test the real-time repair plan and multiple historical repair plans sequentially; Step S600: If the test passes, output a stable repair patch according to the corresponding repair plan and import it into the long-term memory. The management update module is connected to the repair module. The management update module is configured to execute the following steps: Step S700: The deployment manager agent collects the defect analysis report and the stable repair patch to form a complete defect handling case, and stores the defect handling case as the historical defect case in the long-term memory; Step S800: The manager agent automatically reviews the historical defect cases in the long-term memory to obtain high-frequency defect cases, and configures the repair scheme of the high-frequency defect cases to update the corresponding historical repair scheme.

Images