JP2018018197A - Source code evaluation program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an estimation program allowing a spot having a high possibility of containing a bug to be automatically evaluated.SOLUTION: A source code evaluation device 10 causes a computer to execute a difference detection part 11 for detecting a description which is a difference between a first source code and a second source code after modification of the first code and determining whether or not the difference is according to the modification of a bug based on a content of the detected difference; a generation part 12 for dividing the description used as the difference and generating a vector which arranges a numerical value defined according to the type of each phrase in order of each phrase in the description; a learning part 13 for learning a relationship with a determination result by the vector and the difference detection part; and a recognition part 15 for generating the vector relating to any description of a third source code and evaluating a possibility of the bug being contained in the description based on a learning result by the vector and the learning part.SELECTED DRAWING: Figure 2

Description

  The present invention relates to a source code evaluation program.

  In software development, bug detection is an important task for ensuring the quality of software.

  In general, bug detection is performed by performing a test based on a test specification created by a developer or the like. Such work has a heavy work burden on the worker and has a difficulty in efficiency.

  Therefore, techniques for supporting bug detection have been studied (for example, Non-Patent Document 1 and Non-Patent Document 2).

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.

  However, in the above-described conventional technology, it is difficult to automatically estimate a portion that may contain a bug in a detailed unit such as a line unit or a sentence unit.

  The present invention has been made in view of the above points, and an object of the present invention is to enable automatic estimation of a portion that is highly likely to contain a bug in a source code.

  Therefore, in order to solve the above problem, the source code evaluation program detects a description that is a difference between the first source code and the second source code after the change of the first source code, and the detected difference is detected. Based on the content, a difference detection unit that determines whether or not the difference is due to a bug correction, and the description that becomes the difference is divided into lexical terms, and numerical values defined according to the types of the lexical terms Description of any one of a generation unit that generates a vector arranged in the order of each lexical word in the description, a learning unit that learns a relationship between the vector and a determination result by the difference detection unit, and a third source code The computer functions as an evaluation unit that generates the vector and evaluates the possibility that a bug is included in the description based on the vector and a learning result by the learning unit. That.

  It is possible to automatically estimate a portion that is likely to contain a bug in the source code.

It is a figure which shows the hardware structural example of the source code evaluation apparatus in embodiment of this invention. It is a figure which shows the function structural example of the source code evaluation apparatus in embodiment of this invention. It is a flowchart for demonstrating an example of the process sequence of a learning process. It is a figure for demonstrating the detection of a difference, and provision of a bug correction presence / absence label. It is a figure for demonstrating the production | generation of a lexical vector. It is a figure for demonstrating learning of the relationship between a lexical vector and a bug correction presence / absence label. It is a figure which shows an example of a neural network. It is a flowchart for demonstrating an example of the process sequence of a source code evaluation process.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a diagram illustrating a hardware configuration example of a source code evaluation apparatus according to an embodiment of the present invention. The source code evaluation device 10 in FIG. 1 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, a display device 106, an input device 107, etc., which are mutually connected by a bus B. .

  A program that realizes processing in the source code evaluation apparatus 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 storing the program is set in the drive device 100, the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100. However, the program need not be installed from the recording medium 101 and may be downloaded from another computer via a network. The auxiliary storage device 102 stores the installed program and also stores necessary files and data.

  The memory device 103 reads the program from the auxiliary storage device 102 and stores it when there is an instruction to start the program. The CPU 104 realizes functions related to the source code evaluation device 10 according to a program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network. The display device 106 displays a GUI (Graphical User Interface) or the like by a program. The input device 107 includes a keyboard and a mouse, and is used for inputting various operation instructions.

  FIG. 2 is a diagram illustrating a functional configuration example of the source code evaluation apparatus according to the embodiment of the present invention. 2, the source code evaluation device 10 includes a difference detection unit 11, a lexical vector generation unit 12, a learning unit 13, an evaluation target analysis unit 14, a recognition unit 15, and the like. Each of these units is realized by a process that the CPU 104 causes one or more programs installed in the source code evaluation apparatus 10 to execute. The source code evaluation device 10 also uses a VCS repository 121, a difference storage unit 122, a label storage unit 123, a lexical DB 124, a lexical vector storage unit 125, and a learning information storage unit 126. These various storage units can be realized using, for example, a storage device that can be connected to the memory device 103, the auxiliary storage device 102, or the source code evaluation device 10 via a network.

  The VCS repository 121 is a repository of a version control system (VCS (Version Control System)) (not shown). For example, the VCS repository 121 stores a source code file, its change history, revision number, and the like.

  Based on the information stored in the VCS repository 121, the difference detection unit 11 detects the difference before and after the source code change (before and after the revision). Information regarding the detected difference is stored in the difference storage unit 122. The difference detection unit 11 also determines, for each difference, whether or not the difference is due to bug correction based on the content of the difference, and a label indicating the determination result (hereinafter, “bug correction presence / absence label”). Is stored in the label storage unit 123 in association with each difference.

  For each difference stored in the difference storage unit 122, the lexical vector generation unit 12 divides a description (description on the source code) that becomes the difference into a lexical (token). The lexical vector generation unit 12 generates a vector in which numerical values defined according to the type of each lexical are arranged in the order of each lexical in the description that is the difference. Hereinafter, this vector is referred to as a “lexical vector”. The generated lexical vector is stored in the lexical vector storage unit 125. The numerical values defined according to the lexical type are stored in the lexical DB 124.

  The learning unit 13 learns the relationship between each lexical vector and the bug correction presence / absence label associated with the difference between the lexical vector generation sources, and stores the learning result in the learning information storage unit 126.

  The evaluation object analysis unit 14 generates a lexical vector for a certain part (a certain line, a certain sentence, a certain expression, or the like) of the source code that is an object to be evaluated for bugs.

  The recognition unit 15 may apply the lexical vector generated by the evaluation target analysis unit 14 to the learning result stored in the learning information storage unit 126, and a bug may be included at a location corresponding to the lexical vector. Assess sex.

  Hereinafter, a processing procedure executed by the source code evaluation device 10 will be described. FIG. 3 is a flowchart for explaining an example of the processing procedure of the learning process. The processing procedure in FIG. 3 is started, for example, when a learning execution instruction is input by the user.

  In step S101, the difference detection unit 11 detects (extracts) a difference for every two revisions before and after the revision stored in the VCS repository 121 for all source codes of a program, and detects the detected difference. Store in the difference storage unit 122. The difference may be generated in, for example, a diff output format.

  Subsequently, for each detected difference, the difference detection unit 11 determines whether the difference is due to bug correction based on the content of the difference, and displays a bug correction presence / absence label indicating the determination result. The difference is given (S102). The given bug correction presence / absence label is stored in the label storage unit 123 in association with each difference. The association between the difference and the bug correction presence / absence label may be realized, for example, by associating each difference identification information (hereinafter referred to as “difference ID”) stored in the difference storage unit 122 with a correction presence / absence label. .

  FIG. 4 is a diagram for explaining the difference detection and the bug correction presence / absence label assignment. FIG. 4 shows an example in which a difference is detected for every two previous and subsequent revisions (that is, every revision N before change and revision N + 1 after change) for a certain source code having a change history of revision 1 to revision 6. It is shown. Specifically, the difference d1 is detected as the difference between revision 1 and revision 2, the difference d2 is detected as the difference between revision 2 and revision 3, and the difference d3 is calculated as the difference between revision 3 and revision 4. Has been detected.

  The contents of the difference are added descriptions and deleted descriptions. In FIG. 4, “+” is assigned to the added description, and “−” is assigned to the deleted description. Note that the difference does not necessarily have to be in units of rows. This is because one sentence or one expression may span a plurality of lines. For example, assuming that a range until a line feed code is detected as one unit, a difference may be detected for each unit.

  FIG. 4 also shows bug correction presence / absence labels L1 to L3 for each difference. The value of the bug correction presence / absence label is either “bug correction” or “not bug correction”. In the present embodiment, “difference in bugs” is indicated for a difference in which both the reduced description and the increased description exist (that is, a place where a certain description is replaced with another description) at locations corresponding to each other. It is determined, and the difference that is not so is determined as “not a bug correction”. This is because a place replaced with another description is likely to be a bug correction empirically.

  Subsequently, for each difference stored in the difference storage unit 122, the lexical vector generation unit 12 performs lexical analysis on the content of the difference (description of the source code), and divides the description into lexical characters (tokens) ( S103). Note that the difference to which the bug correction presence / absence label “is a bug correction” is added includes a deleted description and an added description. In this case, the deleted description is divided into each phrase.

  Subsequently, the lexical vector generation unit 12 obtains a numerical value stored in the lexical DB 124 in association with the type of the lexical phrase (identifier, basic type of variable, keyword indicating control structure, parentheses, etc.) for each lexical phrase. (S104). Subsequently, the lexical vector generation unit 12 generates a lexical vector by arranging the acquired numerical values in the order in which each lexical is arranged, and stores the lexical vector in the lexical vector storage unit 125 (S105). Each lexical vector is stored in the lexical vector storage unit 125 in association with the difference ID of the source difference.

  FIG. 5 is a diagram for explaining generation of a lexical vector. FIG. 5 shows an example in which the deleted description in the difference d2 is divided into lexical terms, and an array of numerical values corresponding to each lexical type (conditional sentence, identifier) is generated as the lexical vector v2. . That is, a lexical vector is generated for the deleted description. This is because when a description is replaced with another description, there is a high possibility that a bug is included in the certain description (that is, the deleted description).

  For a difference consisting of N lexical terms, an N-dimensional lexical vector is generated. In addition, there is a large difference in numerical values between a type, an identifier, and the like, and a keyword or parenthesis representing a control structure. That is, the difference in numerical values corresponding to each type having relatively high relevance in the source code is relatively small, and the numerical value corresponding to each type having relatively low relevance in the source code is relatively large. A numerical value corresponding to the type is defined in the lexical DB 124. By doing so, the difference in the pattern for each description can be made remarkable, and the meaning of the source code can be defined.

  Specifically, in FIG. 5, the numerical value of “if” representing the control structure is 200, which is greatly different from the numerical values of other lexical phrases. Also, since “(” and “)” have a correspondence relationship, the numerical values corresponding to them are 100 and 101, respectively, and the difference between them is small.

  Subsequently, the learning unit 13 inputs a set of the lexical vector and the bug correction presence / absence label for each difference to the learning algorithm, and learns the relationship between the lexical vector and the bug correction presence / absence label (S106). That is, the relationship between the source code description pattern and the presence or absence of bugs is learned. The learning unit 13 stores the learning result in the learning information storage unit 126. Note that learning is performed using a supervised binary classifier, for example.

  FIG. 6 is a diagram for explaining learning of the relationship between the lexical vector and the bug correction presence / absence label. FIG. 6 shows an example in which the relationship between the lexical vector v2 generated for the difference d2 and the bug correction presence / absence label L2 given to the difference d2 is learned, and the learning result is stored in the learning information storage unit 126. It is shown.

  For example, when a neural network is used in a supervised binary classifier, parameters (coefficients) that define the neural network as shown in FIG. 7 are stored in the learning information storage unit 126. Regarding neural networks, for example, “Rumelhart, David E .; Hinton, Geoffrey E .; Williams, Ronald J. (8 October 1986).“ Learning representations by back-propagating errors ”. Nature 323 (6088): 533 -536. "

  In addition, when the number of dimensions of the lexical vector is less than the number of input dimensions of the binary classifier (64 lexicons in FIG. 7), the learning unit 13 moves the lexical vector to the center and fills the left and right with zeros. Extend the number of dimensions of the lexical vector. In addition, when the number of dimensions of the lexical vector is larger than the number of input dimensions of the binary classifier, the learning unit 13 extracts the lexical equivalent of the number of input dimensions in the front-rear direction from the numerical value arranged at the center of the lexical vector. By doing so, the number of dimensions of the lexical vector is reduced. In other words, where the length of each line of the source code varies, it is possible to grasp even a part of the characteristics as the source code. In addition, since centered information can bring highly important information to the center, it is possible to perform highly accurate learning by reflecting the main features.

  Next, processing for evaluating the possibility of bugs in a certain source code based on the learning result stored in the learning information storage unit 126 will be described.

  FIG. 8 is a flowchart for explaining an example of the processing procedure of the source code evaluation processing. For example, when the source code to be evaluated is designated by the user and an evaluation start instruction is input, the process of FIG. 8 is started.

  In step S201, the evaluation object analysis unit 14 inputs a description of a predetermined unit (hereinafter referred to as “object description”) from the source code to be evaluated. The predetermined unit is, for example, a unit divided by a line feed code.

  Subsequently, the evaluation target analysis unit 14 generates a lexical vector for the target description (S202). The generation method of the lexical vector is as described above.

  Subsequently, the recognition unit 15 applies the learning result of the learning information storage unit 126 to the generated lexical vector, and evaluates the possibility that the target description includes a bug (potential of bug). (S203). For example, an object description may be input to a neural network as shown in FIG. In this case, when the number of dimensions of the lexical vector is less than the number of input dimensions of the binary classifier (64 lexicons in FIG. 7), the recognition unit 15 puts the lexical vector in the center and fills the left and right with zeros. Extend the number of dimensions of the lexical vector. Further, when the number of dimensions of the lexical vector is larger than the number of input dimensions of the binary classifier, the recognition unit 15 reduces the number of dimensions of the lexical vector by extracting the center of the lexical vector.

  When the source code to be evaluated is a new source code, the processing procedure in FIG. 8 may be executed in order from the beginning for each description of the source code. On the other hand, when the existing source code is modified, the process of FIG. 8 may be executed for a part of the modified description. The corrected description may be specified by the user.

  As described above, according to the present embodiment, it is possible to automatically estimate a portion that is likely to contain a bug in the source code after the start of program manufacture. As a result, for example, in the development of large-scale software, the development period can be shortened and an improvement in productivity can be expected.

  In the present embodiment, the lexical vector generation unit 12 is an example of a generation unit. The recognition unit 15 is an example of an evaluation unit.

  As mentioned above, although the Example of this invention was explained in full detail, this invention is not limited to such specific embodiment, In the range of the summary of this invention described in the claim, various deformation | transformation・ Change is possible.

DESCRIPTION OF SYMBOLS 10 Source code evaluation apparatus 11 Difference detection part 12 Lexical vector generation part 13 Learning part 14 Evaluation object analysis part 15 Recognition part 100 Drive apparatus 101 Recording medium 102 Auxiliary storage apparatus 103 Memory apparatus 104 CPU
105 Interface device 121 VCS repository 122 Difference storage unit 123 Label storage unit 124 Lexical DB
125 Lexical vector storage unit 126 Learning information storage unit B bus

Claims (3)

A description which is a difference between the first source code and the second source code after the change of the first source code is detected, and the difference is based on a bug correction based on the content of the detected difference. A difference detection unit for determining whether or not there is,
A generation unit that divides the description to be the difference into words and generates a vector in which numerical values defined according to the types of the words are arranged in the order of the words in the description;
A learning unit for learning a relationship between the vector and the determination result by the difference detection unit;
An evaluation unit that generates the vector for any description of the third source code, and evaluates a possibility that the description includes a bug based on the vector and a learning result by the learning unit;
A source code evaluation program characterized by causing a computer to function as: The difference in numerical values corresponding to each of the above-mentioned various types having relatively high relevance in the source code is relatively small, and the difference in numerical values corresponding to each of the various types having relatively low relevance in the source code is relatively large A numerical value corresponding to the type is defined in
The source code evaluation program according to claim 1, wherein: The learning unit extracts a predetermined number of numerical values in the front-rear direction from the numerical values arranged in the center of the vector, and learns the relationship between the extracted numerical vector and the determination result by the difference detection unit,
3. The source code evaluation program according to claim 1 or 2,

Images