JP2010067188A - Information processor for supporting programming, information processing system, and programming support method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an information processor for supporting programming, an information processing system, and an information processing method and program. <P>SOLUTION: A verification server 110 for detecting a change in a source code includes a source code reading part 210 for acquiring a new version and an old version of the source code, a source code comparing part 220 for comparing code difference between the new version and the old version, a difference code registering part 230 for extracting a differed code and generating a difference code set, and a source code executing part 240 for acquiring test cases added after the old version in accordance with the change to execute the test cases in order to execute all codes relating to a specific function of the changed source code, calculates a product set of the difference code set and an executed code set, and generates a specific difference code set in which a code changed in relation to a specific function unit is defined as an element node. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a programming support technology, and more particularly to an information processing apparatus, an information processing system, a programming support method, and a program for supporting cooperative programming by a plurality of developers.

  Currently, software that provides an application for executing a specific task is composed of an enormous amount of source code. The source code also has various attributes such as a program that is called at runtime and controlled by the application, such as a dynamic link library and a plug-in program, in addition to the program constituting the application main body. In such application development, an operation for identifying a specific code of a source code corresponding to a function is an important operation as an operation prior to understanding the function and correcting a bug in the source code.

  In conventional software development, the emphasis is on the correspondence between application specifications and functions, so in order to maintain synchronization between the specifications and source code when changing specifications such as adding requirements. , Manage the correspondence between units using a tool that easily recognizes the correspondence between source codes (for example, Rational (Registered Trademark) Requisite Pro (trademark) manufactured by International Business Machines Corporation) .

  However, since the functions required for applications are becoming more and more diverse and the product cycle tends to be shortened, XP (Extreme Programming: eXtreme Programming) has recently been aimed at increasing the efficiency of application development. As represented by agile, agile software development in which many developers collaborate to create programs has become widespread. In agile software development represented by XP, coding and testing are important, and the source code corresponding to the specification change may occur even when new source code that is not described in the original specification exists. . For this reason, when trying to identify the source code corresponding to the latest function, it takes a lot of time to identify the source code related to the added new function only by referring to the specification, and the XP environment. Managing program development in the world becomes increasingly difficult.

  In order to cope with the problem of identifying a difference in code between source codes, a diff command (http://www.gnu.org/software/) conventionally prepared as a shell command in UNIX (registered trademark) or the like. diffutils / diffutils.html: Non-Patent Document 1) is used. The diff command is a shell command that specifies two files and executes a process to determine the lines that have been added, deleted, or changed between the two files. Sources added for two source codes with different versions It is possible to identify the code set of the code. In many version control systems, the diff command is used internally, and the diff command recognizes its effectiveness with respect to checking the editing contents, such as extracting the editing part between two versions of the program. Has been.

  As an OS level command having a similar function, for example, the comp command in MS-DOS (registered trademark) can be cited, and the comp command is also written in text by being executed from the MD-DOS shell. Can detect differences in source code. Other programs that perform file comparison at the application level are also known.

  As described above, a program for detecting a code that differs between two source codes is known. However, in an agile program development environment, there are cases where additions and changes are made across a plurality of specific functional units between two source code versions and these are tested at the same time. It has been difficult to identify code sets that have undergone changes such as additions and modifications in the associated source code. FIG. 13 shows a schematic change inspection procedure 1300 of the source code using the conventional diff command.

  As shown in FIG. 13, the source code evolves as a change set 1310 to a change 1340 with a different version name corresponding to the change of each unit providing the functional module. In the conventional example shown in FIG. 13, one change set, for example, a change set 1320, includes units 1322, 1324 with version names such as “A.clac_v1”, “B.class_v0”, and “C.class_v0”, respectively. 1326.

  In the change set 1320, the function α of the unit 1322 is modified from the unit 1312 of the version name “A.class_v0” corresponding to the previous change set 1310. Further, in the change set 1330, the function β is changed to the unit 1324 and the unit 1326, respectively. As a result, the change set 1330 that has received each modification includes units 1334 and 1336 with version names “B.class_v1” and “C.class_v1”, respectively.

  Further, in the change set 1340, the function γ and the function ω are changed in response to the unit change by the programmer. As a result, the change set 1340 includes units 1342, 1344, 1346 having version names “A.class_v2”, “B.class_v1”, and “C.class_v2”.

  A source code change inspection procedure to which a conventional diff program is applied will be examined using the change inspection procedure 1300 shown in FIG. As for the inspection of each specific function unit shown in FIG. 13, only the unit 1312 and the unit 1322 related to a single specific function are changed between the change set 1310 and the change set 1320. For this reason, the code related to the same functional unit can be extracted even if the diff command is used, and the code set extending over a plurality of specific functional units is not extracted in parallel even in the diff program. it can.

  Also, between the change set 1320 and the change set 1330, a plurality of units related to the function β are changed. In this case, it can be said that there is little inconvenience when the unit related to the function β is created by a specific programmer or a group of programmers. On the other hand, if unit 1334 and unit 1336 related to function β are created by different programmers or groups of programmers, it may be preferable to perform the tests separately even for code related to function β. .

  The above-described conventional example is sufficiently effective when the programming is streamlined to some extent and it is not expected that a plurality of specific functions are added between tests, or when there are no units related to a specific function. is there.

  However, another problem occurs in a programming environment in which a plurality of programmers perform programming in a distributed manner. For example, in FIG. 13, when a change from the change set 1320 to the change set 1330 causes a single function to extend over a plurality of units, even if different codes are output collectively with the diff command, the programmers are different. In some cases. In such a case, the programmer wastes time to interpret and understand the relationship between code that is not involved and code that is involved.

  Further, consider the changes made between change set 1330 and change set 1340. A function γ and a function ω are simultaneously added between the change set 1330 and the change set 1340. Furthermore, the programmers who have changed the function γ and the function A may not be the same. In such a case, there is a problem that the contents of change cannot be specified for each specific functional unit simply by extracting the difference in the source code using the diff program. In addition, when the change of the source code is inspected with the diff command or the like, the code set of a specific unit that is not related at all to the change of the source code is extracted, and for the debugging process by the programmer and the understanding of the code set, It will also cause confusion.

  A source code analysis system that simply extracts a difference while ignoring a difference in function between two program versions is described in, for example, Japanese Patent Application Laid-Open No. 2004-326337 (Patent Document 1). In Patent Document 1, it is possible to detect a difference between two versions, but a static difference is simply extracted without identifying a function-specific code associated with the difference. Then, the analysis result of the source code is narrowed down based on the extracted difference information. However, the narrowing down can identify only the difference between the previous version and the current version, and does not make it possible to extract the difference of the program depending on the specific function.

  Furthermore, the method described in Patent Document 1 extracts only differences for an application configured by so-called object-oriented programming, in which a unit for providing each function is configured as an object. Therefore, a source code unique to each object is extracted. The difference between the two cannot be identified, and it cannot be said that it is suitable for the verification and execution inspection of the source code created using the object-oriented programming technique.

  Japanese Patent Laid-Open No. 2007-4255 (Patent Document 2) compares two source code versions to generate comparison result information, converts the current version into an execution format, and performs a test using a test case. A program for acquiring and outputting comparison result information corresponding to test result information using the time when the current source code is stored and the time when the current source code is stored is disclosed. FIG. 14 shows a flowchart of the processing described in Patent Document 2. The process shown in FIG. 14 executes a process of identifying a file that has passed a test and registering a difference code between a file that has passed the test and a newer file than that registered in the repository. When an abnormal result is obtained with a file that is newer than the file that passed the test, the abnormal execution result is output in association with the difference code.

  The debugging support method described in Patent Document 2 can also identify the difference between the old file and the new file and display the execution result in association with the difference code. However, just by displaying the execution result in association with the difference code of the old and new files, as to what function the difference code supports, refer to the script of the new file and determine the coding position of the code. Otherwise, the programmer must trace the new file, determine the functional meaning of the coding, is inefficient and requires a holistic review of the source code, and is agile It is difficult to apply to a simple programming environment as it is.

  Further, in Patent Document 2, only code portions registered in the list of test scripts in advance can be tested, and code regions newly added in response to specification changes are not described in the specifications. Is not tested at all and is not suitable for agile programming techniques such as XP.

In addition, in recent programming techniques, object-oriented programming has become widespread and is often coded as a function block for each function. In such a case, setting test items that are scheduled in advance and executing the test cannot quickly respond to specification changes, and multiple changes can be made or described in the previous source code. The problem of not being able to cope with a program development environment such as XP in which a code set that was not present may appear still remained.
http://www.gnu.org/software/diffutils/diffutils.html JP 2004-326337 A JP 2007-4255 A

  As described above, although various methods for detecting a change in the source code and inspecting the change in the source code have been known so far, a change in the source code related to the specific functional unit is detected and the specific functional unit is detected. It does not enable programming support by extracting differences between related and different codes.

  In other words, there has been a need for programming support technology that can be applied appropriately and efficiently to an agile software development environment in which source code is evolved and completed by repeating tests using test cases. It was.

  Furthermore, even when new functions have been added to the source code so far, new functions can be efficiently extracted from the analysis of the source code to facilitate technical interpretation, and the origin of bugs can be identified. There has been a need for a programming support technology that improves the efficiency of identifying problem codes in source code by identifying each unit.

  In addition, by executing a test case corresponding to the evolution of the source code, the source code corresponding to the latest function is not the part that has been implemented for a long time, but the source that exists only in the source code at that time There was a need for programming assistive technology that would identify even a new set of source code on the code and enable effective execution checking.

  The present invention has been made in view of the above-described problems of the prior art, and the information processing apparatus according to the present invention is a test that comprehensively executes the code related to the change when the source code is changed. Create a case, attach an appropriate test case identifier, and register it in association with the functional unit of the changed source code.

  When executing the execution inspection of the source code, a difference code between the new version of the source code and the old version which is the source code created before the new version is extracted. In the extracted difference code, there is a possibility that a plurality of specific functional units of the source code are changed between the old version and the new version corresponding to a plurality of functions.

  In the present invention, a test case additionally registered after the old version is registered is searched and extracted, and the execution inspection of the new version is performed using the extracted test case. Furthermore, it is preferable to retrieve and extract test cases from those registered after the old version is registered and before the new version is registered, in order to ensure the synchronization of the change verification of the source code. The test case is provided as a minimum unit script or program for executing a source code portion changed by a programmer.

  The source code execution inspection is managed in association with the source code line and the execution instruction, and is executed in the test case by processing the line identification corresponding to the execution of the instruction in units of lines. An executed code set from which codes are extracted is created. This executed code set is sorted in the order of element code execution to provide an execution trace.

  The information processing apparatus of the present invention sequentially executes the test cases registered between the old version and the new version in the source code change inspection process, and extracts the difference code between the old version and the new version The obtained code set is classified for each specific function unit, and is output as a specific difference code for each specific function. As a result, the new version code extracted as the difference code is classified for each specific functional unit and then provided for subsequent processing. As a result, the programmer can avoid the effort of going back to the entire source code and interpreting and understanding the changed portion, thereby enabling more efficient programming development.

  Furthermore, according to the present invention, by managing the execution of instructions in association with the lines of the source code, it is possible to perform a debugging process for each specific function changed for the source code. For this reason, it is possible to concentrate on execution inspections on changes created by the programmer or related to a specific functional unit without being bothered by code sets that have been changed separately by other programmers such as XP, so that bugs can be handled efficiently. It becomes possible.

  Furthermore, by examining the execution trace of the test case, the code set of the source code that is not described in the specification and exists only on the source code is identified from the source code corresponding to the latest functions. In particular solution development, it becomes possible to inspect the response status to the user needs and to perform debugging processing specialized for the code.

  According to the present invention, it is possible to efficiently associate a difference code with a function to be provided by the source code even when a plurality of changes are made to the source code corresponding to a plurality of functions. In addition, since debugging can be performed for each function, it is possible to provide an information processing apparatus, an information processing system, a programming support method, and a program for supporting programming that enable more efficient program development.

  Hereinafter, although this invention is demonstrated with embodiment, this invention is not limited to embodiment mentioned later. FIG. 1 shows an embodiment of an information processing system 100 according to this embodiment. An information processing system 100 shown in FIG. 1 stores a verification server 110 for verifying changes to the source code in programming of the source code, and a test case for storing a test case used by the verification server 110 to test the source code. A server 120 is included.

  The verification server 110 manages a source code database 140 (hereinafter referred to as a test case DB) that stores a source code to be verified, and periodically or in response to an external command from an administrator, The accumulated source code is verified. The source code DB 140 is given a version name such as S_v1, S_V2,..., S_v4, and a time stamp corresponding to the time registered in the test case DB, and a plurality of source codes 160 are registered. .

  The language for creating the source code is not particularly limited. For example, Fortran, COBOL, PASCAL, PL-1, BASIC, C, C ++, Java (registered trademark), Java (registered trademark) Beans, Java (registered trademark) ) Applet, Java (registered trademark) Script, Perl, Ruby and the like. The source code may be an execution format in which an execution object is created by a compiler and an instruction is executed, or an execution format that is executed line by line via an interpreter or the like.

  The test case server 120 manages a test case database 150 (hereinafter referred to as a test case DB) that stores test cases 170 related to source code changes. In the embodiment to be described, when the timing for executing the verification process arrives, the verification server 110 is specified from a plurality of test cases 170 registered in the test case DB 150 and assigned identifiers such as TC_1, TC_2,. Extract test cases. The verification server 110 acquires the test case 170 to be tested from the test case server 120 and starts verifying the source code.

  In the embodiment shown in FIG. 1, the verification server 110 and the test case server 120 are interconnected via a network 130 such as a LAN, WAN, or the Internet, and send and receive files under the TCP / IP protocol. It is carried out. When the test case server 120 receives the inquiry request for the test case 170 from the verification server 110, the test case server 120 searches for the test case 170 corresponding to the inquiry. When the test case is searched, the test case server 120 sends the searched test case to the verification server 110, thereby causing the verification server 110 to acquire the test case and enabling the verification process.

  A plurality of network clients 112 to 118 (hereinafter simply referred to as clients) are connected to the network 130. In the clients 112 to 118, the programmer has changed a specific functional unit or a specific code set of the source code, and the source code is sent to the verification server 110 irregularly or periodically. In the present embodiment, the source code change includes a process of adding a code set to the source code and correcting / deleting the code set.

  In certain embodiments, upon receipt of a new change unit, the verification server 110 accumulates in a suitable storage area for a period of time. After that, the verification server 110 overwrites the code area of the old unit corresponding to the changed unit with the changed unit in response to the arrival of the timing to upgrade the source code, and adds the new version name to the source code. Register in the code database 140. At this time, the verification server 110 registers the source code in the source code DB 140 with a version name and time stamp uniquely identifying the source code.

  Hereinafter, the latest version of the source code stored in the source code DB 140 is referred to as the new version, and the source code older than that is referred to as the old version. In addition to the version name, the verification server 110 may register a created time stamp, a creator code, and the like so that it can be referred to as a subsequent change history log or the like.

  Further, the programmer accessing the clients 112 to 118 creates a test case when the source code is changed, and sends it to the test case server 120 in the embodiment of FIG. The test case 170 can execute a code set constituting a specific functional unit related to the change in the source code, and can be executed by the verification server 110 in the test case itself. Is described as

  Further, the test case 170 can describe a test case identifier such as a test case name, a specific function unit name targeted by the test case, a time stamp, and a programmer name. These test case identifiers can be used as indexes when searching for test cases to be verified by the verification server 110 prior to the verification process of the verification server 110.

  In the information processing system 100 illustrated in FIG. 1, the verification server 110 and the test case server 120 are described as separate configurations. However, in another embodiment of the information processing system 100, the verification server 110 and the test case server 120 may be functionally integrated to form a single verification server. In the other embodiment, the information processing system 100 is implemented as a configuration in which the programmer sends a test case corresponding to the change to the verification server 110 together with the unit changed via the clients 112 to 118. In the other embodiment, the verification server 110 receives a changed version of a specific functional unit related to the change and a test case.

  The verification server 110 generates a new version of the source code in response to the arrival of appropriate timing and registers it in the source code DB 140. Thereafter, the received test case is searched and acquired, the acquired test case is executed, and the new version is verified. The verification result can be managed by the verification server 110 as a verification result log of the verification server 110, or can be configured so that the verification result is processed into a debug result and then returned to the clients 112 to 118. The clients 112 to 118 receive the verification result, and when there is no abnormality, start development of the next unit.

  If there is an abnormality, the abnormality part is analyzed, the corresponding addition / change is executed, and the result is sent to the verification server 110 again. In this case, a test case is also sent, but since a test case for a location that reflects the debug result has already been created, the ready-made test case is sent again to the verification server 110 or the test case server 120. You can respond by doing. In addition, for debugging, it is possible to explicitly specify a test case to be used for the verification server 110 and request debugging processing.

  Even when adopting an embodiment that explicitly requests debug processing from the verification server 110 when there is an abnormality in the changed part, the verification server 110 sends the debug result of the code area created by another programmer. The debugging result related to the specific functional unit created by the programmer can be received. As a result, the unit can be debugged and developed separately from functions or code areas created by other programmers, and development efficiency is improved. Further, in the present embodiment, it is possible to concentrate on program development without mutually knowing which area a specific programmer is coding, and it becomes easy to manage information regarding the program contents.

  The verification server 110 or the test case server 120 can be implemented using a general-purpose server device. The above-described general-purpose server device can be mounted with a CISC architecture microprocessor such as PENTIUM (registered trademark) or PENTIUM (registered trademark) compatible chip, or a RISC architecture microprocessor such as POWER PC (registered trademark). The microprocessor can be single-core or multi-core.

  The general-purpose server device is controlled by an operating system such as WINDOWS (registered trademark) 200X, UNIX (registered trademark), LINUX (registered trademark), or AIX (registered trademark), and includes C ++, JAVA (registered trademark), Server programs such as CGI, servlet, and APACHE, which are implemented using programming languages such as JAVA (registered trademark) SCRIPT, PERL, and RUBY, are executed, and transactions are performed with clients 112 to 118. In addition, the general-purpose server is mounted with a RAM, an L2, L3 cache, a hard disk device, and the like to enable various processes. In the embodiment in which the verification server 110 and the test case server 120 are configured integrally, the functions of the servers can be implemented in a form integrated as a general-purpose computer.

  In this embodiment, the clients 112 to 118 are coded by a programmer and used to access the servers 110 and 120. For this purpose, the clients 112-118 can be configured using a personal computer, workstation, server, or the like. Further, the clients 112 to 118 change the specific functional unit and use a file transfer protocol such as HTTP or FTP based on a transaction protocol such as TCP / IP between the verification server 110 and the test case server 120. As long as the change unit and the test case can be transferred, the implementation format is not particularly limited in this embodiment.

  FIG. 2 shows the software block 200 of the verification server 110 of this embodiment. The verification server 110 reads the new version of the source code from the source code DB 140 and the old version created before the new version of the source code, compares the new version with the code of the old version, and compares the new version with the old version. Get the difference code. In this embodiment, the difference code is a mismatch code detected by, for example, the diff command between the new version and the old version, and is present in the new version and not in the old version, and Defined as code that exists in the old version but not in the new version.

  The verification server 110 further searches the test case DB 150 and the like to acquire the test case, and then executes the test case, extracts a code set related to the specific functional unit from the difference codes, and sets the specific difference code set 280. As output. In the present embodiment, the specific difference code means a specific code set in a specific functional unit that can be executed independently by executing a test case within the specific functional unit itself or within the specific functional unit. Each software block 200 shown in FIG. 2 is stored on the information processing apparatus when the information processing apparatus reads the program and data of this embodiment into a program execution space such as a RAM and the microprocessor executes the program. It is realized as a functional means.

  In order to execute the processing described above, the verification server 110 of the embodiment shown in FIG. 2 includes a source code reading unit 210, a source code comparison unit 220, and a difference code registration unit 230. The source code reading unit 210 reads the latest source code, that is, a new version from the source code DB 140 with reference to, for example, the version name of the source code, a time stamp, and the like. In the preferred embodiment, the source code reading unit 210 reads a previously created source code, that is, an old version specified by a version name or a time stamp immediately before the latest version, etc. Are stored as a new version 210a and an old version 210b.

  Note that the old version to be read may be a version created in the past instead of the previous version depending on the purpose of the verification process. Regardless of which source code is adopted as the old version, the function specified by the test case can be verified by using the test case of the corresponding function.

  The source code comparison unit 220 may include a program that can compare source codes, such as a file comparison application, instead of a diff command, a comp command, and a system level command. The source code comparison unit 220 reads the buffered versions 210a and 210b and assigns code line identification values such as code line numbers to the old and new versions of the source code.

  Thereafter, the source code is compared, and the code that is different between the new version and the old version is extracted. Thereafter, the result of the source code comparison unit 220 is sent to the difference code registration unit 230, and the difference code registration unit 230 receives the different code output from the source code comparison unit 220 and registers it as a difference code. The registration format of the difference code can be any registration format known so far. The registration format of the difference code can be a table or list, and a difference code set can be used suitably for subsequent set operations, and search and set operations can be performed using a database program. Therefore, this is a preferred embodiment.

  Furthermore, the verification server 110 includes a test case acquisition unit 250, a source code execution unit 240, and a specific difference code extraction unit 270. In the embodiment to be described, the test case acquisition unit 250 issues a test case 170 inquiry request to the test case DB 150. In the inquiry request, the test case time stamp, function name, creator name, etc. can be used as a search index. Thereafter, the verification server 110 acquires a test case that matches the inquiry request from the test case server 120 and passes it to the source code execution unit 240. The source code execution unit 240 receives a test case, creates an instruction such as an execution-type object or byte code, and executes the code called by the test case for each line of the source code. In this embodiment, an instruction means an assembler, a machine language, or a byte code in the case of JAVA (registered trademark).

  The source code execution unit 240 passes the execution result of the instruction to the code execution inspection unit 260, thereby enabling the execution of the instruction and the code, acquisition of the code contents, acquisition of the execution result, and the like. The code can be identified using various methods, but can be performed using a code line identification value such as a line number generated by the source code comparison unit 220. The code execution inspection unit 260 manages a correspondence table in which code lines are associated with instructions and an executed code set. For this purpose, the source code execution unit 240 and the code execution inspection unit 260 can be implemented using a debugger, and any debugger known so far can be adopted as the debugger to be adopted.

  When the new version of the instruction is executed, the code execution inspection unit 260 refers to the correspondence table, acquires the corresponding code, and registers the code as an executed code in the executed code set. A file in which the codes of the executed code set are sorted in the execution order can be used as an execution trace.

  The specific difference code extraction unit 270 reads the difference code set and the executed code set registered by the difference code registration unit 230, calculates a product set for each set, and extracts codes related to the specific functional unit. Thereafter, the specific difference code extraction unit 270 registers a specific difference code set 280 having the extracted code as an element node.

  In another embodiment of the process of generating the specific difference code set 280, the code execution checking unit 260 receives the code from the source code execution unit 240 in addition to the code identification value of the code corresponding to the executed instruction. The executed code set can be generated using data including the determination of whether the execution result is FAIL or PASS. In the case of this embodiment, the specific difference code extraction unit 270 can extract a registered element of a corresponding executed code set such as a line number registered in the difference code set to create a specific difference code set 280. In the described embodiment, the specific differential code set 280 can provide debug results for code associated with a specific functional unit of source code.

  FIG. 3 is a diagram showing the generation process 300 of the specific difference code set 280 by the verification server 110 of the present embodiment, with codes specified by code identification values such as line numbers as element nodes of each set. In the generation process 300 shown in FIG. 3, a set of all codes included in the new version is shown as a set 310. The verification server 110 includes the inherited code set 320 that includes the inherited code 340 that is the code that remains unchanged as the element node, and the code 370 and 380 that has been changed or added. Separated into a differential code set 330 included as an element node. The separation is performed by the difference code registration unit 230. In the embodiment to be described, the set 350 is a set including a code 370 belonging to a specific function that is not executed by the test case. The set 360 is a specific differential code set 360 executed by a test case in the differential code set 330.

  Further, the specific difference code extraction unit 270 checks the element nodes of the executed node set and the element nodes of the difference code set 330, which are codes that have been executed when the test case is executed by the code execution checking unit 260. Compute the intersection. The result of the product set gives a specific difference code set 360 having the element node 380 as an element.

  The specific difference code extraction unit 270 calculates the product set for all the nodes included in the executed code set, determines the specific difference code set 360, stores it in an appropriate storage device as the output of the verification server 110, and stores the verification log file. And so on. In another embodiment, the specific difference code set 360 is transmitted to the clients 112 to 118 and used for supporting a debugging process by a programmer, and the process ends.

  FIG. 4 shows a schematic flowchart of a code change detection process constituting a programming support method executed by the verification server 110 of this embodiment. The processing in FIG. 4 starts from step S400, and in step S401, the old version before the addition of the function and the new version whose code has been changed are read. In step S <b> 402, the source code comparison unit 220 including the diff command performs comparison, acquires the code identifier of the difference code included in the new version, and registers it in the difference code set 330. In step S403, a test case that activates only a specific function is executed, a code corresponding to the executed instruction is registered in the executed code set, and an executed code set is created. In this embodiment, when creating an execution trace, the element nodes of the executed code set are generated by sorting them in the order of execution and registering them as an appropriate list or table. In a preferred embodiment, the executed code set can be configured as the same data as the execution trace.

  In step S404, it is determined whether or not the code registered in the executed code set is included as an element node of the difference code set 330, the product set is calculated, and the code registered in the executed code set is the difference code. If it is registered in the set 330, it is registered as an element node of the specific difference code set 360, and the process ends in step S405.

  FIG. 5 shows a flowchart of processing for generating an executed code set executed by the code execution checking unit 260 in the present embodiment. The processing in FIG. 5 starts from step S500, and in step S501, an executed code set is initialized, and a correspondence table between an execution instruction and a new version of source code is created. In step S502, the source code execution unit 240 executes the instruction, and in step S503, the code identification value of the code corresponding to the executed instruction is acquired with reference to the correspondence table.

  Further, in step S504, the code execution checking unit 260 determines whether or not the acquired code is already registered as an element node of the executed code set, and if not registered (no), the code acquired in step S508. Are registered in the executed code set. In addition, in another embodiment, the code execution inspection unit 260 can acquire the code contents and the execution result from the source code execution unit 240 in addition to the code identification value, and create an element node of the executed code set.

  On the other hand, if the acquired line number has already been registered in the executed code set in step S504 (yes), the code execution inspection unit 260 proceeds to step S505 to execute all instructions of the new version of the source code. It is determined whether or not execution has been completed. If it is determined in step S505 that execution of all instructions has not been completed (no), the process branches to step S502 and the process is repeated. If it is determined in step S505 that execution of all instructions has been completed (yes), the process branches to step S506 to determine the executed code set. In this embodiment, the element node of the executed code set is further determined. Are sorted in the code execution order to create an execution trace, and the process ends in step S507. Thereafter, the code execution inspection unit 260 notifies the specific difference code extraction unit 270 to request extraction of the specific difference code.

FIG. 6 shows an embodiment of a source code version to which the present embodiment is applied and a test case extraction process 600 corresponding to the version. The source code is created in units of units such as code areas or functions independently by a plurality of programmers. Then, until the program for solving the specific solution is completed, the function of the program is repeatedly changed, and the source code is upgraded. For example, in the source code 610, a unit 612 corresponding to the function α is added, and version v _{x. x} is given. The version registration history is synchronized between the test case server 120 and the verification server 110 so that the source code version is associated with the test case, and an appropriate test case is verified. Corresponding to the source code version to be.

  Further, when the unit 612 is added, the programmer creates a test case 614 that can execute all the codes of the unit 612 and registers it in the test case server 120.

Thereafter, the source code 620 in which the unit 622 corresponding to the function β is added to the source code by the programmer is represented by version name = version v _x. Registered as _{x + 1} . At this time, a test case 624 is sent from the programmer to the test case server 120 and registered. Further, after that, units 632 and 634 corresponding to the function A and the function γ are added by the programmer, and the version name = version v _{x. x + 2} is attached. In this embodiment, the version v _{x. x + 2} is the new version, version v _{x. x + 1} is the old version. In the source code 630, corresponding to the additional function A and the additional function γ, test cases 636 and 638 for executing all the codes of the function A and all the codes of the function γ are registered in the test case server 120.

The verification server 110 of this embodiment identifies a differential code related to a specific function by reading a test case by separating a specific functional unit added or modified in the source code and executing the source code. Make it possible. For this purpose, the test case acquisition unit 250 uses, for example, new version = version v _x. A process for extracting a test case corresponding to the purpose of the test from the test cases registered up to the time point when _{x + 2} is registered is executed. Various embodiments can be adopted as a criterion for the test case acquisition unit 250 to extract a test case.

  For example, in the first embodiment when acquiring a test case, after referring to the synchronization information assigned to the source code 630 which is the new version and the source code 620 of the old version, the old version is registered, In this embodiment, test cases registered in the test case server 120 are sequentially extracted until a new version is registered. The synchronization information may be a time stamp or serial number as long as the source code can be associated with the test case. It can be. This embodiment will be described with reference to FIG. 6. For example, at the time when the new version of the source code 630 is registered, the test cases 636 and 638 are registered before the new version is registered in addition to the test case 614 and the test case 624. Two test cases are registered. Each test case 614, 624, 636, 638 is given a time stamp indicating the time registered in the test case server 120.

In the first embodiment, for example, the test case 636 is registered first, the test case 638 is registered later in time, and then the new version v _{x. A} description will be given assuming that _{x + 2} is registered. The verification server 110 refers to the synchronization information of the previous version, reads the test cases 636 and 638 registered after that from the synchronization information, and sequentially registers them in, for example, the execution queue. Thereafter, the test case 636 is executed, and a specific difference code set corresponding to the test case 636 is generated. Thereafter, the test case 638 is executed to generate a second specific difference code set corresponding to the test case 638, so that it is possible to identify and extract a difference code related to each specific function.

  A specific differential code set can be created as an independent data set for each test case, or a specific differential code set generated for each test case can be integrated and created as a list identified for each test case. You can also. In the embodiment in which the specific difference code set is presented as a debug result to the programmer, an embodiment in which a different specific difference code set is generated for each test case is preferable in reporting subsequent debug results.

  The generated specific difference code set can also be stored as a verification log file of the verification server 110. Furthermore, the specific difference code set is returned from the verification server 110 together with the execution result of the element node of the specific difference code set to the client or administrator terminal computer managed by the programmer who created the test case as a debug result report. Can be used for processing.

  The second embodiment for extracting a test case is an embodiment in which a case instruction code for designating a test case is embedded in an added / modified unit. The case instruction code can use a unit name, function name, (creator + version name) identification value set, etc., and can be embedded as a file name, a comment line, or the like. In the case of the second embodiment, the test case acquisition unit 250 acquires instruction codes such as a file name and a unit name from the new version.

  Thereafter, a test case inquiry request can be issued to the test case DB 150 to obtain a corresponding test case, which can be executed by the source code execution unit 240. In the case of this embodiment, when a plurality of test cases are extracted, the test cases are registered in the execution queue in the order of registration time and executed, and the same as in the first embodiment. Further, the verification log or the debug result may be created by appropriately integrating the extracted specific difference code sets.

  FIG. 7 shows an embodiment of source code 700 to which this embodiment is applied. A source code 700 illustrated in FIG. 7 is an old version corresponding to a unit that provides a specific function, and a programmer performs coding on the source code 700 in the clients 112 to 118 for the purpose of adding a function or changing a function. After coding is complete, the change code is sent to the verification server 110 for creation of a new version.

  FIG. 8 shows a new version of source code 800 that has been modified as a result of coding by the programmer. In the new version, function2 () and related functions, which are different from the functions specified by function1 (), have been added, and the configuration has been changed to include code corresponding to multiple functions. A specific code line has been deleted, but will be described in detail later.

  As can be understood with reference to FIGS. 7 and 8, it is difficult to intuitively recognize which code has been changed between the old version and the new version. In this situation, even if these codes are collectively verified and debugged, a programmer in a programming development environment such as XP spends extra time understanding and interpreting the source code. For this reason, it is necessary to extract a code set in association with a specific functional unit.

  FIG. 9 shows an embodiment of a comparison result by the source code comparison unit 220. The source code comparison unit 220 includes a diff command, adds line numbers to the new version and the old version, identifies code lines whose code contents do not match, forms line marking, code list, etc. To extract the difference code. For example, referring to FIG. 9, in FIG. 9, the code area 910 is a code area deleted in the new version, and the code areas 920 and 940 are code areas corresponding to the function A changed in the new version. It is.

  The code area 930 is a code area corresponding to the function B added in the new version. The difference code registration unit 230 extracts the line number of the code that is the difference code shown in FIG. 9 and exists in the new version, and registers it as a difference code set. In the embodiment shown in FIG. 9, line numbers 12 and 13, line numbers 20-30, and line numbers 42-46 are registered as element nodes of the difference code set.

  FIG. 10 shows an embodiment of a test case 1000 for the new version shown in FIG. A test case 1000 shown in FIG. 10 is a test case for specifying a code related to the code area specifying function A of the source code in FIG. The test case 1000 is coded to exhaustively call functions and methods related to specific functions included in the new version of the source code 800. In the exemplary embodiment, the test case 1000 is given a file name, for example, testcase_compomnentA. The time registered in the case server is added and registered as synchronization information.

  The test case acquisition unit 250 identifies a test case with reference to synchronization information such as a case instruction code and a time stamp. When a plurality of test cases are acquired, the test case acquisition unit 250 stores the test cases in the execution queue and sequentially The source code is executed, and a specific differential code set is generated using the execution trace.

  FIG. 11 is a diagram showing an embodiment of an execution trace generated when the test case 1000 is executed in association with the executed code area. The execution trace 1100 is registered by sorting the code identification values in the order in which the code lines of the source code 800 called by the test case 1000 are executed. The element node of the execution trace can be generated as the same configuration as the element node of the executed code set by including the line number of the code, the code contents, the execution result, and the like. In the embodiment shown in FIG. 11, the execution trace 1100 also displays the execution result of each code line, and the execution trace 1100 also provides the debug result.

  FIG. 11 shows an execution code list 1150 showing the contents of the code lines listed in the execution trace 1100 with the execution trace execution order superimposed on the source code 800 for convenience of explanation. The execution code list 1150 can be included in the execution trace itself as the code contents of the execution trace. Referring to the execution code list 1150, first, the function super () is called with the execution number (1), SampleCommon () is declared with the execution number (2), and then the values sum and num are set with the execution number (3). Are calculated, and the functions commonMethod1 () and commonMethod2 () are called at the execution numbers (4) and (5) for the calculation. In the execution number (5), the function privateMethod1 () is called at the execution number (6). In the privateMethod1 (), the return value = sum / num is calculated, and an error that divides by 0 occurs.

Referring to FIG. 10, the test case 1000 ends the process when the sum / num value is returned. The code corresponding to the code area 930 is terminated without being called. Therefore, it can be seen that the test case 1000 calls and executes only a specific functional unit.
In addition, an error that has occurred in the execution number (6) is assigned FAIL as an execution result and added to the execution trace 1100.

  The execution trace 1100 illustrated in FIG. 11 is managed by the verification server 110 as a table / list format. In addition, it is possible to report to an administrator according to a specific mounting format and purpose of the information processing system 100. In still another embodiment, the specific differential code set 360 or the execution trace 1100 can be sent as a debug processing result to the programmer who created the source code and the test case.

  When creating the specific difference code set 360 instead of reporting the execution trace 1100 directly to the administrator or programmer, the specific difference code set 360 includes code contents and execution results in association with the code identification values. You may not. In the case of this embodiment, a debug result for only the specific difference code set 360 is generated and can be sent to the programmer. The debug result can also be registered as a verification result log by the verification server 110. Any data may be possible depending on the purpose of the programming support of the present embodiment.

  FIG. 12 is a schematic diagram of a process in which the specific difference code set 360 is generated using the source code 800 that gives the execution trace shown in FIG. FIG. 12 also shows an embodiment of the specific difference code set 360. As shown in FIG. 11, the source code 800 includes line numbers 1 to 48. Of these, line numbers 12 and 13, line numbers 20 to 30, and line numbers 42 to 46 are identified as difference codes. The Line numbers 1 to 11, line numbers 14 to 19, and line numbers 31 to 41 are codes inherited from the old version without any change. The verification server 110 activates the differential code registration unit 230 and classifies the codes of the source code 800 into an inherited code set 1220 and a differential code set = {set 1230∪set 1250} as shown in FIG.

  The code execution inspection unit 260 inspects an execution instruction from the source code execution unit 240, generates an executed code set and an execution trace, and is an element node included in the difference code set {set 1230 集合 set 1250}, A code 1240 that also exists in the execution trace is separated and registered as an element of the specific difference code set 1250. In FIG. 12, the executed code set 1270 is indicated by a broken line for reference. As a result, the codes included in the source code 800 are classified into an inherited code set 1220, a specific differential code set 1250, and a differential code set 1230. Of these sets, by generating a specific difference code set 1250 made up of codes 1240 as a verification result, verification can be performed for each specific functional unit.

  The specific differential code set 1250 shown in FIG. 12 includes only the differential code related to the function A shown in FIG. 11 in the source code 800, and its element nodes are line numbers 12, 13, and line numbers 42 to 46. Code identification values, and in other embodiments, code contents and execution results. Note that the codes of line numbers 20 to 30 corresponding to the code area 930 in FIG. 9 remain registered in the difference code set 1230.

  As described above, in this embodiment, when there is a possibility that the source code has undergone a plurality of changes, it is possible to extract only the code that has been changed by designating a specific function. Efficient debugging processing is possible, and efficient programming support technology can be provided.

  Furthermore, according to the present embodiment, the efficiency of FVT (Function Verification Test) or SVT (Site Verification Test) is improved in program development under an agile environment in which a plurality of programmers evolve a solution in parallel. be able to.

  The functions of the present embodiment are legacy programming languages or object-oriented such as C, C ++, Java (registered trademark), Java (registered trademark) Beans, Java (registered trademark) Applet, Java (registered trademark) Script, Perl, and Ruby. It can be realized by a device-executable program written in a programming language or the like, and the program can be stored in a device-readable recording medium such as a hard disk device, CD-ROM, MO, flexible disk, EEPROM, EPROM and distributed. It can also be transmitted over the network in a format that other devices are capable of.

  Although the present embodiment has been described so far, the present invention is not limited to the above-described embodiment, and other embodiments, additions, changes, deletions, and the like can be conceived by those skilled in the art. It can be changed, and any aspect is within the scope of the present invention as long as the effects and effects of the present invention are exhibited.

The functional block diagram of the information processing system 100 of this embodiment. The software block diagram of the verification server 110 of this embodiment. The figure which showed the generation process 300 of the specific difference code set 280 by the verification server 110 of this embodiment as a node of each set by the code designated by the code identification value. 4 is a schematic flowchart of code change detection processing executed by the verification server 110 according to the present embodiment. The flowchart of the process which the code execution test | inspection part 260 performs in this embodiment. The figure which showed embodiment of the version of the source code to which this embodiment is applied, and the extraction process 600 of the test case corresponding to the said version. The figure which showed embodiment of the source code 700 with which this embodiment is applied. The figure which showed the source code 800 of the new version changed as a result of the coding by the programmer. The figure which showed embodiment of the comparison result by the source code comparison part 220. FIG. FIG. 9 shows an embodiment of a test case 1000 for the new version shown in FIG. The figure which matched the embodiment of the execution trace produced | generated when the test case 1000 was performed matched with the executed code area | region. FIG. 12 is a schematic diagram of processing in which a specific differential code set 360 is generated using the source code 800 that gives the execution trace shown in FIG. 11. The figure which showed the rough change inspection procedure 1300 of the source code which uses the conventional diff command. The flowchart of the conventional process which compares the version of two source codes, produces | generates comparison result information, converts the current version into an execution format, and tests with a test case.

Explanation of symbols

DESCRIPTION OF SYMBOLS 100 ... Information processing system 110 ... Verification server, 112-118 ... Network client, 120 ... Test case server, 130 ... Network, 140 ... Source code database, 150 ... Test case database, 160 ... Source code, 170 Test case 200 Software block (verification server) 210 Source code reading unit 220 Source code comparison unit 230 Difference code registration unit 240 Source code execution unit 250 Test case acquisition unit 260 ... code execution inspection unit, 270 ... specific difference code extraction unit, 280 ... specific difference code set

Claims (21)

An information processing apparatus for detecting a change in source code, wherein the information processing apparatus includes:
A source code reading unit for acquiring a new version and an old version of the source code;
A source code comparison unit for comparing code differences between the new version and the old version;
A differential code registration unit for extracting the different codes and generating a differential code set;
A source code execution unit for acquiring a test case added after the old version corresponding to the change and executing the test case in order to execute all code related to the specific functional unit of the changed source code; ,
A code execution inspection unit for detecting the code executed by the execution of the test case and registering it in the executed code set;
A specific differential code extraction unit that calculates a product set of the differential code set and the executed code set and generates a specific differential code set having a code changed in association with the specific functional unit as an element node; Information processing device.   The information processing apparatus includes a test case acquisition unit, and the test case acquisition unit is added before the new version is registered, and searches for a test case that executes a code related to the change of the specific functional unit. The information processing apparatus according to claim 1, acquired by   The information processing apparatus according to claim 2, wherein the code execution inspection unit generates an execution trace that registers the element nodes of the executed code set in an execution order.   The element node of the executed code set includes a code identification value and an execution result of the executed code, and the specific differential code set provides a debug result corresponding to the change of the specific functional unit. The information processing apparatus described in 1.   The information processing apparatus according to claim 4, wherein the source code change is executed in an extreme programming environment, and the information processing apparatus executes a function verification test or a site verification test for the change of the specific function unit.   The information processing apparatus according to claim 5, wherein the specific difference code set is created for each of the test cases associated with the change of the source code. An information processing system including a verification server for detecting a change in source code, wherein the information processing system includes:
A network client connected via a network and changing a specific functional unit of the source code;
A verification server that receives a code set associated with a specific functional unit by the network client, generates a new version from an old version of source code, and registers the old version and the new version, the verification server comprising: ,
A source code reading unit for acquiring a new version and an old version of the source code;
A source code comparison unit for comparing code differences between the new version and the old version;
A differential code registration unit for extracting the different codes and generating a differential code set;
A source code execution unit for acquiring a test case added after the old version corresponding to the change and executing the test case in order to execute all code related to the specific functional unit of the changed source code; ,
A code execution inspection unit for detecting the code executed by the execution of the test case and registering it in the executed code set;
A specific differential code extraction unit that calculates a product set of the differential code set and the executed code set and generates a specific differential code set having a code changed in association with the specific functional unit as an element node; Information processing system.   The verification server includes a test case acquisition unit, and the test case acquisition unit searches for a test case that is added before the new version is registered and that executes code related to the change of the specific functional unit. The information processing system according to claim 7, wherein the information processing system is acquired.   The information processing system according to claim 8, wherein the code execution inspection unit generates an execution trace for registering the element nodes of the executed code set in an execution order.   The element node of the executed code set includes a code identification value of an executed code and an execution result, and the specific differential code set provides a debug result corresponding to the change of the specific functional unit. Information processing system described in 1.   The information processing system according to claim 10, wherein the source code change is executed in an extreme programming environment, and the verification server executes a function verification test or a site verification test for the change of the specific functional unit. A programming support method in which an information processing device detects a change in source code in association with a specific function unit, the programming support method comprising:
Obtaining a new version and an old version of the source code;
Comparing code differences between the new version and the old version;
Extracting the different codes to generate a differential code set;
Obtaining a test case added after the previous version in response to a change in order to execute all the code related to the specific functional unit of the changed source code, and executing the test case;
Detecting code executed by execution of the test case and registering it in an executed code set;
A step of calculating a product set of the differential code set and the executed code set to generate a specific differential code set having a code changed in association with the specific functional unit as an element node. .   The programming support method further includes the step of obtaining the test case, and the step of obtaining the test case is added before the new version is registered, and includes code related to the change of the specific functional unit. The method according to claim 12, comprising searching and obtaining a test case to be executed. The step of executing the test case includes a step of generating an execution trace that registers the element nodes of the executed code set in an execution order, and the programming support method further includes:
Adding a code identification value and an execution result of the executed code to the element node of the executed code set;
The method according to claim 13, further comprising: providing a debug result corresponding to the change of the specific functional unit by the specific differential code set.   The source code change is performed in an extreme programming environment, and the programming support method includes a step of performing a function verification test or a site verification test on the change of the specific functional unit, and 15. The method of claim 14, comprising creating for each test case associated with a change in the source code. An information processing executable program for executing a programming support method in which an information processing device detects a source code change in association with a specific function unit, and the program includes:
Obtaining a new version and an old version of the source code;
Comparing code differences between the new version and the old version;
Extracting the different codes to generate a differential code set;
Obtaining a test case added after the previous version in response to a change in order to execute all the code related to the specific functional unit of the changed source code, and executing the test case;
Detecting code executed by execution of the test case and registering it in an executed code set;
Calculating a product set of the differential code set and the executed code set, and generating a specific differential code set having a code changed in association with the specific functional unit as an element node. Possible program.   The program further includes the step of obtaining the test case, wherein the step of obtaining the test case is added before the new version is registered, and executes code related to the change of the specific functional unit. The program according to claim 16, comprising a step of searching for and acquiring a test case. The step of executing the test case includes a step of generating an execution trace for registering the element nodes of the executed code set in an execution order, and the program further includes:
Adding a code identification value and an execution result of the executed code to the element node of the executed code set;
The program according to claim 17, further comprising: providing a debug result corresponding to the change of the specific functional unit by the specific differential code set.   The source code change is performed in an extreme programming environment, and the programming support method includes a step of performing a function verification test or a site verification test on the change of the specific functional unit, and The program according to claim 18, comprising a step of creating each test case associated with the change of the source code. A programming support method in which an information processing device detects a change in source code in association with a specific function unit, the programming support method comprising:
Obtaining a new version and an old version of the source code;
Comparing code differences between the new version and the old version;
Extracting the different codes to generate a differential code set;
A test case added after the old version in response to the change in order to execute all the code related to the specific functional unit of the changed source code is added before the new version is registered, and the specified Searching and obtaining a test case for executing code related to the change of the functional unit, and executing the test case;
Detecting code executed by execution of the test case and registering it in an executed code set;
Calculating a product set of the differential code set and the executed code set to generate a specific differential code set having an element node as a code changed in relation to the specific functional unit; and Adding the code identification value of the executed code and the execution result to the element node;
Providing a debug result corresponding to the change of the specific functional unit by the specific differential code set, and providing the debug result,
Generating an execution trace that registers the element nodes of the executed code set in execution order;
Adding a code identification value and an execution result of the executed code to the element node of the executed code set;
Providing a debug result corresponding to the change of the specific functional unit by the specific differential code set,
The source code change is executed in an extreme programming environment, and the programming support method executes a function verification test or a site verification test for the change of the specific functional unit, and further, the specific differential code set is converted to the source code. A programming support method for creating each test case associated with the change of the test case. An information processing apparatus for detecting a change in source code, wherein the information processing apparatus includes:
A source code reading unit for acquiring a new version and an old version of the source code;
A source code comparison unit for comparing code differences between the new version and the old version;
A differential code registration unit for extracting the different codes and generating a differential code set;
A source code execution unit for acquiring a test case added after the old version corresponding to the change and executing the test case in order to execute all code related to the specific functional unit of the changed source code; ,
A code execution inspection unit for detecting the code executed by the execution of the test case and registering it in the executed code set;
Created for each test case associated with the change of the source code by calculating the intersection of the difference code set and the executed code set and using the changed code related to the specific functional unit as an element node A specific differential code extraction unit that generates a specific differential code set, and a test that is added before the new version is registered and that searches for and acquires a test case that executes a code related to the change of the specific functional unit Including a case acquisition unit,
The code execution inspection unit generates an execution trace for registering the element nodes of the executed code set in an execution order;
The element node of the executed code set includes a code identification value and an execution result of the executed code, and the specific differential code set provides a debug result corresponding to the change of the specific functional unit;
The information processing apparatus, wherein the source code is changed in an extreme programming environment, and the information processing apparatus executes a function verification test or a site verification test for the change of the specific function unit.

Images