JP2015011372A - Debug support system, method, program, and recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a debug support system for improving efficiency in debugging software, and a method, a program, and a recording medium.SOLUTION: A debug support system includes: a version management unit which inputs/outputs history information such as creation date and time of first and second source codes; a source code comparison unit which compares the first and second source codes; a test item execution unit which records a path of processing when a test with a plurality of test items is executed on the second source code; a relation difference information extraction unit which extracts difference information on a relation located in a path where a test item with a bug has passed; and a correction revision extraction unit which extracts a revision including the extracted relation difference information from the version management unit.

Description

  The present invention relates to a debugging support system, method, program, and recording medium.

  In recent years, software development includes not only new development but also development related to maintenance and improvement of existing software. For example, after operation of existing software, a request to add software functions, a specification change to a new version, etc. occurs due to changes in the user's business content, usage, work content, etc. Even when defects are found, it is necessary to correct the program accordingly.

  As a result of these occurrences, it may be necessary to modify a program having other existing functions that are affected by the modified function or program. Causes an error (degrade bug, hereinafter referred to as a bug) that causes an error that prevents normal operation.

  Therefore, in the maintenance and improvement of existing software, the same tests as those performed before the modification were performed to confirm that the parts whose specifications do not change when the software is modified perform the same operation as before the modification. Implementation of the item is performed. Such a test is called a regression test.

  In general, the regression test is often automated by using a test support tool or the like. In order to identify the code that caused the bug while checking the test result, examine the input contents for testing and the contents of the bug, and in which process of which route from inputting test data to outputting it The work (debugging work) that has to find out if a bug has occurred must be done manually.

  In addition to simply fixing the code identified as a bug by testing, we investigate the cause of the programmer's coding of the code that caused the bug, and no other similar problems occur. It is also important to confirm whether

  Normally, when debugging a program, the entire target program is handled, so if the program becomes large, it takes time to identify the cause of the bug when debugging, which deteriorates the efficiency of program development. . For this reason, various debugging support technologies are being developed.

  So far, as a debugging support technique, for example, there is a technique described in Patent Document 1 (Japanese Patent Application Laid-Open No. 2004-118443). In Patent Document 1, design data and a test bench (test program) for verifying the function of an LSI (large scale integration) circuit designed by a hardware description language are transferred to a simulation apparatus while performing version management and difference checking. By supplying and performing a regression test by simulation and re-simulation, a regression test can be executed every time a design change occurs, and a regression test based on the latest design data can always be performed.

  However, in the above technique, when there is a difference between the design data already registered in the system and the newly input design data, it is determined whether or not a regression test should be executed based on the difference, and based on the difference When the influence range cannot be specified, the regression test can always be executed by combining the latest design data and the test bench. However, Patent Document 1 extracts only the part related to the test item in which the difference is included in the test item, and combines information on when the related difference information was created. The problem remains that it is necessary to perform the output operation.

  As another debugging support technique, there is a technique described in Patent Document 2 (Japanese Patent Laid-Open No. 2007-199800). In Patent Document 2, the correction target including the correction content is detected by comparing the source code before and after the correction of the program specified by the user's operation, and the influence content affected by the correction target is linearly affected by the correction target. Including affected objects can be detected.

  According to Patent Literature 2, it is possible to effectively prevent omission of the investigation of the influence range of the program correction target, and support the correction work in the influence range with high reliability. However, as in Patent Document 1, only the part related to the correction target that is a bug is extracted in Patent Document 2, and information on when the related correction content was created is also output. There still remains a problem that it is necessary to work.

  Further, as another debugging support technique, there is a technique described in Patent Document 3 (Japanese Patent Laid-Open No. 2010-122959). In Patent Document 3, detailed analysis of the program is not required, and even if the user does not specify a change location, based on the passing module information of each test item and the module that has been changed before and after correction, Test items to be executed as a regression test can be extracted.

  According to Patent Document 3, if the program is changed, only the changed part of the changed program, that is, paying attention to the difference of the program, can verify the validity of the changed program. Is efficient. However, the test support system of Patent Literature 3 can extract test items using the passing module information and modules that have been changed before and after the program correction. However, it is not possible to perform processing for outputting information indicating which test item has the difference between the source code before and after the correction, and when the difference was created.

  Furthermore, as another debugging support technique, there is a technique described in Patent Document 4 (Japanese Unexamined Patent Application Publication No. 2009-211124). In Patent Literature 4, the version number stored in the degradation determination database, the determination target test identification information indicating identification information of a test that may be degraded, and one or more correction positions corresponding to the combination thereof are provided. Based on the correction position information to be shown, it is possible to automatically determine a portion where a regression test is necessary.

  According to Patent Document 4, it is possible to extract a test that requires a regression test, and to automate the test from failure detection to a corrected regression test. However, as in the test support system of Patent Document 3, the information on which test item the source code difference before and after the failure detection was in, and when the difference was created, was added. The process of outputting cannot be performed.

  Furthermore, as another debugging support technique, there is a technique described in Patent Document 5 (Japanese Patent Laid-Open No. 2008-129661). In Patent Document 5, a plurality of function identifiers that specify a plurality of functions included in a program that has been corrected by past correction, and a plurality of functions that are included in the program that has been corrected in the new correction and the function identifier. The number of function identifiers that match among a plurality of function identifiers to be identified is obtained, and based on the number of function identifiers that match, the modification identified by the modification identifier of the function included in the program that has been modified by past modifications ( Determine the priority of the test case to test its past modifications. The developer of the program can determine the priority indicating the high possibility that a test case among the listed test cases is likely to cause an error again due to the change according to the determined priority.

  However, in the above technology, the priority of the test case is determined when further corrections are required with respect to past corrections. The new corrections identified the functions that become bugs again and caused the bugs. There remains a problem that it is necessary to identify the correction part.

  Furthermore, as another debugging support technique, there is a technique described in Patent Document 6 (Japanese Patent Laid-Open No. 2007-4255). In Patent Document 6, by presenting the difference information between the source code at the time of normal operation and the source code at the time of the bug, the efficiency of the work for identifying the correction location causing the bug is improved. ing.

  However, in the above technology, since the difference information includes information that does not have a relationship that exists in the test item that became a bug, only the difference information portion that has a relationship that exists in the path through which the test item that caused the bug has passed is extracted. The information on when the difference information of the extracted relationship was created cannot be output.

  Therefore, many debugging support technologies have been proposed, but only the part of the relationship that exists in the path through which the test item that caused the bug in the difference information has been extracted, and when the difference information of the relationship was created. There is still a problem that it is necessary to output the information together.

JP 2007-004255 A Japanese Patent Application No. 2012-280814 JP 2010-152715 A JP 2008-129661 A JP 2008-129661 A JP 2008-129661 A

  The present invention has been made in view of such problems, and a main object of the present invention is to provide a debugging support system, method, program, and recording medium that can improve the efficiency of software debugging.

In order to achieve the above object, the debugging support system of the present invention includes a first source code and a second source in which at least a part of the source code included in the first source code is modified or changed. Version management unit that inputs / outputs history information such as source code creation date / time, modification date / time, modification location, and source code creation or revision, and
A source code comparison unit that compares the first source code and the second source code output from the version management unit and outputs difference information;
A test item execution unit that records a path through which a process passes when a test of a plurality of test items is executed on the second source code in association with the test item;
An execution path information storage unit that stores an execution path recorded by the test item execution unit;
A relationship in which a test item that becomes a bug based on the difference information exists in an execution path that passes through the execution path stored in the execution path information storage unit and the difference information output by the source code comparison unit. A relational difference information extraction unit for extracting difference information having
And a revision revision extracting unit that extracts a revision in which the difference information having the extracted relationship is generated from the version management unit.

The debugging support method of the present invention includes a first source code from the version management unit, and a second source code in which at least a part of the source code included in the first source code is modified or changed. Output
Compare the first source code and the second source code output from the version management unit, output the difference information,
A path through which the process passes when a test of a plurality of test items is executed on the second source code is recorded in association with the test item;
Save the execution path recorded by the test item execution unit,
Referencing the execution path stored in the execution path information storage unit and the difference information output by the source code comparison unit, the difference in the relationship existing in the execution path through which the test item that caused the bug has passed from the difference information Extract only information,
The revision in which the difference information of the extracted relationship has occurred is extracted from the version management unit.

Furthermore, the present invention provides a process for outputting a first source code and a second source code in which at least a part of the source code included in the first source code is modified or changed from the version management unit. When,
A process of comparing the first source code and the second source code output from the version management unit and outputting difference information;
A process of recording a path through which a process passes when a test of a plurality of test items is executed on the second source code in association with a test item;
Processing for storing an execution path recorded by the test item execution unit;
Referencing the execution path stored in the execution path information storage unit and the difference information output by the source code comparison unit, the difference in the relationship existing in the execution path through which the test item that caused the bug has passed from the difference information A process to extract only information,
Provided is a debugging support program that causes a computer to execute a process of extracting a revision in which the extracted difference information of the extracted relationship is generated from the version management unit.

Furthermore, the present invention outputs the first source code from the version management unit and the second source code in which at least a part of the source code included in the first source code is modified or changed. Processing,
A process of comparing the first source code and the second source code output from the version management unit and outputting difference information;
A process of recording a path through which a process passes when a test of a plurality of test items is executed on the second source code in association with a test item;
Processing for storing an execution path recorded by the test item execution unit;
Referencing the execution path stored in the execution path information storage unit and the difference information output by the source code comparison unit, the difference in the relationship existing in the execution path through which the test item that caused the bug has passed from the difference information A process to extract only information,
Provided is a recording medium on which is recorded a program that causes a computer to execute a process of extracting a revision in which the extracted difference information of the extracted relationship is generated from the version management unit.

  According to the present invention, there is an effect that it is possible to improve the efficiency of specifying the cause of the bug.

1 is a block diagram illustrating a configuration of a debugging support system according to a first embodiment of the present invention. It is a flowchart figure which shows the procedure which extracts the difference information and revision information of the relationship which concern on the 1st Embodiment of this invention. It is explanatory drawing which shows the source code of description before the change which concerns on the 1st Embodiment of this invention. It is explanatory drawing which shows the return value (expected value) assumed as three test items with respect to the source code before the change which concerns on the 1st Embodiment of this invention. It is explanatory drawing which shows an example of the source code of description after the change which concerns on the 1st Embodiment of this invention. It is explanatory drawing which shows another example of the described source code after the change which concerns on the 1st Embodiment of this invention. It is explanatory drawing which shows the path | route which three test items based on the 1st Embodiment of this invention passed. It is explanatory drawing which shows only the path | route which the test item used as the bug passed among three test items which concern on the 1st Embodiment of this invention. It is a block diagram which shows the structure of the debug assistance system which concerns on the 2nd Embodiment of this invention. It is a block diagram which shows an example of the hardware constitutions of the debug assistance system which concerns on the 1st Embodiment of this invention.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
[First Embodiment]
FIG. 1 is a configuration diagram of a debugging support system 100 according to the present embodiment. The debug support system 100 includes a version management unit 101, a source code comparison unit 104, a test item execution unit 105, an execution path information storage unit 106, a relational difference information extraction unit 107, a modified revision extraction unit 108, and a display unit 109.

  Hereinafter, functions of each unit constituting the debug support system 100 will be described.

  The version management unit 101 includes a first storage unit 102 that stores a source code when operating normally (hereinafter referred to as a normal operation source code), and a source code when a bug occurs (hereinafter referred to as an error). A second storage unit 103 for storing source code at the time of occurrence), and history information such as source code creation date and time, modification date and time, modification location, and source code creation or modification number (revision) Store, change and input / output.

  As the first storage unit 102 and the second storage unit 103, an HDD (Hard Disk Drive), an SSD (Solid State Drive), a DRAM (Dynamic Random Access Memory), or the like can be used. The first storage unit 102 and the second storage unit 103 may be a single storage unit. An external storage device may be used.

  Further, the source code of this embodiment includes a plurality of modules. A module is a logical component of a program defined in source code. In the source code after the change, at least a part of the module of the source code before the change is modified or changed.

  That is, the normal operation source code represents the source code at the time when the test was operating normally. The error source code represents the source code at the time of error occurrence in the regression test. As for the source code when an error occurs, at least a part of the module of the source code during normal operation is corrected or changed.

The source code during normal operation and the source code when an error occurs are stored in the first storage unit 102 and the second storage unit 103, respectively. The version management unit 101 stores, changes, and inputs / outputs history information such as source code developer, commit message, creation date / time, modification date / time, modification location, and source code creation number or revision number (revision). Is managing.
When the user instructs the start of the regression test, the source code comparison unit 104 can acquire the normal operation source code and the error generation source code by making an inquiry to the version management unit 101.

  The source code comparison unit 104 compares the acquired normal operation source code with the error source code, identifies the changed content, and relates to the program function change from the specified change content Is output to the related difference information extraction unit 107 as difference information.

  The test item execution unit 105 stores path information indicating which module (hereinafter referred to as a path) each test item to be tested passes when executing the test of the modified source code. Stored in the unit 106.

  Further, the test item execution unit 105 extracts only the test items in error from the test target test items when the test of the modified source code is executed, and limits the information on the test items in error. Thus, route information indicating which route the test item passes through may be recorded in the execution route information storage unit 106.

  The execution path information storage unit 106 includes a storage device such as a hard disk drive (HDD), a solid state drive (SSD), a dynamic random access memory (DRAM), and the like, and a plurality of test items for the corrected source code. The path through which the process passes when the test is executed is stored in association with the test item.

  Further, the execution path information storage unit 106 may also serve as a test item execution unit that executes a test of each test item for the corrected source code. In that case, the test item execution unit (corresponding to the test item execution unit 105) records the execution path information of the test item in the storage device while executing the test of each test item. An external device may be used as the storage device.

  The relation difference information extraction unit 107 is a test that has become a bug as a result of the test based on the passage route information of each test item stored by the execution path information storage unit 106 and the difference information output by the source code comparison unit 104. Difference information having a relationship existing in the path through which the item has passed is extracted and output to the revision revision extracting unit 108. The test results here are those executed from the test item execution unit 105.

  The revision revision extraction unit 108 inquires the version management unit 101 for the revision information in which the difference is generated, extracts the relation difference information output by the relation difference information extraction unit 107, and outputs it to the display unit 109.

The display unit 109 is a display device. In this case, the display unit 109 is a display, and displays the relationship difference information output from the relationship difference information extraction unit 107 and the revision information output from the modified revision extraction unit 108. The display unit may use an external display device.
<Description of operation for extracting difference information and revision information>
FIG. 2 shows a procedure for extracting relational difference information and revision information in the regression test of the present invention.

  When the user instructs a regression test, the source code comparison unit 104 acquires the normal operation source code 102 and the error occurrence source code 103 from the version management unit 101, compares them, and specifies the change contents.

  Changes here include things such as the developer's name, revision and commit message changes that do not change the program's functions, and minor changes in the source code that accompany the program's function changes.

For example, a class, a method name, a function, and the like are extracted from the identified change contents, for example, and output to the related difference information extraction unit 107 as difference information (step S11).
In addition, the test item execution unit 105 obtains an execution path for each test item, stores it in the execution path information storage unit 106, and outputs it to the related difference information extraction unit 107 (step S12).
Next, the relationship difference information extraction unit 107 compares the difference information output by the source code comparison unit 104 with the execution path information stored by the execution path information storage unit 106, and determines the path through which the test item that caused the bug has passed. Only the difference information of the existing relationship is extracted and output to the revision revision extracting unit 108 (step S13).

  Then, the revision revision extracting unit 108 inquires the version management unit 101 about the revision information in which the difference is output, and obtains the revision, and outputs it to the display unit 109 (step S14). ).

Finally, the display unit 109 displays the relationship difference information extracted by the relationship difference information extraction unit 107 and the revision information in which the difference has occurred, and presents it to the user (step S15).
(First embodiment)
Hereinafter, the operation of the embodiment of the present invention will be described using specific examples.

  First, FIG. 3 shows the source code described before correction. For the description of the source code, a programming language such as C language or an object-oriented programming language can be used. The source code is not limited to the source code of the software program, and may be a hardware source code described in a hardware description language (HDL) or the like. Further, the language used for the description of the source code before and after the correction may be a common language or a separate language.

  In this embodiment, a common Java (registered trademark) language is used. The source code is assumed to be managed by the version management unit.

  As shown in FIG. 3, the registrant is developer A, the commit message is “V1.0 source code registration”, and the source code describes three classes, Main, SubA, and SubB. The registered revision is 1.

  FIG. 4 shows three test items for which the regression test is performed in this embodiment and expected return values (expected values). For example, when testing “test item 1”, the func method of the Main class is called with an argument = 0, and the process described in the source code is performed.

  When testing “test item 2”, the func method of the Main class is called with an argument = 1, and the process described in the source code is performed.

  Further, when testing “test item 3”, the func method of the Main class is called with an argument = −1, and processing described in the source code is performed.

  When the test of the three test items shown in FIG. 4 is performed on the source code before correction, all the test items return the expected results.

  Next, FIG. 5 and FIG. 6 show the source code of the description after correction. In FIG. 5, the registrant is developer B, the commit message is “define SubB m method processing as a utility method”, and the source code includes Main, SubA, SubB, and Util. The class is described and the registered revision is 2.

  As shown in FIG. 5, the “Main.func” method and the “SubA.m” method are not changed, the “SubB.m” method is changed, and a new Util. The m method is created, and the SubB m method processing is defined as a utility method. Then, the Util class method is called from the SubB class.

  In FIG. 6, the registrant is developer C, the commit message is “Modify SubA processing to use utility method”, and the source code includes Main, SubA, SubB, and Util. Four classes are described, and the registered revision is 3.

  As shown in FIG. 6, the “Main.func” method has not been changed, and in addition to the change of the “SubB.m” method, the “SubA.m” method has also been changed, and a new Util.m method has been changed. The process of the SubA m method is created as a utility method.

  The source code is further changed to call the method of the Util class from the SubA class.

  The user performs a regression test using the test items in FIG. 4 in order to confirm that the specification of the program has not been changed with respect to the modified source code shown in FIG.

  At this time, the source code comparison unit 104 compares the source code before correction (source code shown in FIG. 3) with the source code after correction (source code shown in FIG. 6) in step S11 of FIG.

  Further, the source code comparison unit 104 identifies the changed content by comparing texts described in the source code.

  In the present embodiment, the specified change content includes a registrant, a commit message, a revision, and a “SubA.m method, SubB.m method, and Util.m”.

  Note that the contents of the change related to the program function change are “SubA.m method, SubB.m method and Util.m”, and this change information is extracted as difference information and output to the related difference information extraction unit 107.

  Further, in step S12 of FIG. 2, the test item execution unit 105 executes each test item, and stores the path passing through each test item in the execution path information storage unit 106 for each test item. As shown in FIG. 7, a path through which three test items have passed is shown.

  For example, in test item 1, the func method of the Main class is called with an argument = 0, so the conditional expression (a> 0) on the third line becomes negative, and SubB. The m method is called with argument = 0. SubB. In the m method, Util. Since the m method is called, the execution path information is Main. func, SubB. m, Util. m, and the information is stored in the execution path information storage unit 106.

  In test item 2, since the func method of the Main class is called with argument = 1, the conditional expression (a = 1) on the third line becomes positive, and SubA. The m method is called with argument = 1. SubA. In the m method, Util. Since the m method is called, the execution path information is Main. func, SubA. m, Util. m, and the information is stored in the execution path information storage unit 106.

  In test item 3, since the func method of the Main class is called with argument = -1, the conditional expression (a = -1) on the third line becomes negative, and SubB. The m method is called with argument = -1. SubB. In the m method, Util. Since the m method is called, the execution path information is Main. func, SubB. m, Util. m, and the information is stored in the execution path information storage unit 106.

  FIG. 7 shows information stored in the execution path information storage unit 106 after all the test items are executed. In this embodiment, only the method name executed as execution path information is saved, but more detailed lines may be saved.

  As an execution means of the test item execution unit 105, for example, in the case of a test using JUnit in Java, a means of acquiring coverage information using a coverage tool such as jcoverage can be considered.

  As another means, for example, a test is executed on the source code when an error occurs, for example, a debug statement is added at the start or end of a method, and a test is executed, and the executed method information is acquired from the debug statement. Is also possible. Any means may be used for the test item execution unit 105.

Further, as shown in FIG. 8, the test item execution unit 105 stores, in the execution path information storage unit 106, only the path through which the test item 3 that has become a bug passes among the three test items.
In step S13, the relationship difference information extraction unit 107 refers to the execution path information (FIG. 7) stored in the execution path information storage unit 106, and executes the execution path information of the test item 3 that is NG (error) in the regression test. “Main.func, SubB.m, Util.m” is acquired from the execution path information storage unit 106.

  Further, the relation difference information extraction unit 107 receives “SubA.m method, SubB.m method and Util.m” as the difference information from the source code comparison unit 104, and executes the execution path information of the test item 3 that has become NG. Only the difference information existing in is extracted.

  Referring to FIG. 7, the paths executed in the test item 3 are “Main.func”, “SubB.m”, and “Util.m” methods.

  On the other hand, since the difference information acquired from the source code comparison unit 104 in step S11 of FIG. 2 is “SubA.m method, SubB.m method and Util.m”, the difference information of the relationship is “SubB.m”. "And" Util.m "methods.

  Then, in step S13 of FIG. 2, the relationship difference information extraction unit 107 extracts two of the relationship difference information, “SubB.m method and Util.m”.

  In step S14, the revision revision extracting unit 108 extracts the SubB. m method and Util. For each of the m methods, the version management unit 101 is inquired about a revised revision.

  As shown in FIG. m method and Util. Since both m have been changed in revision 2, the version management unit 101 outputs the revision information (in this case, the number 2) to the revised revision extraction unit 108.

  In step S15, the display unit 109 generates the relationship difference information (SubB.m method and Util.m method) extracted by the relationship difference information extraction unit 107 and the difference information extracted by the revision revision extraction unit 108. Revision information (in this case, the number 2) is received, and SubB. m method and Util. Display that m method and revision 2 should be confirmed.

In the display unit 109, the class and method name to be confirmed, and the difference information between the source code before the correction and the source code after the correction, the difference information having a relationship that exists in the path through which the test item having the bug passes, The revision information in which the difference has occurred is displayed together. However, the revision information may be a link to the revision information to the version management unit. When there are a plurality of revision revisions to the same location, either the latest revision information or all of the revision information may be displayed. They shall be switched by setting.
[Second Embodiment]
Next, a second embodiment of the present invention will be described in detail with reference to the drawings. In the description of the present embodiment, in addition to the input / output unit, the display unit, and the transmission / reception unit of the debug support system 800 according to the second embodiment of the present invention, the debug support system according to the first embodiment of the present invention. Since it has a system configuration similar to 100 and steps that operate in the same manner, detailed description thereof will be omitted.

  That is, the configuration of the debug support system 900 according to the second embodiment of the present invention is as shown in FIG. 9. The debug support system 900 includes an input / output unit 901 having a keyboard 902 and a mouse 903, and a source code comparison unit 904. , A test item execution unit 905, a relationship difference information extraction unit 906, a modified revision extraction unit 907, a display unit 908 having a display 909, and a transmission / reception unit 910.

  The debugging support system 900 is connected to an external device via a network 911.

  The input / output unit 901 includes a storage device 912. A keyboard 902 and a mouse 903 are connected to each other, and signals sent from the keyboard 902 and the mouse 903 are transferred to each unit via a bus.

  The user operates the input / output unit 901 to access an external device via the network 911 and, for example, is input via an external recording medium such as a CD-ROM or communicates with the network via a network such as a LAN or the Internet. Information necessary for debugging work from a server or the like that can be connected, for example, source code at normal operation, source code at the time of error occurrence, source code creation date / time, modification date / time, modification point and source code creation, History information such as the number (revision) at the time of change is stored in the storage device 912 via the transmission / reception unit.

  The source code comparison unit 904 compares the normal operation source code acquired from the transmission / reception unit with the error source code, and identifies the changed content. The change content related to the function change is extracted from the specified change content, and is output to the related difference information extraction unit 906 as difference information.

  When executing the test of the modified source code, the test item execution unit 905 extracts path information indicating which path each test item to be tested passes through and passes it to the relational difference information extraction unit 906.

  The relationship difference information extraction unit 906 passes the path through which the test item that caused the bug has passed based on the passage route information of each test item received from the test item execution unit 905 and the difference information output by the source code comparison unit 904. Only the difference information of the relations existing in is extracted.

  The revision revision extracting unit 907 inquires the storage device 812 and extracts the revision information in which the difference is generated, regarding the difference information of the relationship output by the relationship difference information extracting unit 906.

  The display unit 908 is connected to an external display device, for example, a display 909. The display unit 908 combines the relationship difference information output from the relationship difference information extraction unit 906 and the revision information output from the revised revision extraction unit 907. 909 is displayed.

  If there is a user instruction, the transmission unit 910 transmits the relationship difference information and revision information displayed on the display unit 908 to an external device via the network 911.

  As a result, in the debug support system as the second embodiment of the present invention, the difference information of the relationship existing in the path through which the test item that caused the bug has passed and the revision information in which the difference information has occurred are presented to the user together It is possible to transmit the information to an external device according to a user instruction.

  As described above, according to the first and second embodiments of the present invention, in the regression test, the difference information on the relationship existing in the path through which the test item that caused the bug has passed and the revision information in which the difference information has occurred. Therefore, it is possible to improve the efficiency of software debugging.

  In the above-described embodiments of the present invention, the processing functions described with reference to the flowcharts can be realized by a computer. In that case, a program describing the processing contents of the functions that the debug support system should have is provided.

  FIG. 10 is a block diagram illustrating an example of a hardware configuration of the debugging support system according to the first embodiment or the second embodiment of the present invention.

  As shown in FIG. 10, the processing functions of the debugging support system according to the first embodiment or the second embodiment of the present invention are a computer program stored in a ROM 1003 (Read Only Memory) or a storage device (HDD) 1004. The CPU 1001 (Central Processing Unit) reads the program into the RAM 1002 (Random Access Memory) and executes the program, thereby realizing the processing functions on the computer.

The internal configuration of the debugging support system is an example. The debugging support system may include only the CPU 1001 and operate using the storage device 1004, the external device connection interface 1005, and the network interface 1006 provided outside.

  Further, the program describing the processing contents can be recorded on a computer-readable recording medium. Examples of the computer-readable recording medium include a magnetic recording device, an optical disk, a magneto-optical recording medium, and a semiconductor memory.

  Examples of the magnetic recording device include an HDD, a flexible disk (FD), and a magnetic tape (MT). Optical discs include DVD (Digital Versatile Disc), DVD-RAM, CD-ROM (Compact Disc-Read Only Memory), CD-R (Recordable) / RW (Rewritable), and the like. Magneto-optical recording media include MO (Magneto-Optical disk).

When distributing the above program, for example, a DVD on which the program is recorded,
Portable recording media such as CD-ROMs are sold. It is also possible to store the program in a server computer and transfer the program from the server computer to another computer via a network.

The computer that executes the program stores, for example, the program recorded on the portable recording medium or the program transferred from the server computer in its own storage device.

Then, the computer reads the program from its own storage device and executes processing according to the program. The computer can also read the program directly from the portable recording medium and execute processing according to the program.

  Further, each time the program is transferred from the server computer, the computer can sequentially execute processing according to the received program.

  Although the embodiment of the present invention has been described above, the above description merely shows the principle of the present invention. The present invention is not limited to the configurations and application examples shown and described above, and many variations and modifications can be made by those skilled in the art.

  Furthermore, other arbitrary components and processes may be added to the present invention. Further, the present invention may be a combination of any two or more configurations (features) of the above-described embodiments.

  The present invention can be applied to software development in general including maintenance or improvement work, for example.

DESCRIPTION OF SYMBOLS 100 Debug support system 101 Version management part 102 1st memory | storage part 103 2nd memory | storage part 104 Source code comparison part 105 Test item execution part 106 Execution path information storage part 107 Relational difference information extraction part 108 Correction revision extraction part 109 Display part 900 debug support system 901 input / output unit 902 keyboard 903 mouse 904 source code comparison unit 905 test item execution unit 906 relation difference information extraction unit 907 modified revision extraction unit 908 display unit 909 display unit 910 transmission / reception unit 911 network 912 storage device 1001 CPU
1002 RAM
1003 ROM
1004 Storage device 1005 External device connection interface 1006 Network interface

Claims (8)

Creation date / time, change date / time, change location and source of source code between the first source code and the second source code in which at least part of the source code included in the first source code is modified or changed A version management unit that inputs and outputs history information such as revisions at the time of code creation or modification;
A source code comparison unit that compares the first source code and the second source code output from the version management unit and outputs difference information;
A test item execution unit that records a path through which a process passes when a test of a plurality of test items is executed on the second source code in association with the test item;
An execution path information storage unit that stores an execution path recorded by the test item execution unit;
A relationship in which a test item that becomes a bug based on the difference information exists in an execution path that passes through the execution path stored in the execution path information storage unit and the difference information output by the source code comparison unit. A relational difference information extraction unit for extracting difference information having
A debugging support system comprising: a revision revision extracting unit that extracts a revision in which difference information having the extracted relationship has occurred from the version management unit.   The debugging according to claim 1, wherein the version management unit includes a first storage unit that stores the first source code and a second storage unit that stores the second source code. Support system.   The test item execution unit extracts only test items in error when executing tests on a plurality of test items with respect to the second source code, and limits information on the test items in error. The debugging support system according to claim 1 or 2, wherein route information indicating which route the test item passes through is recorded. Outputting a first source code from the version management unit and a second source code in which at least a part of the source code included in the first source code is modified or changed;
Compare the first source code and the second source code output from the version management unit, output the difference information,
A path through which the process passes when a test of a plurality of test items is executed on the second source code is recorded in association with the test item;
Save the execution path recorded by the test item execution unit,
Referencing the execution path stored in the execution path information storage unit and the difference information output by the source code comparison unit, the difference in the relationship existing in the execution path through which the test item that caused the bug has passed from the difference information Extract only information,
A debugging support method, comprising: extracting a revision in which the extracted difference information of the relationship has occurred from the version management unit.   When the test of a plurality of test items is executed on the second source code, only the test items that are in error are extracted, and the information on the test items that are in error is limited, 5. The debugging support method according to claim 4, wherein route information indicating which route is passed is recorded. A process of outputting the first source code from the version management unit and the second source code in which at least a part of the source code included in the first source code is modified or changed;
A process of comparing the first source code and the second source code output from the version management unit and outputting difference information;
A process of recording a path through which a process passes when a test of a plurality of test items is executed on the second source code in association with a test item;
Processing for storing an execution path recorded by the test item execution unit;
Referencing the execution path stored in the execution path information storage unit and the difference information output by the source code comparison unit, the difference in the relationship existing in the execution path through which the test item that caused the bug has passed from the difference information A process to extract only information,
A debugging support program for causing a computer to execute a process of extracting a revision in which the extracted difference information of the extracted relationship is generated from the version management unit.   When the test of a plurality of test items is executed on the second source code, only the test items that are in error are extracted, and the information on the test items that are in error is limited, The debugging support program according to claim 6, wherein a process of recording route information indicating which route is passed is performed. A process of outputting the first source code from the version management unit and the second source code in which at least a part of the source code included in the first source code is modified or changed;
A process of comparing the first source code and the second source code output from the version management unit and outputting difference information;
A process of recording a path through which a process passes when a test of a plurality of test items is executed on the second source code in association with a test item;
Processing for storing an execution path recorded by the test item execution unit;
Referencing the execution path stored in the execution path information storage unit and the difference information output by the source code comparison unit, the difference in the relationship existing in the execution path through which the test item that caused the bug has passed from the difference information A process to extract only information,
A recording medium on which a program for causing a computer to execute a process of extracting the revision in which the extracted difference information of the extracted relationship is generated from the version management unit is recorded.

Images