JP7562483B2 - Apparatus and method for assisting in identifying defective parts - Google Patents

Description

The present invention relates to a technology that assists in identifying defects in source files.

In software development, when a program malfunctions (behavior different from what the developer intended), the cause of the malfunction must be identified and the program must be modified so that the malfunction does not occur again. The cause of a program malfunction is called a defect (fault, bug). The process of identifying the part of the program source file that contains the malfunction and rewriting that part to remove the malfunction is called debugging. As debugging is one of the most time-consuming parts of the software development process, debugging support technologies are being developed to shorten the development process. Automated technology for extracting the cause of the malfunction is one such example.

The technique that has been most actively researched in recent years for automating fault location extraction is Spectrum-Based Fault Localization (SBFL), which uses information about the execution path in a source file (source code) by test cases to automatically extract the fault location. SBFL is a technique for extracting the fault location based on the idea that, among the lines in a source file, lines executed in a failing test case are likely to be the fault location, and lines executed in a successful test case are unlikely to be the fault location. SBFL uses information about how many times each line was executed in failing and successful test cases to calculate a value (hereinafter referred to as the "suspicion value") that indicates the likelihood that the line is the fault location.

In SBFL, suspicion values are assigned based only on the execution path (the executed line) when the test case is executed and information about the success or failure of the test. This means that there are many lines with the same suspicion value in multiple statements in a source file, and it is not possible to rank them, making it difficult to narrow down the location of the problem.

Figure 1 shows an example where a large number of suspected equivalent values occur as a result of using SBFL. Specifically, in the source code in Figure 1, the command statement L48 marked with a circle is the defective part, but the same suspect value of 0.6 is assigned to L45 to L49. In this case, there is no difference in ranking from L45 to L49, making it difficult to narrow down the defective part.

To address the problem with SBFL, Patent Document 1 discloses a technology that helps narrow down the problem areas when a large number of suspected equivalent values occur in SBFL. Specifically, the suspicion value calculated by SBFL is corrected to be higher for source files with a large number of violations based on the number of violations of code conventions.

JP 2021-005171 A

Another problem with SBFL is that defective areas with a high rate of successful testing have a lower suspicion value than non-defective areas, resulting in defects being missed.

Figure 2 shows an example of the results of using SBFL where the suspicion value of a defective part is smaller than the suspicion value of a non-defective part. Specifically, in the source code in Figure 2, the command statements L83 and L86 marked with a circle are defective parts, but the command statement L86 is assigned a suspicion value of 0.3, which is smaller than the suspicion value of 0.7 of the non-defective parts L81 and L82, and the ranking of L86 is lower than the rankings of L81 and L82.

In the technology described in Patent Document 1, the same suspicion value calculated by SBFL is ranked based on additional information, namely the number of violations of code rules. However, it is not possible to assign a high suspicion value to a defect that originally has a low suspicion value, and the relevant defect cannot be extracted as a high-ranking defect.

The main objective of the present invention is to assist developers in identifying defective areas and to make debugging more efficient by assigning appropriate suspicion values to defective areas.

A preferred aspect of the present invention is a defect location identification support device, characterized by comprising: a source file relevance acquisition unit that acquires source file relevance information that indicates the relevance between each command statement in a source file; test execution information that holds the execution results of a test case; test result starting point suspicious value information that holds a suspicious value calculated based on the number of times each command statement in the source file is executed when the test case is executed; and a suspicious value reassignment unit that calculates a suspicious value using the source file relevance information and generates recalculated suspicious value information.

Another preferred aspect of the present invention is a defect location identification support method for identifying defect locations in a source file using an information processing device, which uses source file relevance information including relevance information between each command statement in the source file, test execution information including information on where an exception occurs when a test file is executed, and test result origin suspicious value information in which a suspicious value generated by the SBFL method is assigned to a command statement in the source file, and the source file relevance information is used to extract a command statement that is highly related to the command statement corresponding to the exception occurrence location information, and assigns a suspicious value to the extracted command statement that is higher than the suspicious value assigned by the test result origin suspicious value information.

According to the present invention, by assigning an appropriate suspicion value to a defective part, it is possible to assist a developer in identifying the defective part and to make the debugging process more efficient.

FIG. 13 is a table showing an example in which suspected-equivalence values are assigned to a plurality of statements. 13 is a table showing an example in which a suspected defect value is assigned smaller than a suspected non-defective defect value. 1 is a block diagram showing an example of a hardware configuration of a defect point identification support device according to an embodiment of the present invention. 1 is a block diagram showing an example of a functional configuration of a defect point identification support device according to an embodiment of the present invention; FIG. 4 is a list diagram showing an example of a source file group according to the embodiment of the present invention. FIG. 11 is a list diagram showing an example of a test file group in the embodiment of the present invention. FIG. 11 is a table showing an example of test execution information according to an embodiment of the present invention. FIG. 11 is a table showing an example of test result starting suspicious value information in an embodiment of the present invention. 11 is a table showing an example of intra-source file correlation information in the embodiment of the present invention. FIG. FIG. 11 is a table showing an example of malfunction possibility information in the embodiment of the present invention. FIG. 13 is a table showing an example of recalculated suspicious value information in an embodiment of the present invention. FIG. 4 is a flowchart of a defect location identification support process according to an embodiment of the present invention. FIG. 11 is a flowchart of a suspicious value assignment process according to an embodiment of the present invention.

The following describes the embodiments with reference to the drawings. In the following description, identical or similar components are designated by the same reference numerals, and duplicate descriptions may be omitted.

The present invention should not be interpreted as being limited to the description of the embodiments shown below. Those skilled in the art will easily understand that the specific configuration can be changed without departing from the concept or spirit of the present invention.

When there are multiple elements with the same or similar functions, they may be described using the same reference numerals with different subscripts. However, when there is no need to distinguish between multiple elements, the subscripts may be omitted.

The designations "first," "second," "third," and the like in this specification are used to identify components and do not necessarily limit the number, order, or content. Furthermore, numbers for identifying components are used in different contexts, and a number used in one context does not necessarily indicate the same configuration in another context. Furthermore, this does not prevent a component identified by a certain number from also serving the function of a component identified by another number.

The position, size, shape, range, etc. of each component shown in the drawings, etc. may not represent the actual position, size, shape, range, etc., in order to facilitate understanding of the invention. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings, etc.

The publications, patents and patent applications cited herein are incorporated by reference in their entirety into the present specification.

In this specification, elements expressed in the singular include the plural unless the context clearly indicates otherwise.

In the embodiment described below, the main objective is to improve the efficiency of debugging work by developers, for example by appropriately assigning suspicion values to defect locations that are overlooked by SBFL. To this end, a defect location identification support device in one embodiment includes an intra-source file relevance acquisition unit that uses source files to extract intra-source file relevance information, and a suspicion value reassignment unit that calculates and assigns suspicion values using test execution information, test result starting point suspicion value information, and the intra-source file relevance information. More detailed means will be described later.

Figure 3 shows an example of the hardware configuration of the defect location identification support device 100. The defect location identification support device 100 includes a processor 110, a main memory device 120, an auxiliary memory device 130, an input device 140, an output device 150, and a communication device 160. These are connected to each other so that they can communicate with each other via a communication means such as a bus (not shown).

The processor 110 is configured using, for example, a CPU (Central Processing Unit) or an MPU (Micro Processing Unit). The processor 110 reads and executes a program stored in the main memory device 120, thereby realizing various functions of the defect location identification support device 100.

The main memory device 120 is a device that stores programs and data, and is, for example, a read only memory (ROM), a random access memory (RAM), or a non-volatile semiconductor memory (NVRAM (Non Volatile RAM)).

The auxiliary storage device 130 is, for example, a hard disk drive, an SSD (SolID State Drive), an optical storage device (CD (Compact Disc), DVD (Digital Versatile Disc), etc.), a storage system, an IC card, a read/write device for recording media such as an SD memory card or optical recording media, a storage area of a cloud server, etc. The programs and data stored in the auxiliary storage device 130 are loaded into the main storage device 120 as needed.

The input device 140 is, for example, a keyboard, a mouse, a touch panel, a card reader, a voice input device, etc. The output device 150 is a user interface that provides the user with various information such as the process progress and the processing results, and is, for example, a screen display device (liquid crystal monitor, LCD (Liquid Crystal Display), graphics card, etc.), a voice output device (speaker, etc.), a printer, etc. For example, the defect location identification support device 100 may be configured to input and output information between it and other devices via the communication device 160.

The communication device 160 is a wired or wireless communication interface that realizes communication with other devices via a communication means such as a LAN or the Internet, and is, for example, a NIC (Network Interface Card), a wireless communication module, a USB (Universal Serial Bus) module, a serial communication module, etc.

The hardware configuration of the defect location identification support device 100 may be configured as a stand-alone computer, or any part may be configured as another computer connected via a network.

Here, we will define the terms used in this embodiment. A "source file" is a program that is the subject of software development, and may contain defects that cause behavior different from that intended by the developer. A "statement" is a program statement that constitutes a source file. A "test file" is a file that stores a program that checks the behavior of source code. A "test method" is a program that checks the behavior of a single method by dividing test code into units of integrated processing. Test code includes one or more test methods. A "method" is a subroutine that inputs data called arguments and obtains an output called a return value.

Figure 4 is a diagram showing an example of the functional configuration of a defect location identification support device. The defect location identification support device 100 includes the following functional units: a source file correlation acquisition unit 210, a defect possibility determination unit 220, and a suspicion value reassignment unit 230. The processing executed by these functional units will be described later with reference to the flowchart in Figure 12.

The source file correlation acquisition unit 210, defect possibility determination unit 220, and suspicion value reassignment unit 230 are configured by the processor 110 in FIG. 3 executing the defect location identification support program stored in the main memory device 120.

The information storage unit 240 is mainly composed of the auxiliary storage device 130 in FIG. 3. The information storage unit 240 stores a source file group 241, a test file group 242, test execution information 243, test result starting point suspicious value information 244, intra-source file correlation information 245, defect possibility information 246, and recalculated suspicious value information 247. Details of the various information in the information storage unit 290 will be described later with reference to FIGS. 5 to 11.

Figure 5 is a diagram showing an example of a source file group 241. The source file group 241 includes one or more source folders 510. The source folder 510 has the folder name core. The source folder 510 includes one or more source files 520. The source file 520 has the file name CreateCore. The source file 520 includes one or more lines of source code, and Figure 5 shows an example of 17 lines. The source file 520 includes a method named create in lines 1 to 17.

The source folder may contain one or more other source folders. The source code may be in a programming language such as Java (registered trademark) or C++, or any other programming language.

The defect in source file 520 is that the method "createData" is called on lines 5 and 7, but if we assume that the method "createDate" should actually be called, then the statements on lines 5 and 7 can be considered to be the defective parts.

Figure 6 is a diagram showing an example of a test file group 242. The test file group 242 includes one or more test folders 610. The test folder 610 has the folder name coretest. The test folder 610 includes one or more test files 620. The test file 620 has the file name CreateCoreTest.

Test file 620 includes one or more lines of test code; FIG. 6 shows an example of 23 lines. Test file 620 includes a test method named testCreate1 on lines 1 to 5, a test method named testCreate2 on lines 7 to 11, a test method named testCreate3 on lines 13 to 17, and a test method named testCreate4 on lines 19 to 23. Test methods testCreate1, testCreate2, testCreate3, and testCreate4 are all test methods corresponding to the method create included in source file 520 in FIG. 5.

Figure 7 is a diagram showing an example of test execution information 243 used in the SBFL technique. The test execution information 243 can be generated from a log of the results of executing the test file 620, and includes one or more entries. An entry of the test execution information 243 includes columns for the success or failure result when the test file is executed, and information on the location where an exception occurred in the case of failure. The information on the location where an exception occurred corresponds to information output as a stack trace during test execution, for example. The stack trace indicates which processes were called and in what order when an exception occurred.

The example in Figure 7 shows test execution information when the test file 620 in Figure 6 is executed. In the example in Figure 7, each column includes the test method name, execution result, exception type in case of failure, and information about the location where the exception occurred in case of failure. The information about the location where the exception occurred includes the folder name, file name, and line number.

Figure 7 shows that the test method "testCreate2" has failed, causing an AssertionError. It also shows that the statement on line 5 of the source file "CreateCore" shown in Figure 5 is being processed when the AssertionError occurs. It also shows that the method "create", which contains the statement on line 5 of the source file "CreateCore", is being called by the statement on line 9 of the test file "CreateCoreTest" in Figure 6.

Figure 8 is a diagram showing an example of test result origin suspicious value information 244. Test result origin suspicious value information 244 is generated in advance after execution of test file 620 by conventional SBFL techniques. Test result origin suspicious value information 244 includes one or more entries. An entry of test result origin suspicious value information 244 includes columns for the target source folder name, the target source file name, the line number of the target statement, and the suspicious value of the target statement.

The suspicion value is calculated using information on how many times each statement in the source file was executed in failing test methods and passing test methods. The suspicion value may be modified using the technology of Patent Document 1, for example. Figure 8 shows test result origin suspicion value information generated for the source file shown in Figure 5 when the test code in Figure 6 is executed.

In the test result starting suspicion value information shown in Figure 8, the command statement on line 5, which is the defective part of the source file "CreateCore" shown in Figure 5, is assigned a suspicion value of 1.0, and the command statement on line 7 is assigned a suspicion value of 0.0. In particular, the command statement on line 7 has a lower suspicion value than the other command statements that are not defective.

Figure 9 is a diagram showing an example of intra-source-file relevance information 245. The intra-source-file relevance acquisition unit 210 uses a source file as input to generate intra-source-file relevance information 245. In addition, the intra-source-file relevance information 245 may also use defect possibility information 246 as input.

The source file relevance information 245 includes one or more entries. An entry of the source file relevance information 245 includes columns for the source file name including the original statement to be compared, the line number of the original statement to be compared, the source file name including the related statement, the line number of the related statement, and the relevance to the original statement to be compared. Types of relevance include similar statements, used variable setting statements, etc. The source file including the original statement to be compared and the source file including the related statement may be the same or different.

Details about the generation of the source file relevance information 245 by the source file relevance acquisition unit 210 are shown in S1210 of FIG. 12 and will be described later.

Figure 10 is a diagram showing an example of defect possibility information 246. The defect possibility determination unit 220 receives the source file, the test execution information 243, and the test result starting point suspicious value information 244 as input, determines the defect possibility of each command statement in the source file, and generates defect possibility information 246.

The malfunction possibility information 246 includes one or more entries. An entry of the malfunction possibility information 246 includes columns for the source file name, the line number, the malfunction possibility value, and the reason for setting the malfunction possibility value. The malfunction possibility value may be indicated by a level as in FIG. 10, or may be indicated by a quantitative value. Details of the generation of the malfunction possibility information 246 by the malfunction possibility determination unit 220 are shown in S1220 of FIG. 12 and will be described later.

Figure 11 is a diagram showing an example of recalculated suspicious value information 247. The suspicious value reassignment unit 230 receives as input a source file group 241, test execution information 243, test result starting suspicious value information 244, and intra-source file correlation information 245, and generates recalculated suspicious value information 247. The suspicious value reassignment unit 230 may also receive as input fault possibility information 246.

The recalculated suspicious value information 247 includes one or more entries. An entry of the recalculated suspicious value information 247 includes columns for the target folder name, the target source file name, the line number of the target command statement, and the suspicious value of the target command statement. In addition, if there has been a change in the suspicious value from the test result starting suspicious value information 244, the entry of the recalculated suspicious value information 247 may also include columns for the suspicious value change content and the suspicious value change reason. Details of the generation of the recalculated suspicious value information 247 by the suspicious value reassignment unit 230 are shown in S1230 of FIG. 12.

Figure 12 is a flowchart explaining the process performed by the defect location identification support device 100 (hereinafter referred to as defect location identification support process 1200). The defect location identification support process 1200 will be explained below with reference to Figure 12. Note that the defect location identification support device 100 starts the defect location identification support process 1200, for example, in response to an instruction from a user. Also, the defect location identification support device 100 starts the defect location identification support process 1200 automatically, for example, by batch processing at a scheduled timing. In the following, the letter "S" before the reference symbol indicates a processing step.

First, the source file relevance acquisition unit 210 reads the source file group 241 stored in the information storage unit 240, extracts the relevance of each command statement in the source file 520 to other command statements, and generates source file relevance information 245 (S1210).

The types of relationships that can be extracted include similar command statements, used variable setting command statements, etc. The extraction of similar command statements and used variable setting commands will be explained using the source file 520 shown in FIG. 5. Note that FIG. 9 shows the source file relationship information 245 that is generated by the source file relationship acquisition unit 210 using the source file in FIG. 5 as input.

First, we will explain how to extract similar command statements. Similar command statements can be determined by the degree to which the command statements contain elements in common. To determine whether a command statement is similar, for example, the number of types of tokens (variable names, method names, etc.) contained in the command statements is used to calculate the number of tokens common to the tokens contained in the source command statement and the tokens contained in the target command statement. If the difference between the number of common tokens and the number of tokens contained in the target command statement is below a preset threshold, the command statements are determined to be similar.

In the example of obtaining the intra-source file relevance information in FIG. 9, the threshold value of the difference between the number of common tokens and the number of tokens contained in the comparison target command statement when searching for similar commands is set to 1. In the source file 520 in FIG. 5, the tokens contained in the command statement on the fifth line, which is the comparison source command statement, are (String, result, createData, str, name), and the tokens of the command statement on the seventh line, which is the comparison target command statement, are (String, result, createData, name), and the number of common tokens between the comparison source command statement and the comparison target command statement is 4. The difference between the number of common tokens and the number of tokens contained in the comparison target command statement is |4-5|=1, which is less than the threshold value of 1, so the command statement on the seventh line, which is the comparison target command statement, is determined to be a similar command statement to the command statement on the fifth line, which is the comparison source command statement. Therefore, the intra-source file relevance information 245 shown in FIG. 9 indicates that the seventh line of the CreateCore file corresponds to a command statement similar to the fifth line of the comparison source command statement, which is the comparison source command statement.

The difference threshold can be set arbitrarily, and in addition to judging based on the difference, it can also be judged based on the ratio of the number of common tokens among the tokens contained in the compared command statements.

Next, we will explain how to extract used variable setting statements. A used variable setting statement is a statement that assigns a value to a variable used in the comparison source statement. For example, if the comparison source statement contains a method call statement, used variable setting statements are identified by using syntax tree analysis to search for the statement that most recently assigned a value to the variable used as an argument in the method call.

Here, in source file 520 in FIG. 5, the statement that most recently assigned a value to the argument "name" in the method call "createData(str, name)" on line 5, which is the source statement, is "String name = tmp.get("data");" on line 3, so the statement on line 3 is determined to be the variable setting statement for the statement on line 5. Therefore, the intra-source file relevance information shown in FIG. 9 indicates that line 3 of the CreateCore file corresponds to the variable setting location on line 5 of the source statement.

In this way, statements that define, assign, or use the same parameter are likely to be interrelated, and may cause common problems.

Next, the defect possibility determination unit 220 reads the source file 520, the test execution information 243, and the test result starting point suspicious value information 244, determines the defect possibility of each command statement in the source file, and generates defect possibility information 246 (S1220). At this time, since the source file group 241 usually includes multiple source files, for example, the source files are called up one by one and a defect is determined for each source file to be determined.

The determination of the possibility of a malfunction for a statement in a source file will be explained using the source file shown in FIG. 5, the test execution information shown in FIG. 7, and the test result starting point suspicious value information shown in FIG. 8. Note that the malfunction possibility information 246 shown in FIG. 10 indicates the malfunction possibility information generated by the malfunction possibility determination unit 220 using the source file 520 shown in FIG. 5, the test execution information 243 shown in FIG. 7, and the test result starting point suspicious value information 244 shown in FIG. 8 as input.

For example, the malfunction possibility determination unit 220 determines that the command statement of the source file indicated in the exception occurrence location information of the test execution information 243 is highly likely to be malfunctioning because it was called when the exception occurred, and assigns information indicating a high malfunction possibility. In the example of the test execution information 243 in FIG. 7, the command statement on the fifth line indicates that the source file "CreateCore" shown in FIG. 5 is called when the exception occurred. Therefore, in FIG. 10, the malfunction possibility value for the fifth line of the source file "CreateCore" is set to "high". In addition, the reason for the "high malfunction possibility" is indicated as "exception occurrence location".

In addition, the defect possibility determination unit 220 determines that the instruction statement with the highest suspicion value indicated in the test result starting point suspicion value information 244 has a high probability of being defective because it tends to be executed in failing tests and tends not to be executed in passing tests. This is processing based on the conventional SBFL principle.

The example of test result origin suspicion value information 244 in Figure 8 shows that for the source file "CreateCore" shown in Figure 5, the command statements on lines 3, 4, and 5 have been assigned a maximum suspicion value of 1.0. Therefore, in Figure 10, the malfunction possibility value is set to "high" for lines 3, 4, and 5 of the source file "CreateCore". In addition, the reason for determining that lines 3 and 4 of "CreateCore" have a "high" malfunction possibility is shown to be that they are the "locations with the highest test-induced suspicion value."

Here, in the case where the location of the highest test suspected value and the location where an exception occurred overlap, as in the fifth line of the source file "CreateCore", it is acceptable to indicate either the reason for determining the possibility of a malfunction for both, or the reason for determining the possibility of a malfunction for only one of them, as in Figure 10.

The defect possibility determination unit 220 also extracts specific types of instructions in the source file that are not related to defects, and adds information indicating that the defect possibility is low. For example, it determines that a debug command in the source file has a low defect possibility because it is not related to the test execution results. In the example source file in FIG. 5, the command "System.err.println(e.getMessage());" in lines 11 and 14 indicates standard error output, and the command "e.printStackTrace();" in lines 12 and 15 indicates output to a stack trace, and are both debug commands. Therefore, in FIG. 10, the defect possibility values for lines 11, 12, 14, and 15 of the source file "CreateCore" are set to "low". Also, the reason for determining the defect possibility as "low" is indicated as "debug command".

Here, regarding the order of the processing steps of the defect location identification support process 1200, the order of execution of the source file relation acquisition unit 210 (S1210) and the processing of the defect possibility determination unit 220 (S1220) may be reversed. In other words, it is sufficient if both are prepared before S1230.

When the defect possibility determination unit 220 is executed first, the source file relation acquisition unit 210, which is executed later, may read the defect possibility information 246 as an input together with the source file. When the source file relation acquisition unit 210 reads the defect possibility information 246, only the parts indicated as having a "high" defect possibility in the defect possibility information 246 may be used as the comparison source command statements to extract related command statement information.

Next, the suspicion value reassignment unit 230 calculates the suspicion value using the test execution information 243, the test result starting point suspicion value information 244, the intra-source file relevance information 245, and the defect possibility information 246, and generates recalculated suspicion value information 247 (S1230).

Figure 13 is a flowchart explaining the process performed by the suspicious value reassignment unit 230 (hereinafter referred to as suspicious value reassignment process 1300). Hereinafter, the suspicious value reassignment process 1300 for generating the recalculated suspicious value information shown in Figure 11 will be explained with reference to Figure 13. Note that the recalculated suspicious value information shown in Figure 11 represents the result of reassigning suspicious values for the source file shown in Figure 5 using the test execution information shown in Figure 7, the test result starting suspicious value information shown in Figure 8, the source file correlation information shown in Figure 9, and the defect possibility information shown in Figure 10. In addition, the suspicious value reassignment unit 230 automatically starts the suspicious value reassignment process 1300 by batch processing or the like at a scheduled timing, for example.

First, the suspicious value reassignment unit 230 generates the original data of the recalculated suspicious value information 247 by referring to the information of the test result starting suspicious value information 244 (S1310). Specifically, for example, data in which a column of suspicious value change content and a column of suspicious value change reason are added to the entry of the test result starting suspicious value information 244 shown in FIG. 8 is used as the original data of the recalculated suspicious value information 247.

Next, the suspicion value reassignment unit 230 assigns a suspicion value to the command statements related to the command statement with a high probability of malfunction, and updates the recalculated suspicion value information 247 (S1320). Specifically, the related command statement information of the command statement indicated as having a "high" probability of malfunction in the malfunction possibility information 246 is extracted from the source file relevance information 245. Then, if the corresponding command statement information exists in the recalculated suspicion value information 247, the corresponding suspicion value in the recalculated suspicion value information 247 is rewritten, and if the corresponding command statement information does not exist in the recalculated suspicion value information 247, the command statement information and the suspicion value information are added. For example, the highest suspicion value in the test result starting point suspicion value information is assigned as the suspicion value for the command statement related to the command statement with a high probability of malfunction. A specific example is described below.

The source file relevance information shown in FIG. 9 reveals that the command statements related to the command statement on line 5 of the source file "CreateCore", which has a "high" defect possibility in the defect possibility information shown in FIG. 10, are the command statements on lines 7 and 3 of the source file "CreateCore". Therefore, the suspicion value reassignment unit 230 assigns the highest suspicion value of 1.0 in the test result starting point suspicion value information shown in FIG. 8 to the command statements on lines 7 and 3 of the source file "CreateCore", and updates the recalculated suspicion value information.

The updated result is shown in line #4 of the example of recalculated suspicion value information in Figure 11. Note that the suspicion value for the command statement on line #3 of the source file "CreateCore" is unchanged, since it has already been assigned the highest suspicion value of 1.0 in the test result starting suspicion value information shown in Figure 8. From the above, it can be seen that an appropriate suspicion value is assigned to the command statement on line #7, which is the defective part in the source file "CreateCore" shown in Figure 5.

The above operations increase the suspicion value of commands related to commands that are likely to be defective. In the above example, the highest suspicion value of 1.0 is assigned to the related commands, but a specified number of points may be added or a coefficient may be multiplied.

Next, the suspicion value reassignment unit 230 assigns a suspicion value to the command statement with a high probability of malfunction, and updates the recalculated suspicion value information 247 (S1330). Specifically, it extracts command statements whose malfunction possibility information 246 indicates a "high" probability of malfunction. If the recalculated suspicion value information 247 contains the corresponding command statement information, it rewrites the corresponding suspicion value in the recalculated suspicion value information 247, and if the recalculated suspicion value information 247 does not contain the corresponding command statement information, it adds the command statement information and the suspicion value information. For example, the suspicion value calculation for the command statement where the exception occurred is performed by assigning a suspicion value higher than the highest suspicion value in the test result starting point suspicion value information 244. A specific example is shown below.

It can be seen that the command statement on line 5 of the source file "CreateCore", which is indicated as having a "high" defect possibility in the defect possibility information shown in Figure 10, is the location where the exception occurred. Therefore, the suspicion value reassignment unit 230 assigns a suspicion value of 1.5, which is higher than the highest suspicion value of 1.0 in the test result starting point suspicion value information shown in Figure 8, to the command statement on line 5 of the source file "CreateCore", and updates the recalculated suspicion value information. The updated result is shown in line #1 of the example of recalculated suspicion value information in Figure 11. From the above, it can be seen that a higher suspicion value has been assigned to the command statement on line 5, which is the defect location in the source file "CreateCore" shown in Figure 5, than to other locations.

Next, the suspicious value reassignment unit 230 deletes the suspicious value information of the command statement with a low malfunction probability held in the recalculated suspicious value information 247 (S1340). Specifically, if suspicious value information exists in the recalculated suspicious value information 247 for a command statement whose malfunction probability is indicated as "low" in the malfunction possibility information 246, the suspicious value information is deleted. A specific example is shown below.

The statements in lines 11 and 12 of the source file "CreateCore", which are indicated as having a "low" defect possibility in the defect possibility information shown in FIG. 10, are assigned a suspicion value of 0.25 in the test result starting suspicious value information shown in FIG. 8. Therefore, the suspicious value reassignment unit 230 deletes the suspicious values in lines 11 and 12 of the source file "CreateCore" from the suspicious value reassignment information. The result of the deletion is shown in lines #11 and #12 of the example of recalculated suspicious value information in FIG. 11. From the above, it can be seen that suspicious values are not assigned to the statements in the source file "CreateCore" shown in FIG. 5 that are not related to the test execution results and cannot be defects.

As described above, the defect location identification support device 100 according to this embodiment identifies command statements that are related to command statements such as exception occurrence points that are likely to be defective based on the intra-source file relevance information 245, and assigns a high suspicion value to them. This increases the suspicion value of command statements at defective points to prevent them from being overlooked, compared to a method in which the suspicion value calculation results based on the test results are corrected to the same suspicion value, thereby making the process of identifying defective points more efficient.

The defect location identification support device 100 according to this embodiment also manipulates the suspected value of the test result starting point according to the defect possibility information 246. This makes it possible to also correct the equivalence suspected value of the test result starting point suspected value information 244.

The present invention is not limited to the above-described embodiment, and can be modified as appropriate without departing from the spirit of the present invention.

100...Fault location identification support device, 210...Source file correlation acquisition unit, 220...Fault possibility determination unit, 230...Suspicious value reassignment unit, 240...Information storage unit, 241...Source file group, 242...Test file group, 243...Test execution information, 244 Number of steps and result starting point suspicious value information, 245...Source file correlation information, 246...Fault possibility information, 247...Recalculated suspicious value information

Claims (12)

a source file relation acquisition unit that acquires source file relation information indicating relations between each command in a source file;
a suspicion value reassignment unit that calculates a suspicion value using test execution information that holds the execution results of a test case, test result starting suspicion value information that holds a suspicion value calculated based on the number of executions of each statement in the source file when the test case is executed, and the source file relevance information, and generates recalculated suspicion value information;
The present invention is characterized in that it comprises
A device to assist in identifying defective areas. The source file relation acquisition unit includes:
generating the intra-source-file relevance information by searching and extracting at least one of a command statement having a dependency relationship with a certain command statement and a command statement having similarity to the certain command statement, which are included in the source file;
The defect location identification support device according to claim 1 . the test execution information includes exception occurrence location information that identifies a statement related to an exception occurrence during test execution;
The suspicious value reassignment unit:
A command statement related to the command statement related to the occurrence of the exception is extracted using the relevance information in the source file, and a higher suspicion value than the suspicion value described in the test result starting point suspicion value information is assigned to the command statement, thereby generating recalculated suspicion value information.
The defect location identification support device according to claim 1 . The test execution information includes exception occurrence location information that identifies a statement related to an exception occurrence during test execution,
a defect possibility determination unit that determines a defect possibility of a statement in the source file by inputting the source file, the test execution information, and the test result starting point suspicious value information, and generates defect possibility information.
The defect location identification support device according to claim 1 . The malfunction possibility determination unit is
The malfunction possibility information is characterized in that information indicating a high malfunction possibility is added to a statement regarding an exception occurrence during the test execution.
The defect location identification support device according to claim 4. The malfunction possibility determination unit is
In the defect possibility information, information indicating a high defect possibility is added to a command statement having the highest suspicious value included in the test result starting suspicious value information.
The defect location identification support device according to claim 4. The malfunction possibility determination unit is
The malfunction possibility information is characterized in that information indicating that a malfunction possibility is low is added to a specific type of command statement that is not related to the malfunction.
The defect location identification support device according to claim 4. The suspicious value reassignment unit:
Among the command statements to which information indicating a high probability of a malfunction is added in the malfunction possibility information, a first suspicion value higher than the suspicion value described in the test result starting suspicion value information is added to the command statements regarding the occurrence of an exception during the test execution, thereby generating recalculated suspicion value information.
The defect location identification support device according to claim 4. The suspicious value reassignment unit:
Among the command statements to which information indicating a high probability of a malfunction is added in the malfunction possibility information, other than the command statements related to the occurrence of an exception during the test execution, a second suspicious value, which is a suspicious value described in the test result origin suspicious value information, is added to generate recalculated suspicious value information.
The defect location identification support device according to claim 4. The suspicious value reassignment unit:
a command statement related to a command statement related to an exception occurrence during test execution is extracted using the intra-source file correlation information, and a third suspicion value higher than the suspicion value described in the test result starting suspicion value information is assigned to the command statement, thereby generating recalculated suspicion value information.
The defect location identification support device according to claim 4. The suspicious value reassignment unit:
a fourth suspicious value lower than the suspicious value described in the test result starting suspicious value information is assigned to a command statement to which information indicating a low probability of a defect is assigned in the defect possibility information, thereby generating recalculated suspicious value information.
The defect location identification support device according to claim 4. A defect location identification support method for identifying a defect location in a source file using an information processing device, comprising:
Using source file correlation information including correlation information between each command in the source file, test execution information including information on an exception occurrence location when the test file is executed, and test result origin suspicious value information in which a suspicious value generated by the SBFL technique is assigned to a command in the source file,
extracting a command statement that is highly related to the command statement corresponding to the exception occurrence location information by using the intra-source file relevance information, and assigning a suspicion value to the extracted command statement that is higher than the suspicion value assigned by the test result starting point suspicion value information;
A method to assist in identifying defective areas.

Images