Program modification device, program modification method, and program modification program

Abstract

To provide a program correction device, a program correction method, and a program correction program for performing efficient program correction according to a configuration of a program.SOLUTION: A program correction device 1 includes: an information storage unit 260 that stores component information, which is information in which information on each component of a program to be verified is associated with information on each test program for verifying each component; a defect part estimation unit 220 that estimates a defect part of the program to be verified by executing each test program; an execution priority degree determination unit 240 that identifies each component of the program to be verified regarding each estimated defect part by the component information, and determines a correction ranking of each component based on relationships between the identified components; and an automatic correction execution control unit 250 that corrects each component of the program to be verified with a correction program corresponding to each component according to the determined correction ranking.SELECTED DRAWING: Figure 1

Description

Technical Field

[0004] , , , , , , , ,

[0005] , , , ,

[0001] The present invention relates to a program modification device, a program modification method, and a program modification program.

Background Art

[0002] As a technology for identifying and fixing bugs included in software, Automated Program Repair (APR) has been proposed. APR is composed of, for example, two phases: "identifying the bug location" and "generating a patch". Specifically, after identifying the bug location in the software to be modified by a predetermined bug location detection program, a plurality of modification programs (patch candidates) that can modify the software by rewriting the part related to the bug location are created. Then, by verifying each created patch candidate, an optimal patch candidate (patch plan) is identified. By applying this patch plan to the software to be modified, the bug is repaired.

[0003] As a technology related to APR, for example, in Patent Document 1, a test suite is used to identify the failure location in a software program, and machine learning is used to determine a repair effectiveness indication indicating the potential effectiveness of executing possible repair processing at the failure location. Based on the repair effectiveness indication, priority is given to performing repair at the failure location, and based on the prioritization of the failure location, a repair process for the software program is executed.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] Thus, Patent Document 1 uses machine learning to determine the effectiveness of repairing bugs in software, and this effectiveness is determined based on the execution results of individual repair processes in the software. However, there is a risk that bug repair may not be efficient with such a method. For example, if there are certain dependencies between software components and a situation arises where one bug triggers another, the order of repair processes may make it difficult to easily reach a fundamental bug fix. In addition, it may not be possible to distinguish between areas that should be prioritized for repair and other areas, which could prevent bug repair from being carried out in line with the realities of software development.

[0006] The present invention has been made in view of these circumstances, and its purpose is to provide a program modification device, a program modification method, and a program modification program that can perform efficient program modification according to the program's configuration. [Means for solving the problem]

[0007] One aspect of the present invention for solving the above problems is an information storage unit having a processor and memory, which stores component information that associates information about each component of the program to be verified with information about each test program that verifies each component, a defect location estimation unit that estimates the defect locations of the program to be verified by executing each test program, and the components of the program to be verified related to each estimated defect location. The program modification device comprises: an execution priority determination unit that identifies element information and determines the order in which each component is modified based on the relationships between the identified components; and an automatic modification execution control unit that modifies each component of the program to be verified with a modification program corresponding to each component, according to the determined modification order.

[0008] Furthermore, one aspect of the present invention for solving the above problems is a program modification method comprising: a configuration information storage process in which an information processing device stores configuration information, which is information that associates information on each component of a program to be verified with information on each test program that verifies each component; a defect location estimation process that estimates the defect locations of the program to be verified by executing a plurality of the test programs; an execution priority determination process that identifies each component of the program to be verified related to each estimated defect location using the configuration information and determines the order in which to modify each component based on the relationships between the identified components; and an automatic modification execution control process that modifies each component of the program to be verified with a modification program corresponding to each component according to the determined modification order.

[0009] Furthermore, one aspect of the present invention for solving the above problems is a program modification program that causes an information processing device to execute: a configuration information storage process which stores configuration information which is information that associates information on each component of the program to be verified with information on each test program that verifies each component; a defect location estimation process which estimates the defect locations of the program to be verified by executing a plurality of the test programs; an execution priority determination process which identifies each component of the program to be verified related to each estimated defect location using the configuration information and determines the order in which to modify each component based on the relationships between the identified components; and an automatic modification execution control process which modifies each component of the program to be verified with a modification program corresponding to each component according to the determined modification order. [Effects of the Invention]

[0010] According to the present invention, efficient program modification can be performed according to the program's structure.

[0011] Other issues, configurations, and effects not mentioned above will be clarified by the following description of the embodiments. [Brief explanation of the drawing]

[0012] [Figure 1] It is a diagram for explaining an example of the functions provided by the program modification apparatus according to the first embodiment. [Figure 2] It is a diagram showing an example of source file information. [Figure 3] It is a diagram showing an example of test program information. [Figure 4] It is a diagram for explaining an example of the hardware provided by the program modification apparatus. [Figure 5] It is a flowchart for explaining an example of the program modification process, which is a process performed by the program modification apparatus. [Figure 6] It is a diagram showing an example of test result information. [Figure 7] It is a diagram showing an example of defect identification information. [Figure 8] It is a diagram showing an example of execution priority information. [Figure 9] It is a diagram showing an example of revision history information. [Figure 10] It is a diagram showing an example of revision result information. [Figure 11] It is a flowchart for explaining the details of the execution priority determination process. [Figure 12] It is a diagram for explaining an example of the program modification process according to the second embodiment.

Mode for Carrying Out the Invention

[0013] Hereinafter, the program modification apparatus 1 according to the present embodiment will be described. The program modification apparatus 1 of the present embodiment is an information processing apparatus that modifies a program (for example, source code written in a predetermined language. Hereinafter, referred to as a verification target program.) that may contain defects (bugs).

[0014] Specifically, this program modification device 1 estimates defective parts in the program to be verified by executing a predetermined test program, and generates a plurality of modification programs (hereinafter referred to as patches or patch candidates) for correcting each estimated defective part. Then, the program modification device 1 executes each modification program, and for each program to be verified corrected thereby, executes the test program again to identify the modification program that most appropriately corrects the defective part, and presents the identified modification program to the user as a patch proposal. Note that, for example, when the program modification device 1 executes the corrected program to be verified again against the test program, if there is no change in the test result or if it fails in more test cases, etc., and the correction result is not appropriate, the program modification device 1 may present the correction failure to the user.

[0015] At this time, the program modification device 1 determines the execution order of each modification program based on the dependency relationship of components related to each defective part in the program to be verified, and corrects the program to be verified based on the determined execution order. Thereby, the defective parts existing in the program to be verified can be efficiently and surely eliminated. Note that the components are, for example, program packages, classes, and methods.

[0016] -Example 1- Hereinafter, the program modification device 1 according to Example 1 will be described.

[0017] FIG. 1 is a diagram for explaining an example of the functions provided in the program modification device 1 according to Example 1. The program modification device 1 includes functional units such as an information storage unit 260, a test execution unit 210, a defective part estimation unit 220, a patch candidate generation unit 1010, a patch verification unit 1020, a program modification unit 230, an execution priority determination unit 240, an automatic correction execution control unit 250, and an information storage unit 270.

[0018] The information storage unit 260 stores source file information 261, test program information 262, test result information 263, patch candidate information 1001, defect identification information 264, execution priority information 265, revision history information 266, and revision result information 267.

[0019] (Source file information) Figure 2 shows an example of source file information 261. Source file information 261 contains information on one or more source files 320 (the program under verification). Each source file 320 is associated with and stored in a location 310 (file name and folder, etc.).

[0020] (Test program information) Figure 3 shows an example of test program information 262. Test program information 262 is information about a test class, which is a collection of one or more test files 420 (hereinafter referred to as a test program or test case group). Each test file 420 has its name and storage location 410 (file name and folder, etc.) associated with it and stored.

[0021] Each test file 420 determines whether or not there is a defect in the corresponding component (a component of the program under verification). Specifically, each test file 420 has one or more test units 421 (test cases). Each test unit 421 has a call unit 422 that executes the program under verification by specifying various input values ​​(e.g., variables or constants) for the corresponding component, and the execution result of the program under verification based on the call unit 422, and a pre-specified It includes a determination unit 423 that determines whether or not the expected result matches.

[0022] The constituent elements include, for example, each package of the program under verification, the classes that make up a package, the methods that make up a class, and each processing unit (path) within a method. There may be dependencies between constituent elements, such as one constituent element depending on another (e.g., calling a process, referencing a variable). In this embodiment, the program modification device 1 stores such relationships between constituent elements of the program under verification as constituent element information. Here, the program modification device 1 may generate the constituent element information in advance, for example, from analysis results or design information in the source file information, or from the execution results of a test program.

[0023] The determination unit 423 outputs either "No problem" (if the execution result matches the correct value) or "Problem found" (if the execution result does not match the correct value).

[0024] Next, the test result information 263 shown in Figure 1 stores information on each component of the program under verification, information on each test program that identifies defects in each component, and the execution result of each test program ("defect found" or "no defect"), in association with each other.

[0025] Patch candidate information 1001 is information about a potential fix (patch candidate).

[0026] The defect location candidate information 264 is information about the defect location of the program under verification, estimated based on the execution results of the test program.

[0027] Execution priority information 265 is information regarding the order in which each component to be corrected by the hotfix (patch) is corrected.

[0028] The revision history information 266 is information about the history of revisions made by revision programs. The history information includes, for example, the time each revision program was applied and the history of whether each revision program successfully revised its components.

[0029] Furthermore, the information storage unit 270 stores information about the execution time of the test program for each of the aforementioned components.

[0030] Correction result information 267 is information about the verified program that was corrected based on the correction order described above.

[0031] Details of the test result information 263, potential defect location information 264, execution priority information 265, correction history information 266, and correction result information 267 will be described later.

[0032] Next, the test execution unit 210 executes the test program on the program to be verified.

[0033] The defect location estimation unit 220 estimates the defect location of the program under verification by executing the test program.

[0034] The patch candidate generation unit 1010 generates a correction program (patch candidate) that corrects the defective parts of the components of the program under verification. In this process, the patch candidate generation unit 1010 generates the patch candidates according to the correction order of the components, which will be described later.

[0035] The patch verification unit 1020 verifies each patch candidate generated by the patch candidate generation unit 1010. The effectiveness (successful or unsuccessful correction) of the patch when applied to (executed) the target program is verified. The patch verification unit 1020 identifies effective patch candidates from among the patch candidates as proposed patches.

[0036] The program modification unit 230 generates a modified program for verification by applying (executing) the proposed patch to the program for verification.

[0037] The execution priority determination unit 240 identifies each component of the program to be verified related to each defect location estimated by the defect location estimation unit 220 using component information, and determines the order in which each component should be corrected based on the relationships between the identified components.

[0038] For example, the execution priority determination unit 240 determines whether there are processing dependencies between each component identified by the defect location estimation unit 220, and if it determines that there are processing dependencies, it sets different correction priorities between each component based on those processing dependencies.

[0039] The automatic correction execution control unit 250 corrects each component of the program to be verified using a correction program corresponding to that component, according to the correction order determined by the execution priority determination unit 240.

[0040] Here, Figure 4 illustrates an example of the hardware provided by the program modification device 1. The program modification device 1 includes a processor such as a CPU (Central Processing Unit). The system comprises 10, a main memory 120 such as RAM (Random Access Memory) and ROM (Read Only Memory), an auxiliary storage 130 such as HDD (Hard Disk Drive) and SSD (Solid State Drive), an input device 140 such as a keyboard, mouse, and touch panel, an output device 150 such as a monitor (display), and a communication device 160 such as a wireless network interface or network interface card for data communication with other information processing devices.

[0041] The functional unit of the program modification device 1 is realized by the processor 110 of the program modification device 1 executing a program stored in the main memory 120 or the auxiliary memory 130. These programs may be stored, for example, in a storage device such as a secondary storage device, non-volatile semiconductor memory, hard disk drive, SSD, or a non-temporary data storage medium readable by each node, such as an IC card, SD card, or DVD. Next, we will explain the process performed by the program modification device 1.

[0042] Figure 5 is a flowchart illustrating an example of the program modification process performed by the program modification device 1. The program modification process is initiated, for example, when the program modification device 1 receives input from a user specifying the program to be verified, or when source file information is updated, or as a periodic task.

[0043] First, the test execution unit 210 reads the specified program to be verified (s801). Then, the test execution unit 210 obtains each test file 420 (test program) from the test program information 262 and executes each obtained test program (s802).

[0044] The defect location estimation unit 220 stores the execution results of each test program in the test result information 263 (s803). The defect location estimation unit 220 also estimates the defect location in each component of the program under verification based on the execution content of each test program and stores the result in the defect identification information 264 (s803).

[0045] Specifically, for example, the fault location estimation unit 220 sets information indicating whether the execution of each test program was successful or unsuccessful in the test result information 263. The fault location estimation unit 220 also uses, for example, Spectrum-Based Fault Localization (SBFL) to determine the success or failure of the test program. By identifying the execution path of each process within the program under verification, executed by the RAM, the suspicious value of each process within the program under verification is calculated, and the location of the defect is identified. Here, we will explain examples of test result information 263 and defect identification information 264.

[0046] (Test results information) Figure 6 shows an example of test result information 263. The test result information 263 includes the following data items: the test number 2631 of each test program (test case group), the corresponding element 2632 which is a component whose presence or absence of defects is verified by the test program related to test number 2631, the test result 2633 from the test program related to test number 2631, and the test execution time 2634 which is the execution time of the test program related to test number 2631. The corresponding element 2632 is set in advance, for example, based on predetermined design information related to the program to be verified.

[0047] Initially, no information is set for test result 2633; the information is set when the test program related to test number 2631 is executed.

[0048] In the example shown in the diagram, "Test Program 1" verifies a defect in method "m1" within class "CA". "Test Program 3" verifies defects in methods "m2" and "m3" within class "CB". Furthermore, "Test Program 1" runs successfully (○) (no defects found), while "Test Program 2" fails (×) (defects found). It is assumed that, as part of the component information, method "m3" within class "CB" depends on method "m2" within class "CB".

[0049] (Information identifying defects) Figure 7 shows an example of defect identification information 264. Defect identification information 264 has a number 2641 assigned to each defect location, and data items for one or more test case groups 2642, which are test programs that detected that defect location.

[0050] Of these, test case group 2642 has data items for defect location 2643 and suspected value 2644. Defect location 2643 is set with information about the defect location detected by the test program related to test case group 2642. Suspected value 2644 is set with the suspected value (information indicating the likelihood of a defect existing) related to defect location 2643, calculated based on the test program related to test case group 2642.

[0051] Next, as shown in s804 in Figure 5, the execution priority determination unit 240 executes an execution priority determination process that determines the order in which to correct each component based on the test result information 263 and defect identification information 264 generated in s803. Details of the execution priority determination process s804 will be described later.

[0052] (Execution priority information) Here, Figure 8 shows an example of execution priority information 265 generated by the execution priority determination process. The execution priority information 265 includes data items for the component to be modified 2651, priority 2652, and APR result 2653.

[0053] The component 2651 to be modified contains information about each component of the program being verified.

[0054] Priority 2652 is assigned the order in which the components related to component 2651 to be modified will be modified. Specifically, priority 2652 is assigned the order in which the components set in the corresponding element 2632 of each record in the test result information 263 where the test result 2633 was "×" will be modified.

[0055] APR result 2653 contains information indicating whether the patch fix for the component related to component 2651 was successful.

[0056] Next, as shown in Figure 5, the automatic correction execution control unit 250 repeatedly performs the processes s805 to s809 described below (correction of the components whose correction order has been determined).

[0057] First, the automatic correction execution control unit 250 identifies the component with the highest correction priority among the components that have not yet been corrected (s804).

[0058] Specifically, for example, the automatic correction execution control unit 250 refers to each record of the execution priority information 265 and obtains the content of the component to be corrected 2651 of the record with the highest correction priority among the component corrections that have not been performed so far (s807 described later).

[0059] The automatic correction execution control unit 250 generates or acquires a correction program (patch candidate) to correct the defective part of the component identified in s804, and also acquires a test program to verify whether or not there is a defect in the component identified in s804 (s805).

[0060] A correction program (candidate patch) is a program that makes various changes to the faulty parts of the components (for example, adding, changing, or deleting various expressions such as conditional statements, adding, changing, or deleting variables, or adding, changing, or deleting functions, etc.), and one or more such programs may be created.

[0061] The automatic correction execution control unit 250 executes each correction program (patch candidate) acquired in s805 to generate temporary verification target programs that correct the components identified in s804 (s807).

[0062] The automatic correction execution control unit 250 then executes the test program acquired in s805 on each of the generated programs to be verified, thereby identifying a patch proposal from among the patch candidates. Specifically, the automatic correction execution control unit 250 identifies the patch candidate on which the execution result of the test program for that program was successful (no defects found) as the patch proposal (s807).

[0063] The automatic correction execution control unit 250 stores the execution results of the correction program (patch candidate) in the execution priority information 265 and the correction history information 266.

[0064] Specifically, for example, if the automatic correction execution control unit 250 can identify a patch proposal, it sets "○" to the APR result 2653 of the execution priority information 265, and if it cannot identify a patch proposal, it sets "×" to the APR result 2653 of the execution priority information 265.

[0065] (Revision history information) Figure 9 shows an example of correction history information 266. The correction history information 266 includes the number of the executed correction program (patch candidate) 2661, the component to be corrected by that patch candidate 2662, the number of times the correction by that patch candidate has been successful and unsuccessful so far (correction success / failure 2663), and the history of the time when that patch candidate was applied. It contains each data item of the correction application time history 2664.

[0066] Furthermore, the revision history information 266 may contain information not only about patch candidates but also about the generated patch proposal. For example, if a program under verification that was modified based on the patch proposal later develops a bug, that bug can be recorded in the revision history information 266 as a modification failure.

[0067] Next, as shown in s809 of Figure 5, the automatic correction execution control unit 250 determines whether or not there are any other components that have not been corrected.

[0068] Specifically, for example, the automatic correction execution control unit 250 refers to each record of the execution priority information 265 and determines whether there is a record in which information is set to priority 2652 and the correction of the component related to the component to be corrected 2651 has not been performed.

[0069] If there are any other components that have not been modified (s809:YES), the automatic modification execution control unit 250 repeats the process from s805 onwards for those components. If there are no other components that have not been modified (s809:NO), the program modification process ends (s810).

[0070] (Correction result information) Figure 10 shows an example of correction result information 267, which is information about the program under verification that has been modified by the program modification process. This correction result information 267 includes information about one or more programs under verification 920 that have been modified, and each program under verification 920 is associated with its name and storage location 910 (file name and folder, etc.). For example, the program 920 under verification may have a new function 921 added and some processing removed by a patch program (indicated by 922).

[0071] Next, we will explain the details of the execution priority determination process. <Execution priority determination process> Figure 11 is a flowchart illustrating the details of the execution priority determination process. The execution priority determination unit 240 identifies components that have dependencies on each other by referring to the corresponding elements 2632 of the test result information 263 and component information, and determines the order in which each component should be modified according to the identified dependencies (s821).

[0072] Specifically, for example, if a certain method is calling (executing) one or more different methods, the execution priority determination unit 240 will give a higher priority to the called method than to the calling method.

[0073] Furthermore, for example, if multiple methods each refer to another identical method, the execution priority determination unit 240 will give a higher priority to the multiple methods (the referencing methods) than to the referenced method.

[0074] Furthermore, if the programs to be verified have independent execution paths (method groups), the execution priority determination unit 240 may divide the test program information 262 into multiple test program information 262 corresponding to each execution path.

[0075] Next, the execution priority determination unit 240 determines the modification order for each component other than those for which the modification order has been set based on dependencies (s822).

[0076] For example, the execution priority determination unit 240 determines the past modifications of the modification program related to each component. The order in which each component needs to be modified is determined based on its success rate or the degree to which it needs to be corrected.

[0077] Regarding the success rate, for example, the execution priority determination unit 240 calculates the success rate of correction by the patch candidate for each component based on the patch success / failure status 2663 for each record in the correction history information 266. The execution priority determination unit 240 sets the correction order for each component according to the success rate (for example, in order of lowest or highest success rate). Note that the method of setting the correction order based on the success rate is not limited to what is described here; for example, a different correction order may be set only for components whose success rate is lower or higher than a predetermined threshold.

[0078] Regarding the degree of necessity, for example, the execution priority determination unit 240 calculates the modification frequency of each component based on the patch application history 2664 of each record in the modification history information 266, and identifies components whose modification frequency exceeds a predetermined threshold and the components around them (for example, components that are executed immediately before or after). The execution priority determination unit 240 sets the modification priority of the identified components higher than that of the other components. Note that the method of setting the modification priority based on modification frequency is not limited to what is described here; for example, the modification priority of each component may be set in order of decreasing modification frequency.

[0079] Furthermore, for example, the execution priority determination unit 240 determines the order in which each component is modified based on the number of patch candidates used to modify each component.

[0080] Specifically, the execution priority determination unit 240 calculates the number of patch candidates applied for the modification of each component based on the patch application history 2664 of each record in the modification history information 266. The execution priority determination unit 240 sets the modification order of the corresponding components according to the number of patch candidates (for example, in descending order of the number of patch candidates).

[0081] Furthermore, for example, the execution priority determination unit 240 determines the order in which each component should be corrected based on the execution time of the test program executed to identify the faulty part of each component.

[0082] Specifically, the execution priority determination unit 240 identifies the execution time of the test program for each component by referring to the test execution time 2634 in the test result information 263. The execution priority determination unit 240 sets the modification order of the corresponding components according to the length of the execution time (for example, in order of longest execution time).

[0083] Furthermore, for example, the execution priority determination unit 240 determines the order in which each component should be modified based on a predetermined importance level for each component (for example, in order of highest importance).

[0084] As described above, the program modification device 1 of this embodiment stores component information that associates each component of the program to be verified with each test program that verifies each component. By executing the test program, it identifies the component of the program to be verified that corresponds to the estimated defect in the program to be verified using the component information. Based on the relationships between the identified components, it determines the order in which each component should be modified, and according to this modification order, modifies each component of the program to be verified with its corresponding modification program.

[0085] In other words, the program correction device 1 of this embodiment sets the order of correction for each defective part according to the components of the program to be verified, and corrects the program to be verified according to this correction order. This enables efficient program correction according to the program's structure.

[0086] Furthermore, the program correction device 1 of this embodiment determines whether or not there is a processing dependency between each component in which the faulty part has been identified, and if it determines that there is a processing dependency, Based on this, different modification priorities are set between each component. This allows for efficient program modification according to the dependencies between each module in the program.

[0087] Specifically, for example, in this embodiment, if there is a dependency between the first component and the second component among the components in which a defect has been identified, the program modification device 1 sets the modification priority for the second component higher than that for the first component. This makes it possible to efficiently modify programs even with complex configurations where one module and other modules have a call-and-called relationship.

[0088] Furthermore, for example, in this embodiment, if the program modification device 1 has a dependency relationship where the first and second components of the identified defective components refer to information of the third component, the modification priority for the third component is set higher than the modification priority for the first and second components. This makes it possible to efficiently modify programs even for programs that have a configuration in which multiple modules refer to other common modules.

[0089] Furthermore, the program correction device 1 of this embodiment estimates the success rate or necessity of correcting each component whose faulty location has been identified, based on the correction history of each component, and determines the order in which to correct each component based on these. This makes it possible to respond flexibly, for example, by lowering the priority of correcting components that are difficult to correct, or by prioritizing the correction of components that are frequently corrected and therefore require correction.

[0090] Furthermore, the program correction device 1 of this embodiment determines the order of correction for each component based on the number of correction programs used to correct each component in which a defect has been identified. This allows for flexible responses, such as prioritizing the correction of components for which there are many candidates for correction.

[0091] Furthermore, the program correction device 1 of this embodiment determines the order of correction for each component based on the execution time of the test program for each component in which the faulty part has been identified. This allows for efficient program development by lowering the priority of corrections that require more time to address.

[0092] -Example 2- In Example 2, the program modification device 1, based on the test program, determines the order of modification for components related to the faulty parts identified, and updates the program under verification by modifying only the dependent components with the modification program. Then, the program modification device 1 runs each test program again on the newly updated program under verification.

[0093] Figure 12 is a diagram illustrating an example of a program modification process according to Embodiment 2. The program modification device 1 performs modifications on the program to be verified 1100, which has the component Compα, component Compβ, component CompA which depends on component Compα and component Compβ, and component Compγ.

[0094] The program modification device 1 identifies the location of the defect in each component of the program 1100 under verification by executing a test program for each component (s901; corresponding to s802-s803 in Example 1).

[0095] The program modification device 1 consists of components Compα, Compβ, and Com The program correction device 1 identifies the faulty parts in pγ and then in component CompA, and identifies that there are faulty parts in component Compα, component Compγ, and component CompA (s902. Corresponds to s801-s803 in Example 1). The program correction device 1 then generates correction programs (patch candidates) for each of component Compα, component Compγ, and component CompA (s903. Corresponds to s805-s806 in Example 1).

[0096] The program modification device 1 verifies the effectiveness of a modification when the modification program is applied to the program under verification by applying the modification program to the components Compα, Compγ, and CompA in that order (s904; corresponding to s807 in Example 1). The program modification device 1 identifies the modification program that is determined to be effective as a proposed patch (s905; corresponding to s808 in Example 1).

[0097] Here, the program modification device 1 generates a new program to be verified 1110 by applying the proposed patch for component Compα identified in s905 to only the dependent component Compα that has a dependent component (component CompA) among the components Compα, Compγ, and CompA whose verification has been deemed valid (s906).

[0098] Subsequently, the program modification device 1, in the same manner as s901, executes a test program for each component on the new program 1110 to be verified, which has the component Compα modified, thereby identifying the faulty part in each component. Since the modification of component Compα also modifies its dependent component CompA, the test program for the new program 1110 identifies only component Compγ as the faulty part.

[0099] In this way, the program modification device 1 of this embodiment (1) generates a new program to be verified that has been modified by each modification program corresponding to the dependent component among the components that have a dependent-dependent relationship, (2) estimates the location of the program defect by re-executing each test program on the new program to be verified, and (3) identifies the components corresponding to each estimated defect location and determines the order in which they should be modified. In this way, by first applying the modification program to the component that is a prerequisite for a certain component (the dependent component) and running the test again, the likelihood of being able to repair the dependent component increases. In this way, efficient program modification can be performed.

[0100] The present invention is not limited to the embodiments described above, and includes various modifications. The embodiments described above are explained in detail for a better understanding of the present invention and are not necessarily limited to those having all of the configurations described.

[0101] For example, some of the functions of each device in each embodiment may be provided in other devices, or functions provided by other devices may be provided in the same device.

[0102] Furthermore, the method for estimating the location of defects in the program under verification described in this embodiment is not limited to that described herein. For example, the location of defects may be estimated using parameters other than the suspected value. [Explanation of symbols]

[0103] 1 Program correction device, 260 Information storage unit, 220 Defect location estimation unit, 240 Execution priority determination unit, 250 Automatic correction execution control unit

Claims

1. a processor and a memory; an information storage unit that stores component information, which is information that associates information about each component of a program to be verified with information about each test program that verifies each component; a defect location estimation unit that estimates a defect location in the verification target program by executing each of the test programs; an execution priority determination unit that identifies each component of the program to be verified, which is related to each of the estimated defect locations, based on the component information, and determines a correction order for each of the components based on the relationship between the identified components; an automatic modification execution control unit that modifies each component of the program to be verified using a modification program corresponding to each component in accordance with the determined modification order; A program modification device comprising:

2. the execution priority determination unit determines whether or not there is a process dependency between the identified components, and if it determines that there is a process dependency, sets different modification priorities between the components based on the process dependency; The program correction device according to claim 1 .

3. the execution priority determination unit determines whether or not there is a dependency relationship in which a first component among the identified components causes a second component to be executed, and if it determines that there is such a dependency relationship, sets a modification priority for the second component higher than a modification priority for the first component; The program correction device according to claim 2 .

4. the execution priority determination unit determines whether or not there is a dependency relationship in which a first component and a second component among the identified components refer to information of a third component, and if it determines that there is such a dependency relationship, sets a modification priority for the third component higher than modification priorities for the first component and the second component; The program correction device according to claim 2 .

5. further comprising an information storage unit that stores a modification history of each of the components by the modification program; the execution priority determination unit estimates a success rate or a degree of necessity of modification of each of the identified components based on the modification history, and determines a modification order for each of the components based on the estimated success rate or degree of necessity. The program correction device according to claim 1 .

6. an information storage unit that stores, for each of the components, information on the number of the modification programs used to modify the components; the execution priority determination unit identifies the number of modification programs used to modify each of the identified components based on the information on the number of modification programs, and determines a modification order for each of the components based on the identified number of modification programs. The program correction device according to claim 1 .

7. further comprising an information storage unit that stores information on the execution time of the test program for each of the components; the execution priority determination unit estimates an execution time of each of the test programs related to each of the identified components based on the information on the execution times, and determines a correction order for each of the components based on the estimated execution times. The program correction device according to claim 1 .

8. the automatic correction execution control unit identifies components that are prerequisites for other components with respect to processing dependencies between the components, and generates a new verification target program corrected by the correction program corresponding to the identified components; the defect location estimation unit estimates a defect location in the new program to be verified by executing the plurality of test programs on the new program to be verified; the execution priority determination unit identifies, based on the component information, each component of the new program to be verified that is related to each of the estimated defect locations, and determines a correction order for each of the components based on the relationship between the identified components. The program correction device according to claim 1 .

9. The information processing device a configuration information storage process for storing component information that associates information about each component of the program to be verified with information about each test program that verifies each component; a defect location estimation process for estimating a defect location in the verification target program by executing a plurality of the test programs; an execution priority determination process for identifying each component of the program to be verified, which is related to each of the estimated defect locations, based on the component information, and determining a correction order for each of the components based on the relationships between the identified components; an automatic modification execution control process for modifying each component of the program to be verified by a modification program corresponding to each component in accordance with the determined modification order; Implementing a program modification method.

10. In the information processing device, a configuration information storage process for storing component information that associates information about each component of the program to be verified with information about each test program that verifies each component; a defect location estimation process for estimating a defect location in the verification target program by executing a plurality of the test programs; an execution priority determination process for identifying each component of the program to be verified, which is related to each of the estimated defect locations, based on the component information, and determining a correction order for each of the components based on the relationships between the identified components; an automatic modification execution control process for modifying each component of the program to be verified by a modification program corresponding to each component in accordance with the determined modification order; Run the program fix.

Images