Program abrupt change fault positioning method and system based on correction test matrix

Abstract

The invention discloses a program abrupt change fault positioning method and system based on a correction test matrix, and the method comprises the steps: processing a to-be-tested source program through a method of combining symbolic execution, shared variable tracking and hypothesis reasoning, and obtaining a to-be-tested source program through identifying a key path in a code; code lines used for generating mutation are found out by sharing variables and potential fault interaction points; understanding the context of the source code based on a large language model, generating complex mutants for to-be-selected code lines, and running the mutated program to obtain a kill information matrix; for different mutation types, the modification probability is corrected through a Bayesian method, the test matrix is modified according to the probability, and noise in the test matrix is reduced; and calculating a suspicious degree according to the modified test matrix, and generating a suspicious code list. According to the method, unnecessary mutation operation can be reduced, the test coverage rate is increased, and the fault positioning accuracy is improved.

Description

Technical Field

[0001] The invention relates to a method for locating a program mutation fault, and belongs to the technical field of software testing. Background Art

[0002] As the scale and complexity of software systems continue to increase, software plays an increasingly important role in all walks of life. However, software faults still occur frequently, which may cause system crashes, functional failures, and even cause serious security issues. In order to ensure software quality, fault location has become a crucial part of the software development and maintenance process.

[0003] Traditional fault location 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 location, academia and industry have proposed a variety of automated fault location technologies, among which mutation-based fault location is a commonly used method. When there are multiple faults in the software, the faults may affect each other, resulting in inaccurate suspiciousness calculation results, reducing the effectiveness of fault location. Program mutation testing generates mutants by introducing small modifications (i.e. mutations) in the source code to evaluate the effectiveness of test cases and locate potential faults. However, in practical applications, traditional mutation testing methods perform various possible mutations on each line of code in the program, which will generate a large number of mutants, resulting in huge computational costs and time overhead, making it difficult to apply in actual projects. Secondly, in a multi-fault environment, the behavior of the mutant may be affected by multiple faults, resulting in a large amount of noise in the test results and the kill information matrix, affecting the accuracy of fault location.

[0004] In recent years, in order to cope with the challenges of fault location in multi-fault environments, a variety of improved methods have been proposed, such as fault location based on machine learning and methods based on statistical analysis. However, these methods still have problems such as complex models, large training data requirements, and insufficient generalization capabilities. Summary of the invention

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

[0006] In order to solve the above technical problems, the present invention provides a method for locating program mutation faults based on a modified test matrix, comprising the following steps:

[0007] 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, and select the code lines that meet two of the above three conditions as candidate code lines for generating mutations;

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

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

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

[0011] In the aforementioned method for locating a program mutation fault based on a modified test matrix, in step 1, the step of identifying the code line in the critical path of the program includes:

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

[0013] During symbolic execution, the path conditions, branch information, and symbolic input of each path are recorded;

[0014] Use code coverage analysis tools to generate path coverage information, combine 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] In the aforementioned method for locating program mutation faults based on a 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, 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 variables, identify the propagation path of variables between different code lines, in a multi-threaded program, identify variables that may be accessed by multiple threads, mark the code lines involving shared variables, and form a set of shared variable code lines. .

[0016] In the aforementioned method for locating program mutation faults based on a modified test matrix, in step 1, the step of identifying code lines containing potential fault interaction points includes: expressing the constraint relationship between path conditions and shared variables as a set of logical formulas, using logical reasoning tools to solve the logical formulas, and finding solutions that meet specific conditions, such as the situation where multiple faults are triggered under the same conditions; based on the solution results, finding code lines that may cause multiple fault interactions under specific path conditions, marking the code lines containing potential fault interaction points, and forming a set of fault interaction point code lines. .

[0017] In the aforementioned method for locating program mutation faults based on a modified test matrix, the path conditions include branch conditions and loop conditions; and the logic reasoning tool adopts Z3.

[0018] The aforementioned method for locating a program mutation fault based on a modified test matrix, in step 2, includes the following steps:

[0019] Step 21: Use the large language model LLM to understand the context of the source code and select the lines of code found in step 1. Generate complex mutants, for each line of code to be mutated , input the context code snippet into LLM, and instruct LLM to perform operator variable mutation and code insertion and deletion mutation on the input source program;

[0020] Step 22. After the mutant is generated, the source program is first tested with the test set, and the pass and fail conditions of the source program are saved to obtain a test result vector. Then, each mutant is tested with the test case set. If the mutant running result is different from the source program, it is defined as killed. Record whether all mutant runs generate kill information to obtain a kill information matrix.

[0021] In the aforementioned method for locating a program mutation fault based on a modified test matrix, in step 3, obtaining the modification probability of the test matrix includes:

[0022] Step 31: Set the prior probability of the test result matrix , which means the initial probability of changing a failed test to a passed test, and the proportion of passed tests As a conditional probability, it is used to measure the relative proportion of passed tests and total tests under the current test set;

[0023] = ,

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

[0025] Step 32: As the likelihood function, It represents the probability that a failed test is mistakenly marked as a passed test, which is obtained by multiplying the probability of a failed test not killing the test and the probability of a passed test killing the test.

[0026] ,

[0027] Indicates the percentage of failed tests, equal to 1- ,in, Indicates the line of code The number of times it was killed by a passing test case, Indicates the line of code The number of times it was not killed by a failed test case, n is the number of code lines to be mutated, is the number of failed test cases;

[0028] Step 33. Using Bayes’ theorem, update the probability that the failed test is modified to a passed test:

[0029] ,

[0030] The probability that a failing test is modified to a passing test based on the update Correct the test result vector;

[0031] Step 34. For each failed test case, generate a random number r∈[0,1]. If r< , then mark it as passed the test and get the modified test result vector;

[0032] Step 35: Distinguish different mutation types by killing information matrix, divide mutants into m batches by type, perform iterative calculation on each batch; set initial prior probability for killing information , Indicates the initial probability that the kill information of the operator variable modification type mutation needs to be corrected, Indicates the initial probability that the killing information of insertion-deletion type mutations needs to be corrected;

[0033] Step 36: Calculate the likelihood function , represents the proportion of failed tests in all kill information;

[0034] , ;

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

[0036] Step 37: Use Bayesian theorem to update the modification probability, which includes the probability of modifying the kill information of the failed test to the probability of not killing for the operator variable modification type mutation and the insertion and deletion type mutation respectively. , , expressed as:

[0037] ,

[0038] ,

[0039] Will update replace , will update replace , as the prior probability of the next batch, return to step 35 and recalculate until the predetermined number of iterations is reached;

[0040] Step 38: According to the final modification probability, the killing information matrix is ​​corrected using the method in step 34.

[0041] The aforementioned method for locating a program mutation fault based on a modified test matrix, in step 4, includes the following steps:

[0042] Step 41, statistically analyze the information in the test result vector and the kill information matrix: Indicates the line of code The number of times it was killed by a passing test case, Indicates the line of code The number of times it was killed by a failed test case, Indicates the line of code The number of times it was killed by a failed test case, Indicates the line of code The number of times it was not killed by a failed test case;

[0043] Calculated using Ochiai formula Degree of suspicion: ( )= ;

[0044] Sort the code lines from most suspicious to least suspicious to generate a list of suspicious code.

[0045] A computer device / equipment / system comprises a memory, a processor and a computer program stored in the memory, wherein the processor executes 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 implements the steps of the above method when executed by a processor.

[0047] The beneficial effects achieved by the present invention are as follows: the method of the present invention accurately identifies the key code lines to be mutated by combining symbolic execution, shared variable tracking and logical reasoning; uses a large language model to generate complex mutants to simulate real fault scenarios; introduces the Bayesian method to correct the test matrix to reduce the interference of multiple faults on the test results; and finally generates a suspicious code list through suspicion calculation to improve the accuracy and efficiency of fault location. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 Flow chart of the program mutation fault location method based on the modified test matrix in Example 1 of the present invention. DETAILED DESCRIPTION

[0049] The invention is further described in detail below in conjunction with specific embodiments.

[0050] Example 1

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

[0052] 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, and select the code lines that meet two of the above three conditions as candidate code lines for generating mutations;

[0053] Step 2: Use the large language model to understand the source code context, use the candidate code lines found in step 1 to generate complex mutants, input the test case, 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 respectively, use the Bayesian method to correct the prior probabilities in the data set to obtain modified probabilities, and use the modified probabilities to modify the failed tests and kill information in the test matrix; the data set refers to a public vulnerability data set, 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 code line to be selected includes the following steps:

[0057] Step 11: Use a symbolic execution tool to perform symbolic execution on the source program to generate all possible execution paths of the program, wherein the symbolic execution tool adopts KLEE;

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

[0059] In order to filter out the paths that control the main logic flow, use code coverage analysis tools (such as llvm-cov) to generate path coverage information. Combine condition frequency and path coverage information to identify the paths that have the greatest impact on the overall behavior of the program, mark them as critical paths, and form a critical path code line set. ;

[0060] Step 12: Use static analysis tools to track shared variables, 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 variables, identify the propagation path of variables between different code lines, and in multi-threaded programs, identify variables that may be accessed by multiple threads, mark the code lines involving shared variables, and form a collection of shared variable code lines. ; The static analysis tool adopts Frama-C;

[0061] Step 13: Express the constraint relationship between the path conditions and shared variables as a set of logical formulas, use logical reasoning tools to solve the logical formulas, and find solutions that meet specific conditions, such as the situation where multiple faults are triggered under the same conditions; based on the solution results, find the code lines that may cause multiple fault interactions under specific path conditions, mark the code lines containing potential fault interaction points, and form a set of fault interaction point code lines ; The path conditions include branch conditions and loop conditions; the logical reasoning tool uses Z3;

[0062] Step 14. For each line of code If it exists in at least two of the above three code line sets, it will be added to the code line set to be mutated , get the code lines that need to be mutated, and ensure that the mutants are concentrated in the key areas that can trigger multiple faults. Through the method in step 1, unnecessary mutation operations can be reduced.

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

[0064] Step 21: Use the large language model LLM to understand the context of the source code and select the lines of code found in step 1. Generate complex mutants, for each line of code to be mutated , input the context code snippet into LLM, and instruct LLM to perform operator variable mutation and code insertion and deletion mutation on the input source program;

[0065] Step 22: After generating mutants, first use the test set to test the source program, save the pass and fail conditions of the source program, and obtain the test result vector. Then use the test case set to test each mutant. If the mutant running result is different from the source program, it is defined as a kill. Record whether all mutant runs generate kill information to obtain a kill information matrix. Complex mutants generated by large language models can discover more potential faults and improve test coverage.

[0066] In step 3, obtaining the modification probability of the test matrix includes:

[0067] Step 31: Set the prior probability of the test result matrix , which means the initial probability of changing a failed test to a passed test, and the proportion of passed tests As a conditional probability, it is used to measure the relative proportion of passed tests and total tests under the current test set;

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

[0069] Step 32: As the likelihood function, It represents the probability that a failed test is mislabeled as a passed test. Since there is no direct way to represent it, it is obtained by multiplying the probability of a failed test not killing the test and the probability of a passed test killing the test. , Indicates the percentage of failed tests, equal to 1- ,in, Indicates the line of code The number of times it was killed by a passing test case, Indicates the line of code The number of times it was not killed by a failed test case, n is the number of code lines to be mutated, is the number of failed test cases;

[0070] Step 33. Using Bayes’ theorem, update the probability that the failed test is modified to a passed test:

[0071] ,

[0072] The probability that a failing test is modified to a passing test based on the update , correct the test result vector;

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

[0074] Step 35: Distinguish different mutation types by killing information matrix, divide mutants into m batches by type, perform iterative calculation on each batch; set initial prior probability for killing information , that is, the initial possibility that the killing information needs to be corrected before the test results are observed. Here, it is necessary to distinguish the mutation types. Indicates the initial probability that the kill information of the operator variable modification type mutation needs to be corrected, Indicates the initial probability that the killing information of insertion-deletion type mutations needs to be corrected;

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

[0076] It can be obtained by directly counting the data set, but it is necessary to distinguish different mutation types, which are divided into two types:

[0077] , ;

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

[0079] Step 37: Use Bayesian theorem to update the modification probability, which includes the probability of modifying the kill information of the failed test to the probability of not killing for the operator variable modification type mutation and the insertion and deletion type mutation respectively. , , expressed as:

[0080] ,

[0081] ,

[0082] Will update replace , will update replace , as the prior probability of the next batch, return to step 35 and recalculate until the predetermined number of iterations is reached;

[0083] Step 38: According to the final modification probability, the killing information matrix is ​​corrected using the method in step 34.

[0084] The test matrix is ​​corrected by the Bayesian method to reduce the interference of multiple faults on the test results, thereby improving the accuracy of fault location.

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

[0086] Step 41, statistically analyze the information in the test result vector and the kill information matrix: Indicates the line of code The number of times it was killed by a passing test case, Indicates the line of code The number of times it was killed by a failed test case, Indicates the line of code The number of times it was killed by a failed test case, Indicates the line of code The number of times it was not killed by a failed test case;

[0087] Calculated using Ochiai formula Degree of suspicion: ( )= ;

[0088] The higher the suspicion, the more lines of code Sort the lines of code from most to least suspicious, the more likely they are to contain faults, to generate a list of suspicious code.

[0089] Assume there is a simple calculator program that provides basic arithmetic operations, including addition, subtraction, multiplication, and division. The source code is shown in Table 1:

[0090] Table 1 Calculator program source code

[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 the array to be out of bounds; when size <= 0, arr[0] will be accessed out of bounds due to the lack of array size check.

[0093] Using a program mutation fault location method based on a modified test matrix of the present invention, 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 that meet two of the above three conditions will be selected as candidate code lines for generating mutations. 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, enter the loop normally;

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

[0098] Path 3: When i == size, arr[size] is accessed, which is out of bounds.

[0099] Use llvm-cov to generate path coverage information and identify the paths that control the main logic flow. Line 4 initializes the maximum value and is always executed, so it is of high importance. Line 5 controls the number of loops and affects the array access range. Line 6 compares and updates the maximum value. Included critical path code behaviors: 4, 5, 6;

[0100] Step 12: Use Frama-C to track shared variables and obtain 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, and max and i are local variables in the function. The variables arr[] and i are used multiple times in the loop body, which involves array access and may cause out-of-bounds problems. Therefore, Included shared variable code behavior: 4, 5, 6;

[0102] Step 13. Express the constraint relationship between the 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]), and Formula 2 is: i=size⟹Access(arr[size]). Enter the above constraints into Z3 and find a solution that satisfies the conditions. When size <= 0, arr[0] is out of bounds, involving row 4. When i = size, arr[size] is out of bounds, involving row 6. Rows 4 and 6 will cause array out of bounds under certain conditions, and are fault interaction points. Therefore, Included fault interaction point code behaviors: 4, 6;

[0103] Step 14. For each line of code , to determine whether at least two of the above sets exist at the same time, where row numbers 4, 5, and 6 meet the requirements, so The code behaviors to be mutated are: 4, 5, and 6.

[0104] Step 2: Use the large language model to understand the source code context, use the candidate code lines found in step 1 to generate complex mutants, input the test case, run the mutated program to obtain the kill information matrix, and run the source program to obtain 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 code lines to be selected found in step 1 to simulate abnormal behaviors in a multi-fault environment. A mutation for line number 4 is: modify intmax = arr[0] to int max = 0. This mutation means deleting the initial assignment to the array. The other mutations are similar and will not be described in detail.

[0106] Step 22: Run the mutant and the source program to obtain the test result vector and the kill information matrix;

[0107] One of the test cases is: data = {3, 5, 2, 8, 6}; size1 = 5; the expected output is 8. The other test cases are similar. Running the source program to get the test result vector is shown in Table 2:

[0108] Table 2 Test result vector table

[0109]

[0110] Where 0 means failure and 1 means pass. The kill information matrix obtained by running the mutant is shown in Table 3:

[0111] Table 3 Killing information matrix

[0112]

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

[0114] Step 3: For different types of mutants, test result vectors, and the kill information matrix, set the prior probability respectively. Use the Bayesian method to correct the prior probability in the data set to obtain the modified probability. For a more intuitive demonstration, assume that the above test is an example in the data set, and use the modified probability to modify the failed test and kill information in the test matrix. The specific steps are as follows:

[0115] Step 31: Based on experience, set the prior probability of the test result matrix In this test is 1, is 5, calculate the proportion of passed tests =0.2 as the conditional probability, which is used to measure the relative proportion of passed tests to total tests under the current test set;

[0116] Step 32: As the likelihood function, It represents the probability that a failed test is mislabeled as a passed test. Since there is no direct way to represent it, it is obtained by multiplying the probability of a failed test not killing the test and the probability of a passed test killing the test. , Indicates the percentage of failed tests, equal to 1- ,so ,in, Indicates the line of code The number of times it was killed by a passing test case, here 1, Indicates the line of code The number of times 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 that the failed test is modified to a passed test: , according to the updated , correct the test result vector.

[0118] Step 34. For each failed test case, generate a random number r∈[0,1]. If r< , it is marked as passed the test and the modified test result vector is obtained. Since the probability obtained this time is very small, the test result vector is not modified;

[0119] Step 35: For the killing information matrix, different mutation types need to be distinguished;

[0120] Divide the mutants into m batches by type, perform iterative calculations on each batch, and set the initial prior probability for the killing information , that is, the initial possibility that the killing information needs to be corrected before the test results are observed. Here, it is necessary to distinguish the mutation types. Indicates the initial possibility that the information killed by the operator variable modification type mutation needs to be corrected, Indicates the initial probability that the killing information of the insertion and deletion type mutation needs to be corrected, let , ;

[0121] Step 36: Calculate the likelihood function , which represents the proportion of failed tests in all kill information, can be obtained directly from the statistical data set, but it is necessary to distinguish different mutation types, which are divided into two types:

[0122] , ;

[0123] Step 37: Using Bayes’ theorem, update the probability of changing the kill information of failed tests to not kill for the two mutation types:

[0124] , ,

[0125] Will update replace , will update replace , as the prior probability of the next batch, repeat the above calculation until the predetermined number of iterations is reached. This demonstration only shows one example, so there is no need to iterate;

[0126] Step 38: According to the final modification probability, the killing information matrix is ​​modified in the same way as step 34. Assume that for mutation 1, a random number r=0.4 is generated. Since r<0.625, the killing information is modified to not killing. The rest of the modifications are similar and will not be repeated. The modified killing information matrix is ​​shown in Table 4:

[0127] Table 4 Killing information matrix

[0128]

[0129] In step 4, the suspicion of the code line is calculated to obtain the suspicious code. The specific steps are as follows:

[0130] Step 41, statistically analyze the information in the test result vector and the kill information matrix: Indicates the line of code The number of times it was killed by a passing test case, Indicates the line of code The number of times it was killed by a failed test case, Indicates the line of code The number of times it was killed by a failed test case, Indicates the line of code The number of times the program was not killed by a failed test case. Here, we take line 5 as an example. , , , , calculated using the Ochiai formula Degree of suspicion: ( )= , the suspicion calculation values ​​of line numbers 4 and 6 are both 0. The higher the suspicion, the higher the suspicion of the code line. The more likely it is to contain a fault, the more suspicious the code lines are. Sort the lines of code from high to low suspicion to generate a list of suspicious code. In this example, line number 5 is the code that is most likely to cause a fault.

[0131] A computer device / equipment / system comprises a memory, a processor and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the above method.

[0132] A computer-readable storage medium stores a computer program / instruction, which implements the steps of the above method when executed by a processor.

[0133] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0134] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0135] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0136] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for locating program mutation faults based on a modified test matrix, characterized in that: The following steps are involved: 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, and select the code lines that meet two of the above three conditions as candidate code lines for generating mutations; Step 2: Use the large language model to understand the source code context, use the candidate code lines found in step 1 to generate complex mutants, input the test case, 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 the Bayesian method to correct the prior probabilities in the data set to obtain modified probabilities, and use the modified probabilities to modify the failed tests and kill information in the test matrix; The dataset refers to a publicly available vulnerability dataset; 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. A method for locating program mutation faults based on a modified test matrix according to claim 1, characterized in that: In step 1, the steps of identifying the lines of code in the program that are on the critical path include: Use symbolic execution tools to perform symbolic execution on the source program and generate all possible execution paths of the program; During symbolic execution, the path conditions, branch information, and symbolic input of each path are recorded; Use code coverage analysis tools to generate path coverage information, combine 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 .

3. The method for locating program mutation faults based on a modified test matrix according to claim 1, characterized in that: In step 1, the steps to identify the line of code that owns the shared variable include: Use static analysis tools to track shared variables, obtain the definition-usage chain of all variables in the program, find global variables, static variables, and parameters passed between multiple functions, track the definition and usage relationship of variables, identify the propagation path of variables between different lines of code, and in multi-threaded programs, identify variables that may be accessed by multiple threads, mark the lines of code involving shared variables, and form a collection of shared variable code lines. .

4. The method for locating program mutation faults based on a modified test matrix according to claim 1, characterized in that: In step 1, the steps to identify the lines of code containing potential fault interaction points include: The constraint relationship between path conditions and shared variables is expressed as a set of logical formulas. The logical reasoning tool is used to solve the logical formulas to find solutions that meet specific conditions, such as when multiple faults are triggered under the same conditions. Based on the solution results, the code lines that may cause multiple fault interactions under specific path conditions are found, and the code lines containing potential fault interaction points are marked to form a set of fault interaction point code lines. .

5. The method for locating program mutation faults based on a modified test matrix according to claim 4, characterized in that: The path conditions include branch conditions and loop conditions; the logic reasoning tool adopts Z3.

6. The method for locating program mutation faults based on a modified test matrix according to claim 1, characterized in that: In step 2, the following steps are included: Step 21: Use the large language model LLM to understand the context of the source code and select the lines of code found in step 1. Generate complex mutants, for each line of code to be mutated , input the context code snippet into LLM, and instruct LLM to perform operator variable mutation and code insertion and deletion mutation on the input source program; Step 22. After the mutant is generated, the source program is first tested with the test set, and the pass and fail conditions of the source program are saved to obtain a test result vector. Then, each mutant is tested with the test case set. If the mutant running result is different from the source program, it is defined as killed. Record whether all mutant runs generate kill information to obtain a kill information matrix.

7. The method for locating program mutation faults based on a modified test matrix according to claim 1, characterized in that: In step 3, the step of obtaining the modification probability of the test matrix includes: Step 31: Set the prior probability of the test result matrix , which means the initial probability of changing a failed test to a passed test, and the proportion of passed tests As a conditional probability, it is used to measure the relative proportion of passed tests and total tests under the current test set; = ， is the number of passed test cases, is the total number of test cases; Step 32: As the likelihood function, It represents the probability that a failed test is mistakenly marked as a passed test, which is obtained by multiplying the probability of a failed test not killing the test and the probability of a passed test killing the test. , Indicates the percentage of failed tests, equal to 1- ,in, Indicates the line of code The number of times it was killed by a passing test case, Indicates the line of code The number of times it was 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 the failed test is modified to a passed test: ， The probability that a failing test is modified to a passing test based on the update Correct the test result vector; Step 34. For each failed test case, generate a random number r∈[0,1]. If r< , then mark it as passed the test and get the modified test result vector; Step 35: Distinguish different mutation types by killing information matrix, divide mutants into m batches by type, perform iterative calculation on each batch; set initial prior probability for killing information , Indicates the initial probability that the kill information of the operator variable modification type mutation needs to be corrected, Indicates the initial probability that the killing information of insertion-deletion type mutations needs to be corrected; Step 36: Calculate the likelihood function , represents the proportion of failed tests in all kill information; ， ； , They represent the operator variable modification type likelihood function and the insertion and deletion type likelihood function respectively; Step 37: Use Bayesian theorem to update the modification probability, which includes the probability of modifying the killing information of the failed test to not killing for the operator variable modification type mutation and insertion and deletion type mutation respectively. , , expressed as: ， , Will update replace , will update replace , as the prior probability of the next batch, return to step 35 and recalculate until the predetermined number of iterations is reached; Step 38: According to the final modification probability, the killing information matrix is ​​corrected using the method in step 34.

8. The method for locating program mutation faults based on a modified test matrix according to claim 1, characterized in that: In step 4, the following steps are included: Step 41, statistically analyze the information in the test result vector and the kill information matrix: Indicates the line of code The number of times it was killed by a passing test case, Indicates the line of code The number of times it was killed by a failed test case, Indicates the line of code The number of times it was killed by a failed test case, Indicates the line of code The number of times it was not killed by a failed test case; Calculated using Ochiai formula Degree of suspicion: ( )= ; Sort the code lines from most suspicious to least suspicious to generate a list of suspicious code.

9. A computer device / equipment / system, characterized in that: The invention comprises a memory, a processor and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that: A computer program / instruction is stored thereon, wherein when the computer program / instruction is executed by a processor, the steps of the method as claimed in any one of claims 1-8 are implemented.

Images