Software Defect Localization and Repair Recommendation Method Based on Code Semantic Vectors

Abstract

This invention relates to a software defect localization and repair recommendation method based on code semantic vectors, comprising: acquiring the source code, failure execution information, and preset failure explanation conditions of the software to be tested; the preset failure explanation conditions including vector matching thresholds and stage order relationships corresponding to the failure input entry stage, the abnormal semantic generation stage, and the failure result formation stage; dividing the source code into multiple code segments, generating code semantic vectors for each code segment, and generating failure semantic vectors based on the failure execution information; determining a candidate code segment set based on a similarity threshold; performing responsibility shrinkage processing according to a preset removal order, deleting unnecessary segments and retaining necessary segments, identifying the retained code segments as defect localization results, and generating repair recommendations based on their code semantic vectors. This invention can reduce irrelevant repairs or superficial matching repair suggestions, improve the consistency between repair recommendations and actual failure causes, and improve the efficiency of software defect repair.

Description

Technical Field

[0001] This invention relates to the field of software defect localization and repair recommendation technology, specifically a software defect localization and repair recommendation method based on code semantic vectors. Background Technology

[0002] In existing technologies, software defect detection, localization, and repair recommendations typically rely on static rules, historical repair examples, code similarity matching, or deep learning models to identify defective code and generate repair suggestions. As software systems grow in scale, the relationships between function calls, exception propagation, input-output relationships, and runtime failure information within the source code become more complex. Relying solely on syntax rules or local code text similarity for judgment can easily lead to problems such as an excessively large range of candidate defects, unclear explanation chains of defect causes, and discrepancies between repair suggestions and actual failure results. For example, Chinese patent CN118427080A discloses a deep learning-based method for recommending code defect repair schemes. This method obtains method-level granular defective code fragments, extracts feature vectors by combining defect type label information, calculates the similarity between defective code and historical repaired code using a Doc2Vec model, and then re-ranks candidate repair codes using a binary classification text convolutional neural network to obtain recommended repair schemes. This type of approach can improve the relevance of the recommended remediation solutions, but it mainly focuses on matching defective code snippets with historical remediation code and emphasizes screening similar solutions from historical remediation cases. It still lacks direct constraints on the stage-by-stage explanatory relationship between how failed inputs enter the program, how abnormal semantics are generated, and how failed results are formed.

[0003] Existing technologies also include modular approaches that combine defect identification with automatic repair. For example, Chinese patent CN118503110A discloses a method for identifying and repairing source code defects. This method is based on a source code I / O module, a source code defect detection module, and a source code automatic repair module. The source code defect detection module identifies potential defects and outputs defect and error information through static analysis, semantic analysis, and style analysis. The source code automatic repair module uses an AST template-driven automatic repair method to repair upstream code defects. This technology can automatically detect and repair defects related to coding standards or those that can be expressed in templates. However, its repair reliance is mainly on rules, AST templates, and defect information output by the detection module. It does not adequately distinguish the causality, necessity, and responsibility contraction relationships between candidate segments and the semantic vectors of multiple code segments in the failure information.

[0004] Therefore, in the field of software defect localization and repair recommendation, there is still a need for a technical solution that can uniformly express source code, failure runtime information, and preset failure explanation conditions. This solution would enable multiple code segments of the software under test to form code semantic vectors, and transform failure runtime information into failure semantic vectors. After similarity screening, responsibility contraction processing would be used to determine the necessity of each candidate code segment for the failure explanation conditions, thereby avoiding overly broad defect candidate results generated solely based on similarity, rule hits, or historical case matching. Simultaneously, repair recommendations need to be generated based on the code semantic vectors of the retained code segments. These recommendations should not merely superficially resemble historical patches or satisfy local template replacements, but rather weaken or disrupt the failure explanation chain by addressing the stages of failure input, abnormal semantic generation, and failure result formation. This would improve the accuracy, interpretability, and engineering applicability of defect localization and repair recommendation results. Summary of the Invention

[0005] The purpose of this invention is to provide a software defect location and repair recommendation method based on code semantic vectors, thereby solving some of the drawbacks and shortcomings pointed out in the background art.

[0006] The present invention adopts the following technical solution to solve the above-mentioned technical problems:

[0007] The source code, failure running information, and preset failure explanation conditions of the software to be tested are obtained. The preset failure explanation conditions include vector matching thresholds and stage order relationships corresponding to the failure input entry stage, the abnormal semantic generation stage, and the failure result formation stage.

[0008] The source code is divided into multiple code segments, and code semantic vectors are generated for each code segment. Failure semantic vectors are also generated based on the failure execution information. Based on the similarity threshold between the failure semantic vectors and each code semantic vector, a set of candidate code segments that are semantically related to the failure result is determined.

[0009] The responsibility shrinking process is performed on the candidate code snippet set according to a preset removal order. The responsibility shrinking process includes: temporarily removing the code semantic vector corresponding to a candidate code snippet; determining whether the remaining code semantic vectors meet the preset failure explanation conditions; deleting the candidate code snippet if they meet the conditions, and retaining the candidate code snippet if they do not meet the conditions, until all remaining candidate code snippets do not meet the deletion conditions; determining the retained code snippets as defect localization results, and generating repair recommendations based on the code semantic vectors of the retained code snippets.

[0010] Furthermore, the preset failure interpretation conditions are judged according to the failure input entry stage, the abnormal semantic generation stage, and the failure result formation stage; after temporarily removing a candidate code segment, the stage in which the remaining code semantic vectors cannot satisfy the vector matching threshold for the first time is recorded as the semantic breakpoint of the candidate code segment, and the positioning priority of the candidate code segment whose semantic breakpoint is located in the abnormal semantic generation stage is set to be higher than that of the candidate code segment whose semantic breakpoint is located in the failure input entry stage or the failure result formation stage.

[0011] Furthermore, during the execution of the responsibility contraction process, the pass operation information is obtained and a pass semantic vector is generated; if the retained candidate code segment is necessary to maintain the operation result under both the failure semantic vector and the pass semantic vector, and the semantic difference corresponding to the candidate code segment is not transmitted to the failure result, then the candidate code segment is excluded from the defect location result according to the preset exclusion conditions, or the location priority of the candidate code segment is reduced according to the preset downgrade conditions.

[0012] Furthermore, the repair recommendation is generated based on the semantic change direction that makes the preset failure explanation condition not true; after applying the repair recommendation, the responsibility contraction process is performed again. If the set of code semantic vectors after applying the repair recommendation does not meet the preset failure explanation condition, and the original explanation result is maintained by the semantic vectors corresponding to the running information, then the repair recommendation is output.

[0013] Furthermore, the semantic breakpoint is determined using a reverse verification method; when the failure result formation stage cannot be interpreted after temporarily removing a candidate code segment, it is further determined whether the abnormal semantic generation stage can still be interpreted. If it can be interpreted, the semantic breakpoint is determined as the failure result formation stage; if it cannot be interpreted, the semantic breakpoint is backtracked to determine the abnormal semantic generation stage.

[0014] Furthermore, the responsibility shrinking process is repeatedly executed according to multiple preset removal orders; if the semantic breakpoints of the same candidate code segment belong to the same stage under multiple preset removal orders, the positioning priority of the candidate code segment as a defect location result is increased; if the stage to which the semantic breakpoint belongs changes with the preset removal order, the positioning priority of the candidate code segment is decreased.

[0015] Furthermore, after determining the semantic breakpoint, it is determined whether the retained candidate code segment causes the semantic breakpoint of other candidate code segments to move from the failure result formation stage to the abnormal semantic generation stage, or from the abnormal semantic generation stage to the failure input entry stage; if the stage shift occurs, the candidate code segment that causes the stage shift is determined as the abnormal transmission segment, and the positioning priority of the abnormal transmission segment is set to be lower than that of the candidate code segment corresponding to the abnormal semantic generation stage.

[0016] Furthermore, the semantic change direction is determined by the inclusion relationship between candidate semantic change directions; when the first candidate semantic change direction can make the preset failure explanation condition not true, and the code semantic vector content changed by the second candidate semantic change direction contains the code semantic vector content changed by the first candidate semantic change direction, the first candidate semantic change direction is determined as the semantic change direction for generating repair recommendations.

[0017] Furthermore, after applying the repair recommendation, if the retained code fragment obtained by performing the responsibility contraction process again changes, it is determined whether the changed retained code fragment still has a semantic association with the failure result; if there is still a semantic association, the output priority of the repair recommendation is reduced; if there is no semantic association, and the original interpretation result is maintained through the semantic vector corresponding to the running information, the output priority of the repair recommendation is increased.

[0018] Furthermore, if the modified retained code fragment still has a semantic association with the failure result, the source of semantic association before and after applying the repair recommendation is compared; when the source of semantic association shifts from the original retained code fragment to the modified retained code fragment, and the explanation stage of the failure result does not move from the failure result formation stage to the abnormal semantic generation stage or the failure input entry stage, the repair recommendation is determined to be a failure migration type repair, and the output of the repair recommendation is canceled.

[0019] This invention obtains the source code, failure execution information, and preset failure explanation conditions of the software to be tested. It divides the source code into multiple code segments and generates a code semantic vector for each code segment. At the same time, it generates a failure semantic vector based on the failure execution information. Then, it determines a set of candidate code segments based on the similarity threshold between the failure semantic vector and each code semantic vector. This allows the establishment of a semantic association between the execution failure information and the source code segments before defect localization, avoiding localization errors caused by relying solely on keywords, rule hits, or single historical code similarity.

[0020] This invention performs a responsibility shrinking process on the candidate code segment set according to a preset removal order. After temporarily removing the code semantic vector corresponding to a candidate code segment, it determines whether the remaining code semantic vectors still meet the preset failure interpretation conditions. If they do, the candidate code segment is deleted; otherwise, it is retained, until none of the remaining candidate code segments meet the deletion conditions. Through this process, code segments that only have superficial or redundant semantic connections to the failure result can be excluded from the candidate set, making the ultimately retained code segments more reflective of their necessary contribution to the failure interpretation chain, thereby improving the accuracy and interpretability of the defect localization results.

[0021] This invention identifies retained code snippets as defect localization results and generates repair recommendations based on the code semantic vectors of these snippets. These recommendations are generated directly around the key code semantics verified through responsibility contraction. Since these repair recommendations originate from the matching and contraction results between failure semantic vectors, code semantic vectors, and preset failure explanation conditions, they reduce irrelevant, redundant, or superficially matching repair suggestions, improve the consistency between repair recommendations and actual failure causes, and ultimately enhance the efficiency of software defect repair. Attached Figure Description

[0022] Figure 1 This is a flowchart of the software defect location and repair recommendation method based on code semantic vectors according to the present invention.

[0023] Figure 2 This is a similarity screening diagram of candidate code segments in Embodiment 1 of the present invention.

[0024] Figure 3 This is a semantic breakpoint determination diagram for responsibility contraction in Embodiment 1 of the present invention.

[0025] Figure 4 This is a comparison chart of the priority of candidate code segment location in Embodiment 1 of the present invention.

[0026] Figure 5 This is a comparison chart of the semantic differences of code fragments in Embodiment 2 of the present invention.

[0027] Figure 6 This is a verification diagram of the candidate repair direction index in Embodiment 2 of the present invention.

[0028] Figure 7 This is a comparison chart of the repair recommendation output scores in Embodiment 2 of the present invention. Detailed Implementation

[0029] As attached Figure 1As shown, in one embodiment, the software defect localization and repair recommendation method based on code semantic vectors can be used to locate the defect location in the software to be tested and generate corresponding repair recommendations based on the localization results. During implementation, the source code and failure runtime information of the software to be tested are first obtained, along with preset failure interpretation conditions. The source code may include the source files, dependency files, configuration files, and interface call information related to the runtime path of the software to be tested. The failure runtime information may include failed test cases, exception logs, error messages, call stack information, and intermediate state information during runtime. The preset failure interpretation conditions include vector matching thresholds corresponding to the failure input entry stage, the exception semantic generation stage, and the failure result formation stage, as well as the stage order relationship between the above three stages. The stage order relationship is used to limit the failure input to first enter the relevant code segment, then form the exception semantics, and finally form the failure output or exception result, thereby enabling subsequent judgments to be performed step by step according to the failure generation process. The vector matching thresholds can be determined by historical defect samples, manual configuration experience, or normal operation samples of the software to be tested, and should remain consistent throughout the same testing process.

[0030] After obtaining the source code, it is divided into multiple code segments according to functions, statement blocks, basic blocks, or a preset number of lines. Semantic features are then extracted from each segment to obtain a corresponding code semantic vector. Semantic features can include identifiers, variable read / write relationships, conditional statements, function call relationships, parameter passing relationships, exception handling statements, return statements, control flow relationships, and data dependencies within the code segment. In practice, these semantic features can be input into a pre-trained code semantic encoding model, or corresponding code semantic vectors can be generated using preset feature encoding rules. Simultaneously, semantic features such as failure inputs, exception states, and failure outputs are extracted based on failure runtime information to generate failure semantic vectors. The failure semantic vectors and code semantic vectors reside in the same semantic representation space, enabling semantic matching. Subsequently, similarity calculations are performed between the failure semantic vectors and each code semantic vector. Similarity calculations can use vector similarity calculations, semantic matching model outputs, or vector distance transformation results. Code segments whose similarity meets a similarity threshold are identified as candidate code segments semantically related to the failure result, thus forming a set of candidate code segments.

[0031] After determining the candidate code segment set, responsibility shrinking is performed on the candidate code segment set according to a preset removal order. The preset removal order can be determined based on the position of the code segments in the source code, the degree of matching between the candidate code segments and the failure semantic vector, the order of calls in the call chain, or data dependencies. Specifically, the code semantic vector corresponding to a candidate code segment is temporarily removed, and the remaining code semantic vector is used to determine whether the failure input entry stage, the abnormal semantic generation stage, and the failure result formation stage still meet the preset failure interpretation conditions. Temporary removal is only used to determine whether the candidate code segment participates in failure interpretation and does not change the actual source code of the software under test. If the remaining code semantic vector still meets the preset failure interpretation conditions, it means that the temporarily removed candidate code segment is not a segment necessary to maintain failure interpretation, and the candidate code segment is deleted from the candidate code segment set. If the remaining code semantic vector does not meet the preset failure interpretation conditions, it means that the temporarily removed candidate code segment participates in maintaining failure interpretation, and the candidate code segment is retained. Candidate code segments are processed in the above manner, and the current candidate code segment set is updated after each deletion or retention, until the remaining candidate code segments no longer meet the deletion conditions, and the finally retained code segment is determined as the defect localization result. Furthermore, semantic features related to defects are determined based on the code semantic vectors of the preserved code fragments, and repair recommendations for eliminating failure results are generated by combining the failure semantic vectors.

[0032] In one embodiment, the preset failure interpretation conditions can be judged according to the failure input entry stage, the abnormal semantic generation stage, and the failure result formation stage. Specifically, after temporarily removing a candidate code segment, the remaining code semantic vector is first used to match and judge the failure input entry stage, then the abnormal semantic generation stage, and finally the failure result formation stage. The matching judgment for the failure input entry stage can be determined based on whether there are semantic features in the remaining code semantic vector corresponding to failure input, entry function, input parameters, or call entry points; the matching judgment for the abnormal semantic generation stage can be determined based on whether there are semantic features in the remaining code semantic vector corresponding to abnormal states, error conditions, boundary value handling, or abnormal branches; the matching judgment for the failure result formation stage can be determined based on whether there are semantic features in the remaining code semantic vector corresponding to abnormal output, error return, log error, or test assertion failure. If the remaining code semantic vector corresponding to a certain stage does not meet the vector matching threshold for that stage, then that stage is recorded as the semantic breakpoint of the temporarily removed candidate code segment. In this way, the position of the candidate code segment in the failure generation process can be determined. Since the abnormal semantic generation stage usually corresponds to the location where the defect semantics begin to appear, candidate code segments with semantic breakpoints located in the abnormal semantic generation stage are set to a higher positioning priority, and their positioning priority is higher than that of candidate code segments with semantic breakpoints located in the failed input entry stage or the failed result formation stage, thereby improving the accuracy of defect positioning results.

[0033] In one embodiment, semantic breakpoints can also be determined using a reverse verification method. Specifically, when a candidate code segment is temporarily removed, if the failure result formation stage cannot be interpreted by the remaining code semantic vectors, it is further determined whether the abnormal semantic generation stage can still be interpreted by the remaining code semantic vectors. If the abnormal semantic generation stage can still be interpreted, it indicates that the removed candidate code segment mainly affects the failure result formation process, and therefore the semantic breakpoint is determined as the failure result formation stage. If the abnormal semantic generation stage cannot be interpreted, it indicates that the removed candidate code segment has already affected the abnormal semantic generation process, and therefore the semantic breakpoint is backtracked to determine the abnormal semantic generation stage. If the failure input entry stage also cannot be interpreted, it indicates that the candidate code segment may still participate in the failure input entry code path process, and the candidate code segment is associated with the failure input entry stage. Through the above reverse verification method, the misjudgment of the function stage of the candidate code segment can be avoided based solely on the judgment result of the failure result formation stage.

[0034] In one embodiment, to reduce the impact of a preset removal order on the responsibility shrinking process results, the responsibility shrinking process can be repeatedly executed according to multiple preset removal orders. Specifically, preset removal orders can be set according to the position order of candidate code segments in the source code, the similarity order with failure semantic vectors, the call chain order, or the data dependency order, and the stage to which the semantic breakpoints corresponding to the same candidate code segment belong is recorded under each preset removal order. If the semantic breakpoints corresponding to the same candidate code segment belong to the same stage under multiple preset removal orders, it indicates that the relationship between the candidate code segment and the corresponding failure stage is stable, thus increasing the positioning priority of the candidate code segment as a defect localization result. If the stage to which the semantic breakpoints of the same candidate code segment belong changes with the preset removal order, it indicates that the influence of the candidate code segment on the failure explanation is affected by the combination relationship of other candidate code segments, thus reducing the positioning priority of the candidate code segment. Candidate code segments that are retained under multiple preset removal orders can be used as the main defect localization results; candidate code segments that are retained only under some preset removal orders can be used as auxiliary defect localization results.

[0035] In one embodiment, after determining the semantic breakpoint, it can be further determined whether the retained candidate code segment causes a stage shift in the semantic breakpoints of other candidate code segments. Specifically, when a candidate code segment is retained, if the semantic breakpoints of other candidate code segments move from the failure result formation stage to the exception semantic generation stage, or from the exception semantic generation stage to the failure input entry stage, then the candidate code segment causing the aforementioned movement is identified as an exception propagation segment. An exception propagation segment indicates that the candidate code segment may participate in the propagation of exception semantics between code segments, but it is not necessarily the initial position of exception semantic generation. Exception propagation segments may include code segments that pass exception parameters, code segments that continue to propagate error return values, code segments that trigger subsequent exception branches, or code segments that write exception states to shared variables. Therefore, the positioning priority of exception propagation segments is set to be lower than that of candidate code segments corresponding to the exception semantic generation stage, so that the positioning results preferentially point to code segments closer to the source of the defect.

[0036] In one embodiment, during the responsibility contraction process, pass / fail information corresponding to the software under test can be obtained, and a pass / fail semantic vector can be generated based on the pass / fail information. The pass / fail information may include input data of the pass / fail test cases, normal operation logs, normal return results, call stack information, and intermediate state information during operation. The pass / fail semantic vector is used to characterize the code semantic state of the software under test in a normal operation scenario, and together with the failure semantic vector, it is used to determine whether candidate code segments are directly related to defective results. When generating the pass / fail semantic vector, the same semantic feature extraction method as that used to generate the failure semantic vector can be employed, enabling the pass / fail semantic vector and the failure semantic vector to be compared within the same semantic representation space.

[0037] In practice, for candidate code segments retained after responsibility contraction, it is determined whether each candidate code segment is required to maintain the running result under both the failure semantic vector and the pass semantic vector. If the candidate code segment participates in maintaining the failure result in the failure running scenario and also participates in maintaining the normal result in the pass running scenario, it is further determined whether the semantic difference corresponding to the candidate code segment is propagated to the failure result. The semantic difference can be determined based on the vector distance, semantic feature change, or stage matching result of the candidate code segment in the failure semantic vector and the pass semantic vector. The propagation of semantic difference to the failure result can be manifested as the abnormal state of the candidate code segment affecting subsequent branch selection, return result generation, exception throwing, log error reporting, or test assertion results. If the semantic difference is not propagated to the failure result, it means that although the candidate code segment participates in the formation of the running result, its difference is not the direct cause of the failure result.

[0038] In the above situations, the candidate code segment can be excluded from the defect localization results according to preset exclusion criteria, or its localization priority can be reduced according to preset downgrade criteria. The preset exclusion criteria may include that the semantic difference between the candidate code segment and the successful execution scenario is less than a difference threshold, and that this semantic difference has not been transmitted to the failure result formation stage through the abnormal semantic generation stage. The preset downgrade criteria may include that the candidate code segment has semantic differences, but the contribution of these semantic differences to the matching in the failure result formation stage is less than a preset contribution threshold. For excluded or downgraded candidate code segments, their association records with the defect localization results can be retained to determine whether the code segment belongs to the affected code segment when generating subsequent repair recommendations. This approach can reduce the occurrence of code segments required for normal operation being misidentified as defective code segments and improve the accuracy of defect localization results.

[0039] In one embodiment, repair recommendations can be generated based on semantic change directions that prevent preset failure explanation conditions from being met. Specifically, based on the code semantic vectors of the retained code segments in the defect localization results, abnormal semantic features related to the failure input entry stage, the abnormal semantic generation stage, and the failure result formation stage are first determined. Then, one or more candidate semantic change directions are generated. Candidate semantic change directions can represent modifications to variable value ranges, conditional judgment relationships, function call objects, parameter passing relationships, exception handling paths, or return result generation logic. When generating candidate semantic change directions, priority can be given to code segments whose semantic breakpoints are located in the abnormal semantic generation stage, determining modification directions that can block the generation of abnormal states or prevent the continued propagation of abnormal states. If a candidate semantic change direction can make the modified code semantic vector set no longer satisfy the preset failure explanation conditions, then that candidate semantic change direction is used as the basis for generating repair recommendations. Repair recommendations can include the location of the code segment to be modified, the corresponding abnormal semantic features, the type of suggested modification, and the reason for the suggested modification.

[0040] After applying the recommended fix, a new set of semantic vectors can be generated for the code, and responsibility shrinking can be performed again. If the set of semantic vectors after applying the recommended fix does not meet the preset failure explanation conditions, it means that the recommended fix can disrupt the semantic explanation chain of the failure result. Furthermore, it is determined whether the semantic vectors corresponding to the runtime information maintain the original explanation result. If the semantic vectors maintain the original explanation result, it means that the recommended fix has eliminated the failure result without disrupting the normal operating scenario, and therefore the recommended fix is ​​output. If the semantic vectors cannot maintain the original explanation result, it means that the recommended fix may affect the normal operating path, and the output priority of the recommended fix is ​​reduced or it is not output. Through the above methods, it is possible to avoid outputting fixes that only eliminate failure behavior but disrupt normal functionality.

[0041] In one embodiment, the semantic change direction can be determined by the inclusion relationship between candidate semantic change directions. Specifically, the code semantic vector content changed by each candidate semantic change direction is compared. If the first candidate semantic change direction can make the preset failure explanation condition not true, and the code semantic vector content changed by the second candidate semantic change direction includes the code semantic vector content changed by the first candidate semantic change direction, then the first candidate semantic change direction has a more concentrated modification range compared to the second candidate semantic change direction. Therefore, the first candidate semantic change direction is determined as the semantic change direction for generating repair recommendations to reduce unnecessary code modifications and improve the feasibility of repair recommendations. If multiple candidate semantic change directions can make the preset failure explanation condition not true, then the candidate semantic change direction with a smaller modification range, less impact on the pass-through information, and corresponding to the abnormal semantic generation stage is preferentially selected.

[0042] In one embodiment, after applying the repair recommendation, if the retained code segment obtained from the responsibility contraction process changes again, it is determined whether the changed retained code segment still has a semantic association with the failure result. If the changed retained code segment still has a semantic association with the failure result, it indicates that the repair recommendation may have only changed the associated code segment in the failure explanation chain, without eliminating the semantic cause corresponding to the failure result, thus reducing the output priority of the repair recommendation. If the changed retained code segment no longer has a semantic association with the failure result, and the original explanation result is maintained through the semantic vector corresponding to the runtime information, it indicates that the repair recommendation can eliminate the semantic association corresponding to the failure result and maintain the normal operation explanation result, thus increasing the output priority of the repair recommendation. The changed retained code segment can be obtained by re-dividing the code segment, regenerating the code semantic vector, and re-executing the stage matching judgment.

[0043] In one embodiment, if the modified retained code fragment still has a semantic association with the failure result, the source of semantic association before and after applying the repair recommendation is further compared. The source of semantic association can be determined based on the similarity between the retained code fragment and the failure semantic vector, the stage matching result, and the anomaly propagation relationship. When the source of semantic association shifts from the original retained code fragment to the modified retained code fragment, and the explanation stage of the failure result does not move from the failure result formation stage to the anomaly semantic generation stage or the failure input entry stage, it indicates that the repair recommendation has not converged the failure cause to an earlier stage, but rather migrated the failure manifestation to other code fragments. Therefore, the repair recommendation is judged as a failure migration repair, and the output of the repair recommendation is canceled. If the source of semantic association decreases after applying the repair recommendation, and the stage matching relationship corresponding to the failure result cannot continue to form a complete explanation chain, then the repair recommendation is judged as a valid repair recommendation and output is allowed.

[0044] Example 1:

[0045] In one embodiment, the software to be tested by Company A is a date parsing service, comprising 120 source files and 4380 lines of code. The source code, failure runtime information, and preset failure interpretation conditions of the software to be tested are obtained. The failure runtime information includes failed test cases, exception logs (IndexOutOfBoundsException), error messages, and call stack information, which sequentially points to DateParser.parse, DateParser.normalize, and DateValidator.checkRange. The preset failure interpretation conditions include vector matching thresholds for the failure input entry stage, the exception semantic generation stage, and the failure result formation stage. The vector matching threshold for the failure input entry stage is 0.62, for the exception semantic generation stage it is 0.70, and for the failure result formation stage it is 0.66. The three stages are preset to be judged in the order of failure input entry, exception semantic generation, and failure result formation.

[0046] After obtaining the source code, it was divided into 86 code segments based on functions, statement blocks, and basic blocks. For each code segment, identifiers, variable read / write relationships, conditional statements, function call relationships, parameter passing relationships, exception handling statements, return statements, control flow relationships, and data dependencies were extracted. A corresponding code semantic vector was generated based on the extraction results. Failure semantic vectors were generated based on failed test cases, the exception log `IndexOutOfBoundsException`, and call stack information, ensuring that the failure semantic vectors and the code semantic vectors reside in the same semantic representation space.

[0047] When determining the candidate code snippet set, the failed semantic vectors are semantically matched with the code semantic vectors of each code snippet, and the similarity is calculated according to the following formula:

[0048]

[0049] in, The failure semantic vector and the first Similarity between the code semantic vectors of code snippets This represents a failure semantic vector generated from failed test cases, exception logs, and the call stack. Indicates the first The code semantic vector of a code snippet This indicates the degree of overlap between the two in terms of semantic features. and These represent the vector lengths of the failure semantic vector and the code semantic vector, respectively, and are used to mitigate the impact of differences in the number of features in different code segments on the matching results.

[0050] Specifically, the dot product between code snippet C27 and the failure semantic vector is 5.67, the length of the failure semantic vector is 2.70, and the length of the code semantic vector corresponding to C27 is 2.59. Substituting the above data, we get:

[0051]

[0052] Therefore, C27 has a high semantic correlation with the failure semantic vector, which can be rounded to 0.81. Using the same method, the similarity is calculated as follows: C12 = 0.68, C34 = 0.74, and C51 = 0.69. Figure 2 The matching relationship between the aforementioned candidate code snippets and the failure semantic vector is shown. The candidate selection threshold is set to 0.66. C12, C27, C34, and C51 are all higher than this threshold, with C27 showing the highest similarity, indicating stronger semantic consistency with failed test cases, exception logs, and call stacks. Therefore, C12, C27, C34, and C51 are identified as candidate code snippets with semantic association to the failure result, forming a candidate code snippet set.

[0053] After forming a set of candidate code snippets, responsibility shrinking is performed according to a preset removal order. This preset removal order can be determined based on the code snippets' position in the source code, their similarity to failure semantic vectors, call chain order, or data dependency order. During execution, the code semantic vector corresponding to one candidate code snippet is temporarily removed, and the remaining code semantic vectors are used to determine whether the preset failure explanation conditions are still met in the failure input stage, the abnormal semantic generation stage, and the failure result formation stage. Temporary removal is only used to determine whether the candidate code snippet is necessary to maintain the failure explanation and does not change the actual source code of the software under test.

[0054] If, after temporarily removing C12, the remaining code semantic vectors still meet the vector matching thresholds for the failed input entry stage, the abnormal semantic generation stage, and the failed result formation stage, then C12 is not a necessary code segment for maintaining the failure interpretation, and C12 is removed from the candidate code segment set. If, after temporarily removing C27, the remaining code semantic vectors do not meet the vector matching threshold of 0.70 in the abnormal semantic generation stage, then C27 participates in maintaining the failure interpretation, and C27 is retained. C34 and C51 are processed sequentially in the same manner until none of the remaining candidate code segments meet the deletion conditions, and the finally retained code segment is taken as the defect localization result.

[0055] During the responsibility contraction process, the remaining code semantic vectors are judged in the order of the failure input entry stage, the abnormal semantic generation stage, and the failure result formation stage. The stage where the remaining code semantic vectors cannot meet the vector matching threshold for the first time is recorded as the semantic breakpoint where the candidate code segment is temporarily removed. Figure 3 This demonstrates the changes in matching values ​​at each failure interpretation stage after temporarily removing different candidate code snippets. After temporarily removing C27, the matching value for the failure input entry stage is 0.64, still meeting the vector matching threshold of 0.62. However, the matching value for the abnormal semantic generation stage is 0.58, which does not meet the vector matching threshold of 0.70. Therefore, the semantic breakpoint of C27 is recorded as the abnormal semantic generation stage. After temporarily removing C34, the matching value for the abnormal semantic generation stage is 0.69, lower than 0.70, and can also be recorded as a semantic breakpoint in the abnormal semantic generation stage. After temporarily removing C51, the matching value for the failure result formation stage is 0.59, lower than 0.66, indicating that C51 mainly affects the failure result formation stage. Since the abnormal semantic generation stage usually corresponds to the location where the defect semantics begin to appear, the positioning priority of C27 and C34 is set higher than that of C51, whose semantic breakpoint is located in the failure result formation stage.

[0056] In one embodiment, a reverse verification method is also used to correct semantic breakpoints. Specifically, when a candidate code segment is temporarily removed, if the failure result formation stage cannot be interpreted by the remaining code semantic vectors, it is further determined whether the abnormal semantic generation stage can still be interpreted by the remaining code semantic vectors. If the abnormal semantic generation stage can still be interpreted, it indicates that the removed code segment mainly affects the failure result formation process, and the semantic breakpoint is determined to be the failure result formation stage. If the abnormal semantic generation stage cannot be interpreted, it indicates that the removed code segment has affected the abnormal semantic generation process, and the semantic breakpoint is backtracked to determine the abnormal semantic generation stage. This avoids misjudging the anomaly generation location as the result output location based solely on the judgment result of the failure result formation stage.

[0057] To reduce the impact of a single removal order on the localization results, responsibility shrinkage processing is repeatedly performed according to the source code location order, similarity from high to low, call chain order, and data dependency order. The semantic breakpoints of the same candidate code segment under different preset removal orders are recorded. If the semantic breakpoints of the same candidate code segment are all located in the abnormal semantic generation stage under multiple preset removal orders, it indicates that the relationship between the code segment and abnormal semantic generation is stable, increasing its localization priority as a defect localization result. If the semantic breakpoints of the same candidate code segment change with the preset removal order, it indicates that the code segment's impact on failure explanation is affected by the combination relationship with other candidate code segments, reducing its localization priority.

[0058] When determining the location priority, the overall location priority of candidate code snippets can be calculated using the following formula:

[0059]

[0060] in, Indicates the first The priority of locating candidate code snippets Indicates the first The degree of matching between each candidate code snippet and the failure semantic vector. Indicates the first The stability of semantic breakpoints among candidate code snippets under multiple preset removal orders. Indicates the first The semantic breakpoint of each candidate code segment is set to 1 if it is located in the abnormal semantic generation stage, and 0 otherwise. , and These represent the weights for matching degree, stability degree, and abnormal semantic generation stage, respectively.

[0061] Specifically, the matching degree of C27 The stability is 0.81. 1, stage marker =1, It is 0.5. It is 0.3. The value is 0.2. Substituting the above data, we get:

[0062]

[0063] C51 matching degree The stability is 0.69. The value is 0.5, and the stage marker is... The value is 0. Substituting the above data, we get:

[0064]

[0065] Figure 4The results of combining C27 and C51 in terms of matching degree, stability, and anomaly stage are presented. C27 not only has a high semantic matching degree but also maintains semantic breakpoint stability under multiple preset removal orders. Furthermore, its semantic breakpoint is located in the anomaly semantic generation stage, thus achieving a comprehensive localization priority of 0.905, higher than the priority output reference line of 0.80. Although C51 has a certain matching relationship with the failure semantic vector, its semantic breakpoint is not located in the anomaly semantic generation stage, and its stability is low, resulting in a comprehensive localization priority of 0.495. Therefore, C27 has a higher localization priority than C51, and C27 is prioritized as the defect localization result for output.

[0066] After determining the semantic breakpoints, it is further determined whether the retained candidate code segments cause a stage shift in the semantic breakpoints of other candidate code segments. Specifically, if the semantic breakpoint of C34 moves from the failure result formation stage to the abnormal semantic generation stage, or from the abnormal semantic generation stage to the failure input entry stage, then C27, which caused the above movement, is identified as an abnormal propagation segment. An abnormal propagation segment indicates that the code segment may participate in the propagation of abnormal semantics between code segments, but it is not necessarily the initial position of abnormal semantic generation. For abnormal propagation segments, their positioning priority is set to be lower than the initial defective code segment corresponding to the abnormal semantic generation stage, so that the final positioning result preferentially points to the code segment closer to the source of the defect.

[0067] Through the above processing, in the scenario of failure of Company A's date parsing service, it is possible to shrink from 86 code snippets to obtain the remaining code snippets that have the necessary semantic association with the failure result, and combine them with... Figure 2 The candidate code snippet similarity filtering results are shown. Figure 3 The results of the responsibility contraction semantic breakpoint determination shown are as follows: Figure 4 The comprehensive location priority comparison results shown determine the defect location order of candidate code segments. Finally, the code segments whose semantic breakpoints are stably in the abnormal semantic generation stage and have a higher comprehensive location priority are identified as the main defect location results, and basic information for subsequent repair recommendations is generated based on the abnormal semantic features corresponding to the code segments.

[0068] Example 2:

[0069] In one embodiment, the software to be tested by Company A is the OrderValidator module, which is used to validate the quantity of goods in an order, the inventory limit, and the exception return logic. The source code, failure runtime information, pass runtime information, and preset failure explanation conditions of the order validation module are obtained. Failure runtime information includes the failed test case `testNegativeQuantity`, the failed input, the failure log `IllegalArgumentException: quantityrange error`, and the failed return result. Pass runtime information includes the passed test case `testQuantityWithinRange`, the normal input, and the normal return result `validation passed`. Preset failure explanation conditions include the vector matching thresholds corresponding to the failure input entry stage, the exception semantic generation stage, and the failure result formation stage, as well as the stage order relationship between these stages.

[0070] After determining the defect location, the code snippets retained for the responsibility contraction process include C18, C22, and C39. C18 corresponds to the order quantity reading logic, C22 corresponds to the conditional judgment `quantity <= maxLimit`, and C39 corresponds to the exception return generation logic. A failure semantic vector is generated based on the failure execution information, and a success semantic vector is generated based on the success execution information. Both failure and success execution information are processed using the same semantic feature extraction method, placing them in the same semantic representation space. Semantic features include the input value range, conditional judgment relationships, exception triggering paths, return result content, log fields, and call stack propagation relationships.

[0071] For code segments retained after responsibility contraction, it is determined whether they are necessary to maintain the execution result under both the failure semantic vector and the pass semantic vector. If a code segment participates in maintaining the failure result in the failure execution scenario and also participates in maintaining the normal result in the pass execution scenario, it is further determined whether the semantic difference corresponding to the code segment has been propagated to the failure result formation stage. The propagation of semantic differences can be manifested by the triggering of an exception branch, the generation of an exception return, the writing of log fields, or the modification of test assertion results.

[0072] When determining semantic differences, the semantic difference between the i-th code snippet and the successful execution scenario is calculated using the following formula:

[0073]

[0074] in, Indicates the first Semantic differences between code snippets Indicates the first The matching values ​​of each code snippet and the failure semantic vector. Indicates the first Each code snippet is matched with a semantic vector. The larger the difference between the two, the more significant the semantic state difference between the code snippet's failed execution and its normal execution. Absolute values ​​are used to ensure a consistent difference result regardless of whether the failed match value is higher than the passed match value or vice versa.

[0075] Specifically, the matching value of C22 under the failure semantic vector The value is 0.73, based on the matching value under the semantic vector. The value is 0.70. Substituting the above data, we get:

[0076]

[0077] Therefore, although C22 participates in the formation of the execution result, its semantic difference between failed and successful executions is small. The matching value of C39 under the failure semantic vector... The value is 0.84, based on the matching value under the semantic vector. The value is 0.41. Substituting the above data, we get:

[0078]

[0079] Therefore, it can be seen that there is a clear semantic difference between C39 running in failure mode and running successfully mode. Figure 5 The failed match values, passed match values, and semantic differences for C22 and C39 are displayed in the same comparison relation, with a difference judgment threshold of 0.20. Figure 5 It can be seen that the semantic difference of C22 is only 0.03, which is lower than the difference judgment threshold, indicating that it is more likely to belong to the general judgment logic that needs to be passed in both normal and failed operations; the semantic difference of C39 is 0.43, which is higher than the difference judgment threshold, indicating that it has more prominent abnormal return semantics in the failed operation scenario. If we further judge that the abnormal return generation logic of C39 can... If the corresponding abnormal state is passed to the failure result formation stage, then C39 will be retained as a code segment directly related to the failure result. For C22, if its semantic difference is not passed to the failure result formation stage through the abnormal semantic generation stage, then its positioning priority will be reduced according to the preset downgrade conditions, or it will be excluded from the main defect positioning results according to the preset exclusion conditions.

[0080] When generating repair recommendations, candidate repair directions are formed based on semantic changes that invalidate the preset failure explanation conditions. Candidate repair directions include M1, M2, and M3, where M1 adds a branch handling for values ​​less than zero in the quantity lower limit judgment, M2 simultaneously adjusts the quantity lower limit judgment, the exception return text, and the log field, and M3 only modifies the exception return text. For each candidate repair direction, it is first mapped to the changes made to the code semantic vector, and then it is determined whether the modified code semantic vector set can still explain the failure input entry stage, the exception semantic generation stage, and the failure result formation stage.

[0081] For M1, After entering the order verification module, the newly added quantity lower limit judgment can intercept illegal quantities before abnormal semantics are generated, preventing the original abnormal return generation logic from forming the same semantic interpretation chain as the failure log. For M2, it can also disrupt the failure interpretation chain, but by simultaneously changing the abnormal return text and log fields, it may affect the interpretation results of existing logs in the running scenario. For M3, it only modifies the abnormal return text and cannot block the error. It corresponds to the generation and transmission of abnormal states, and therefore has a weak effect on explaining the failure chain. Figure 6 Using the disruption of the failure explanation chain, the maintenance of the explanation outcome, and the risk of failure migration as three verification indicators, M1, M2, and M3 are presented in a matrix format. Figure 6 It can be seen that M1 achieves 0.92 and 0.88 in the indicators of disrupting the failure explanation chain and maintaining the pass explanation result, respectively, while the failure migration risk is 0.10, indicating that it can meet the requirements of failure elimination and normal maintenance with a relatively small migration risk. Although M2 has a failure explanation chain disruption indicator of 0.95, the pass explanation result maintenance indicator is only 0.60 and the failure migration risk is 0.35. M3 has a pass explanation result maintenance indicator of 0.95, but the failure explanation chain disruption indicator is only 0.30, so it cannot be used as a priority repair direction.

[0082] When multiple candidate repair directions involve the same abnormal semantic features, the inclusion relationship between the candidate semantic change directions is further compared. If the first candidate semantic change direction can make the preset failure explanation condition not true, and the code semantic vector content changed by the second candidate semantic change direction includes the code semantic vector content changed by the first candidate semantic change direction, then it indicates that the first candidate semantic change direction has a more concentrated modification range. In this embodiment, M1 changes the semantic feature corresponding to the quantity lower limit judgment, and M2 simultaneously changes the semantic features corresponding to the quantity lower limit judgment, the exception return text, and the log field. The semantic vector content changed by M2 includes the semantic vector content changed by M1. Therefore, when M1 can make the preset failure explanation condition not true, M1 is preferentially selected as the semantic change direction for generating repair recommendations.

[0083] After applying candidate repair directions, a new set of semantic vectors for the repaired code is generated, and responsibility shrinking is performed again. If the set of semantic vectors for the repaired code no longer meets the preset failure explanation conditions, and the original explanation result is maintained through the semantic vectors corresponding to the runtime information, then the corresponding repair recommendation is allowed to be output. If the original explanation result cannot be maintained through the semantic vectors after repair, it indicates that the repair direction may disrupt the normal operation path, and its output priority is reduced. If the retained code fragments obtained from the second responsibility shrinking process change, it is further determined whether the changed retained code fragments still have a semantic relationship with the failure result.

[0084] When determining the output order of candidate repair directions, the output score of the m-th candidate repair direction is calculated according to the following formula:

[0085]

[0086] in, Indicates the first Output scores for each candidate repair direction Indicates the first The ability of each candidate repair direction to disrupt the explanation chain of failures Indicates the first Each candidate repair direction retains the ability to interpret the results. Indicates the first Each candidate repair direction carries the risk of failed migration. , and These represent the preset weights corresponding to the ability to disrupt the failure explanation chain, maintain the normal explanation capability, and the risk of failure migration, respectively. and The larger the value, the more suitable the candidate repair direction is for output. A higher value indicates that the candidate fix is ​​more likely to transfer the failure to other code segments, and therefore a deduction is made in the score.

[0087] Specifically, M1 It is 0.92. It is 0.88. It is 0.10. It is 0.45. It is 0.40. The value is 0.15. Substituting the above data, we get:

[0088]

[0089] M2 It is 0.95. It is 0.60. The value is 0.35. Substituting the above data, we get:

[0090]

[0091] M3 It is 0.30. It is 0.95. The value is 0.20. Substituting the above data, we get:

[0092]

[0093] Based on the above scoring results, the output score of M1 is higher than that of M2 and M3, and it is given priority as the recommended output for repair. Figure 7 The recommended output scores for repairs M1, M2, and M3 are further presented, with an output reference line set at 0.70. (By...) Figure 7 It can be seen that the output score of M1 is 0.751, which is higher than the output reference line and meets the priority output condition; the output score of M2 is 0.615, which is lower than the output reference line, mainly because its modification range is larger and its ability to retain the results of the run interpretation is lower; the output score of M3 is 0.485, which is lower than the output reference line, mainly because it cannot effectively break the failure interpretation chain. Therefore, M1 is prioritized as the recommended output for repair, M2 has a reduced output priority, and M3 is not prioritized for output.

[0094] If the retained code fragment obtained after applying the repair recommendation and then performing the responsibility contraction process changes from C39 to another code fragment, the semantic association source before and after applying the repair recommendation is further compared. The semantic association source is determined based on the matching value between the retained code fragment and the failure semantic vector, the stage matching result, and the anomaly propagation relationship. When the semantic association source shifts from C39 to the changed retained code fragment, and the explanation stage of the failure result does not move from the failure result formation stage to the anomaly semantic generation stage or the failure input entry stage, it indicates that the repair recommendation has not converged the failure cause to an earlier stage, but rather migrated the failure manifestation to other code fragments. This repair recommendation is judged as a failure migration-type repair, and the output is canceled.

[0095] The above method enables the OrderValidator module to combine failure runtime information with the runtime information to distinguish between the code snippets required for normal operation and the code snippets that directly lead to failure. Figure 5 The semantic difference comparison results shown Figure 6 The candidate repair direction index verification results shown and Figure 7 The comparison results of the repair recommendation output scores shown determine the order of the repair recommendation outputs, so that the final output repair recommendation can both disrupt the failed explanation chain and maintain the normal operation explanation result.

Claims

1. A software defect location and repair recommendation method based on code semantic vectors, characterized in that, include: The source code, failure runtime information, and preset failure explanation conditions of the software to be tested are obtained. The preset failure explanation conditions include vector matching thresholds and stage order relationships corresponding to the failure input entry stage, the abnormal semantic generation stage, and the failure result formation stage. The failure input entry stage is determined based on semantic features corresponding to failure input, entry function, input parameters, or call entry. The abnormal semantic generation stage is determined based on semantic features corresponding to abnormal states, error conditions, boundary value processing, or abnormal branches. The failure result formation stage is determined based on semantic features corresponding to abnormal output, error return, log error, or test assertion failure. The source code is divided into multiple code segments, and code semantic vectors are generated for each code segment. Failure semantic vectors are also generated based on the failure execution information. Based on the similarity threshold between the failure semantic vectors and each code semantic vector, a set of candidate code segments that are semantically related to the failure result is determined. The responsibility shrinking process is performed on the candidate code segment set according to a preset removal order. The responsibility shrinking process includes: temporarily removing the code semantic vector corresponding to a candidate code segment; determining whether the remaining multiple code semantic vectors meet the preset failure explanation conditions; deleting the candidate code segment if they meet the conditions, and retaining the candidate code segment if they do not meet the conditions, until the remaining multiple candidate code segments do not meet the deletion conditions; determining the retained code segments as defect localization results, and generating repair recommendations based on the code semantic vectors of the retained code segments.

2. The method according to claim 1, characterized in that, The preset failure interpretation conditions are judged according to the failure input entry stage, the abnormal semantic generation stage, and the failure result formation stage. After temporarily removing a candidate code segment, the stage in which the vector matching threshold cannot be met by the remaining multiple code semantic vectors for the first time is recorded as the semantic breakpoint of the candidate code segment. The positioning priority of the candidate code segment whose semantic breakpoint is located in the abnormal semantic generation stage is set to be higher than that of the candidate code segment whose semantic breakpoint is located in the failure input entry stage or the failure result formation stage.

3. The method according to claim 1, characterized in that, When performing the responsibility contraction process, the pass operation information is obtained and a pass semantic vector is generated; if the retained candidate code segment is necessary to maintain the operation result under both the failure semantic vector and the pass semantic vector, and the semantic difference corresponding to the candidate code segment is not transmitted to the failure result, then the candidate code segment is excluded from the defect location result according to the preset exclusion conditions, or the location priority of the candidate code segment is reduced according to the preset downgrade conditions.

4. The method according to claim 1, characterized in that, The repair recommendation is generated based on the semantic change direction that makes the preset failure explanation condition not true. After applying the repair recommendation, the responsibility contraction process is performed again. If the set of code semantic vectors after applying the repair recommendation does not meet the preset failure explanation condition, and the original explanation result is maintained by the semantic vectors corresponding to the running information, then the repair recommendation is output.

5. The method according to claim 2, characterized in that, The semantic breakpoints are determined using a reverse verification method. When the failure result formation stage cannot be interpreted after temporarily removing a candidate code segment, it is further determined whether the abnormal semantic generation stage can still be interpreted. If it can be interpreted, the semantic breakpoint is determined as the failure result formation stage. If it cannot be interpreted, the semantic breakpoint is backtracked to determine the abnormal semantic generation stage.

6. The method according to claim 2, characterized in that, The responsibility shrinking process is repeatedly executed according to multiple preset removal orders; if the semantic breakpoints of the same candidate code segment belong to the same stage under multiple preset removal orders, the positioning priority of the candidate code segment as a defect location result is increased; if the stage to which the semantic breakpoint belongs changes with the preset removal order, the positioning priority of the candidate code segment is decreased.

7. The method according to claim 2, characterized in that, After determining the semantic breakpoint, it is determined whether the retained candidate code segment causes the semantic breakpoint of other candidate code segments to move from the failure result formation stage to the abnormal semantic generation stage, or from the abnormal semantic generation stage to the failure input entry stage. If a phase shift occurs, the candidate code segment that caused the phase shift is identified as an exception propagation segment, and the positioning priority of the exception propagation segment is set to be lower than that of the candidate code segment corresponding to the exception semantic generation phase.

8. The method according to claim 4, characterized in that, The semantic change direction is determined by the inclusion relationship between candidate semantic change directions. When the first candidate semantic change direction can make the preset failure explanation condition not true, and the code semantic vector content changed by the second candidate semantic change direction contains the code semantic vector content changed by the first candidate semantic change direction, the first candidate semantic change direction is determined as the semantic change direction for generating repair recommendations.

9. The method according to claim 4, characterized in that, After applying the repair recommendation, if the retained code fragment obtained by performing the responsibility shrinking process again changes, it is determined whether the changed retained code fragment still has a semantic association with the failure result; if there is still a semantic association, the output priority of the repair recommendation is reduced. If there is no semantic association, and the original interpretation result is maintained through the semantic vector corresponding to the running information, then the output priority of the repair recommendation is increased.

10. The method according to claim 9, characterized in that, If the modified retained code fragment still has a semantic association with the failure result, the source of semantic association before and after applying the repair recommendation is compared; when the source of semantic association is transferred from the original retained code fragment to the modified retained code fragment, and the explanation stage of the failure result is not moved from the failure result formation stage to the abnormal semantic generation stage or the failure input entry stage, the repair recommendation is determined to be a failure migration type repair, and the output of the repair recommendation is canceled.

Images