JP2016024784A - Bug prediction device, method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To predict a function including many bugs to be found in a test process about created software during a period after starting a manufacturing process and before starting the test process.SOLUTION: Under assumption that as many as places which have been modified in the near past are likely to be modified in the near future, functions of software related to functions including many bugs are estimated by: acquiring a change history of source codes; limiting to only revisions where it is determined that modification of the bugs is performed according to the change history; creating a matrix for deriving change places of the source codes having strong functional relationship; and clustering the matrix.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a bug prediction apparatus, method, and program, and more particularly, to a bug prediction apparatus, method, and program for predicting a bug in a source code.

  A technique for predicting likely bugs in the source code from successive versions of the source code (see, for example, Non-Patent Document 1), and many corrections on the source code tend to be corrected in the near future. There is a bug prediction technique based on the empirical rule that there is (see, for example, Non-Patent Document 2).

  In addition, there is a many-to-many mapping technique from source code to function based on an empirical rule that parts that tend to be changed at the same time in the source code are highly functionally related (for example, see Non-Patent Document 3). ).

Y. Higo, K. Murao, S. Kusumoto, K. Inoue, "Predicting Fault-Prone Modules Based on Metrics Transitions", DEFECTS '08. S. Kim, T. Zimmermann, E.J.Whitehead, and A. Zeller, "Predicting faults from cached history," ICSE '07. R. Robbes, D. Pollet, and M. Lanza, "Logical coupling based on fine-grained change information," WCRE '08. "An efficient algorithm for large-scale detection of protein families". A. J. Enright *, S. Van Dongen and C.A. Ouzounis, Nucleic Acids Research, 2002, Vol. 30, No. 7 1575-1584. "Extraction of technical terms based on appearance frequency and connection frequency", Hiroshi Nakagawa, Tomoaki Yumoto, Tomonori Mori, Natural Language Processing 2003. "Identifying Linux bug fixing patches", Yuan Tian; J .: Lo, D., ICSE 2012.

  However, the technique of Non-Patent Document 1 described above has a problem that the result of bug prediction is “module”, and “functions” with many bugs cannot be obtained.

  The technique of Non-Patent Document 2 can predict the position on the source code where a bug is likely to be included, but does not require a “function” with many bugs.

  The technique of Non-Patent Document 3 is a candidate for a function with many bugs by applying the technique of Non-Patent Document 3 after obtaining the source code part with many bugs by the techniques of Non-Patent Documents 1 and 2 described above. There is a problem that it is not possible to specify which of the candidates actually contains a bug.

  The present invention has been made in view of the above points, and it is possible to predict a function including many bugs to be found in the test process in the period after the start of the manufacturing process and before the start of the test process for the created software. It is an object to provide a bug prediction apparatus, method, and program.

According to one aspect, a bug prediction apparatus for detecting a function including many bugs in a source code,
Functionality is limited to only revisions that can be determined that bugs have been corrected based on the assumption that changes made in the near past are likely to be corrected in the near future. A bug prediction apparatus having a bug estimation means for estimating a function of software having a function including many bugs by creating a matrix for deriving a change point of a source code having a strong relation and clustering the matrix is provided. The

  According to one aspect, it is possible to specify the function of software that includes many bugs to be found in the test process after the manufacturing process starts and before the test process starts.

The structural example of the bug prediction apparatus in one embodiment of this invention. The structural example of the VCS repository in one embodiment of this invention. The flowchart of the outline | summary operation | movement of the bug prediction apparatus in one embodiment of this invention. The example of the matrix produced | generated by the correction location matrix registration part in one embodiment of this invention. The detailed flowchart of the change location registration process in one embodiment of this invention. The detailed flowchart of the bug correction revision registration process in one embodiment of this invention. The detailed flowchart of the correction location matrix preparation process in one embodiment of this invention. The detailed flowchart of the correction location matrix initialization process in one embodiment of this invention. The detailed flowchart of the clustering process in one embodiment of this invention. The detailed flowchart of the feature word extraction process in one embodiment of this invention. The detailed flowchart of the cluster feature word extraction process in one embodiment of this invention.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  In the present invention, it is known from the change history of the source code that “the portion corrected in the near past is easier to be corrected in the future”, and that the bug can be predicted, and the change in the source code In a history, a series of source code parts that tend to change co-occurringly with shared revisions, together with feature word extraction using source code comments and commit messages, when forming a cluster with strong functional relationships Thus, it is assumed that related function candidates can be derived.

  FIG. 1 shows a configuration example of a bug prediction apparatus according to an embodiment of the present invention.

  A bug prediction apparatus 1 shown in the figure is connected to a user terminal 2 and outputs a function with many bugs in response to an inquiry from the user terminal 2.

  The bug prediction device 1 includes a change location registration unit 10, a bug correction revision registration unit 20, a correction location matrix registration unit 30, a clustering unit 40, a feature word extraction unit 50, a VCS (Version Control System) repository 11, and a change location storage unit 12. A bug correction revision storage unit 13, a correction location matrix storage unit 14, and a cluster storage unit 15.

  The VCS repository 11 generally has a function as shown in FIG. The revision storage unit 111 stores a managed file name, file content, and commit message for each revision. When there is a commit operation from the user terminal 2, the file difference extraction function 112 acquires the file name, commit message, and new revision that have been added, changed, or deleted, and is stored in the user's local file and revision storage unit 111. Compare the latest revision files and extract the differences. The revision recording function 113 adds the difference, the commit log, and the revision number to the revision storage unit 111 and notifies the user terminal 2 that the processing is completed. The inter-revision difference calculation function 114 obtains two revision numbers by a user comparison operation, and obtains a difference (existence of a file, contents of a file) between the two revisions. The function name derivation function 115 derives the function name at the location based on the context before and after the location of the difference. The commit message extraction function 116 extracts all the commit messages between two revisions, and returns the contents of the difference, the function name of the difference part, and the commit message. In FIG. 1, the VCS repository 11 is provided in the bug prediction apparatus 1. However, the present invention is not limited to this example, and may be provided outside the bug prediction apparatus 1.

  Next, the process of each part in said structure is demonstrated.

  FIG. 3 is a flowchart of an outline operation of the bug prediction apparatus according to the embodiment of the present invention.

  Step 210) Upon receiving an inquiry from the user terminal 2, the change location registration unit 10 reads revisions from the VCS repository 11, collects the change locations of each revision, and registers them in the change location storage unit 12. Specification of the location of the VCS repository 11 is input as an inquiry from the user terminal 2. Also, the collected changes include a file name and a function name. The change location storage unit 12 has a change revision list which is a list of revisions of the collected change locations. Detailed processing will be described with reference to FIG.

  Step 220) Based on the commit message read from the VCS repository 11, the bug correction revision registration unit 20 registers a revision that can be determined to have corrected the bug in the bug correction revision storage unit 13.

  Step 230) The correction part matrix registration unit 30 selects one of the revisions of the bug correction registered in the bug correction revision storage unit 13 in Step 220 for the set of change parts registered in the change part storage unit 12 in Step 210. Second, a matrix is created that indicates whether the two changes are changed together. Specifically, as shown in FIG. 4, one matrix is created for each bug correction revision. The size of the matrix is the number of changes in both rows and columns. The matrix represents that both changes have been changed in a particular revision. If there is a change location i and a change location j, if i and j are both changed in the revision of interest, the matrix element (i, j) is set to "1", otherwise it is set to "0". . The example of FIG. 4 shows that only the changes 1 and 2 are changed in a certain revision.

  The obtained matrix is registered in the corrected part matrix storage unit 14.

  Step 240) The clustering unit 40 applies the clustering algorithm to the set of corrected location matrices registered in the corrected location matrix storage unit 14, thereby making the highly relevant changed locations a cluster. Specifically, a technique (for example, Non-Patent Document 4) that reads a correction part matrix from the correction part matrix storage unit 14 and obtains a highly relevant subgraph from a plurality of given graphs with respect to the correction part matrix. By applying, a cluster as a classification result is obtained. The cluster is composed of a set of changed portions and is stored in the cluster storage unit 15.

  Step 250) The feature word extraction unit 50 obtains the name of the software function that is considered to contain a bug in the cluster storage unit 15 by extracting the feature word for the commit message. Specifically, the clustering result is read from the cluster storage unit 15, and the name of the software function is acquired for each cluster. The processing content is that all correction points constituting the cluster are referred to the change point storage unit 12 to obtain a list of change revisions from all the change points, and then a commit message in each revision is sent to the bug correction revision storage unit. 13, a feature word extraction algorithm such as a natural language processing method (see, for example, Non-Patent Document 5) that extracts a characteristic word is applied to the commit message group. The obtained feature word is output to the user terminal 2 as a software function name that is considered to contain a bug.

  Next, the details of the change location registration process in step 210 will be described.

  FIG. 5 is a detailed flowchart of the change location registration process according to the embodiment of the present invention.

  The following steps 310 to 330 are repeated for all revisions in the VCS repository 11.

  Step 310) The change location registration unit 10 compares the i-th revision of interest in the VCS repository 11 with the previous revision, and extracts the difference. When extracting a difference, a VCS diff command is assumed, and differences indicated by symbols such as “+”, “−”, “*”, and “!” Are classified and held for each difference portion.

  Step 320) For each difference obtained in Step 310, the function name where the difference portion is located is acquired. If it cannot be obtained, a nearby symbol name is used.

  Step 330) The difference part is registered in the changed part storage unit 12.

  Next, details of the bug correction revision registration process in step 220 will be described.

  FIG. 6 is a detailed flowchart of the bug correction revision registration process according to the embodiment of the present invention.

  The bug correction revision registration unit 20 repeats the following steps 410 to 440 for all the revisions in the read VCS repository 11.

  Step 410) A commit message of the revision read from the VCS repository 11 is acquired.

  Step 420) Based on the commit message, a method (for example, Non-Patent Document 6) for determining whether or not the patch includes a bug fix is applied to determine whether or not an expression representing a bug correction is included.

  Step 430) If an expression representing a bug correction is included, the process proceeds to step 440. If not included, the process returns to step 410.

  Step 440) If the commit message includes an expression representing bug correction, the revision number and the commit message are registered in the bug correction revision storage unit 13.

  Next, details of the correction location matrix creation processing in step 230 will be described.

  FIG. 7 is a detailed flowchart of the correction location matrix creation process according to the embodiment of the present invention.

  Step 510) The correction location matrix registration unit 30 reads the revision from the bug correction revision storage unit 13.

  Step 520) Let Rv be the number of read revisions.

  Step 530) The changed part is read from the changed part storage unit 12.

  Step 540) Let P be the number of read changes.

  Step 550) The number of processed revisions rev is initialized to zero.

  Step 560) The correction location matrix is initialized. Detailed processing will be described with reference to FIG.

  Step 570) Set rev = rev + 1.

  Step 580) If rev <Rv, the process returns to Step 560, and if rev ≧ Rv, the process of the modified part matrix registration unit 30 is terminated.

  Next, the process of step 560 will be described in detail.

  FIG. 8 is a detailed flowchart of the correction location matrix initialization process according to the embodiment of the present invention.

  Step 6010) The correction part matrix registration unit 30 reads the rev-th change part from the change part storage part 12, and sets it to R.

  Step 6020) A T = P × P zero matrix (where P is the number of changed locations read from the changed location storage unit 12).

  Step 6030) The changed part i is set to i = 0.

  Step 6040) The changed portion j is set to j = i + 1.

  Step 6050) It is determined whether both the i-th and j-th unique changed portions are included in R.

  Step 6060) If yes, go to Step 6070, otherwise go to Step 6080.

  Step 6070) T (i, j) = T (j, i) = 1.

  Step 6080) j = j + 1.

  Step 6090) If j <P, go to Step 6040, and if j ≧ P, go to Step 6100.

  Step 6100) The changed part i is set to i = i + 1.

  Step 6110) If i <P, return to Step 6040, and if i ≧ P, go to Step 6120.

  Step 6120) The matrix T and the revision rev are registered in the corrected part matrix storage unit 14.

  Next, details of the clustering process in step 240 of FIG. 3 will be described.

  FIG. 9 is a detailed flowchart of the clustering process according to the embodiment of the present invention.

  Step 710) The clustering unit 40 retrieves the correction part matrix for each revision from the correction part matrix storage unit 14.

  Step 720) Clustering is performed by applying an existing method (for example, Non-Patent Document 4) for obtaining a highly relevant part from a plurality of given graphs to the extracted correction matrix group.

  Step 730) The clusters clustered in Step 720 are registered in the cluster storage unit 15.

  Next, the details of the feature word extraction process in step 250 of FIG. 3 will be described.

  FIG. 10 is a detailed flowchart of the feature word extraction process according to the embodiment of the present invention.

  Step 810) The feature word extraction unit 50 reads all the clusters from the cluster storage unit 15.

  Step 820) All changed portions are read from the changed portion storage unit 12.

  Step 830) Cluster feature word extraction processing is performed for all the clusters read in step 810. Details will be described in detail with reference to FIG.

  Step 840) The feature word obtained in step 830 is output as a buggy function represented by the cluster.

  The cluster feature word extraction process in step 830 will be described.

  FIG. 11 is a detailed flowchart of cluster feature word extraction processing according to an embodiment of the present invention.

  Step 910) The feature word extraction unit 50 obtains the changed part constituting the cluster read from the cluster storage unit 15.

  Step 920) Acquire a set of revisions whose changed portions are changed.

  Step 930) Document D on the memory (not shown) is set to D = φ.

  Step 940) The commit message of each revision in the set of revisions acquired in Step 920 is read from the bug correction revision storage unit 13.

  Step 950) Add a revision commit message to document D.

  Step 960) After the processes of Steps 940 and 950 are repeated for all revisions in the revision set, feature word extraction for the document D is executed. The feature word extraction process can be realized by applying an existing feature word extraction technique including a natural language processing method (for example, Non-Patent Document 5) that extracts a characteristic word.

  The bug prediction apparatus 1 according to the present embodiment can be realized, for example, by causing one or a plurality of computers to execute a program describing the processing content described in the present embodiment. In other words, the functions of the bug prediction device 1 are realized by executing a program corresponding to the processing executed by the bug prediction device 1 using hardware resources such as a CPU, memory, and hard disk built in the computer. Is possible. Further, the program can be recorded on a computer-readable recording medium (portable memory or the like), stored, or distributed. It is also possible to provide the program through a network such as the Internet or electronic mail.

  The present invention is not limited to the above-described embodiments, and various modifications and applications are possible within the scope of the claims.

DESCRIPTION OF SYMBOLS 1 Bug prediction apparatus 2 User terminal 10 Change location registration part 11 VCS (Version Control System) repository 12 Change location storage part 13 Bug correction revision storage part 14 Correction part matrix storage part 15 Cluster storage part 20 Bug correction revision registration part 30 Correction part Matrix registration unit 40 Clustering unit 50 Feature word extraction unit 111 Revision storage unit 112 File difference extraction function 113 Revision recording function 114 Revision difference calculation function 115 Function name derivation function 116 Commit message extraction function

Claims (7)

A bug prediction device for detecting a function including many bugs in source code,
Functionality is limited to only revisions that can be determined that bugs have been corrected based on the assumption that changes made in the near past are likely to be corrected in the near future. A bug characterized by having a bug estimation means for estimating a function of software having a function that includes many bugs by creating a matrix for deriving a source code change part having a strong relation and clustering the matrix Prediction device. The bug estimation means is:
At least a change history for each revision of the source code, a change history storage means storing a commit message,
Change location registration means for extracting a change location for each revision from the change history storage means and registering a change revision list in the change location storage means;
A revision that can be determined that a bug has been corrected from the change history storage means, based on the commit message, and that is registered in the bug correction revision storage means;
For the change revision list acquired from the change location storage means, a matrix indicating whether two change locations are changed for each corrected revision acquired from the bug correction revision storage means is generated, and the correction location matrix storage means Correction location matrix registration means to be registered in
Clustering for the matrix of the correction location matrix storage means, clustering the highly relevant change locations between each other, clustering means for storing in the cluster storage means,
Based on all the changed portions constituting each cluster acquired from the cluster storage unit, the revision of the changed portion is acquired from the changed portion storage unit, and based on the revision, the revision of each revision is acquired from the bug correction revision storage unit. A feature word extraction means for extracting the name of the function of the software presumed to include a bug by acquiring a commit message and extracting a feature word of the commit message;
The bug prediction apparatus according to claim 1, comprising: The corrected location matrix registration means includes:
The number of rows and columns of the matrix is the number of changed parts. If the changed part i and the changed part j are both changed for each revised revision, the matrix element (i, j) is set to 1. , Otherwise includes a means of 0,
The clustering means includes
3. The bug prediction apparatus according to claim 2, further comprising means for clustering the changed part matrix having an element (i, j) of 1 in the matrix. A bug prediction method in a device for detecting a function containing many bugs in source code,
Functionality is limited to only revisions that can be determined that bugs have been corrected based on the assumption that changes made in the near past are likely to be corrected in the near future. A bug is characterized in that a bug estimation step for estimating a function of software of a function including many bugs is created by creating a matrix for deriving a source code change part having a strong relation and clustering the matrix. Prediction method. In the bug estimation step,
At least a change history for each revision of the source code, a change location registration step for extracting a change location for each revision from the change history storage means storing the commit message and registering a change revision list in the change location storage means;
A bug correction revision registration step of extracting a revision that can be determined to have corrected a bug from the change history storage means based on the commit message, and registering the revision in the bug correction revision storage means;
For the change revision list acquired from the change location storage means, a matrix indicating whether two change locations are changed for each corrected revision acquired from the bug correction revision storage means is generated, and the correction location matrix storage means A correction location matrix registration step to be registered in
Clustering with respect to the matrix of the corrected location matrix storage means, clustering the highly relevant change locations together, and storing in the cluster storage means,
Based on all the changed portions constituting each cluster acquired from the cluster storage unit, the revision of the changed portion is acquired from the changed portion storage unit, and based on the revision, the revision of each revision is acquired from the bug correction revision storage unit. A feature word extraction step of extracting a name of a software function that is estimated to include a bug by obtaining a commit message and extracting a feature word of the commit message;
The bug prediction method of Claim 4 which has these. In the modified location matrix registration step,
The number of rows and columns of the matrix is the number of changed parts. If the changed part i and the changed part j are both changed for each revised revision, the matrix element (i, j) is set to 1. , Otherwise 0,
In the clustering step,
The bug prediction method according to claim 5, wherein clustering is performed on the changed portion matrix having an element (i, j) of 1 in the matrix. Computer
A bug prediction program for functioning as each means of the bug prediction apparatus according to claim 1.

Images