A visual analysis method for fault location

Abstract

The present application relates to a kind of visual analysis methods of fault location, specific steps are as follows: step 1, overview is carried out to test case, show the execution result of each test case, and the code line number of each test case execution;Step 2, based on existing statement suspicion formula, the suspicion of each line statement is calculated, and the test coverage of each statement is combined, and the statement suspicion and whether the execution information such as being executed are shown;Step 3, the execution process of single test case is shown, help user understand the specific running process when program executes, analyze when the program appears unexpected result, judge the actual position of fault generation, obtain the intermediate result of program execution by using GDB;Step 4, whether the accuracy of fault location needs to be judged, the system allows user to modify fault position, and re-execute program, to detect whether the current fault position is accurate.The present application improves fault location efficiency.

Description

Technical Field

[0001] This invention relates to the technical field of fault location, and in particular to a visual analysis method for fault location. Background Technology

[0002] With the rapid development of computer technology, software functions are becoming increasingly powerful, and its scale and complexity are also increasing dramatically. Since the birth of the first software, software debugging has been a crucial task. The purpose of software debugging is to discover and fix software faults, including fault location and correction. Fault location is a time-consuming and tedious task. In the software development process, 50% of the software development and maintenance budget is allocated to fault location and correction.

[0003] Traditional fault location can be subdivided into four techniques: program logging, assertions, breakpoints, and analysis. Program logging uses statements (such as `print`) to monitor variable values ​​and other program state information, which programmers use to diagnose the cause of program failures. Assertions detect erroneous behavior during execution; they add constraints to the program, and when the constraint is true, the program executes the correct statement. Breakpoints are used to pause the program and allow programmers to examine its current state and determine if there are any faults. Analysis involves analyzing program execution speed and memory usage, typically used for program optimization. However, these four fault location techniques are no longer sufficient for effective fault location; therefore, many advanced fault location techniques that can be automated or semi-automated and utilize causal relationships have emerged.

[0004] For example, the most widely used fault localization technique is based on program spectrum analysis. After executing all test cases, it analyzes the coverage information of each statement and generates a program spectrum. Finally, it calculates the suspicion level of each statement from the program spectrum. This method provides programmers with the suspicious values ​​of statements and suggests that they debug in the order of the suspicious values.

[0005] For example, broader research on software fault localization is based on slicing techniques. This method groups all code containing characteristic variables into a slice and removes irrelevant parts to simplify the scope of fault localization. Subsequent research proposed dynamic slicing. This method generates statement fragments that can truly affect specific variables by analyzing the program's execution process.

[0006] Therefore, some researchers have attempted to combine fault location methods with visualization, employing color coding, visual charts, and other methods to more intuitively display fault location results. For example, based on the accuracy and coverage of test cases, statements are coded using color and brightness; others continuously recommend breakpoints to programmers based on the analysis of execution information and feedback collected from programmers, and record historical breakpoints to help programmers debug.

[0007] However, despite the rapid development of fault location methods and related visualization technologies, most fault location algorithms only provide statement susceptibility and expect programmers to analyze based on these susceptibility levels. This is far removed from the actual fault location logic of programmers and is therefore difficult to apply. Existing visualization technologies still require programmers to constantly modify breakpoints and repeatedly check variable values ​​to determine whether the program execution process matches expectations. Moreover, these methods heavily rely on programmers' development experience for judgment and analysis, making fault location a time-consuming and labor-intensive task. Summary of the Invention

[0008] In view of the above-mentioned problems in the existing technology, the technical problem to be solved by the present invention is that the existing fault location requires the programmer's development experience to make judgments and analyses, which leads to time and effort consumption.

[0009] How to solve the above problems: This invention obtains the intermediate process of program execution, and uses visualization to display the execution results of test cases, source code logic and statement doubts to users, and reproduces the execution process of test cases, so as to help programmers improve the efficiency of fault location.

[0010] This invention discloses a visual analysis method for fault location, specifically including the following steps:

[0011] Step 1: Provide an overview of the test cases, displaying the execution result of each test case and the number of lines of code executed for each test case. Specifically, by executing all test cases of the program, relevant information during the target software testing process is obtained. After obtaining the test case execution information, the relevant information is displayed using rectangles. Within a rectangle, the transparency indicates the number of times the statement of the current test case is executed; different colors are used to indicate whether the execution of the test case meets expectations. The relevant information includes: the result of each test case, the number of statement executions and the relevant lines of code executed, the test coverage of each statement, and the test cases executed.

[0012] Step 2: Based on the following existing statement suspicion formulas, calculate the suspicion level of each statement and combine it with the test coverage of each statement to display information such as statement suspicion level and whether it has been executed, helping users quickly find statements with high suspicion level. During the display process, test coverage and statement suspicion level are marked using rectangles of different lengths, and the suspicion level corresponding to the statement can be displayed according to different formulas. The source code is highlighted to indicate whether the current code has been executed. If the current code has been executed, the executed source code will be highlighted; otherwise, no highlighting will be done.

[0013]

[0014]

[0015]

[0016] In the above formula: Nep indicates that the test case executing the relevant statement passed; Nef indicates that the test case executing the relevant statement failed; Nnp indicates that the test case without executing the relevant statement passed; N n f represents the test case that failed without executing the relevant statement; Np represents the set of test cases that passed with executing the relevant statement and test cases that passed without executing the relevant statement; Nf represents the set of test cases that failed with executing the relevant statement and test cases that failed without executing the relevant statement.

[0017] Step 3: Then, by demonstrating the execution process of a single test case, we help users understand the specific running process of the program, analyze when the program produces unexpected results, and determine the actual location of the fault. This is mainly achieved by using GDB (GNU symbolic debugger, used for debugging C / C++ programs) to obtain intermediate results of program execution.

[0018] Step 4: Based on the function of providing program modification and viewing code modification history, after the operation in Step 3, it is necessary to determine whether the fault location is accurate. The system allows users to modify the fault location and re-execute the program to check whether the current fault location is accurate. The specific steps are as follows:

[0019] 4-1. Users can directly modify the code in the source code view and re-execute all test cases based on the modified code. When the test cases are re-executed, the code information before and after the modification can be compared, and the specific content of the modification is recorded and displayed in the code modification history view. The specific content mainly includes the line number of the modified code and the modified information data.

[0020] 4-2. Determine whether the test case execution passes. If the test case execution passes, it indicates that the fault has been located and repaired. If the execution fails, the system will record the modification location and allow the user to repeat steps 1-4 to locate the fault.

[0021] Preferably, to facilitate the processing of intermediate result data, the specific steps for obtaining the intermediate results of program execution using GDB in step 3 are as follows:

[0022] 3-1. Obtain the variable names and types related to each step of the test case execution; First, input a macro command into GDB, which contains only a next statement, allowing the program to automatically step to the end of the program; When the program executes, obtain the relevant information of global variables, local variables, and function parameters in the current statement by using the relevant GDB commands: info variables, info locals, and info args; Use these three commands to supplement the proposed macro command, which allows the program to obtain the names of all current variables in sequence at each step of execution; After executing the macro command, parse its output file, and obtain detailed information of the program execution statements, the variable names of the current statements, and the variable types by normalizing the text.

[0023] 3-2. Use the `print` and `display` statements to let GDB display the specific values ​​of variables. For pointer variables, you need to further use `print*` to get their specific values. Then, edit a new macro command. This macro command mainly includes two aspects: the first aspect is the `print`, `print*`, and `display` statements, which are used to get the specific values ​​of variables after each single step of execution; the second aspect is the `next` statement, which helps the program automatically step to the end. After GDB executes the new macro command, finally parse its output file to get the specific values ​​of variables after each step of the test case execution.

[0024] 3-3 Finally, by analyzing the source code, we find the statement information contained in each function, the calling relationship between different functions, and the variable passing relationship when calling these functions. Based on this information, we judge the code during program execution, analyze the environment variables, functions, and code context of each statement, judge the variable relationship between different statements, determine whether the variables between different statements are the same, then merge the same variables, and obtain the statement location where the variable is changed.

[0025] Preferably, for ease of viewing, in step 1, higher transparency indicates fewer statement executions in the current test case, and red indicates that the execution result of the current test case does not meet expectations, while green indicates the opposite, indicating that the execution result of the current test case meets expectations.

[0026] Preferably, to further improve the clarity of data display, in step 1, the rectangle can be used to display relevant information for each test case, or it can be used to display relevant information for a test case that executes a certain statement.

[0027] Preferably, to further improve the speed at which users find faults, in step 2, the highlighted source code will be changed according to the test cases in step 1. At the same time, in the display view, if a statement is not executed, it indicates that the error is not related to these statements. In this case, by looking at the relevant highlighted source code statements through the test cases in step 1, users only need to view the relevant highlighted source code statements to find the problem that occurred in the test, which greatly narrows the scope of fault finding. The statement suspicion level can help users optimize the search order. By setting the statement with a higher suspicion level, the probability of the statement having a fault is greater, which can effectively improve the speed at which users find faults.

[0028] The advantages of the visual analysis method for fault location obtained by this invention are: by demonstrating the entire testing process of this invention, the repetitive steps of setting breakpoints and running programs during fault location can be effectively reduced. This invention helps users to locate faults, and by demonstrating the intermediate process of program execution, we effectively improve the efficiency of fault location. Attached Figure Description

[0029] Figure 1 This is a system display diagram of the present invention;

[0030] Figure 2 To group the experimental results, a box plot is used to represent the structure of the highest, lowest, and average values.

[0031] Figure 3 A structural diagram showing the percentage improvement in test time and efficiency for each program;

[0032] Figure 4 This is a reference diagram illustrating how GDB commands are used to obtain the intermediate results of program execution, analyze the data, and obtain detailed data about the program's execution. Detailed Implementation

[0033] The present invention will now be described in further detail.

[0034] Example 1:

[0035] This embodiment discloses a visual analysis method for fault location, specifically including the following steps:

[0036] Step 1: Provide an overview of the test cases, displaying the execution result of each test case and the number of lines of code executed for each test case. Specifically, by executing all test cases of the program, relevant information during the target software testing process is obtained. After obtaining the test case execution information, the relevant information is displayed using rectangles. Within a rectangle, transparency indicates the number of times the current test case statement was executed; different colors are used to indicate whether the execution of the test case meets expectations. The relevant information includes: the result of each test case (i.e., the final result of the program execution; for example, if a code's purpose is to obtain the factorial of n, then the result of the test case is the result of the program execution using the current test case), the number of statement executions and the relevant lines of code executed (e.g., if a code block contains 100 lines of statements, and the current test case only executes 50 lines, the relevant line information is the specific content and corresponding line number of the 50 lines of statements executed by the current test case), the test coverage of each statement, and the test cases executed (using...). Figure 1 (Displaying part A);

[0037] In step 1, different colors are used to indicate whether the test case execution meets expectations. Specifically, a red box indicates a test case execution error and a green box indicates a test case execution success.

[0038] Step 2: Based on the following existing statement suspicion formulas, calculate the suspicion level for each statement and combine it with the test coverage of each statement. Display the statement suspicion level and whether it has been executed to help users quickly find statements with high suspicion (using...). Figure 1 The left-hand rectangular bar of section C is used for display; during the display process, test coverage and statement skepticism are marked using rectangular bars of varying lengths, allowing for the display of skepticism corresponding to different formulas; and source code is highlighted to indicate whether the current code has been executed. If the current code has been executed, the executed source code is highlighted; otherwise, no highlighting is performed (using...). Figure 1 (The source code on the right side of the C section is displayed);

[0039]

[0040]

[0041]

[0042] In the above formula: Nep indicates that the test case executing the relevant statement passed; Nef indicates that the test case executing the relevant statement failed; Nnp indicates that the test case without executing the relevant statement passed; N nf represents the test case that failed without executing the relevant statement; Np represents the set of test cases that passed with executing the relevant statement and test cases that passed without executing the relevant statement; Nf represents the set of test cases that failed with executing the relevant statement and test cases that failed without executing the relevant statement.

[0043] Step 3: Then, by demonstrating the execution process of a single test case, we help users understand the specific running process of the program, analyze when the program produces unexpected results, and determine the actual location of the fault. This is mainly achieved by using GDB (GNU symbolic debugger, used for debugging C / C++ programs) to obtain intermediate results of program execution.

[0044] Step 4: Based on the function of providing program modification and viewing code modification history, after the operation in Step 3, it is necessary to determine whether the fault location is accurate. The system allows users to modify the fault location and re-execute the program to check whether the current fault location is accurate. The specific steps are as follows:

[0045] 4-1. Users can directly modify the code in the source code view and re-execute all test cases based on the modified code (using...). Figure 1 (Displayed in section C). When test cases are re-executed, the code information before and after the modification can be compared, and the specific content of the modification can be recorded. The specific content of the modification is displayed in the code modification history view, and the specific content mainly includes the line number of the modified code and the modified information data (using...). Figure 1 (Displaying part B),

[0046] 4-2. Determine whether the test case execution passes. If the test case execution passes, it indicates that the fault has been located and repaired. If the execution fails, the system will record the modification location and allow the user to repeat steps 1-4 to locate the fault.

[0047] like Figure 4 As shown, preferably, to facilitate the processing of intermediate result data, the specific steps for obtaining the intermediate results of program execution using GDB in step 3 are as follows:

[0048] 3-1. Obtain the variable names and types related to each step of the test case execution; first, input a macro command into GDB containing only a `next` statement, allowing the program to automatically step to the end of the program; when the program executes, use the relevant GDB commands: `info variables`, `info locals`, and `info...` The `args` function retrieves information about global variables, local variables, and function parameters in the current statement (this step is to obtain statement variable names and types; each line of code contains the three types of variables mentioned above, and all variable names and types can be obtained using the three commands mentioned earlier). These three commands supplement the proposed macro command, which allows the program to sequentially obtain the names of all current variables at each step of execution. After executing the macro command, its output file is parsed, and the text is normalized to obtain detailed information about the executed statements, the names of current statement variables, and their types. For example, in the current line of code, `a = b * c`, we need to obtain the content of the currently executed statement, i.e., `a = b * c`, as well as the variables contained in the current line of code: `a`, `b`, and `c`, and the type of each variable, such as `a` being of type `int` and `b` being of type `float`. The purpose of obtaining this data is as follows: the content of the executed statement is to demonstrate the actual execution process of the test case, and obtaining the variable names is for subsequent use of GDB commands to obtain the specific results of each variable. By obtaining the variable type, we can determine whether the current variable is a pointer type, and thus decide which GDB command to use. For non-pointer type variables, we use the print command, and for pointer type variables, we use the print* command.

[0049] 3-2. Use the `print` and `display` statements to let GDB display the specific values ​​of variables. For pointer variables, you need to further use `print*` to get their specific values. Then, edit a new macro command. This macro command mainly includes two aspects: the first aspect is the `print`, `print*`, and `display` statements, which are used to get the specific values ​​of variables after each single step of execution; the second aspect is the `next` statement, which helps the program automatically step to the end. After GDB executes the new macro command, finally parse its output file to get the specific values ​​of variables after each step of the test case execution.

[0050] 3-3 Finally, by analyzing the source code, we find the statement information contained in each function, the calling relationship between different functions, and the variable passing relationship when calling these functions. Based on this information, we judge the code during program execution, analyze the environment variables, functions, and code context of each statement, judge the variable relationship between different statements, determine whether the variables between different statements are the same, merge the same variables, and obtain the statement location where the variable is changed.

[0051] This embodiment also sets up a specific data display box for each executed statement, such as... Figure 1 As shown in Part E, green rectangles are drawn to the left of code statements to display the function they belong to and related information, such as function parameters and function name, used to display all functions executed. During program execution, variable values ​​are constantly changing; this is addressed using a variable information view (using...). Figure 1 The F section (displayed in the middle) shows all the variable names and corresponding values ​​contained in each statement during function execution. The variable information view will display the corresponding information based on the statement selected by the user. However, during fault localization, users often focus more on changes in individual variables; therefore, the system draws a new view to display information about specific variables (using...). Figure 1 (The G section will be used for demonstration). This view can display all values ​​of a specific variable from the start to the end of program execution. Furthermore, we also display specific variables within the specific steps of program execution; if the currently executed statement contains the variable, we will draw a square (using...) to the left of the statement. Figure 1 (The red and green squares on the left of section E in the diagram are used to illustrate this.) Red indicates that the variable has changed during the execution of this statement, while green indicates that it has not changed, thus showing the specific value of the variable at each step of program execution. During function calls, variable passing information is often generated; we use a node link graph (using...) Figure 1 The view uses part D of the graph to display the static function call relationships and uses the Dagre algorithm for layout. By editing the edges and nodes of the node link graph, it displays the function's parameter information and variable information during function calls. Simultaneously, this view highlights the user-selected single variable, comprising two parts: drawing a new view to display the variable's specific value; and drawing a square in the function execution view to indicate whether the variable has changed.

[0052] Preferably, for ease of viewing, in step 1, higher transparency indicates fewer statement executions in the current test case, and red indicates that the execution result of the current test case does not meet expectations, while green indicates the opposite, indicating that the execution result of the current test case meets expectations.

[0053] Preferably, to further improve the clarity of data display, in step 1, the rectangle can be used to display relevant information for each test case, or it can be used to display relevant information for a test case that executes a certain statement.

[0054] As a preferred option, to further improve the speed at which users find faults, in step 2, the highlighted source code will be changed according to the test cases in step 1. Specifically, when the user selects different test cases, the system will highlight the code actually executed by the current test case, and the yellow highlighted parts mentioned above will be re-rendered. For example, if the current test case executes lines 1, 2, 3, and 4 of the code, the system will highlight lines 1, 2, 3, and 4 with a green background. If the reselected test case executes lines 1, 2, 5, and 6, the system will only highlight lines 1, 2, 5, and 6 with a green background.

[0055] Meanwhile, in the display view, if a statement is not executed, it indicates that the error is unrelated to these statements. In this case, through the test cases in step 1, users only need to view the relevant highlighted source code statements to find the problem that occurred in the test, which greatly narrows the scope of the fault finding. The statement suspicion level can help users optimize the search order. By setting the statement with a higher suspicion level, the possibility of the fault occurring is greater, which can effectively improve the speed of the user's fault finding.

[0056] The advantages of this invention are as follows:

[0057] First point: Based on the test cases in step 1, obtain relevant information during the target software testing process by executing all test cases of the program, and use the rectangular data acquisition method to display the execution information of the test cases, using different colors and transparency to highlight to help users quickly select the appropriate test cases;

[0058] Secondly, by demonstrating the suspicion level of statements and the actual execution statements of test cases in step 2, the actual scope of fault analysis can be reduced, and the fault can be located precisely to a small number of lines of code.

[0059] Thirdly, step 3 demonstrates the execution process of a single test case, which helps users analyze the actual execution steps of the program, view the changes in variables during execution, and track suspicious variables. At the same time, the function hierarchy highlighting and call information can more quickly find the transmission information of suspicious variables, effectively improve the analysis of variable values, find the location where the variable generates errors, and determine the actual location of the failure.

[0060] Fourthly, by modifying the source code and recording the modification history in step 4, users can effectively fix program malfunctions.

[0061] Therefore, the demonstration of the entire testing process of this invention can effectively reduce the repetitive steps of users constantly setting breakpoints and running programs when locating faults. This invention helps users locate faults, and by demonstrating the intermediate process of program execution, we effectively improve the efficiency of fault location.

[0062] To improve the efficiency of fault location for programmers, an experiment was conducted. Twenty volunteers (12 men and 8 women) were recruited, all currently studying computer science and software engineering. They had four to seven years of learning experience (average 5.35 years) and all had C / C++ programming experience. To ensure the accuracy of the experiment, participants were interviewed beforehand to ensure they had not been exposed to content relevant to the experiment. The volunteers were divided into four groups (G1, G2, G3, and G4), with three men and two women in each group. The experiment involved repairing two different programs, each with only one error. Groups G1 and G3 followed the same experimental protocol, as did groups G2 and G4. Groups G1 and G2 used existing fault location methods, such as traditional methods (program logs, assertions, breakpoints, profiling) and advanced fault location methods (program spectrum-based techniques, etc.), while groups G3 and G4 used the method of this invention for fault location. The experiment ended when volunteers completed the repair of two programs or reached 3 hours of experimental time. The standard for program repair completion was that the output of all test cases matched expectations. To minimize the influence of other factors, all volunteers received relevant training before the experiment. Volunteers in groups G1 and G2 were shown how to execute test cases against the program. However, volunteers needed to write additional code to execute test cases during the experiment. To eliminate the influence of this factor, we provided code for automatically executing test cases, as well as code for automatically calculating coverage and skepticism. This is calculated automatically when users execute test cases to ensure that users do not spend more time calling these functions. For volunteers in groups G3 and G4, we showed them how to visualize the system using the method of this invention before the experiment and explained the information presented in each view. To eliminate the influence of environmental factors, the four experiments were scheduled on four different afternoons, from 14:00 to 17:00, at the same location and computer.

[0063] In the lab, we had staff record the time each volunteer spent repairing each program, and the results were as follows: Figure 2 As shown. Twenty volunteers from four groups completed the task, all finding and fixing the fault within the allotted time. Due to different experimental procedures, the experimental times varied among the groups. However, the experimental times for G3 and G4 using the method of this invention were significantly shorter than those for G1 and G2, respectively. Figure 2 G3 is approximately 24% more efficient than G1. Compared to G2, G4 is about 26% more efficient. Further analysis shows that the longer the repair process requires, the higher the efficiency of the method of this invention. Figure 3 ,in Figure 3In the four groups of bars at the bottom center, the leftmost bar in each group corresponds to the existing fault location method, and the rightmost bar corresponds to the method of this invention. The curve at the top corresponds to the existing slice-based technology. G1 and G3 have the lowest average first program time, with the efficiency improvement of the method of this invention being less than 20%. G2 and G4 have the longest average first programming time, with the efficiency improvement of the method of this invention exceeding 28%.

[0064] Finally, it should be noted that the above embodiments are merely illustrative of the technical solutions of the present invention and not intended to limit it. Those skilled in the art can, through their understanding of the present invention, modify and extend its form or details without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A visual analysis method for fault location, characterized in that, Specifically, the following steps are included: Step 1: Provide an overview of the test cases, displaying the execution results of each test case and the number of lines of code executed for each test case. Specifically, by executing all test cases of the program, relevant information during the target software testing process is obtained. After obtaining the test case execution information, the relevant information is displayed using rectangles. Within a rectangle, the transparency is used to indicate the number of times the current test case statement is executed. Different colors are used to indicate whether the test cases are executed as expected; The relevant information includes: the result of each test case, the number of times the statement was executed and the relevant lines of code executed, the test coverage of each statement and the test cases executed; Step 2: Based on the following existing statement suspicion formulas, calculate the suspicion level of each statement and combine it with the test coverage of each statement. Display the statement suspicion level and execution status to help users quickly find highly suspicious statements. During the display, test coverage and statement suspicion level are marked using rectangles of varying lengths, allowing for the display of the corresponding suspicion level based on different formulas. Source code is highlighted to indicate whether the current code has been executed. If the current code has been executed, the executed source code is highlighted; otherwise, no highlighting is performed. （1） （2） （3） In the above formula: This indicates that the test case executing the relevant statements has passed; This indicates that the test case executing the relevant statements failed; This indicates that the test case, in which the relevant statements were not executed, passed. This indicates that the test case failed because the relevant statements were not executed. This represents the set of test cases that passed when the relevant statements were executed and the set of test cases that passed when the relevant statements were not executed. This represents the set of test cases that failed to execute the relevant statements and test cases that failed without executing the relevant statements; Step 3: Then, by demonstrating the execution process of a single test case, we help users understand the specific running process of the program, analyze when the program produces unexpected results, and determine the actual location of the fault. This is mainly achieved by using GDB to obtain the intermediate results of the program execution. Step 4: Based on the function of providing program modification and viewing code modification history, after the operation in Step 3, it is necessary to determine whether the fault location is accurate. The system allows users to modify the fault location and re-execute the program to check whether the current fault location is accurate. The specific steps are as follows: 4-1. Users can directly modify the code in the source code view and re-execute all test cases based on the modified code. When re-executing the test cases, the code information before and after the modification can be compared, and the specific content of the modification can be recorded. The specific content of the modification is displayed in the code modification history view, and the specific content mainly includes the line number of the modified code and the modified information data. 4-2. Determine whether the test case execution passes. If the test case execution passes, it indicates that the fault has been located and repaired. If the execution fails, the system will record the modification location and allow the user to repeat steps 1-4 to locate the fault.

2. The visual analysis method for fault location according to claim 1, characterized in that: The specific steps for obtaining the intermediate results of program execution using GDB in step 3 are as follows: 3-1. Obtain the variable names and types related to each step of the test case execution; First, input a macro command into GDB, which contains only a next statement, allowing the program to automatically step to the end of the program; When the program executes, obtain the relevant information of global variables, local variables, and function parameters in the current statement by using the relevant GDB commands: info variables, info locals, and info args; Use these three commands to supplement the proposed macro command, which allows the program to obtain the names of all current variables in sequence at each step of execution; After executing the macro command, parse its output file, and obtain detailed information of the program's executed statements, the variable names of the current statements, and the variable types by normalizing the text. 3-2. Use the print and display statements to let GDB show the specific values ​​of variables. For pointer variables, further processing is required. To obtain its specific value, a new macro command is then edited. This macro command mainly includes two aspects: the first aspect is print, The first aspect is the `display` statement, used to obtain the specific value of the variable after each single-step execution; the second aspect is the `next` statement, used to help the program automatically step to the end; after GDB executes the new macro command, it finally parses its output file to obtain the specific value of the variable after each step of the test case execution; 3-3 Finally, by analyzing the source code, we find the statement information contained in each function, the calling relationship between different functions, and the variable passing relationship when calling these functions. Based on this information, we judge the code during program execution, analyze the environment variables, functions, and code context of each statement, judge the variable relationship between different statements, determine whether the variables between different statements are the same, then merge the same variables, and obtain the statement location where the variable is changed.

3. The visual analysis method for fault location according to claim 1, characterized in that: In step 1, higher transparency indicates fewer statement executions in the current test case, and red indicates that the current test case execution result does not meet expectations, while green indicates the opposite, indicating that the current test case execution result meets expectations.

4. The visual analysis method for fault location according to claim 1, characterized in that: In step 1, the rectangle can be used to display information about each test case, or it can be used to display information about a test case that executes a specific statement.

5. The visual analysis method for fault location according to claim 1, characterized in that: In step 2, the highlighted source code will be modified according to the test cases in step 1. At the same time, in the display view, if a statement is not executed, it indicates that the error is not related to these statements. At this time, by using the test cases in step 1, the user only needs to view the relevant highlighted source code statements to find the problem that occurred in the test, which greatly narrows the scope of the fault finding. The statement suspicion level can help the user optimize the search order. By setting the statement with a higher suspicion level, the statement is more likely to have a fault, which can effectively improve the speed of the user's fault finding.

6. The visual analysis method for fault location according to claim 1, characterized in that: In step 1, different colors are used to indicate whether the test case execution meets expectations. Specifically, a red box indicates a test case execution error and a green box indicates a test case execution success.

Images