Software defect analysis device and software defect analysis method

Abstract

To make it possible to efficiently secure and assist in correction on a test case needed to automatically correct a failure of software.SOLUTION: A software failure analytic device 100 is configured to include: a storage device 101 which holds test cases of software and information associated with restrictions on occurrence of a failure in application functions of the test cases; and an arithmetic unit 104 which executes processing to determine a test case satisfying the restrictions on occurrence of the failure among the test cases and processing to output notice of a correction request for expectation as to the test case satisfying the restrictions on occurrence as a result of the determination.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a software defect analysis device and a software defect analysis method. [Background technology]

[0002] It is difficult to completely eliminate software defects before they occur, so various studies are being conducted to find ways to efficiently and accurately identify, remove, and fix software defects. One method for detecting such defects is to use test cases, which describe the inputs and outputs (expected values) defined in the specifications or expected by the developer.

[0003] To detect defects, test cases are applied to the target software to check whether the correct expected value is returned for the input. If the output for the input differs from the expected value, or if the software itself stops working, it is determined that the software contains a defect.

[0004] If a developer recognizes the existence of a defect as described above, they will analyze the location of the defect and modify the software logic to perform appropriate input and output. However, for large-scale software, a large number of test cases will be required, and in terms of the effort and cost, this method is not considered realistic.

[0005] Therefore, technologies aimed at automating such defect repair have been proposed, such as a method for interactively repairing software programs using one or more automatically generated tests together with one or more manually created test oracles (see Patent Document 1).

[0006] The method includes: identifying defect locations in the software program; generating potential repairs at the defect locations based on candidate repairs; automatically generating a first test to test the potential repairs; generating a first query for the first test oracle based on the first test; obtaining a response to the first query from a human; generating a first human-provided test oracle based on the first query and the obtained response to the first query; adding the first human-provided test oracle to the first test to generate an extended first test; augmenting a test suite to include the extended first test; and testing the possible repairs using the augmented test suite.

[0007] Also, a method for automated selection of software program repair candidates (see Patent Document 2) has been proposed.

[0008] The method includes identifying defect locations of defects in a tested software program using a test suite, obtaining repair candidates for the defects, obtaining repair code patterns for the repair candidates, determining a number of occurrences of the repair code patterns in existing code of a plurality of existing software programs, prioritizing the repair candidates as repairs for the tested software program based on the number of occurrences of the repair code patterns, and performing repairs on the tested software program according to the prioritization of the repair candidates. The repair action is performed on the affected system.

[0009] Another proposed method includes identifying fault locations of faults in a software program using a test suite; implementing repair candidates for the faults in the software program; extending the test suite with a plurality of test oracles based on observed behavior of the software program, the plurality of test oracles corresponding to the fault locations; running the extended test suite against the software program having the implemented repair candidates; and prioritizing the repair candidates for repairing the software program based on failure rates of the plurality of test oracles for running the extended test suite (see Patent Document 3). [Prior art documents] [Patent documents]

[0010] [Patent Document 1] Japanese Patent Application Publication No. 2019-29015 [Patent Document 2] Japanese Patent Application Publication No. 2019-96292 [Patent Document 3] Japanese Patent Application Publication No. 2018-55676 Summary of the Invention [Problem to be solved by the invention]

[0011] However, in conventional technology, it is necessary for humans ( The decision is made by the developer, and ultimately requires a considerable amount of man-hours. The larger the scale of the system, the greater the amount of work required, which can lead to significant costs. Another problem is that it is difficult to evaluate the validity of such developer decisions. In other words, even if a decision is made with a great deal of effort, if the validity is not certain, the accuracy of automatic corrections based on insufficient test cases cannot be expected.

[0012] Therefore, an object of the present invention is to provide a technology that enables efficient acquisition of test cases necessary for automatic correction of software defects and support for correction. [Means for solving the problem]

[0013] The software defect analysis device of the present invention, which solves the above-mentioned problems, includes a storage device that stores software test cases and information on defect occurrence constraints in application functions of the test cases, a process for determining which of the test cases satisfy the defect occurrence constraints, and a test case that satisfies the defect occurrence constraints as a result of the determination. If there is no such constraint, a test case is generated that specifies an input that satisfies the constraint based on the information about the constraint, and a request for setting an expected value for the input is issued. and a computing device that executes a process of outputting the notification. Furthermore, the software defect analysis method of the present invention includes a process in which an information processing device stores software test cases and information on defect occurrence constraints in application functions of the test cases in a storage device, a process for determining which of the test cases satisfy the defect occurrence constraints, and a process for determining which test cases satisfy the defect occurrence constraints as a result of the determination. If there is no such constraint, a test case is generated that specifies an input that satisfies the constraint based on the information about the constraint, and a request for setting an expected value for the input is issued. The present invention is characterized in that it executes a process of outputting a notification. [Effects of the Invention]

[0014] According to the present invention, it is possible to efficiently secure test cases necessary for automatic correction of software defects and to support the correction. [Brief explanation of the drawings]

[0015] [Figure 1] FIG. 1 is a diagram illustrating an overview of a software defect analysis technique according to an embodiment of the present invention. [Figure 2] 1 is a diagram illustrating an example of the configuration of a software defect analysis device according to an embodiment of the present invention. [Figure 3] 10A and 10B are diagrams illustrating examples of constraints on the occurrence of defects in the present embodiment. [Figure 4] 10A and 10B are diagrams illustrating examples of constraints on the occurrence of defects in the present embodiment. [Figure 5] 10A and 10B are diagrams illustrating examples of constraints on the occurrence of defects in the present embodiment. [Figure 6] FIG. 1 is a diagram illustrating an example of a flow of a software defect analysis method according to an embodiment of the present invention. [Figure 7] FIG. 10 is a diagram illustrating a comparative example of a defect occurrence constraint and a test case according to the present embodiment. [Figure 8] FIG. 10 is a diagram illustrating an example of output in this embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0016] <Summary> As illustrated in FIG. 1, the software defect analysis device 100 in this embodiment uses a so-called log-based APR (Automatic Program Repair) technique to determine the constraint conditions under which the defect occurs from the software execution log (which includes a log related to the defect), while analyzing existing test cases and adding or modifying test cases necessary to fix the defect.

[0017] Furthermore, the software defect analysis device 100 uses the test cases thus added and modified to perform so-called test-based APR (Automatic Program Repair) and obtain modified source code.

[0018] 2, the input to the software defect analysis device 100 includes a source code 12 of the software 11 and an execution log 13 of the software 11. The execution log 13 includes functions (methods) that were called during execution. When an exception (e.g., division by zero) occurs during execution, the execution log 13 ends with the call of the function where the exception occurred, the statement (line / step of source code) where the exception occurred, and the type of exception that occurred (recording a program stop).

[0019] The software defect analysis device 100 sets the statement (line / step of source code) of the software 11 that includes a division operation in the function where the exception occurred as the analysis start point from the execution log 13. It also queries the user (developer) and sets the function that directly or indirectly calls the function that includes the analysis start point as the analysis end point.

[0020] The software defect analysis device 100 performs backward symbolic execution, which is the reverse of normal software execution, from the analysis start point to the analysis end point. During the backward symbolic execution, the software defect analysis device 100 records the execution path and path conditions.

[0021] An execution path is a path (sequence of statements / lines / steps) in software that connects the analysis end point and the analysis start point, and processing proceeds along the execution path. Execution paths also include function calls. Path conditions are conditions on variables that cause exceptions (such as division by zero), that is, constraints on the occurrence of a malfunction. The variables mentioned above include local variables within a function and input parameters to the function.

[0022] The software defect analysis device 100 determines which of the test cases 20 satisfy the defect occurrence constraints based on the information regarding the defect occurrence constraints identified as described above and the test cases 20 prepared in advance for the functions of the above-mentioned software 11.

[0023] Furthermore, as a result of this determination, the software defect analysis device 100 outputs to the user terminal 200 a notification requesting modification of the expected values ​​for test cases that satisfy the above-mentioned defect occurrence constraints, and prompts the developer or the like to modify the test cases.

[0024] Furthermore, the software defect analysis device 100 determines the defect occurrence constraints based on the results of the above-mentioned determination. If there is no test case that satisfies the constraint, a test case that specifies inputs that satisfy the constraint is generated based on the information about the constraint, and a notification requesting setting of expected values ​​for the inputs is output to the user terminal 200. The developer or the like who receives this notification sets the expected values ​​for the test case through the user terminal 200 and completes the test case.

[0025] The software defect analysis device 100 uses an SMT solver (Satisfiability Modulo Theories Solver) 111 to find input parameters of a function that is an analysis end point that satisfies a path condition. By performing a test using this value as input, it becomes possible to confirm whether the software 11 with the bug fixed operates correctly. Other types of solvers, such as a SAT solver (SATisfiability Solver), may be used instead of the SMT solver.

[0026] Furthermore, software defects are corrected using known techniques, such as test-based APR (Automatic Program Repair).

[0027] In this technology, the software defect analysis device 100 executes a predetermined correction process based on, for example, a repair template and the test case 20 that has been modified, added, etc. as described above, in order to correct a defect in the source code that is the target of defect correction.

[0028] The above-mentioned template contains instructions, etc., that, when executed, change the source code 12 in response to the existence of a defect in the source code 12. On the other hand, the test case 20 determines whether the source code 12 exhibits the behavior (e.g., output of an expected value for a given input) specified by the specifications or the developer. <Input for software defect analysis equipment> The inputs of the software defect analysis apparatus 100 include source code 12, an execution log 13, and a software specification 14.

[0029] The source code 12 is the source code of the functions (methods) that make up the software 11 to be analyzed. The software specification 14 describes the name of the function, as well as the names, types, and ranges of the input parameter values ​​and return values ​​of the function.

[0030] The execution log 13 includes a record of function calls made during the execution of the software 11. In addition to the name (identification information) of the called function, the execution log 13 may also include input parameter values ​​at the time of the call and return values ​​when returning from the call.

[0031] The execution log 13 may further include exceptions that occurred during the execution of the software 11. Exceptions include division by zero and violations of input parameter values ​​or return values ​​described in the software specification 14 (values ​​outside the range of the specification). <Output from software defect analysis equipment> The output of the software defect analysis apparatus 100 includes an execution path 21, input parameter values ​​22, and test cases 20. The execution path 21 is a path through the software where a defect occurs (a series of statements / lines / steps that are processed sequentially in the source code 12).

[0032] One end of the execution path 21 is a statement / line / step where an exception (fault) related to the defect occurs, and is referred to as the analysis start point or simply the start point. The analysis start point is, for example, a statement including a division operation in which division by zero occurs.

[0033] The other end of the execution path 21 is a function that directly or indirectly calls the function including the analysis start point, and is referred to as the analysis end point or entry point. That's fine.

[0034] The input parameter value 22 is the input parameter value of the entry point function when the malfunction occurs.

[0035] The test cases 20 are test cases that are prepared in advance for the functions of the source code 12, but are modified or added to as appropriate by the software defect analysis device 100 of this embodiment. <Configuration of software defect analysis device> 2 is, for example, an information processing device arranged in a test environment 10 of software 11, and enables efficient acquisition of test cases necessary for automatic correction of defects in the software 11 and support for correction. Here, it is assumed that the above-mentioned software 11 is composed of source code 12.

[0036] The software defect analysis device 100 may implement its own user interface, or may use a user terminal 200 connected via an appropriate network as the user interface.

[0037] In this case, the user terminal 200 is a terminal device operated by a developer or the like of the software 1. Specifically, the user terminal 200 can be a personal computer, a smartphone, a tablet terminal, or the like.

[0038] The software defect analysis device 100 and the above-described user terminal 200 may be collectively referred to as a software defect analysis system.

[0039] Of these, the storage device 101 is configured with an appropriate nonvolatile storage element such as an SSD (Solid State Drive) or a hard disk drive.

[0040] The memory 103 is composed of a volatile storage element such as a RAM.

[0041] The arithmetic unit 104 is a CPU that reads out the program 102 stored in the storage unit 101 into the memory 103 and executes the program, thereby controlling the device itself and performing various types of judgment, calculation and control processing.

[0042] The input / output device 105 is a device that receives key input or voice input from developers and displays processing data. Alternatively, it may be a network interface card that connects to an appropriate network and handles communication processing with the user terminal 200.

[0043] In addition to a program 102 for implementing the functions required for the software defect analysis device 100 of this embodiment, the storage device 101 also stores at least the source code 12 of the above-mentioned software 11, an execution log 13 of the software 11, software specifications 14, a function call relationship DB 15, and test cases 20.

[0044] The function call relationship DB 15 stores data indicating the relationship between functions that call other functions, in other words, a call relationship graph (a graph of a control flow that expresses the call relationship between functions).

[0045] The program 102 includes at least a symbolic execution engine 110 and an SMT solver 111.

[0046] The calculation device 104 executes the program 102, and thereby the calculation device 104 has a function of acquiring the function call relationships from the source code 12 and storing them in the function call relationship DB 15, a function of analyzing the execution log 13 to acquire the analysis start point, a function of acquiring functions that call the function including the analysis start point from the function call relationship DB 15 and displaying them as entry point candidates on the display of the input / output device 105 or the user terminal 200, a function of setting the displayed entry point candidates, i.e., the function selected by the user (developer), as the analysis end point (entry point), and a function of calculating the defect occurrence constraints obtained by the processing up to this point and the test cases 20 held in the storage device 101, and a function of calculating the defect occurrence constraints of the test cases 20 based on the defect occurrence constraints obtained by the processing up to this point and the test cases 20 held in the storage device 101. The software 11 is provided with a function to determine which test cases satisfy the occurrence constraints of the defect, a function to output a notification of a request to modify the expected value to the input / output device 105 or the user terminal 200 for test cases that satisfy the defect occurrence constraints as a result of this determination, a function to generate a test case that specifies an input that satisfies the occurrence constraints based on information about the occurrence constraints, and to output a notification of a request to set an expected value for the input to the input / output device 105 or the user terminal 200 if the result of the above determination shows that there are no test cases that satisfy the defect occurrence constraints, a function to identify the location of the defect in the software 11 using the test case 20 that has undergone the above processing, and a function to generate repair candidates for the defect based on a repair template and the test case 20.

[0047] The symbolic execution engine 110 generates the execution path 21 and path conditions (see, for example, Japanese Patent Application No. 2020-143591). The path conditions are conditions for variables (local variables and input parameters) that allow the execution of the software to be analyzed to follow the execution path 21. Details of the symbolic execution engine are described in the following literature: Peter Dinges and Gul Agha, "Targeted Test Input Generation Using Symbolic Concrete Backward Execution."

[0048] The SMT solver 111 (solver) generates input parameter values ​​22 that satisfy the path conditions. The SMT solver is described in the following literature: Leonardo de Moura and Nikolaj Bjorner, "Z3: An Efficient SMT Solver". <Example of restrictions on the occurrence of problems> An example of a constraint on the occurrence of a defect regarding the source code 12 of the software 11 is shown in Figure 3. The example shown here corresponds to a situation where it is found in the execution log 13 that a division by zero defect has occurred in the function "Percentage."

[0049] Therefore, when the above log-based defect analysis is performed starting from the function "Percentage", three execution paths and path conditions, i.e., occurrence constraints, that reach the defect location are obtained.

[0050] In this case, the software defect analysis device 100 analyzes the execution log 13 and determines that line 10 of the function "Percentage" is a statement / line that includes a division operation, and therefore sets the starting point to line 10 of the function "Percentage".

[0051] A path condition is a condition / constraint that causes an exception to occur. The path condition on line 10 of the function "Percentage," which is the starting point of the analysis, is "max=0."

[0052] Symbolic execution engine 110 starts from a starting point and searches through source code 12 in the opposite direction to normal (forward) execution until it reaches an entry point (also referred to as backward symbolic execution). If there are multiple entry points, symbolic execution engine 110 searches until it reaches one of the entry points.

[0053] Also, the symbolic execution engine 110 searches for a statement that calls the function "Percentage." In the case of FIG. 3, the statement that calls the function "Percentage" is T is the function "abs max", and the symbolic execution engine 110 continues the search from this line and ends the search until the analysis end point. The execution path and path conditions (including the conditions of the input parameter values at the entry point (analysis end point)) identified up to this point become the occurrence constraints of the defect. The SMT solver 111 solves the above path conditions and calculates the input parameter value 22 of the function that is the entry point and satisfies the path conditions.

[0054] As a result of performing the identification of such occurrence constraints with respect to the source code 12, examples are shown in FIGS. 3 to 5. The constraints illustrated here assume an environment where the int type is a 32-bit signed integer, and the actual values differ depending on the execution environment. The occurrence constraint shown in FIG. 3 is ¬(A > B) ∩ ¬(B > 0) ∩ (B - A = 0), and the input parameter values are (a, b) = (0, 0).

[0055] Also, the occurrence constraint shown in FIG. 4 is ¬(0 < A) ∩ ¬(0 - A < 0) ∩ (B = 0), and the input parameter values are (a, b) = (-2147483648, 0).

[0056] Also, the occurrence constraint shown in FIG. 5 is ¬(B < 0) ∩ ¬(0 > 0 - B) ∩ (A = 0), and the input parameter values are (a, b) = (0, -2147483648). <Software defect analysis process> Subsequently, a flowchart example of the software defect analysis method of this embodiment will be described based on FIG. 6. First, the software defect analysis apparatus 100 acquires the occurrence constraints of defects for each defect occurrence path (execution path) related to the source code 12 by the log-based APR technique as already described based on the execution log 13 (s1).

[0057] Subsequently, the software defect analysis apparatus 100 acquires the test case 20 of the target function that is the location where the above defect occurs from the storage device 101 (s2).

[0058] Furthermore, the software defect analysis device 100 selects one of the occurrence constraints obtained in step s1 for the target function (step s3). There are no particular limitations on the selection method.

[0059] Furthermore, the software defect analysis device 100 selects one of the test cases acquired in s2 (s4). There are no particular limitations on the method of this selection.

[0060] Here, the software defect analysis device 100 determines whether the input values ​​of the test cases selected in s4 satisfy the occurrence constraints selected in s3 (s5). Specifically, as shown in Fig. 7, the defect occurrence constraints C1 to C3 are compared with the cases T1 to T4 of the test cases 20 related to the function "abs max." In this case, the comparison is an operation to verify whether each defect occurrence constraint satisfies the relationship between the input value and the expected value of each test case of the function "abs max."

[0061] As a result of the determination in s5, if a test case that satisfies the above-mentioned occurrence constraints can be identified (s5: Yes), the software defect analysis device 100 records the test case as a test case that needs to be corrected (s6).

[0062] In this case, as shown in the output example of Figure 8, since it is determined that the occurrence constraint C1 satisfies the condition for test case T1 (it is determined that this is a test case in which a defect occurs and requires correction), in s6, the software defect analysis device 100 outputs a notification to the input / output device 105 or the user terminal 200 requesting the developer to correct the output of test case T1, i.e., the expected value.

[0063] On the other hand, the developer operates the input / output device 105 or the user terminal 200 to execute the test case T The expected value of test case T1 is input. Software defect analysis apparatus 100 receives this input and completes the correction of test case T1.

[0064] On the other hand, if the result of the above determination is that no test case that satisfies the occurrence constraints can be identified (s5: No), the software defect analysis device 100 determines whether there are any remaining test cases (i.e., unprocessed test cases) among the test cases obtained in s2 (s7).

[0065] If it is determined that there are remaining test cases (s7: Yes), the software defect analysis device 100 returns the process to s4.

[0066] On the other hand, if the result of the above determination is that there are no remaining test cases (s7: No), the software defect analysis device 100 determines whether there are one or more test cases that satisfy the occurrence constraint of the defect (s8).

[0067] If, as a result of this determination, it is found that there are no test cases that satisfy the defect occurrence constraints (s8: No), the software defect analysis device 100 adds test cases T5 and T6 that have input parameter values ​​that satisfy the defect occurrence constraints C2 and C3, as illustrated in Figure 8 (s9).

[0068] In this case, the software defect analysis device 100 outputs a request to set the expected value of the function "abs max" for the added test cases T5 and T6 to the input / output device 105 or the user terminal 200 in s9.

[0069] Meanwhile, the developer inputs the expected values ​​of the test cases T5 and T6 by operating the input / output device 105 or the user terminal 200. The software defect analysis device 100 receives this input and completes the addition of the test cases T5 and T6.

[0070] On the other hand, if the result of the above determination indicates that there is one or more test cases that satisfy the occurrence constraint of the defect (s8: Yes), the software defect analysis device 100 determines whether there are any remaining occurrence constraints that have not been processed among the occurrence constraints of the defect obtained in s1 (s10).

[0071] If the result of this determination is that there are remaining occurrence constraints (s10: Yes), the software defect analysis device 100 returns the process to s3.

[0072] On the other hand, if it is determined as a result of the above-mentioned determination that there are no remaining occurrence constraints (s10: No), the software defect analysis device 100 uses the test cases 20 that have been corrected and added up to this point to identify the location of the defect in the software 11, and executes defect correction for this defect based on the repair template and the test cases 20 (s11), and ends the process. For this defect correction process, an existing test case-based automatic correction technology may be appropriately adopted.

[0073] The best mode for carrying out the present invention has been specifically described above, but the present invention is not limited to this and can be modified in various ways without departing from the spirit of the present invention.

[0074] According to this embodiment, it is possible to efficiently secure test cases necessary for automatically correcting software defects and to support the correction.

[0075] The description of this specification makes at least the following clear: In the software defect analysis device of this embodiment, the arithmetic unit determines, as a result of the determination, the occurrence control. If there is no test case that satisfies the constraint, a test case that specifies an input that satisfies the occurrence constraint may be generated based on information about the occurrence constraint, and a notification requesting setting of an expected value for the input may be output.

[0076] This makes it possible to secure a sufficient number of test cases required for correcting software defects, and ultimately enables more efficient securing of test cases required for automatic software defect correction and support for correction.

[0077] Furthermore, in the software defect analysis device of this embodiment, the arithmetic device may perform the following processes based on the execution log of the software: acquiring a statement in which an exception occurred as an analysis start point; acquiring a function that directly or indirectly calls the function including the analysis start point as an analysis end point; performing backward symbolic execution from the analysis start point to the analysis end point to identify an execution path and calculate a path condition that is a condition under which the exception will occur; and storing in the storage device, as the occurrence constraint, a condition for the input parameter value of the function that is the analysis end point and that satisfies the path condition, or an input parameter value of the function that is the analysis end point and that satisfies the path condition.

[0078] This technology, known as log-based Automatic Program Repair (APR), can be used to accurately and efficiently identify the constraints that cause defects, which in turn enables more efficient acquisition of test cases required for automatic software defect repair and support for repairs.

[0079] In addition, in the software defect analysis device of this embodiment, the arithmetic device may further perform a process of identifying the location of a defect in the software using the test case, and a process of generating repair candidates for the defect based on a repair template and test case.

[0080] This allows so-called test-based APR (Automatic Program Repair) to be applied to the above-mentioned log-based APR (Automatic Program Repair), making it possible to efficiently secure the test cases necessary for automatically repairing software defects and automatically repair software based on those test cases.

[0081] Furthermore, in the software defect analysis method of this embodiment, if the information processing device determines as a result of the determination that there is no test case that satisfies the occurrence constraint, it may generate a test case that specifies an input that satisfies the occurrence constraint based on information regarding the occurrence constraint, and output a notification requesting the setting of an expected value for the input.

[0082] Furthermore, in the software defect analysis method of this embodiment, the information processing device may perform the following processes based on the execution log of the software: acquiring a statement in which an exception occurred as an analysis start point; acquiring a function that directly or indirectly calls the function including the analysis start point as an analysis end point; performing backward symbolic execution from the analysis start point to the analysis end point to identify an execution path and calculate a path condition that is a condition under which the exception will occur; and storing in the storage device, as the occurrence constraint, a condition for the input parameter value of the function that is the analysis end point and that satisfies the path condition, or an input parameter value of the function that is the analysis end point and that satisfies the path condition.

[0083] In addition, in the software defect analysis method of this embodiment, the information processing device may further perform a process of identifying the location of a defect in the software using the test case, and a process of generating repair candidates for the defect based on a repair template and test case. [Explanation of symbols]

[0084] 10 Test Environment 11 Software 12 Source Code 13 Execution log 14 Software Specifications 15 Function call relationship database 20 Test Cases 21 Execution Path 22 Input parameter values 100 Software Defect Analysis Equipment 101 Storage device 102 Programs 103 memory 104 Arithmetic equipment 105 Input / Output Devices 110 Symbolic Execution Engine 111 SMT Solver 200 user terminals

Claims

1. a storage device for storing test cases of the software and information on the constraints on the occurrence of faults in the application functions of the test cases; a computing device that executes a process of determining which of the test cases satisfies the defect occurrence constraint, and, if the determination result shows that there is no test case that satisfies the defect occurrence constraint, executes a process of generating a test case that specifies an input that satisfies the defect occurrence constraint based on information about the defect occurrence constraint, and outputs a notification of a request to set an expected value for the input; A software defect analysis device comprising:

2. The computing device The method executes a process of acquiring a statement in which an exception has occurred as an analysis start point based on an execution log of the software, a process of acquiring a function that directly or indirectly calls the function including the analysis start point as an analysis end point, a process of performing backward symbolic execution from the analysis start point to the analysis end point to identify an execution path and calculate a path condition that is a condition for the exception to occur, and a process of storing in the storage device, as the occurrence constraint, a condition for an input parameter value of the function that is the analysis end point and that satisfies the path condition, or an input parameter value of the function that is the analysis end point and that satisfies the path condition.

2. The software defect analysis device according to claim 1.

3. The computing device and further performing a process of identifying a location of a defect in the software using the test cases, and a process of generating repair candidates for the defect based on repair templates and test cases.

2. The software defect analysis device according to claim 1.

4. The information processing device storing, in a storage device, test cases for the software and information on constraints on the occurrence of faults in application functions of the test cases; a process of determining which of the test cases satisfies the defect occurrence constraint, and if it is determined that there is no test case that satisfies the defect occurrence constraint, a process of generating a test case that specifies an input that satisfies the defect occurrence constraint based on information about the defect occurrence constraint, and outputting a notification of a request to set an expected value for the input. A software defect analysis method comprising:

5. The information processing device, based on the execution log of the software, a process of acquiring a statement in which an exception has occurred as an analysis start point, a process of acquiring a function that directly or indirectly calls the function including the analysis start point as an analysis end point, a process of performing backward symbolic execution from the analysis start point to the analysis end point to identify an execution path and calculate a path condition that is a condition for the exception to occur, and a process of storing in the storage device, as the occurrence constraint, a condition for an input parameter value of the function that is the analysis end point and that satisfies the path condition, or an input parameter value of the function that is the analysis end point and that satisfies the path condition.

5. The software defect analysis method according to claim 4.

6. The information processing device, further performing a process of identifying a location of a defect in the software using the test cases, and a process of generating repair candidates for the defect based on repair templates and test cases.

5. The software defect analysis method according to claim 4.

Images