A program mutation fault locating method and system based on a revised test matrix

Abstract

The application discloses a program mutation fault positioning method and system based on a modified test matrix, and comprises the following steps: processing a source program to be tested by a method combining symbolic execution, shared variable tracking and hypothesis reasoning, finding out code lines for generating mutations by identifying key paths, shared variables and potential fault interaction points in the code; understanding the context of the source code based on a large language model, generating complex mutants for the selected code lines, and running the mutated programs to obtain a kill information matrix; for different mutation types, modifying the probability by a Bayesian method, modifying the test matrix according to the probability, and reducing the noise in the test matrix; and calculating the suspicious degree according to the modified test matrix, and generating a suspicious code list. The method can reduce unnecessary mutation operations, improve test coverage, and improve the accuracy of fault positioning.

Description

TECHNICAL FIELD

[0001] The application relates to a program mutation fault locating method and belongs to the technical field of software testing. BACKGROUND

[0002] With the increasing scale and complexity of software systems, software plays an increasingly important role in various industries. However, faults in software still frequently occur, which can lead to system crashes, function failures, and even serious safety problems. In order to ensure software quality, fault locating is a crucial step in the software development and maintenance process.

[0003] Traditional fault locating methods mainly rely on the experience of developers and manual debugging, which is time-consuming and labor-intensive, and is easily affected by subjective factors. In order to improve the efficiency and accuracy of fault locating, various automatic fault locating techniques have been proposed in academia and industry. Mutation-based fault locating is a commonly used method. When there are multiple faults in software, the faults may interact with each other, resulting in inaccurate suspiciousness calculation results and reducing the effectiveness of fault locating. Program mutation testing generates mutants by introducing small modifications (i.e., mutations) into the source code to evaluate the effectiveness of test cases and locate potential faults. However, traditional mutation testing methods apply various possible mutations to each code line in the program, resulting in a large number of mutants, which leads to high computational cost and time overhead, making it difficult to apply in practical projects. In addition, in a multi-fault environment, the behavior of mutants may be affected by multiple faults, resulting in a large amount of noise in the test results and the kill information matrix, which affects the accuracy of fault locating.

[0004] In recent years, in order to address the challenges of fault locating in a multi-fault environment, various improved methods have been proposed, such as machine learning-based fault locating and statistical analysis-based methods. However, these methods still have problems such as complex models, large training data requirements, and insufficient generalization ability. SUMMARY

[0005] The technical problem to be solved by the present application is how to improve the accuracy of fault locating in a multi-fault environment.

[0006] To solve the above technical problems, the present application provides a program mutation fault locating method based on a revised test matrix, comprising the following steps:

[0007] Step 1, identify the code lines in the program that are in the critical path, have shared variables, and contain potential fault interaction points, and select the code lines that meet two of the above three conditions as the candidate code lines for generating mutations;

[0008] Step 2, use a large language model to understand the source code context, generate complex mutants using the candidate code lines found in step 1, input test cases, run the mutated program to get the kill information matrix, and run the source program to get the test result vector;

[0009] Step 3, set the prior probability for different types of mutants, test result vectors, and kill information matrices, respectively, and use the Bayesian method to correct the prior probability in the dataset to obtain the modified probability, and use the modified probability to modify the failed tests and kill information in the test matrix; the dataset refers to a publicly available vulnerability dataset;

[0010] Step 4, calculate the suspicious degree according to the modified test matrix, generate a suspicious code list as the final identified fault.

[0011] The foregoing program mutation fault positioning method based on the modified test matrix, in step 1, the step of identifying the code lines in the critical path of the program includes:

[0012] Use a symbolic execution tool to perform symbolic execution on the source program to generate all possible execution paths of the program;

[0013] During symbolic execution, record the path condition, branch information and symbolic input of each path;

[0014] Use a code coverage analysis tool to generate path coverage information, and combine the condition frequency and path coverage information to identify the path that has the greatest impact on the overall behavior of the program, mark it as a critical path, and form a critical path code line set .

[0015] The foregoing program mutation fault positioning method based on the modified test matrix, in step 1, the step of identifying the code lines with shared variables includes: the step of identifying the code lines in the critical path of the program includes: using a static analysis tool to track shared variables, obtaining the definition-use chain of all variables in the program, finding global variables, static variables and parameters passed between multiple functions, tracking the definition and use relationship of the variables, identifying the propagation path of the variables between different code lines, in a multi-threaded program, identifying variables that can be accessed by multiple threads, marking code lines involving shared variables, and forming a shared variable code line set .

[0016] The program mutation fault locating method based on the modified test matrix in the preceding, in step 1, the step of identifying the code line containing the potential fault interaction point comprises: representing the constraint relationship of the path condition and the shared variable as a set of logical formulas, using a logical reasoning tool to solve the logical formulas, and finding solutions that meet certain conditions, such as multiple faults being triggered under the same condition; according to the solving result, finding out the code line that may cause multiple fault interactions under a certain path condition, marking the code line containing the potential fault interaction point, and forming a fault interaction point code line set .

[0017] The program mutation fault locating method based on the modified test matrix in the preceding, the path condition comprises a branch condition and a loop condition; and the logical reasoning tool adopts Z3.

[0018] The program mutation fault locating method based on the modified test matrix in the preceding, in step 2, comprises the following steps:

[0019] Step 21, using a large language model (LLM) to understand the context of the source code, and generating a complex mutant for each code line to be mutated , inputting the context code segment into the LLM, and instructing the LLM to perform operator variable mutation and code insertion and deletion mutation on the input source program;

[0020] Step 22, after generating the mutant, first test the source program using the test set, save the pass and fail conditions of the source program, obtain the test result vector, and then test each mutant using the test case set, if the running result of the mutant is different from that of the source program, the mutant is defined as killed, record whether the running of all mutants produces killed information, and obtain the killed information matrix.

[0021] The program mutation fault locating method based on the modified test matrix in the preceding, in step 3, the modification probability of the test matrix comprises:

[0022] Step 31, setting the prior probability of the test result matrix , representing the initial probability of modifying the failed test to the passed test, and the proportion of the passed test as a conditional probability, used to measure the relative proportion of the passed test and the total test under the current test set;

[0023] = ,

[0024] the number of passed test cases, the total number of test cases;

[0025] ​Step 32, update the probability of failure test being mislabeled as pass test using Bayes' theorem: Let L be the likelihood function, which represents the probability of failure test being mislabeled as pass test, calculated as the product of the probability of failure test not killing and the probability of pass test killing

[0026] ,

[0027] Let p be the proportion of failure test, equal to 1- , where n is the number of code lines killed by pass test cases, where n is the number of code lines not killed by failure test cases, and n is the number of code lines to be mutated, is the number of failure test cases.

[0028] Step 33, update the probability of failure test being mislabeled as pass test using Bayes' theorem:

[0029] ,

[0030] According to the updated probability of failure test being mislabeled as pass test correct the test result vector;

[0031] Step 34, for each failure test case, generate a random number r∈[0,1], if r< , mark it as pass test, and get the modified test result vector;

[0032] Step 35, divide the kill information matrix into different mutation types, divide the mutants into m batches according to the type, and perform iterative calculation on each batch; set the initial prior probability of kill information , Let p be the initial probability of kill information needing to be corrected for operator variable modification type mutation, Let p be the initial probability of kill information needing to be corrected for insertion deletion type mutation.

[0033] Step 36, calculate the likelihood function , which represents the proportion of failure test in all kill information;

[0034] , ;

[0035] , respectively represent the operator variable modification type likelihood function and the insertion deletion type likelihood function.

[0036] ​​​Step 37, using Bayes' theorem, update the modification probability, which includes the probability of modifying a failed test's kill information to not-kill respectively for operator variable modification type mutation, insertion deletion type mutation , , is expressed as:

[0037] ,

[0038] ,

[0039] The updated instead of , the updated instead of , as the prior probability of the next batch, return to step 35 to recalculate until a predetermined number of iterations is reached;

[0040] Step 38, according to the final modification probability, use the method in step 34 to correct the kill information matrix.

[0041] The aforementioned program mutation fault location method based on the corrected test matrix, in step 4, comprises the following steps:

[0042] Step 41, count the information in the test result vector and the kill information matrix: denotes the number of times the code line is killed by the passing test case, denotes the number of times the code line is killed by the failed test case, denotes the number of times the code line is not killed by the passing test case, denotes the number of times the code line is not killed by the failed test case;

[0043] The suspicion of is calculated using the Ochiai formula: ( )= ;

[0044] Sort the code lines according to the suspicion from high to low to generate a suspicious code list.

[0045] A computer device / apparatus / system comprising a memory, a processor and a computer program stored on the memory, the processor executing the computer program to implement the steps of the above method.

[0046] A computer readable storage medium having a computer program / instruction stored thereon, characterized in that the computer program / instruction is executed by a processor to implement the steps of the above method.

[0047] The beneficial effects achieved by this invention are as follows: The method of this invention accurately identifies the key lines of code to be mutated by combining symbolic execution, shared variable tracking and logical reasoning; it generates complex mutants using a large language model to simulate real fault scenarios; it introduces a Bayesian method to correct the test matrix and reduce the interference of multiple faults on the test results; and finally, it generates a list of suspicious codes by calculating the degree of suspicion, thereby improving the accuracy and efficiency of fault location. Attached Figure Description

[0048] Figure 1 This is a flowchart of the program mutation fault location method based on the modified test matrix in Embodiment 1 of the present invention. Detailed Implementation

[0049] The invention will be further described in detail below with reference to specific embodiments.

[0050] Example 1

[0051] like Figure 1 As shown, this embodiment provides a method for locating program mutation faults based on a modified test matrix, including the following steps:

[0052] Step 1: Identify the lines of code in the program that are on the critical path, have shared variables, and contain potential failure interaction points. Select the lines of code that meet two of the above three conditions as candidate lines of code for generating mutations.

[0053] Step 2: Use a large language model to understand the source code context, generate complex mutants using the candidate code lines found in Step 1, input test cases, run the mutated program to obtain the kill information matrix, and run the source program to obtain the test result vector.

[0054] Step 3: Set prior probabilities for different types of mutants, test result vectors, and kill information matrices. Use Bayesian methods to correct the prior probabilities in the dataset to obtain the modification probabilities. Use the modification probabilities to modify the failed tests and kill information in the test matrix. The dataset refers to a publicly available vulnerability dataset, such as defect4j.

[0055] Step 4: Calculate the suspicion level based on the modified test matrix and generate a list of suspicious codes as the final identified faults.

[0056] In step 1, the process of obtaining the candidate lines of code includes the following steps:

[0057] Step 11: Perform symbolic execution on the source program using a symbolic execution tool to generate all possible execution paths of the program. The symbolic execution tool used is KLEE.

[0058] During symbolic execution, path conditions, branch information and symbolic inputs of each path are recorded;

[0059] In order to screen out the path controlling the main logic flow, the path coverage information is generated by using a code coverage analysis tool (such as llvm-cov), and the condition frequency and path coverage information are combined to identify the path having the greatest influence on the overall behavior of the program, which is marked as a critical path to form a critical path code line set ;

[0060] Step 12, shared variable tracking is performed using a static analysis tool to obtain the definition-use chain of all variables in the program, find global variables, static variables and parameters passed between multiple functions, track the definition and use relationship of the variables, identify the propagation path of the variables between different code lines, and in a multi-threaded program, identify variables that can be accessed by multiple threads, mark the code lines related to the shared variables to form a shared variable code line set ; the static analysis tool uses Frama-C;

[0061] Step 13, the constraint relationship of the path condition and the shared variable is expressed as a set of logical formulas, and a logical reasoning tool is used to solve the logical formulas to find solutions that meet certain conditions, such as multiple faults being triggered under the same condition; according to the solving result, the code lines that can cause multiple faults to interact under certain path conditions are found, and the code lines containing potential fault interaction points are marked to form a fault interaction point code line set ; the path condition includes branch conditions and loop conditions; the logical reasoning tool uses Z3;

[0062] Step 14, for each code line , if it exists in at least two of the above three code line sets at the same time, it is added to the code line set to be mutated , obtaining the code line to be mutated, ensuring that the mutant set is concentrated in the critical area that can trigger multiple faults. Through the method of step 1, unnecessary mutation operations can be reduced.

[0063] In step 2, the following steps are included:

[0064] Step 21, using a large language model (LLM) to understand the context of the source code, generating complex mutants for the code lines to be mutated found in step 1 , for each code line to be mutated , the context code segment where it is located is input into the LLM, instructing the LLM to perform operator variable mutation and code insertion and deletion mutation on the input source program;

[0065] Step 22, after generating the mutants, first test the original program with the test set, save the pass and fail of the original program, get the test result vector, then test each mutant with the test case set, if the mutant running result is different from the original program, it is defined as killed, record all mutant running whether to produce killed information, get the killed information matrix. The complex mutant generated by the large language model can find more potential faults and improve the test coverage.

[0066] In step 3, the modification probability of the test matrix is obtained, including:

[0067] Step 31, set the prior probability of the test result matrix , which represents the initial probability of modifying the failed test to the passed test, and the proportion of the passed test as the conditional probability, which is used to measure the relative proportion of the passed test and the total test under the current test set;

[0068] , is the number of passed test cases, is the total number of test cases;

[0069] Step 32, take as the likelihood function, which represents the probability of mislabeling the failed test as the passed test, since there is no direct method to represent it, we multiply the failed test non-killed probability and the passed test killed probability to get , which represents the proportion of failed tests, equal to 1- , where represents the number of times the code line is killed by the passed test case, represents the number of times the code line is not killed by the failed test case, n is the number of code lines to be mutated, is the number of failed test cases;

[0070] Step 33, use Bayes' theorem to update the probability of modifying the failed test to the passed test:

[0071] ,

[0072] According to the updated probability of modifying the failed test to the passed test , correct the test result vector;

[0073] Step 34, for each failed test case, generate a random number r∈[0,1], if r< , mark it as a passed test, and get the modified test result vector;​

[0074] Step 35, divide the kill information matrix into different mutation types, divide the mutants into m batches according to the types, and perform iterative calculation on each batch; set the initial prior probability of the kill information , that is, the initial possibility that the kill information needs to be corrected before the test results are observed, which needs to be distinguished according to the mutation type, represents the initial possibility that the kill information of the operator variable modification type mutation needs to be corrected, represents the initial possibility that the kill information of the insertion deletion type mutation needs to be corrected;

[0075] Step 36, calculate the likelihood function , which represents the proportion of failed tests in all kill information;

[0076] It can be directly counted from the data set, but different mutation types need to be distinguished, which can be divided into two types:

[0077] , ;

[0078] , respectively represent the likelihood function of the operator variable modification type and the insertion deletion type;

[0079] Step 37, update the modification probability using the Bayes theorem, which includes the probability of modifying the kill information of the failed test to non-kill for the operator variable modification type mutation and the insertion deletion type mutation respectively 、 , which is represented as:

[0080] ,

[0081] ,

[0082] Replace with the updated , Replace with the updated , as the prior probability of the next batch, return to step 35 to recalculate until the predetermined number of iterations is reached;

[0083] Step 38, according to the final modification probability, use the method in step 34 to correct the kill information matrix.

[0084] By using the Bayes method to correct the test matrix, the interference of multiple faults on the test results is reduced, thereby improving the accuracy of fault location.

[0085] In step 4, the suspicious degree of code lines is calculated to obtain a suspicious code list, including the following steps:

[0086] Step 41, statistics test result vector and information in the kill information matrix: representing the number of times that the code line is killed by the passed test cases, representing the number of times that the code line is killed by the failed test cases, representing the number of times that the code line is not killed by the passed test cases, representing the number of times that the code line is not killed by the failed test cases.

[0087] The suspicious degree of is calculated using the Ochiai formula: ( ) = ;

[0088] The higher the suspicious degree, the more likely the code line contains a fault, and the code lines are sorted according to the suspicious degree from high to low to generate a suspicious code list.

[0089] Suppose there is a simple calculator program that provides basic arithmetic functions, including addition, subtraction, multiplication and division, and the source code is shown in Table 1:

[0090] Table 1 Source code of calculator program

[0091]

[0092] This code has two faults: the for loop condition is wrong, i <= size should be changed to i < size, otherwise arr[size] will be accessed when i == size, causing array out of bounds; arr[0] will be accessed out of bounds when size <= 0, and there is no check for array size.

[0093] Using a program mutation fault location method based on a modified test matrix of the application, the following steps are performed:

[0094] Step 1, identify the code lines in the critical path, the code lines with shared variables and the code lines containing potential fault interaction points in the program, the code lines meeting two of the above three conditions will be selected as candidate code lines for mutation, the specific steps are as follows:

[0095] Step 11, use the symbolic execution tool KLEE to perform symbolic execution on the source program, generate all possible execution paths, and record the path conditions and symbolic inputs;

[0096] Path 1: size > 0, normal enter loop;

[0097] Path 2: size <= 0, out-of-bounds access at arr[0];

[0098] Path 3: i == size, access arr[size], out-of-bounds;

[0099] Generate path coverage information using llvm-cov, identify paths that control the main logic flow, where line 4 initializes the maximum value, is always executed, is important, line 5 controls the number of loops, affects the range of array access, line 6 compares and updates the maximum value, so Key path code behaviors: 4, 5, 6;

[0100] Step 12, use Frama-C to track shared variables, get the definition-use chain of variables, where the shared variables are: arr[], size, max, i;

[0101] In this program, arr[] and size are parameters passed to the find_max function, max and i are local variables within the function, and variables arr[] and i are used multiple times in the loop body, involving array access, which may cause out-of-bounds problems, so Shared variable code behaviors: 4, 5, 6;

[0102] Step 13, represent the constraint relationship between path conditions and shared variables as a logical formula, when size <= 0, arr[0] is out-of-bounds, formula 1 is: size <= 0⟹Access(arr[0]), formula 2 is: i = size⟹Access(arr[size]), input the above constraints to Z3, find solutions that satisfy the conditions, when size <= 0, arr[0] is out-of-bounds, involves line 4, when i = size, arr[size] is out-of-bounds, involves line 6; Line 4 and line 6 may cause array out-of-bounds under certain conditions, which are fault interaction points, so Fault interaction points code behaviors: 4, 6;

[0103] Step 14, for each code line , determine whether it exists in at least two of the above sets at the same time, where line 4, 5, 6 meet the requirements, so Mutated code behaviors: 4, 5, 6.

[0104] Step 2, use a large language model to understand the source code context, generate complex mutants using the candidate code lines found in step 1, input test cases, run the mutated program to get the kill information matrix, run the source program to get the test result vector, the specific steps are as follows:

[0105] Step 21, input each code line to be mutated and its context into LLM, generate complex mutants for the candidate code lines found in step 1, simulate abnormal behavior in a multi-fault environment, one mutation for line number 4: change int max = arr[0] to int max = 0, this mutation means deleting the initial assignment to the array, the rest of the mutations are similar and will not be repeated.

[0106] Step 22, run the mutant and the source program to get the test result vector and the kill information matrix;

[0107] One of the test cases is: data = {3, 5, 2, 8, 6}; size1 = 5; expected output 8, the rest of the test cases are similar, the test result vector obtained by running the source program is shown in Table 2:

[0108] Table 2 Test result vector table

[0109]

[0110] Where 0 means fail, 1 means pass, the kill information matrix obtained by running the mutant is shown in Table 3:

[0111] Table 3 Kill information matrix

[0112]

[0113] Where 0 means not killed, 1 means killed.

[0114] Step 3, set the prior probability for different types of mutants, test result vectors, and kill information matrices, and modify the prior probability to get the modified probability through the Bayesian method, in order to demonstrate more intuitively, assume that the above test is a sample in the dataset, use the modified probability to modify the failed tests and kill information in the test matrix; The specific steps are as follows:

[0115] Step 31, according to experience, set the prior probability of the test result matrix In this test is 1, is 5, calculate the proportion of passing tests =0.2 as a conditional probability to measure the relative proportion of passing tests and total tests under the current test set;

[0116] Step 32, As the likelihood function, represents the probability of a failed test being mislabeled as a passed test, which is obtained by multiplying the probability of a failed test not killing and the probability of a passed test killing since there is no direct way to represent it , represents the proportion of failed tests, which is equal to 1- , where, represents the number of times a code line is killed by passed test cases, here 1, represents the number of times a code line is not killed by failed test cases, here 8, n is the number of code lines to be mutated, n = 3, is the number of failed test cases, ;

[0117] Step 33, using Bayes' theorem, update the probability of a failed test being modified to a passed test: , according to the updated , the test result vector is corrected.

[0118] Step 34, for each failed test case, generate a random number r∈[0,1], if r< , mark it as a passed test, get the modified test result vector, since the probability obtained this time is very small, do not modify the test result vector;

[0119] Step 35, for the kill information matrix, different mutation types need to be distinguished;

[0120] The mutants are divided into m batches according to the type, and the iterative calculation is carried out on each batch, and the initial prior probability of the kill information is set , that is, before the test result is observed, it is considered that the initial possibility of the kill information needs to be modified, here the mutation type needs to be distinguished, represents the initial possibility of the operator variable modification type mutation kill information needs to be modified, represents the initial possibility of the insertion deletion type mutation kill information needs to be modified, let , ;

[0121] Step 36, calculate the likelihood function , which represents the proportion of failed tests in all kill information, which can be directly counted from the data set, but different mutation types need to be distinguished, which can be divided into two types:

[0122] , ;

[0123] Step 37, using Bayes' theorem, update the kill information of the failed test to the probability of not being killed for the two mutation types:

[0124] , ,

[0125] The updated instead of , the updated instead of , as the prior probability of the next batch, repeat the above calculation until a predetermined number of iterations is reached, this demonstration only shows an example, so no iteration is needed;

[0126] Step 38, according to the final modified probability, modify the kill information matrix, the method and step 34 are the same, assuming that for mutation 1, a random number r = 0.4 is generated, since r < 0.625, the kill information is modified to not be killed, the rest is similar and will not be repeated, the modified kill information matrix is shown in Table 4:

[0127] Table 4 Kill information matrix

[0128]

[0129] In step 4, calculate the suspicious degree of code lines to get suspicious code, the specific steps are as follows:

[0130] Step 41, count the test result vector and the information in the kill information matrix: represents the number of times the code line is killed by the passing test case, represents the number of times the code line is killed by the failed test case, represents the number of times the code line is not killed by the passing test case, represents the number of times the code line is not killed by the failed test case, here we take line number 5 as an example, , , , , calculate the suspicious degree of using the Ochiai formula: ( )= , the suspicious degree of line numbers 4 and 6 is 0, the higher the suspicious degree, the more likely the code line contains a fault, sort the code lines according to the suspicious degree from high to low to generate a suspicious code list, in this example, line number 5 is the most likely to cause a fault.

[0131] A computer device / apparatus / system comprising a memory, a processor and a computer program stored on the memory, the processor executing the computer program to implement the steps of the above method.

[0132] A computer readable storage medium having stored thereon computer program / instructions which, when executed by a processor, implement the steps of the above method.

[0133] The present application is described in reference to the flowcharts and / or block diagrams of the methods, apparatus (systems) and computer program products in accordance with embodiments of the present application. It is understood that each flow and / or block in the flowcharts and / or block diagrams, as well as combinations of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowcharts and / or block diagrams block or blocks. Figure 1 one or more flows and / or blocks Figure 1 means for carrying out the function specified in the flowchart block or blocks.

[0134] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the flowcharts and / or block diagrams block or blocks. Figure 1 one or more flows and / or blocks Figure 1 means for carrying out the function specified in the flowchart block or blocks.

[0135] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the flowcharts and / or block diagrams block or blocks. Figure 1 one or more flows and / or blocks Figure 1 means for carrying out the function specified in the flowchart block or blocks.

[0136] The above only is the preferred embodiment of the present application, it should be pointed out that, for those skilled in the technical field, without departing from the technical principles of the present application, can also make a number of improvements and variations, these improvements and variations should be considered as the protection scope of the present application.

Claims

1. A program mutation fault location method based on a revised test matrix, characterized by, Includes the following steps: Step 1: Identify the lines of code in the program that are on the critical path, have shared variables, and contain potential failure interaction points. Select the lines of code that meet two of the above three conditions as candidate lines of code for generating mutations. Step 2: Use a large language model to understand the source code context, generate complex mutants using the candidate code lines found in Step 1, input test cases, run the mutated program to obtain the kill information matrix, and run the source program to obtain the test result vector. Step 3: Set prior probabilities for different types of mutants, test result vectors, and kill information matrices respectively. Use Bayesian methods to correct the prior probabilities in the dataset to obtain the modified probabilities. Use the modified probabilities to modify the failure test and kill information in the test matrix. The dataset refers to a publicly available vulnerability dataset; The steps to obtain the modification probability of the test matrix include: Step 31, setting the prior probability of the test result matrix , represents the initial probability of modifying a failed test to a passed test, the proportion of passed tests as a conditional probability, used to measure the relative proportion of passed tests and total tests under the current test set; = ， to pass the number of test cases, is the total number of test cases; Step 32, if As a likelihood function, denotes the probability that a failed test is mislabeled as a passed test, obtained by multiplying the probability of a failed test not killing and the probability of a passed test killing , represents the proportion of failed tests, equal to 1- wherein, represents the number of code lines killed by a passing test case, represents the number of code lines not killed by a failed test case, n is the number of code lines to be mutated, is the number of failed test cases; Step 33: Using Bayes' theorem, update the probability that a failed test is changed to a passed test: ， Probability of a test being modified from failing to passing based on the updated test Correcting the test result vector; Step 34, for each failed test case, generate a random number r e [0, 1], if r , mark it as passing the test, get the modified test result vector; Step 35, distinguish different mutation types of the kill information matrix, divide the mutants into m batches according to the types, and perform iterative calculation on each batch; set the initial prior probability of the kill information , represents the initial possibility that the kill information of the operator variable modification type mutation needs to be corrected, represents the initial possibility that the kill information of the insertion deletion type mutation needs to be corrected; Step 36, computing the likelihood function represents the fraction of failed tests among all kill information; ， ； , respectively denote operator variable modification type likelihood function, insertion deletion type likelihood function; Step 37, updating the modification probabilities using Bayes' theorem, said modification probabilities including modifying the kill information of the failed test to the probability of not being killed, respectively for operator variable modification type mutations, insertion deletion type mutations , , is represented as: ， , The updated Instead of The updated Instead of As a prior probability for the next batch, return to step 35 to recalculate until a predetermined number of iterations is reached; Step 38: Based on the final modification probability, correct the kill information matrix using the method in step 34; Step 4: Calculate the suspicion level based on the modified test matrix and generate a list of suspicious codes as the final identified faults.

2. The method of claim 1, wherein, In step 1, the steps for identifying lines of code in the critical path of the program include: Use symbolic execution tools to perform symbolic execution on the source program, generating all possible execution paths of the program; During symbolic execution, the path conditions, branch information, and symbolic input for each path are recorded; The path coverage information is generated by using a code coverage analysis tool, and the path coverage information and the condition frequency are combined to identify a path having the greatest influence on the overall behavior of the program, which is marked as a critical path to form a critical path code line set .

3. The method of claim 1, wherein, In step 1, the steps to identify the lines of code that own the shared variables include: The static analysis tool is used to track shared variables, obtain definition-use chains of all variables in the program, find global variables, static variables and parameters passed between multiple functions, track the definition and use relationship of the variables, identify the propagation path of the variables between different code lines, identify variables that can be accessed by multiple threads in a multi-threaded program, mark code lines related to shared variables, and form a shared variable code line set .

4. The method of claim 1, wherein, In step 1, the steps of identifying lines of code containing potential failure interaction points include: The constraint relationship between the path condition and the shared variable is expressed as a set of logical formulas, a logical reasoning tool is used to solve the logical formulas, and a solution satisfying a specific condition, such as a plurality of faults being triggered under the same condition, is searched; according to a solving result, a code line that may cause a plurality of faults to interact under a specific path condition is found out, the code line containing a potential fault interaction point is marked, and a fault interaction point code line set is formed .

5. The method of claim 4, wherein, The path conditions include branching conditions and looping conditions; the logical reasoning tool used is Z3.

6. The method of claim 1, wherein, Step 2 includes the following steps: Step 21, using a large language model LLM to understand the context of the source code, the candidate code lines found in step 1 Generating complex mutants, for each code line to be mutated Input the context code segment where it is located into the LLM, instruct the LLM to perform operator variable mutation and code insertion and deletion mutation on the input source program; Step 22: After generating mutants, first test the source program with the test set, save the pass and fail cases of the source program, and obtain the test result vector. Then, use the test case set to test each mutant. If the mutant's running result is different from the source program, it is defined as being killed. Record whether all mutants generate killing information and obtain the killing information matrix.

7. The method of claim 1, wherein, Step 4 includes the following steps: Step 41, count the number of times information in the test result vector and the kill information matrix: the number of times a code line is killed by a passing test case, the number of times a code line is killed by a failing test case, the number of times a code line is not killed by a passing test case, the number of times a code line is not killed by a failing test case, the number of times a code line is killed by a passing test case, the number of times a code line is not killed by a passing test case, the number of times a code line is killed by a failing test case, the number of times a code line is not killed by a failing test case; Calculate using the Ochiai formula Suspicion level: ( )= ; The lines of code are sorted from highest to lowest suspicion level to generate a list of suspicious code.

8. A computer device / equipment / system, characterized in that, It includes a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to perform the steps of the method as claimed in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, It stores a computer program / instruction thereon, characterized in that when the computer program / instruction is executed by a processor, it implements the steps of any one of claims 1-7.

Images